The profile configuration UI reads the available plugins and their buttons from values coded into _tinymce_get_plugins(). This means if a user adds a custom plugin to tinymce's plugins directory, she/he then has to manually edit the file plugin_reg.php to register the plugin and its buttons (if it has any). So, having patched a module file, the user is faced with the usual problems when upgrading.

How can we enable users to add plugin support without patching the module code? What are the options?

Finding out what plugins are installed is easy--scan the plugins directory, find the child directory names. The difficulty is with button names. Plugins don't explicitly describe their buttons. Typically you need to read the readme file included with a plugin to know what buttons it has.

I can think of a couple possible approaches to coding this.

1. we move from a hard-coded list in plugin_reg.php to a set of files, one per plugin. These would be be read in and parsed to get the set of available plugins and their buttons (testing for the existance of the plugin directory to ensure it's installed). A file in php ini format might look like this (name: media.plugin):

theme_advanced_buttons3 = media

So to add support for a new plugin you would write a new file.

2. We provide a UI that saves its data in the database (maybe as a variable). The page scans available plugins and compares them to those already registered in plugin_reg.php. If it finds unregistered plugins, it provides a list of them to enable (check its checkbox), along with fields to specify their buttons.

In either case we'd need to think through what happens when a user has manually added a plugin that later gets default support in the tinymce module.

Is supporting custom plugins a priority issue? Thoughts on which approach would be better, or other possibilities?

Comments

luti’s picture

luti commented

Whatever the approach would be, it would be very nice if custom plugins could be added to a plugins directory directly in TinyMCE module and not in TinyMCE plugins directory. This way, upgrade to new TinyMCE would be much easier and straightforward.

About the names, I would suggest a combination - the version 5 module info kind of file per module could be a default (but not absolutely requested), and this data could be overridden (or, specified, if there is no info file present) through admin settings available at the admin page.

For a situation when a new version of TinyMCE provides certain plugin, which was custom until then, I would suggest:
- to provide a mechanism for admin to be explicitely notified about the duplication
- as a default the newly provided plugin (which probably should be newer and better fitted to a new version of TinyMCE, or?) to be chosen
- default choice to be easily overridable with a custom version through admin screens (tabbed browsing, not to interfere with already quite a lot of settings in TinyMCE module...?), without a need for any manual changes of the code (in filesystem)

Too complicated all together? Sorry, I am not he coder, so I look it purely through the eyes of an admin not skilled in this...

By the way, there are some other "annoyances" I have to edit any time a new versions of TinyMCE are installed:
- I don't like <p> style line breaks, so I have to switch defaults to <br> ("force_br_newlines" default from false to true, "force_p_newlines" default from true to false)
- I mainly enter the code manually (and, want to manually control newlines as well), so I have to switch off automatic newline handling ("remove_linebreaks" default from true to false)
- due to some strange Firefox behavior, I have to make a default for windows to be resizable (args['resizable'] default from "no" to "yes")

Could these (and, maybe some more) settings be included in the admin pages settings to avoid this, please, or is it too complicated?

mupsi’s picture

mupsi
she/her
commented
Status: Active » Closed (outdated)