I've recently committed a project that provides an input filter that is inlining node titles, field values and taxonomy terms by ID.*
To utilize this the module has to provide buttons for editors that uses the filter tags and there the WYSIWYG API comes in mind. To provide those editor buttons (list of certain nodes/fields/terms) I return the data of a db query (for details see link) (1) and the output is forwarded to different buttons (autocomplete field, select list etc.) (2) and then sent to the editor by an additional function (3) because each editor uses a different "button format".
Is it possible to do step 3 with (a planned version of) WYSIWYG API, so the raw data of the db query or better the themed button containing that data can be submitted to WYSIWYG which then initialize this button for every editor supported? Currently I have to write an extra button for each editor and provide it by self written submodules.
*((the way like the issues are linked at drupal.org and unlike Inline API which will do it with "img_assist like tags" as I understand))
Comments
Editor plugin API
As visible in the roadmap, the current spotlight is Wysiwyg's plugin API rewrite. It does not make sense to implement support for all the editors in your own module. Instead, Wysiwyg's plugin API will allow all Drupal modules to expose editor buttons that may be used in an input format/editor configuration.
However, to achieve this, the current editor/plugin API in Wysiwyg needs to be rewritten. The work on this has already begun and the current patch already supports (very) simple plugins that just need to insert contents into the currently enabled/attached editor. The next step will be to introduce support for dialogs as well as editing already inserted contents.
Effectively, this probably means that you will have to refactor your module's plugin and add a dependency on Wysiwyg API.
Regarding Inline API, the current code assumes just one syntax for macros. However, we already identified that Inline API could support any syntax, and not just one, so it could also support different markup languages like Wiki-syntax.
Daniel F. Kudwien
unleashed mind
Daniel F. Kudwien
netzstrategen
Editor plugin API: button workflow
Sounds good. If the dialog works it would be nice if the final editor API wouldn't be limited to that:
I'm using popup windows since the content of my buttons could consist of hundreds of choices. Therefore I use an autocomplete textfield, too. That and the popup window are called by the editor with a small javascript function that opens the popup window. This JS function is same for all editors, but to pass the variables to the path every editor needs different ways. So the editor support (sub)modules I was talking about have two functions:
a) Pass needed php variables to my Filter Buttons API (containing popup/autocomplete and gets data for buttons) and call the JS function of the Filter Buttons API.
b) Send the user input back to the editors textarea with a custom JS function (different for each editor).
As far as I understand editors API provides an own JS textarea Object and functions for (b) like BUEditor but (a) is not possible currently or limited to the dialog.
Therefore I imagine the following button workflow:
This will be a minor task in comparison to the work I will spare when all editors are supported by my module that WYSIWYG API supports. :)
...
The first generation of the new plugin API supports static plugin settings that are defined in the plugin definition file in PHP. As mentioned before, the new plugin API will also have to support plugin settings callback functions to allow the user to configure advanced settings for each plugin and provide those configuration values via JavaScript (if required).
Simple insertion of content is already done and working with the current patch.
Almost, but too geeky and complicated. Instead, each Drupal module can simply expose one or more editor buttons/plugins by implementing hook_wysiwyg_include_directory(). Each PHP file defines a new plugin/button, and needs a corresponding JavaScript that integrates with Wysiwyg API. The JavaScript is more or less just one JSON object implementing various, pre-defined callback functions, such as getContent(), setContent(), isNode(), aso. (please look at the patch for details, resp. actual method names)
Unfortunately, it's not that easy. Each editor implements its own way of dealing with buttons and plugins. If BUeditor requires a plugin to register an onClick event for a button, that's a fairly poor way of handling plugins. Wysiwyg API tries to integrate tightly with the actual plugin data flow of each editor, which will effectively mean that it registers so called "proxy plugins" that only have one purpose: transmit, process, and convert data from the editor's expected format to a unique format expected by "Drupal plugins". This means that the proxy plugin will be different for each editor and editor version, but the JavaScript of plugins provided by Drupal modules is always the same and works with all editors (which support plugins/buttons).
Basically yes. Everything in a dialog (if required at all), must be provided by the Drupal module, which provides the plugin. However, another long-term vision is to also provide a consistent UI across all "Drupal plugins". Well, offtopic for now...
Daniel F. Kudwien
unleashed mind
Daniel F. Kudwien
netzstrategen
Plugin system in WYSIWYG v3
What are the plans for WYSIWYG API v3 regarding WYSIWYG plugins? Currently (WYSIWYG v2) the plugin system works very well if you want to insert a single button, e.g. a themed popup like img_assist does. However when one wants to add several buttons you have to write one plugin for each button. Adding dynamically created buttons (e.g. on an admin settings page) is currently not possible like discussed in the BUEditor support issue.
Are there plans to work further on the plugin system for v3 or will be the plugin hooks of v2 likely be the same in v3 (so I can adjust my work priorities accordingly)?
Yes, the JS API for plugins
Yes, the JS API for plugins will be revisited for 3.x as well. Not only because we want proper support for dialogs as well as text processing (for all Drupal plugins), but also, because (the still in flux) Inline API demands some enhanced integration possibilities from Wysiwyg module.
Daniel F. Kudwien
unleashed mind
Daniel F. Kudwien
netzstrategen