TinyMCE and the non-breaking space problem

Let’s get right to it then: TinyMCE is great, but I am annoyed by its willingness to take users’ multiple spaces literally! Collapsing multiple spaces is a basic characteristic of HTML, and allowing users to carelessly (or intentionally, which they still shouldn’t do) insert multiple spaces by converting every other one of those spaces into the   (non-breaking space) character is BAD!

IMHO.

Anyway… start with a pinch of Stack Overflow, add a dash of the official TinyMCE documentation, along with a heaping tablespoon of reading between the lines, and I have a working solution to the problem. My installation of TinyMCE now automatically converts any   characters in the text back into regular ol’ spaces.

It’s a bit draconian; after all there are legitimate uses for non-breaking spaces. But 95% of the times they’re inserted by TinyMCE are user accidents, and another 4.9% of those times are abuses like faked “tabs” that would be solved better by another approach altogether. (There are reasonable CSS-based solutions that work in some cases, but let’s talk HTML’s need for tabs another time.)

Anyway… here’s the gist of the solution. You need to create a callback function. Here’s mine:

function my_cleanup_callback(type,value) {
  switch (type) {
    case 'get_from_editor':
      // Remove   characters
      value = value.replace(/ /ig, ' ');
      break;
    case 'insert_to_editor':
    case 'submit_content':
    case 'get_from_editor_dom':
    case 'insert_to_editor_dom':
    case 'setup_content_dom':
    case 'submit_content_dom':
    default:
      break;
  }
  return value;
}

It may look like there’s a lot of extra stuff in here you don’t need; I included all possible values for type inside the switch to be prepared for the future. You do want to check for type == 'get_from_editor' though; otherwise your replace() is going to run under way too many conditions and may cause weird behavior like new paragraphs appearing when you just want to insert new text into an existing one, or browser-generated warnings about leaving the page when you try to save. (I ran into both as I was fine-tuning this.)

Now that you have your callback function, you just need to… you know… call it. That’s done inside tinyMCE.init(). You’ll need to include this line somewhere:

cleanup_callback: 'my_cleanup_callback',

Be sure to check if cleanup_callback is already declared somewhere, and also don’t forget the comma at the end, unless you’re inserting this as the last line.

Once you’ve got it all rolled out to your site, you’ll need to clear your cache. I’ve found TinyMCE’s configuration files can be annoyingly persistent in the browser cache.

Yes… you have correctly observed that I had to use non-breaking spaces myself in this post, to get the indents in the code samples to show. Pay no attention to the man behind the curtain. And remember my complaint about the lack of tab characters in HTML. Another day.

File under “Don’t Make Me Do This Myself”: a comparison of “TTW” (Through The Web) WYSIWYG text editors

I really don’t want to have to spend time thinking about this, but there’s such a dearth of useful information out there on this topic — based on my searches of Google and Bing, which return little more than uncritical lists of 40+ different TTW text editors, usually displayed on such hideously designed or woefully outdated websites that I discount their validity on sight — that I feel compelled to step in.

The question today is TTW (through-the-web) WYSIWYG (what-you-see-is-what-you-get) text editors. If all of that sounds like 10 letters of gibberish to you, feel free to stop here. But if you’re a web developer, especially of the custom CMS variety, you’re certainly aware of the situation: how do you give users of your system a usable tool that allows them to easily edit site content without having to muck around directly with HTML? (That is, after all, kind of the whole point of a CMS.)

It’s something I’ve struggled with for over a decade. At one point I was actually rolling my own. But that’s a little more JavaScript than I care to deal with directly, and I long ago left the project of building a WYSIWYG editor to those who really love that kind of thing.

That puts me in a position where I need to select the best available option for a pre-built, drop-in WYSIWYG editor. Fortunately things have come a long way in this regard over the past decade. I’ve been — more or less happily — using TinyMCE to solve this particular problem for the past 3-plus years. But lately “less happily” has been outweighing “more,” and I’ve been exploring my options.

So far the only viable alternative I’ve found (or had recommended to me) is CKEditor. It’s the successor to one of the really early TTW WYSIWYG editors, FCKEditor, which I tried ages ago and never really liked.

Today I took a major step forward with cms34, my custom CMS, by setting up a configurable site option that allows users to select the editor of their choice: TinyMCE, CKEditor, or raw HTML. As inclined as I am to use raw HTML myself, I’m giving CKEditor a whirl for now.

So far I am inclined to say CKEditor is just the remedy I’ve been looking for to cure my TinyMCE malaise. As good as TinyMCE is, it just gets a little wonky sometimes. It especially seems to have trouble figuring out where to put closing tags when you’re switching between block elements, and especially when you’re inserting new content. I find myself often switching to the HTML pane to fix its quirks manually, but I can’t expect clients to do that.

My experience with CKEditor is still pretty limited at this point, but I have to say I really like how it’s set up for customizing the interface (which buttons to show, especially), in addition to its better handling of switching between elements than TinyMCE. They’re both pretty similar, actually, in how they’re configured, and in the overall user experience. But CKEditor has a little more polish, a little more flexibility. It almost feels like “TinyMCE done right,” although perhaps it’s too early for me to make such a proclamation.

So, that’s it for me, for now. The only two options in this realm that I really have any experience with. I know there are others out there. Some may even be good. Even better than TinyMCE or CKEditor. What’s your favorite?

TinyMCE and the relative URLs SNAFU

My CMS, cms34, uses a few third-party tools for certain complex features. One of the most useful is TinyMCE, a JavaScript/DOM-based drop-in WYSIWYG text editor. If that doesn’t mean anything to you, you probably want to stop here, but in case you’re a glutton for punishment, it is, in short, a way to produce HTML-formatted text with a word processor-like interface. Think Microsoft Word in a web browser, with the results being formatted for display on a web page. Slick.

Anyway, there’s been one nagging problem: When users paste in URLs for links, TinyMCE converts any on-site links into “relative URLs” — it strips out the domain name. This is not necessarily bad; in fact, for the most part I would want it to do that. But for some reason the nature of my CakePHP-based CMS seems to confound TinyMCE’s ability to properly determine the relative URL. And what’s worse, the CMS includes an enewsletter editor which has to have absolute URLs, but TinyMCE was converting them to relative URLs even if the user pasted in an absolute URL.

A little research led me to a handy explanation in the TinyMCE Wiki. Basically, if you want your URLs to always be absolute, make sure your TinyMCE configuration includes the following:

relative_urls : false,
remove_script_host : false,
document_base_url : “http://www.site.com/path1/”

Of course, you’ll want to change the value of document_base_url to be the actual base URL of your website. As it happens, my CMS has a global JavaScript file that creates a variable called baseUrl that I can use anywhere in JavaScript to substitute for the full base URL of the website. So, in my case, I set the value for document_base_url equal to baseUrl.

And, voilà, it seems to work!