From MoodleDocs

Moodle 2.7

Atto is a javascript text editor built specifically for Moodle. Atto is the default text editor in Moodle from 2.7 onwards.

Atto is implemented as a standard Moodle text editor plugin (Editors). Most of the code is written in javascript as a standard Moodle YUI module.

Follow the development of ATTO here:

What does Atto mean?

Atto means: really really small. (10^-18). Well... It used to be :)

The name still ties in with some of the design concepts for Atto which is to be a simple, fast editor users.

Where can I get Atto?

GIT - and you can check here:

Atto Plugins

All of the buttons/menus in Atto are implemented as true Moodle subplugins. This means that the subplugins can do anything a subplugin can do including, lang strings, db tables, yui modules.

There are a couple of extra functions/structure required for an Atto subplugin which are required in order to load a plugin on the toolbar.

Structure of an Atto Plugin

/lib.php Optional. Only required if your plugin needs to implement one of the component callbacks listed below.

/settings.php Optional. Only required if your plugin wants to support custom admin settings. See: Admin_settings#Individual_settings for more info on settings.

/version.php Required. Moodle plugin version. See:version.php for more info on version files.

/lang/en/atto_pluginname.php Required. Language file. This file is required and must at least define the language string 'pluginname'.

/yui/src/button/ Required. The plugin must implement a YUI module that will be included by the editor when the page loads. That YUI module must be named 'button' and must insert itself a class into the Y.M.<plugin name> namespace, with constructor that will be called to initialise the editor. It is recommended that you extend the EditorPlugin class as described below. See: YUI/Modules for more information about YUI modules.

Atto subplugin Php API

Atto sub plugins can contain a lib.php file with 2 callbacks that will be looked for when the plugin is loaded.

The first is "XXX_strings_for_js" (example taken from atto_table plugin):

 * Initialise the js strings required for this module.
function atto_table_strings_for_js() {
    global $PAGE;


The purpose of this callback is to allow the plugin to initialise the strings that it will use in it's user interface. Note: that the pluginname string for each plugin is automatically loaded, and if this is the only string your plugin requires, then it is not necessary to implement this callback in your plugin. See: JavaScript_guidelines#Getting_Moodle_to_load_your_JavaScript_files for more information on strings_for_js.

The second php callback that can be implemented in lib.php is: "XXX_params_for_js" (fictional example, not used in core):

 * Return the js params required for this module.
 * @return array of additional params to pass to javascript init function for this module.
function atto_gambling_params_for_js() {
    return array('bestodds' => '34 to 1', 'worstodds' => '5 to 1');

If you are using this second callback, you need to specify these parameters in your JavaScript source file, passing it as an argument in the constructor:

    ATTRS: {
        bestodds: {
            value: '<defaultvalue>'
        worstodds: {
            value: '<defaultvalue>'

Atto subplugin Javascript API

Atto subplugins must implement a yui module named "moodle-atto_pluginname-button". This module will be automatically loaded when Atto is displayed on a page (and the subplugin is listed in the toolbar configuration).

The plugin:

It is up to the plugin author to decide how best to write their plugin, but it is highly advisable to extend EditorPlugin class, which provides a number of useful functions for dealing with the Editor, Toolbars, Keyboard Navigation, and other related areas.

Of particular interest are:

  • addBasicButton - to add a basic button which directly uses document.execCommand with minimal effort;
  • addButton - to add a button giving you a greater degree of control via your own callback;
  • addToolbarMenu - to add a dropdown toolbar menu;
  • markUpdated - should be called after making changes to the content area; and
  • getDialogue - return a standard dialogue, creating one if it does not already exist.


You may also wish to take a look at some of the existing plugins for examples on how to create the different types:

See Also

Atto makes accessibility tools available to content authors. See

Atto makes use of contenteditable regions, and the rich text editing API supported by modern browsers. See for further reading.

See the comparision (pros, cons, technical notes, missing features, etc) of Atto versus other candidate editors for Moodle 2.7 in

For opening dialogues it is recommended to use M.core.dialogue :