Text Editors

Speaking of Xinha, can anyone give me any quick advice on integrating a new RTE into Jojo? I looked a while back and Xinha seemed pretty much hard wired. There was code for it all over the place.

I'm thinking of integrating TinyMCE or probably even elrte since it has an integrated filemanager and it may be possible to tweak it's image manager to add Jojo dimensions support.

Possibly maybe even make an option for the textarea field to attach the RTE to the initial textarea (just disabled) instead of popping it up in a lightbox.

Speaking of Xinha, can anyone give me any quick advice on integrating a new RTE into Jojo? I looked a while back and Xinha seemed pretty much hard wired. There was code for it all over the place. I'm thinking of integrating [url=http://tinymce.moxiecode.com/]TinyMCE[/url] or probably even [url=http://www.elrte.org/]elrte[/url] since it has an integrated filemanager and it may be possible to tweak it's image manager to add Jojo dimensions support. Possibly maybe even make an option for the textarea field to attach the RTE to the initial textarea (just disabled) instead of popping it up in a lightbox.

Ah Xinha...

Oddly enough, Harvey and I were talking about this just the other day. There are apparently already ideas floating around on how to improve it's integration etc. In particular looking at integrating Jojo's image handing into it.

Anyway as far as using a different RTE, I started down the path on trying to workout how to get something else in there an then got side tracked. However I'd think the easiest way would be to create a new field, all be it possibly a little over kill.

Ah Xinha... Oddly enough, Harvey and I were talking about this just the other day. There are apparently already ideas floating around on how to improve it's integration etc. In particular looking at integrating Jojo's image handing into it. Anyway as far as using a different RTE, I started down the path on trying to workout how to get something else in there an then got side tracked. However I'd think the easiest way would be to create a new field, all be it possibly a little over kill.

Sounds good...

The only problems I have with the current Xinha implementation are...

• Seems very separated
• It fills modified elements with "apple-style-span" crap like so many other editors out there
• A bit slow to load
• There doesn't seem to be a a way to remove certain features from the toolbar (eg allow heading selection but remove font-size etc)

These are nothing specifically against Xinha... but I'd just like to get RTEs a bit more pluggable.

I thought about just creating a new textarea field, but I want to avoid duplicating and changing because then it makes it harder to offer the features back to the community.

I did some research a while ago on adding plugins to TinyMCE without them being in its plugin directory. This would allow using the TinyMCE svn repo and adding a plugin to take advantage of Jojo's image dimensions capabilities.

Sounds good... The only problems I have with the current Xinha implementation are... [list] [*]Seems very separated [*]It fills modified elements with "apple-style-span" crap like so many other editors out there [*]A bit slow to load [*]There doesn't seem to be a a way to remove certain features from the toolbar (eg allow heading selection but remove font-size etc) [/list] These are nothing specifically against Xinha... but I'd just like to get RTEs a bit more pluggable. I thought about just creating a new textarea field, but I want to avoid duplicating and changing because then it makes it harder to offer the features back to the community. I did some research a while ago on adding plugins to TinyMCE without them being in its plugin directory. This would allow using the TinyMCE svn repo and adding a plugin to take advantage of Jojo's image dimensions capabilities.

This is something Mike Harvey and I had some discussion about the other day - partly because we'd like to move to jQuery 1.4.2, which completely breaks the jTagEditor.

I have a version of Jojo running that replaces it with the new version (from the same developer) called MarkItUp. It's a lot cleaner and more flexible, but given that I don't actually use it myself (and never use bbcode, which makes even testing difficult) I'm reluctant to commit it without getting a feel from the community first about who actually uses it and whether they'd be happy to help out with cleaning up/debugging the new version.

That discussion prompted some other questions about text editors in general.

For one, we'd like to have the editor in-line (rather than in a pop-up). That much should be reasonably easy to do, and something I'll be looking at once I've finished being distracted by the multi-language stuff.

Mike was going to look at building a Jojo-ised version of Xinha's image manager that will use Jojo's built-in image resizing/caching instead of the clunky version used by Xinha, which would be a big improvement. And stripping out the text-styling buttons.

