|
History
| Log In
|
|
|
|
May I clarify why I used function use_admin_editor(): it was necessary only because I did not get tinymce to render editor properly on admin settings and upgradesettings pages and message editor so I used a different function to load init script through function. The problem comes from different way to init editor: in current version htmlarea and xinha replace textarea created by function print_textarea with editor using use_html_editor and for these editor use_admin_editor was basicly the same as use_html_editor (a little bit different button sets only). TinyMCE has a class selector that it uses to replace elements that have class "form-textarea" with editor and init code is loaded before page itself is loaded - in header tags. FCKEditor is usually using the same method as htmlarea and Xinha but in my tests I have used this kind of a header script in meta.php to do the replacement like tinymce:
<script type="text/javascript"> window.onload = function () { var alltextareas = document.getElementsByTagName("textarea"); for (var i=0; i < alltextareas.length; i++) { if(alltextareas[i].className=='form-textarea') { var oFCKeditor = new FCKeditor(alltextareas[i].name) ; oFCKeditor.Config["CustomConfigurationsPath"] = "<?php echo $CFG->wwwroot ?>/lib/editor/fckeditor/moodleconfig.js"; oFCKeditor.BasePath = "<?php echo $CFG->wwwroot .'/lib/editor/fckeditor/' ?>" ; oFCKeditor.Height = 400 ; oFCKeditor.Width = 600 ; oFCKeditor.ReplaceTextarea(alltextareas[i].name) ;} } } </script> and moodleconfig.js has all the settings for fckeditor. If we have only a couple of different ways to use editor we can have also a couple of different config files (for administration and messages). It might still be good to keep both function print_textarea and use_html_editor (even if it was empty) or have different functions for editor header tags/scripts and editor body tags/scripts. Or those "special cases" (like message editor and front page description page could use header tags and editor the same way as other pages) Anyway a common plug-in layer is a great thing. We might have some settings stable in lib files and some settings might be configurable through themes and css or some custom config files. FCKEditor is using a 3-level configuration 1) default configuration file (fckconfig.js) 2) custom configuration file(s) (moodleconfig.js) and 3) custom tags like oFCKeditor.Height = 400 ; that can be given for example in theme header.html or meta.php
Settings 2) overide settings 1) and settings 3) override settings 2) (if there are some custom settings) And if you decide that tinymce is the default editor it would be natural to force other editors (htmlarea and xinha) to use the same logic to render editor like tinymce with build-in-class-selector and fckeditor with window.onload-class-selector. Then functions use_html_editor and probably also use_admin_editor could be moved to deprecatedlib.php. One big question is how to set editor configuration for special needs - with common plug-in-layer and functions like print_editor_config($editorhidebuttons='', ...) or some other method like theme tags. The difference is that if we use common plug-in-layer we can have stable settings for activities like messages and settings are given by the activity. If we use theme settings we can change the layout of editors so that message window does not have to look the same in different themes. Both are good choices and have several benefits...
If possible these settings could be given before printing textarea with class="form-textarea" and not after printing the textarea (now htmlarea gets the settings in function use_html_editor after function print_textarea and tinymce can't use function use_html_editor to give new settings because it has already replaced textarea with editor according to class="form-textarea". ...or Tinymce needs to reload the editor with new settings.
Thanks for the explanations Mauno, I will start working on this patch again, make it work against head again and possibly commit it soon.
I added a link to new test package to http://moodle.org/mod/forum/discuss.php?d=96160 and tested some optional ways to render editors. We may use also editor functions like Xinha.replace() directly. If you download the package and check the files I tried for example the following "tricks" to get the problematic pages loaded with use_admin_editor() - textarea id, textarea name and textarea class are used differently in different editors:
For Xinha: function tsetup() { var alltextareas = document.getElementsByTagName("textarea"); for (var i=0; i < alltextareas.length; i++) { if(alltextareas[i].className=='form-textarea') { Xinha.replace(alltextareas[i].id) ;} } } For FCKEditor no extra functions needed: window.onload = function () { var alltextareas = document.getElementsByTagName("textarea"); for (var i=0; i < alltextareas.length; i++) { if(alltextareas[i].className=='form-textarea') { var oFCKeditor = new FCKeditor(alltextareas[i].name) ; oFCKeditor.ReplaceTextarea(alltextareas[i].name) ;} } } For tinymce (only IE has problems): <!--[if IE]> <script type="text/javascript"> function tsetup() { tinyMCE.init({ ... all tinymce init code for those admin pages here - tinymce uses class-selector editor_selector : "form-textarea", ... } } </script> <![endif]--> <!--[if !IE]>--> <script type="text/javascript"> function tsetup() {} </script> <!--<![endif]--> If all pages had a same kind of header, same way to get settings and same way to render editor life would be much easier. Could it be possible to get Front page description field and messages to use same logic to render editor as other pages and activities? Then no tricks were needed afterwards. |
|||||||||||||||||||||||||||||||||||||||||||||||||
 |
|
Sub-task
Open
Major
* I added some administration settings, so that the admin can choose the default html editor.
* I reverted the user selection: we will need to create something a bit more complicated, based on formats.
* The /0/, /1/, ... folders have been merged back into the editor folder.
* A new function has been added to moodlelib.php to detect which editors are available on disk.
* A few more changes/fixes: removed php4 compat, cleaned up based on coding standards, etc.
I am not committing this to the repository, mostly because the change from use_html_editor() to use_admin_editor() needs to be clarified (and if do change, there are a lot more places where this needs to be fixed) (and use_html_editor() deleted, or moved to deprecatedlib.php). Committing this now would make the code in a "clearly uncertain" state.
This has less functionality than what Mauno has in his zipfile, but should make it easier to add it back later.
I'll be out of town for two weeks, will be back on the 28th... to work on that and everything else.