| Project: | Wysiwyg |
| Version: | 6.x-2.x-dev |
| Component: | Code |
| Category: | feature request |
| Priority: | normal |
| Assigned: | Unassigned |
| Status: | closed (fixed) |
Issue Summary
I think I submitted a patch similar to this once before, but I was unable to find it. In the last several sites I've built I've need to adjust TinyMCE settings or configure options that do not yet exist through the UI. The last patch I submitted received the feedback, "we should make the UI support every option TinyMCE supports". I'm not entirely sure that's a good idea (that's a lot of options) and it's difficult to keep up with all the possible options for all editors.
What I'd like to propose is a hook that lets contrib (or custom in my case) modules modify the WYSIWYG configuration options after the defaults have been set by the appropriate editor .inc file. This would allow for the configuration of esoteric options that don't make sense in the UI, or changing of the defaults that are not allowed to be changed.
There's a lot of similar discussion happening over in #313497: Allow configuration of advanced editor settings, including some nice hacks to work around the inability to configure these options with PHP. I'd feel better using a sanctioned method rather than manually inserting things into the Drupal.settings.wysiwyg settings.
| Attachment | Size |
|---|---|
| wysiwyg_config_alter.patch | 675 bytes |
Comments
#1
This is a great patch - thanks!
Without this functionality we would have been unable to move from tinytinymce - please commit it.
#2
Patch works fine.
But why not name it wyswiyg_edit_settings_alter. For me it does make a little more sense here.
With this hook, it is also able to build a rundimentary order buttons extra module. I know this should be included into wysiwy itself, see http://drupal.org/node/277954, but as short-time solution it would be able to use this alter hook.
#3
The name
wyswiyg_edit_settings_alteris a little redundant ("edit" and "alter"). Perhaps you meanwyswiyg_editor_settings_alter? That would be fine by me, of course we'll have to wait and see what sun thinks about adding this hook at all, regardless of its name.#4
sure. I wanted to write this, too.
#5
I found that the default settings for ckeditor were breaking any form theming because the forced width and height of the wysiwyg editor:
function wysiwyg_ckeditor_settings($editor, $config, $theme) {
$settings = array(
'baseHref' => base_path(),
--> 'width' => '100%',
--> 'height' => 420,
The only way to override those values is with a hook settings alter like the one proposed here.
I agree that hook_wyswiyg_editor_settings_alter sounds better, but at the end is just a terminology for something that should be required.
+1
#6
It looks like a nice and useful idea to me. +1
[EDIT] I would also vote for
wyswiyg_editor_settings_alter, because it seems to me "settings" is used in Wysiwyg API already.[EDIT2] BTW, this thing could be used to set the interface language of the editor, I think, and that's pretty nice to have for multilingual sites. :)
#7
Updated patch.
This adds a a alter before the edit specific stuff is loaded. I used this for a plugin-sort module.
#8
Maybe this:
<?phpdrupal_alter('wysiwyg_editor_config', $profile, $theme);
?>
Could be:
<?phpdrupal_alter('wysiwyg_editor_profile', $profile, $theme);
?>
#9
I like this idea. the name config is for me nearly the same as setting. With profile its a different thing.
#10
Bump. Lovely feature! Thank you a lot for to the contributors.
#11
Another vote for
wyswiyg_editor_settings_alter.#12
The second alter hook is totally nice. But the first, I don't really understand. Use-cases? Further remarks inline. ;)
#13
The hook names seem good to me. wysiwyg_profile_load does look like a better place for hook_wysiwyg_profile_alter, if it is to be at all. Changing the callbacks to generate completely different settings would be one use-case, but it would probably be easier and less risky to use hook_wysiwyg_editor_settings_alter and just override all the settings.
I don't think the $theme variable even is the same type between editors (string in some, array in some), so I think we should allow the theme setting to be altered for now. Sending it as part of the context for hook_wysiwyg_editor_settings_alter is probably ok though as it shouldn't be altered there.
#14
Lacking a concrete use-case for the first alter hook, I removed it.
Thanks for reporting, reviewing, and testing! Committed to all branches.
A new development snapshot will be available within the next 12 hours. This improvement will be available in the next official release.
#15
Automatically closed -- issue fixed for 2 weeks with no activity.
#16
Reopening this issue.
We tried adding the teaser 'break' plugin to the settings in the default case (where no plugins/buttons are selected by the administrator for a given format).
Note that the teaser "break" plugin is a drupal plugin and not a ckeditor one. It is not possible to load it using this settings_alter hook provided.
We need an alteration process that allows to load new plugins.
Finally we've been unable to load the teaser break button by module code - if it is not chosen by the wysiwyg administration interface.
#17
It is not possible to load not editor plugins with the settings hook, thats confirmed. Drupal / WYSIWYG plugins need to be activated in the editor settings page, otherwise they wont get loaded. I guess simly those plugins are not included and therefore CKeditor has no idea where to load them.
#18
I'm strongly missing an api to load a plugin and its buttons.
We might need cleaner processes and abstraction here.
#19
The scope of this issue was to allow to alter editor profile settings, which is possible now.
Providing a more extensive API to perform larger changes properly needs to be tackled in its own issue, to which should be linked here. Also note, however, that you are basically asking for more atomic editor "parts" that can be interfaced with individually -- that's roughly the story of http://groups.drupal.org/node/25112