My personal feeling is that despite it's failings, Xinha is still pretty good, and it's one of the few editors that have a built-in and free image/file manager. I haven't noticed the <span> issue on the recent releases - it seemed to be an apple/webkit issue, which I think they've fixed. It should also load/work faster under jQ 1.4. It's still not 5.3 safe, but I've committed a diff that solves most of those issues.

Mostly though, it's the one that all of our clients have been trained in using, so for that reason alone I'd be reluctant to replace it as a default.


The big issue however, as you've both pointed out, is not so much about what editor you like so much as the inflexibility in the current setup to choose one that you like, or add a new one in.

Mike has been looking at this one
http://forum.wymeditor.org/forum/viewtopic.php?f=3&t=653&p=2429&hilit=upload&sid=d5baca86c61764915aa305fe355bbec7#p2429
as another possible alternative.

So, that's my next project - presuming I don't suddenly get flooded with work that pays actual money, or someone else wants to put their hand up - to work out a way of turning editors into plugins that can be installed/uninstalled at will.

Thoughts welcome

This is something Mike Harvey and I had some discussion about the other day - partly because we'd like to move to jQuery 1.4.2, which completely breaks the jTagEditor. I have a version of Jojo running that replaces it with the new version (from the same developer) called MarkItUp. It's a lot cleaner and more flexible, but given that I don't actually use it myself (and never use bbcode, which makes even testing difficult) I'm reluctant to commit it without getting a feel from the community first about who actually uses it and whether they'd be happy to help out with cleaning up/debugging the new version. That discussion prompted some other questions about text editors in general. For one, we'd like to have the editor in-line (rather than in a pop-up). That much should be reasonably easy to do, and something I'll be looking at once I've finished being distracted by the multi-language stuff. Mike was going to look at building a Jojo-ised version of Xinha's image manager that will use Jojo's built-in image resizing/caching instead of the clunky version used by Xinha, which would be a big improvement. And stripping out the text-styling buttons. My personal feeling is that despite it's failings, Xinha is still pretty good, and it's one of the few editors that have a built-in and free image/file manager. I haven't noticed the <span> issue on the recent releases - it seemed to be an apple/webkit issue, which I think they've fixed. It should also load/work faster under jQ 1.4. It's still not 5.3 safe, but I've committed a diff that solves most of those issues. Mostly though, it's the one that all of our clients have been trained in using, so for that reason alone I'd be reluctant to replace it as a default. The big issue however, as you've both pointed out, is not so much about what editor you like so much as the inflexibility in the current setup to choose one that you like, or add a new one in. Mike has been looking at this one http://forum.wymeditor.org/forum/viewtopic.php?f=3&t=653&p=2429&hilit=upload&sid=d5baca86c61764915aa305fe355bbec7#p2429 as another possible alternative. So, that's my next project - presuming I don't suddenly get flooded with work that pays actual money, or someone else wants to put their hand up - to work out a way of turning editors into plugins that can be installed/uninstalled at will. Thoughts welcome

Getting them inline would be fantastic, but would best suit editors that have a Fullscreen feature. The field tabs area in Jojo is quite narrow as-is. If we were to just make the textarea bigger, it's also be useful to put the basic fields on the same tab as the editor (eg for Pages: Heading, URL, SEO Title, Body) and move all others to other tabs.

What would need to be done to make editors pluggable? Editors would need to be able to...
Add javascript and CSS includes
Add inline javascript to initiate the editor(s)

So the textarea field could fire off hooks, eg...
textarea_editor_external_files - Fires off only once per page that has one or more textareas on it.
textarea_editor_init($fieldid) - Fires off once per textarea instance to allow the editors to initialise themselves

