Browsing, insertion, creation of images in wysiwyg editor - the present and future

Hi all,

I wonder if a few folk could take the time to look through this rather long post (sorry!) and give me their thoughts of current and future best practices for wysiwyg image use.

in short

What's the best way, now and for the future, to insert images which are nodes into an article with a wysiwyg editor, allowing both browsing and uploading within the editor? Ideally the image browser is a view, the image content type is my homemade beast, the upload form is just a node creation form, and video (well ideally any asset) could be inserted in the same way. I'd also like to be able to pull any necessary data (eg copyright) from the image node.

background

I created a newspaper site where every story had a picture, but always following a standard format/positioning, so there was no need for inline pictures. I needed to give each picture info such as caption, photographer and copyright, and I needed to use i18n: I chose to have an image as a node, and use CCK fields for metadata rather than ImageField Extended so I could run queries on them. I used imagefield, imagecache, nodereference, nodereference explorer, and a template for the nodereference - it was wonderful!

current situation

On a different site I now need to allow inline insertion of pictures, and for the same reasons as before I think I need to have an image as a node. I'd basically love all of the convenience of my old method, but with an inline image, plus the ability to create the image node within the editor. I've spent a bit of time looking into this (phew) and I've outlined what I see as the options below. I'd love to hear which of these options people currently use, and which folk consider are future-proof. Also, of course, if I've missed out The Easy Way, please let me know:)

image, img_assist, wysiwyg + TinyMCE

pros

• Allows wysiwyg insertion of inline images based on the nid, not a direct link.
• Allows upload and creation of images within the editor.

cons

• Image is at beta, img_assist's at alpha, and in fact if you look here it says the alpha for img_assist's abandoned and implies you should use the dev.
• It's a very specific solution - it only works with images, in fact only with the module-defined image content type. I'd prefer something a bit more generic, but that's not the be-all and end-all.
• If you have translated images, then one image for each translation shows up in the browser.
• Not sure how easy it is to find particular images within a large library.
• If I add a CCK field, eg. photographer, to the Image content type I'm not sure how easy it will be to have it display. Can I just theme it in?

linodef, linodef_taglists, linodef_wysiwyg, wysiwyg

pros

• It's rc5 (well, it's a pro compared to the others!).
• It uses the nid instead of direct links.
• Can be used to insert imagefields inline.
• Might be quite easy to use/adapt for use with assets in general (video, audio, etc.)?

cons

• It doesn't display as wysiwyg.
• I couldn't find a way to integrate it with imagecache, though I'm sure something could be done (add new tags to linodef; play with theming or templating if only simple use of imagecache).
• I couldn't get it to show the taglists as anything other than text lists: not a great way to browse.
• I don't think there's an easy way to allow you to upload and create a new node.

inline

pros

• Works with imagecache.
• Is at version 1.0.

cons

• Only works with files attached to the current node (didn't realise that when I started evaluating:).
• Only allows one imagecache preset for all images.
• Not wysiwyg.

imagefield, imagefield_assist, imagecache

pros

• Allows wysiwyg inline insertion of images.
• Allows upload and creation of nodes (I don't know how much massaging it would take, if any, to create any custom content type, but I presume not too much).
• Avoids direct links.
• imagefield's at v3.2.
• Is a generic solution that feels nice to me:)
• update: can use views for the browser with this patch which worked for me against beta3. The issue's at http://drupal.org/node/613968.

cons

• imagefield_assist and imagecache are both betas (tho it seems every drupaller and their dog uses imagecache).
• If you have translated nodes with imagefields then a) the browser displays the same picture once for each translation, and b) choosing any picture causes a lookup based on fid with no regard for either current language or which picture you clicked on.
• Not sure how easy it will be to hook into the node to get info like author's name. Maybe it'd be better to use ImageField Extended for such data.
• When editing previously added images, I can't go straight to the image edit form - I have to delete and insert again.
• Although it reads and displays the alt text from the imagefield, it doesn't automatically use it.

imagebrowser(v1), image, imagecache, fckeditor

pros

• Doesn't use direct links.
• Image shows up inline as wysiwyg.
• Plays nicely with imagecache.
• Uses a view for browser, nice and flexible.
• rc1 status.

cons

• Uses custom urls such as /imagebrowser/view/image/20/_original, which makes grabbing metadata a bit difficult - but 20 is the nid, so definitely possible.
• Needs fckeditor.module.
• Can't be used with custom image content types.
• No built-in way to get the translation of specified nid (AFAICT).
• The default is to accept an url (minor).

imagebrowser(v2), wysiwyg, imagecache, views

pros

• Uses a view as a browser, so advanced browsing's ok.
• Works with wysiwyg.module.
• Nice simple ui.
• Allows simple adding of css styles.

cons

• Still only at dev.
• Works with a fid, not a nid - possible issues with i18n and metadata.

