Forum OpenACS Improvement Proposals (TIPs): TIP #134 Change default value for RichTextEditor param in acs-templating

So far, it defaults to "xinha". Since we have now tinymce and it is more accessible than xinha, I think it makes sense to change the default value to "tinymce".

Note that UseHtmlAreaForRichtextP is turned off by default.

Forgot to mention that it would be for 5.5.0
I have not watched in detail the commits of tinymce, so i have a few questions about its state and features to get a better understanding:

Can one specify more precisely, what "more accessible" means?
Is the OpenACS file selector plugin (or something equivalent) supported by tinymce?
Is there an alternative for the css stylist in tinymce?
Once, the default is changed from xinha to tinymce, can a package instance (or a package type) still stick with xinha (e.g. when it depends on xinha plugins, or end-user documentation describes it, etc.)?

I created the OacsAttach plugin which works the same as the oacslink plugin on Tinymce. This allows a very simply file upload utility. It uses the same popup tcl script depending on which editor is configured. It is similar, but simpler than the image upload I discussed here https://openacs.org/xowiki/site_wide_image_upload_widget

I found the xowiki based file upload selected was very confusing to get working reliably since if it not clear which file-storage instance you would use outside context of dotlrn, which has a global file storage instance. (Similar to issue with attachments package.)

I have seen that xowiki forces xinha no matter which editor you have choosen. I did some work on one local install to try to get tinymce working and it mostly worked but it was frustratng to find exactly where to change this as the form processing sometime uses the acs-templating form builder and sometimes the xowiki build in form code.

I did not find an exact duplicate of the CSS stylist of TinyMCE but there might be something similar.

Hi Gustaf,