These could both be inside a hook in the textarea field that is called from the admin_edit_bottom hook (I forget it's name). The textarea field could have been keeping track of each field it had displayed then uses this information to run the appropriate hooks to be picked up by the editor plugin.

The editor plugin could then have it's own options etc for handling what toolbars to show and such.

Would any editors need additional hooks/features? Most I've seen are simply triggered by a jQuery call and have a few file includes (css, editor, jQuery theme maybe).

I've seen a few editors around recently that have their own integrated file and image managers (elrte had a very nice implementation of both). An editor that lets you add plugins from other dirs apart from it's own plugins dir would be great. This would let us use their svn repo as an external svn while still integrating plugins into the editor from outside their svn repo. TinyMCE can do this, but I haven't been able to find a decent free image manager for TinyMCE. And although it'd be relatively straightforward to code one, I don't have the time.

Getting them inline would be fantastic, but would best suit editors that have a Fullscreen feature. The field tabs area in Jojo is quite narrow as-is. If we were to just make the textarea bigger, it's also be useful to put the basic fields on the same tab as the editor (eg for Pages: Heading, URL, SEO Title, Body) and move all others to other tabs. What would need to be done to make editors pluggable? Editors would need to be able to... Add javascript and CSS includes Add inline javascript to initiate the editor(s) So the textarea field could fire off hooks, eg... [b]textarea_editor_external_files[/b] - Fires off only once per page that has one or more textareas on it. [b]textarea_editor_init($fieldid)[/b] - Fires off once per textarea instance to allow the editors to initialise themselves These could both be inside a hook in the textarea field that is called from the admin_edit_bottom hook (I forget it's name). The textarea field could have been keeping track of each field it had displayed then uses this information to run the appropriate hooks to be picked up by the editor plugin. The editor plugin could then have it's own options etc for handling what toolbars to show and such. Would any editors need additional hooks/features? Most I've seen are simply triggered by a jQuery call and have a few file includes (css, editor, jQuery theme maybe). I've seen a few editors around recently that have their own integrated file and image managers (elrte had a very nice implementation of both). An editor that lets you add plugins from other dirs apart from it's own plugins dir would be great. This would let us use their svn repo as an external svn while still integrating plugins into the editor from outside their svn repo. TinyMCE can do this, but I haven't been able to find a decent free image manager for TinyMCE. And although it'd be relatively straightforward to code one, I don't have the time.

that all sounds very sensible. I think the only other major change i'd like to make to the current setup is to have one editor and one only, set in options (with the option list populated from whatever texteditor plugins are installed) - partly just to make the coding easier, but hopefully also making it less confusing.

I imagine that Xinha and BbCode would be plugins installed with the core set (at least to begin with). MarkItUp could probably be added to jojoplugins (unless there's a general outcry... does anyone use it regularly?)

Without having looked at it much, if multiple editors were a requirement, I'm guessing it could work something like the way the cart and product plugins do at present - a general function in the core texteditor field file that checks for any plugins that register themselves as doing texteditor handing.

that all sounds very sensible. I think the only other major change i'd like to make to the current setup is to have one editor and one only, set in options (with the option list populated from whatever texteditor plugins are installed) - partly just to make the coding easier, but hopefully also making it less confusing. I imagine that Xinha and BbCode would be plugins installed with the core set (at least to begin with). MarkItUp could probably be added to jojoplugins (unless there's a general outcry... does anyone use it regularly?) Without having looked at it much, if multiple editors were a requirement, I'm guessing it could work something like the way the cart and product plugins do at present - a general function in the core texteditor field file that checks for any plugins that register themselves as doing texteditor handing.

You're proposing to only have one editor active across the entire site, yes? Just to clarify, does that mean one WYSIWYG editor and BBCode active (and choosable per item), or only one editor (eg BBCode OR one WYSIWYG OR Markdown type editor?

I just found a flaw in my suggestion above... We need to account for there being two editor plugins installed at once. So we need to allow for choosing between installed editor plugins (eg from the Options area), and make the core only use that specific editor plugin or drop back to plain html in the textarea if the selected plugin has somehow been uninstalled.

Almost doing it your way... Making the textarea field grab the editor class name from options and call standard function names instead of using hooks like my example would prevent more than one editor plugin trying to use each textarea even if they were installed.

