Forum OpenACS Development: Supporting tinymce in xowiki

How extensible and modular is it? With xinha you can configure the toolbar for instance.

is your intention to replace xinha completely by TinyMCE?

why new parameters. you should be able to use {options {editor EDITOR plugins {YOURPLUGINS}} in the richtext widget.
https://openacs.org/api-doc/proc-view?proc=template%3a%3awidget%3a%3arichtext

what is the problem with the back-button in xinha? OpenACS 5.3.1 uses HTML 4.01 Transitional, not xhtml.

I just changed this line of code:

{text:richtext(richtext),nospell,optional
{label #xowiki.content#}
{options {editor [parameter::get -parameter "RichTextEditor" -p\
ackage_id [apm_package_id_from_key "acs-templating"] -default "xinha"] plugins {
[parameter::get -parameter "XowikiXinhaDefaultPlugins" -default [parameter::get\
_from_package_key -package_key "acs-templating" -parameter "XinhaDefaultPlugins\
"]]

to check the acs-templating parameter instead of always using Xinha. Perhaps we need an expression in there to fallback to xinha or tinymce if RTE is choosen? How many people are still using RTE?

I guess it would make sense to change the parameters form XinhaDefaultPlugins to RichtextEditorDefaultPlugins? I will look into documenting the available plugins and choosing defaults for TinyMCE as well.

I have a request from a client to make the entire config object for TinyMCE available as a parameter.

I think it makes sense to modify the Xinha support to work in a similar way, instead of having a parameter for each seperate attribute of the config object. Right now Xinha config has two parameters, for plugins and toolbar buttons.

The basic structure would be a tcl list in array format of the attribute name and value.

I decided on a list after noticing that the current xinha support allows overriding the config with a parameter passed to the ad_form element delcaration. This way it would be possible to override the default config attributes on an individual basis for one richtext element by specifying a list of attribute names and values for that element. Then when the richtext widget is created it will be posible to loop through the default config and replace any overridden attributes with the element specific ones.

I should have an implementation of this by the beginning of next week, for review.

If anyone has a better idea please share. This seemed like the most flexible way to handle it that supports the current richtext requirements and allows more general support for TinyMCE and Xinha.

If people want to switch between Xinha and tinymce, it looks as a bad idea to use the same parameter with different content for Xinha and TinyMCE. How about introducing a parameter TinyMCE_Config?

Hi Dave,

I had a look at TinyMCE and I liked it a lot, nice work!. I had to tweak it a bit to make the "openacs" theme work on HEAD (committed) but couldn't make the oacsimage and oacslink plugins work. It will need some HTML strict cleanup too.

Tinymce on HEAD is version 2.1.3, the last one available is 3.1.1. I think we should upgrade, I can help with that. Right now, only english is available but if we upgrade, we'll be able to provide all the available languages (http://services.moxiecode.com/i18n/). The downside is that the API has changed in version 3.x so we'd have to adapt the oacs plugins and openacs theme, but it won't require too much effort I guess.

I agree that new parameter(s) should be created to hold the tinymce configuration. It may be worth to separate the different section of the configuration into different parameters (see http://wiki.moxiecode.com/index.php/TinyMCE:Configuration for reference): one parameter for the theme configuration, one for plugins, and one for general stuff. One might want to use the openacs theme but not the oacs plugins, in this case, the default would be kept for the theme parameters and the user would have to edit the plugins one only.