Can QuickEdit turns into a generic editor driver?

I have been thinking all editor essentially are doing the same thing which turn a regular textarea into a WYSIWYG editor page. So would that be nice to have a driver or module (for example: QuickEdit) to call different snippet that has a custom configuration to know what, where and how on each flavor of editor to call. The flavor of editor can be: noeditor, TinyMCE, Xinha, FCKEditor, etc. So QuickEdit will pick up the editor preference from the system configuration and make the call to the appropriate smippet to invoke the editor.

This way for people that have a differenent preference on editor can pick and choose their editor to install and avoid Modx of beng bloat due to the smiley, icons, etc

Of all the editor that I have encountered they mess up my special javascript or custom HTML coding due to the editor try to be helpful and clean up the HTML code which mess up my page. Many people and myself included most of the time just prefer to use an external editor to do the page creation then just cut and paste the code into the page of CMS.

Is that possible?
What do you think?

Thanks

Quote from: chanh at Sep 09, 2005, 03:16 PM

Is that possible?
What do you think?

I think what you’re looking for is already done.

Edit a user and see the Editor to use: option on the User Settings tab.
That will allow each user to choose their own editor, you can also define default editors in the System Configuration.

Adam,

I don’t see an option for noeditor and currently each editor snippet is part of the respective editor installer.

I am talking about the snippet for each editor is independence from the editor engine itself so if the user is daring and wanting to use the latest bleeding edge version of the editor engine of their choice they can just go to the project site and download the editor engine zip file and drop it into Modx to the right folder. Modx or QuickEdit should not even care what version it is run so as long as it is there.

Another word the differenct flavor of snippet for the various editor should be part of QuickEdit not part of the individual editor themself.

That’s an interesting idea. I don’t know enough about how the editors work to know how plausible it is. Jeff is the real editor guru. I’ll be interested to hear what he has to say.

Well...there’s nothing stopping anyone from downloading the latest version of, say, TinyMCE and uploading it into the plugins folder whether it be an existing folder or a new one of your choosing. You can always duplicate an existing plugin and modify the plugin code as you see fit. However, the problem with editor plugins is the fact that each one has their own little quirks when it comes to it’s configuration. For instance, let’s dissect the TinyMCE plugin a little bit:

With the plugin installed, there are just two configuration settings for the editor itself. The thing about configuration settings is that it allows the user to pick and choose their own options for the most common parameters for that particular editor. Without it, we would have to hardcode static options that can’t be changed unless you edit the plugin code itself.

Now, the call to the editor itself presents some other challenges: Does the user have a CSS entered in the ’Path to CSS file’ option in Interface & Editor settings? And do we even want to allow the use of CSS selectors in the editor? What are the names of the textareas the editor is replacing? Do we need to add the use of the Resource Browser for images, links, and Flash documents? These are all questions that were addressed in the plugin itself. The main one dealt with the Resource Browser. Each of the editors needed to be edited in some way to address the integration of the Resource Browser. In the case of the TinyMCE plugin, a few lines of JavaScript were needed in the .htm files for the image, link, and Flash dialog boxes in order for the Resource Browser to work.

FCKeditor is probably the one that has been hacked the most to allow better integration with MODx as a plugin. The up-and-coming Xinha plugin required very little hacking to get it to work with everything...only thing that was needed was a few new custom MODx specific plugins for the Resource Browser.

The reason I bring this up is to let you know that there is a bit more going on in the background with each plugin that what you might think. Each plugin is crafted to address different configuration settings and compatibility issues...including which features work and don’t work with MODx. To make the editors themselves independent from MODx is simply not possible at this time. There’s a few too many things to consider for any editor to be integrated in as a plugin or otherwise.

However...all is not lost! In the case of the QuickEdit Module/Plugin, we could always make use of the OnRichTextEditorRegister system event and add a configuration option that allows the user to select which editor they wish to use with QuickEdit. This is definitely a possibility. However, the editors themselves would still only have one single set of options...it’s not as if you could use one editor theme with Content Areas and another with QuickEdit for the same editor. This would be something else to address.

Another thing I’ll mention is the whole drop-and-install option for, not just editors, but just about any plugin or module. One of the things that’s been mentioned recently is a method of installing and updating modules and plugins in a manner similar to that of Mambo or the like. It’s something that we’re definitely aware of...but will take some time to implement.

Hopefully, this essay answers most, if not all, of your questions. But if not...heck...I’ll gladly reply back.

P.S. Do we have a need for a ’textarea-only’ editor plugin?

A ’textarea-only’ editor plugin ... as in no RTE? I think so for sure.

Jeff,

Thanks for such an in deepth reply and I appreciated.

I am not suggestion their should not be a plugin specifically written for a particular editor rather I am suggesting that once the plugin has been developed to deal with all the quark of a particular editor then it is like the mapping is in place so it should not care what version of the editor will be using in the future. All the modx plugin for the editor should care it whehter the editor is there and whether the entry point for the editor in available to be call to invoke the edit.

