[development] inline files. last desparate attempt.
Bèr Kessels
ber at webschuur.com
Tue Dec 6 14:32:23 UTC 2005
Hello
Last week and this week I am finalizing some work for remixreading (now
remixcommons). One of the aims of us, was to move closer to vanilla Drupal.
Using pure vanilla is still not possible, because of the limited file supprt.
I have started betterupload, which I am developing primarily for remixcommons.
But for now its still too betha to use in a production environment. However,
since getting that drnd inline patch updated is far too much work after all
the fapi changes, I decided to leave core what is and add some nice features
to inline.module.
* autoinline. One can now choose per node type, if attacements should go
inline automatically:
** in the teaser
** in the body
** in both,
** not at all.
* how small an image must be to show up inline. (dont show larger then
400*500, for example)
* For themes: I add an inline flag: $node->file[fid]->inline == TRUE for
inline files.
All of this has rather crude default settings, but can be very well themed.
None of this changes the default filter tokens or their behaviour.
I have a few questions though:
* Why does inline module not use the filter system, nodeapi(view) it uses now
performs horrible! And previews do not show us the inline files.
* How could we enhance the UI for inline images? I personally prefer to add a
hook_quicktags, to add a JS button in the quicktags bar for each attached
file.
* How can we keep all this consistent? We should really re-think the
** logic to decide when an img must be inserted with an img tag (see above
about settings)
** logic when to show a link and when to show nothing.
** how the tokens and the autoinline work together. e.g. should an image not
be auto-inlined when a token for that image is inserted? Should we add a
token autmatically rather then changing $node->body on nodeapi(view) ? and so
on,
I would love some feedback. (initial patch will follow soon)
Bèr
More information about the development
mailing list