All we'd need then, is maybe create a core function (or would it belong in the textarea field) to register each editor at setup. This function would update a radio list in the options table with applicable class and display names. That sounds a bit hack-ish... there must be a better way to make the editor easily selectable by the user, eg without having to enter a classname.

You're proposing to only have one editor active across the entire site, yes? Just to clarify, does that mean one WYSIWYG editor and BBCode active (and choosable per item), or only one editor (eg BBCode OR one WYSIWYG OR Markdown type editor? I just found a flaw in my suggestion above... We need to account for there being two editor plugins installed at once. So we need to allow for choosing between installed editor plugins (eg from the Options area), and make the core only use that specific editor plugin or drop back to plain html in the textarea if the selected plugin has somehow been uninstalled. Almost doing it your way... Making the textarea field grab the editor class name from options and call standard function names instead of using hooks like my example would prevent more than one editor plugin trying to use each textarea even if they were installed. All we'd need then, is maybe create a core function (or would it belong in the textarea field) to register each editor at setup. This function would update a radio list in the options table with applicable class and display names. That sounds a bit hack-ish... there must be a better way to make the editor easily selectable by the user, eg without having to enter a classname.

I had thought just one editor (this is just for admin - you could, and probably would, want different ones for the public side). For myself I only use Xinha or the raw HTML, and for clients I only ever show them Xinha, so for me BBCode and JTag are just unnecessary distractions - but maybe that's just me and I'm quite happy to take direction on that.

There are cases where it wouldn't work - editing forum posts like this one from the backend for example, where it's in BBCode and I'd have an HTML editor set.

Your approach sounds good to me. I'm not likely to start looking at it properly for another week or so though, so there's be plenty of time for alternative suggestions should others have a different view, and I'll post findings as I discover them once I'm actually in the code.

I had thought just one editor (this is just for admin - you could, and probably would, want different ones for the public side). For myself I only use Xinha or the raw HTML, and for clients I only ever show them Xinha, so for me BBCode and JTag are just unnecessary distractions - but maybe that's just me and I'm quite happy to take direction on that. There are cases where it wouldn't work - editing forum posts like this one from the backend for example, where it's in BBCode and I'd have an HTML editor set. Your approach sounds good to me. I'm not likely to start looking at it properly for another week or so though, so there's be plenty of time for alternative suggestions should others have a different view, and I'll post findings as I discover them once I'm actually in the code.

On further thought, it will be necessary to allow for multiple editors to be installed and active as options (much like they are at the moment).
What would be good though is to find a way of getting rid of the body_code field. As far as I can tell, it's only BBCode (and the other markup languages) that actually need it.

What may be preferable is to have a single field for HTML and convert it on the fly into BBCode or whatever for editing. I don't know how feasible that is but if it's doable it would simplify things considerably (albeit by making the BBCode editor more complex).

It would also mean that you could switch editors whenever you liked without it being a one way street as it is at the moment - once you switch a page to Xinha there's no going back to BBCode - and different people could use the editor of their choice even when both editing the same page.

I'm guessing you'd need some fandangle parsing to do the conversion, and some handling for elements that can't be parsed/rendered in the target markup, but.. maybe?

On further thought, it will be necessary to allow for multiple editors to be installed and active as options (much like they are at the moment). What would be good though is to find a way of getting rid of the body_code field. As far as I can tell, it's only BBCode (and the other markup languages) that actually need it. What may be preferable is to have a single field for HTML and convert it on the fly into BBCode or whatever for editing. I don't know how feasible that is but if it's doable it would simplify things considerably (albeit by making the BBCode editor more complex). It would also mean that you could switch editors whenever you liked without it being a one way street as it is at the moment - once you switch a page to Xinha there's no going back to BBCode - and different people could use the editor of their choice even when both editing the same page. I'm guessing you'd need some fandangle parsing to do the conversion, and some handling for elements that can't be parsed/rendered in the target markup, but.. maybe?

