The most important decision on editor integration

The most important decision on editor integration

by Mauno Korpelainen -
Number of replies: 99

After some weeks of testing with TinyMCE, FCKEditor and Xinha I am sure that any one of them really can replace htmlarea in a fully functional way. Just tested Xinha again and it can even use the same editor functions as htmlarea - basicly you only need to copy all files of latest Xinha to the same folder as htmlarea and create a proper combination of files XinhaCore.js and htmlarea.php and save the result as htmlarea.php (image & link plugins need to use plugin structure of Xinha if possible...)

But... TinyMCE,FCKEditor and Xinha are ALL great editors with some unique features. The only difference between one-editor-system and selectable editor system is that we need to have different files for integration and administration of each editor (only Xinha can use the same configuration as htmlarea - yet htmlarea has less buttons and plugins than Xinha. What I would like to do is to change editor control in administration menu as much as possible "editor independent" and to change main part of editor style administration to theme files and editor files. It would give free hands to develop different versions of editor - role based, activity based, theme based or even user based editors. It would make changing default editor easier - any time. It would make testing new features easier...

All the previous moodle hacks of htmlarea are possible to use in other editors - editable smiley list, hiding buttons, toggling editor... - with small changes to editor code. Upgrading of editor files to latest versions is also possible without overriding any settings or any editor integration files. 

Why should we actually remain one-editor-system???

Martin, Mathieu?

Average of ratings: Useful (1)
In reply to Mauno Korpelainen

Re: The most important decision on editor integration

by Eloy Lafuente (stronk7) -
Picture of Core developers Picture of Documentation writers Picture of Moodle HQ Picture of Peer reviewers Picture of Plugin developers Picture of Testers
Hi Mauno,

first of all I want to say THANKS by the amazing job you are doing with all those editors. cool cool

If I'm not wrong, the decision was to bundle Moodle with only one "official" editor (I guess the best) but to leave the system ready for potential changes in the future (i.e. editors won't be pluggable, in the sense of having multiple working together, but replaceable, by another one).

That will force all editors to be auto-contained and will force Moodle to have a standard way to handle editors, while avoiding the proliferation of different editors working together.

Of course, that "replaceable" editor, can be replaced easily by admins, it's a matter of feelings or personal/institutional needs, as long as the editor fullfill all the reqs to play with Moodle. Or also developers will work on their own editor just replacing the "official" one.

But only one will be the present in official distros AFAIDMAITLDM*

* AFAIDMAINDM: As far as I didn't miss anything in the last Developer Meeting. (be noted it's highly possible I misunderstood something, sincerely!)

Ciao smile
Average of ratings: -
In reply to Mauno Korpelainen

Re: The most important decision on editor integration

by Mathieu Petit-Clair -
Picture of Core developers Picture of Moodle HQ Picture of MoodleCloud team Picture of Plugin developers Picture of Testers
Mauno,

I think that's a good analysis of the situation. I agree that making it possible to use many editors would be great. Giving choice is good (though they're all pretty much equivalent, afaict), but making the code separated enough to make this possible would indeed be a good thing: it makes testing, upgrades, and other future changes easier.

It might be less work than I thought at first, but I still think this would involved significant changes. I'm probably missing stuff, but as a start, I see we would need hooks for smileys, button/feature choice, spellchecker (?), styles (wouldn't it be nice to be able to remove the font choice and use only css-specified styles?)... What else?

Obviously, as Eloy says, we should choose one to bundle in the official download (I feel, and I think others too, that TinyMCE is a good choice for this). Anything else should be in contrib.

I'll think about this today and try to talk about it with Martin..

Average of ratings: -
In reply to Mathieu Petit-Clair

Re: The most important decision on editor integration

by Mauno Korpelainen -

I have both choices available - stable default editor and totally flexible selection system - the difference is where you put functions print_textarea and use_htmlarea and how you configure editor (from separate init files depending on editor or editor profile or from lib files). It just needs one variable ($user->htmleditor) to hold editor selector, 0=no editor, 1=default editor, 2=second editor, 3=third editor... and you really need only 0 and 1 if there is only one editor available.

The functions need to behave differently according to each editor. List of moodle smilies is taken from database, hidden buttons are taken from database ($cfg->editorhidebuttons)...no problem. Spellchecker must be configured separately. In tinymce default spellchecker is Google spellchecking service and it works nicely on my test server - and you may add languages from the list of languages available in google. I would like to get that font selection from administration to themes as well because editors may have different skins and it is not sensible to have white background for all skins if editor skin itself is not normal light style. CSS-specific styles - YES!

I am right now writing again my integration for Xinha - TinyMCE integration is already 99.9% functional. I have not had time for FCKEditor so far but I have read documentation and I am going to test it more after Xinha tests.

I really like TinyMCE most and would love to see it as the default editor 1 but it is "relatively easy" to get other editors available too. Toggle button is missing from TinyMCE so I built my own one and created two plugins for moodle specific changes (lang menu & keyboard shortcuts) + different editor theme (named it "standard") to avoid overwriting integration files when upgrading tinymce. I think I can write all code needed for a working selectable single/multi-editor integration but I need your help on testing and writing those patches.wink

Average of ratings: Useful (1)
In reply to Mauno Korpelainen

Re: The most important decision on editor integration

by Mauno Korpelainen -

I must add something here: I have used now a couple of hours in combining the code of htmlarea.php and XinhaCore.js and that really works. I had to change a couple of rows in image plugin code too but all settings of htmlarea work in Xinha - multi lang menu was in about 10 different pieces around htmlarea.php but computers are amazing...

The best thing is that this latest nightly Xinha does work in Opera and Safari too and has a lot of plugins that htmlarea does not have...big grin

Average of ratings: Useful (1)
In reply to Mauno Korpelainen

Re: The most important decision on editor integration

by Marc Grober -
I just posted a similar query elsewhere... If moodle is going to support multiple editors, and even multiple editors at th same time for different users, wouldn't it make sense for plugins to have a location in the directory structure that was independent of the particular editor, as in /lib/editor/plugins as opposed to /lib/editor/tineMCE/plugins?

Personally I am also curious as to whether the version og Xinha that included asciimathml will still work...
Average of ratings: Useful (1)
In reply to Marc Grober

Re: The most important decision on editor integration

by Mathieu Petit-Clair -
Picture of Core developers Picture of Moodle HQ Picture of MoodleCloud team Picture of Plugin developers Picture of Testers
I don't think we'll get to multiple editors on the same site anytime soon, and certainly not for the same user...

I think the discussion is more about making it possible for an admin to choose which editor a site should use. You only get one editor on a site.

