Editor support in future version of ImpressCMS

What is the general consensus? How soon can we dump the DHTML editor from the core?

Basically, it's a pain to support the differences in how to handle html v. non-html markup. Any of the wysiwyg editors can have a stripped down toolbar with only the basic options on them, just like the dhtml editor has.

I think we can dump dhtml yesterday.

Great initiative Steve. You know my opinion already since we were talking about it yesterday.

For all the others: Remove all editors except one and stick to it once and forever. Make it customizable via the ACP for different groups and that's it.

One little wish from my site: We should make something out of this conversation (and not just talk about something). Actions should result out of it!

yesterday would be nice.

y the need for more than 1 editor i don't know. it's a burden, i've been saying this for a long time.

take a look at wordpress.. they only use 1 editor, and their interface for tinymce is superb. stick with tinymce and make an admin interface for it so that it can be customised on a group level.

I'm in the quality not quantity camp as well. One good editor and everyone knows what to expect and is running out of the box.

I'm for TinyMCE as well.
We still have to remember there's 1 problem.

The extra linebreak we get in certain modules when we edit content with TinyMCE. I think it still isn't resolved.
And I wonder whether if we put something in BBcodes (dhtml editor does that) that the BBcodes get saved or that it gets to be turned around to actual HTML.

I agree with the above - except to add - we should make it as easy as possible to change in the future - just in the unlikely case that a better editor comes along.

Would it be fairly straightforward to provide code to migrate text from the plain editor to the new one in upgrades?

And how would this effect BBCodes etc?

Would this effect the code editors - such as the editor Mekdrop's autotask function uses, or purely on the user/data aspect?

Thank you Steve for the great topic.

Let me explain about my last work:

I love the TinyMCE, because you can write very easy and fast the Text. Our Plugins from the TinyMCE (especially the image-manager) is the best feature. And you can switch between WYSIWYG and HTML very easy. But sometimes you like to get an other editor for the users. Example: The guest can write a comment in the modules, but he can see only a complicate DHTML Edit. You can not select an easy editor like a textarea.

Here we are on the second problem. You can not choose in the ACP the Editor to the modul especially for the comments, the comments are not a module.

And the third problem is, at the moment it's easy to create a new editor, but you can select only one editor as a "WYSIWYG" editor. (@phoenyx know's what I would like to say.)


My personal ambition:
- Make the comments as a module
- Take the TinyMCE and create 5 selectable toolbars for the user-groups and modules
- create an "textarea" editor
- the admin can select for all modules in all groups an editor

1. Textarea
2. DHTML editor
3. TinyMCE full toolbar
4. TinyMCE a little less
5. TinyMCE less
6. TinyMCE still less
7. TinyMCE fewest of all



My English is better now but not the best. I hope you can understand me.

if we filter on input (like should be done) then the bbcodes will be turned into html before saving to the DB. personally i think that's the best way. ok you may argue that people like bbcode, but it's antiquated and was only ever designed to use on text when HTML wasn't allowed to give people some control of formatting. an HTML editor then who needs bbcode.

on a performance point of view, filtering the bbcode on output and converting the code to HTML on output seriously slows the site down.

20 articles with a lot of bbcode in them, each article is converted before the page is displayed = increased page loading time.

convert the bbcode on input, then there's no need to do it on output, which means rendering the page is far quicker.

remember, the whole point of the WYSIWYG editor is to ease use, if you want to bold text you can either do it in HTML source mode, or on the WYSIWYG, highlight and click the bold button. who needs bbcode? people who aren't familiar with HTML (and to be frank, anyone wanting to build a website should be expected to at least learn something) will most likely use WYSIWYG mode, more knowledgeable people would probably use html source mode.

The defination level for TinyMCE would be a good idea - to control what different user groups have access to.

@sato-san: You're mentioning 3 different editors again: textarea, dhtml and tiny. We want to go for ONLY ONE OF THEM!

As far as opinions were mentioned, TinyMCE will make the race. We just have to work on the customizability and that's it.

BBCode can be removed completely once we are on TinyMCE.

Filtering on Input instead of output: GREAT! This will also help us with the htmlpurifier because we should deactive it for any content that is entered by the administrator.

This post is really about empowering the content creators - simplify the way people add text and media to a site.

The purpose of the original post was to make a decision on the DHTML editor. That's easy - everyone seems to be willing to get rid of it. 1 decision and we're on to the next decision.

Since 1.3 is all about optimization and standardazation, I think this falls into a feature change for the next release (1.4). When Phoenyx and I were talking, we discussed having to handle this during an upgrade - it involves removing configuration options, changing system preferences, changing group permissions and possibly dealing with lots of old content that would be in the db, filled with bbcodes.

As for which wysiwyg editor, I don't think we'll ever agree on which is 'best'. I think TinyMCE is OK, but I much prefer even the old FCKeditor over it. But, that is not the goal of this post.

No more DHTML!

So we have one of our first tasks for 1.4. Great!

Quote:

yes that is 1 good reason, the main reason and advantage of filtering the input as opposed to output is that filtered Input would mean that all the content stored in the DB is actually Safe with no harmfull or malignant code in there at all, which means a relaxed set of filters for output filtering, of course some output filtering will still be required to prevent XSS & SQLi etc, but it wouldn't need to be filtering on the content, just mainly the URI & $_REQUEST & $_GET etc, and i've already started working on that process with the DataFilter, TextFilter & HTMLFilter classes, though i think the textfilter class will be redundant and can move that to datafilter. it's just complicated at moment to implement fully because of the different editors in use, having 1 editor will effectively make this system easier to implement.

It will certainly be a fun task for 1.4

Quote:
Changing the old BBcodes to actual HTML during an upgrade could involve a good lesson in regular expressions. Steve can teach some of us about that (maybe in a blog post or wiki document?)
We have to list what needs to be done.
I would like to have the upgrade done, but then be able to choose to convert the BBcodes now or later and on which modules.
Really interesting and good to look forward to.

Simplifying the core to use only 1 editor seems to me the logical way to go. I still remember the difficulties we had with the different editors for 1.2.

For the conversion, keep in mind that we need to include as much modules as possible in the process.

Also, when this makes the content filtering easier (as I understood from Vaughan's post), that's certainly an added bonus.

Quote:
For 1.3, we need to go over all the modules anyway, so this could just be 1 of the tasks we need to do.

Quote:
Just installed TinyMCE version 3.3.9.2 on my testserver and the extra linebreak issue seems not to be solved yet.

EDIT: I don't think it's TinyMCE that's adding the extra linebreak but the core. There are no extra linebreaks added when text is saved to the database, but only when it's displayed on a websites frontpage.

try adding



to the render function in tinymce.php

so it looks like the following




let me know how it goes.

The extra linebreak isn't added by TinyMCE but by this function:

in class/module.textsanitizer.php