Pasting in TinyMCE

Pasting in TinyMCENow first of all, I’ll be honest, I love TinyMCE. It’s a brilliant example of a JavaScript WYSIWYG editor, and has pretty much become the de-facto standard, too. We’ve all used it at one time or another, I’m using it right now to write this blog post, and it makes our lives a lot easier when we’re using it to see exactly how what we’re writing is going to look like (or thereabouts). However, trying to integrate it into a custom system that requires a lot of specific features and browser support can be a flipping nightmare, as I’m about to explain…

At LINGsCARS, we use TinyMCE for composing messages in the LINGO system, on both sides, admin and customer, so it gets used fairly heavily each day. On the old system (LINGO v1) we just had a textarea that would end up being filled with tags like <b>, <br />, etc. Not particularly pretty to look at and not much use either, so we decided to give a WYSIWYG editor a go, to make typing the message look exactly like a message, and I suggested TinyMCE straight away. We ended up building a couple of quick in-house plugins for templates, image uploading and storage and all was going very well initially when we turned the system on. But then, the mysterious bugs started appearing…

What was Google Chrome Doing?

Pasting in TinyMCEMost of the team at LINGsCARS use Google Chrome for all their admin work, with a few exceptions who use Firefox, so the first bug we noticed was one that only showed up in Chrome. Every time some plain text content was pasted into Chrome, the content would come in upside-down! Not back-to-front, all the letters were still the right way around, but the bottom line was at the top and so forth! I found it such a strange bug that I couldn’t believe it at first, it must’ve been the way that Chrome itself was handling the plain text content before passing it to the paste plugin. I managed to debug it in the paste plugin source code all the way back to the event trigger, so I knew it wasn’t an easily fixed problem…

Of course, by the time this bug had cropped up, so had many others. Pasting from Outlook was causing massive problems for some staff, with <style> tags being included, a plethora of various pointless HTML tags being passed through with no explanation or conversion, and random spaces being omitted from the ends of lines when pasting from MS Word! We were using the BBCode plugin to translate any HTML into strict BBCode so that we weren’t contaminating the database with HTML like we were in the previous system, and to make sure no admin staff or customers could post anything remotely injectable, so a lot of the tags weren’t going to be used anyway. Trying to ascertain whether TinyMCE was going to return HTML filled with <p>s or <br>s was basically guess-work, as the option for setting either one wasn’t just in one place… By this time, I’d realised the pit of snakes I’d fallen into and was beginning to regret it…

First step: Upgrade

Of course, after having a system in active development for such a long time, the first thing I noticed was that we were running a version of TinyMCE that was of a fair age. I think we were running version 3.2.x, and version 3.3.x was out at the time. I know that when LINGO development started, Chrome was a fairly new idea, so maybe the upside-down bug had been picked up and eliminated? Yep, correct. Upgrading TinyMCE fixed that particular problem, which was good news! I didn’t fancy sitting there debugging all the way through a huge library like that, and to be perfectly frank, I didn’t have the time! This helped me ease my fears over TinyMCE and helped me develop a resolve to get rid of further bugs…

Look at the Paste Plugin

The next step was to get rid of some of the strange HTML pasting problems. I was using the paste plugin that comes with TinyMCE to differentiate between plain-text and HTML-formatted text, so this was the code I focused my efforts in. There didn’t seem to be a consistent way of getting the HTML to work between various browsers, applications and operating systems, so I made the decision early on to abandon HTML support for pasting and merely support plain-text. Looking back on this, I could’ve made a better decision at this point, as now we’ve been in situations where being able to paste tables, bulleted lists and the like would be an advantage, but hindsight is a wonderful thing, and I’m happy with the outcome of the plain-text work.

Modifications needed to be made to the paste plugin source code, trying to get rid of the strange HTML tags and converting all content to plain-text. I even roped in one of the core developers of TinyMCE on Twitter in sorting a bug with <br /> and <p> inconsistency between Webkit-based browsers and others. That pretty much sorted the <p> to <br /> problem I mentioned earlier, and after about a day and a half of debugging and swearing, I had the plain-text isolation sorted, so pasting was finally working in a consistent manner.

Style Tags?

Now, even though all content was being pasted as plain-text and forced into the editor in that guise, there were still a few tags slipping through full of content, one of which was a <style> tag. This only ever happened when pasting from MS Outlook, and only when pasting messages into the system from one particular supplier, who happened to include a <style> tag in his message signature above his name. The <style> tag itself was getting removed, but the inner content, including all the CSS definitions and comments, was being pasted every time! This was a very strange bug relating to the way the paste plugin actively searches for and removes special tags such as <style> tags. It must have been an unintentional oversight, but after careful examination of the code, it really does leave the content in! Having discovered this, I quickly removed this problem and finally got the last of the reported bugs ironed out…

The Finished Article

After spending almost a week on TinyMCE, I was very pleased with the results I got. Now I have a very good understanding of how the library works, and have integrated it a lot quicker into subsequent projects, taking the modified plugins and knowledge I’ve built along the way. A lot of Twitter users have recommended I look into alternative WYSIWYG editors, such as CKEditor, or just abandon them altogether in favour of a solution such as Markdown, but for now I’m sticking with TinyMCE after putting all that effort in. Plus, when it works, it really does the job.

I do plan on submitting some code examples of what I changed to get the paste plugin to work in plain-text only mode, and am still planning on submitting a couple more patches to the latest TinyMCE builds from these bugs I’ve found, but I need to make sure I’ve clearly tested these changes first before I submit anything…

I hope some of you found this useful, it just shows that even with these massive libraries, they aren’t always perfect and any developer can make a difference to these projects and help to improve them for their own needs and everyone else’s.

This entry was posted in JavaScript and tagged , , , , , , , , , , , , , , , , , , . Bookmark the permalink. Post a comment or leave a trackback: Trackback URL.

3 Comments

  1. Posted 22/12/2010 at 18:19 | Permalink

    +1 for Mr Bean there.

    I do exactly the same, the only addition being a small “preview” div, which shows what it’ll look like once submitted, as opposed to just having the textarea filled with markdown.

  2. Posted 17/12/2010 at 15:26 | Permalink

    I’m going to agree with Martin here, Markdown rocks. As the submitted data is format neutral, converting it into various other formats (pdf, image, json), should the need arise, is a breeze.

    Of course, if you’re needing your users to be able to move images, resize ‘em and generally affect direct layout – Markdown isn’t going to be for you.

    Chin chin.

    Anthony.

  3. Posted 17/12/2010 at 15:04 | Permalink

    As you mentioned, I’ve started using Markdown in my content management system. My clients don’t know how to write HTML so I’m not going to make them. I instead have a text area that’s parsed via Markdown, and has a simple WYSIWYG editor similar to the one found on Stack Overflow where the user can highlight text, click say, the ‘B’ button and have the correct Markdown bold declarations added either side of the currently-highlighted text. Does the job perfectly, and no one’s requested “one of those Word windows” yet.

Post a Comment

Your email is never published nor shared. Required fields are marked *

*
*

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>