Most settings available for tweaking through the editor profile configuration GUI are currently implemented in wysiwyg.admin.inc even though most editors/integrations do not support them all. The widgets and settings descriptions available in the WysiwygGUI were originally based on the settings offered by TinyMCE and are thus very specific to that editor.
This is becoming a problem since the default state of the profile GUI has lots of widgets not relevant for many editors, confusing users as to which settings are actually possible to change. Editors not supporting some settings will simply not react in any way no matter which value a settings widget in the GUI is changed to, a major UX WTF!
Since #1650416: Allow editor specific changes to be made to the profile settings form was committed (7.x-2.2), it's possible to implement a callback (settings form callback
), defined in the editor metadata, for overriding the form generated by wysiwyg.admin.inc.
I intend to move as many settings as possible from wysiwyg.admin.inc out to the individual wysiwyg/editors/editorname.inc files and update the internal names of the settings to actually match those used by the editor (makes for saner code int the editor .inc files). Settings widgets which are not relevant for an editor will simply no longer exist or be visible for that editor.
Existing editor profiles will be updated to use the new names to avoid having to support two names for the same setting. New editor profiles will automatically use the correct names. This will not affect modules implementing hook_wysiwyg_editor_settings_alter()
because the editor .inc files are already converting the names of working settings (or the editors wouldn't understand them), and that hook has to expect the native names of settings for each editor to make sense anyway. This means you'll see PHP notices about missing settings if you update the code and forget to run update.php. The notices are harmless in themselves, but if you forget to run update.php before editing an editor profile, some settings will revert to their default values.
Comment | File | Size | Author |
---|---|---|---|
#10 | wysiwyg-2018439.10.patch | 59.01 KB | TwoD |
Comments
Comment #1
TwoDAnd here's a first patch for 7.x-2.x-dev.
I've tried hard to move as much as possible without affecting the parts of the GUI which should stay the same for each editor, as in the widgets which do actually work.
Notable things which this does change include:
hook_form_alter()
, but that does not give Wysiwyg any control over when/where plugin settings are shown. Ideally, I only want settings for enabled plugins to show.Comment #2
TwoDForgot to pass $element instead of the $form array in these validation handlers so saving the form throws errors.
I'm doing things a bit different for the next iteration of this patch so it won't look exactly the same anyway.
Comment #3
TwoDLarge update, some highlights:
I could use some help testing this and verify all settings changes are correctly forwarded to the editors. But, since there are other issues depending on this one (most notably the TinyMCE 4 support), I will commit this once those need to go in.
Comment #4
TwoDAnd the patch...
Comment #5
TwoDTypo, will remove this.
UPDATE: Also missed a call to
url()
in tinymce.inc.Comment #6
TwoDFixed the above notes, otherwise the same patch.
Some default values for new profiles are still missing.
Help with testing the upgrade hooks and various editor versions would also be greatly appreciated.
Comment #7
TwoDAdded the last default values for some settings in a few editors.
Removed duplicate code from YUI.
Removed a comment from CKEditor's form callback since it no longer reflects the only thing it did earlier. Switched to using the landing URL for the settings reference link in the comment.
Some minor comments removed since they didn't add anything.
Comment #8
rocketeerbkw CreditAttribution: rocketeerbkw commentedapply_source_formatting isn't used in ckeditor
Move this up to $check_if_set?
Patch applied cleanly, and the update function worked. I only tested ckeditor, but looking over the rest I didn't catch anything wrong.
Comment #9
TwoDGood catches!
apply_source_formatting
is actually used by the JavaScript side of the CKEditor integration to trigger some tweaks to the DataProcessor's Writer class, but I forgot to copy the form element into the CKEditor settings form callback so there's no way to toggle it now. Should probably also rename it to something else while we're at it.I'd like to expand the source formatting options later, but that's for another issue.
Yes, we should move the toolbarLocation check, thanks. Will re-roll ASAP.
Comment #10
TwoDFixed the last points above and committed the attached patch to 7.x-2.x.
Commit: 5bf5886
Thanks for your help, this was much needed!
I've tested all of these changes very carefully, but if something was indeed broken, let's deal with that in a follow-up issue.
Comment #12
TwoDBackported to 6.x-2.x.