I definitely agree! Working with htmlArea is very frustrating at times. Both TinyMCE and FCK are excellent, well-maintained, and output XHTML 1.0 (and work with Safari).

I would love to see an official alternate editor added as an optional choice with 1.9 ASAP. If that isn't possible, definitely get it added in 2.0.

Just a note to mention the YUI editor could also be an alternative? It seems to be improving all the time and we have it included too

Possible yes - although YUI RTE is still beta and has only a small amount of those properties that TinyMCE and FCKEditor have. Why not have all of them? This is the best possible time to create first that selection code for any current or coming editor including htmlarea - if we can select languages, themes and activities it would be natural to be able to select editor integration files too.

Dan,

have you tried to integrate YUI RTE to moodle? The code itself is great but not as user friendly as simple init code of TinyMCE or FCKEditor with good documentation. If I had to choose my order of editors would be TinyMCE, FCKEditor, HtmlArea and YUIRTE...

Hey, nice to get some comments in here!

I had a short talk with Martin at lunch and he was telling me there was apparently a consensus on using Tinymce. FCKeditor is quite nice, and I wouldn't mind one or the other. All others have shortcomings at this time (arguably less and less as time goes on).

I am starting working on this. We want to have a recent html editor in the next version of Moodle. It might be backported to 1.9, but this is not the goal at this time. I have the feeling (and the more I look at the code, the stronger it gets) that updating the editor will involve modifying quite a lot of code, so it might be quite a lot of work to backport it. We'll see...

Ideally, we would come up with a set of functions that people could use to create modules to use whatever editor they fancy. This would be quite nice, but we need to "plug" the editor to (among others) the list of files (images and others) available on the server (this part of moodle core will get a serious overhaul soon), the moodle list of smileys, etc.

Please, if you already have code/patches/etc. send them in or post links to them in this issue. Even if it's for older versions, or not quite working, I will have a look and it might help a lot.

Great!

I have no patches because I used different route to render editors but you should check at least these files and functions and all activities separately (some have special editor code but not all):

lib/weblib.php: functions

use_html_editor
print_textarea
print_editor_config
editorhelpbutton
helpbutton
emoticonhelpbutton
editorshortcutshelpbutton

lib/moodlelib.php: functions

can_use_html_editor (browser check to support latest versions of Safari and Opera)
loadeditor (no need to change? -> editorlib.php)

lib/adminlib.php: classes and functions for settings

lib/editorlib.php (selection and classes)

Those plugins Glen wrote (moodleimage and moodlelink) for TinyMCE are good - you could check capabilities to use of coursefiles and imagemanager. When you get the basic integration ready I would be happy to help with testing plugins, themes and skins and settings.

Mat,
remember to upgrade moodle to the latest code of TinyMCE 3 from http://tinymce.moxiecode.com/

And compressor code should be optional (some kind of a selector use compressor/disable compressor) - http://wiki.moxiecode.com/index.php/TinyMCE:Compressor/PHP

If it helps we could also create a theme/skin that looks like htmlArea for such moodlers who still miss htmlArea. One part of TinyMCE that I have never tested is Spellchecker http://wiki.moxiecode.com/index.php/TinyMCE:Plugins/spellchecker

It is a long list of new code and we need definitely many testers in different environments but the good thing is that after integration is ready bug fixes in TinyMCE itself (if you find any) will be done by Moxiecode and other developers of TinyMCE. Just contact Spocke (Main developer of TinyMCE) directly or TinyMCE support http://tinymce.moxiecode.com/support/

Mathieu, two notes:

1) Although we may probably use TinyMCE something unexpected has happened.

Latest nightly build XINHA has started to work with the latest Opera and I checked that it supports with Safari too - Thanks you Petr Dlouhý ( MDL-6403 )

This is really good news because Xinha has some really good plugins and the integration of Xinha is almost similar to integration of htmlArea - basicly you just replace name htmlarea with Xinha.

2) If you use Janne's integration for TinyMCE you should probably check also files

