MoodleDocs - User contributions [en]

Forum update

2014-05-20T01:43:15Z

Phalacee: /* Documentation */

{{Work in progress}}
{{Infobox Project
|name = Moodle Forum Revamp
|state = Specification
|tracker = MDL-39707
|discussion =
|assignee = Jason Fowler & Andrew Nicols @ Moodle HQ
}}

== Project goals ==

The headline goals of this update are:
* to substantially improve the accessibility of the Moodle Forums;
* to make the forums more modern in appearance;
* to make it possible for theme designers and developers to override aspects of the forum layout easily;
* to allow for creation of new forum types; and
* to make it easier for subsequent creation of new features.

In achieving the above, a number of related benefits are anticipated:
* a more manageable and maintainable codebase for the forum;
* reduced complexity in the generated markup;
* improved developer documentation;
* a thorough review of all existing code; and
* removal of long-since deprecated sections of code.

Although performance enhancements are desirable, we cannot state the effect of these changes on performance. It is hoped that the compartmentalisation of existing code into more manageable chunks will reduce memory consumption.

== Considerations ==

* Backwards compatibility
* Creating sub-plugins for "Forum Types" (Q&A etc) and "Forum View"
* Subscription management
* Editor Light - a cut down version of Atto for "Reply inline"
* Make use of Renderables and Renders

== Description ==

At present the Moodle forums are the oldest part of the code base, and lag behind the rest of Moodle in a big way.

We hope to implement a new interface for the forums, based on the accessible view from MoodleRooms' HSU Forum, and add some new functionality over time.

== Current issues ==
At present, a number of issues have been highlighted with the forum, including:

# the forum cannot be overridden by theme designers or developers;
# it is impossible to add contrib forum types;
# it is difficult to add new core forum types;
# the forum is not WCAG compliant;
# the forum themeing has been neglected and looks out-of-date when compared with other parts of Moodle;
# it is impossible to style or override appearance of forum emails;
# the forum does not use the new scheduling API;
# the "News forum" is very different from other types which complicates logic in many places;
# several core parts of Moodle are strongly tied to forums (e.g. News forums in courses);
# a number of core features are missing:
#* thread level subscription
#* anonymity;
#* the ability to send private replies in context;
#* inline reply;
#* post locking and time-based locking;
#* post hiding;
#* discussion sorting; and
#* the ability to make posts sticky;
# the forum code does not match the current coding guidelines.

== Task list ==

=== Compartmentalise existing codebase ===

Forum is one of the oldest components in Moodle and precedes many of the current guidelines and best practices that we currently follow. As a result, much of the code is in a single library file and tightly linked to it's original functionality.

To make the codebase more manageable, we propose splitting apart the existing lib.php (8614 lines), and where relevant moving functionality to appropriate locations. These will include:
* moving the display models to a new set of renderable objects;
* moving the display views to a new set of renderers;
* creation of a new sub-plugin type for different kinds of forum; and
* moving shared code into relevant classes.

By doing so we will better help the community:
* to create new types of forum (discussed below) thereby enhancing the pedagogical aspects of the Forum module;
* by allowing theme designers to override individual renderers to change styling as desired; and
* improving code manageability which should reduce time required to both fix issues, and add new features.

=== Update forum layout ===

The initial proposal is to model the new forum layout on the mod_hsuforum (contributed by Moodle Rooms).

==== Goals ====
As standard, the new forum layout should:
* provide an accessible interface;
* make clear use of CSS classes and selectors;
* have a simplified DOM layout; and
* make use of JavaScript and AJAX to improve the experience for users.

==== Status ====
The mod_hsuforum code contributed by Moodle Rooms:
* is relatively up-to-date with the core forum code;
* makes use of renderers; and
* has all JavaScript written in Shifted YUI modules and very close to our new coding guidelines.

However:
* the new interface is implemented as an alternate view and hard-coded in a similar way to existing views;
* renderers contain a lot of logic, DB queries, and capability checks which would need removing.

The JavaScript seems largely good, though there are some up-front DOM changes which could instead be moved to the renderer to avoid costly DOM changes on each page load.

=== Create a new forum type sub-plugin ===
At present we have several types of forum type:
* News forum (news)
* Single simple discussion (single);
* Each person posts one discussion (eachuser);
* Question and Answer (qanda);
* Standard forum displayed in a blog-like format (blog); and
* Standard forum for general use (general).

However, there have been frequent requests for more types of forum for specific use-cases, pedagogical approaches, and other requirements (MDL-42981, MDL-20903, MDL-40385, MDL-3277, etc).
At present all of the current forum types are hard-coded in lib.php and locallib.php so it is not possible for contrib developers to submit new forum types.
It is also very difficult to add new forum types to core, and it is hard to maintain existing code. Cron logic is also heavily influenced by the existing types which makes debugging difficult.

As a resolution to these issues, we propose the creation of a new sub-plugin for forums for forum types.

=== Implement new subscription methods ===
At present it is only possible to subscribe to an entire forum, or opt out of an entire forum. Per-discussion subscription is not possible and is one of the most requested feature in Moodle.

=== Documentation ===
Documentation will need to be written for the new renderers and renderables, as they are added to the element library.

Additionally, user documentation with be required for any changes to the interface (in-line reply, subscription management) etc.

Forum update

2014-05-19T03:05:27Z

Phalacee: /* Details */

{{Work in progress}}
{{Infobox Project
|name = Moodle Forum Revamp
|state = In Development
|tracker =
|discussion =
|assignee = Jason Fowler & Andrew Nichols @ Moodle HQ
}}

== Project goals ==

* Improve accessibility of the Moodle Forums
* Make the forums more modern in appearance
* Make the code in the forums module more manageable
* Implement renderers and renderables

== Considerations ==

* Backwards compatibility
* Creating sub-plugins for "Forum Types" (Q&A etc) and "Forum Formats"
* Subscription management
* Editor Lite - a cut down version of Atto for "Reply inline"

== Details ==

At present the moodle forums are the oldest part of the code base, and lag behind the rest of moodle in a big way.

We hope to implement a new interface for the forums, based on the accessible view from MoodleRooms' HSU Forum, and add some new functionality over time.

Forum update

2014-05-19T03:05:08Z

Phalacee:

{{Work in progress}}
{{Infobox Project
|name = Moodle Forum Revamp
|state = In Development
|tracker =
|discussion =
|assignee = Jason Fowler & Andrew Nichols @ Moodle HQ
}}

== Project goals ==

* Improve accessibility of the Moodle Forums
* Make the forums more modern in appearance
* Make the code in the forums module more manageable
* Implement renderers and renderables

== Considerations ==

* Backwards compatibility
* Creating sub-plugins for "Forum Types" (Q&A etc) and "Forum Formats"
* Subscription management
* Editor Lite - a cut down version of Atto for "Reply inline"

== Details ==

At present the moodle forums are the oldest part of the code base, and lag behind the rest of moodle in a big way.
We hope to implement a new interface for the forums, based on the accessible view from MoodleRooms' HSU Forum, and add some new functionality over time.

Editor 2.7

2014-05-19T02:46:55Z

Phalacee:

{{Infobox Project
|name = Text Editor Revamp
|state = In Production
|tracker =
|discussion = https://moodle.org/mod/forum/discuss.php?d=243197
|assignee = Jason & Damyon @ Moodle HQ
}}
{{Moodle 2.7}}

== Project goals ==

The purpose of this document is to plan how to update the default text editor in Moodle.

The aim of this change is to improve accessibility and usability, while replacing TinyMCE 3.5, which is now unsupported.

TinyMCE 3.5 will be kept in place for the next few releases, but will be disabled by default.

Along with the replacement of the Editor, plugins for TinyMCE 3.5.8, that are included as part of the Moodle release, will need to be made compatible with the new editor.

== Considerations ==

* Usability of the editor - is it easy to create content with?
* Accessibility of the editor - is it at or easy to get it to follow the WCAG AA standard?
* Accessibility of the code produced by the editor - will it produce content that is up to the WCAG AA standard?
* Maintainability of the links between the editor and Moodle - how much work will we need to do every time we upgrade?
* Appearance of the editor - can its interface be modified to look like the other toolbars currently in Moodle?
* Do the dialogues look the same and have the same accessibility features we expect from Moodle dialogues? Do the dialogues scale/re-flow on small screens?
* Strong feature set - does it support the things our users have come to expect already?
* String support - how difficult will it be to allow strings to change when the Moodle language changes?
* Mobile support - how well does it scale on small screens and touchscreens?
* Plugin support - can our community write plugins easily?
* Browser support - does it support all the browsers Moodle does?
* Loading speed - how quick is it to load the editor ready for use?
* Upstream support - will it be supported for the lifetime we want (3 years+?)
* RTL support - does it include RTL support for the content, user interface and included dialogues?
* Given we need to redo the dragmath support - is dragmath the best choice for an equation editor?
** Cons of dragmath
*** Java applet
*** Requires tex filter to be enabled globally
*** Complaints about tex filter
*** Open GPL issue: MDL-32450
** Alternative
*** MathJax filter + equation editor plugin

