http://moodle.org/mod/forum/discuss.php?d=99001#p438263

1) First round of checking the code in HEAD done and I am ready to sink into the ground - now also editor theme standard is gone so in practice there is nothing left of my several weeks of testing. Most of the default configuration I had done was in that theme to avoid overwriting previous files in upgrading, to keep tinymce doing the same things as htmlarea and to be able to add extra features to moodle without modifying the code of tinymce itself. The main idea in TinyMCE themes is that theme (usually advanced) has all default settings in file editor_template.js and external configuration is used only if necessary. If we use only advanced theme we are tied to functions there - I thought we needed to create a "moodle specific editor theme" - standard - that can be modified to look like moodle and not to use the prototype advanced theme of Moxiecode. Basic code of theme standard is exactly the same code as in theme advanced - you just need to use word standard in init code instead of advanced. Skins can be used for setting colors, fonts etc css but themes are a larger set of code in tinymce.

2) contextmenu should be used with advanced theme and standardmenu (modified settings for shortcut keys/accessibility and right mouse click menus) only with standard theme that does not exist anymore.

3) There's also some confusion in init code: Imagemanager,filemanager vs moodleimage and moodlelink by Glen, still course files are not used at all. Have you done a new filemanager plugin, Mathieu?

4) xhtml_ruleset.txt - we should be able to select if we want to use it or not because media plugin does not allow embedding media with full xhtml rule set

5) Role based settings - for example students should probably not have media button but teachers need access to course files - the reason why I used separate init code for students and teachers - selection of code can be made with capability checking. Without these file/imagemanager (moodleimage), links (moodlelink), anchors and embedding media are "torso". Teachers need the correct button (plugin that gives access to course files) to be able to add course files inside content.

There are two small bugs in Glen's moodlelink plugin but they are easy to fix. First the plugin has two browse buttons and second the close button is not using correct function and does not work so here's the fix:

In lib/editor/tinymce/jscripts/tiny_mce/plugins/moodlelink/link.php

this function from rows 47-51 can be deleted:

function onCancel() {
window.close();
return false;
}

and change row 145

<button type="button" name="close" onclick="return onCancel();"><?php print_string("close","editor");?></button>

to

<button type="button" name="close" onclick="tinyMCEPopup.close();"><?php print_string("close","editor");?></button>

Delete lines 169-170 (extra browse button)

<input name="save" type="submit" id="save" onclick="return checkvalue('userfile','uploader');" value="Browse" />

Because standard theme is not used you could change in init code words "standardmenu" (in plugins rows) to word "contextmenu". Although I used it also for accessibility and keyboard shortcuts we can add those functionalities without theme as well.

If contextmenu (or some other corresponding plugin) is not used in plugins we do not get right click menus in tinymce at all.

For fckeditor you should be able to send $course->id as a variable to integration file and the integration file should be able to send $course->id to fckeditor filemanager connector ( ?id=<?php echo $COURSE->id; ?> ) to get course files instead of site files. That's exactly the reason why I suspected that using core javascript integration files of fckeditor may be impossible or at least difficult without any changes to core files ( and made the custom php integration files separately for students and teachers in fckeditor integration...)

Have you thought about the capability checking - in htmlarea check of capability to manage files was included to htmlarea.php but the OU approach was to keep core editor files untouched so capability checking should most likely be in the integration files or lib files but it should be somewhere.

One big thing is also CSS. We can use skins or we can use custom css files / css included to themes of moodle. Most people who have used htmlarea will notice that default fonts are much smaller in tinymce and fckeditor than in htmlarea and Xinha. The easiest way is to edit skins and use some custom skin instead of o7k7 or default skin.

Glen's plugin has capability checking code but students and teachers do not have permission to manage site files ( id = 1 ) so current configuration allows only administrators to use site files in tinymce and nobody can use other course files because $course->id is not correct. Teachers and students get the unfunctional connector link image anyway, students should not see the image at all and the init code for students should not have tags like

file_browser_callback : "moodlefilemanager",