Are there many plugins that are compatible with many editors? (That's new to me, so I never thought about it...)
Average of ratings: -
In reply to Marc Grober

Re: The most important decision on editor integration

by Mauno Korpelainen -
Mathieu is right - editors can't use plugins from other editor - but you can always create a similar plugin like dragmath to all editors and you can probably set the location of dragmath files to be the same (it does not have to be inside plugin files). I think Xinha's asciimathml plugin is still working - tested it quickly about two weeks ago - I could test it again today...
Average of ratings: Useful (1)
In reply to Marc Grober

Re: The most important decision on editor integration

by Mauno Korpelainen -

That Xinha plugin is called "Equation" and it works ok.

Attachment Equation.gif
Average of ratings: Useful (1)
In reply to Mauno Korpelainen

Re: The most important decision on editor integration

by Mauno Korpelainen -

Marc G., ASCII MATH plugin Equation included to this package - change theme/standard/meta.php to this code:

<script type="text/javascript">
_editor_skin = "xp-blue"; // If you want use a skin, add the name (of the folder) here
_editor_lang = "en"; // And the language we need to use in the editor.
var mathcolor = "black"; // You may change the color the formulae are displayed (default: red)
var mathfontfamily = "Arial"; //and the font (default: serif, which is good I think)
</script>
<script type="text/javascript" src="<?php echo $CFG->httpswwwroot ?>/lib/editor/htmlarea/plugins/Equation/ASCIIMathML.js"></script>
<!--[if IE 7]>
<link rel="stylesheet" type="text/css" href="<?php echo $CFG->httpsthemewww ?>/standard/styles_ie7.css" />
<![endif]-->
<!--[if IE 6]>
<link rel="stylesheet" type="text/css" href="<?php echo $CFG->httpsthemewww ?>/standard/styles_ie6.css" />
<![endif]-->

Average of ratings: Useful (1)
In reply to Marc Grober

Re: The most important decision on editor integration

by Mauno Korpelainen -
I just added also Dragmath to Xinha - Thank you Marc, John, Alex and Chris for the integration of Dragmath to moodle and htmlarea, it was really easy to add it to Xinha with your guidelines. It looks like I am getting Xinha package first ready - and the full package will be ready soon.wink
Average of ratings: Useful (1)
In reply to Mauno Korpelainen

Re: The most important decision on editor integration

by Mauno Korpelainen -

Before final steps of making that selection package I would appreciate if somebody could test Xinha on https server - and why not on any TEST SERVER... with a package that is simply installed over files of htmlarea. It should do all tricks that htmlarea does and a little more - keyboard shortcuts are not all yet defined.

If you find any strange behaviour let me know. There is one page and one field - front page description - that has problems with all other editors than htmlarea. Other pages seem to render Xinha ok. You may also test Xinha in http://korpelainen.net/xinhatest with username/password teacher/teacher or student/student . I will give more advice about customizing Xinha later.

To totally replace HtmlArea with Xinha unzip this package over files of htmlarea - all files should go to folder lib/editor/htmlarea/

If you want to use some custom skin open file meta.php with a text-editor from theme/standard (or your custom theme) and add for example the following code to the beginning of code of meta.php:

<script type="text/javascript">
_editor_skin = "xp-blue";
</script>

Skins blue-look, blue-metallic, green-look, inditreuse, silva, titan, xp-blue and xp-green are in folder lib/editor/htmlarea/skins.

If you want to let Opera and Safari to use editor edit file lib/moodlelib.php and change function can_use_html_editor() to either to proper browser check for the latest versions of Opera and Safari

 - code is here -

or if you want to check if some previous versions of Opera or Safari (or other browsers) could also work try short code (no browser check at all)

 - code is here

Average of ratings: Useful (1)
In reply to Mauno Korpelainen

Re: The most important decision on editor integration

by Mauno Korpelainen -

Note however that Xinha has a couple of more buttons than htmlArea and this package does not change any lib files so for example message window is too small for Xinha. For a perfect result we need to edit some other files too like lib/adminlib.php, lib/weblib.php, message/send.php, message/discussion.php, user/editlib.php and lang files + images.

It is also possible to make xinha look the same as htmlarea with skin. Right now icons of editor are taken from one sprite image (attached)

Current integration of Xinha is WORSE than my coming integration of TinyMCE because Xinha can't be integrated by simply upgrading files of Xinha - file htmlarea.php has all moodle hacks and it is a combination of Xinhacore.js and htmlarea.php of htmlarea. For TinyMCE all files can be upgraded when new versions are published.

Attachment ed_buttons_main.gif
Average of ratings: Useful (1)
In reply to Mauno Korpelainen

Re: The most important decision on editor integration

by Mauno Korpelainen -
Small steps forward every day - I can compress the package of xinha to about 20% of original size with small cleaning of code and unnecessary plugins (that can be included later if needed). Selection of editor code is working ok now and during this week I should test FCKEditor to get the full package of HtmlArea, TinyMCE, Xinha and FCKEditor ready for public testing.
Average of ratings: Useful (1)
In reply to Mauno Korpelainen

Re: The most important decision on editor integration

by Mauno Korpelainen -

You may now download the latest weekly moodle 1.9 with htmlArea, TinyMCE and Xinha for testing from http://korpelainen.net/weekly19.zip

I have tested fresh install and upgrading but you must be aware that if you upgrade this package with normal package from moodle.org many changes get lost. The main changes are:

- moved functions print_textarea, use_htmlarea and print_editor_config from weblib.php to separate files in lib/editor/0-4
- changed function can_use_html_editor in moodlelib.php to allow Safari and Opera to use editor (latest versions)
- changed function use_html_editor to new function use_admin_editor for files admin/upgradesettings.php, admin/settings.php, admin/roles/manage.php, message/discussion.php and message/send.php because these pages have a special way to render editor. Admin editor and message editor are now also configurable.
- added some strings to lang/en_utf8/editor.php
- In mod/forum/post.php replaced twice $post->message = ''; with $post->message    = ' ';
for tinymce - Glen has used tinyMCE.triggerSave(); in lib/formslib.php but it causes errors to other editors.
- In adminlib.php changed

/**
 * Special text editor for site description.
 */
class admin_setting_special_frontpagedesc extends admin_setting {
    function admin_setting_special_frontpagedesc() {
        parent::admin_setting('summary', get_string('frontpagedescription'), get_string('frontpagedescriptionhelp'), NULL);
    }

to

/**
 * Special text editor for site description.
 */
class admin_setting_special_frontpagedesc extends admin_setting {
    function admin_setting_special_frontpagedesc() {
        parent::admin_setting('summary', get_string('frontpagedescription'), get_string('frontpagedescriptionhelp'), ‘moodle’);
    }

just for upgrading (get blank page otherwise)

Editor can be selected from user profile but I did not include different administration (adminlib.php) for each editor because I am not sure which is better - to have same administration settings (hidden buttons etc) or different administration settings for each editor. Both are possible but this version is still using htmlarea defaults.

If you want to change things you may look at subfolders 0-4 inside folder lib/editor for init code and for tinymce main settings are in lib/editor/tinymce/jscripts/tiny_mce/themes/standard/editor_template.js (editor_template_src.js is more readable version of same file and editor_template.js is compressed version). For Xinha most settings are in lib/editor/xinha/htmlarea.php and lib/editor/xinha/asciiarea.php for asciimathml version.

If you have a custom theme and in theme config.php $THEME->standardmetainclude = false;
you need to add the following code to theme meta.php


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

And I played a lot with asciimathml plugin Equartion but there is some preview problem between the latest version of ASCIIMathML.js and dialog.html for that plugin so I kept the old version and continue testing later with tinymce too. Dragmath is included to TinyMCE and Xinha but not to htmlarea (I did not make any changes to htmlarea itself)

Average of ratings: Useful (1)
In reply to Mauno Korpelainen

Re: The most important decision on editor integration

by Mauno Korpelainen -

And of course I forgot the super glorious toggle button for tinymce - originally I had it in function print_textarea attached content

Toggle button


I will update this to lib/editor/2/meta.php and lib/editor/2/messages.php
Also size and buttons of message window should be checked.

Average of ratings: Useful (1)
In reply to Mauno Korpelainen

Re: The most important decision on editor integration

by Mauno Korpelainen -
Sorry for cross-posting but attached a short patch file. While doing this patch I noticed one missing thing in message editor and updated files message/discussion.php and message/send.php to my test server.
 
In addition to these changes to files of moodle I have of course written tons of code for those files that do not currently exist in moodle and added new files to tinymce and xinha folders - the actual integration files of tinymce (editor theme "standard") and Xinha .
Average of ratings: Useful (1)
In reply to Mauno Korpelainen

Re: The most important decision on editor integration

by Nicolas Sicard -
Hi Mauno,

I tested your latest testing package. Great work ! Hope it will be intergrated in core Moodle as soon as possible !

It is especially usefull when using Safari ! wink

I have still some problems with fixed size 1024px themes. It doesn't look good when all toolbar icons are displayed because there isn't enough horizontal space on two lines. Is there a way to force toolbar to be dislpayed on three lines instead of two when necessary ?

Thanks again.

Nicolas.

Average of ratings: Useful (1)
In reply to Nicolas Sicard

Re: The most important decision on editor integration

by Mauno Korpelainen -

It is possible to create a "toolbar switcher" / "skin switcher" - I will update the test package step by step (next time after a week or two) and Mathieu will do the core integration probably first for one editor system (TinyMCE) but hopefully for full selection system too.

Can you attach a screenshot about the problem? I have not used any administration/configuration settings for this package but they will be added pretty soon. I have used the last week for testing fckeditor and spaw2 (looks almost the same as yuirte) and math editors and next week I will try to test TinyMCE again (language and skin selection + administration)

Average of ratings: Useful (1)
In reply to Nicolas Sicard

Re: The most important decision on editor integration

by Mauno Korpelainen -

In fact the original idea was to make editors totally configurable and one benefit of theme based editors is that by setting in custom theme config.php

$THEME->standardmetainclude = false;

and pasting to custom theme meta.php something else than

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

you could create totally different configuration for all editors for that custom theme. For example in folder lib/editor/2/ are currently tinymce init files and if you copy those files to for example $CFG->dirroot.'/somefolder'

you may simply copy 3 line code from adminsrc.php to staff.php:

plugins : "safari,spellchecker,table,style,layer,advhr,advimage,advlink,emotions,emoticons,inlinepopups,media,searchreplace,paste,standardmenu,directionality,fullscreen,moodleimage,moodlelink,dragmath,nonbreaking",
theme_standard_buttons1 : "fontselect,fontsizeselect,formatselect,|",
theme_standard_buttons1_add : "styleselect,selectall,pastetext,pasteword,insertlayer",
theme_standard_buttons2 : "bold,italic,underline,strikethrough,justifyleft,justifycenter,justifyright,justifyfull,sub,sup,undo,redo,cleanup,removeformat,code,|",
theme_standard_buttons2_add : "styleprops,ltr,rtl,table,nonbreaking",
theme_standard_buttons3 : "bullist,numlist,outdent,indent,forecolor,backcolor,link,unlink,anchor,image,charmap,|",
theme_standard_buttons3_add : "media,emotions,emoticons,charmap,dragmath,spellchecker,search,code,fullscreen",

instead of current

plugins : "safari,spellchecker,table,style,layer,advhr,advimage,advlink,emotions,emoticons,inlinepopups,media,searchreplace,paste,standardmenu,directionality,fullscreen,moodleimage,moodlelink,dragmath,nonbreaking",
theme_standard_buttons1_add : "styleselect,selectall,pastetext,pasteword,insertlayer",
theme_standard_buttons2_add : "styleprops,ltr,rtl,table,nonbreaking,media,advhr,emotions,emoticons,charmap,dragmath,spellchecker,search,code,fullscreen",

All settings are first defined in editor configuration and they can be overdriven by editor theme settings and site theme settings. I am planning to write an admin module or plugin for tinymce where most settings could be changed the same way as in plugin style you may give different css styles without any knowledge of css - with selection boxes and lists. The current package is using only one user setting - $USER->htmleditor that selects the editor but this one variable could as well hold a larger editor profile for each user as a string of settings that can be exploded or imploded - or id of editor profile instead of id of editor.

I will write some documention about editor settings when most settings have been fully tested

Average of ratings: Useful (1)
In reply to Nicolas Sicard

Re: The most important decision on editor integration

by Mauno Korpelainen -

There is also an easy css fix for this - I tested a fixed width theme college_blue.

Change in standard theme styles_layout.css or in custom theme css file

.mform div.fhtmleditor {
  margin: 0 auto 10px auto;
  width : 600px;
  clear:both;
  float:none;
  padding: 25px 0 20px 0;
}

to

.mform div.fhtmleditor {
  margin: 0 30px 10px 30px;
  width : 600px;
  clear:both;
  float:none;
  padding: 25px 0 20px 0;
}

Attachment fixtheme.gif
Average of ratings: Useful (1)
In reply to Mauno Korpelainen

Re: The most important decision on editor integration

by Nicolas Sicard -

I get this, even after the CSS change


I'll try configuring the editor tomorrow.

Thanks
Attachment Image_2.png
Average of ratings: Useful (1)
In reply to Nicolas Sicard

Re: The most important decision on editor integration

by Nicolas Sicard -

Well, it seems it comes from my theme, because other fixed size theme are doing fine...


Average of ratings: Useful (1)
In reply to Nicolas Sicard

Re: The most important decision on editor integration

by Mauno Korpelainen -

If there are some (common) css tags in theme that override editor css things like this may happen. So

- we need to check that editor theme css has no conflicts with css of moodle or moodle themes

- moodle already has the editorhidebuttons setting but this package is using only settings of htmlarea. I will probably implement the option to show/hide buttons separately for each editor(profile) - meaning that each editor must have different administration file/settings. The other choice is that we have common settings for all editors.

- we need different type of editors for different needs and therefore themes, editor themes, editor skins and editor skin variants are useful. We can for example set a block to use "mini editor" with smaller buttons in 4 rows or use a toolbar selector where user gets first a simple row of buttons and toolbar can be expanded to show advanced buttons with one button click (rows 2-4). I have also tested a kids style editor with less buttons but the buttons are three times bigger that normal editor buttons and have different icons.

All css and code of editors - especially in tinymce - can be modified to work nicely with moodle. It will however take some time to create the administration of all buttons, plugins, skins, languages  etc.

Average of ratings: Useful (1)
In reply to Mauno Korpelainen

Re: The most important decision on editor integration

by Nicolas Sicard -
Ok, I finally fixed my problem cool My layout css needed some cleaning...

- moodle already has the editorhidebuttons setting but this package is using only settings of htmlarea. I will probably implement the option to show/hide buttons separately for each editor(profile) - meaning that each editor must have different administration file/settings. The other choice is that we have common settings for all editors.

The way I see it is to have a common settings pane for all editors containing the basic features and a specific one for the choosen editor.

- we need different type of editors for different needs and therefore themes, editor themes, editor skins and editor skin variants are useful. We can for example set a block to use "mini editor" with smaller buttons in 4 rows or use a toolbar selector where user gets first a simple row of buttons and toolbar can be expanded to show advanced buttons with one button click (rows 2-4). I have also tested a kids style editor with less buttons but the buttons are three times bigger that normal editor buttons and have different icons.

Well, an ajaxed interface where admin can drag and drop and rearrange buttons on a toolbar would be great... ;)
Average of ratings: Useful (1)
In reply to Nicolas Sicard

Re: The most important decision on editor integration

by Mauno Korpelainen -

Fckeditor is now in control too and file/image manager is reading correct folders. The biggest obstacle for free integration of editor with a possiblility to select htmlarea, tinymce, xinha, fckeditor or any other editor is language files = translation of editor language files and administration of settings.

I'm afraid I don't have enough knowledge to write that ajax drag and drop interface yet (maybe later) but I might be able to build a prototype of editor profile selector with some buttons, lists and choices (selection of editor, skin, hidden buttons depending on editor etc). It is easier to write different settings for each editor but the structure of settings could be from most parts similar. For translation I have tested using developing version of tinymce with separate class files and for fckeditor I can already define all settings through php integration file - next step is to study if it is possible to use lang files like tinymce.php, fckeditor.php, xinha.php to handle translation of different editor menus and plugins.

Average of ratings: Useful (1)
In reply to Mauno Korpelainen

Re: The most important decision on editor integration

by Nicolas Sicard -
Impressive work ! HTML editor is one of our biggest complaint, can't wait to use it on my production server... ;)

I tried your xinhatest integration files too. Works great. I like this solution for a quick way to change from htmlarea. The main drawback I saw (but maybe does it come from xinha) was a certain latency for the editor to load on top of html forms, comparing to htmlarea. Did you make the same package for tinymce ?

Concerning translation, I too would think that the most elegant solution should be using lang files for the different editor menus and plugins as any administrator would be able to custom as he needs through the language file edition form.
Average of ratings: Useful (1)
In reply to Nicolas Sicard

Re: The most important decision on editor integration

by Mauno Korpelainen -
This first xinha integration was a "raw version" with lots of comments and unnecessary code. Tinymce is using compressed javascript files (like the coming xinha package) and when I get the package II ready (hopefully next week) you may see some differencies wink (mostly tiny ones)
Average of ratings: Useful (1)
In reply to Mauno Korpelainen

Re: The most important decision on editor integration

by Mauno Korpelainen -

And now also moodle language files are working. It was finally easier than I thought and no changes to original files were needed which means that files can be upgraded any time. I simply added a new language "all" with empty language files and added all language strings to one language file lang.php that calls translations for current language from files lang/en_utf8/tinymce.php, lang/en_utf_8/fckeditor.php etc. This lang.php is included through theme as all previous settings.

I haven't yet translated editor strings for all languages...big grin

The only "big thing" missing is separated administration of settings - and it is not too hard to create. I believe this full package is getting "ready" sooner than I expected.

Average of ratings: Useful (1)
In reply to Mauno Korpelainen

Re: The most important decision on editor integration

by Nicolas Sicard -
I haven't yet translated editor strings for all languages...big grin

Well, if you need help for the french translation, I'm ready ! cool
Average of ratings: Useful (1)
In reply to Nicolas Sicard

Re: The most important decision on editor integration

by Mauno Korpelainen -

I might copy most strings from editor language files to moodle language files for some of 78 current languages of moodle and others might update most translations later (when I get the package out...)

Average of ratings: Useful (1)
In reply to Mauno Korpelainen

Re: The most important decision on editor integration

by Mauno Korpelainen -

Editor package II is getting ready for testing on Thursday and I have included a lot of new things, for example:

- FCKEditor with it's own file/image manager connector using course files of moodle (many people have asked about this. I tested also Ajax Filemanager with online image editor but did not integrate it yet).

- Experimental FCKEditor Image map plugin, you may check a demo page of this plugin here: http://martinezdelizarrondo.com/imagemaps/

Image map

- Language file for tinymce (not complete yet), tinymce can be translated to all languages of moodle

Language

- Tested kids style theme for tinymce but did not include it yet, maybe to next package...

- Dragmath included to htmlarea, xinha and tinymce - not yet in fckeditor...

- Changed a couple of things in init code and clicked thousands of times different buttons of different editors. big grin

There are also some new buttons and tabs (compared to htmlarea) particularly in tinymce that are very usefull:

Tinymce

Average of ratings: Useful (1)
In reply to Mauno Korpelainen

Re: The most important decision on editor integration

by Marc Grober -
Super! Does this version contain the EqEd functionality for tinyMCE?

Average of ratings: Useful (1)
In reply to Marc Grober

Re: The most important decision on editor integration

by Mauno Korpelainen -
It's on the waiting list. All editors are now using common Dragmath files - I placed Dragmath to folder /lib/editor/common as well as asciimathml.js so that all editors can use the same files - but the location of files can be changed if necessary.
Average of ratings: Useful (1)
In reply to Mauno Korpelainen

Re: The most important decision on editor integration

by Mauno Korpelainen -

Here we go...package II or actually two large editor packages are now "ready" for downloading and testing on my test server.

The latest moodle 1.9.1 weekly package with modified htmlarea (1), tinymce (2), xinha(3), fckeditor(4) and as an extra feature for Marc xinha with asciimathml equation plugin(5) is now in http://korpelainen.net/weekly19.zip

and the same package with Nwiki in http://korpelainen.net/weekly19nwiki.zip

The standard weekly 1.9 zip package is about 2-3 Mb larger with all these extra files.

Why Nwiki? Because old wiki has some problems with editors but Nwiki seems to work fine with all modern browsers. I have tested TinyMCE, FCKEditor and Xinha with different versions of IE, FF, Opera 9.50 and Safari 3.1.1 and all those editors seem to work without any major bugs.

I tested both normal upgrading & fresh install and upgrading with non standard modules and had no errors in 5 different test installs. You may also visit http://korpelainen.net/test19  with usernames and passwords

teacher1 - teacher1 (tinymce)

teacher2 - teacher2 (fckeditor)

teacher3 - teacher3 (xinha)

teacher4 - teacher4 (xinha with asciimathml)

I will keep this test site open for some days - not longer... There are still lots of things on the waiting list - perhaps administration and more flexible configuration is ready after next two weeks...wink

FCKEditor is also missing a couple of "moodle functionalities" that do work in TinyMCE and Xinha. Patch is almost similar as before - I will try to write it during the next days.

Average of ratings: -
In reply to Mauno Korpelainen

Re: The most important decision on editor integration

by Mauno Korpelainen -

Starting the bug report - TinyMCE media plugin seems to strip tags but I don't know yet if it is my fault (for example full xhtml rule set?)

FCKEditor flash plugin seems to work ok.

Average of ratings: -
In reply to Mauno Korpelainen

Re: The most important decision on editor integration

by Mauno Korpelainen -

Well, now I know. It is not a bug, full XHTML rule set of tinymce http://wiki.moxiecode.com/index.php/TinyMCE:Configuration/valid_elements#Full_XHTML_rule_set: strips flash tags so either we can use valid xhtml or take away (or "lighten") full rule set to be able to use all features of embedded objects.

Taking away

<?php include_once($CFG->dirroot.'/lib/editor/common/fullrule.php'); ?>

from integration files of tinymce in folder lib/editor/2/ takes away full xhtml rule set. If no valid elements are defined tinymce uses default rule set.

Average of ratings: -
In reply to Mauno Korpelainen

Re: The most important decision on editor integration

by Mauno Korpelainen -
Attached a short version of patch with explanations.
Average of ratings: -
In reply to Mauno Korpelainen

Re: The most important decision on editor integration

by Mauno Korpelainen -

One more note:

Because htmlarea is still default editor of moodle and if editor has not been changed from user profile Safari will give an alert message in htmlarea that comes from htmlarea.php browser check.

Changing these lines in htmlarea.php:

HTMLArea.checkSupportedBrowser = function() {
if (HTMLArea.is_gecko) {
if (navigator.productSub < 20021201) {
alert("You need at least Mozilla-1.3 Alpha.\n" +
"Sorry, your Gecko is not supported.");
return false;
}
if (navigator.productSub < 20030210) {
alert("Mozilla < 1.3 Beta is not supported!\n" +
"I'll try, though, but it might not work.");
}
}
if(HTMLArea.is_safari) {
return false;
}
return HTMLArea.is_gecko || HTMLArea.is_ie;
};

to

HTMLArea.checkSupportedBrowser = function() {
if (HTMLArea.is_gecko) {
if (navigator.productSub < 20021201) {
alert("You need at least Mozilla-1.3 Alpha.\n" +
"Sorry, your Gecko is not supported.");
return false;
}
if (navigator.productSub < 20030210) {
}
}
if(HTMLArea.is_safari) {
return false;
}
return HTMLArea.is_gecko || HTMLArea.is_ie;
};

leaves the unnecessary message away - htmlarea shows still only textarea.

I will update this later to packages but you may change these lines directly to htmlarea.php if you have already installed the package.

Would it be better to change default editor to be tinymce?

Attachment select.gif
Average of ratings: -
In reply to Mauno Korpelainen

Re: The most important decision on editor integration

by Mauno Korpelainen -

In http://moodle.org/mod/forum/discuss.php?d=98134 John wanted to change default editor so here a quick way to do it.

If you have downloaded (and installed) the full test package download files from http://korpelainen.net/John.zip over folders lib/editor/2 and lib/editor/1 and user/editlib.php to change order of tinymce and htmlarea. Simple and tested. TinyMCE will be editor id 1 (default editor) and htmlarea will be editor id 2. I will still keep htmlarea as a default editor in the main package although it would be more logical to move htmlarea to number 5.wink

In future a better way could be to have a setting for selecting the default editor from available editors list.

Average of ratings: Useful (1)
In reply to Mauno Korpelainen

Re: The most important decision on editor integration

by Andrew Zaffke -
So I have been trying to test out these editors that you have been talking about for the last few days but the only success I have had is when I downloaded your Xinha zip file to overwrite the htmlarea folder.

I also am completely lost when trying to find how you made that editor selector that you seem to be using the the post this is a reply to.

Thanks
Average of ratings: -
In reply to Andrew Zaffke

Re: The most important decision on editor integration

by Mauno Korpelainen -

Xinha package replaces only editor files of htmlarea in folder lib/editor/htmlarea - nice that you tested it.

The package http://korpelainen.net/weekly19.zip is full moodle 1.9.1 generic package - not the latest one, I have not upgraded package this week, but last weeks weekly moodle 1.9.1. You don't need to add anything from patches - it's a ready to use package - but you make changes from patch to some other version of moodle if you like.

When you have installed that package or upgraded previous version of moodle click your name - edit profile - (Show advanced) - and from "When editing text" select the editor and Update profile. Done.

How did I make it? If you open file user/editlib.php you may find rows

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

that is the code that selects number 0...5 for variable $USER->htmleditor and translations are taken from language file editor.php (lang/en_utf8/editor.php)

The code in theme/standard/meta.php

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

selects the correct editor integration files with one exception - if you have custom theme that has  standardmetainclude = false you need to add the previous tags to your custom theme meta.php

Before you nobody has told that the weekly package would not work - can you give some more info...did you make some changes of your own and with what program?

Average of ratings: -
In reply to Mauno Korpelainen

Re: The most important decision on editor integration

by Marc Grober -
I went and tested teacher4 on your site and ran up against a conflict in reg. moodle or Nwiki.... while I expect asciimathml to parse both asciimathml and latex, in your site asciimathml is getting parsed correctly (in black) , but single dollar tokens have no effect and double dollar tokens provides a link to a tex pop-up that does not seem to be working in the reg moodle or Nwiki..... I did an insert in asciimathml and moodletex and the doubledollars are not being parsed correctly but are getting inserted correctly

I think asciimathml should not be used with other tex filter (duplicates effort if nothing else as asciimathml parses Latex
Average of ratings: -
In reply to Marc Grober

Re: The most important decision on editor integration

by Mauno Korpelainen -

Marc, I never thought that there could be such conflicts - this explains a lot.

Thank you again!

Average of ratings: -
In reply to Mauno Korpelainen

Re: The most important decision on editor integration

by Marc Grober -
In Test 19 I created a web resource with comment so you can see what is or is not working, though things seemed to change while I was working so I am wondering if you are playing with code while I am using ;=}

I went back into nwiki as it appears that asciimathml is working outside of wiki but not in wiki, so I assume course theme is an issue for Nwiki usage.

This is one reason I think issue of asciimathml as filter may be important.... because if there are people who insist they do not want asciimathml then how do we make it so it can be turned off..... at present we are talking about changing theme or fixing asciimathml so it behaves properly as a filter??
Average of ratings: -
In reply to Marc Grober

Re: The most important decision on editor integration

by Mauno Korpelainen -

I disabled ALGEBRA NOTATIONS filter and suddenly latex equations were visible again...thoughtful

Average of ratings: -
In reply to Mauno Korpelainen

Re: The most important decision on editor integration

by Marc Grober -
I figured you were playing while I was testing big grin Gee, speaking of editors, I only get half the smiley panel in moodle.org.... harrrummmmppphhhhh!

Well I have fiddled about with all the editors on your test site and will look at further experimentation once i am clear on how to use the weekly zips... need a little family time now.

I tried to leave details notes on your test site and highlight with postings to the forum.

I really think we should put the whole enchilada in a 1.9.x of some sort to have a larger audience beat up on things - versioning with moodle is still a bit confusing... but if there was a full cvs with your full editor code that would be nice. Have a good morning! I am off to dinner.


Average of ratings: -
In reply to Marc Grober

Re: The most important decision on editor integration

by Mauno Korpelainen -

We can use different smiley sets for each editor or use same smileys for all editors, we may use different plugins for each editor or try to convert plugins to do the same things at least for most plugins, for example dragmath. For small children all kind of "stamps" and "helper forms" are important - as a part of accessibility and for teachers different plugins may have more use. I like for example this image map plugin of fckeditor altghough it is not perfect because playing with images is so nice...

None of these integrations is 100% tested, bug free or has all features we need/hope but this editor system is getting better all the time.

Average of ratings: -
In reply to Mauno Korpelainen

Re: The most important decision on editor integration

by Marc Grober -
Warning WIll Robinson!
DragMath now allows us to put tokens in the export format as intended, so moodle integrations of editors that add dollar signs should no longer do that. The default dragmath export format is now moodletex, which adds doubledollars. The problem is most oblviously evidence when one sets the export format to ASCIIMathML, and then one sees a formula in backticks sourrounded by double dollars.... Please make sure Matthieu and others understand this....

I had tinyMCE balk on me a couple of times... it opended but would not respond further first attempt at changing topic, but eventually worked. It also balked on saving web page indicating a required field around the main text entry for the web page, but the red box seemed overlapped by the editor in part.... very strange... I just clicked merrily away and it finally agreed to save....

Big diff is that dragmath does not float free of window in tinyMCE.... this is unfortunate.

btw... was working with your site as was a bit unsure about your zips.... are they zips of full moodle install suitable for unzipping over existing 1.9? DO they need to be set up as new moodles... it wold be nice to cvs your changes over existing install.... ;=}


Average of ratings: -
In reply to Marc Grober

Re: The most important decision on editor integration

by Mauno Korpelainen -

Xinharepla was only htmlarea replacement but this weekly package is full moodle 1.9.1 (latest weekly package) with all editors and if you want to update xinharepla package to latest weekly editor test package you could rename or delete folder lib/editor/htmlarea where xinharepla files are and unzip all files of weekly package over your moodle files. Then also theme/standard/meta.php will be overwritten and asciimathml link is taken from lib/editor/5/meta.php where xinha with asciimathml is in weekly full package.

If you want to keep old moodle you could simply create new folder (for example editortest to webroot) and new moodledata folder (whatever name) + either new database or different prefix than your current moodle has in database. All the rest is controlled by settings of config.php

If you need to recover moodle without all editors you may simply delete folder lib/editor and extract latest moodle (standard package) over test package files. Editors do not change anything in database.

Average of ratings: -
In reply to Mauno Korpelainen

Re: The most important decision on editor integration

by Larry Elchuck -
Mauno:

Re: "If you need to recover moodle without all editors you may simply delete folder lib/editor and extract latest moodle (standard package) over test package files"

Is the reverse true as well?
If I currently have a CVS version of 1.9.1 running (with modes outside of the lib/editor folder), to add your editor enhancements, do I only need to replace the lib/editor folder?

Great work, by the way.

larry
Average of ratings: -
In reply to Larry Elchuck

Re: The most important decision on editor integration

by Mauno Korpelainen -

Well - basicly to use all the editors you need to replace files in folder lib/editor and make the changes mentioned in patch attachment. In package http://korpelainen.net/weekly19.zip all these changes have been done so you only need to download the package and drop either all files or the edited files over files of moodle 1.9.1 - BUT I do not guarantee that CVS version has the same files as this latest weekly generic package from http://download.moodle.org/ - CVS package may have some newer and upgraded files. I could make a similar package to any version of moodle but making those changes to several packages takes as much more time and this is a sort of hobby to me - not my work...

What I said about recovering is true with one exception - NWIKI. If you install Nwiki package you can't go back to old wiki so easily. Nwiki is included only to package http://korpelainen.net/weekly19nwiki.zip 

I add here the list of files outside lib/editor folder that have some modifications listed in the patch.txt file:

/admin/settings.php
/admin/upgradesettings.php
/admin/roles/manage.php
/lang/en_utf8/editor.php
/lib/adminlib.php
/mod/forum/post.php
/theme/standard/meta.php
/lib/moodlelib.php
/lib/weblib.php
/user/editlib.php
/user/view.php
/message/discussion.php
/message/index.php
/message/lib.php
/message/send.php
/mod/wiki/ewiki/ewiki.php

I have tested the package in several environments and have not seen any troubles in upgrading moodle 1.8 or moodle 1.9 but if you get any troubles because of this editor package I can promise a full support to solve the problems.

Average of ratings: -
In reply to Mauno Korpelainen

Re: The most important decision on editor integration

by Larry Elchuck -
Thanks, Mauno

I could incorporate your patch changes into my modded CVS build and they should not be impacted when I do my updates from the CVS server.

If your future changes only involve the editor folder, this could easily be swapped out, as the project evolves. Otherwise, is there a change log that you maintain on your site for changes made in your patch.txt file?

larry
Average of ratings: -
In reply to Larry Elchuck

Re: The most important decision on editor integration

by Mauno Korpelainen -

I will try to make the structure of integration so simple and "standard" that we could change editors and settings + upgrade moodle and editor files without extra work in parsing packages. If I find an easy way to use database or single file for editor profiles and configuration/administration of profiles instead of these files in folders 0-5 it can be possible within a couple of weeks.

I may not update my packages weekly (summer holidays just started here) but if I make any big changes they will be moved to new packages or patches and I will send some info here...

Mathieu is working on moodle 2.0 and if he gets a good solution for new default editor integration I can as well use that model and changes can be patched to moodle 1.9

Average of ratings: -
In reply to Larry Elchuck

Re: The most important decision on editor integration

by Marc Grober -
Mauno,

As soon as Mathieu and you can chat please think about using the CVS that was offered for this codeas that would make it much easier for folks to swap stuff in and out and check out the wonderful work you have been doing.... I know there is a bit of a hurdle on this (eclipse is still running me in circles) but I think it makes a lot of sense.
Average of ratings: -
In reply to Marc Grober

Re: The most important decision on editor integration

by Mauno Korpelainen -

There is still that tiny problem that I don't have  CVS access at my home PC (Windows Vista Home Premium) and I really should study how to use developer CVS, get that access etc ... or I could co-operate with you or Mathieu to make changes to CVS

Tomorrow I noticed that I had left to my latest package one line of code that you should remove. I have tested on my test site loading asciimathml through course theme and used theme/standardwhite/header.html and line:

<script type="text/javascript" src="<?php echo $CFG->httpswwwroot ?>/lib/editor/xinha/plugins/Equation/ASCIIMathML.js"></script>

for that. I took it off from the package now but some people have downloaded that version and could clean that row.

The conflict between asciimathml.js and tinymce is strange. I suspect that they have some common variable name because tinymce does not render editor without pressing toggle button if textarea has some latex code starting with single dollar expression $\ and asciimathml.js has been loaded.

I could try to modify/test asciimathml.js variable by variable to to find the reason - or try to use different way to render tinymce. FCKEditor and Xinha replace textarea with editor using different method.

Average of ratings: -
In reply to Mauno Korpelainen

Re: The most important decision on editor integration

by Mauno Korpelainen -

Marc,

attached (old fixed) version of Equation plugin does not use latex part of asciimathml.js at all and tex filter can be used for converting double dollar latex.

Do we need single dollar expressions in moodle?

Where do you get that version of Dragmath that has Moodletex as default? I downloaded the latest version of Dragmath from http://www.dragmath.bham.ac.uk/ and it has latex as default and it seems to insert double dollars around all expressions - also asciimathml. And does tex filter change 4 dollars to 2 dollars ? I was a little surprised when I took away dollars from Glen's tinymce plugin and file js/dragmath.js around mathExpression text and it did not change anything.

Third - should Dragmath insert \infty instead of ∞ to latex equations?

Average of ratings: -
In reply to Mauno Korpelainen

Re: The most important decision on editor integration

by Mauno Korpelainen -

Thanks for you email/message, Marc.

I restored the package version to my test site. Nice graphs! This eq version has only asciimathml code (from old xinha plugin) so it does not show grapics or convert latex. Better to continue on the basis of the latest asciimathml.js and try to get all features of it to talk with plugin and moodle.smile

Average of ratings: -
In reply to Mauno Korpelainen

Re: The most important decision on editor integration

by Marc Grober -
I just tried to look at this thread.... this needs to pruning if ever I saw a thread that is out of control ;=}