Theres a jojo_html2bbcode plugin in the repo. It uses the same class that Jojo uses to convert BBCode to HTML, but now uses it in reverse.

plugins/jojo_core/external/bbconverter/bbconverter.class.php

I don't know how well it works... I've never tried it as I've always avoided using BBCode because I rather like <p> instead of <br /><br /> tags.

As good as it may be, imagine it may lose some attributes, and I doubt it could convert the [thumb] or [mag] tags back and forth.

It'd be even worse if anyone wanted to use a markdown style editor. I don't know how we can fix this though.

Theres a jojo_html2bbcode plugin in the repo. It uses the same class that Jojo uses to convert BBCode to HTML, but now uses it in reverse. [code]plugins/jojo_core/external/bbconverter/bbconverter.class.php[/code] I don't know how well it works... I've never tried it as I've always avoided using BBCode because I rather like [code]<p>[/code] instead of [code]<br /><br />[/code] tags. As good as it may be, imagine it may lose some attributes, and I doubt it could convert the [code][thumb][/code] or [code][mag][/code] tags back and forth. It'd be even worse if anyone wanted to use a markdown style editor. I don't know how we can fix this though.

Sorry, I'm a bit late joining in on this post, was having feed reader issues. Tom kindly pointed it out while he was in our office this morning.

Early on it Jojo we tried the whole html back to bbcode thing but it wasn't reliable with too many html variations to consider.

What I have been wanting to do for about a year is get rid of the _code columns and replace them with a separate database table - which I don't yet have a name for. The columns (in my head) are:
table, column, rowpk, format, content
With an example row being something like:
page, pg_body, 1, bbcode, 'BBcode content for the homepage here'

This is where the text editors would store their raw content, and they would always store their outputed html into the real column. This way we just need to assign the text editor to a column, and not create a second column every time.

It would only work on tables that have a single column primary key as I have only allowed for one column (3rd one) to store the primary key in. From memory a number of things break in Jojo when you try working with a table with a multi column primary key anyway.

I haven't written any code around this yet though.

Sorry, I'm a bit late joining in on this post, was having feed reader issues. Tom kindly pointed it out while he was in our office this morning. Early on it Jojo we tried the whole html back to bbcode thing but it wasn't reliable with too many html variations to consider. What I have been wanting to do for about a year is get rid of the _code columns and replace them with a separate database table - which I don't yet have a name for. The columns (in my head) are: [code]table, column, rowpk, format, content[/code] With an example row being something like: [code]page, pg_body, 1, bbcode, 'BBcode content for the homepage here'[/code] This is where the text editors would store their raw content, and they would always store their outputed html into the real column. This way we just need to assign the text editor to a column, and not create a second column every time. It would only work on tables that have a single column primary key as I have only allowed for one column (3rd one) to store the primary key in. From memory a number of things break in Jojo when you try working with a table with a multi column primary key anyway. I haven't written any code around this yet though.

As far as the existing editors, I use the jtag inline editor quite a lot for adding tags around plain text content. And seldom use xinha - but our clients do. I don't use bbcode at all.

As far as the existing editors, I use the jtag inline editor quite a lot for adding tags around plain text content. And seldom use xinha - but our clients do. I don't use bbcode at all.

Moving the _code column to another table is nice as it cleans up the original tables. But two things that come to mind are... it still doesn't allow direct compatibility with other editors (you can't edit a page in bbcode then go back and edit it with an html editor, then bbcode again). And two, it'll take a extra steps to maintain the table, including deleting rows as pages/articles are deleted.

Moving the [code]_code[/code] column to another table is nice as it cleans up the original tables. But two things that come to mind are... it still doesn't allow direct compatibility with other editors (you can't edit a page in bbcode then go back and edit it with an html editor, then bbcode again). And two, it'll take a extra steps to maintain the table, including deleting rows as pages/articles are deleted.

I don't think this is ever going to be possible. I can't see how you could ever convert html back to bbcode or markdown without loss. There's just not a one to one mapping in there, unless the html editor was really stripped down to the lowest common denominator.