insert, wysiwyg, imagefield, imageacache

(Couldn't get it to work with wysiwyg, so dunno about the browser - if it has one.)

pros

• Should work with wysiwyg, and plays nicely with imagecache.

cons

• Uses direct links (or imagecache links) - makes i18n more difficult, as well as problems when files move.
• Still at beta.

media, styles, wysiwyg + CKEditor

(I couldn't get anything really working on 6.x, but had a brief play on 7.x-dev.)

pros

• Allows upload to and selection from library.
• Also allows urls.
• I'm guessing it's this beautiful API so maybe loadsa modules will be able to plug into it.
• Apparently it allows you to add fields (eg. photographer) to a piece of media.
• It's massively generic (AFAICT) which is cool!

con: it's not ready!

questions

• Is this the True Path? :)
• Will it be easy to translate fields?
• Is the image browser based on a view or otherwise customisable?
• I wonder if anyone would (very) tentatively say when they think the complete set of functionality I'm looking for might be available in for 6.x. A 'not before' would be great!

new: ProsePoint modules: pp_ed, pp_img, imagecache, imagefield

pros

• On clicking the editor image button, you get a simple choice: upload new image, use existing, enter URL.
• The browser is a view.
• Integrates with imagecache.
• Puts the caption under the image in nice wysiwyg fashion.
• Uses nid in the tag.
• As the caption is stored as part of the tag, it plays nicely with i18n.
• Best wysiwyg inline node as image method for D6 I've seen IMHO.

cons

• Modules aren't released separately from PP.
• Modules are rather hard-coded for specific usecase of PP; you must use TinyMCE, you can't change button options through a web interface, etc.
• Uses custom ifimage content type for images. Inspection reveals it's just a normal node with the body changed from a textarea to a textfield (to act as the caption field), and with an imagefield.
• The caption attached to the node (ie the re-purposed body field) isn't used as the caption when inserting. Presumably the idea is that the general caption you see when viewing in a gallery is different from that you use in a specific article. Still, it would be nice at least to use it as a default.

new: nodereference_explorer, insert, wysiwyg

There's a patch being developed for insert that will let you insert a nodereference in a wysiwyg fashion. This would be fantastic for images, and pretty much anything else for that matter, especially if combined with nodereference_explorer. Thanks, segments, for pointing this one out.

new 3 Sep 2010: wysiwyg_imageupload

pros

• Very sleek looking interface!
• Works all nice and wysiwygey.
• Allows you to choose from a user-defined subset of imagecache presets.
• Allows you to choose user-defined styles.
• Allows simple placement of the image from within the popup.

cons

• It doesn't support images as nodes.
• It requires the use of jquery_update, which is currently alpha.
• I had some warnings about versions being out of date, but I think that's probably a very minor typo in a .info somewhere.

new 3 Sep 2010: nrembrowser

pros

• Can be used with both wysiwyg insertion and choice of nodereference.
• Has finegrained control over which nodes to allow and what to use as the thumbnail.
• Works with imagecache presets.
• Can use exposed views to help users navigate large content sets.
• Can be used to insert other things than images (ie you can install this one solution and use it in quite a few different ways).
• Works with Styles to allow D6 to behave in a similar way to D7 + Media (the future is now!).

cons

• Although it's beta12, I had a hell of a time getting it to work at all. It doesn't help that it uses jquery_ui and jquery_update, but doesn't mention which versions are required. Even so it seems the CSS file for the browser doesn't exist in any of the jQuery UI packages (there's an issue for this). After too much experimentation I found it worked for me (FF 3.6) with jquery_update 2.0-alpha1 and jQuery UI 1.7.4 (and check out http://drupal.org/node/883924 for the path problems - you can either rename the CSS file, or edit the module file). At this point I had a nice looking browser, that showed my image nodes, and allowed me to select and insert them. Unfortunately they showed up as inline code rather than a thumbnail. If I disabled and re-enabled rich-text using the wysiwyg button the image showed up correctly.
• There doesn't seem to be any way to insert captions, though I think in conjunction with styles you could have a field from the node automatically displayed as the caption.

Thanks to Scott J for pointing this out, it actually looks like the way forwards, and isn't *that* far from being ready, but I still wouldn't want to put it on a live site.

conclusion

I loved the elegance of my old nodereference solution. Using a custom view with nodereference_explorer was divine. Creating exactly the content type I needed was supremely versatile. Using the templating system with the nodereference to show the caption and photographer was beautifully simple. The change to inline has suddenly muddied the waters for me - none of the options as I understand them fill me with joy. I'd love to hear people's comments. As I mentioned at the beginning, I'm interested both in what's considered a live-ready solution now, what's considered 'the path of the future', and of course any comments on things I've missed or got wrong.

Thanks in advance, sorry for the length,

Andy