If you have a similar issue the first thing you may notice, when trying to get to your site is that maintenance mode is “enabled”. To disable this connect to hosting server via FTP (or SSH) and delete the file ‘.maintenance’. The file may be hidden so you may have to enable viewing hidden files in your FTP client. Once deleted you should once again be able to see your site (fingers crossed!).

The next issue I had was not being able to log into my site admin panel. Navigating to the page gave me a horrible fatal PHP error; a sure sign that something was very broken. Not to worry there’s a (fairly) simple fix.

While logged onto your server via FTP or SSH, delete the ‘wp-admin’ and the ‘wp-includes’ folder. Make sure you don’t delete the ‘wp-content’ folder! Once that’s done download a copy of WordPress 3.2, unzip it and upload the unzipped ‘wp-admin’ and the ‘wp-includes’ folders to your server. Once complete you should be able to see your WordPress login page again! Yay!

You may be asked to update your database, go ahead and click the update button and login. Now take in all the goodness that is version 3.2 of WordPress! The guys have done a superb job with the admin panel, love the new design. Glad to hear they have also dropped IE6 support too. About bloody time!

So a quick summary for the tr;dr’s out there:

1. Maintenance mode on? Delete ‘.maintenance’.
2. Delete ‘wp-admin’ and the ‘wp-includes’ folders (Not ‘wp-content’!)
3. Download a copy of WordPress and unzip it.
4. Upload the unzipped ‘wp-admin’ and the ‘wp-includes’ folders.
5. Navigate to the admin page, update database and login

Phew, crisis averted! Now’s a good time to reiterate what is mentioned on the updates page. Always remember to back-up your database and files before you run an update. If something does break with the auto update you can always revert to your backup!

Edit a post directly in the page, the future is here.

Now I’d love to show you a picture of it working in my blog template, but that would be too easy wouldn’t it. :) Unfortunately the plug-in doesn’t work with my custom theme, I’m yet to figure out the reason why. Boo! I know it isn’t a plug-in issue as it works with the default WordPress theme. This could be an issue for others wanting to use the plug-in, so as soon as I figure out why I’ll post an update.

One issue I did notice was Aloha likes to use its own version of jQuery; manually including it in your theme will cause Aloha to throw an error. A quick workaround is to wrap a WordPress conditional tag around the jQuery script element like so:

Since you need to be logged in for Aloha to be initialised this will fix the error and allow you to use the latest version of jQuery in your theme.

As soon as I fix Front-End Editor for my current theme I’m sure it will be one of my favourite plug-ins. Last but not least a big thank you to the Aloha Editor team, I’m looking forward to seeing how the project progresses.

So what do you get in Jetpack? Well here are three of my favourites:

• WordPress.com Stats – exactly what it says on the tin…
• Shortcode Embeds – easily add media from YouTube, Vimeo and Slideshare.
• LaTeX – need equations in a blog post? This ones for you then.

There are eight plug-ins currently available with more coming soon.

The last plug-in I mentioned, LaTeX may sound like it’s come straight from a .xxx domain name but bare with me; under that slightly suspect name is a powerful tool for anyone who needs to format equations in a post. Here’s a small demonstration:

LaTeX has allowed me to embed one of the most beautiful equations in all of mathematics; Euler’s Equation directly into my blog post. It links Real Numbers, Euler’s Number, Imaginary Numbers and Pi in a staggeringly simple equation. There’s a mass of information on LaTeX here with everything you’d ever need pretty much covered.

So if you’re looking to give your WordPress blog a bit of a boost (horrible pun I know), give Jetpack a whirl!

Committing your plug-ins to SVN tends to break this (very cool) auto-update functionality. SVN adds a hidden “.svn” directory to each directory you commit. WordPress auto-update tries to delete the updating plug-ins folder before downloading and extracting the new version into the “wp-content/plugins directory”. WordPress isn’t able to delete the “.svn” directories so the auto update process fails, leaving you without the plug-in you were trying to update (since it deleted it before failing).

So what’s the solution? Well you could download the latest plug-in version and manually extract / commit it to your repository; but that’s too long winded (and boring). The ideal solution lies in the use of the svn:externals property. It allows you to attach an external repository location to a folder in your own repository. Since all WordPress plug-ins are hosted in the WordPress repository you can update all your plug-in’s directly from there with a quick “SVN Update”! Perfect!

You can do this via SSH and the command line or you can do it via a SVN client with a GUI (I use TortoiseSVN). I’ll be showing you how to do it via the GUI.

First you need to remove the plug-in you want to update from your repository if it’s been added. This may seem a little strange as you are trying to update it; but we need to update from an external repository and if a version already exists it will fail:

Delete the plug-in you need updating from the repository first

Next you need to setup your svn:externals property on the “wp-content/plugins” directory via the properties menu:

Edit the properties on the 'plugins' directory.

Now for the tedious bit. For all the plug-ins you want SVN to auto-update, you will need to find the WordPress repository URL for. So for the example, to update Akismet and All in One SEO pack you will enter the following:

Add the plug-in repositories to the externals properties, one per line.