== Out there suggestions ==
* Add a picture editor to Moodle. (Paintweb - previous GSOC project: [[Paint_tool_integration]] )
* Add a "html_tiny" text format with a super cut down editor that supports it (e.g. - no toolbar at all - but still html with bold, italics, cut/paste etc)
* [http://wordpress.org/plugins/plugnedit/ Drag and drop handling of media]

== Candidates ==

* CKEditor4
* Atto
* TinyMCE 4
* ??? Are there other alternatives?

{| class="nicetable"
|-
! ..
! CKEditor 4
! Atto
! TinyMCE 4
! TinyMCE 3.5
|-
| '''Usable Editor'''
|
* Still minor room for improvement
|
* Visual feedback for the state of the text under the cursor/caret needs improvement
|
* Still minor room for improvement
|
* Still minor room for improvement
|-
| '''Accessible Editor'''
|
* Still minor room for improvement
|
* Still minor room for improvement
|
* Lots of warnings on the Chrome Accessibility Audit
|
* Still room for improvement
|-
| '''Accessible Content'''
|
* Fairly good
|
* Fairly good
|
* Fairly good
* Decorative images need empty alt tag
|
* Still room for improvement
* Decorative images need empty alt tag
|-
|''' Maintainable with Moodle'''
|
* '''Unknown'''
|
* Needs documentation and acceptance tests
|
* '''Unknown'''
|
* Scripts already in place to help with this
|-
| '''Editor Appearance'''
|
* Can be themed to look like existing toolbars
* Dialogues are easy to change
* Icons need work
|
* Already looks like existing toolbars
|
* Can be themed to look like existing toolbars
* Dialogues are easy to change
* Icons need work
|
* The DOM is really nasty
* Uses tables for layout
|-
| '''Feature set'''
|
* Almost 100% matching what we have already
|
* Still many features left to implement
|
* Almost 100% matching what we have already
|
* 100% of what we have
|-
| '''String Support'''
|
* May need some work to get it working
|
* Built with string support in mind
|
* Will need some work to get it working
|
* Scripts already in place to help with this
|-
| '''Mobile Support'''
|
* Editor works well, the the dialogues don't
|
* Editor works well, as do the dialogues it launches
|
* Editor works well, the the dialogues don't
|
* Very poor
|-
| '''Plugin Support'''
|
* Plugins are easy to write
* Plenty of 3rd party plugins already out there
|
* Plugins support YUI
* Plugins are easy to write
* Moodle is the only source of plugins
|
* Plugins are easy to write
* Plenty of 3rd party plugins already out there
|
* Plugins are easy to write
* Plenty of 3rd party plugins already out there
|-
| '''Loading Speed''' (Lets wait until all editors have comparible levels of Moodle integration before comparing speed please.)
|
* -
|
* -
|
* -
|
* -
|-
| '''Equation Editor'''
|
* Has mathjax plugin - uses different maths delimiters so needs hacking to make it backwards compatible with our existing equations.
|
* Has mathjax plugin - requires newly written mathjax filter but is 100% compatible with existing equations
|
* Has dragmath plugin. Java based - ugly, not-accessible.
|
* Has dragmath plugin. Java based - ugly, not-accessible.
|}
(Sorry - editing the above table hurts my brain - just noting that it is not up to date)

=== CKEditor 4 ===

'''Pros:'''
* Huge community of developers
* Plenty of plugins (177 - http://ckeditor.com/addons/plugins/all)
* Good existing documentation
* Sample plugin: http://docs.ckeditor.com/#!/guide/plugin_sdk_sample_1
* Inline HTML Source editor - no need to open a dialogue to edit the source
* Ability to replace file browser with Moodle's filepicker
* [http://docs.ckeditor.com/#!/api/CKEDITOR.config-cfg-baseFloatZIndex baseFloatZIndex] - allows the zIndex to be set in a more strict manner
* Release cycle seems to be based on minor releases every 5 weeks with major releases every 2-3 minor releases. This seems to imply that the changes between releases will be relatively minor (good), but - the downside is releases will only be supported for 5 weeks and all bug fixes will be mixed with new features after that (bad). https://groups.google.com/forum/#!topic/ckeditor-dev/09BBYK9-OTE
* Accessibility support - http://ckeditor.com/blog/CKEditor-WAI-ARIA-Usable-Accessibility http://ckeditor.com/addons/accessibility

'''Cons:'''
* Unfamiliar to Moodle developers
* Currently disabled on Android

'''Technical notes (lessons learned from the prototypes)'''
* Code seems high quality, as is the documentation.
* Language strings can be mapped directly to AMOS
* Ships with a nice mathjax solution
* Has own collapse feature (which we disabled in favour of ours)
* Does initially include alot of separate JS and CSS files (which get browser cached by our loader)
* Good accessibility support
* Theme system is fairly easy to work with
* Has a lot of features without feeling super heavyweight
* Dialogues on mobile do not go "fullscreen" (so don't fit)
* Current prototype has 0 modifications to the upstream code.

'''Outstanding work from the prototype'''
* Moodle language loading not implemented for plugins yet (but there is nothing stopping it)
* Needs a hack to the code to prevent the window flash when accessing a repository
* Important missing plugins - Insert media, Manage files
* Update behat tests, may require changes to behat framework to wait for editor loading

'''Missing features'''
* Media Manager
* Emoticons
* Non-breaking space ??
* Cleanup Messy code
* Prevent automatic linking

=== Atto ===

'''Pros:'''
* Excellent accessibility
* Excellent integration for Moodle strings
* Inline HTML Source editor - no need to open a dialogue to edit the source

'''Cons:'''
* Maintenance will rely on Moodle developers
* We need to document it ourselves
* No external community to lean on

'''Technical notes (lessons learned from the prototypes)'''

* Code is high quality, it is quick to build new plugins - https://github.com/damyon/moodle-editor_atto/tree/master/plugins/bold
* No mapping required for Language strings
* Ships with a nice mathjax solution
* Uses YUI in plugins - so easy for Moodle developers to learn
* Good accessibility support (but could do with some improvements)
* Fully themable in a moodle theme (even icons)
* Feels fast and nimble. This also means it does less.
* Uses Moodle dialogues - so dialgoues will be 100% as accessible as the rest of the dialogues in Moodle

'''Outstanding work from the prototype'''
* Important missing plugins - Tables/Grid, Manage files
* Update behat tests, behat framework will work nicely with this editor because it uses standard yui loading.

'''Missing features'''
* <strike> Tables </strike> (This is supported now)
* Strike-through
* Subtext
* Supertext
* Fontface
* Fontsize
* Color
* Background color
* Paste as plain text
* Paste from Word
* Insert character
* Switch RTL/LTR
* Find
* Find/Replace
* Media Manager
* Emoticons
* Non-breaking space
* Cleanup Messy code
* Prevent automatic linking
* Undo/redo
* Toolbar buttons to indicate state of selected text
* Advanced image formatting options

=== TinyMCE 4 ===

'''Pros:'''
* Menus allow the toolbars to be less cluttered
* Huge community of developers
* Plenty of plugins
* Good existing documentation
* Simple hook for file-picker: http://www.tinymce.com/wiki.php/Configuration:file_browser_callback
* Uses LESS for style sheets

'''Cons:'''
* Swapping from WYSIWYG mode to Source mode launches a dialogue
* Uses Jake for LESS compilation
* Uses fonts for icons - icoMoon font service

'''Technical notes (lessons learned from the prototypes)'''

* Code is of average quality. It is hard to build new plugins, the documentation is lacking.
* Language strings are terrible and require nasty hacks to work at all and the solution is ugly.
* We have drag math for equations but it sucks
* There is alot of accessibility features built in - but there are numerous violations of the spec and everything does not work nicely with the keyboard.
* Skinning is hard and ugly.
* Loads slowly
* Requires yet another tool for building skins (jake)
* Despite being the most similar to tinymce3, this editor took the most work and the most hacks to get to the same level of integration.

'''Outstanding work from the prototype'''
* Split onblur hack from collapse plugin into it's own plugin.
* Improvements to the nasty lang string hack
* Implement missing plugins (manage files)
* Update behat tests, behat framework requires hacks for this editor because it loads things slowly and randomly.

[edit]

== Sub Tasks ==

# Assess different editors
# Prototype alternatives
# Ask some users
# Decide on an editor
# Implement editor
## Getting the new editor to render without altering the existing DOM - prevents changes needed to maintain third party plugins.
## Getting AMOS strings working within Editor.
## Getting Filepicker working within Editor Dialogues.
## Add file management plugin (Marinas or other)
# Disable TinyMCE

== Mobile Examples/Alternatives ==
* Evernote - has a minimal toolbar that collapses to a single toggle button with nothing else displayed
* Google Docs - has a simple toolbar that scrolls with a swipe
* Gmail - Single icon that launches a simple menu-like toolbar

== Mock-Ups/Prototypes ==
http://prototype.moodle.net/editor

== Related Tracker Issues ==

[[Category:Project]]

Forum update

2014-05-19T02:46:40Z

Phalacee: Created page with "{{Work in progress}} {{Infobox Project |name = Moodle Forum Revamp |state = In Development |tracker = |discussion = |assignee = Jason Fowler & Andrew Nichols @ Moodle HQ }} ..."

{{Work in progress}}
{{Infobox Project
|name = Moodle Forum Revamp
|state = In Development
|tracker =
|discussion =
|assignee = Jason Fowler & Andrew Nichols @ Moodle HQ
}}
{{Moodle 2.8}}

PHPUnit

2014-03-12T07:21:02Z

Phalacee: /* Installation of PHPUnit via Composer */

{{Moodle 2.3}}

=What is PHPUnit=
PHPUnit by Sebastian Bergmann is an advanced unit testing framework for PHP. It is installed as Composer dependency and is not part of Moodle installation. To run PHPUnit tests, you have to manually install it on your development computer or test server.

Read the excellent guide at
* [http://phpunit.de/manual/current/en/index.html PHPUnit Manual]

=Installation of PHPUnit via Composer=

If you have Two Factor Authentication enabled on your github account, you will need to add a auth token to your ~/.composer/config.json as shown here: https://gist.github.com/andrewnicols/c5377ed25a9df1006ce1

The installation procedure depends on your operating system.
* Check that /your/moodle/dirroot/composer.json exists and the contents are similar to
{
"require-dev": {
"phpunit/phpunit": "3.7.*",
"phpunit/dbUnit": "1.2.*"
}
}
* Install Composer dependency manager

cd /your/moodle/dirroot
curl -s https://getcomposer.org/installer | php

On Windows go to https://getcomposer.org/download/ and download the Composer-Setup.exe file

* Execute Composer installer

cd /your/moodle/dirroot
php composer.phar install --dev

(If that gives you connection problems try...)

php composer.phar install --dev --prefer-source

On Windows if you are behind a proxy you will need to setup an environment variable called HTTP_PROXY with a value detailing your HTTP Proxy address and port before composer will correctly download files.

Detailed instructions:
* [http://getcomposer.org/doc/00-intro.md Composer documentation]

Detailed instructions:
* [[PHPUnit installation in Windows]]
* [[PHPUnit installation in OS X]]

=Initialisation of test environment=

Our PHPUnit integration requires a dedicated database and dataroot. First, add a new dataroot directory and prefix into your config.php, you can find examples in config-dist.php (scroll down to 'Section 9').

$CFG->phpunit_prefix = 'phpu_';
$CFG->phpunit_dataroot = '/home/example/phpu_moodledata';

If your system does not have a direct connection to the Internet, you also need to specify your proxy in config.php - even though you normally specify it by using the admin settings user interface. (If you do not use a proxy, you can skip this step.) Check the settings on the relevant admin settings page, or from the mdl_config table in your database, if you are unsure of the correct values.

// Normal proxy settings
$CFG->proxyhost = 'wwwcache.example.org';
$CFG->proxyport = 80;
$CFG->proxytype = 'HTTP';
$CFG->proxybypass = 'localhost, 127.0.0.1, .example.org';
// Omit the next lines if your proxy doesn't need a username/password:
$CFG->proxyuser = 'systemusername';
$CFG->proxypassword = 'systempassword';

Then you need to initialise the test environment using following command.

cd /home/example/moodle
php admin/tool/phpunit/cli/init.php

This command has to be repeated after any upgrade, plugin (un)installation or if you have added tests to a plugin you are developing:

'''NOTE:''' make sure that your php cli executable (or the one you want to use) is correctly on your path as the individual init scripts will call it repeatedly.

=Test execution=

To execute all test suites from main configuration file execute the <code>vendor/bin/phpunit</code> script from your <code>$CFG->dirroot</code> directory.

cd /home/example/moodle
vendor/bin/phpunit

The rest of examples uses <code>phpunit</code>, please substitute it with <code>vendor/bin/phpunit</code> or create a shortcut in your dirroot.

In IDEs, you may need to specify the path to the PHPUnit configuration file. Use the absolute path to <code>phpunit.xml</code> from your <code>$CFG->dirroot</code>.

There is an alternative script for running of tests via web interface: <code>admin/tool/phpunit/webrunner.php</code>. Use this as the last resort only when you cannot use the command-line interface on your test server. It will most probably break due to permissions problems if you try to execute it both from command-line and from webrunner. This feature is not officially supported.

===How to run only some tests===

==== Running a single test quickly ====

The fastest way to run a single test is:

vendor/bin/phpunit my_test_class_name my/tests/filename.php

This is faster than other methods because it avoids the need to search for the test file, but you should be careful because it may be possible to run tests this way which are not included in the normal run. If you use this method, do at least one full test run (or --group run, as below) to ensure the test can be found.

==== Using the @group annotation ====

If you add annotations like

<code php>
/**
* Unit tests for {@link stack_cas_keyval}.
* @group qtype_stack
*/
class stack_cas_keyval_exception_test extends basic_testcase {
</code>

to all the classes in your plugin, the you can run just the tests for your plugin by doing

phpunit --group qtype_stack

Therefore, it is suggested that you annotate all your tests with the Frankenstyle name of your plugin.

==== Using multiple phpunit.xml files ====

It's easy to create alternative phpunit.xml files defining which tests must be run together. For reference, take a look to the default /phpunit.xml available in your base directory once the testing environment has been initialised. After creating the custom file you will be able to run those tests with

vendor/bin/phpunit -c path/to/your/alternative/phpunit/file.xml

Also, for commodity, you can use this command:

php admin/tool/phpunit/cli/util.php --buildcomponentconfigs

It will, automatically, create one valid phpunit.xml file within each component (plugin or subsystem) and other important directories, so later you will be able to execute tests like

vendor/bin/phpunit -c mod/forum[/phpunit.xml] // Note that it's not needed to specify the name of the file (if it is 'phpunit.xml').
vendor/bin/phpunit -c question
vendor/bin/phpunit -c question/type/calculated
vendor/bin/phpunit -c backup
vendor/bin/phpunit -c lib/dml
...

or, also

cd directory/with/phpunit.xml
phpunit

=External test resources=
{{Moodle 2.6}}
By default Moodle phpunit tests contact http://download.moodle.org server when testing curl related functionality. Optionally you may checkout a local copy of the test scripts and access it instead:

# clone https://github.com/moodlehq/moodle-exttests to web directory
# add to your config.php or modify phpunit.xml file <code php>define('TEST_EXTERNAL_FILES_HTTP_URL', 'http://localhost/moodle-exttests');</code>

=Writing new tests=
* read [http://www.phpunit.de/manual/current/en/ official PHPUnit online documentation]
* see [[Writing PHPUnit tests]]

=Conversion of existing SimpleTests=
* see [[SimpleTest conversion]]

=PHPUnit support in IDEs=

* [http://www.phpsrc.org/projects/pti-phpunit/wiki/ Eclipse PHP Tool Integration]
* [http://blog.jetbrains.com/webide/2009/12/phpunit-support/ PHPStorm IDE]
* [http://netbeans.org/kb/docs/php/phpunit.html Netbeans]

=Common Unit Test Problems=
[[Common unit test problems]]

[[Category:Unit testing]]

Editor 2.7

2014-01-22T06:38:07Z

Phalacee:

{{Work in progress}}
{{Infobox Project
|name = Text Editor Revamp
|state = In Development
|tracker =
|discussion = https://moodle.org/mod/forum/discuss.php?d=243197
|assignee = Jason & Damyon @ Moodle HQ
}}
{{Moodle 2.7}}

== Project goals ==

The purpose of this document is to plan how to update the default text editor in Moodle.

The aim of this change is to improve accessibility and usability, while replacing TinyMCE 3.5, which is now unsupported.

TinyMCE 3.5 will be kept in place for the next few releases, but will be disabled by default.

Along with the replacement of the Editor, plugins for TinyMCE 3.5.8, that are included as part of the Moodle release, will need to be made compatible with the new editor.

== Considerations ==

* Usability of the editor - is it easy to create content with?
* Accessibility of the editor - is it at or easy to get it to follow the WCAG AA standard?
* Accessibility of the code produced by the editor - will it produce content that is up to the WCAG AA standard?
* Maintainability of the links between the editor and Moodle - how much work will we need to do every time we upgrade?
* Appearance of the editor - can its interface be modified to look like the other toolbars currently in Moodle?
* Do the dialogues look the same and have the same accessibility features we expect from Moodle dialogues? Do the dialogues scale/re-flow on small screens?
* Strong feature set - does it support the things our users have come to expect already?
* String support - how difficult will it be to allow strings to change when the Moodle language changes?
* Mobile support - how well does it scale on small screens and touchscreens?
* Plugin support - can our community write plugins easily?
* Browser support - does it support all the browsers Moodle does?
* Loading speed - how quick is it to load the editor ready for use?
* Upstream support - will it be supported for the lifetime we want (3 years+?)
* RTL support - does it include RTL support for the content, user interface and included dialogues?
* Given we need to redo the dragmath support - is dragmath the best choice for an equation editor?
** Cons of dragmath
*** Java applet
*** Requires tex filter to be enabled globally
*** Complaints about tex filter
*** Open GPL issue: MDL-32450
** Alternative
*** MathJax filter + equation editor plugin

== Out there suggestions ==
* Add a picture editor to Moodle. (Paintweb - previous GSOC project: [[Paint_tool_integration]] )
* Add a "html_tiny" text format with a super cut down editor that supports it (e.g. - no toolbar at all - but still html with bold, italics, cut/paste etc)
* [http://wordpress.org/plugins/plugnedit/ Drag and drop handling of media]

== Candidates ==

* CKEditor4
* Atto
* TinyMCE 4
* ??? Are there other alternatives?

{| class="nicetable"
|-
! ..
! CKEditor 4
! Atto
! TinyMCE 4
! TinyMCE 3.5
|-
| '''Usable Editor'''
|
* Still minor room for improvement
|
* Visual feedback for the state of the text under the cursor/caret needs improvement
|
* Still minor room for improvement
|
* Still minor room for improvement
|-
| '''Accessible Editor'''
|
* Still minor room for improvement
|
* Still minor room for improvement
|
* Lots of warnings on the Chrome Accessibility Audit
|
* Still room for improvement
|-
| '''Accessible Content'''
|
* Fairly good
|
* Fairly good
|
* Fairly good
* Decorative images need empty alt tag
|
* Still room for improvement
* Decorative images need empty alt tag
|-
|''' Maintainable with Moodle'''
|
* '''Unknown'''
|
* Needs documentation and acceptance tests
|
* '''Unknown'''
|
* Scripts already in place to help with this
|-
| '''Editor Appearance'''
|
* Can be themed to look like existing toolbars
* Dialogues are easy to change
* Icons need work
|
* Already looks like existing toolbars
|
* Can be themed to look like existing toolbars
* Dialogues are easy to change
* Icons need work
|
* The DOM is really nasty
* Uses tables for layout
|-
| '''Feature set'''
|
* Almost 100% matching what we have already
|
* Still many features left to implement
|
* Almost 100% matching what we have already
|
* 100% of what we have
|-
| '''String Support'''
|
* May need some work to get it working
|
* Built with string support in mind
|
* Will need some work to get it working
|
* Scripts already in place to help with this
|-
| '''Mobile Support'''
|
* Editor works well, the the dialogues don't
|
* Editor works well, as do the dialogues it launches
|
* Editor works well, the the dialogues don't
|
* Very poor
|-
| '''Plugin Support'''
|
* Plugins are easy to write
* Plenty of 3rd party plugins already out there
|
* Plugins support YUI
* Plugins are easy to write
* Moodle is the only source of plugins
|
* Plugins are easy to write
* Plenty of 3rd party plugins already out there
|
* Plugins are easy to write
* Plenty of 3rd party plugins already out there
|-
| '''Loading Speed''' (Lets wait until all editors have comparible levels of Moodle integration before comparing speed please.)
|
* -
|
* -
|
* -
|
* -
|-
| '''Equation Editor'''
|
* Has mathjax plugin - uses different maths delimiters so needs hacking to make it backwards compatible with our existing equations.
|
* Has mathjax plugin - requires newly written mathjax filter but is 100% compatible with existing equations
|
* Has dragmath plugin. Java based - ugly, not-accessible.
|
* Has dragmath plugin. Java based - ugly, not-accessible.
|}
(Sorry - editing the above table hurts my brain - just noting that it is not up to date)

=== CKEditor 4 ===

'''Pros:'''
* Huge community of developers
* Plenty of plugins (177 - http://ckeditor.com/addons/plugins/all)
* Good existing documentation
* Sample plugin: http://docs.ckeditor.com/#!/guide/plugin_sdk_sample_1
* Inline HTML Source editor - no need to open a dialogue to edit the source
* Ability to replace file browser with Moodle's filepicker
* [http://docs.ckeditor.com/#!/api/CKEDITOR.config-cfg-baseFloatZIndex baseFloatZIndex] - allows the zIndex to be set in a more strict manner
* Release cycle seems to be based on minor releases every 5 weeks with major releases every 2-3 minor releases. This seems to imply that the changes between releases will be relatively minor (good), but - the downside is releases will only be supported for 5 weeks and all bug fixes will be mixed with new features after that (bad). https://groups.google.com/forum/#!topic/ckeditor-dev/09BBYK9-OTE
* Accessibility support - http://ckeditor.com/blog/CKEditor-WAI-ARIA-Usable-Accessibility http://ckeditor.com/addons/accessibility

'''Cons:'''
* Unfamiliar to Moodle developers
* Currently disabled on Android

'''Technical notes (lessons learned from the prototypes)'''
* Code seems high quality, as is the documentation.
* Language strings can be mapped directly to AMOS
* Ships with a nice mathjax solution
* Has own collapse feature (which we disabled in favour of ours)
* Does initially include alot of separate JS and CSS files (which get browser cached by our loader)
* Good accessibility support
* Theme system is fairly easy to work with
* Has a lot of features without feeling super heavyweight
* Dialogues on mobile do not go "fullscreen" (so don't fit)
* Current prototype has 0 modifications to the upstream code.

'''Outstanding work from the prototype'''
* Moodle language loading not implemented for plugins yet (but there is nothing stopping it)
* Needs a hack to the code to prevent the window flash when accessing a repository
* Important missing plugins - Insert media, Manage files
* Update behat tests, may require changes to behat framework to wait for editor loading

'''Missing features'''
* Media Manager
* Emoticons
* Non-breaking space ??
* Cleanup Messy code
* Prevent automatic linking

=== Atto ===

'''Pros:'''
* Excellent accessibility
* Excellent integration for Moodle strings
* Inline HTML Source editor - no need to open a dialogue to edit the source

'''Cons:'''
* Maintenance will rely on Moodle developers
* We need to document it ourselves
* No external community to lean on

'''Technical notes (lessons learned from the prototypes)'''

* Code is high quality, it is quick to build new plugins - https://github.com/damyon/moodle-editor_atto/tree/master/plugins/bold
* No mapping required for Language strings
* Ships with a nice mathjax solution
* Uses YUI in plugins - so easy for Moodle developers to learn
* Good accessibility support (but could do with some improvements)
* Fully themable in a moodle theme (even icons)
* Feels fast and nimble. This also means it does less.
* Uses Moodle dialogues - so dialgoues will be 100% as accessible as the rest of the dialogues in Moodle

'''Outstanding work from the prototype'''
* Important missing plugins - Tables/Grid, Manage files
* Update behat tests, behat framework will work nicely with this editor because it uses standard yui loading.

'''Missing features'''
* <strike> Tables </strike> (This is supported now)
* Strike-through
* Subtext
* Supertext
* Fontface
* Fontsize
* Color
* Background color
* Paste as plain text
* Paste from Word
* Insert character
* Switch RTL/LTR
* Find
* Find/Replace
* Media Manager
* Emoticons
* Non-breaking space
* Cleanup Messy code
* Prevent automatic linking
* Undo/redo
* Toolbar buttons to indicate state of selected text
* Advanced image formatting options

=== TinyMCE 4 ===

'''Pros:'''
* Menus allow the toolbars to be less cluttered
* Huge community of developers
* Plenty of plugins
* Good existing documentation
* Simple hook for file-picker: http://www.tinymce.com/wiki.php/Configuration:file_browser_callback
* Uses LESS for style sheets

'''Cons:'''
* Swapping from WYSIWYG mode to Source mode launches a dialogue
* Uses Jake for LESS compilation
* Uses fonts for icons - icoMoon font service

'''Technical notes (lessons learned from the prototypes)'''

* Code is of average quality. It is hard to build new plugins, the documentation is lacking.
* Language strings are terrible and require nasty hacks to work at all and the solution is ugly.
* We have drag math for equations but it sucks
* There is alot of accessibility features built in - but there are numerous violations of the spec and everything does not work nicely with the keyboard.
* Skinning is hard and ugly.
* Loads slowly
* Requires yet another tool for building skins (jake)
* Despite being the most similar to tinymce3, this editor took the most work and the most hacks to get to the same level of integration.

'''Outstanding work from the prototype'''
* Split onblur hack from collapse plugin into it's own plugin.
* Improvements to the nasty lang string hack
* Implement missing plugins (manage files)
* Update behat tests, behat framework requires hacks for this editor because it loads things slowly and randomly.

[edit]

== Sub Tasks ==

# Assess different editors
# Prototype alternatives
# Ask some users
# Decide on an editor
# Implement editor
## Getting the new editor to render without altering the existing DOM - prevents changes needed to maintain third party plugins.
## Getting AMOS strings working within Editor.
## Getting Filepicker working within Editor Dialogues.
## Add file management plugin (Marinas or other)
# Disable TinyMCE

== Mobile Examples/Alternatives ==
* Evernote - has a minimal toolbar that collapses to a single toggle button with nothing else displayed
* Google Docs - has a simple toolbar that scrolls with a swipe
* Gmail - Single icon that launches a simple menu-like toolbar

== Mock-Ups/Prototypes ==
http://prototype.moodle.net/editor

== Related Tracker Issues ==

[[Category:Project]]

Editor 2.7

2014-01-07T01:17:03Z

Phalacee: /* Atto */

{{Work in progress}}
{{Infobox Project
|name = Text Editor Revamp
|state = In Development
|tracker =
|discussion = https://moodle.org/mod/forum/discuss.php?d=243197
|assignee = Jason & Damyon @ Moodle HQ
}}
{{Moodle 2.7}}

== Project goals ==

The purpose of this document is to plan how to update the default text editor in Moodle.

The aim of this change is to improve accessibility and usability, while replacing TinyMCE 3.5, which is now unsupported.

TinyMCE 3.5 will be kept in place for the next few releases, but will be disabled by default.

Along with the replacement of the Editor, plugins for TinyMCE 3.5.8, that are included as part of the Moodle release, will need to be made compatible with the new editor.

== Considerations ==

* Usability of the editor - is it easy to create content with?
* Accessibility of the editor - is it at or easy to get it to follow the WCAG AA standard?
* Accessibility of the code produced by the editor - will it produce content that is up to the WCAG AA standard?
* Maintainability of the links between the editor and Moodle - how much work will we need to do every time we upgrade?
* Appearance of the editor - can its interface be modified to look like the other toolbars currently in Moodle?
* Do the dialogues look the same and have the same accessibility features we expect from Moodle dialogues? Do the dialogues scale/re-flow on small screens?
* Strong feature set - does it support the things our users have come to expect already?
* String support - how difficult will it be to allow strings to change when the Moodle language changes?
* Mobile support - how well does it scale on small screens and touchscreens?
* Plugin support - can our community write plugins easily?
* Browser support - does it support all the browsers Moodle does?
* Loading speed - how quick is it to load the editor ready for use?
* Upstream support - will it be supported for the lifetime we want (3 years+?)
* RTL support - does it include RTL support for the content, user interface and included dialogues?
* Given we need to redo the dragmath support - is dragmath the best choice for an equation editor?
** Cons of dragmath
*** Java applet
*** Requires tex filter to be enabled globally
*** Complaints about tex filter
*** Open GPL issue: MDL-32450
** Alternative
*** MathJax filter + equation editor plugin

== Out there suggestions ==
* Add a picture editor to Moodle. (Paintweb - previous GSOC project: [[Paint_tool_integration]] )
* Add a "html_tiny" text format with a super cut down editor that supports it (e.g. - no toolbar at all - but still html with bold, italics, cut/paste etc)
* [http://wordpress.org/plugins/plugnedit/ Drag and drop handling of media]

== Candidates ==

* CKEditor4
* Atto
* TinyMCE 4
* ??? Are there other alternatives?

{| class="nicetable"
|-
! ..
! CKEditor 4
! Atto
! TinyMCE 4
! TinyMCE 3.5
|-
| '''Usable Editor'''
|
* Still minor room for improvement
|
* Visual feedback for the state of the text under the cursor/caret needs improvement
|
* Still minor room for improvement
|
* Still minor room for improvement
|-
| '''Accessible Editor'''
|
* Still minor room for improvement
|
* Still minor room for improvement
|
* Lots of warnings on the Chrome Accessibility Audit
|
* Still room for improvement
|-
| '''Accessible Content'''
|
* Fairly good
|
* Fairly good
|
* Fairly good
* Decorative images need empty alt tag
|
* Still room for improvement
* Decorative images need empty alt tag
|-
|''' Maintainable with Moodle'''
|
* '''Unknown'''
|
* Needs documentation and acceptance tests
|
* '''Unknown'''
|
* Scripts already in place to help with this
|-
| '''Editor Appearance'''
|
* Can be themed to look like existing toolbars
* Dialogues are easy to change
* Icons need work
|
* Already looks like existing toolbars
|
* Can be themed to look like existing toolbars
* Dialogues are easy to change
* Icons need work
|
* The DOM is really nasty
* Uses tables for layout
|-
| '''Feature set'''
|
* Almost 100% matching what we have already
|
* Still many features left to implement
|
* Almost 100% matching what we have already
|
* 100% of what we have
|-
| '''String Support'''
|
* May need some work to get it working
|
* Built with string support in mind
|
* Will need some work to get it working
|
* Scripts already in place to help with this
|-
| '''Mobile Support'''
|
* Editor works well, the the dialogues don't
|
* Editor works well, as do the dialogues it launches
|
* Editor works well, the the dialogues don't
|
* Very poor
|-
| '''Plugin Support'''
|
* Plugins are easy to write
* Plenty of 3rd party plugins already out there
|
* Plugins support YUI
* Plugins are easy to write
* Moodle is the only source of plugins
|
* Plugins are easy to write
* Plenty of 3rd party plugins already out there
|
* Plugins are easy to write
* Plenty of 3rd party plugins already out there
|-
| '''Loading Speed''' (Lets wait until all editors have comparible levels of Moodle integration before comparing speed please.)
|
* -
|
* -
|
* -
|
* -
|-
| '''Equation Editor'''
|
* Has mathjax plugin - uses different maths delimiters so needs hacking to make it backwards compatible with our existing equations.
|
* Has mathjax plugin - requires newly written mathjax filter but is 100% compatible with existing equations
|
* Has dragmath plugin. Java based - ugly, not-accessible.
|
* Has dragmath plugin. Java based - ugly, not-accessible.
|}
(Sorry - editing the above table hurts my brain - just noting that it is not up to date)

=== CKEditor 4 ===

'''Pros:'''
* Huge community of developers
* Plenty of plugins
* Good existing documentation
* Inline HTML Source editor - no need to open a dialogue to edit the source
* Ability to replace file browser with Moodle's filepicker
* [http://docs.ckeditor.com/#!/api/CKEDITOR.config-cfg-baseFloatZIndex baseFloatZIndex] - allows the zIndex to be set in a more strict manner

'''Cons:'''
* Unfamiliar to Moodle developers

'''Technical notes (lessons learned from the prototypes)'''
* Code seems high quality, as is the documentation.
* Language strings can be mapped directly to AMOS
* Ships with a nice mathjax solution
* Has own collapse feature (which we disabled in favour of ours)
* Does initially include alot of separate JS and CSS files (which get browser cached by our loader)
* Good accessibility support
* Theme system is fairly easy to work with
* Has a lot of features without feeling super heavyweight
* Dialogues on mobile do not go "fullscreen" (so don't fit)
* Current prototype has 0 modifications to the upstream code.

'''Outstanding work from the prototype'''
* Moodle language loading not implemented for plugins yet (but there is nothing stopping it)
* Needs a hack to the code to prevent the window flash when accessing a repository
* Important missing plugins - Insert media, Manage files
* Update behat tests, may require changes to behat framework to wait for editor loading

'''Missing features'''
* Media Manager
* Emoticons
* Non-breaking space ??
* Cleanup Messy code
* Prevent automatic linking

=== Atto ===

'''Pros:'''
* Excellent accessibility
* Excellent integration for Moodle strings
* Inline HTML Source editor - no need to open a dialogue to edit the source

'''Cons:'''
* Maintenance will rely on Moodle developers
* We need to document it ourselves
* No external community to lean on

'''Technical notes (lessons learned from the prototypes)'''

* Code is high quality, it is quick to build new plugins
* No mapping required for Language strings
* Ships with a nice mathjax solution
* Uses YUI in plugins - so easy for Moodle developers to learn
* Good accessibility support (but could do with some improvements)
* Fully themable in a moodle theme (even icons)
* Feels fast and nimble. This also means it does less.
* Uses Moodle dialogues - so dialgoues will be 100% as accessible as the rest of the dialogues in Moodle

'''Outstanding work from the prototype'''
* Important missing plugins - Tables/Grid, Manage files
* Update behat tests, behat framework will work nicely with this editor because it uses standard yui loading.

'''Missing features'''
* Tables
* Strike-through
* Subtext
* Supertext
* Fontface
* Fontsize
* Color
* Background color
* Paste as plain text
* Paste from Word
* Insert character
* Switch RTL/LTR
* Find
* Find/Replace
* Media Manager
* Emoticons
* Non-breaking space
* Cleanup Messy code
* Prevent automatic linking
* Undo/redo
* Toolbar buttons to indicate state of selected text
* Advanced image formatting options

=== TinyMCE 4 ===

'''Pros:'''
* Menus allow the toolbars to be less cluttered
* Huge community of developers
* Plenty of plugins
* Good existing documentation
* Simple hook for file-picker: http://www.tinymce.com/wiki.php/Configuration:file_browser_callback
* Uses LESS for style sheets

'''Cons:'''
* Swapping from WYSIWYG mode to Source mode launches a dialogue
* Uses Jake for LESS compilation
* Uses fonts for icons - icoMoon font service

'''Technical notes (lessons learned from the prototypes)'''

* Code is of average quality. It is hard to build new plugins, the documentation is lacking.
* Language strings are terrible and require nasty hacks to work at all and the solution is ugly.
* We have drag math for equations but it sucks
* There is alot of accessibility features built in - but there are numerous violations of the spec and everything does not work nicely with the keyboard.
* Skinning is hard and ugly.
* Loads slowly
* Requires yet another tool for building skins (jake)
* Despite being the most similar to tinymce3, this editor took the most work and the most hacks to get to the same level of integration.

'''Outstanding work from the prototype'''
* Split onblur hack from collapse plugin into it's own plugin.
* Improvements to the nasty lang string hack
* Implement missing plugins (manage files)
* Update behat tests, behat framework requires hacks for this editor because it loads things slowly and randomly.

[edit]

== Sub Tasks ==

# Assess different editors
# Prototype alternatives
# Ask some users
# Decide on an editor
# Implement editor
## Getting the new editor to render without altering the existing DOM - prevents changes needed to maintain third party plugins.
## Getting AMOS strings working within Editor.
## Getting Filepicker working within Editor Dialogues.
## Add file management plugin (Marinas or other)
# Disable TinyMCE

== Mobile Examples/Alternatives ==
* Evernote - has a minimal toolbar that collapses to a single toggle button with nothing else displayed
* Google Docs - has a simple toolbar that scrolls with a swipe
* Gmail - Single icon that launches a simple menu-like toolbar

== Mock-Ups/Prototypes ==
http://prototype.moodle.net/editor

== Related Tracker Issues ==

[[Category:Project]]

Editor 2.7

2014-01-06T07:37:17Z

Phalacee: /* Atto */

{{Work in progress}}
{{Infobox Project
|name = Text Editor Revamp
|state = In Development
|tracker =
|discussion = https://moodle.org/mod/forum/discuss.php?d=243197
|assignee = Jason & Damyon @ Moodle HQ
}}
{{Moodle 2.7}}

== Project goals ==

The purpose of this document is to plan how to update the default text editor in Moodle.

The aim of this change is to improve accessibility and usability, while replacing TinyMCE 3.5, which is now unsupported.

TinyMCE 3.5 will be kept in place for the next few releases, but will be disabled by default.

Along with the replacement of the Editor, plugins for TinyMCE 3.5.8, that are included as part of the Moodle release, will need to be made compatible with the new editor.

== Considerations ==

* Usability of the editor - is it easy to create content with?
* Accessibility of the editor - is it at or easy to get it to follow the WCAG AA standard?
* Accessibility of the code produced by the editor - will it produce content that is up to the WCAG AA standard?
* Maintainability of the links between the editor and Moodle - how much work will we need to do every time we upgrade?
* Appearance of the editor - can its interface be modified to look like the other toolbars currently in Moodle?
* Do the dialogues look the same and have the same accessibility features we expect from Moodle dialogues? Do the dialogues scale/re-flow on small screens?
* Strong feature set - does it support the things our users have come to expect already?
* String support - how difficult will it be to allow strings to change when the Moodle language changes?
* Mobile support - how well does it scale on small screens and touchscreens?
* Plugin support - can our community write plugins easily?
* Browser support - does it support all the browsers Moodle does?
* Loading speed - how quick is it to load the editor ready for use?
* Upstream support - will it be supported for the lifetime we want (3 years+?)
* RTL support - does it include RTL support for the content, user interface and included dialogues?
* Given we need to redo the dragmath support - is dragmath the best choice for an equation editor?
** Cons of dragmath
*** Java applet
*** Requires tex filter to be enabled globally
*** Complaints about tex filter
*** Open GPL issue: MDL-32450
** Alternative
*** MathJax filter + equation editor plugin

== Out there suggestions ==
* Add a picture editor to Moodle. (Paintweb - previous GSOC project: [[Paint_tool_integration]] )
* Add a "html_tiny" text format with a super cut down editor that supports it (e.g. - no toolbar at all - but still html with bold, italics, cut/paste etc)
* [http://wordpress.org/plugins/plugnedit/ Drag and drop handling of media]

== Candidates ==

* CKEditor4
* Atto
* TinyMCE 4
* ??? Are there other alternatives?

{| class="nicetable"
|-
! ..
! CKEditor 4
! Atto
! TinyMCE 4
! TinyMCE 3.5
|-
| '''Usable Editor'''
|
* Still minor room for improvement
|
* Visual feedback for the state of the text under the cursor/caret needs improvement
|
* Still minor room for improvement
|
* Still minor room for improvement
|-
| '''Accessible Editor'''
|
* Still minor room for improvement
|
* Still minor room for improvement
|
* Lots of warnings on the Chrome Accessibility Audit
|
* Still room for improvement
|-
| '''Accessible Content'''
|
* Fairly good
|
* Fairly good
|
* Fairly good
* Decorative images need empty alt tag
|
* Still room for improvement
* Decorative images need empty alt tag
|-
|''' Maintainable with Moodle'''
|
* '''Unknown'''
|
* Needs documentation and acceptance tests
|
* '''Unknown'''
|
* Scripts already in place to help with this
|-
| '''Editor Appearance'''
|
* Can be themed to look like existing toolbars
* Dialogues are easy to change
* Icons need work
|
* Already looks like existing toolbars
|
* Can be themed to look like existing toolbars
* Dialogues are easy to change
* Icons need work
|
* The DOM is really nasty
* Uses tables for layout
|-
| '''Feature set'''
|
* Almost 100% matching what we have already
|
* Still many features left to implement
|
* Almost 100% matching what we have already
|
* 100% of what we have
|-
| '''String Support'''
|
* May need some work to get it working
|
* Built with string support in mind
|
* Will need some work to get it working
|
* Scripts already in place to help with this
|-
| '''Mobile Support'''
|
* Editor works well, the the dialogues don't
|
* Editor works well, as do the dialogues it launches
|
* Editor works well, the the dialogues don't
|
* Very poor
|-
| '''Plugin Support'''
|
* Plugins are easy to write
* Plenty of 3rd party plugins already out there
|
* Plugins support YUI
* Plugins are easy to write
* Moodle is the only source of plugins
|
* Plugins are easy to write
* Plenty of 3rd party plugins already out there
|
* Plugins are easy to write
* Plenty of 3rd party plugins already out there
|-
| '''Loading Speed''' (Lets wait until all editors have comparible levels of Moodle integration before comparing speed please.)
|
* -
|
* -
|
* -
|
* -
|-
| '''Equation Editor'''
|
* Has mathjax plugin - uses different maths delimiters so needs hacking to make it backwards compatible with our existing equations.
|
* Has mathjax plugin - requires newly written mathjax filter but is 100% compatible with existing equations
|
* Has dragmath plugin. Java based - ugly, not-accessible.
|
* Has dragmath plugin. Java based - ugly, not-accessible.
|}
(Sorry - editing the above table hurts my brain - just noting that it is not up to date)

=== CKEditor 4 ===

'''Pros:'''
* Huge community of developers
* Plenty of plugins
* Good existing documentation
* Inline HTML Source editor - no need to open a dialogue to edit the source
* Ability to replace file browser with Moodle's filepicker
* [http://docs.ckeditor.com/#!/api/CKEDITOR.config-cfg-baseFloatZIndex baseFloatZIndex] - allows the zIndex to be set in a more strict manner

'''Cons:'''
* Unfamiliar to Moodle developers

'''Technical notes (lessons learned from the prototypes)'''
* Code seems high quality, as is the documentation.
* Language strings can be mapped directly to AMOS
* Ships with a nice mathjax solution
* Has own collapse feature (which we disabled in favour of ours)
* Does initially include alot of separate JS and CSS files (which get browser cached by our loader)
* Good accessibility support
* Theme system is fairly easy to work with
* Has a lot of features without feeling super heavyweight
* Dialogues on mobile do not go "fullscreen" (so don't fit)
* Current prototype has 0 modifications to the upstream code.

'''Outstanding work from the prototype'''
* Moodle language loading not implemented for plugins yet (but there is nothing stopping it)
* Needs a hack to the code to prevent the window flash when accessing a repository
* Important missing plugins - Insert media, Manage files
* Update behat tests, may require changes to behat framework to wait for editor loading

'''Missing features'''
* Media Manager
* Emoticons
* Non-breaking space ??
* Cleanup Messy code
* Prevent automatic linking

=== Atto ===

'''Pros:'''
* Excellent accessibility
* Excellent integration for Moodle strings
* Inline HTML Source editor - no need to open a dialogue to edit the source

'''Cons:'''
* Maintenance will rely on Moodle developers
* We need to document it ourselves
* No external community to lean on

'''Technical notes (lessons learned from the prototypes)'''

* Code is high quality, it is quick to build new plugins
* No mapping required for Language strings
* Ships with a nice mathjax solution
* Uses YUI in plugins - so easy for Moodle developers to learn
* Good accessibility support (but could do with some improvements)
* Fully themable in a moodle theme (even icons)
* Feels fast and nimble. This also means it does less.
* Uses Moodle dialogues - so dialgoues will be 100% as accessible as the rest of the dialogues in Moodle

'''Outstanding work from the prototype'''
* Important missing plugins - Tables/Grid, Manage files
* Update behat tests, behat framework will work nicely with this editor because it uses standard yui loading.

'''Missing features'''
* Tables
* Strike-through
* Subtext
* Supertext
* Fontface
* Fontsize
* Color
* Background color
* Paste as plain text
* Paste from Word
* Insert character
* Switch RTL/LTR
* Find
* Find/Replace
* Media Manager
* Emoticons
* Non-breaking space
* Cleanup Messy code
* Prevent automatic linking
* Undo/redo

=== TinyMCE 4 ===

'''Pros:'''
* Menus allow the toolbars to be less cluttered
* Huge community of developers
* Plenty of plugins
* Good existing documentation
* Simple hook for file-picker: http://www.tinymce.com/wiki.php/Configuration:file_browser_callback
* Uses LESS for style sheets

'''Cons:'''
* Swapping from WYSIWYG mode to Source mode launches a dialogue
* Uses Jake for LESS compilation
* Uses fonts for icons - icoMoon font service

'''Technical notes (lessons learned from the prototypes)'''

* Code is of average quality. It is hard to build new plugins, the documentation is lacking.
* Language strings are terrible and require nasty hacks to work at all and the solution is ugly.
* We have drag math for equations but it sucks
* There is alot of accessibility features built in - but there are numerous violations of the spec and everything does not work nicely with the keyboard.
* Skinning is hard and ugly.
* Loads slowly
* Requires yet another tool for building skins (jake)
* Despite being the most similar to tinymce3, this editor took the most work and the most hacks to get to the same level of integration.

'''Outstanding work from the prototype'''
* Split onblur hack from collapse plugin into it's own plugin.
* Improvements to the nasty lang string hack
* Implement missing plugins (manage files)
* Update behat tests, behat framework requires hacks for this editor because it loads things slowly and randomly.

[edit]

== Sub Tasks ==

# Assess different editors
# Prototype alternatives
# Ask some users
# Decide on an editor
# Implement editor
## Getting the new editor to render without altering the existing DOM - prevents changes needed to maintain third party plugins.
## Getting AMOS strings working within Editor.
## Getting Filepicker working within Editor Dialogues.
## Add file management plugin (Marinas or other)
# Disable TinyMCE

== Mobile Examples/Alternatives ==
* Evernote - has a minimal toolbar that collapses to a single toggle button with nothing else displayed
* Google Docs - has a simple toolbar that scrolls with a swipe
* Gmail - Single icon that launches a simple menu-like toolbar

== Mock-Ups/Prototypes ==
http://prototype.moodle.net/editor

== Related Tracker Issues ==

[[Category:Project]]

Editor 2.7

2014-01-06T07:35:49Z

Phalacee: /* CKEditor 4 */

{{Work in progress}}
{{Infobox Project
|name = Text Editor Revamp
|state = In Development
|tracker =
|discussion = https://moodle.org/mod/forum/discuss.php?d=243197
|assignee = Jason & Damyon @ Moodle HQ
}}
{{Moodle 2.7}}

== Project goals ==

The purpose of this document is to plan how to update the default text editor in Moodle.

The aim of this change is to improve accessibility and usability, while replacing TinyMCE 3.5, which is now unsupported.

TinyMCE 3.5 will be kept in place for the next few releases, but will be disabled by default.

Along with the replacement of the Editor, plugins for TinyMCE 3.5.8, that are included as part of the Moodle release, will need to be made compatible with the new editor.

== Considerations ==

* Usability of the editor - is it easy to create content with?
* Accessibility of the editor - is it at or easy to get it to follow the WCAG AA standard?
* Accessibility of the code produced by the editor - will it produce content that is up to the WCAG AA standard?
* Maintainability of the links between the editor and Moodle - how much work will we need to do every time we upgrade?
* Appearance of the editor - can its interface be modified to look like the other toolbars currently in Moodle?
* Do the dialogues look the same and have the same accessibility features we expect from Moodle dialogues? Do the dialogues scale/re-flow on small screens?
* Strong feature set - does it support the things our users have come to expect already?
* String support - how difficult will it be to allow strings to change when the Moodle language changes?
* Mobile support - how well does it scale on small screens and touchscreens?
* Plugin support - can our community write plugins easily?
* Browser support - does it support all the browsers Moodle does?
* Loading speed - how quick is it to load the editor ready for use?
* Upstream support - will it be supported for the lifetime we want (3 years+?)
* RTL support - does it include RTL support for the content, user interface and included dialogues?
* Given we need to redo the dragmath support - is dragmath the best choice for an equation editor?
** Cons of dragmath
*** Java applet
*** Requires tex filter to be enabled globally
*** Complaints about tex filter
*** Open GPL issue: MDL-32450
** Alternative
*** MathJax filter + equation editor plugin

== Out there suggestions ==
* Add a picture editor to Moodle. (Paintweb - previous GSOC project: [[Paint_tool_integration]] )
* Add a "html_tiny" text format with a super cut down editor that supports it (e.g. - no toolbar at all - but still html with bold, italics, cut/paste etc)
* [http://wordpress.org/plugins/plugnedit/ Drag and drop handling of media]

== Candidates ==

* CKEditor4
* Atto
* TinyMCE 4
* ??? Are there other alternatives?

{| class="nicetable"
|-
! ..
! CKEditor 4
! Atto
! TinyMCE 4
! TinyMCE 3.5
|-
| '''Usable Editor'''
|
* Still minor room for improvement
|
* Visual feedback for the state of the text under the cursor/caret needs improvement
|
* Still minor room for improvement
|
* Still minor room for improvement
|-
| '''Accessible Editor'''
|
* Still minor room for improvement
|
* Still minor room for improvement
|
* Lots of warnings on the Chrome Accessibility Audit
|
* Still room for improvement
|-
| '''Accessible Content'''
|
* Fairly good
|
* Fairly good
|
* Fairly good
* Decorative images need empty alt tag
|
* Still room for improvement
* Decorative images need empty alt tag
|-
|''' Maintainable with Moodle'''
|
* '''Unknown'''
|
* Needs documentation and acceptance tests
|
* '''Unknown'''
|
* Scripts already in place to help with this
|-
| '''Editor Appearance'''
|
* Can be themed to look like existing toolbars
* Dialogues are easy to change
* Icons need work
|
* Already looks like existing toolbars
|
* Can be themed to look like existing toolbars
* Dialogues are easy to change
* Icons need work
|
* The DOM is really nasty
* Uses tables for layout
|-
| '''Feature set'''
|
* Almost 100% matching what we have already
|
* Still many features left to implement
|
* Almost 100% matching what we have already
|
* 100% of what we have
|-
| '''String Support'''
|
* May need some work to get it working
|
* Built with string support in mind
|
* Will need some work to get it working
|
* Scripts already in place to help with this
|-
| '''Mobile Support'''
|
* Editor works well, the the dialogues don't
|
* Editor works well, as do the dialogues it launches
|
* Editor works well, the the dialogues don't
|
* Very poor
|-
| '''Plugin Support'''
|
* Plugins are easy to write
* Plenty of 3rd party plugins already out there
|
* Plugins support YUI
* Plugins are easy to write
* Moodle is the only source of plugins
|
* Plugins are easy to write
* Plenty of 3rd party plugins already out there
|
* Plugins are easy to write
* Plenty of 3rd party plugins already out there
|-
| '''Loading Speed''' (Lets wait until all editors have comparible levels of Moodle integration before comparing speed please.)
|
* -
|
* -
|
* -
|
* -
|-
| '''Equation Editor'''
|
* Has mathjax plugin - uses different maths delimiters so needs hacking to make it backwards compatible with our existing equations.
|
* Has mathjax plugin - requires newly written mathjax filter but is 100% compatible with existing equations
|
* Has dragmath plugin. Java based - ugly, not-accessible.
|
* Has dragmath plugin. Java based - ugly, not-accessible.
|}
(Sorry - editing the above table hurts my brain - just noting that it is not up to date)

=== CKEditor 4 ===

'''Pros:'''
* Huge community of developers
* Plenty of plugins
* Good existing documentation
* Inline HTML Source editor - no need to open a dialogue to edit the source
* Ability to replace file browser with Moodle's filepicker
* [http://docs.ckeditor.com/#!/api/CKEDITOR.config-cfg-baseFloatZIndex baseFloatZIndex] - allows the zIndex to be set in a more strict manner

'''Cons:'''
* Unfamiliar to Moodle developers

'''Technical notes (lessons learned from the prototypes)'''
* Code seems high quality, as is the documentation.
* Language strings can be mapped directly to AMOS
* Ships with a nice mathjax solution
* Has own collapse feature (which we disabled in favour of ours)
* Does initially include alot of separate JS and CSS files (which get browser cached by our loader)
* Good accessibility support
* Theme system is fairly easy to work with
* Has a lot of features without feeling super heavyweight
* Dialogues on mobile do not go "fullscreen" (so don't fit)
* Current prototype has 0 modifications to the upstream code.

'''Outstanding work from the prototype'''
* Moodle language loading not implemented for plugins yet (but there is nothing stopping it)
* Needs a hack to the code to prevent the window flash when accessing a repository
* Important missing plugins - Insert media, Manage files
* Update behat tests, may require changes to behat framework to wait for editor loading

'''Missing features'''
* Media Manager
* Emoticons
* Non-breaking space ??
* Cleanup Messy code
* Prevent automatic linking

=== Atto ===

'''Pros:'''
* Excellent accessibility
* Excellent integration for Moodle strings
* Inline HTML Source editor - no need to open a dialogue to edit the source

'''Cons:'''
* Maintenance will rely on Moodle developers
* We need to document it ourselves
* No external community to lean on

'''Technical notes (lessons learned from the prototypes)'''

* Code is high quality, it is quick to build new plugins
* No mapping required for Language strings
* Ships with a nice mathjax solution
* Uses YUI in plugins - so easy for Moodle developers to learn
* Good accessibility support (but could do with some improvements)
* Fully themable in a moodle theme (even icons)
* Feels fast and nimble. This also means it does less.
* Uses Moodle dialogues - so dialgoues will be 100% as accessible as the rest of the dialogues in Moodle

'''Outstanding work from the prototype'''

* Important missing plugins - Tables/Grid, Manage files
* Update behat tests, behat framework will work nicely with this editor because it uses standard yui loading.

=== TinyMCE 4 ===

'''Pros:'''
* Menus allow the toolbars to be less cluttered
* Huge community of developers
* Plenty of plugins
* Good existing documentation
* Simple hook for file-picker: http://www.tinymce.com/wiki.php/Configuration:file_browser_callback
* Uses LESS for style sheets

'''Cons:'''
* Swapping from WYSIWYG mode to Source mode launches a dialogue
* Uses Jake for LESS compilation
* Uses fonts for icons - icoMoon font service

'''Technical notes (lessons learned from the prototypes)'''

* Code is of average quality. It is hard to build new plugins, the documentation is lacking.
* Language strings are terrible and require nasty hacks to work at all and the solution is ugly.
* We have drag math for equations but it sucks
* There is alot of accessibility features built in - but there are numerous violations of the spec and everything does not work nicely with the keyboard.
* Skinning is hard and ugly.
* Loads slowly
* Requires yet another tool for building skins (jake)
* Despite being the most similar to tinymce3, this editor took the most work and the most hacks to get to the same level of integration.

'''Outstanding work from the prototype'''
* Split onblur hack from collapse plugin into it's own plugin.
* Improvements to the nasty lang string hack
* Implement missing plugins (manage files)
* Update behat tests, behat framework requires hacks for this editor because it loads things slowly and randomly.

[edit]

== Sub Tasks ==

# Assess different editors
# Prototype alternatives
# Ask some users
# Decide on an editor
# Implement editor
## Getting the new editor to render without altering the existing DOM - prevents changes needed to maintain third party plugins.
## Getting AMOS strings working within Editor.
## Getting Filepicker working within Editor Dialogues.
## Add file management plugin (Marinas or other)
# Disable TinyMCE

== Mobile Examples/Alternatives ==
* Evernote - has a minimal toolbar that collapses to a single toggle button with nothing else displayed
* Google Docs - has a simple toolbar that scrolls with a swipe
* Gmail - Single icon that launches a simple menu-like toolbar

== Mock-Ups/Prototypes ==
http://prototype.moodle.net/editor

== Related Tracker Issues ==

[[Category:Project]]

Peer reviewing

2013-12-09T01:21:44Z

Phalacee: /* Output */

These are points to consider while peer-reviewing issues. Further explanation below.

[] Syntax
[] Whitespace
[] Output
[] Language
[] Databases
[] Testing (instructions and automated tests)
[] Security
[] Documentation
[] Git
[] Third party code
[] Sanity check

Acceptable check-marks are Y (for yes), N (for no) or - (for not applicable). All N check-marks should be accompanied by an explanation of the problem that still needs to be addressed.

==Syntax==
To allow the community of Moodle developers to work together, conventions should be followed.

* The code is easy to understand and, where it isn't, comments have been provided.
* Variables are named correctly (all lower case, no camel-case, no underscores).
* Functions are named correctly (all lower case, no camel-case, underscores allowed).
* PHP DocBlocks have been updated and adhere to [[Coding_style#Documentation_and_comments|coding style guide]].
* Where functions are being removed, the [[Deprecation]] process is followed.
* The code doesn't use [[Deprecated_functions_in_2.0|deprecated functions]].
* $_GET, $_POST, $_REQUEST, $_COOKIE, and $_SESSION are never used.

See the [[Coding style]] guide for details.

==Whitespace==
Unnecessary whitespace changes can cause conflicts when committing code.

Ensure that:
* there are no unnecessary blank lines in the new code;
* blank lines do not contain spaces;
* there are no unnecessary changes to whitespace in other areas on the file;

==Output==
Output needs to be controlled by renderers to achieve consistency and correct application of themes.

Ensure that:
* output renders are used to generate output strings, including HTML tags;
* HTML output is valid XHTML;
* no inline styles have been used in HTML output (everything has to be in CSS);
* CSS has been added to the appropriate CSS files (base, specific area, sometimes canvas); and
* the code doesn't use buffered output unless absolutely necessary.
* all visual output has a RTL alternative included

feedback any notices (E_STRICT, etc) seen into the MDL.

==Language==
To achieve appropriate internationalisation of Moodle, language strings must be managed correctly.

Ensure that:
* new language strings are named correctly (all lower case, no camel-case, underscores are permissible in some cases);
* language strings are used instead of hard-coded strings for text output;
* language strings have not been removed or renamed in stable branches (permitted only in master); and
* AMOS commands have been specified when moving, copying, or deleting language strings.

==Databases==
DB calls are the greatest performance bottleneck in Moodle.

If there is SQL code you can test quickly then do so.

Ensure that:
* there are minimal DB calls (no excessive use of the DB); and
* the code uses SQL compatible with all the supported DB engines (check all selected fields appear in an 'order by' clause).

==Testing instructions and automated tests==
It is the developer's responsibility to test code before integration. Issues should not be sent for peer review without tests so that the peer reviewer can assess their quality and use them to consider the scope of the issue.

Ensure that:
* there are specific testing instructions that state how, as well as what, to test. Please ensure that the testing instructions are in the correct format: [https://docs.moodle.org/dev/Behat Behat gherkin];
* new unit tests have been added when there is a change in functionality; and
* '''unit tests pass''' for related areas where changes have been made.
* '''Behat tests pass''' for related areas where changes have been made, especially when it involved UI changes.

==Security==
The user community relies on Moodle being responsibly secure.

Ensure that:
* user login is checked where an identity is needed;
* sesskey values are checked before all write actions where appropriate (some read actions as well);
* capabilities are checked where roles differ; and
* if the issue itself is a [[Security|security]] issue, the [[Process#Security_issues|security process]] is being followed.
** Ensure that the fix is '''not''' available in a public repository (ie. a personal Github account); stand-alone patches should be provided instead.
** The issue will not be integrated until just before the next minor version release.

==Documentation==
Work does not stop when code is integrated.

Ensure that:
* Appropriate [[Tracker_issue_labels|labels]] have been added when there has been a function change, particularly
** qa_test_required (significant functional change),
** docs_required (any functional change, usually paired with ui_change),
** dev_docs_required (any change to APIs, usually paired with api_chage),
** ui_change (any functional change, usually paired with docs_required, except ui_change remains permanetly), and
** api_change (any change to APIs that devs will need to know about, usually paired with dev_docs_required, except api_change remains permanetly).

==Git==
Ensure that:
* the commit matches the [[Coding style#Git_commits|Coding style]]
* the Git history is clean and the work has been rebased to logical commits; and
* the original author of the work provided as a patch has been given credit within the commit (as author of in the commit message if changes were made).

==Third party code==
Does the change contain third party code? If so, ensure that:

* The code is licensed under a [http://www.gnu.org/licenses/license-list.html#GPLCompatibleLicenses| GPL compatible license].
* The instructions for upgrading/importing the library and contained within a readme_moodle.txt file.
* The library is recorded in a thirdparty.xml file, including licensing information.
* Third party code has been scanned to check for url accessible entry points that could be exploited. These should either be disabled, or if required functionality they should be checked for security weaknesses.
* Does not duplicate the functionality of any existing api or third party library in core.

==Sanity check==
Ensure that:
* the code seems to solve the described problem completely within its reported scope (and further issues have been created to resolve remaining parts or further refactoring);
* the code makes sense in relation to the broader codebase (look at the whole function, not just the altered code); and
* the developer has searched for and fixed other areas that may also have been affected by the same problem.

==See Also==
* [http://moodle.org/plugins/view.php?plugin=local_codechecker Code checker plugin]

Editor 2.7

2013-12-06T00:37:17Z

Phalacee: /* Candidates */

Editor 2.7

2013-12-04T03:30:23Z

Phalacee: /* Mock-Ups/Prototypes */

Editor 2.7

2013-11-22T08:09:43Z

Phalacee: /* Mobile Examples */

Editor 2.7

2013-11-22T06:53:59Z

Phalacee:

Editor 2.7

2013-11-22T06:48:50Z

Phalacee:

Editor 2.7

2013-11-20T04:16:12Z

Phalacee: /* TinyMCE 4 */

Editor 2.7

2013-11-19T06:18:26Z

Phalacee: /* TinyMCE 4 */

Editor 2.7

2013-11-19T03:42:23Z

Phalacee: /* TinyMCE 4 */

Editor 2.7

2013-11-18T01:50:45Z

Phalacee:

Editor 2.7

2013-11-18T01:49:21Z

Phalacee: /* CKEditor 4 */

Editor 2.7

2013-11-18T01:31:34Z

Phalacee: /* CKEditor 4 */

Editor 2.7

2013-11-18T01:31:18Z

Phalacee: /* CKEditor 4 */

Editor 2.7

2013-11-18T01:25:27Z

Phalacee: /* Project goals */

Editor 2.7

2013-11-15T05:51:09Z

Phalacee: /* TinyMCE 4 */

Editor 2.7

2013-11-15T05:48:57Z

Phalacee: /* Candidates */

Editor 2.7

2013-11-15T05:46:28Z

Phalacee: /* Considerations */

Editor 2.7

2013-11-15T05:33:42Z

Phalacee: /* Candidates */

Editor 2.7

2013-11-15T05:31:26Z

Phalacee: /* Considerations */

Editor 2.7

2013-11-15T03:46:15Z

Phalacee: /* Candidates */

Editor 2.7

2013-11-15T03:17:05Z

Phalacee: /* TinyMCE 4 */

Editor 2.7

2013-11-15T01:57:14Z

Phalacee:

Editor 2.7

2013-11-15T01:56:09Z

Phalacee: /* Candidates */

Editor 2.7

2013-11-15T01:34:35Z

Phalacee: /* Candidates */

Editor 2.7

2013-11-15T01:32:12Z

Phalacee: /* Candidates */

Editor 2.7

2013-11-15T01:29:51Z

Phalacee: /* Considerations */

Editor 2.7

2013-11-15T01:29:02Z

Phalacee: /* Candidates */

Editor 2.7

2013-11-15T01:27:25Z

Phalacee: /* Candidates */

Editor 2.7

2013-11-14T23:56:27Z

Phalacee: /* Candidates */

Editor 2.7

2013-11-14T23:51:33Z

Phalacee: /* Candidates */

Editor 2.7

2013-11-14T07:42:27Z

Phalacee: /* Considerations */

Editor 2.7

2013-11-14T07:41:33Z

Phalacee:

Editor 2.7

2013-11-14T07:38:11Z

Phalacee: /* TinyMCE 4 */

Editor 2.7

2013-11-14T07:28:19Z

Phalacee: /* Atto */

Editor 2.7

2013-11-14T07:27:49Z

Phalacee: /* CKEditor 4 */

Editor 2.7

2013-11-14T07:27:10Z

Phalacee: /* TinyMCE 4 */

Editor 2.7

2013-11-14T07:22:37Z

Phalacee:

Editor 2.7

2013-11-14T06:25:26Z

Phalacee:

Editor 2.7

2013-11-14T06:15:00Z

Phalacee:

Editor 2.7

2013-11-14T05:56:16Z

Phalacee: /* Considerations */