I came across an old post on my blog the other day that was getting a lot of hits. When I viewed the page I decided that the code snippet in the article could do with an increase in text size to make it more readable.

I went into the admin panel and added an in-line style attribute to the code tag in question. When I saved the page WordPress reported that the post had been updated, however the text in the editor screen reverted back to what it had been prior to my change. I tried numerous times to save and tried different browsers but try as I might, the change just wouldn’t “stick”.

I usually consider myself pretty adept at solving WordPress related issues but this one was stumping me so I did what all developers do when they are in a tight spot and I googled it. Most posts turned up were completely unrelated, but one article suggested that the issue may be symptomatic of a corrupted table.

A quick command as the MySQL root user had my answer and effected the fix into the bargain

[kieran@www:~/public_html]$ mysqlcheck --check --databases wordpress --tables wp_posts -u root -p
Enter password:
wordpress.wp_posts
warning : Table is marked as crashed
error : Key in wrong position at page 132096
error : Corrupt

I re-ran the same command to make sure it had effected a fix (it isn’t clear from the output)

[kieran@www:~/public_html]$ mysqlcheck --check --databases wordpress --tables wp_posts -u root -p
Enter password:
wordpress.wp_posts OK

Now updating the offending post works first time without issue. I suspect, although can’t be sure, that the corruption occurred during a recent upgrade of the server when not all the services, MySQL included, got shut down gracefully.

When carrying out a recent upgrade of suPHP I encountered the following error in my apache error logs and PHP pages were not being served.

SecurityException in Application.cpp:511: Unknown Interpreter: php

Turns out the fix is a simple one; the syntax of the config file has change between versions and it’s simple a case of replacing the following lines:

[handlers]
;Handler for php-scripts
x-httpd-php=php:/usr/bin/php-cgi

;Handler for CGI-scripts
x-suphp-cgi=execute:!self

With the following (note the addition of double quotes)

[handlers]
;Handler for php-scripts
x-httpd-php="php:/usr/bin/php-cgi"

;Handler for CGI-scripts
x-suphp-cgi="execute:!self"

A quick bounce of apache and you should be back and kicking

When I recently upgraded an OpenVZ container in-situ over SSH, I had a few issues with the upgrade path. One of these was that the upgrade process called for the installation of a new kernel, however a container doesn’t need one and in my case couldn’t handle installing one either and thus caused the upgrade process to error out.

The fix was to force remove the kernel, both from the dpkg directory structure (in this case I copied the files to /tmp/ just in case) and using dpkg it’s self. The following commands as root:

mv /var/lib/dpkg/info/linux-image-3.2.0-58-generic.* /tmp/
dpkg --remove --force-remove-reinstreq linux-image-3.2.0-58-generic

Resuming the dist-upgrade after this process was a success