My TinyMCE Bugfix

TinyMCE LogoAs you might have noticed I have been am using TinyMCE quite intensively throughout most of the projects I create and maintain. Working a lot with such a nice piece of code will undoubtedly bring forward certain limitations and/or bugs. Today I stumbled upon quite a big one (and not only in today’s 2.1.0 release, but also in the previous builds – at least 2.0.9 had it too) … and fixed it of course.

Using TinyMCE has been quite a blessing upon all of the projects created over the past year. Project by project the configuration of TinyMCE got tweaked more and more, resulting in a nearly perfect config. One of the configuration parameters is convert_fonts_to_spans which is quite necessary for projects having a valid XHTML 1.0 Strict template as we don’t want the invalid font tags to appear on the website.

Now, I must say that the conversion works quite well. Pasting in text using font tags will nicely get converted to spans. During testing today I entered some gibberish test messages and coloured the text a bit and changed the font-size. Saved it (through AJAX, so the page of the editor does not reload), checked the site where it was shown in the full layout, decided to edit it a bit more – first hit F5 in the admin zone though, as I had changed some of the JavaScript code in a quickie – and … noticed that the colours were gone in the TinyMCE instance.

TinyMCE Formatting Bug
Entered text on the left // entered text after a page refresh on the right.

Hmmz … bramus.debugmode.on

Firstly refreshed the frontend of the site … yes the colours still were there. Then checked the database: correct data inside the database. Then I switched to source code view of the current HTML page (not the editor) and noticed the correct data was there inside the textarea. Above that the “path” was shown correctly in the TinyMCE status bar (see screenshots above). Hmmz …

So I decided to take a peek at the content of the textarea using the HTML button of the TinyMCE editor itself. And yes, the correct data was there too. After hitting the update button from within that source-view window I noticed that all of the sudden the content was shown correctly again inside the TinyMCE instance. Okay, I found out how to fix this little sucker by accident, but the client won’t know that and it’s no real solution either.

TinyMCE View Source

While poking around a bit more I refreshed the page and immediately hit the save button I had placed underneath the editor. I saw that the data sent to the webserver was the correct data (thank you Firebug!), and also noticed that the editor showed the correct data again.

Now, the method I use for saving the data of a TinyMCE instance via AJAX is quite simple:

  • Call a tinyMCE.triggerSave(false,true), so that the content of the editor get placed inside the textarea the editor is replacing
  • Get the value of that textarea
  • Send that value over XHR to the server

Now read that previous paragraph again. Yes indeed, the triggerSave() apparantly fixes this nasty bug.

Logic thinking results in a easy solution:

  • let the tinyMCE.init() roll
  • after it has inited, invoke a triggerSave

But how to hook that triggerSave after tinyMCE has been inited?

Well, luckely for us tinyMCE provides us some nice callback functions, one of them being called after the init has been completed. The event is – quite logically – named init_instance_callback and implementation is really easy when looking at the code example.

Without no further a due I hereby present the resulting code that will do what I want it to do:

[js]function myCustomInitInstance(inst) {
tinyMCE.triggerSave(false,true);
}

tinyMCE.init({

init_instance_callback : “myCustomInitInstance”
});[/js]

Now, I’ve opened a bug report for this little sucker hoping it’ll get fixed soon. If now, the solution already has been made 😉 I’m pretty sure that a permanent solution would be to modifying the tinyMCE.init so that it automatically invokes a triggerSave at the very end of the function itself.

To make the story complete I also discovered that when setting convert_fonts_to_spans to false (default setting) the bug does not appear at all.

Happy coding!

B!

Published by Bramus!

Bramus is a frontend web developer from Belgium, working as a Chrome Developer Relations Engineer at Google. From the moment he discovered view-source at the age of 14 (way back in 1997), he fell in love with the web and has been tinkering with it ever since (more …)

Unless noted otherwise, the contents of this post are licensed under the Creative Commons Attribution 4.0 License and code samples are licensed under the MIT License

Join the Conversation

1 Comment

Leave a comment

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.