sun's vision for handling embedded/inline content and Wysiwyg in Drupal

.

.

As some of you know, I've recently taken over maintenance of Inline and Image Assist, and initiated the Wysiwyg project. That was not only caused by personal interest, but also to take the necessary steps to realize the long awaited Inline API. You might ask yourself, what those three modules have in common or to do with each other at all: They deal with user input, allow to embed complex contents into a content, and provide an interactive GUI for that. If you already had the chance to work with them, you already know that there is a rather hidden, non-obvious hard-dependency between them.

Although I'd really like to discuss both topics (Inline and Wysiwyg support) separately, the gained experience on these topics enforces us to discuss them concurrently. The following mockup hopefully explains why: (see attachment to view in full size)

This draft already incorporates Gabor's battle plan for Wysiwyg support in Drupal.

1. Inline API macro management

• configurable per input format
• automatically forces/ensures that required HTML tags for macro rendering are in the set of allowed HTML tags.

2. Inline API macro processing

• available/required arguments supplied through hook_inline()
• support for default values and multiple values
• parameter validation
• CCK support
• stores references of inlined contents in the database to track where else a content (f.e. an image) is in use
• very easy to implement for any contrib module
• centralizes required code for macro processing into one module
• goal: standardized way for macro processing in Drupal

3. Inline API macro rendering

• allows to display any contents inline
• cached output via Drupal's filter system
• provides previews for Wysiwyg editors

4. Inline/Wysiwyg API plugin framework

• exposes an Inline API plugin widget to textarea buttons and Wysiwyg editor buttons
• invokes a widget in a popup, modal dialog (you name it...)
• returns user supplied data from the widget as a macro into the content (textarea/editor)
• allows to edit existent tags in contents (tags shouldn't be written manually)

5. Inline API widget

• each hook_inline() implementation automatically provides a default/basic widget
• supports extended widgets (f.e. Image Assist)
• returns user supplied data (macro parameters) to the framework

6. Inline API plugin button

• controlled by Inline API macro management
• displayed below a textarea
• only displayed if no Wysiwyg editor is enabled for a field

7. Inline API instant plugin button

• inserts an Inline tag based on an already displayed widget (f.e. node attachments)

8. Wysiwyg API (editor) controller

• configurable per input format (in D5/6 also per content-type, page url, and field name).
• automatically forces/ensures that required HTML tags for all editor plugins are in the set of allowed HTML tags.
• allows editor and editor plugin configuration per editor
• may allow to assign an editor or editor profiles to user roles
• supports loading of different editors on the same page

9. Wysiwyg API plugin button

• controlled by Inline API macro management
• displayed in an editor's toolbar
• invokes a widget via the Inline/Wysiwyg API plugin framework

10. Wysiwyg API editor plugin hook

• allows to add external editor plugins via hook_wysiwyg_plugin() (f.e. Link to node)

As a result of having both APIs working, a module like Image Assist would not have to deal with macro processing at all. Image Assist would only provide a extended widget (for selecting images), some rendering-related settings, and a button for Inline/Wysiwyg API. The framework takes care of user access, user input validation, generating and parsing of macros, aso.
As an (almost working) example, the former Inline v1 module (which allowed to embed uploaded attachments into a content) has been ported to implement hook_inline(). Many feature requests of Inline's issue queue are actually resolved due to that.

While Inline API is already under heavy development and plenty of above features are already implemented, Wysiwyg API only gained interested developers so far. From my personal experience, I can understand that not many Drupal developers have studied and dealt with the code and issue queues of available macro-based, Wysiwyg editor and editor plugin modules for Drupal - which is badly required to bring both APIs into shape. However, if you would like to contribute to these efforts, please let me know.