I believe we already have delete events and hooks in place to cover all of these cases. I think that's the easy bit to manage.

[quote=Rick]Moving the [code]_code[/code] column to another table is nice as it cleans up the original tables. But two things that come to mind are... it still doesn't allow direct compatibility with other editors (you can't edit a page in bbcode then go back and edit it with an html editor, then bbcode again). [/quote] I don't think this is ever going to be possible. I can't see how you could ever convert html back to bbcode or markdown without loss. There's just not a one to one mapping in there, unless the html editor was really stripped down to the lowest common denominator. [quote=Rick]And two, it'll take a extra steps to maintain the table, including deleting rows as pages/articles are deleted.[/quote] I believe we already have delete events and hooks in place to cover all of these cases. I think that's the easy bit to manage.

It'd be nice to be able to edit any rich text area with any editor, but you're right, it's not realistically possible.

It'd be very nice to get rich editors nice and pluggable though... From what Tom and I came up with above, can you see anything we might've missed?

It'd be nice to be able to edit any rich text area with any editor, but you're right, it's not realistically possible. It'd be very nice to get rich editors nice and pluggable though... From what Tom and I came up with above, can you see anything we might've missed?

I started thinking that for cases like the forum we only need one-way conversion anyway, the admin can edit the posts in html... but then I remembered that'd break the user editing their own posts, and the quote feature.

The Wiki another front-end use of bbcode. It might be best to stick with both html and bbcode support.

I started thinking that for cases like the forum we only need one-way conversion anyway, the admin can edit the posts in html... but then I remembered that'd break the user editing their own posts, and the quote feature. The Wiki another front-end use of bbcode. It might be best to stick with both html and bbcode support.

If the editors were plugin based there's no reason why other plugins couldn't re-use them - it would just create a dependency, so that if you wanted to install the forum plugin, you'd also need to install a compatible editor if one wasn't installed already. The admin would need to edit them in the same edit language as it was posted in anyway to avoid breaking further editing by the poster.

It might allow for more flexibility there also, allowing for either bbcode or tinymce as the forum editor for example (as options to set it up with I mean, not as options for the user).

I imagine the setup would be much the same as for the admin side - the display is from the main html body field but editing is done through the code field/table - just with different options for the editor if it's public.

Would be nice to have a proper editor menu for the forum, rather than assuming people know how to type in bbcode like it does at the moment

If the editors were plugin based there's no reason why other plugins couldn't re-use them - it would just create a dependency, so that if you wanted to install the forum plugin, you'd also need to install a compatible editor if one wasn't installed already. The admin would need to edit them in the same edit language as it was posted in anyway to avoid breaking further editing by the poster. It might allow for more flexibility there also, allowing for either bbcode or tinymce as the forum editor for example (as options to set it up with I mean, not as options for the user). I imagine the setup would be much the same as for the admin side - the display is from the main html body field but editing is done through the code field/table - just with different options for the editor if it's public. Would be nice to have a proper editor menu for the forum, rather than assuming people know how to type in bbcode like it does at the moment

Xinha has been falling short a bit recently so over the weekend I stripped Xinha back to being merely plugged in via the /edit/ system. I then created a plugin that throws CKEditor in there. The integration is rough round the edges but it's only a proof of concept.

I'll pull it back further to merely be plugged in via the Texteditor field. I guess the ultimate goal is to combine some of the ideas above and end up with