lib/editor/tinymce/moodlecontent.css
lib/editor/tinymce/moodledialog.js
lib/editor/tinymce/tinymce.class.php

Hey, that's good news! Is it possible to make xinha xhtml-compliant? It seems to be possible to make this happen with tinymce, following http://wiki.moxiecode.com/index.php/TinyMCE:Configuration/valid_elements#Full_XHTML_rule_set: (at some performance cost, apparently)

Can you try dropping-in Xinha to see if it "just works" ? This could be a very nice thing for 1.8 / 1.9 .. I'm sure a lot of people would appreciate.. We can then see if TinyMCE/FCKeditor are worth the trouble of adapting all the code for 2.0.

I added the testing code to http://moodle.org/mod/forum/discuss.php?d=93475

I think it works with all versions of moodle and should be easy to change the administration code to use Xinha - also all those hacks that have been made to old htmlarea code should work. I haven't tested performance etc

TinyMCE may still be the most reliable and flexible choice and configuration options are absolutely the best of these 3 editors. I agree that changing editor integration code is not easy - the original code was written to be stable and we would need some kind of module structure for editors to be able to change them easier. We don't yet know what happens when we get new browsers ( Firefox 3, Internet Explorer 8,...).

If we want the easiest solution it might be to replace htmlarea with Xinha and to write new code for "Editor editor" to be able to change editors later with some standard way.

And code of coursefiles.php should work with Xinha too but the files used for browsing images should be moved to foder xinha. One interesting extra plugin is Equation editor - xinha has AsciiMathML Formula Editor and Glen has added DragMath plugin to his TinyMCE test site plugins.

The list of possible configuration options of Xinha is in http://xinha.webfactional.com/wiki/Documentation/ConfigVariablesList

If we look at other systems using TinyMCE

http://wiki.moxiecode.com/index.php/TinyMCE:CMS_systems

or FCKEditor

http://www.fckeditor.net/whosusing

and Xinha or YUI RTE have no references... TinyMCE and FCKEditor dominate...

Yeah, this makes me think it could be possible to provide different settings per role .. thus letting some people input tables or some more advanced formatting (mathml) while providing a more simple interface to student or users not needing the advanced stuff. This would be a bit of a nightmarish admin interface to code though. I've seen it in a few CMS and I haven't seen one that's really nice... :(

Maybe the settings of editor could be collected from several places: for example names of possible plugins could be in table mdl_tinymce_plugins and they could be selected based on role, activity, user...id
Table mdl_tinymce_config could have the basic init code like
entity_encoding : "raw"
or
theme_advanced_fonts : "Arial=arial,helvetica,sans-serif;Courier New=courier new,courier,monospace"
and they could be selected based on role, activity, user...id
and so on (languages, themes...).
If no settings were found from database editor would always use default configuration.

Or we could have the whole init code in one editable file/field of database and the name of that file/field could be called from editor integration code. The same way as we use session themes, user themes ,course themes or category themes. The original integration code is simply too complicated.

The only restricting functions are function print_textarea and use_html_editor in weblib.php

If they were in theme meta.php or in some selectable editor integration file and location of init code could be changed based on role, activity or user (from editor profile files like tiny_professional.php and tiny_kids.php) the situation would be close to editing themes. There is a plan to create a simple theme with configuration menu - the same way we could have a simple editor profile selector that could save the init code to database or to edited editor profile file.

In fact http://xinha.gogo.co.nz/xinha-nightly/examples/ExtendedDemo.html

is an example of such selector. You can select language, skin and each plugin separately. The only thing missing is the possibility to select buttons and the order of buttons. If the order of buttons comes from table where we have row (1,2,3,4) and order number 1,2,3... it could be possible too. Editor administration code could be in the same folder as editor itself, not necessarely in adminlib.php

Anyway I am just giving ideas - some of them may be easy to implement and some may be too troublesome.

The editor profile could also be created with a method like in http://www.cb1inc.com/open-source/dojo-toolkit-module/documentation/configuration/editor-profiles