In that case someone can just download an new package from the site drop it in the folder of a particular editor and that’s it. To take it a step further installer for the modx editor plugin should not include the actual editor itself to avoid the bloating of the modx package itself for distribution sake.

How about an option for just plain textarea so if someone has a need to tweak the page without worry that the editor will mess up their custom code?

Thanks

Quote from: chanh at Sep 09, 2005, 09:44 PM

Jeff,

Thanks for such an in deepth reply and I appreciated.

My pleasure! We all love the feedback!

Quote from: chanh at Sep 09, 2005, 09:44 PM

I am not suggestion their should not be a plugin specifically written for a particular editor rather I am suggesting that once the plugin has been developed to deal with all the quark of a particular editor then it is like the mapping is in place so it should not care what version of the editor will be using in the future. All the modx plugin for the editor should care it whehter the editor is there and whether the entry point for the editor in available to be call to invoke the edit.

I agree with what you’re saying and it’s what I’ve been sort of aiming for. Problem is that each of the editors require some tweaks in some shape, fashion, or form, whether it be a plugin for the editor itself, an insertion of some javascript in certain key areas, or some database abstration for a configuration file. If there was indeed a way to just drop in the editor code without the need for any hacking I’d do it in a heartbeat. A strong part of the problem deals with the resource browser...I can tell you that for certain! If all of the editors had a more reasonable way of creating custom calls to a third-party image/file browser the job would be alot easier. I’ve been talking a little bit with some of the others about possibly finding a better resource browser. I’ll be exploring all these options pretty soon.

Quote from: chanh at Sep 09, 2005, 09:44 PM

In that case someone can just download an new package from the site drop it in the folder of a particular editor and that’s it. To take it a step further installer for the modx editor plugin should not include the actual editor itself to avoid the bloating of the modx package itself for distribution sake.

Well...as stated before, probably not right now...maybe later if I can integrate a better resource browser or hack the current one to do what I want it to do without resorting to hacks to the editors. In the meantime, I’ll be doing my best to cut down on the size of the editors by doing away with files that aren’t needed (ie. useless plugins, too many smileys, bogus language files, etc.). All the editor plugins with the exception of FCK are still betas so...there’s just a bit more to go, but they’re all pretty solid right now.

One thing I will say though...since you mentioned Mambo in another thread. If you look at the majority of the Rich Text Editor plugins for Mambo, the majority of them that are based on open-source solutions (FCK, TinyMCE, Xinha, etc.) all of them pretty much include the editor code integrated into the installer. The beauty of Mambo’s use of plugins is the fact that you can install and/or update plugins just by browsing for a zip file and uploading it to the server. Mambo will unzip the plugin, copy the files to the proper directories, and update the database all in one swoop. I absolutely love this concept and I hope that we can get this kind of functionality into MODx real soon. Makes updating plugins and stuff so much easier, wouldn’t you say?

Quote from: chanh at Sep 09, 2005, 09:44 PM

How about an option for just plain textarea so if someone has a need to tweak the page without worry that the editor will mess up their custom code?

One step ahead of you! Already working on this! In fact...I’m think we can just add a ’None’ option since MODx will display a plain textarea by default if a RTE isn’t used. I’ll see if I can get this change committed before the next TP release.

One thing I will say though...since you mentioned Mambo in another thread. Wink If you look at the majority of the Rich Text Editor plugins for Mambo, the majority of them that are based on open-source solutions (FCK, TinyMCE, Xinha, etc.) all of them pretty much include the editor code integrated into the installer. The beauty of Mambo’s use of plugins is the fact that you can install and/or update plugins just by browsing for a zip file and uploading it to the server. Mambo will unzip the plugin, copy the files to the proper directories, and update the database all in one swoop. I absolutely love this concept and I hope that we can get this kind of functionality into MODx real soon. Makes updating plugins and stuff so much easier, wouldn’t you say?

That would be wonderful and power to Modx!

PS: One thing that can be done relative easy to begin with is to standardize on how the zip file is package. If the convention is to do the install after the zip file is unzip into Modx root install then the zip file should all be created with that convention. I should be able to unzip quickedit.zip into modx root and run the install that should go for all zip file that to be installed into Modx.

Is that doable?

Currently some zip file is done that way but some are not I have to unzip into a temp folder then cp into Modx root folder. It is a pain to install resource in Modx at the moment!

Quote from: chanh at Sep 10, 2005, 02:07 AM

If the convention is to do the install after the zip file is unzip into Modx root install then the zip file should all be created with that convention. I should be able to unzip quickedit.zip into modx root and run the install that should go for all zip file that to be installed into Modx.

Is that doable?

Definitely doable! In fact, I agree so much that I’ll be doing this from now on!