Fixing a Visual Editor Problem by Taking the Slow LaneAugust 12th, 2011
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.
- 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.
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/