hook_wysiwyg_plugin()
Roger López - June 15, 2007 - 13:19
| Project: | Wysiwyg API |
| Version: | 6.x-1.x-dev |
| Component: | Code |
| Category: | feature request |
| Priority: | normal |
| Assigned: | sun |
| Status: | closed |
Description
I would like to suggest a hook for _tinymce_plugins, so that modules that have accompanying tinymce plugins dont require the person installing the plugin to modify the plugin_reg.php code. It would be a pretty simple matter to do a module_invoke_all and merge the results with the plugins array. This would make the installation of additional plugins much easier, and we could even create drupal modules to easily expose additional plugins.
I can write create a patch, but probably not for a few days.
#1
If you have the time and coding skill to write patches, you're time would probably be better spent updating Nedjo's "expert config" patch...
http://drupal.org/node/121981#comment-203686
That has the functionality you are looking for, but cannot be applied to the current release because of the fixes m3avrck committed that resolved some of the other top TinyMCE issues. I'm still using Nedjo's expert config patch on my installs because the YouTube and PHP buttons were more important that the other issues to me.
#2
I second this. nedjo's patch for custom configuration file support is not related to this feature.
And I would say, a hook system for WYSIWYG editors rocks! Just apply attached patch. It's clean, solid and simple. And it's backwards compatible.
That means, all plugin specific code, f.e. for imagemanager, filemanager or any other plugin, can live in contrib modules from now on. Let's focus on TinyMCE core implementation and building a solid API in tinymce module now.
Attached patch looks big, but changes not quite much.
External plugin names need to be prefixed with a hiven, so TinyMCE does not try to load the plugin from the default plugins directory (see TinyMCE docs). It's automatically prepended for all (external) plugins that are provided by Drupal contrib modules.
This is a real-world example of hook_wysiwyg_plugin():
<?php/**
* Implementation of hook_wysiwyg_plugin().
*/
function img_assist_wysiwyg_plugin($editor) {
switch ($editor) {
case 'tinymce':
return array(
'drupalimage' => array(
'path' => drupal_get_path('module', 'img_assist') .'/drupalimage',
'theme_advanced_buttons1' => array('drupalimage'),
'extended_valid_elements' => array('img[class|src|border=0|alt|title|width|height|align|name]'),
)
);
}
}
?>
This effectively means: Editing of plugins_reg.php is not needed anymore. Install TinyMCE and f.e. Image Assist, enable the plugin and you're done!
Furthermore, contrib modules providing TinyMCE plugins are able to add custom editor variables for tinyMCE.init()!
I'll commit it to Image Assist, if this one has been committed.
#3
Plugins are not loaded, if gzip compressor is enabled. I'll dig into this.
#4
I've spent the last hours debugging TinyMCE's php compressor. Specifically, why external plugins are not loaded if gzip compression is enabled.
I've tried several ways to fix this, but unfortunately, external plugins are only loaded, unless we try to invoke a non-existing member function of tinyMCE_GZ immediately after tinyMCE_GZ.init() has been executed:
try { tinyMCE_GZ.loadPlugin(); } catch(e) {};I have no clue, why that happens. However, this fix works and this patch is ready to be committed now.
#5
Man, that bug was caused due to multiple invocations of tinyMCE.loadPlugin() on the same page. Moved loading of external plugins into its own function, ensuring that external plugins are loaded only once per page request.
#6
Added (contrib module) developer documentation.
#7
This would be a really cool feature.
As the developer of the tinymce extension module linktocontent I've always struggled with finding the best way for users to add the needed text to plugin_reg.php.
Furthermore with this patch there is no need to copy the plugins to tinymce's plugin folder. Very cool!
RTBC and +1
Stefan
#8
Moving this over to the wysiwyg queue.
Let's find out which requirements other editors have and minimize the actual code for TinyMCE et al.
#9
#10
#11
Here we go. See #179712: Implement hook_wysiwyg_plugin() (Image Assist) or the following snippet for Paging module for example implementations of hook_wysiwyg_plugin():
<?php/**
* Implementation of hook_wysiwyg_plugin().
*/
function paging_wysiwyg_plugin($editor) {
switch ($editor) {
case 'tinymce':
return array(
'drupalbreak' => array(
'path' => drupal_get_path('module', 'paging') .'/drupalbreak',
'theme_advanced_buttons1' => array('drupalbreak', 'drupalpagebreak'),
)
);
}
}
?>
Works like a charm for me. :)
@stBorchert: If you're still interested in this, I'd like to get feedback from you, too.
#12
Well, I've reworked the whole architecture last night and just committed that code, because I don't think anyone will ever be able to review and properly understand the patch anyway.
See #269039: Implement hook_wysiwyg_plugin() for a working implementation for Paging module.
#13
Automatically closed -- issue fixed for two weeks with no activity.
#14
OK, I've been trying to see if I could get the Image assist implementation working: #179712: Implement hook_wysiwyg_plugin()
Unfortunately the drupalimage button doesn't show up on the settings page. I've been looking through the code and from what I can tell the hook is fired in wysiwyg_editor_load_plugins(). That function is called when Wysiwyg is looking at a textarea, but I guess it would also have to be called on the profile editing page – otherwise we won't be able to see the buttons that modules make available through the hook.
I'm on Drupal 6 right now, don't know if this issue exists in the Drupal 5 version.
#15
@zoo33: I've just posted a new patch for IA over at #179712: Implement hook_wysiwyg_plugin()
#16
Yes, seems to work now, so I guess the issue was not with Wysiwyg Editor.
#17
Automatically closed -- issue fixed for two weeks with no activity.