Not sure where we are.... I went to test19 and noted that the nwiki test is still there and did some additional tests and left a note. The initial tex graphic is rendered some third way (not asciimathml and not moodle tex filter I think...) as there is an object...

As far as priorities:
  • I think first priority is ensuring dragmath integration with all editors. This because it is a simpler issue than any with asciimathml.
  • Second I would like to make sure that we have a consistent way to implement asciimathml.js/d.svg as parsing/display utility. Do you see same type of behavior from jsMath if you put it in filter directory as you saw with asciimathml? In any event, while this is not necessarily a purely "editor" issue, it will help all the way around if it is addressed with editor implementation and is a complement to dragmath now. [not to mention that the ability to do this: agraph xmax=10; xmin=10; plot(y=1/2x+3) endagraph
  • Third: EqEd (equation editor). I think it great that this may have prospects now, but in some respects I look at this as a laboratory for what we may be able to do. As Peter Jipsen himself suggests, asciimathml is pretty simple to use, and, as I have pointed out, dragmath will now do asciimathml. However, the code (whether js or php) has I think the most promise for a fully integrated mathematics editor and included great option for extensibility
As far as the problem you mentioned in parsing dollar signs.... I am not sure what the issue is as the discussion has ranged so far and wide and I am not sure of context.... Are you talking about EqEd parsing the single $ in tinyMCE?

Average of ratings: -
In reply to Marc Grober

Re: The most important decision on editor integration

by Mauno Korpelainen -

Nwiki in test19 site had some problem when I tested different ways to render tinymce and changed code of files - I lost your examples for a while  - took them back from source code and so on. That "third way" must have been me. smile

Adding Dragmath to FCKEditor should be relatively easy. The behaviour of Tinymce when asciimathml.js was used is something I don't yet fully understand - it looked like tinymce had used some same functions as asciimathml.js and if I edited text with tinymce, asciimathml.js was on and textarea had latex tinymce started to translate latex to different form...or something like that. Without asciimathml.js and with tex filter tinymce has no problems and it does not change the code. In some cases tinymce refused to work without pressing toggle button so I tested different ways to wake up editor and finally took asciimathml.js away from header.html of course theme - intermission - ...

I believe this is a temporary problem - if some character in current integration is causing some javascript conflict I must only find the cause of conflict to be able to change the code.

Asciimathml itself with all those graphics and features is something unbelievable - if it just could work with all browsers wink

Average of ratings: -
In reply to Mauno Korpelainen

Re: The most important decision on editor integration

by Marc Grober -
I can run up additional examples, not an issue. Have piles of stuff.
If you want to put the tinyMCE with asciimathml in course theme I can beat it up again in resources and activities.... It looked really good to me when I did the edits with some minor complaints that were not editor related I think.

When looking at what is happening I suggest the following:
  • I use backticks for obvious asciimathml text first
  • Then I use dragmath to create a text expression using Latex.xml, moodleTex.xml and ASCIIMathML.xml. This gives me the latex expression without tokens, the Latex expression with double dollars, and an asciimathml expression in backticks, all from dragmath. The first is not parsed, the second is parsed by the tex filter and the third by asciimathml.
  • Then I take the doubledollars expression from above and copy it over with single dollars. This is the asciimathml interpretation of the Tex.
  • Then I pick a couple of asciimathml expressions and replace the backticks with the auto commands (amath...endamath) which will get parsed by asciimathml but will not likely cause any confusion with any other parsing of any other symbol.
As I recall I did most if not all of this in nWiki, and web resource on test19 without problems.
Average of ratings: -
In reply to Mauno Korpelainen

Re: The most important decision on editor integration

by Larry Elchuck -
Hi Mauno

I created a new htdocs folder of my CVS-based M19 folder (and I called this second iteration M19beta). It draws from the same db and moodledata folder as the existing M19 folder. I modified all files in the M19beta folder, as per the patch.txt file in M19beta and then applied the "John" version so that those testing the existing m19 build will get the original htmleditor by default and I can use tinymce for testing ... using htmleditor set to 1 in the common db config table.

It is working but in my tinymce version (M19beta), the language bits are not showing up for the variables.

tinymce pbm

Might I have missed something?

In addition the Xinha versions are not working for me .... but that is no big issue for me... I'm really only interested in tinymce at this point in time.

Also, how do I set the spell checker to the built-in version of aspell that works with the htmleditor?

thanks
larry
Average of ratings: -
In reply to Larry Elchuck

Re: The most important decision on editor integration

by Mauno Korpelainen -

Larry,

the missing file might be lang/en_utf8/tinymce.php

I could try to explain the basic structure of tinymce integration:

1) The latest version of tinymce (3.0.8) should be included + plugins standardmenu, moodleimage, moodlelink and dragmath.
2) My integration is using theme "standard" that should be in lib/editor/tinymce/jscripts/tiny_mce/themes. All basic configuration is actually there - not in theme advanced as usually in tinymce
3) To get languages translated I have added a new language "all" to language folders - for some plugins file all.js is the same as en.js - for most language tags file lib/editor/(x)/meta.php where (x) is the number of you tinymce folder - in normal package 2, in John's version 1 should have a line

