Support for Drupal 7 is ending on 5 January 2025—it’s time to migrate to Drupal 10! Learn about the many benefits of Drupal 10 and find migration tools in our resource center.The attached patch checks for the existence of fckeditor.config.js in the theme directory before defaulting to wysiwyg/editors/js/fckeditor.config.js
This means a custom config file can be created (by theme if required) without fear of it being overwritten during WYSIWYG module updates.
I hope the patch conforms to Drupal standards - it's my first Drupal patch so please let me know if I need to do anything differently!
| Comment | File | Size | Author |
|---|---|---|---|
| rb7_wysiwyg.patch | 933 bytes | rb7 |
Comments
Comment #1
sunSorry, but for now, I'm marking this won't fix. Wysiwyg API was designed in a way that should not force anyone to alter any files. That goal may not be completely achieved yet, but that does not mean we have to step backwards.
Comment #2
rb7 CreditAttribution: rb7 commentedI understand where you're coming from and it's a totally laudable goal. I think your key word is that we "should not force anyone to alter any files". I agree. But there are settings available in the config file that I can't believe will ever make it through to WYSIWYG API but are still useful - the ability to enable Firefox spell check, for example. I agree that core options should be web-editable, but think of the patch as allowing users to have ultimate flexibility if they really want to tweak the file as opposed to forcing the average user to alter files. Consider phptemplate files as an analogy: you don't have to use them but the option is there if you want a little more control.
At the very least, this might be a little step in making life easier for existing FCKeditor module users wishing to migrate to WYSIWYG API, which has to be a good thing.
If I still haven't persuaded you, I'll shut up! And thanks for the efforts you're putting into this module.
Comment #3
sunSure, I can understand your point.
But there is another, hidden issue with this that may not be obvious: If users are able to alter / customize / hack the built-in logic (and fckeditor.config.js is, where most of Wysiwyg API's automated/dynamic logic will live very soon), then I can already predict that we have to deal with lots of new bug reports and support requests in this queue, because users managed to break the intended/expected logic of the file while hacking their stuff in. Currently, I'm already buried with support requests for the built-in settings alone - so when users would start to add custom settings this project would fail (much like the FCKeditor and TinyMCE projects failed).
We can discuss this again after #313497: Allow configuration of advanced editor settings hit the wagon.
Comment #4
sunAlso, I want to point you to #287321: Add wysiwyg_external_plugins module, which contains some info about handling of native, external plugins (which I guess FCK's spell checker you referred to is).