Giving your WordPress a check up

Every now and then someone finds something wrong with a WordPress install which, rather than be caused by a bug in WordPress itself, is caused by a server configuration error, an interaction between WordPress and something else installed on the server or is just a recommend optimisation for better site performance.

Everyone has a different set of pitfalls that they have come across and I would like to collect together all these little things into a comprehensive community developed plugin which can hopefully become one of the first “canonical” plugins that we have talked about.

To that end I have developed a framework for this plugin, in the style of a unit test framework, to make it really easy to write tests and I am hoping that some of you will have ideas for tests and also that you will want to get involved.

For a while I have tagged tickets in the main WordPress trac where there are is possible inspiration for tests –

The following is an example of the code required to carry out one of these tests which recommends users of PHP4 upgrade to PHP5.

 * Check that we are running at least PHP 5
 * @todo Provide a link to a codex article
 * @link
 * @author peterwestwood
class HealthCheck_PHP_Version extends HealthCheckTest {
    function run_test() {
        $this->assertTrue(    version_compare('5.0.0', PHP_VERSION, '<'),
        sprintf( __( 'Your Webserver is running PHP version %s, which is no longer receiving security updates and will no longer be supported by a future version of WordPress.', 'health-check' ), PHP_VERSION ),

If you would like to get involved in the development of the plugin then you can check the source code out from the WordPress plugins subversion repository here: and you can follow the development progress using the WordPress plugins trac here:

As the plugin is not yet ready for its first release we will be doing the development in this alpha branch and then move to trunk once we make the first release.

I am actively looking for fellow developers for this project as a community team we can make this a success.

So if you would like commit access to write some tests then drop me a note using the contact form with a bit about yourself and I will give you access.

22 thoughts on “Giving your WordPress a check up

    1. @Nick: Yes I had seen that.

      I am thinking of a much leaner approach and trying to capture as many configuration issues as possible and ensure that people get a simple list of what they should be addressing.

      I think the two plugins will likely complement each other.

  1. Exactly what I could have used the last few days. Have been trying to convince a host that they changed something, not me, and they didn’t need to fix *my* WordPress install.

    They finally fixed it today. It was CPanel updates.

    I would like something that checked suPHP and PHP as CGI.

      1. The symptom was the plug-in auto-update feature stopped working – jumping into Connection details and me having to supply FTP credentials. (I think this can be a suPHP andPHP as CGI configuration thing?)

        I knew it wasn’t WordPress because *I* hadn’t changed anything and it affected several WP instances of differing versions on different domains on the same server.

        I have asked for details of the fixes. Host has now conceded that CPanel engineers fixed and they don’t (yet) know what was done to their server. It works now (but I feel very uncomfortable about that!).

        Hope to have a report after the new year holiday.

      2. This sounds like a permissions issue / change in the user under which the server was running.

        Maybe someone can write a set of tests which identifies what part of the server configuration blocks the upgrader using the direct file system root and recommends a solution.

        Sounds like that would have been useful

  2. One of the issues we had recently was with spaces left in the plugin code. Any space before the XML declaration breaks feedburner and other feed readers.

    I would be willing to contribute some code to fix this or help diagnoss this issue, since it cost me about a half a day of looking in a live site to fix last week

    1. That sounds like a great test.

      I guess the test code could use the WordPress HTTP API to check the XML returned by the feeds built in to WordPress and detect this.

      Why don’t you check the code out and have a go at writing a test for that. I have ideas for a couple of other tests which would do similar HTTP request based testing.

  3. Perhaps a check for database and tables collation that would display it if different that utf8_general_ci or utf8_unicode_ci, or not matching get_option(‘blog_charset’).

  4. Oh I also took what you said in the example above through “After the Deadline” at & it suggested changing “Your Webserver is currently using PHP version %s, which is no longer receiving security updates and will no longer be supported by WordPress in an future version” to “Your Webserver is using PHP version %s, which is no longer receiving security updates and will no longer be supported by WordPress in a future version”. Notice “a” instead of “an” before future & it said the following about the other change I listed “Revise currently using

    You should avoid redundant expressions when possible. A redundant expression has extra words that add no new meaning to the phrase. By eliminating redundant expressions you will make your writing more clear and concise.”

    With my knowledge of English the a is correct instead of the an. Beyond that I’m not sure. Just trying to help where I can.

  5. I see this posting with some trepedation.

    Unlike many, I am self-hosted and I do NOT run Apache. This is the source of my concern. I run Win2KAS with IIS6 or Win2k7 with IIS8. PHP5 on both and the RDBMS host is running MySQL5 on Win2KAS. All of these live behind a NET10 NAT wall running an internal TLD of CASELLE-NET, which is also the A/D Domain.

    This is very far from being the standard WP configuration and I do not wish to get caught in a Geek War cross-fire. I run IIS rather than Apache because I believe that is the best integrated server under Windows. I run Windows because, after being a Caldera Linux VAR, I got tired of Tinkerware and just wanted stuff to work without much tinker-factor.

    What I do not want and what I am afraid of is that your project gets too focused on LAMP servers and either ignores of denigrates WIMP configurations.

    1. It is great that you use WordPress in this configuration and I hope that the improvements in IIS support that have been made in recent versions have been appreciated.

      If you have any common configuration issues that cause problems when running in a WIMP configuration they would be appreciated for the plugin too so as to benefit other users like yourself who prefer to use this hosting platform.

Comments are closed.