Have you ever gotten really stuck working with an application that is supposed to be easy, to the point that you want to rip your hair out or throw your Macbook Pro out of the window? Well, save for the MacBook Pro destruction aspect (that’s another story, relating to OSX Lion upgrades crashing my favorite applications), I was recently frustrated by my favorite little “easy to use” application: WordPress.

I was working with a client site – it sits on a dedicated server, so it was a very controlled environment and all was running smoothly. The only issue was that the Visual editor simply would not load on most browsers. Chrome? Nope. Firefox? Nope! Safari? Nope! Alas, only good old IE could do the deed, which had me at first stumped but then paved the way for my answer: javascript.  Here are two screenshots showing the visual editor on the left and html editor on the right.  Too bad they look about the same, right?  You see my problem!

An inadequate visual editor

HTML editor looking fine!

You see, recent versions of Firefox, Safari, and Chrome (along with newer IE versions) seem to be competing for which browser can compress and speed up javascript the most. They even give their javascript engines fancy hipster names that sound really really fast:

• Safari had SquirrelFish and now something awesome called Nitro
• Chrome led the pack for a while with a healthy engine called “V8”
• Firefox is stuck on monkeys: TraceMonkey and now the confusing moniker “SpiderMonkey” which my 4 year old would really love.

Well, the browsers aren’t alone in striving for speed – WordPress and other applications are in on the game as well. The first big push for WordPress fancy-script speediness came in Version 2.8 and it has remained a priority. The recent major release (3.2) touts admin area speed as a major raison d’etre for some 50 million websites to upgrade yet again.

So, back to my problem: IE worked fine but the others (which use a very different javascript engine than IE) did not. This made my “googling” more productive, as I knew the problem involved something between the visual editor and javascript. I came across a few threads that pinpointed the issue rather quickly – evidently a javascript compression conflicts with some hosts, and some versions of TinyMCE (this is what makes your visual editor look pretty and have nice buttons for adding links or bulleted lists).

What is the solution? Well, it comes with a compromise. Essentially, you can spend some serious time troubleshooting the exact conflict between your version of WordPress, the various MySQL and PHP builds on your server, and your TinyMCE release.

Or, you could take a small performance hit in the WordPress admin and force it to not compress all the scripts used to load the visual editor. Et voila, you’re back in action.

How to do it? Add this simple line of code near the end of your wp-config.php file.

define('CONCATENATE_SCRIPTS', false );

Here is a screenshot of my updated wp-config.php file with the new code highlighted:

Let me know if you have another solution, or if you know why this issue has stuck around in so many version of WordPress!

Featured Image Photo Credit: http://akorra.com/2010/03/03/top-10-driving-pet-peeves/