By the way that Extended demo of Xinha is included to Xinha-nightly package examples folder with all files.

I have been testing these editors no several hours and one thing that is very different is use of mouse right click. I personally like the capability to righ click things like images to edit properties, add links etc and this works ok in TinyMCE and FCKEditor but Xinha has no right click properties. On the whole TinyMCE feels better - but this is only my opinion. All of these 3 editors will bring lots of new features to moodle - and hopefully fix some old bugs (but cause no new ones).

Mathieu,

One good way to go - if we want to allow use of different editors with different editor profiles - is to take away functions print_textarea and use_html_editor to some selectable file. To make sure that this file is found in all cases we could for example have editable code in theme folders in a new file, let's say editor.php (or in database) and if there is no such file in theme folder (or no such data in database) moodle should read default editor file from some folder, moodle main folder for example (or read default code from database). Some settings could be in theme/database (just a list of init settings or some php tags to include some editor profile and theme designers could design new editor skins and editor themes ) and the file for creating editor profiles could be in folder lib/editor/nameofeditor with basic administration code for buttons, plugins, languages and security/site wide settings (or settings could be in database). Meaning that each editor has own administration code (the settings are now in adminlib.php and Janne's integration files) and we could change/select the editor itself and editor profile in themes or based on roles (the capability check can be in theme files like Glen did in his TinyMCE integration)

One important thing to note is that editors do not necessarely need additional init code (they use defaults if no settings are found) but some settings like selection of absolute/relative paths and different filters may cause lots of trouble if they are not correct so some kind of a default editor profile (like we have default settings for different roles) could be nice.

To make selection of editor simple we could add to table mdl_user and field htmleditor values for editor profile. Current value 0 means that user does not want to use editor and 1 means selection of editor in user profile. Now if 1 means at the same time default editor in a new table mdl_editor_profile we could have as many editors/editor profiles as we like and selection of editor could be controlled with one value 1, 2,... in field htmleditor of table mdl_user. The admin settings could be controlled with one admin file and only the location of that file could be in profile. The admin file itself could be different for all editors and for htmlarea all settings are already available in lib files.

This would make changing both default editor and role based editor easier - see the attached table editorprofile.jpg - and some administration files could be simple init code and some (at least default editor administration file) could have control panel where user (administrator) can hide/show buttons, plugins etc.

Mathieu,

I will create a test site during the next days (moodle 1.9) so that when you edit profile and html editor is enabled in site administration you have the following choices (from field htmleditor in table mdl_user):

When editing text

0 Use standard web forms
1 Htmlarea - current "Use HTML Editor (some browsers only)"
2 TinyMCE
3 Xinha
4 FCKEditor

I'll send you a link to test when this is ready - I think it will take 2-3 days to get all the settings checked. If I mix Xinha and HtmlArea custom plugins and smilies are not rendred in Xinha so it is better to rewrite code to Xinha. Most button controls (hide/show) of htmlarea work in Xinha with current code of htmlarea but still Xinha is not htmlArea (it's more like a son or daughter of htmlarea)

Editor selection is working.

After some hours of playing with code I found a solution that enables using several editors and custom editors.

Change to user/editlib.php:

    if ($CFG->htmleditor) {
        $choices = array();
        $choices['0'] = get_string('texteditor');
        $choices['1'] = get_string('htmleditor');
        $choices['2'] = get_string('tinymce');
        $choices['3'] = get_string('xinha');
        $choices['4'] = get_string('fckeditor');
        $mform->addElement('select', 'htmleditor', get_string('textediting'), $choices);
        $mform->setDefault('htmleditor', 1);
        $mform->setAdvanced('htmleditor');
    }

Changes to lib/weblib.php:

moved functions print_textarea, use_html_editor and print_editor_config from lib/weblib.php to folders

lib/editor/0/meta.php
lib/editor/1/meta.php
lib/editor/2/meta.php
lib/editor/3/meta.php
lib/editor/4/meta.php