<?php include_once($CFG->dirroot.'/lib/editor/common/tinylang.php'); ?>

and in file lib/editor/common/tinylang.php I have translation code for all tinymce language files - and strings should be found from lang/en_utf8/tinymce.php

Other languages than english can be translated from administration menu but they have not been translated yet. Tinymce should show english for non translated tags. It is also possible to use language files of tinymce and change language in init code from all to current language without _utf8 for some languages ( http://services.moxiecode.com/i18n/ ) but the goal was to get tinymce translated to any language of moodle.

4) to be continued.... 

If tinymce and fckeditor are working but xinhas are not it might have something to do with paths or https - Xinha is using a parsed version of old htmlarea.php and latest xinhacore.js

I could check if I have changed anything lately. Maybe I have forgotten something in patch.txt.

Average of ratings: -
In reply to Mauno Korpelainen

Re: The most important decision on editor integration

by Larry Elchuck -
Re: the missing file might be lang/en_utf8/tinymce.php

Hi Mauno

Adding this file to my lang/en_utf8 fixed my primary issue.

This added change/addition (and and any others not cited) could be added to your patch.txt.file.

I'll look into your other assistance later in the day

thanks so much.

larry



Average of ratings: -
In reply to Larry Elchuck

Re: The most important decision on editor integration