Once you’ve added all the plug-ins you want to auto-update (remember to remove them first if they already exist in your repository!) commit your changes. Then watch the magic happen via an update:

Plug-ins checked out from the WordPress repository.

Akismet and All in One SEO Pack have been checked out from the WordPress repository trunk. Every time you do an update SVN will check for new versions of the plug-ins. Great stuff! There is a slight warning with checking out from trunk; the developer could be working on a new release and unfinished code may have been committed, so the plug-in may be broken if updating from trunk! To get around this you may want to checkout from the plug-in tags (final versions) instead. To do that change the repository URLs to:

Unfortunately this will involve changing your svn:externals property every time a new version of a plug-in comes out, but it’s less likely your plug-ins will break. Note: Remember to replace the tag version number with the latest version.

I hope this little tip helps you streamline your deployment!

P.S. On a side note, if anybody knows how to auto update from a tag automatically please leave a comment, I’d love to know if it’s possible.

After hours of frustration I stumbled upon a similar forum post with the answer:

Hours of frustration over such a simple fix. Sods law I guess. Add this code to the function you use to register your custom post type like so (usually in your themes functions.php):

No more 404 errors! Huzzah! One last tip: make sure you turn off any caching plug-ins (DB-Cache reloaded, Hypercache etc) before you start redeveloping your WordPress blog. Yes I made that mistake too! Yesterday evening is one I wish to forget…

Update: If you are adding custom taxonomies to your post types you may need to add the flush rewrite rules to the function when you initialise them:

Update 2: Adding flush_rewrite_rules in the places mentioned above will force a flush for every page load. This is bad! For a better solution see Kens comment below.

Alternatively you could add the flush_rewrite_rules where suggested and reload your page; this will flush the rewrite rules and fix the 404 errors. Remember to remove or comment out the flush_rewrite_rules line after as it’s no longer needed! Thanks Ken for this update.

It just so happens that I’ve had a request for a customisable header image on an future project, so decided to have a play and see how difficult it is to implement. Well it isn’t difficult at all, very simple in fact.

First you will need to edit your functions.php located in your theme directory. Go ahead and create one if it isn’t in the directory. Now copy and paste the code below into the file. I’ve commented the code but it’s all quite self explanatory. Change the height and width of the image and change the directories where needed.

By adding the code above you will now see a new option under “Appearance” in the admin panel called “Header”. From there you should be able to see all the images and options we just set in the functions.php file. The only thing left to do now is add the header image to the theme.

Where you place the following code will be depend on your theme setup; I’ve decided to place it in the header.php file as I want the image to appear on every page. You may only want the image to appear on specific templates e.g. pages, archive, category (you could also use WordPress conditional tags to do this).

And there you have it, one header image that you can customise via the WordPress admin panel. An ID is attached to the image for CSS styling where needed.

The example above is quite a simplified version of the header image functionality. It is possible to place text over the image and even have a different image per blog post by using the custom thumbnail functionality, but these are beyond the scope of this blog post. Copy & paste and enjoy!

Back when Snipplr was young, Tyler Hall wrote a WordPress plug-in for Snipplr that allowed you to embed your snippets directly into your posts. What a great idea; unfortunately it hasn’t been updated since 2006 and much has changed in the world of WordPress. Enabling the plug-in in it’s current state is a little flakey; so I’ve decided to update it for WordPress 3.0+.

The plug-in is called ‘Snipplr Snippets’ and is available to download from the WordPress plug-in repository. I’ve used many of the functions that were in the old plug-in so it isn’t a complete rewrite but much of the structure has changed (big thank you to Marcin Dominas helped with a couple of issues i was having at first).

Snipplr Snippets sidebar widget in action.

The administrator area has been updated and there are a couple of new features available which hopefully are self explanatory. I’ve also updated to the latest version of GeSHi for the syntax highlighting, if you don’t like the look a feel of the outputted code simply disable the plug-in CSS in the site header (admin panel), copy to your style.css and modify as needed. For the plug-in to work you will need a Snipplr account and an API key (available from the settings page).

Once you’ve installed the plug-in and enabled it, it’s dead simple to include a snippet into your blog post like so:

Where the ## is the ID of the snippet you wish to include in the post (you can get this from the snippet URL). The code below is pulling in a snippet directly from Snipplr using the plug-in:

I’ve tested the plug-in and it seems to work fine, there was a warning from the CodeColorer plug-in because it also uses GeSHi for syntax highlighting but I haven’t noticed anything break because of it. If it does please let me know and I’ll fix it. If you have any suggestions / bugs leave a comment and I’ll see what look into implementing / fixing them. Download here.

Luckily there are already many plug-ins available for WordPress that can get you started on your way, one that really grabbed my attention was ‘WordPress Mobile Pack‘ by MobiForge. The plug-in contains a mobile optimised theme that you can adapt for your needs and the ‘mobile switcher’ functionality. Mobile switcher detects if a user is browsing from a desktop or a mobile phone and switched the theme accordingly. Great, we’re already half way there!