As for "more accessible", TinyMCE produces valid HTML according to the chosen DTD, it also provides access keys to apply styles and shortcuts to jump to/over the tool buttons and more (see http://wiki.moxiecode.com/index.php/TinyMCE:Accessibility).

Approve.

I would also like to a see a replacement for stylist - I use that plugin in CMS - but for the couple of exceptions where xinha might be needed, the default can be changed (until there's a better way to handle this via params).

Dave, there is no "xowiki based file upload". The OpenACS file selector plugin was actually developed before xowiki to fullfill the needs of DotLRN users to refer to images and files from the static portlet etc. What i read from the wiki page of the image upload plugin is that it provides no way to link files/include images from the filestore (except manually via cut&paste) which is used frequently by our users. There seems to be no image selector (it is in your todo list) and there seems to be no way to let the user organize/share files according to their needs by creating folders for various purposes. Since the wiki page of the image upload was not changed over the last two years, i wonder if it is still uptodate. Are the items "definitely on your todo list" now implemented?

Concering xowiki and xinha: xowiki allows a more detailed configuration of xinha on a per-package-instance and per page level, which is currently only implemented for xinha. Since xowiki works with as well with older openacs installations, it guards itself against the old "rte" rich text editor this way. This should change since you people seem to support tinymce nowadays.

Concerning the stylist plugin: there seems to be nothing similar in the public releases of tinymce.

Do you have some documentation how to configure tinymce on a per-rich-text instance in OpenACS? Or is this compatible with the existing configuration? Please update the configuration rich-text widget in the API browser (http://www.openacs.org/api-doc/proc-view?proc=template%3a%3awidget%3a%3arichtext)!

Emma, xowiki uses tidy to correct HTML, since this does not rely on any kind of editor. It is nice that tinymce produces HTML for a configurable document type (xinha loves xhtml). About accessibility: didn't you say that for accessibility, javascript has always be deactivated. With javascript deactivated, both rich text editors just look like a plain textarea.

Only with javascript activated, one is able to get to the table with the access keys, etc. described on that referenced page. so, i am wondering, how you deal in your accessibility tests with rich-text editors....

Just a small follow-on: i had to fiddle around some time to get TinyMCE working at all (i wonder, how the others have tested it).
- in acs-templating, the RichTextEditor variable should be documented accordingly. I just mentions xinha. I typed in TinyMCE (since dave uses this spelling), and nothing worked.
- tinymce is not working at all in cvs HEAD, it (javascript error);
- the tooltips of the attach image/file icons must be improved for usability (currently "oacslink.link_desc" and oacsimage.desc"; i have not checked about i18n)
- If one clicks on the link button, nothing happens
- If one clicks on the image button, a dialog with an error shows up since it tries to access the mounted acs-templating
- the tinymce needs an adminstrator guide (e.g. wiki page) to describe how to use it in OpenACS. AFAIK, there is no way to mount templating via the admin pages.
The answer to the last three of the four questions of mine seems to be "no". Furthermore, the OpenACS integration is not finished yet (not much to do, but someone has to do it). From my short evaluation, TinyMCE looks nice, but i would prefer more experience before making it default. In the current state, making it default premature and does not get my vote.

Hmm, i just saw that someone marked TIP #134 as "implemented". How comes? What happened with our tip rules (TIP #2)? These require at least one week of voting.

I only referred to xowiki since originally you had to have xowiki installed and mounted at xowiki for it to work and it was the first place I saw it in use.

I don't really have a preference, from my perspective this has never been comprehensively addressed, only locally used customizations have been added to the toolkit to provide access to the features.

You are correct that tinymce support does not allow customizing the editor on a per form basis. Its not clear this actually is a good idea. It allows xowiki to do things that are not supported generally in the toolkit by other packages. I don't have a good idea of the use cases for this, but to support flexibility it probably should be fixed. I don't think the existing confifg support in the richtext widget makes sense for TinyMCE, perhaps a way to override individual attributes of the config, instead of just allowing changing some of them or requiring the entire config in javascript. I'd have to think about it.

I believe regarding bugs, all the bugs are fixed on oacs-5-5 branch and not on HEAD yet.

There is an oacsimage plugin for TinyMCE I don't think it was ported to work on Xinha though.

Regarding the parameter value, the description on HEAD says "xinha" or "tinymce" listing the valid values.

Gustaf,

I did. I'm rushing because I will be on leave soon and actually missed that rule.

"tinymce is not working at all in cvs HEAD, it (javascript error);"

Daveb's right, the work's been done on the oacs-5-5 branch.

As is usual, I'll merge oacs-5-5 to HEAD *after* final release of 5.5.0.

This is standard operating procedure during the release process.

"Concerning the stylist plugin: there seems to be nothing similar in the public releases of tinymce."

The only thing I found when looking into this was an article [http://atutor.no/2008/07/adding-styles-tinymce-styles-select-menu] by a developer of a tool that uses TinyMCE. So it apparently IS possible to set up a custom list of styles but it's more of a manual process.

At Galileo, and I know others as well, are creating and have plugins for xinha. At some point those plugins can be contributed and be standard features of applications. I prefer xinha to continue as default. At some point will be nice to see some comparison between editors and see what are the interests of the community in this regard, there are so many editors, also xinha has improved a lot in the last releases.
Dave wrote:
You are correct that tinymce support does not allow customizing the editor on a per form basis. Its not clear this actually is a good idea. It allows xowiki to do things that are not supported generally in the toolkit by other packages. I don't have a good idea of the use cases for this, but to support flexibility it probably should be fixed
If I understand it correctly, the situation of the tinymce integration is actually much worse: in the current openacs integration there is one global customization of tinymce that applies to all textareas in all forms in all packages instances of all package types. Over the rich-text API (over three years in OpenACS) one can configure every single textarea. This has nothing to do with xowiki.

The single global configuration file is a severe limitation. For example, in our learn system, we use different configurations of xhinha in the forums for admins and ordinary users (admins have more functionality). Similarly, we have several custom plugins for xinha, which make sense only for certain applications. Nima has developed some xinha-plugins for assessment. Rocael has developed some plugins for their packages. Do you really think that allowing attachments for every rich-text occurrence is a good thing? Actually, i have trouble to understand, why one has to argue for it.

Dave wrote:

Regarding the parameter value, the description on HEAD says "xinha" or "tinymce" listing the valid values.
It is neither in HEAD nor on oacs-5-5.

The whole discussion boils down to the question: Are the people arguing for making tinymce default are capable/willing to address the various issues and are they capable/willing to take responsibility for tinymce support in a similar way as there is support for xinha, or not. Supporting an additional editor will increase the maintenance work, especially, when it is made the default. For me, it is simply to early to make the decision. My current vote is against making it default.

Emma, thanks. I know what happened: nobody has bumped the version number when the change was done, so the info file is not reloaded, and my up-to-date installation does not show it.... Please don't forget to bump version numbers when updating the info file!
Gustaf,

I didn't bump it because it was already in alpha. My understanding is that only the release manager bumps version number when at alpha and beta stages.

We use special widgets for the content tool, and for assessment as well, more will come.
Based on arguments exposed here, I do not approve the change, until the remaining issues are cleared, and I would prefer to ask first the community about whether they use xinha, or they want to change to something else, and listen the pros / cons of changing to a new editor, which is a very important part of any system that produce content like OpenACS/.LRN.
Based on arguments exposed here, I do not approve the change, until the remaining issues are cleared, and I would prefer to ask first the community about whether they use xinha, or they want to change to something else, and listen the pros / cons of changing to a new editor, which is a very important part of any system that produce content like OpenACS/.LRN.
You (and to some extent Gustaf) are arguing against a strawman, in other words rather than arguing against the TIP, you are arguing against something else of your own invention which is not the TIP.

The TIP is NOT to "switch to a new editor" or "to change to something else".

OpenACS/.LRN has supported *both* TinyMCE and xinha for some time, this TIP does not change that.

This TIP is only to change the *default* editor selected if you change from the default configuration which is NO WYSIWIG AT ALL.

Adoption of this TIP in no way prevents you or Gustaf or others from using xinha.

So please stop arguing that it does. It pisses me off.

The argument for changing the *default*, because out-of-the-box it gives you more accessible and valid HTML without the use of external apps like "tidy", and we claim to support that (I realize that traditionally neither you nor Gustaf consider accessibility to be particularly important, but honchos and the board have decided otherwise).

So we are simply suggesting that we provide a cleaner editor *by default*, not that you stop using xinha.

The whole discussion boils down to the question: Are the people arguing for making tinymce default are capable/willing to address the various issues and are they capable/willing to take responsibility for tinymce support in a similar way as there is support for xinha, or not. Supporting an additional editor will increase the maintenance work...
TinyMCE has been supported for some time now, Gustaf.

This TIP doesn't change that.

Please stop arguing against something that isn't part of the TIP to justify voting against the TIP.

Is this written somewhere? I would agree that only a release manager releases new versions, but i would not agree that it is a good idea to cause inconsistent behavior this way. The question comes down, what "release" means. There should be a way to add updates to the source code repository, which can be tested, without "releasing" this version. If this requires updating the version number, there should be a way to update version numbers without "releasing" it. People who have initially installed 5.5.0a1 before your change see a different behavior than people initially installing the same version after your change. The problem is that even after an update from cvs (and a restart of OpenACS), the behavior is inconsistent. Essentially, a developer with frequent updates is able to test your change only after the version is bumped (which did not happen so far).

Anyhow, this does not belong to the topic of the thread - when it does not happen so often, i can live with it.

Maybe we don't share the same definition of "support". Yes, it is included since a while in OpenACS, but is it supported? If something is default, it should work out of the box and it should be documented how to use it (check the issues above). If people vote for making it default, they either don't care or they don't know about these issues. I would not have brought up maintenance, if there would have been any posting that someone address these.

Just another example, where this impression comes from: the default browser should work with ie8. I tried to figure out, what version of tinymce is in the 5-5 branch. Your posting in the release notes of OpenACS 5.5a1 says 3.1.1, the changelog in the version in the oacs-5-5 branch says 2.13, the .js source file there says 3.2.2.3, while the currently released version is 3.2.4.1 (a few weeks old, why we do not use this one?). Now, try to figure out, whether IE8 works with the included version.

Anyhow, i have spent already too much time on these issues. These are not part of the tip, but necessary to make the decision.

Maybe we don't share the same definition of "support". Yes, it is included since a while in OpenACS, but is it supported?
Maybe you should go to more OCT meetings and take your membership seriously.

Yes, it's supported.

As far as problems go, Daveb is supporting TinyMCE, he's following the thread, and I'm sure he'll fix whatever issues come up.

As far as the version number goes, I got that from Daveb, he can correct it, if it's wrong.

As far as the issue of support goes, we've been discussing TinyMCE and the possibility of making it the default for what seems like forever at our weekly OCT meetings. Really, for OCT members to drop in at the last minute asking "do we support TinyMCE", ignorant of such a basic decision made long ago and discussed often, is just wrong. To veto something at the end while not playing a role in the ongoing decision-making process, is just wrong. To argue that the TIP should be voted down because of a false notion that it will require one to stop using xinha is just wrong.

I would say the version number in the code is correct. Basically its the latest version that was available when it was added to OpenACS.

I have not looked if there was a new version since we added the 3.x version so I was not aware a new version was released. I don't have any system to keep up to date on that.

I added the newer version to add support for the language packs. Personally I don't have a huge amount of time to work on this, but I'll try to address all the issues noted here.

Roceal,

I think the existing of local custom plugins does not affect what editor is available in the core as a default. Of course if something is actually broken, we should fix it. It is not difficult to make plugins for TinyMCE or Xinha either.

I personally don't have a preference for TinyMCE or Xinha as the default. I have not evaluated which one is better for a certain purpose. I did the original work for MGH and added the newer TinyMCE because it supports translations of the TinyMCE interface.

Ok I added per widget config options. You can override any of the tinymce config elements using the same syntax.

Setting {options {editor xinha}} will override the default editor for tinymce or xinha, this already worked as it was built into the richtext widget origianlly when we still supported RTE.

I'll see if I have time to get the OacsFS plugin to work on TinyMCE.

It probably will take 2-3 hours. One good thing of these editors is the plugin architecture. Both editors are very easy to add new plugins.

Thanks Dave. I'll fix the version numbers.
Yes, the default won't affect local install preference (you can change it at any time), this boils down that the online editor it's a matter of preference. The major problem we still face with online editor is the copy/paste from word :p
Gustaf,

(sorry I missed that post of yours)

You said: "didn't you say that for accessibility, javascript has always be deactivated."

Not exactly. I said that the page has to provide the same feature whether javascript is enabled or not. In this case, it means to be able to fill in the textarea form field.

When javascript is enabled, the page still has to be compliant with accessibility guidelines.

Hi all,

I've updated the release notes in acs-core-docs including the right version number. (thks Dave for the upgrade)

I've added the missing message in tinymce (oacslink.desc etc.).

I've updated the doc of template::widget::richtext for tinymce. It was a bit out-of-date. It says that oacsfs scripts live at xowiki, is that still true?

Caveat: the three adp-files needed for the OpenACS file selector (insert-image, insert-ilink and file-selector) are currently part of the xowiki package, since acs-templating is per default not mounted. This is hopefully only a temporal situation and we find a better place.

I don't know if it has been moved to acs-templating but in any case, it means that to use it with xinha it needs xowiki installed or acs-templating mounted.