Problem with TinyMCE in Chrome

[Joss]

By the way, the idea I'm hatching is actually a variety of WYSIWYG - I'm not saying a content editor shouldn't show you what you get, I definitely think it needs to do that, for clients to understand and connect with what they're creating. I'm saying a content editor can be richer, more structured, and more user-friendly - it should be able to drive meaningful decisions, produce beautiful, consistent output, and, well, all the shit you don't get from an HTML WYSIWYG

Just repeating myself from another thread (er, it may have been this one earlier):

I think for many fields where you want some basic typography, the jquery/html5 basic editors that are popping up everywhere are perfect.

They look nice, are very clean and are fast. 

For most of the time you really only want B/I/U, left, centre, right, justified, header1-4 and optional links and image insert.

Oh, and automatic paste as plain text.

Often you probably only need bold and italic!

That does not mean there is no place for TinyMCE or equivalent, just not most of the time.

Something I have done before is to simply create a range of custom styles and the only box in the editor is just the styles dropdown.

But it does seem overkill to load the entire TinyMCE script just for a dropdown!

[ryan]

What are some other editors you've seen that seem good? I've not kept up with these so well and am wondering if there are any standouts right now. Of course redactor looked great, but not something that can be bundled in a GNU open source software. 

[Joss]

Redactor is nice, but I would go even simpler

http://xing.github.com/wysihtml5/ (doesn't need jquery)

And there is a Bootsrap version of the same editor:

http://jhollingworth.github.com/bootstrap-wysihtml5/

It seems pretty customiseable and straight forward.

There is also

http://jqueryte.com/

But I have never used it.

Obviously Aloha - but it is really aimed at front end than back end.

There is also http://jhtmlarea.codeplex.com/

Not updated since last august and really needs better buttons!

I think the xing one is the sort of thing that would be most useful, probably because it can be built to our own specs (as the bootstrap version demonstrates) - the basic version on the github site does not even have graphic buttons!

Possibly just fork it and create a PW version.

[diogo]

For really simple text editing this one looks good. It's lightweight and configurable.

http://nicedit.com/

[apeisa]

While I agree that there are differences between editors (I have found using a latest CKeditor a pleasant surprising), I don't think that settling with another editor will solve the fundamental problems.

If we use just the basic features (text formatting, links) the tinyMce is just find. Replacing it with something that does those things only doesn't solve the problem, it just takes away features that someone might need in some projects.

What I would like to see this discussion going is what kind of problems and solutions we have. In our projects we usually get away with very few tinyMce buttons (the more buttons, the more problems) - but the real pain points for us are:

1) image placement

2) tables (I think this is one area where CKeditor is much better - also area that many smaller editors just skip, or have very poor implementation like Aloha)

For 1) problem there are sometimes nice solutions, like just using predefined image placements on template. I know that is something that Ryan uses a lot (like here: http://www.villarental.com/villas/17-the-harbour/). It works great when working with clear template (like "villa" here), but it fails when site has a lots of general content pages. What our old cms did and what newsletter editors seems to do now (like http://mailchimp.com/) is to have "mini templates" or "blocks" that keep the structure, instead of just having images and text mixed. That is nice way to do it - editors doesn't have to think about image sizes (that is pain currently), it is easy and safe on redesigns (image sizes are relational to column width) etc.

For 2) problem sometimes repeaters can be used, sometimes textarea with text formatters and sometimes just good rte (ckeditor > tinymce in this regard)

Very interested to hear what kind of problems people are having currently and what kind of solutions might help?

[Joss]

Oh, I dont think these should be replacements - just alternatives.

As I said, tinyMCE (and similar) are great where you need complicated.

But a lot of the time all you want is very simple, lightweight and fast. To be able to choose alternatives to suit the purpose is useful.

There is another related issue here which is exclusive to the magazine or news website - the authors and the editors may want different editors. For instance, the author possibly should only have a textarea (or maybe something basic that gives a slightly nice working environment.)

Where as the editor might want a full singing and dancing affair where they can format the article in detail.

This is peculiar to the textarea field of course, but it might be interesting to be able to set which editor for various user groups.....

[Joss]

Saw this - very cute

http://tinymce.swis.nl/demo

[ryan]

Antti, what are the table features that you find to be better in CKEditor? I was playing around with the demo on their site, but couldn't figure out how it was better in that regard (though I didn't experiment for long). 

[apeisa]

Antti, what are the table features that you find to be better in CKEditor? I was playing around with the demo on their site, but couldn't figure out how it was better in that regard (though I didn't experiment for long). 

Sorry Ryan, missed this last time around.

For me the UI is much better in CKEditor (right click for context menu). When I have showed clients how tables in TinyMCE works they are always little unsure (like I am too). And ok.. now that I tested tables in TinyMCE website, I see context menu there - I have never seen that in my own implementations on with PW. There must be some setting I am missing?

About dialog windows: those are very easy to customize in CKeditor (remove or add fields, set defaults etc): http://docs.ckeditor.com/#!/guide/dev_howtos_dialog_windows

Last year I have implemented (or tried to) CKeditor 4, TinyMCE, Aloha and Mercury and I gotta say clear winner was CKeditor. For some reason customizing etc just made sense to me. Most pain I had with Aloha, which was a true mess at that time (they had both JqueryUI and ExtJS - now they have seem to dropped the Ext out).

