.
.
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.
Attachment | Size |
---|---|
inline-wysiwyg-api.png | 38.59 KB |
Comments
How is the project going? I
How is the project going? I would love to help out
vision media
350designs
Print Huge Edmonton Printing Services
Design Inspiration Gallery
Tj Holowaychuk
Vision Media - Victoria BC Web Design
Victoria British Columbia Web Design School
Development of Inline API
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
netzstrategen
Sounds very promising
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.
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
Hi sun,
This is exactly what Drupal needs imho. How are things going?
imagefield please ;)
imagefield please ;)
Luís Pedro Algarvio
Drupal and DevOps Developer, Evangelist & Trainer
lp.algarvio.org
Subscribing
Subscribing
Is this discussion still ongoing?
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
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.