Yesterday one of our writers discovered the WordPress spellchecker was not working properly—namely that it started always saying there were no errors (creating false-negatives). After quite a bit of research, it came down to the following: WordPress packages TinyMCE as WYSIWYG editor including their PHP spellcheck plugin. This plugin uses the Google Spellcheck RPC by default (although it does have other options). Further, the TinyMCE/PHP spellcheck plugin does no error handling, so if it doesn't get a response it likes, it returns the message that no errors were found.
It seems that the Google integration, dates back to 2004, was developed in part by Automattic (of WP fame) and relied upon non-public, undocumented Google features, specifically making a call to https://www.google.com/tbproxy/spell?lang=en&hl=en. Google appears to have discontinued access to this feature without notice (which is within their rights on a non-public, free feature).
This is a big WordPress issue, not only the error, but the false negatives. It is also a TinyMCE issue, and there are some other libraries relying on this feature including jQuery Spellchecker.
The most confusing part has been the silence on this. I have to have one of the first tweets on the subject and a WP Hackers Post that is still un-answered. It's taken a full day for anything to surface on the boards, even so, it's scant. I assume this is primarily because TinyMCE is still happily telling you there are no spelling errors! This should be a reminder to us all to handle errors properly.
Now, here is how to make WordPress work again. Luckily the TinyMCE devs were smart enough to include options in the spellcheck plugin, including a config file where you can set alternate options (although, please note, that while this is a config file, it's out of the main config directory, so it is something you will consciously have to migrate with every WordPress update). In this config file is an option to use PSpell which is a PHP wrapper for aspell, the main unix spellcheck application. Unfortunately none of these are installed by default on most production servers.
So, first you'll have to install pspell. In CentOS, you can do so like so:
yum install php-pspell
(this should bring aspell along as well)
Then you'll need an ASpell dictionary. I chose the english one
So now I did something like:
wget ftp://ftp.gnu.org/gnu/aspell/dict/en/aspell6-en-7.1-0.tar.bz2 tar xvjf aspell6-en-7.1-0.tar.bz2 cd aspell6-en-7.1-0.tar.bz2 ./configure make sudo make install
But I recommend you follow your heart and your system admin if you don't know what any of those commands mean.
This is my first really technical post on my blog here, so bear with me if you're not from the techie crowd (in fact, you may just want to skip this one, your brain cells don't need the stress). Single and double-quoted strings are an oft-argued entry PHP topic; however they are used so often that getting to the bottom of this issue could have significant performance improvements. Our goal in designing high performance websites is to optimize the common conditions and avoid the edge case gotchas. With that in mind, let's take a look at this issue.
When I started PHP 4, (which meant moving from the illustrious PERL) my good friend and ZCE Justin Beasley (@justbeez) was all about the single-quoted strings. I pretty much took his word and the documentation seemed to support them as a better go-to, but is it still that way in modern PHP? TL;DR is yes, but not by much. PHP has gotten a lot smarter in recent versions, but there still is overhead to variable embedding.
All of my loads of PHP Bench actually showed double-quoted strings performing slightly better than single (surprising!). Unfortunately he also does not note which version of PHP he is using. But, on the other side of the aisle, Micro Optimization notes that double quoted-strings are slower. Classy Llama (who also does not show which PHP version he's working on) shows a significant performance detriment to actually using an embedded variable over concatenation, and really if you aren't going to embed variables (other than avoiding escaping strings with lots of apostrophes) why would you want to use a double quoted string? As Classy Llama points out, there is a readability benefit as well to using concatenation and Zend.
Now, I'm thinking this is a version issue (yet another one who doesn't list his version), but this guy noticed that if you ever use a dollar sign that is unattached to a variable in a double-quoted string, there is a huge performance penalty. Even though this is an edge case, it's a great reason to use concatenated single-quoted strings. However Jeff Moore is suggesting that all the tests thus far are missing the boat because the actual embedding process will be done on interpretation which is not being considered in these processes. So, perhaps this is all meaningless. When it comes down to it, I think concatenated values are easier to read, and it's quite possible single-quoted strings perform better.
I went into Manhattan to see how things were going over there. My driver (since there is no subway service) said that he's worked every NYC disaster for the last 10 years and was excited to get some extra cash today from the storm rates.
Staples had a sign with all of the things that were out of stock.