by Mauno Korpelainen -

I have attached two files with the same name - there is a short note about tinymce.php in the second version of patch.txt

I will check this spellchecker issue - Google spellchecker used to work before upgrading tinymce from 3.0.7 to 3.0.8 so I must have missed some path.

EDIT: I found the reason - it's in the plugin itself. I can fix it and send a new version when I have tested the plugin again. The plugin was changed to version 3.0.8 for a tiny security issue with rpc and without your post I would not have probably noticed it at all because I thought spellchecker was working ok as it did in tinymce 3.0.7.

Average of ratings: -
In reply to Mauno Korpelainen

Re: The most important decision on editor integration

by Mauno Korpelainen -

Larry,

unzip/move attached two files to folder lib/editor/tinymce/jscripts/tiny_mce/plugins/spellchecker

editor_plugin.js is the compressed spellchecker plugin main file and editor_plugin_src.js is more readable copy of it. Refresh your browser and google spellchecking service should start working when you select the language from spellchecker button and press the button.

The problem was that spellchecker_rpc_url was not defined - it could be probably given in future from moodle administration menu but here it is using the default value - the folder where plugin itself is.

Another reason why this variable should be given somewhere else is that if we upgrade tinymce no integration files should be overwritten. In this case we should do this change again and I have tried to avoid it in other places.

I will upgrade this change later to my weekly package too but I could test some other ways to give that path outside the plugin first.

The init code for selected languages is in lib/editor/2(or 1 for you)/ and files adminscr.php (editor for front page where tinymce needs some help...), staff.php (teachers editor), student.php (editor for students) and messages.php (message editor). All other editors have only files meta.php and messages.php

The code for tinymce will most likely change a lot when configuration and administration is ready so don't worry about those many lines in init code. Most settings will be given by buttons or dropdown lists from administration menu.

Average of ratings: -
In reply to Mauno Korpelainen

Re: The most important decision on editor integration

by Larry Elchuck -
Great Mauno

I got it working with the fixes that you provided. I think I'll stick with the Google spellchecker ... since I have it working.

I modded the languages to only en and fr in ther cited files.

I noticed that there was no such lang line in student.php. Under the current schema, should there be such a lang line in this file as well?

larry
Average of ratings: -
In reply to Larry Elchuck

Re: The most important decision on editor integration

by Mauno Korpelainen -

