Standardize the CMS to use a single Richtext editor?#

Hello Everyone ,

The weight of the cms files inside jason's branch now stands at 13+ MB The media files alone takes up 9+ MB. I think the increase in size is due to the new richtext editors.

IMO we should distribute the cms editors with only the default language (en). We can then provide the full multi-langage versions of the editors in a separate down. We also need to look for common features between the two editors and merge were possible things like the simley icons, etc.

I'm thinking do we really need two editors? From the looks of things I would have to say that FCKEditor has the larger developer base of the two editors. It's ranked as #3 on SF as the most active project. It has more HTML features than TinyMCE (but might not be as simple). The plugin interface seems very easy to adopt. And it seems to process things faster than TinyMCE. Having a single editor would mean that we only have to create one plugin to extend that editor. Having two editor means that one editor might lag behind the other in terms of features.

What do you think about standardizing on a single Richtext editor?

Hello Everyone ,

The weight of the cms files inside jason's branch now stands at 13+ MB The media files alone takes up 9+ MB. I think the increase in size is due to the new richtext editors.

IMO we should distribute the cms editors with only the default language (en). We can then provide the full multi-langage versions of the editors in a separate down. We also need to look for common features between the two editors and merge were possible things like the simley icons, etc.

I'm thinking do we really need two editors? From the looks of things I would have to say that FCKEditor has the larger developer base of the two editors. It's ranked as #3 on SF as the most active project. It has more HTML features than TinyMCE (but might not be as simple). The plugin interface seems very easy to adopt. And it seems to process things faster than TinyMCE. Having a single editor would mean that we only have to create one plugin to extend that editor. Having two editor means that one editor might lag behind the other in terms of features.

What do you think about standardizing on a single Richtext editor?

And as much as I like FCK's latest features, I'm still torn between editors, as I really like a lot of the features in TinyMCE.

I'd prefer if we kept this option, except I propose we provide a little more abstraction and the ability to plug-in/roll-your-own editor. We can slim down these installs for sure (I'll clean up what isn't needed). Then I suggest we offer our modified editor installs as separate add-ons to the product. In other words, don't ship with any RichText editor, and allow users to choose from the array of pluggable editors available on our site.

Abstraction points include:

* Custom configuration properties for individual editors (perhaps on their own manager tab?)
* TV rich-text control scripts / mergeContent() in document.parser
* Manager document editing / mutate_content.dynamic.action

Then later we can add an auto-installer in the Manager for the packages along with a definition for defining an editor package for MODx.

If Ryan will add the abstraction points as tasks for next release, I'll see if I can get 'er done, unless there are objections to this approach?

I'm also torn between the two. I like TinyMCE and I like FCKEditor. But FCKEditor support some power formbuilding features that are very impressive.

If we should choose the path of separating the editors then I think the CMS should be shipped with a default Richtext editor. Most users want an out of the box solution.

It shouldn't be difficult to implement additional editors in a separate install package. They could even be installed as plugins to the system. Just imagine a plug-able editor can be made to listen to an OnReplaceTextarea event that will allow it to generate js codes to replace the selected textareas. Upon install it can be made to render it's own system settings inside the configuration screen. So each editor will render it's own confiration settings both for the system or for a user. This way everything is contained with the plugin. And should the user choose to disable the plugin then every thing is removed until it's enabled again.

what do you think?

I'm also torn between the two. I like TinyMCE and I like FCKEditor. But FCKEditor support some power formbuilding features that are very impressive.

If we should choose the path of separating the editors then I think the CMS should be shipped with a default Richtext editor. Most users want an out of the box solution.

It shouldn't be difficult to implement additional editors in a separate install package. They could even be installed as plugins to the system. Just imagine a plug-able editor can be made to listen to an OnReplaceTextarea event that will allow it to generate js codes to replace the selected textareas. Upon install it can be made to render it's own system settings inside the configuration screen. So each editor will render it's own confiration settings both for the system or for a user. This way everything is contained with the plugin. And should the user choose to disable the plugin then every thing is removed until it's enabled again.

what do you think?

I think that sounds perfect. Anyone else?

I don't really have an opinion on either editor except that I agree with Raymond, FCK does seem to be very active right now. But the point of supporting just one of the editors is a very good one. With 2, that's just more scarce resources that have to be leveraged. It's hard enough maintaining 1 rich-text editor, especially if we look to extend it for image browsers, internal link dialogs, etc.

I prefer TinyMCE, because it is close to supporting Safari already, and I've not seen if the FCK editor rc is anywhere close. The TinyMCE developers are actually purchasing a Mac Mini for testing and development.

I prefer TinyMCE, because it is close to supporting Safari already, and I've not seen if the FCK editor rc is anywhere close. The TinyMCE developers are actually purchasing a Mac Mini for testing and development.

For the technology preview 2 release, I think we should include them both and I'll do everything I can to get the individual image managers and such working well by default and providing plenty of options for getting the optimum experience out of each preferred editor.

Everybody likes something different, and the bulk will be reduced significantly once we remove HTMLArea from the package completely. I'll work on replacing those dependencies as well. I know that Raymond really likes the image manager/editor, but we can work to re-integrate that piece if necessary, or find something better.

Everybody likes something different, and the bulk will be reduced significantly once we remove HTMLArea from the package completely. I'll work on replacing those dependencies as well. I know that Raymond really likes the image manager/editor, but we can work to re-integrate that piece if necessary, or find something better.

We can still roll with both editors for the short term but I think the long term is to find a single solution. Maybe we could get some developers to integrate both into a single editor? Maybe something like TinyFCK
In the meanwhile we should seek to merge the functionality of bother editors where possible.

Here's what I propose:

1) leave the media/editor folder for storing commonly used editor objects
2) create a new theme default theme for both editor so that they will look for common images, plugins inside the edior folder. Thinks like the simley images can go here.
3) use one set of icons for both toolbars. Copy these to editor/images and point the theme to that folder

This could be the first step in the creation of the TinyFCK editor. We could even make this our first sub project when after we have officially launched the CMS. I can see it now "TinyFCK - The ease of TinyMCE with the power of the FCKEditor"

P.S. On the subject of HTMLArea... It's only 700k in size but it's Image Editor blows away TinyMCE and FCK Very soon they will catch up for sure.

P.S. On the subject of HTMLArea... It's only 700k in size but it's Image Editor blows away TinyMCE and FCK Very soon they will catch up for sure.

Do you mean the image browser or is there a new HTMLarea plugin I don't know about?

P.S. On the subject of HTMLArea... It's only 700k in size but it's Image Editor blows away TinyMCE and FCK Very soon they will catch up for sure.

Do you mean the image browser or is there a new HTMLarea plugin I don't know about?

The Image browser