Symphony.

As long as these fundamental problems of rich text editors on the market have not been solved Markdown is the better choice in the Symphony context.

Absolutely right.

@Nils: I would love to see what you come up with as that’s exactly what I want for my sites.

@TheJester12 and Moonoo2: Yes, a WYSIWYG editor is much better for clients in many ways than giving them Markdown syntax only. However, it is worse still for their site to go down because they copied and pasted from another site and got some tag-along code. As I mentioned I had to spend an hour shifting through many thousands of lines of XML to figure out exactly what was killing off my client’s website. Turned out it was an HTML comment that had come along when they copied the text from another site. The worst par tis that’s happened more than once. More than five times.

A happy median is to do what’s done in the forum and have a formatting bar that does the syntax for you. That is, until someone figures out a WYSIWYG that solves all the myriad of issues current WYSIWYG editors have.

One feature I have yet to see is what that when I create a header or sub-header doesn’t create H1 and H2 tags. I would like to be able to say that it should create H3 and H4 tags instead which wouldn’t rely on clients having to be aware of which ones are appropriate. If it only had a heading and secondary-heading buttons I could explain that the first is for section headings and the second is for headings inside those sections. That’s simple for clients to understand.

I’d like to add that it is possible to use WYSIWYG in an XML environment without hitting on the XML validity issue by utilising CDATA sections. This is a common approach with some of the XML outputs we’ve seen with a couple of large projects (most recently the BBC Radio 1, Meet the Listeners website.

The project periodically pulls from an XML source that contains mobile phone multimedia messages. Since mobile phone message are not guaranteed to be valid, and sanitising it would ruin data integrity, all message nodes are wrapped inside CDATA sections. CDATA sections do have a couple of caveats, which I won’t explain here (I might write up as a new post or an article).

Ultimately, there are really only two options:

1. Use WYSIWYG editor and wrap it in CDATA (although sanitisation through something like HTML Tidy and validation is still recommended for cleanliness sake) but forgo the ability to manipulate the HTML content as XML; or
2. Use a elegant and clean editor that ensures the data output is guaranteed to be valid XML.

One feature I have yet to see is what that when I create a header or sub-header doesn’t create H1 and H2 tags. I would like to be able to say that it should create H3 and H4 tags instead which wouldn’t rely on clients having to be aware of which ones are appropriate.

Just as a side note: I think it is better to use XSLT to for this task. It has worked really well for me to always let the user start with h1 as the first headline in their textarea and change it to the correct headline afterwards by matching and replacing all headlines. This way you could easily use the same text snippet in different contexts applying different headline hierarchies.

A rich text editor with this feature might produce a lot of new problems.

@Nils: I would love to see what you come up with as that’s exactly what I want for my sites.

Drop me a line at post@nilshoerrmann.de

Ugh. I never think to use XSLT to fix the problem. Once again, XSLT provides a simple solution. Thanks for the tip, NIls!

It has worked really well for me to always let the user start with h1 as the first headline in their textarea and change it to the correct headline afterwards by matching and replacing all headlines. This way you could easily use the same text snippet in different contexts applying different headline hierarchies.

This is what I do on my blog. All posts start with an h1 because when rendered on their own URI it makes sense to use the post title as the h1. But when rendering my front page I wanted h2 and use the h1 for my site name instead. The same template renders the article on both front page and detail page, but I pass a numeric offset to my template to tell it which heading level to start from.

Headings that are offset are given a class attribute of the original heading tag so that they can be styled the same i.e. my CSS looks like:

h2, .h2 { ... }

This is all a digression. But the ability to do this relies upon strict, tidy output from your entry content.

Thanks for coming in, ratting on the use of my extension and then proclaiming your unreleased extension is better, Nils.

You jerk :P

Can’t wait to see what you’ve cooked up! Do you know when your WYSIWYG extension will be released?

I’m sorry, but I don’t have a working text-formatter and there is nothing to be released in a short term. I have been experimenting with an editor prototype but I’m not convinced is will ever work as it should. Some things in this context are far beyond my JavaScript knowledge.

I know how I think an rich text editor should work but I’m not sure if this is the way the browser vendors think it should work …

Is there a reason we don’t do something similar to what is done in the forum? I know it’s not as client-friendly as a full WYSIWYG editor but it certainly wouldn’t have all the problems they have, either.

For anyone interested, the Symphony website uses a branched version of the WMD editor found at: http://github.com/derobins/wmd.

Is it the norm for the CKEditor Formatter to output   when using the space to separate words? getting a   everytime I declare a space in a sentence.. no good. Where would I go about switching this off? altering it?

EDIT It only appears if there is a space too many at end or in middle of sentence.. no worries

moonoo2 - there are still some oddities in CKEditor itself. They seem to be little things like the non-breaking space issue you just found, and a distinct lack of proper typographic widgets (which I like).

Solved the tabbed output of paragraphs and lists.. which was causing my javascript to mess up.. think it was adding /t before all p tags and after the opening of all p tags.. messed me up good and propper!

Here is the script I placed in config.js within the lib/ckeditor/ folder in the ckeditor extensions folder:

http://pastie.org/768156

The   element will always appear if there are 2 spaces.. so looking into that one!

How would I ensure the &nsbp; gets rendered as an actual space intead of displaying   in my front end HTML page?

This is the last piece of the ckeditor puzzle for me at present.

EDIT The CKEditor forums refer to regex to do the job of removing   characters s/(s( )+)+s/ /mg

But not sure where this would go in order to achieve the stripping out of such entities in the final submitted text. anyone?

EDIT

Wondered about this for a while longer and it seems or I am reading that as the page generated is xml the   is not allowed or renders as a   instead of actual white space..? so was looking at using process_numerical in the ckeditor js file.. not sure how to write this in the jquery way though.

EDIT tonyarnold: just spotted your post about this on the ckeditor forum.. how frustrtating is it though eh! Yes we should be able to choose how to encode entities ourselves..

CKEditor Formatter updated to version 0.7 on 15th of June 2010

CKEditor Formatter updated to version 0.71 on 26th of June 2010

I’ve submitted an issue for an actual bug. But I’m trying to use this in combination with the Multilingual field, which gives me an error upon saving:

strpos() expects parameter 1 to be string, array given An error occurred in /Library/WebServer/Documents/gourmet/symphony/lib/toolkit/class.general.php around line 93

I’m not sure which extension is at fault here, but the Multilingual extension works fine with other formatters like Markdown.

Update: I’ve found the above mentioned problem to be a bug in the Multilingual Field extension, and reported it.

@tonyarnold: Did you write the xmlentities plugin to CKEditor? Can’t find it anywhere else, and I wondered who would be responsible for updating it. I think a solution to the problematic ‘nbsp’ entities could probably be made here.

@dougoftheabaci - Earlier in this thread you said: “The problem is my clients want more control and I don’t like making them remember Markdown syntax.” The Markdown Guide extension places a button below textareas that will show a condensed guide to markdown syntax if the textarea is using one of the markdown formatters.