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

sun's picture

.

.

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.

AttachmentSize
inline-wysiwyg-api.png38.59 KB

Comments

Development of Inline API

sun's picture

Development of Inline API happens in the DRUPAL-5--2 branch of Inline module. Alpha code, along with a list of plenty of todos is in place, patches are welcome! If we get this code into shape before the D7 code freeze, a feature request to include Inline API for D7 might be possible.

Daniel F. Kudwien
unleashed mind

Daniel F. Kudwien
unleashed mind

Sounds very promising

jaharmi's picture

I think this sounds very promising, if I’m understanding the plan correctly.

Here are a couple of items I see as useful for inlining (based on experience with other CMSes, namely Userland Manila from the early 2000’s), and it seems that you have them accommodated.

  1. Internal links to other nodes, especially by node name (see the Freelinking module), with or without alternate text
  2. External links to other sites (also see the Freelinking module), with or without alternate text
  3. Inline images from the site, especially if they can be resized or otherwise processed from their originals, as well as positioned on the page
  4. Inline images from an external source, such as Flickr, preferably with the same processing options as internal images
  5. Include another block, node, or portion of a node within the current node (which is more common on some documentation-oriented wiki software, as I’ve seen in DocuWiki and TikiWiki), to enable modular content that can be updated once for inclusion in multiple pages
  6. Produce the results of fields (CCK?) or calculations (macro processing?), with the administrator’s ability to set limits on what is considered safe (see Userland Manila’s macro processing at http://macros.userland.com/). It would be really awesome to just be able to insert some live data inline — especially the kind of data available in the Drupal Token module.

It’s fascinating and frustrating that so much of the capability is already available in Drupal through a combination of modules. However, they don’t all work together or pull in the same direction yet. I think your battle plan is right-on in the sense that it needs to be brought together to be able to take the next step.

Hi sun, This is exactly what

AndyF's picture

Hi sun,

This is exactly what Drupal needs imho. How are things going?

imagefield please ;)

lpalgarvio's picture

imagefield please ;)

Luís Pedro Algarvio / LP / LPCA
Drupal Specialist | Debian Linux Consultant | Project Manager -- Solutions on steroids
lp.algarvio.org

Subscribing

mbahlol's picture

Subscribing

Is this discussion still ongoing?

tonychung's picture

Can @sun update this post to direct us to the current state of this project? I think I used inline and image assist in a D7 project but it didn't provide this seamless experience. All my clients want WordPress. I want WP ease-of-use and Drupal performance. ;-)

Media module

effulgentsia's picture

Try out Media module. It's not perfect, it has a bunch of open issues, and it's not really the same as the vision outlined in this post, but it might work for your needs in the meantime.

Image

Group organizers

Group notifications

This group offers an RSS feed. Or subscribe to these personalized, sitewide feeds: