Uploaded image for project: 'Moodle'
  1. Moodle
  2. MDL-52996

Allow Atto customisation for special-purpose plugins



    • MDL-52996-master
    • Hide

      1. Run Behat tests for editor_atto (specifically lib/editor/atto/tests/behat/customtoolbar.feature)
      2. If desired, do additional manual testing by looking at lib/editor/atto/tests/fixtures/custom_toolbar_example.php on your Behat setup

      1. Run Behat tests for editor_atto (specifically lib/editor/atto/tests/behat/customtoolbar.feature) 2. If desired, do additional manual testing by looking at lib/editor/atto/tests/fixtures/custom_toolbar_example.php on your Behat setup


      This feature is not required for core development but it makes a range of enhancements possible for plugin developers.

      We would like to be able to customise the Atto toolbar for a specific instance of the editor. For example, we might have two instances of Atto on the same page:

      • one is a normal editor with normal buttons as per system settings
      • one adds two custom buttons (Atto plugins) that let you add flooglegrobs and manglebleebs to the editor

      In this case, flooglegrobs and manglebleebs are special features that are not available (a) as part of standard HTML, or (b) via Moodle filters. They are only available within specific fields of the specific editor, which receive special processing on input/display. So we do not want to add them to the general editor settings and have them appear everywhere.

      I don't want to waste too much time going into detail of why we want this but suffice to say it is sometimes necessary. For a practical example of a flooglegrob, which is actually in no way related to the plugin I'm writing, you could imagine something like a quiz question in which it is possible to insert special placeholders that the quiz question (and only that specific type of quiz question) will use. Maybe the placeholders have complex options so we want to make a nice dialog to insert them rather than just typing square brackets or whatever. Then, obviously you don't want these buttons to appear everywhere systemwide, because they are only applicable in that question type.

      There is a workaround to achieve this feature which is to include the plugins everywhere, but use the callback within an editor plugin that controls whether it's available to the current user (which is intended for capability checks etc.) in combination with some global variable to decide where they appear. And/or you can also hide unwanted buttons with CSS. But this is kind of sucky because:

      • Callback, global variable, CSS button hiding, ugh.
      • If there are a lot of plugins like this then our global editor configuration is hard to read/modify.
      • If there are a lot of plugins like this in a particular instance (especially if it's more than just flooglegrobs and manglebleebs) then we might want to redesign the editor layout for that location, i.e. move other controls around to make space for them.

      In order to solve this problem elegantly and without major code changes, I suggest that it should be made possible for a plugin to override the global config setting that lists the Atto toolbar items on a per-editor basis. This is extremely simple and appears to work.

      In other words, the effect of this is that normally, the system administrator controls what buttons appear in the Atto toolbar; but in specific plugins where something special is needed, the plugin developer can control it. (Obviously, if necessary they could add extra admin settings to let the administrator customise this as well.)

      Some disadvantages of this approach:

      If we respect the user's preferred editor setting and the user has chosen a different editor then they will not get the plugins or the custom configuration.

      • True, but this is inherent in the very idea of implementing editor plugins for functionality like this. We would still like to be able to do it for our custom plugin. This probably wouldn't be an appropriate way to do it for core Moodle.

      This is a bad way of implementing, the more general concept of a 'reduced' or 'compact' editor profile where you can have an editor with fewer buttons.

      • True, but that's not what we need for this situation; having a compact editor profile wouldn't help us implement flooglegrobs, let alone manglebleebs.

      So far as I can tell (admittedly I've only done a rather minimal example) this is basically a five line code change, which you can see in the attached. I made a Behat test and associated fixture to demonstrate it working. You can see what it looks like in the attached screenshot.

      There was nowhere very clear to document editor options. I've added documentation (including for the existing editor options) to the phpdoc within the Atto use_editor function, and also added a hint to the base class use_editor function so that people might go look there!




            quen Sam Marshall
            quen Sam Marshall
            Dan Poltawski Dan Poltawski
            Andrew Lyons Andrew Lyons
            Simey Lameze Simey Lameze
            Andrew Lyons, Huong Nguyen, Jun Pataleta, Michael Hawkins, Shamim Rezaie, Simey Lameze, Stevani Andolo
            0 Vote for this issue
            7 Start watching this issue