Larry,

I thought students should not get more help than needed in writing different exercises so I left the spellchecker away from students editor. If you want to add spellchecker to students editor check the code from staff.php and add spellchecker for example to

plugins : "safari,spellchecker,table...

theme_standard_buttons2_add : "ltr,rtl,table,nonbreaking,advhr,emotions,emoticons,charmap,dragmath,spellchecker,search,code,fullscreen",

and

spellchecker_languages : "+English=en,French=fr",

I just upgraded tinymce to new version 3.0.9 on my test site and package is getting smaller all the time when files get cleaned wink. I will probably "publish" package III after 10 days - hopefully with nice administration.

Marc,

I have been testing the equation plugin all day long and it might be better to use it only with Xinha (and maybe later with FCKEditor). I have not been able to solve the "dollar conflict" between tinymce and asciimathml.js black eye

Average of ratings: -
In reply to Mauno Korpelainen

Re: The most important decision on editor integration

by Larry Elchuck -
We have students who will take courses in English as first language, French as first language, and French as second language .... so the ability to spellcheck and access the mouse-overs in both languages is important to us. Thanks Mauno.

1. Might the settings for choice of languages be selectable from a spellcheck languages settings matrix (with users across the top and languages down the side and checkboxes in the table)? ... just a thought!

2. As upgrades to 3.0.9, etc. are made, it will prove to be interesting to see exactly what manual changes will be required to manually modify my CVS build each time.

3. Can "language : "<?php echo str_replace("_utf8", "", current_language()) ?>",
" in students.php be replaced by us with "+English=en,French=fr" as well?

4. Poking at the code to make the changes above, I noticed that staff can upload files via tinymce but students can not. What are the implications of giving students this capability? Would they have their own space could they destroy assets for the course?

cheers
larry
Average of ratings: -
In reply to Larry Elchuck

Re: The most important decision on editor integration

by Mauno Korpelainen -

1. Good idea.

2. Upgrading changes only some files in lib/editor/tinymce/jscripts/tiny_mce/ - if necessary I can write a list of changes I made.

3. I have missed that. It should be:

language : "all",

so that language strings get translated for students too. I will change this to next package

4. Usually capability to upload files is given by roles - you may override permissions in some course - but you can also give access to course files with editor integration or we could give students some special folder for uploading files. In file manager of fckeditor it is also possible to set/limit for example file types that can be uploaded.

I got a very interesting email from Thanh Le, Open University, and will test the work he has done during the next days - it is good to have different kind of viewpoints to find the best possible integration for the next default editor(s)

And Thank You Larry for your feedback - it is very important for me to get this kind of notes because sometimes I simply forget to make changes to all files.

Average of ratings: -
In reply to Mauno Korpelainen

Re: The most important decision on editor integration

by Marc Grober -
Ahhhhh..... Here it is:

< I have been testing the equation plugin all day
< long and it might be better to use it only with
< Xinha (and maybe later with FCKEditor). I have not
< been able to solve the "dollar conflict" between
< tinymce and asciimathml.js

Not sure what you mean here. Equation plugin meaning what I have been calling EqEd (Xinha's Equation?) In test19 asciimathml.js displayed equations seemingly fine so unless I am missing something I am assuming this is not a parsing issue with asciimathml (see below) and that you are only talking about when one opens EqEd? I know there are a number of issues with using EqEd which I think need to be addressed by a restructuring of functions as to when and how tokens are stripped and added (one reason I think that using an array may help).

My opinion that EqEd usage should be considered only after restructuring is major reason for my suggestion (posted elsewhere) that while it is great that EqEd can be used in xinha (proof of continued viability) I agree EqEd should remain a xinha feature until Peter has the time to consider the issues.

However, I did not that one of the equations I put in the wiki now shows the notation below lim as opposed to as a superscript... and I need to spend the time to determine the exact details of the inconsistency ;=}

Average of ratings: -
In reply to Larry Elchuck

Re: The most important decision on editor integration

by Mauno Korpelainen -

Tinymce is using Google spellchecking service as default and instructions of spellchecker are in http://wiki.moxiecode.com/index.php/TinyMCE:Plugins/spellchecker

Open file lib/editor/tinymce/jscripts/tiny_mce/plugins/spellchecker/config.php and make changes. In init code

spellchecker_languages : "+English=en,Danish=da,Dutch=nl,Finnish=fi,French=fr,German=de,Italian=it,Polish=pl,Portuguese=pt,Spanish=es,Swedish=sv",

can be changed according to spellchecker.

Xinha is using the same code as htmlarea and for fckeditor I have not configured or tested any spellcheckers but it should be possible to change too - one of those things on waiting list...

Average of ratings: -
In reply to Mauno Korpelainen

Re: The most important decision on editor integration

by Mauno Korpelainen -

For fckeditor the main configuration (= all default settings) of my integration is in files lib/editor/fckeditor/editor/fckteacher.php and lib/editor/fckeditor/editor/fckstudent.php

For Spellchecker settings you could read

http://docs.fckeditor.net/FCKeditor_2.x/Developers_Guide/Configuration/Spell_Checker

and for aspell particularly

http://sourceforge.net/docman/display_doc.php?docid=19473&group_id=86602|Windows/PHP

The whole FCKEditor integration is missing some functionalities of moodle like multilang feature but I took it to package because of the filemanager and some nice plugin it has. Folders lib/editor/3-5 can be easily deleted and editor options from user/editlib.php dropped (xinha, fckeditor, xinha with asciimathml) + folders lib/editor/fckeditor and lib/editor/xinha deleted if you don't need them. If default editor is set to tinymce the same can be done for htmlarea too and if somebody wants to have 10 different versions of tinymce it is possible with different configurations in folders 1-10 + user/editlib.php - but nobody is forced to do so...

I really try to find a better way to do the selections - later...wink

Average of ratings: -
In reply to Mauno Korpelainen

Re: The most important decision on editor integration

by Larry Elchuck -
Wether I select the google spellchecker or aspell (local server), I get stopped at "spellchecker_rpc_url" error.

I saw reference to this at http://tinymce.moxiecode.com/punbb/viewtopic.php?id=10450 but am not sure where to enter this.

I have the same error on your teacher1 test site when I try the spellchecker.
http://korpelainen.net/test19/mod/forum/post.php?reply=2

Also where is this init code that you refer to?
"In init code spellchecker_languages : "+English=en,Danish=da,Dutch=nl,Finnish=fi,French=fr,German=de,Italian=it,Polish=pl,Portuguese=pt,Spanish=es,Swedish=sv", can be changed according to spellchecker."
cheers
larry
Average of ratings: -
In reply to Nicolas Sicard

Re: The most important decision on editor integration

by Marc Grober -
We will never have enough real estate to place all possible icons forever....

It is more reasonable to continue I think with the kind of solution implemented in tinyMCE such that you can choose which functions you want to have on your tool bar via a pop-up gui.... after all, there are functions that someone will never use.....

And, you can always changes those options at any time.....

In the alternative I suppose we could do extensible or cascading menus.....

Mauno?
Average of ratings: Useful (1)
In reply to Marc Grober

Re: The most important decision on editor integration

by Mauno Korpelainen -
The tradidional way is this editorhidebuttons setting in administration menu (tinymce version attached) but we have other alternatives too...
Attachment hidebuttons.jpg
Average of ratings: Useful (1)
In reply to Mauno Korpelainen

Re: The most important decision on editor integration

by Mathieu Petit-Clair -
Picture of Core developers Picture of Moodle HQ Picture of MoodleCloud team Picture of Plugin developers Picture of Testers
Thanks for this great work Mauno!
Average of ratings: -
In reply to Mathieu Petit-Clair

Re: The most important decision on editor integration

by Mauno Korpelainen -

Thank you Mathieu!

It was your email that put the whole process in motion - and the real work has just begun...

I always forget something and this time I forgot old wiki that would also need a small change for example to mod/wiki/ewiki/ewiki.php and function ewiki_page_edit_form. A better choice is to use new Nwiki that works without any changes with all editors and all browsers.

Average of ratings: Useful (1)
In reply to Mauno Korpelainen

Re: The most important decision on editor integration

by Mauno Korpelainen -

One thing missing from the previous package: while cleaning code and unnecessary xinha plugins I had cleaned also dragmath plugin from xinha - it was there in my standalone xinha...blush

Anyway - xinha has a new stable release with compressed code and I might "publish" one more "test package" after one week or two weeks with or without fckeditor but definitely with some new tinymce features and faster xinha. There are still many open tasks - for example language files and administration/configuration of settings... and possible new feature requests.

Thank you for all testers and feedback !!!

Average of ratings: Useful (1)
In reply to Mauno Korpelainen

Re: The most important decision on editor integration

by Marc Bria Ramirez -
Dear Mauno,

Sorry a lot for the long silence, but also to leave you alone with this huge issue.

I like to join Eloy words of thank you for the impressive work done.
You, mainly alone between lines of code, made this significant steep possible.

If it finally becomes a reality (as it seams) we need to remember the kudos.

Back to the point, I think we are in front of a two steep process:

As far as htmlarea is a completely outdated piece of... software, I suggest a fast replacement in next moodle releases with your tinyMCE integration.
After this, an editor layer need to be developed (or improved) to allow admins select different editors than tinyMCE if they like.

I missed a lot of discussions during last months (may be a year) but sounds like you are also thinking, or you developed the "editor by role" functionality.

Is it true? Would be possible to define different editor set of buttons with different profiles?

If this is right I can't thank you enough for the great work done. I personally won't use this feature in my new project, but I always thought that Admins or Teachers has different editor needs than Students.

Once again, Moodle Community is in debt.

Take care,

m.

----
Htmlarea will die in -231 days tongueout
Average of ratings: Useful (1)
In reply to Marc Bria Ramirez

Re: The most important decision on editor integration

by Mauno Korpelainen -

Hi Marc,

I was 2-3 months away from editors and came back when Matheau sent me email two weeks ago. Yes, I have tested role based settings. In a simplest form i just separated code using capability checking in meta.php of theme like this:

<?php

if (($COURSE->id < 2) and has_capability('moodle/site:doanything', get_context_instance(CONTEXT_COURSE, $COURSE->id))) {
include_once($CFG->dirroot.'/theme/standard/editor/adminscr.php');
}
else {
if (!empty($COURSE->id) and has_capability('moodle/course:managefiles', get_context_instance(CONTEXT_COURSE, $COURSE->id))) {
include_once($CFG->dirroot.'/theme/standard/editor/staff.php');
}
else {
include_once($CFG->dirroot.'/theme/standard/editor/student.php');
}
}
?>