[Joss]

Hi Apeisa

TinyMCE has right click context too - for tables as well.

You do have to turn it on, though by adding "contextmenu" to the list of plugins.

[apeisa]

Thanks Joss. I noticed when tested it, but never seen it before. Need to turn it on for clients.

[Joss]

There are a couple of things I add:

In additional settings I add:

paste_text_sticky: true

paste_text_sticky_default:true

 

Which automatically takes all formatting away from pasting.

 

I add H1 to my dropdown, spell checker and a few other bits. here is my settings (I dont use the all at once, but it gives me a good starter):

 

buttons 1

 

formatselect,styleselect,fontsizeselect,|,bold,italic,justifyleft,justifycenter,justifyright,justifyfull,forecolorpicker,|,bullist,numlist,|,link,unlink,|,image,|,code,|,fullscreen,spellchecker

 

block formats

 

p,h1,h2,h3,h4,blockquote,pre,code

 

Plugins

 

inlinepopups,safari,table,media,paste,fullscreen,preelementfix,contextmenu

 

Valid Elements - note, to enable things like font color, size and face, you must use span and NOT font!

 

@[id|class|style],a[href|target|name],strong/b,em/i,br,img[src|id|class|width|height|alt],ul,ol,li,p[class],h1,h2,h3,h4,blockquote,-p,span[face|size|color],-table[border=0|cellspacing|cellpadding|width|frame|rules|height|align|summary|bgcolor|background|bordercolor],-tr[rowspan|width|height|align|valign|bgcolor|background|bordercolor],tbody,thead,tfoot,#td[colspan|rowspan|width|height|align|valign|bgcolor|background|bordercolor|scope],#th[colspan|rowspan|width|height|align|valign|scope],pre,code

 

Content CSS

 

/site/templates/css/editor.css

 

 

Additional Settings

 

paste_text_sticky: true

paste_text_sticky_default:true

theme_advanced_styles:Lead=lead;IconCell=iconcell;Blueheader=blueheader

 

Third party plugins

 

spellchecker : /site/tinymce/myplugins/spellchecker

[Pete]

paste_text_sticky: true

paste_text_sticky_default:true

 

These sound like very good options to have on by default - thanks for pointing them out! Anything to curb the issues I've seen occasionally when people write their content in Word and then paste it in to TinyMCE is welcome

[Joss]

Yeah, they stop me from being an idiot too!

[ceberlin]

Anyone checked the new version TinyMCE 4 already? It's currently in late beta.

The new version looks soooo cool and clean! I cannot wait to see this in PW!

[ryan]

I agree, it does look very nice! I look forward to integrating this into ProcessWire. 

[kongondo]

Here's the presentation to TinyMCE 4

http://www.tinymce.com/presentation/

[ryan]

I've got TinyMCE 4 working with PW locally on my dev branch. They've changed quite a lot on the API side, but it all seems like improvement even if it does require lots of changes to code that uses it. In some ways it seems like a different product. I need to put more work into supporting all the other options we currently support in TinyMCE 3, but so far TinyMCE 4 is looking very good. 

[kongondo]

I've got TinyMCE 4 working with PW locally on my dev branch. They've changed quite a lot on the API side, but it all seems like improvement even if it does require lots of changes to code that uses it. In some ways it seems like a different product. I need to put more work into supporting all the other options we currently support in TinyMCE 3, but so far TinyMCE 4 is looking very good. 

Ryan,

Any chance TinyMCE4 will appear before PW 2.5 2.4?

Edited: meant 2.4

[apeisa]

2.5? That is future!

[kongondo]

2.5? That is future!

Meant 2.4. Thanks

[mindplay.dk]

Since we're on that topic, any thoughts on adding a real UI for the TinyMCE configuration? The current UI is not much better than simply typing into a text-file - there's the same margin for error, and you still need to look up keys/values in the documentation to get it right.

Also missing for me, is the ability to create and share configurations - most of the time, I really want one, or at the most two configurations, for all of the fields, not one for every field.

If a UI isn't going to offer an advantage (convenience, transparency) over editing a text-file, in my opinion, a text-file would be preferable, so at least you can check the configuration into source-control and deploy it easily. So a much simpler solution would be to simply provide a folder where you can place plain JS (or JSON) configuration files, and then simply pick one from a drop-down - I'd be happier with that solution than the current one, since it's the same amount of work, and addresses the issue of sharing configurations...

[ryan]

Have you seen any interactive TinyMCE configurations anywhere? I'd be interested in checking them out for ideas. It seems to me that TinyMCE's configuration options are such that it's not worth trying to build an interface to it. Such an interface would be overwhelming to both user and developer. I actually kind of like having a passthrough giving fields to cover the major configuration components, like we've got. It means TinyMCE's docs and support are still applicable, rather than us being responsible for every single possible option and supporting all them ourselves. But I also like the idea of pointing it to a custom JS file, for the reasons you mentioned. Though as an option, because I think it'd probably be overkill for many (including me) that usually only add an extra button for <hr> or something like that. But I'll plan to add this option.