• a completely rewrite of the Texteditor field
• the ability to add editors of any style (bbcode, markdown, html etc) (Tom's idea)
• editors store their code in a separate table and specify the language and editor (mikec's idea)
• the Texteditor field handles swapping the data in/out with the editor plugin on save/load
• the Texteditor field has a dropdown list above it that lists available editors
• Leave BBCode as a required language for backwards compatibility

All this would require lots of thought. Eg

• do we drop the lightbox from the field?
• do we let more than one HTML WYSIWYG editor installed at once?
• how do we load each editor instance on demand?
• if a field was edited by one editor, what happens when you change editors or that editor is removed?

All of this is a one day dream, for now I'm focussing on getting other editors pluggable but it's not often I'm getting time so it'll be a while.

Xinha has been falling short a bit recently so over the weekend I stripped Xinha back to being merely plugged in via the [code]/edit/[/code] system. I then created a plugin that throws CKEditor in there. The integration is rough round the edges but it's only a proof of concept. I'll pull it back further to merely be plugged in via the Texteditor field. I guess the ultimate goal is to combine some of the ideas above and end up with [list] [*]a completely rewrite of the Texteditor field [*]the ability to add editors of any style (bbcode, markdown, html etc) ([i]Tom's idea[/i]) [*]editors store their code in a separate table and specify the language and editor ([i]mikec's idea[/i]) [*]the Texteditor field handles swapping the data in/out with the editor plugin on save/load [*]the Texteditor field has a dropdown list above it that lists available editors [*]Leave BBCode as a required language for backwards compatibility[/list] All this would require lots of thought. Eg[list] [*]do we drop the lightbox from the field? [*]do we let more than one HTML WYSIWYG editor installed at once? [*]how do we load each editor instance on demand? [*]if a field was edited by one editor, what happens when you change editors or that editor is removed?[/list] All of this is a [i]one day[/i] dream, for now I'm focussing on getting other editors pluggable but it's not often I'm getting time so it'll be a while.

Hi Rick,

"if a field was edited by one editor, what happens when you change editors or that editor is removed?"

So long as you have a default editor for each language then if someone removed an editor you can still edit it. The issue is only to do with editing as we don't use and editor code to display things publicly.

cheers,
Antony

Hi Rick, "if a field was edited by one editor, what happens when you change editors or that editor is removed?" So long as you have a default editor for each language then if someone removed an editor you can still edit it. The issue is only to do with editing as we don't use and editor code to display things publicly. cheers, Antony

Hi Antony,

The way that mikec suggested would leave an html copy of the content in the page table at all times, so the editor's code (eg bbcode) would never make it to the public side. (Aside from forums etc).

But I don't think we can simply have a default editor installed for each language as that would make it bulky and harder to maintain. The idea would be to make the editors/languages completely pluggable. So we could ship with BBCode and an HTML WYSIWYG and plugins could add MarkDown or any other language people prefer.

Some basic ideas:

• I think we'd need to store the editor name and language in the table that houses the copy of the editor's code (as per mikec's suggestion)
• Still keep the option for the "default" html editor as this won't require mikec's table
• editor plugins use a "provides" api to tell Jojo their editor name, class and what language they're for
• the /edit/ system auto switches editors depending on what the field was last saved with
• if a field was edited using an editor that was removed, use another editor for the same languge (if available)
• if not available, then show an error and dump in either the saved html, stripped html or the old editor's code

That's my idea for pushing towards flexibility... I don't actually require anything except an HTML WYSIWYG for my clients so that's where my focus is.

Hi Antony, The way that mikec suggested would leave an html copy of the content in the page table at all times, so the editor's code (eg bbcode) would never make it to the public side. (Aside from forums etc). But I don't think we can simply have a default editor installed for each language as that would make it bulky and harder to maintain. The idea would be to make the editors/languages completely pluggable. So we could ship with BBCode and an HTML WYSIWYG and plugins could add MarkDown or any other language people prefer. Some basic ideas:[list] [*]I think we'd need to store the editor name and language in the table that houses the copy of the editor's code (as per mikec's suggestion) [*]Still keep the option for the "default" html editor as this won't require mikec's table [*]editor plugins use a "provides" api to tell Jojo their editor name, class and what language they're for [*]the /edit/ system auto switches editors depending on what the field was last saved with [*]if a field was edited using an editor that was removed, use another editor for the same languge (if available) [*]if not available, then show an error and dump in either the saved html, stripped html or the old editor's code [/list] That's my idea for pushing towards flexibility... I don't actually require anything except an HTML WYSIWYG for my clients so that's where my focus is.