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.

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...

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.

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/

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/

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

http://wiki.moxiecode.com/index.php/TinyMCE:Configuration/valid_elements#Full_XHTML_rule_set:

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.

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

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.

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...

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.

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.

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.

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.

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)

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';

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.

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.

plugins : "safari,emotions,searchreplace,fullscreen,advlink,advimage,moodleimage,moodlelink",
theme_advanced_buttons1 : "fontselect,fontsizeselect,",
theme_advanced_buttons2 : "forecolor,backcolor,separator,moodlelink,unlink,moodleimage,emotions,charmap,search,separator,code,separator,fullscreen",
theme_advanced_buttons3 : "",
theme_advanced_disable : "formatselect,sub,sup,copy,cut,paste,cleanup,undo,redo,justifyleft,justifycenter,justifyright,justifyfull,ltr,rtl,bullist,numlist,outdent,indent,hr,anchor,tablecontrols",

when htmlarea does the same with function

use_html_editor('message', 'formatblock subscript superscript copy cut paste clean undo redo justifyleft justifycenter justifyright justifyfull lefttoright righttoleft insertorderedlist insertunorderedlist outdent indent inserthorizontalrule createanchor nolink inserttable'); in file message/discussion.php

but it's only needed because I have not defined default administration and configuration of buttons and plugins for tinymce. All these editors have a different way to replace textareas with editor but it really does not matter if the replacement is done by function print_textarea or use_html_editor as long as it is possible to control those settings. And FCKEditor has of course different settings...

theme_advanced_disable : "formatselect,sub,sup,copy,cut,paste,cleanup,undo,redo,justifyleft,justifycenter,justifyright,justifyfull,ltr,rtl,bullist,numlist,outdent,indent,hr,anchor,tablecontrols",

is not needed at all because

theme_advanced_buttons1 : "fontselect,fontsizeselect,",
theme_advanced_buttons2 : "forecolor,backcolor,separator,moodlelink,unlink,moodleimage,emotions,charmap,search,separator,code,separator,fullscreen",
theme_advanced_buttons3 : "",

shows just the selected buttons (noticed 5 seconds after sending previous comment)

So it is possible to select either the list of buttons you want to show or a list of buttons you want to hide (disable)

Normal users should have the capability to select editor from those editor profiles they are allowed to use - there may be several editor profiles for the same editor - and maybe some basic settings like skin.

