The original intent of this issue was to allow TinyMCE plugins to be disabled. However this has changed into an API to allow all plugins to be re-ordered and/or disabled.

In working on this I discovered that we don't have a single, standardised way of displaying a list of plugins for a plugintype. We have about 30 - one for each plugintype. This means that we have:

a range of different tables with:

• different headers
• different columns orders
• different wording
• duplicate code all over the place
  R
  ather than adding to this hellhole of a mess, I have instead opted to spend a little more time on this change and:
• add a new plugin_management_table which extends the standard flexible_table class and implements the dynamic table interface;
• written appropriate JavaScript to make toggling of enabled/disabled flags via JS with a table reload instead of whole page reload
  further extended this to support re-ordering of plugintypes which support this

It is well beyond the scope of this issue to replace all of these cases, but I have implemented the following locations in an effort to ensure that all of the standard use-cases are supported:

• editors (list of available editors)
• blocks
• activities
• TinyMCE plugins

The design of this approach means that any plugintype wishing to use the interface must:

• extend the plugin_management_table class (this is unavoidable because of the nature of the dynamic table system
• ensure that all behaviour for enabling/disabling a plugin, and (if relevant) ordering plugins within the plugintype are fully and correctly encapsulated inside that plugintype's plugininfo class

For any plugintype wishing to extend this in some way, such as the following may do so:

• adding columns
• modifying existing columns

To cater to these changes the JavaScript component to this is written as a class which can be extended with additional behaviours added to the event listeners and/or alternative web services used by setting the relevant methods.

Note: Non-javascript control is maintained with a slimmed-down version of the current files so as to support behat.

I imagine that this change in UI will likely cause some behat failures, and I need to see about unit + behat testing some of the features.