These files have all the functions that are browser spesific - I am now checking the administration code.

I changed code in lib/weblib.php

if (!isset($THEME->standardmetainclude) || $THEME->standardmetainclude) {
        ob_start();
include_once($CFG->dirroot.'/theme/standard/meta.php');
        $metapage .= ob_get_contents();
        ob_end_clean();
    }

to

if (!isset($THEME->standardmetainclude) || $THEME->standardmetainclude) {
        ob_start();
$eprof = intval($USER->htmleditor);
include_once($CFG->dirroot.'/lib/editor/'.$eprof.'/meta.php');
include_once($CFG->dirroot.'/theme/standard/meta.php');
        $metapage .= ob_get_contents();
        ob_end_clean();
    }

and this way correct editor code is selected (unless editor is disabled site wide) and if standardmetainclude is false in theme it is also possible to add modified functions to certain theme.

Changed in lang/en_utf8/moodle.php string

$string['htmleditor'] = 'Use HTML editor (some browsers only)';

to

$string['htmleditor'] = 'HtmlArea (some browsers only)';

and added new lines:

$string['tinymce'] = 'TinyMCE';
$string['xinha'] = 'Xinha';
$string['fckeditor'] = 'FCKEditor';

In previous comment: those meta.php in folders 0...4 have files have all the functions that are EDITOR spesific
(where is the EDIT button of this tracker ???)

Hi Mathieu and other testers of editors,

after reading all pages of http://wiki.moxiecode.com/index.php/TinyMCE:Index and several days of comparing TinyMCE, FCKEditor and Xinha I must say that - although it is good to be able to select different editors - there is only one editor where EVERYTHING WORKS, it's fast and is flexibly configurable. That editor is TinyMCE and my opinion is that it is the only reasonable alternative to next default editor of moodle. Iwas disappointed to stability of Xinha - it is not much better than Htmlarea - and although FCKEditor is near the properties of TinyMCE it is possible to add it later to moodle.

I think we should use all our energy to get the administration of settings of TinyMCE ready and replace Htmlarea with TinyMCE as a default editor of moodle. latest version of TinyMCE 3 is excellent and those plugins Glen has modified (moodleimage, moodlelinks and dragmath) work really nice.

All we need is an administration menu for changing different settings. Role based or not - it is good to have one solid configuration made by administrator - but if it possible to have custom user settings it is even better.

Thanks for doing this job, Mauno .. Eloy was telling me yesterday that it would be nice for somebody to do just that.

I think Eloy, you and other main developers are experts in creating administration forms for moodle but I could also try to create an alternative version of administration code - starting from the current button selection - and test some kind of a editor profile generator. The main idea is to save all settings as a string to database - php can explode and implode those strings to arrays and back. That way users could get a possibility to select some settings of editor themselves (not only the editor) and administrators would have a full control to site wide editor settings. The field for those user settings could be in table mdl_user and field htmleditor - now it is used for testing if user wants to use htmleditor and in my integration it gives the number of editor (0 no editor, 1 htmlarea, 2 tinymce...) but I could simply change in previous code $eprof = intval($USER->htmleditor); to read only first number as the editor and different custom settings could be added with separator after this number.

 I just figured out why messages were not working on my test site with multiple editors enabled - if some activity does not use normal theme headers it does not get meta tags from theme or in my integration editor meta.php. After including a tiny file meta1.php to message/discussion.php and send.php I noticed that it is possible to get editor itself configurable and to get as many different editors as we want and also to get different configuration for message editor (or some other activity if needed)

It would also be possible in tinyMCE to give different configuration for different activities using name of class of textarea (or other element) as editor-selector just by giving multiple init code

tinyMCE.init({
mode : "textareas",
theme : "simple",
editor_selector : "mceSimple"
});

tinyMCE.init({
mode : "textareas",
theme : "advanced",
editor_selector : "mceAdvanced"
});

but it would work only in tinyMCE.