However one key aspect for my employer (and I'm sure many other users) is accessibility. This is not just the output (which should be valid xhtml) but in actually using the editor. Have these alternatives been accessibility-tested (e.g. is it 100% keyboard accessible, is it usable in JAWS, etc)? It may be possible to get an expert accessibility tester here to evaluate an editor such as tinymce, should we request that? (May not be able to happen instantly.)

One other issue re editors is that a frequently-expressed requirement here is the ability to configure the editor differently in different tools. I.e. there should be a 'simple' editor for use in forum posts or blog comments where you basically just want to be able to type text (so you only need bold, italic, bullet points, links, maybe insert image) and a 'complex' editor for use in creating html resources or wiki pages (where you need tables, heading styles, other structure stuff). So ideally the editor settings would actually offer at least two different configurable profiles for which buttons can be turned on/off by admin, and then when used in code, the code that calls the editor (e.g. a wiki page) would specify which profile. Obviously this is a bigger scope than changing the editor and should probably be kept separate but if you get into talking about changing the admin settings then it would be relevant.

.

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

http://culturall.atrc.utoronto.ca/index.php?option=com_content&task=view&id=90&Itemid=35

http://tinymce.moxiecode.com/punbb/viewtopic.php?id=10996

I am here making my personal testing (trying to help Mathieu and other mates) to get editors to behave like themes or part of themes and the best point in modern editors is that both theme and skin of editor can be changed and particularly in TinyMCE almost all parts of editors are configurable. Some other moodlers might prefer removing htmlarea and making tinymce as the one and only editor with one stable configuration. I like the idea that all activities, all themes, all sites and in distant (or not so distant?) future also all users may have an individual configurations for editors and that's the reason why I am "pushing" this idea of taking functions like print_textarea, use_htmleditor and probably also administration functions to separate configurable files or to database.

Making the editor usable by people with disabilities.
Ensuring that accessibility features can be introduced in the contents produced with the editor, guaranteeing and enforcing the minimum accessibility level in the contents.

http://docs.fckeditor.net/FCKeditor_3.x/Design_and_Architecture/Accessibility

I think the goal for both TinyMCE and FCKEditor developer teams is similar - they both want to build the best possible open source editor...

I have now ready a functional "TinyMCE init code generator" (modified Petr's book module) that allows testing and creating online any init code and because book module has already all necessary capability checks I can modify this to generate FCKEditor code as well - need just to create new configuration file for FCK Editor.

When I have renamed files and functions of this "test module" so that it does not cause any trouble to book module itself I could send you a copy if you need one.

If administration of editors (first only TinyMCE and FCKEditor) is in (admin only) module(s) new editors are easy to install or uninstall. You only need to upload/upgrade the latest files of custom editor itself (or several versions of custom editor for testing purposes) and the administration module. Editor itself could be selected from a list of (visible) profiles in database (value of field htmleditor in table mdl_user or mdl_config - value 0 can still be "no editor" and value 1 can be "default editor" with default settings) and there is no limit for a number of profiles (like folders 0,1,2,3...). Selection of buttons, plugins and most basic properties of editor can be done with selection boxes (show/hide) or drop down lists. If init settings are taken from database (editor profile xx in table yy) no init files are needed.

Most cms systems use modular structure for integration which could be better than stable settings in moodlelib.php, adminlib.php, weblib.php, editorlib.php (only my opinion - stable default editor is ok as well) ... you never know when you need to change editor again - for example YUI RTE can be a pleasant surprise after one year... All the functions used to render editor could be outside main lib files

Moodle usually needs only two functions to call editor: print_textarea and use_html_editor and to make everything simpler we could even take away use_html_editor and use only function print_textarea with different settings to render editor (using a function that does the replacement when window is loaded in function print_textarea - now htmlarea first prints a textarea and replaces it with editor using other function)

I vote for TinyMCE as well if only one editor is available.

In addition, supporting multiple editors forces Moodle to remain editor-agnostic which will make the codebase more flexible in the (likely) event that the default editor changes in the future.

At the moment buttons of TinyMCE are taken from table mdl_tiny_buttons that has fields id, tinyid, row, order, button, help and plugin.

Buttons can be placed to rows 1-4 and row 0 means hidden button and order of buttons is selected by field order. If the button needs a plugin it is found from field plugin and field help is for help messages.

Testing, testing...

It sounds more like a loop where counter is getting bigger al the time.

Discussion going on at http://moodle.org/mod/forum/discuss.php?d=96160

An example of TinyMCE: http://moodle.org/mod/forum/discuss.php?d=88382 ... see http://www.host4learning.com/moodlemce/ for the demo site. This works quite well, except the smileys are not connected to Moodle's.

Did you get my emails, Mathieu?

There are several ways to get all functions and moodle hacks to work. We may take all necessary functions away from lib files and place them either to (standard) theme meta.php (with selective include tags as well) or we may use weblib.php and function print_header to make the selection or...

It is also possible to replace configuration settings by exploding, imploding and replacing strings of settings like $cfg->editorhidebuttons if we want to have one default editor that has site wide settings in database and want to use same settings for all other editors - or we can create different settings for different editors.

By the way - I got Xinha to work with all htmlarea's settings - also image plugin. I still need to clean the rest of code and set up a public test site with all these editors.

In my previous tests I added moodle functionalities to tinymce with extra plugins (emoticons for moodle smilies and standardmenu for keyboard shortcuts and mouse right click menus + Glen's plugins moodleimage, moodlelink and dragmath with correct paths + files coursefiles.php & preview.php) and new editor theme (lib/editor/tinymce/jscripts/tiny_mce/themes/standard/editor_template.js has most settings of editor and multilang menu code). That way no code will get overwritten if tinymce is upgraded and you may have several configurations with different editor themes. Administration works ok for editorhidebuttons and smilies with small changes (correct names) to list of buttons in adminlib.php:

function admin_setting_special_editorhidebuttons() {
parent::admin_setting('editorhidebuttons', get_string('editorhidebuttons', 'admin'),
get_string('confeditorhidebuttons', 'admin'), array());
// weird array... buttonname => buttonimage (assume proper path appended). if you leave buttomimage blank, text will be printed instead
$this->items = array('fontselect' => '',
'bold' => 'bold.gif',
'italic' => 'italic.gif',
'underline' => 'underline.gif',
'strikethrough' => 'strikethrough.gif',
'sub' => 'sub.gif',
'sup' => 'sup.gif',
'copy' => 'copy.gif',
'cut' => 'cut.gif',
'paste' => 'paste.gif',
'cleanup' => 'cleanup.gif',
'undo' => 'undo.gif',
'redo' => 'redo.gif',
'code' => 'code.gif',
'spellchecker' => 'spellchecker.gif',
'fontsizeselect' => '',
'justifyleft' => 'justifyleft.gif',
'justifycenter' => 'justifycenter.gif',
'justifyright' => 'justifyright.gif',
'justifyfull' => 'justifyfull.gif',
'ltr' => 'ltr.gif',
'rtl' => 'rtl.gif',
'numlist' => 'numlist.gif',
'bullist' => 'bullist.gif',
'outdent' => 'outdent.gif',
'indent' => 'indent.gif',
'forecolor' => 'forecolor.gif',
'backcolor' => 'backcolor.gif',
'advhr' => 'advhr.gif',
'anchor' => 'anchor.gif',
'formatselect' => '',
'link' => 'link.gif',
'unlink' => 'unlink.gif',
'image' => 'image.gif',
'table' => 'table.gif',
'emotions' => 'emotions.gif',
'emoticons' => 'emoticons.gif',
'charmap' => 'charmap.gif',
'fullscreen' => 'fullscreen.gif',
'pastetext' => 'pastetext.gif',
'pasteword' => 'pasteword.gif',
'selectall' => 'selectall.gif',
'dragmath' => 'dragmath.gif',
'search' => 'search.gif',
'removeformat' => 'removeformat.gif',
'styleselect' => '',
'media' => 'media.gif',
'nonbreaking' => 'nonbreaking.gif',
'insertlayer' => 'insertlayer.gif');
}

and some rows later small change

$return .= ($value == '' ? get_string($key,'editor') :
'<img width="20" height="20" src="'.$CFG->wwwroot.'/lib/editor/tinymce/images/'.$value.'" alt="'.get_string($key,'editor').'" title="'.get_string($key,'editor').'" />').' ';

I tested also separating whole adminlib.php for different editors by code like this in adminlib.php:

<?php
global $USER, $CFG, $COURSE, $HTTPSPAGEREQUIRED;
if (!empty($USER->id)) {$eprof = intval($USER->htmleditor);}
else {$eprof = 1;}
include_once($CFG->dirroot.'/lib/editor/'.$eprof.'/adminlib.php');
?>

and then we can have totally different adminlib.php / settings for administration of each editor (or other things in moodle). For upgrading it might be better to keep adminlib.php unchanged and take just editor settings away to different editor administration. Things like background color of editor and fonts of editor are more css based settings and could be selected by editor theme - not site wide. It would be easier to change $cfg->editorhidebuttons to editor dependent setting - if we have just one config setting and we need to hide some button from all editors we either need to have all buttons and plugins in a long list and all icons for those buttons or hiding works only for those editors that use same name for button or plugin.

Martin,

THANK YOU!!!

This change gives a huge amount of new functionalities to moodle through editor themes and plugins. We may start creating all sorts of "widgets", forms, stamps, helpers etc straight to editors now and as Marc wished when developing Storytelling all sort of role based, activity bases, theme based, course based and user based editor settings become possible with TinyMCE and configurable editor.

Development package of tinymce ( http://tinymce.moxiecode.com/download.php ) has a file called JSTrim that can clean up/compress javascript files - you only need to select files in JSTrim.config and for example tiny_mce_src.js is compressed to tiny_mce.js so that size of the file is about 30-50% of original size and scripts are nearly as much faster to load. I have used it after making changes to files.

To have less files in moodle all files editor_plugin_src.js inside all plugin folders can be deleted. They are just larger duplicates of editor_plugin.js

All files editor_template_src.js inside editor theme folders can be deleted - they are larger duplicates of files editor_template.js

And file tiny_mce_src.js is a larger duplicate of tiny_mce.js.

If editor themes advanced and simple are not used (supposing moodle has a custom theme "standard" etc.) both theme folders can be deleted.

If we create new moodle language files for tinymce most language files of tinymce can be deleted (we should probably leave en language files anyway)

Css of tinymce (and other editors) may need some separation of IE specific css. Current editor skins can be modified to better fit themes of moodle and skins/skin variants can also be selected separately for each theme of moodle.

In /lib/editorlib.php line 102:

• array_push($CFG->editorsrc, "$editorbaseurl/tinymce/jscripts/tiny_mce/tiny_mce_gzip.php");

+ array_push($CFG->editorsrc, "$editorbaseurl/tinymce/jscripts/tiny_mce/tiny_mce.js");

to support old functions used through editorlib.php (Janne's special cases) in some 3rd party activities with method like

$editor = loadeditor($args); or $editor->starteditor('merge');

Otherwise we will have troubles with compressor init code and in some 3rd party activities editor does not render at all.

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

could be rewritten/checked to support Tinymce 3 and the methods that Janne has described in /lib/editor/neweditor_readme.txt (Special usage for Htmlarea and Tinymce). Some functions and plugins have changed from Tinymce 2.x to Tinymce 3.x and if tinymce.class.php is used the code should use existing theme and plugins.

The other alternative is that all 3rd party activities could use different editors and theme based init code and configuration with small changes to code of those activities. In standard activities moodle renders editor with functions print_textarea and use_html_editor and any other function could replace these functions to produce different editors with different init code in a more flexible way.

There may be a couple of such activities that use this method with htmlarea but I have not checked all 3rd party activities...only a couple of them...

It is just a matter of setting the correct init code for the editor we want to use in some activity - one file can define the init code and functions and use the existing editor (htmlarea, tinymce, xinha, fckeditor, yuirte etc)

If we separate also administration for editors we could use the same language files for settings like editorhidebuttons (button and plugin names) and lang/en_utf8/editor.php could have only such strings that are totally editor independent.

after testing fckeditor I might have found a way to avoid that use_admineditor and "double init code" for tinymce. I tested using a script:

window.onload = function ()
{
var alltextareas = document.getElementsByTagName("textarea");
for (var i=0; i < alltextareas.length; i++) {
if((alltextareas[i].className=='form-textarea') and (tinyMCE.getInstanceById(id) == null)) {
tinyMCE.execCommand('mceAddControl',false,'alltextareas[i].id');
}
}
}

for those parts of moodle where tinymce is not rendered with normal init code and it seems to work ok. I must investigate all code once again but during this week (probably on thursday) I should have a new test package ready with some missing features added and also fckeditor integrated to package.

I've just been playing with wordpress and liked the 'display kitchen sink' button on the editor. It allows a toggle between minimal buttons and all buttons and would help a lot with my students. does tinymce have a similar button, or can one be added easily?

http://www.fckeditor.net/nightly/fckeditor/_samples/default.html

We could use either custom plugins and functions inside editor toolbar or external buttons or selectors like the current toggle button. This was one of the ideas I had in mind when I was talking about the possibility to change editor by user (from editor profile or editor itself) but it could be possible to use with site wide default editors too for example with cookies. I still don't understand what's wrong with the approach to allow users to select editor if settings are defined so that students can't change any default settings of different editors...

Basicly it's the same logic as in changing theme - like selecting custom theme with user variable or cookie.

http://wiki.moxiecode.com/examples/tinymce/installation_example_21.php

Custom buttons might be usefull for other purposes too - like switching from one "mode" to another (for example to show mathematics as equation with filter or as code in editor) or to add some pre-customized content (helper functions to build forms etc).

I checked that Wordpress button and the code for kitchenSink-button is one part of Wordpress spesific code in plugin called wordpress - and it uses cookie and custom editor setting wordpress_adv_hidden to show and hide the extra toolbar. It's not the only customized button if you look closer and extra keyboard shortcuts are defined in that same plugin. Thanks for the nice example, Matt!