One of the specifications for the site was that it must work on a set of 4 different screen widths (480px, 320px, 240px and 176px) and this is where the DeviceAtlas API comes in very useful. Device Atlas keep a huge database of mobile phone user agent strings plus specifications associated with a particular mobile phone that you can tap into and use in your web application.

Now one thing I must mention is that according to the mobiForge page listed above, WordPress Mobile Pack includes DeviceAtlas integration. This turns out not to be the case. I couldn’t find any settings regarding DeviceAtlas in the plug-in admin area and very little mentioned on the forums. I assume the page hasn’t been updated for a while and the functionality has been removed. This isn’t a problem though as it’s fairly simple to integrate the DeviceAtlas API into your PHP application i.e. WordPress. Here’s how you do it.

First you must register with DeviceAtlas and order a developer licence (there’s a free option available here). Once registered grab a copy of the PHP API and the latest Device JSON file (under ‘My account’). Unpack the API into the root of your web application (or wherever you like, just make sure the includes are set correctly) and copy the JSON file into the json directory along side it. You are now ready to include the API into the base WordPress Mobile Pack theme. Copy and paste the following into your header.php above the doctype:

Great now we know the user agent that the user is using to view the website (well it may not be 100% accurate but better than nothing). So now you want to query the JSON file and pick out the relevant phone specifications you need. I’m just looking for the width of the device, so I included this in the head tag:

All this code does is find the display width of the phone viewing the website and add a CSS file with relevant site tweaks, allowing you to optimise for that screen size. If the device isn’t found I’ve defaulted to a screen size in the middle of the screen sizes.

Looking through the API docs there are plenty of ways to distinguish between your users, using the following code will allow you to target specific phone brands:

So now you can target only Nokia users. Or instead of loading a different CSS file you could include a different sized image for different screen widths; there are tonnes of options available.

I must admit I really dislike having to ‘sniff’ for the user agent string and having a different CSS file / image per device width, it reminds me of the Netscape / IE browser war days, oh how much fun that was! I guess it’s a necessary evil.

A word or warning when it comes to DeviceAtlas, there seems to be distinct lack of support available. I wrote a couple of emails asking questions and got no reply, and lots of questions on the forum are left unanswered. So if you get stuck you may need to figure it out for yourself I’m afraid.

All in all I’m pleased with the results of my first adventure into the world of mobile web development. I still have lots to learn so if you have any tips and tricks please let me know!

After updating to WordPress 3.0 (yay!) I decided to check the plug-ins that I’ve written to see if they still worked in version 3.0; to my dismay Post Thesaurus had stopped working… nooooo! Not good! A quick scan using Firebug revealed the issue: the Headspace2 plug-in.

Headspace2 is a superb plug-in that allows you to tweak the SEO potential of your site. There are tonnes of options available; All In One SEO is easier to use, but I prefer the flexibility of Headspace2. The problem was occurring in the headspace-tags.js file:

This error was stopping the rest of the JavaScript on a post page from firing (hence breaking Post Thesaurus). Looking at line 76 of headspace-tags.js you will see:

The code seems to be falling over when there are no tags, so I just added a ternary operator which checks the array length first.

If there are no tags create an empty array, else run the usual code. Adding this code fixed the issue and Post Thesaurus works again. Phew! Panic over. I’m sure this error will be picked up by the developer straight away and fixed in the next update.

With the release of WordPress 3.0, developers now have the ability to create custom post types by adding a few lines of code to a themes functions.php. The feature is a huge step forwards for WordPress as it moves closer to being a viable CMS solution (without all the hacks). There have been a number of projects I’ve worked on that have required a custom post type; rather than relying on the client selecting the correct category under ‘Add new post’, which tends to always leads to issues.

I’m in the process of converting nooshu.com to use custom post types and taxonomies, the main area in particular is my portfolio section. At the moment the portfolio posts are just standard posts which have a category of ‘portfolio’ attached to them. It works, but I don’t get that warm fuzzy feeling, and it feels like a bit of a hack. So time to start using a custom post type of ‘portfolio’ (yay!).

Unfortunately at the moment there doesn’t seem to be a quick way of converting a published standard post into a shiny new custom post type, at least not from the administration area. After a little investigation work using phpmyadmin and the nooshu WordPress database, I discovered it’s actually quite easy. Be warned though, it’s easy to break your blog by editing the database directly, so make sure you back everything up. I take no responsibility for what happens if you break something!

To convert a post into a custom post type; in phpmyadmin look for the wp_posts table. Inside it do a search, where the ‘post_type’ value equals ‘post’. This will give you a list of all your posts (otherwise you will also have all the revisions and attachments listed). From the list you should be able to pick out the posts you want converting to your new post type, edit one of these posts and change ‘post_type’ from ‘post’ to your new custom post. In my case this would be ‘portfolio’:

Change 'post_type' from 'post' to your custom post type.

Click save and go back to the previous page. Done! You should now see the post appear under your new custom post type in the WordPress admin panel. If you have any issues just change ‘post_type’ back to ‘post’ and it will reappear under the standard posts. No information is lost when changing the post type.

It’s not an ideal solution, hopefully it will be possible to do it from the administration panel in the future; but it does save having to re-enter all the posts under the custom post type for the moment.