A strange thing happened the other day. I built a basic custom theme for WordPress, gave it a name, version and deployed it locally. Immediately my updates page was complaining that 1.0.0 was out of date and that I should install 2.0.1

Hovering over the link to the update gave me a clue as to what was going on. The *directory* name into which my custom plugin was installed is picked up by WordPress as the theme name slug and passed to the WordPress.org API to check for updates along with the version I specified in the theme files.

That means that even on an intranet, unless you block WordPress.org API calls, you mustn’t have any collisions in the theme names with the repository. This also means that if you come up with a completely novel and custom name for a theme that currently isn’t in the repository, the day a developer releases one with the same name and your version differs, your custom, private theme will be flagged as out of date.

I’m not suggesting that this behaviour is wrong on the part of WordPress, I’m not really sure they could do anything else, I just wanted to flag it up as something you may come across. If anyone has any API hooks that can be used in a theme functions.php to block checks then this may well be a solution – feel free to post a comment!

I upgraded the Akismet anti-spam plugin on my site earlier only to be greeted with a message stating “your akismet key is invalid”. Turns out that despite having my personal key since early 2006, I had to re-request the key on the Akismet site. I noticed when I did this that I was encouraged to pay a subscription fee of my choosing.

While I do completely understand the need to monetise services like this, I really didn’t like the underhand way in which I was forced onto that page. Plugin upgrades shouldn’t render a previously issued key invalid and certainly shouldn’t force you onto a site where payment is solicited to proceed (even if you can side-step this). As a plugin author, if I published a plugin into the WordPress repository that did this kind of thing I’d likely have my entry deactivated for violation of terms of service – smacks of double standards to me

Now as any developer who’s dabbled with WordPress knows, it’s easy to change the root directory location of WordPress so that directory structure wise different CMS systems can play nicely alongside one another.

What about, however, the situation where two CMS systems both require a root file of index.php? Well there you have a problem because if you change the name of the WordPress index file, which on the face of it seems easiest, you break the search feature (and possibly other things I’ve not found yet).

Fortunately I found a simple 3 step method which requires modifying only 1 line in 1 core file, which compared to other CMS systems, is not that many.

1. Firstly you’ll want to follow the instructions on the link at the start of the article to move your WordPress root away from the root of your site so that it can co-exist with your other app. Then, instead of creating a file named index.php in your website root, you create wordpress.php or another name of your choosing
2. Secondly, in the .htaccess file you created as part of the aforementioned guide, replace instances of index.php with wordpress.php or whatever name you chose
3. Now, for the final bit of magic, locate the following file wp-includes/class-wp-rewrite.php and replace
   

   public $index = 'index.php';

   with

   public $index = 'wordpress.php';

   taking care to use your alternative file name if it differs

That’s a wrap as they say! You should find that WordPress works fine, including the search feature, all the while leaving index.php free for use by another CMS. Do let me know in comments how you get along with this if you try it.

Oh and remember, if you upgrade WordPress, which will happen every now and again, do check to make sure your core file change gets put back – I hate to change core, but as index.php is hard-coded, it’s the only way.

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.