and files adminscr.php, staff.php and student.php have different init code. They may as well have different administration. I added all needed buttons and plugins of tinymce to adminlib.php and used $cfg->editorhidebuttons to select site wide hidden buttons - all of them can be hidden. In "role based init files" I set up different settings for those buttons and plugins that are available for that profile. Hiding buttons is stronger so it overrides editor profiles. I have also tested skins and after all this "basic stuff" I am going to create some nice skins to some nice themes (Read: kids style...wink)

It took a while to get basic ideas and differences of these editors studied but I believe things are getting clear now...

EDIT: ...and yes, I have that selection system ready - in fact that's the reason why I asked this original guestion. On my test site I have one htmlarea, tinymce, xinha and fckeditor. We can have several selectable editors, each editor can have several selectable settings, themes, skins and skin_variants. The difference of the last three is that editor themes can make editors use totally different settings and files (like editor profiles), skins can be used to separate css (like normal Moodle Themes) and skin_variants are for example color variants of same basic skin.

Average of ratings: Useful (1)
In reply to Mauno Korpelainen

Re: The most important decision on editor integration

by Julian Ridden -
Ooooooo, I like.

I assume, if implemented, the idea is that there would be a role setting for which editor to use..that would be neat.

the only issue with rolling out multiple editors would be the need to maintain specific moodle hacks in each. (such as the file browser).

But the idea of choosing one as standard, then allowing for others to be added like modules with access granted through roles would be a very clean solution.

JR

Average of ratings: -
In reply to Julian Ridden

Re: The most important decision on editor integration

by Mauno Korpelainen -

I think I just found a very simple and flexible way to do both. We can separate all editor settings in lib files already so that if no custom editors are selected (in $user->htmleditor value < 2) moodle should select default editor or no editor if $cfg->htmleditor or $user->htmleditor is 0. For default editor all editor settings and functions must be backed to default files that can be included with php to lib files (now they are fixed). For custom editors those settings and functions can be in different files that are loaded according to value of $user->htmleditor. I can do all that packing to "editor modules" - it requires changes to about 10 core files but I think it is worth doing because some functions are just moved to other place from current code. The only thing left is to set the method how to select the order of different editor packages (needed in user/editlib.php to be able to select editor in user profile - some sort of "installed editors setting or function") or should I just use a pre-selected order like

Package 1 = Htmlarea (untill TinyMCE is fully tested)
Package 2 = TinyMCE
Package 3 = FCKEditor (not ready yet)
Package 4 = Xinha (almost finished)
Package 5 = YUI RTE (not even started to build integration)???

It may take about one week to get these packages ready for testing and you may download packages from my test server then. The previous version of my multi-editor-moodle was using files of moodle 1.9 but there should be no big difference in editor files of moodle 1.9 and other versions of moodle - this selection system should work with all versions of moodle.

Tim,

I believe nobody has yet tested (compared) accessibility of all these editors but as far as I know TinyMCE has most flexible way to change all settings and FCKEditor has very clear plans to get editor more accessible in their future versions (FCKEDitor 3). None of them is 100% accessible in default init code.

Average of ratings: Useful (1)
In reply to Mauno Korpelainen

Re: The most important decision on editor integration

by Tim Hunt -
Picture of Core developers Picture of Documentation writers Picture of Particularly helpful Moodlers Picture of Peer reviewers Picture of Plugin developers
Of the various options being considered, has anyone tested them to see which is most accessible?
Average of ratings: -
In reply to Tim Hunt

Re: The most important decision on editor integration

by John White -
Tim & Mauno,

I have been trying to get to grips with which editor works best since I installed this choice from Mauno's weekly zip for 1.9.1 on a local Moodle instance a short while ago... bearing in mind that I came into this from the point of view of not having any editor working in Safari 3 or 3.1.1 (which I think is a worryingly common experience)!

I need to be brutally honest, but I want to start by saying that I can only praise the enormous effort Mauno has put into this work. What he has managed to achieve, with input from colleagues, is an awesome testbed for finding the right editor (or editors) for Moodle.

But I think it should be seen as just that. In order to test so very many options, including all sorts of theme setups and user options, you have a system which I think would floor most ordinary Moodlers and give a real headache to most ordinary Administrators.

For example, HTMLarea doesn't work in Safari, but in common setups TinyMCE doesn't seem to step into the breach when needed - this is a much more fundamental issue!

Using the new setup will mean some administrators not knowing what is the best default to use, and even if they are given the option to set the default, users can change their editor... and then wonder what went wrong in they use the wrong browser!

The skins look like a very clever invention, but why is the default appearance not the site theme? I have blue TinyMCE and Xinha editors, but a yellowish FCKEditor - but they all look bad against my carefully created site themes!

More difficult still is the font in the editor. Now this is only a 'representation' of what will be seen when the editor is closed, but you still need to be able to read it. And it TinyMCE and FCKEditor, when viewed on a 20" wide-screen Mac running at its native resolution of 1680x1050 its like typing on a microdot! In the Xinha editors it is much more sensible, but why not use the defaults from the site themes, where text-boxes have a reasonable font size, it all seems a bridge too far to me.

I can see that there is real mileage in providing editors (or other interfaces) that meet the needs of young students or perhaps students with visual impairment (for example), but to provide the user by default the option to change editors or editor settings, is to me a very big concern. Especially as in many cases just changing the default editor font size, and the default icon size, is what would be needed rather than necessarily the editor itself. And in most cases doing this at the site or course level is what educators would ask for.

Even where a mathematics course (say) would benefit from an algebraic editor, this seems to me to be a courses level issue, not a user one.

Above all, I would want to see a natural default state that is under the administrators control;
that the default theme of the editor is the site theme;
a default a setting that blocks, but can allow, changes within a user's profile (as with preventing the editing of email addresses) - or else this feature removed entirely;
a default a setting that blocks, but can allow, editor changes at the course level;
and your current working group to come to a conclusion about which editor(s) work best, and a resulting Wiki document on how to make choices and changes, and suggested circumstances under which each editor might be the best site choice.

I am really sorry about sounding so negative over Mauno's hard work! But it is not negative to want the Moodle experience to be moving forward, and for Moodlers (even administrators) who do not always have very high levels of technical skill, not to get too bogged down in the detail.

With best regards, most particularly to Mauno,

John
Average of ratings: -
In reply to John White

Re: The most important decision on editor integration

by Mauno Korpelainen -

John,

it's not at all negative - I had the same things in mind when I was talking about administration and configuration of settings.

The reason why this part is not ready is that I started working on this only a couple of weeks ago when Matheau sent me email and asked about my previous theme based integration. I guess nobody else has been testing these things so widely - it's a new world for all of us.

I could write some documentation, I could create nice skins for each theme and editor and so on... it just takes some time to get them all ready.

Changing skin or other basic settings could be done with a couple of variables and skins are all css based so basicly changing colors, font sizes and other properties is very similar to changing theme css. When the basic configuration system is ready I can create some examples - if you could send a screenshot of your themes, John,  or I could see the themes I could help you to create exactly that kind of editor skins as you like.

This skin issue was the original reason why I started testing editors - the first ever skin I made was a skin for very young kids - with 3 times bigger buttons and fonts than normal tinymce skins have.smile

Default settings are important and if you select htmlarea it looks like old moodle with all themes. Default skins of other editors could also have the same colors and buttons as htmlarea ("masked" as htmlarea) - to make changing editor easier...now they are using editor default or some selected skin from the skins that come with editors.

Average of ratings: -
In reply to Mauno Korpelainen

Re: The most important decision on editor integration

by Mauno Korpelainen -

I checked quickly some skins and for most themes the neutral grey background for buttons and a about 50 % bigger fonts for tinymce and FCKEditor might be good default settings.

From these links you may test some skins

http://www.fckeditor.net/demo/skins?skin=silver

http://tinymce.moxiecode.com/example_skin.php?example=true

http://xinha.raimundmeyer.de/x_examples/ext_example.html

and for example for tinymce each skin can have skin_variants that are given in init code with tags like

skin : "o2k7",
skin_variant : "silver",

That way each editor can have several themes with different basic settings, each editor theme can have several skins and each skin can have (usually color) variants where only some basic settings are changed to main skin.

Average of ratings: -
In reply to John White

Re: The most important decision on editor integration

by Mauno Korpelainen -

John,

I read you post again and I must clarify one more thing. This package is really a test package and I made it to be able to test different settings of editors. I have never ment to allow students to freely select any buttons or plugins - they must all be set to init code or configuration of editors. One spur behind all selectable options was Storytelling module (thanks to Marc B.) that was the first activity to have role based editors and you can select visible buttons for profile (students usually). If this setting is site wide, some usefull buttons/plugins are either hidden or visible to both teachers and students.

File&imagemanager coursefiles are available only for teachers although for example in fckeditor file manager we could allow limited access to specified folders and specific files for specific courses, roles or users. It is not my intention to allow users of moodle to do anything - my intention is to help other developers to test and try such things in editors that may be useful.

I'm sure that core developers will check all code very, very carefull and make as little as possible changes to core code so that default editor of core moodle will look almost the same in future as today (also the administration). It has just been impossible to change default editor to fully working editor - tinymce may be very close to bug free editor today - but you never know what happens when we have IE10 and FF4. At least IE8 will cause a lot of headache to moodle and all themes - xinha goes wild in IE8 - and also drop down lists of tinymce have troubles in IE8. FCKEditor may be better than tinymce after one or two years or some new editor can drop all current editors. The main reason for all this testing is to find proper ways to change, configure and use editors in moodle.

Average of ratings: -
In reply to Mauno Korpelainen

Re: The most important decision on editor integration

by John White -
Mauno,

Thanks for these responses.
I appreciate that what I have really done is to muscle in on a test-bed and expect to see the finished version, which is daft.
I only really want to be sure that the end result is not too complex for most Moodlers to be happy with.

Cheers again,

John
Average of ratings: -
In reply to Mauno Korpelainen

Re: The most important decision on editor integration

by Mathieu Petit-Clair -
Picture of Core developers Picture of Moodle HQ Picture of MoodleCloud team Picture of Plugin developers Picture of Testers
This thread is getting a bit crowded, to say the least. I must admit it's getting hard for me to keep track of all of this, suggestions and development ideas, that are mentioned in here.

