LinuxChix Los Angeles

UPDATE 9/15: Issue is gone (I hope!). Everything I wrote about fsockopen, cURL, etc. forget it. It was a server firewall issue. The reason for the ad hoc creation of dynamic rules which intermittently blocked outbound http requests is still under investigation, but the installation of a firewall that had better integration with the backend web administration interface looks to have helped.
UPDATE 9/13: Issue is back. All outside connections, including rss feeds, are out. Damn.

Akismet provides wonderful comment spam protection. Except when it doesn’t work. For some reason, still undiagnosed, outgoing communication to the Akismet servers were being intermittently blocked for the LinuxChixLA blog, and then a few days later completely blocked, rendering comment spam protection through Akismet non-existent. Even more disturbing, at the same time communication from within WordPress to wordpress.org was also disrupted.

WordPress versions between 2.7 to 2.8.4 switched the http communication defaults between cURL and fsockopen and consolidated the WordPress http code into a single (more or less) location. So I downgraded (*) to the older 2.7 installation. Some progress. Communication was restored to wordpress.org, however Akismet remained blocked.

Ummmmmmmmmmmmm.

Found this post at techdebug.com which, while dealing with an Akismet solution in a chrooted apache environment on a bsd server, did give me a .php script that I could use to test fsockopen from outside of WordPress. When run I got a time-out. Damn. A server problem?

OK, on to IRC.freenode #wordpress channel. Was pointed in the direction of a WordPress module called Core Control that allows for the testing and, if necessary, switching between cURL and fsockopen as the transport module in WordPress. I then upgraded (again) to WordPress 2.8.4, and upgraded (again) to Akismet 2.2.6, and installed Core Control. Using the HTTP Module of Core Control, I tested each of the given transport modes … and they all tested as working just fine and dandy with no problems reported with cURL OR fsockopen. Now I’m completely confuzzled.

So went back to the WordPress Akismet configuration, and it’s now fine. No problems. Communicating its little bits out. WTF?! Re-ran the fsockopen test .php script, and it’s fine, no problems reported, happy as a working script can be with nary a hint of a time-out.

I did NOTHING other than test the given protocols. And now everything works. What happened? Don’t know for sure, but I suspect that the stream setting was incorrectly set to block and running the HTTP module explicitly unset the block … tho how that apparently affected server wide communication is a mystery.

But I am happy that Akismet is working again.

* OK, downgrading was an accident. I originally had just wanted to look at the differences in the code between the 2.8.4 and 2.7 version, but didn’t specify a separate directory when I untarred the backup. I actually untarred the file over the currently installation. Oops!