A point of view

Replace [ by < and ] by >

Because of the recent activity in
CCK filefield/imagefield implementation for Inline API, I'd like to share some thoughts about Inline API and WYSIWYG.

Our site

We have a home-brewed website in PHP that we want to migrate to Drupal. We handle images pretty much the same way Imagefield does : they are "attached" (DB relation) to each article (node). They have different width presets like Imagecache. Then each image has a "copyright", a "short legend", a "longer legend" and an "alt" field. In our custom CMS we use tags in the "article" textarea to insert these images on our pages. The output can be just an [img tag with a CSS class or more complex, like a div with a CSS class and inside, the [img followed by two [p], the first being the "short legend" + "longer legend", the second the "credits".

Examples of our syntax :
[i123lwhere [i means insert image, 123 is its # in the DB, l means Left (a div of 200px floating at left + other stuff). The [img src uses a preset of the image which has a width of 200px
[i123r = same but Right, preset 200px
[i123c = center, preset 622px
[i123v = just the [img src with the preset "thumbnail" (80px wide).

Now with Imagefield, we can't use a theme-level solution with content-field-field_imagefield.tpl.php or node-type.tpl.php. That is because my editors want to have better control on how the pictures appear in the article : where, how.

Then we can't use solutions like Filefield Insert. The reason is simple, if we change the legends or copyright of the images, we shouldn't have to edit it at two places.

So the tags approach is essential to us.

How to implement this in Drupal

I see 3 steps :

STEP 1 : manual insertion of the tags + imagecache preset + display method + overridable template files at the theme layer

In the step 1, our editors have to know the syntax of theimages tags. They type a tag on their keyboard and on the node view, the
tag is rendered by Inline API.

The tags syntax must :

• identify the image by it's weighted position : 1 is the lightest imagefield or first uploaded if all the weights are at the default value, ...
• identify an imagecache preset
• identify a 'display method'
• identify an alignement of the tag output container

Example :
[img3|max_width|all|left] = take the 3rd image with the preset 'max_width', output what's in the inline_imagefield-all.tpl.php in a container floating to the left

Some default 'display methods' could be provided along with their corresponding inline_imagefield-METHOD.tpl.php. It should be possible to override these display methods at the theme layer and to provide new ones. For example, in the latest Imagefield releases I pushed to allow a textarea and a extensible max length for the Title field. I plan to migrate all my current image fields (copyright, short legend, longer
legend) in that field. Then I need to be able to output a div or more complex with the Title textarea content, which is not at all the standart Title field use. That's why these inline_imagefield-METHOD.tpl.php should control the whole output of the tag, and we should have accessible in that .tpl.php :
- the imagefield
- the imagecache preset
- the alignement

STEP 2 : WYSIWYG integration + Filefield_sources

The step 2's first goal is to be able to visually insert/modify the tags of the step 1. It should be a WYSIWYG API plugin compatible with TinyMCE. The definition and code of new 'display method' should not be integrated in that GUI, they stay at a developper level. The display in the WYSIWYG textarea would still be the un-rendered tag.

The second goal is the integration of Filefield_sources, to allow editors to re-use Imagefields images associated to other nodes. I'd like to see an autocomplete search, where the search would be performed on Imagefield fields, and the search results would be images thumbs.

In the spirit of InlineAPI, if an Imagefield image from node X is used in node Y, it should not be possible to delete the image while editing the node Y.

STEP 3 : Better WYSIWYG integration

In that step the tags would be Ajax-rendered in the WYSIWYG textarea. The un-rendered tags would still be stored in the node, not
the output. Moreover, when an editor clicks an inline_imagefield block, the GUI should open to allow modification/deletion of the tag.