I am currently aware of three branches of development for the editor (Mauno's - available by zip files in here, mine - as a patch in the tracker and partly in cvs head and finally OU's - which is a zip file that I just received by email). I am trying to keep up (and make sense of) all of this...

There are tickets opened in the tracker and pages in the wiki to keep track of this, using them seem like a good idea, otherwise I fear there will be a lot more duplicated effort. Actually, there has been code in Moodle (at least since 1.8, afaik) to prepare for multiple editors usage (written by Janne Mikkonen) that none of the aforementioned branches are using.

I am sure a lot of great ideas have been expressed here, but unless somebody clearly sums them up somewhere (in the wiki, please!), we might very well forget all about them soon... sad

Here's what could be done to ensure we follow a common plan:
* review and (carefully) edit http://docs.moodle.org/en/Development:HTML_editor_2.0 with ideas extracted from this discussion
* post code (patches against HEAD are most appreciated) to MDL-11113, along with comments
* create subtasks in this same ticket to divide (and conquer...) related problems (mathml/dragmath looking like an important one).

Mathieu
Average of ratings: -
In reply to Mathieu Petit-Clair

Re: The most important decision on editor integration

by Mauno Korpelainen -

Hi Mathieu,

it's ok for me to work with any version of integration - we only need that official test version from you or Martin to http://download.moodle.org/ (or CVS - I guess I can get my Vista to use it somehow). Janne has done a good base work and I am sure it can be used for any editor but could you or Janne give an example how to change default editor from htmlarea to tinymce or other editors using Janne's editorlib.php. Janne has written the short text for special cases and for example Marc Bria has used this way tinymce in Storytelling but the "big thing" is the fully working default editor to moodle.

I tested twice the code Thanh Le sent to me also and it did not work at all - either some changes were missing or the package was somehow broken. The idea to select site editor from administration menu is good, the idea to replace header scripts using similar approach as in Janne's case 1: htmlarea, case 2: tinymce does in editorlib.php is good (my files are just making the selection using folder numbers that are the same as $CFG->htmleditor or $USER->htmleditor and Thanh has used a new variable for this ) but OU's package is missing ALL OTHER MOODLE FUNCTIONALITIES but $editorhidebuttons

It is not a problem to replace textareas with editors - it can be done with any editor with 100 different ways - when you start adding the special features of moodle you have collected to http://docs.moodle.org/en/Development:HTML_editor_2.0 things get more complicated. If you want we can start again from the first version with only one default editor - tinymce - where editor functions are there were Janne originally put them and modify the code a little to make tinymce 99% functional. I leave this 1% for bugs. It was ready 1 month ago but I used themes for giving settings and prefered the selection system so I continued testing also xinha and fckeditor. The "Xinharepl(a)" version is the easiest possible substitute of htmlarea and with small changes it is at least as functional as current htmlarea.

Any solution is a good solution if it just works - it really does not matter if it is created by Janne, you, OU, Glen or me.

Average of ratings: -
In reply to Mauno Korpelainen

Re: The most important decision on editor integration

by Marc Grober -
As one of the folks on the sidelines, I really would like to put in another whine fopr using a CVS for editor testing so that we can check out and overlay editor tests as simply as possible. With a couple of commands a new test can be put in place or replacxed.... In the alternative I suppose the option is to run up a few test sites for various configurations and I am happy to host some.

As Mauno has shown, there are lots of things that can be done, the work is in the little details. By way of example, my concern for the ability to use math in moodle has driven a concern that all editors work transparently with dragmath and asciimathml; current editors do not have the ability to calculate, construct or display equations without plugins. The features of asciimathml hold out huge promise for use in Moodle as possible core technology as they are open, extensible, etc. The possibilities to use asciimathml in editing have been demonstrated but have been barely touched (see Mauno's work on Xinharepla with Equation Editor - EqEd. But there are some basic design issues that have to be addressed here as with the rest of the implementation: Use of asciimathml as filter or by way of theme? As js or php? And as I noted to Mauno with respect to Dragmath, the most recent changes require deletion of dollar signs from integration. Should dragmath window be inside or outside editor window.

It would be difficult to document all the details that I have raised or that Mauno has worked through with respect to asciimathml, dragmath, and EqEd on that one Development page.... I think we would need an additional page to address such items.... more a punch list than anything else... and then there would be other issues as discussed elsewhere about editing versus displaying... and If enough people start hacking the wiki page it might soon become as unmanageable as the forum (uh-oh... sounds like a distillation issue!!)


Average of ratings: -
In reply to Mauno Korpelainen

Re: The most important decision on editor integration

by Mathieu Petit-Clair -
Picture of Core developers Picture of Moodle HQ Picture of MoodleCloud team Picture of Plugin developers Picture of Testers
Hi Mauno,

I'm worried about problems you had with what Thanh sent you. I think he sent you a set of patches (against 1.9), but what I got was a complete (2.0-based) distribution. Maybe there was something missing in the patches? I didn't have any problems with the complete archive, but it's worth investigating before committing to cvs...

I am aware that his work is only a start, that plugins and smileys and others are missing, but it's a start that could make it easy to integrate the other features.

I'm working on this today, I'll wait for news from others about possible problems with the complete package sent by Thanh.

Mathieu
Average of ratings: -
In reply to Mathieu Petit-Clair

Re: The most important decision on editor integration

by Mauno Korpelainen -

The problems I still have with Thanh's package or patches might have something to do with my server upgrade - not necessarely the files that Thanh has included.

Debian Etch with mysql version 5.0.51 and php version 5.2.6.0.1 and the latest phpmyadmin seem to have some problems with mysqli or char sets.

I must investigate my environment first.

Average of ratings: -
In reply to Mathieu Petit-Clair

Re: The most important decision on editor integration

by Mauno Korpelainen -

It's not my server. I upgraded all programs on my test server and installed fresh moodle 1.9 and moodle 2.0 using mysql - the reason why I mentioned mysqli was that my server does not use it and mysqli was  the first selection in latest moodle 2.0 but as far as I have understood moodle should run with normal mysql library (the second option).

Both installs worked ok. I installed my previous week package with no problems and debugging gave no errors so I believe my server is ok.

BUT: I reinstalled Than's package and it simply does not work with any other editor than htmlarea. The only place where I get other editor than htmlarea or empty page is user profile. I added the changes mentioned in patch to fresh moodle 1.9 and nothing changed - no luck.

Debugging gave only the following error (the full package I got from Thanh):

Catchable fatal error: Argument 2 passed to moodle_database::record_exists() must be an array, string given, called in /var/www/thanh2/course/lib.php on line 1239 and defined in /var/www/thanh2/lib/dml/moodle_database.php on line 998

Maybe Thanh has sent me a different link/package - when I compared files of generic packages and his package with WinMerge there were about 200 different files - probably some changes are missing or are from wrong version of moodle. If you have a package that really works can you zip it and send a link?

I don't comment the missing features of OU package more before I can test something else than profile page - I'm not sure either how Than's package handles Front Page description, messages, wiki, form-textarea selector (for such places where user can select to textarea or editor), course files or translation. Plugins can be added to do some tasks but using only core integration files for tinymce, fckeditor or xinha with only external configuration (files) may not work either.

I'll take a short holiday and hope you have OU-based package ready when I'm back...wink

Average of ratings: -
In reply to Mathieu Petit-Clair

Re: The most important decision on editor integration

by Mauno Korpelainen -

Mathieu,

which option do you prefer:

- should you first publish some prototype of tinymce integration for moodle 2.0 and I could help you with testing and adding the features and functionalities of moodle ?

- should I continue my own project and use next week to build that administration for my weekly package? I have now wasted 3 days for nothing and am a little bit frustrated for OU package that I never got to work.

- should you publish or send a link to an OU package that works on your server (it must be different package than my OU package) and I could help you and Thanh to add the features and functionalities of moodle to OU package.

or some other option ? Most ideas that you have found from this discussion are not just ideas - they are already working code in editor integrating files but not in standard versions of tinymce, fckeditor or xinha - so why should we start from the beginning again (I mean OU package)?

Average of ratings: -
In reply to Mauno Korpelainen

Re: The most important decision on editor integration

by Mauno Korpelainen -

Mathieu,

I noticed that you have already added some parts of OU package to the latest moodle 2.0 and tried to follow the main logic.

I will continue testing some plugins and features in fckeditor and tinymce with the code I know better and let you and Thanh to work on the OU code.  Yesterday I got Dragmath to work also in fckeditor with IE, Safari and Opera but Firefox was complaining about some communication problem between javascipt and java. This is a small problem compared to those troubles you will probably have with IE, Wiki, messages editor, translation, course files (note that you need to keep $course->id and capabilities in process when file manager/links/images are called from course files) etc.

You may also use the "preconfigured" standard theme instead of advanced theme in init code for default settings - just change advanced to standard - if you want to get some default settings ready without double work. I was planning to create some kind of administration module for each editor instead of global configuration from administration menu that could be used to build editor profiles that you could push directly to header - init code as a string that is just extracted when you need it but you could change the strings the same way as $editorhidebuttons is build from separate buttons you either use or hide.

I'm not sure if I will publish any more packages if you can add the missing features to OU package. In that case it is more reasonable to start working on that version. Perfect cleaning of weekly 1.9.1 editor test package can be done deleting file lang/en_utf8/tinymce.php and folder lib/editor and installing a fresh copy of moodle 1.9.1 or moodle 2 over previous files. On the other hand I do prefer choices compared to stable structure so it is also possible that I keep testing a theme based editor system for the rest of my life...winkbig grin

Average of ratings: -
In reply to Mauno Korpelainen

Re: The most important decision on editor integration

by Mauno Korpelainen -

One update:

Dragmath is now working also in firefox in fckeditor - the problem was finally one missing space. Attached files can be added to previous weekly package. If you want to use the plugin elsewhere with fckeditor you need to upload Dragmath itself and change

codebase="<?php echo $CFG->wwwroot.'/lib/editor/common/dragmath/applet/classes' ?>"

to correct value in file fck_dragmath.php

In test package htmlarea, tinymce, xinha and fckeditor are all using same files in folder lib/editor/common.

Average of ratings: -
In reply to Mauno Korpelainen

Re: The most important decision on editor integration

by Martin Dougiamas -
Picture of Core developers Picture of Documentation writers Picture of Moodle HQ Picture of Particularly helpful Moodlers Picture of Plugin developers Picture of Testers
I have just moved this to the HTML editors forum.

I think it's really essential to get this sorted in HEAD as soon as possible and it's Mathieu's number 1 priority now.
Average of ratings: -