nooshu - Matt Hobbs' Web Development Blog

Kneeling on the shoulders of giants

Category: Wordpress

Posts on anything related to the Wordpress blogging platform including themes, plug-ins and general tips.

WordPress 3.2, auto update fail

Today, while on my lunch hour, I decided to auto update my blog to WordPress 3.2. Usually it goes without a hitch; unfortunately today it didn’t. I’m not quite sure what happened but it failed within a couple of seconds. Damn it! It may be a Dreamhost issue as I’ve seen reports of other users having similar issues, or it could be just bad luck.

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.
  6. Extra: In some cases you may also need to upload the wp-settings.php file then navigate to the admin page.

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!

Aloha Editor and WordPress

This is a short update on a post I wrote back in August 2010 – Aloha Editor, content editing the HTML5 way. When I last looked at the project there were some excellent examples of it working on static pages but no real integration into back-end systems had taken place. As with any open-source project things progress quickly; on the 5th June a plug-in called Front-end Editor for WordPress was updated to include Aloha Editor! You can now edit blog posts directly in the page rather than through the administration panel. The plug-in is a joint effort from authors Jotschi and Scribu, excellent work guys.

Aloha Editor in WordPress using Front-end Editor

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:

1
2
3
4
5
6
<?php
    //If you aren't logged in, include jQuery
    if(!is_user_logged_in()) {
        //Insert jQuery script tag here
    }
?>

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.

WordPress Stats broken? Grab yourself a Jetpack!

Last week one of my favourite WordPress plug-ins broke: WordPress Stats. For anyone who doesn’t use this fantastic plug-in it’s a very clean and simple way of viewing visitor statistics directly on your dashboard. It isn’t as extensive as Google Analytics and for that I’m grateful as it doesn’t need to be. I first thought it was a hosting issue but that turned out to be incorrect. The plug-in, in it’s current form has been discontinued as it has been rolled into a compilation of useful WordPress tools called Jetpack.

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:

e^{i\pi} + 1 = 0

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!

WordPress plug-ins and svn:externals

So last week I decided to play with the post-commit hook in Subversion which allows you to easily update your WordPress install after committing changes to your repository. After some trial and error this works perfectly. One issue you may run into with WordPress when it’s committed to SVN is using the auto-update plug-in function.

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 wish to update

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:

tortoise 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:

1
2
akismet http://plugins.svn.wordpress.org/akismet/trunk/
all-in-one-seo-pack http://plugins.svn.wordpress.org/all-in-one-seo-pack/trunk/
Using Tortoise SVN externals

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:

Updating WordPress plugins directly from the repository

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:

1
2
akismet http://plugins.svn.wordpress.org/akismet/tags/2.4.0/
all-in-one-seo-pack http://plugins.svn.wordpress.org/all-in-one-seo-pack/tags/1.6.9/

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.

Page not found with custom post types

Just a quick post on a very frustrating problem I was having with WordPress and the new custom post types introduced in version 3.0. Everything was rolling along smoothly until it came to actually viewing one of the custom posts… 404 error. Weird, maybe a .htaccess issue… nope that’s all good, spelling error.. nope. Long story short, this tinkering went on for a good couple of hours and the problem wouldn’t go away…. cry! I tried everything I could think of but nothing helped. I could view the post pages with permalinks turned off, but it failed with them turned on.

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

1
flush_rewrite_rules( false );

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):

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
function post_type_myposttype() {
    $labels = array(
        /* Labels here */
    );
     
    register_post_type(
        'myposttype',
            array(
                'labels' => $labels,
                'singular_label' => __('My Post Type'),
                /* More settings etc */
                'rewrite' => array('slug' => 'custom-post-slug'),
                'query_var' => false,
                'supports' => array(
                    'title',
                    'editor',
                    'author',
                    'thumbnail',
                    'excerpt',
                    'custom-fields',
                    'revisions')
    ));
    /* IMPORTIONT: Remember this line! */
    flush_rewrite_rules( false );/* Please read "Update 2" before adding this line */
}
//Initialise custom post type
add_action('init', 'post_type_myposttype');

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:

1
2
3
4
5
6
function create_custom_taxonomies(){
    register_taxonomy('taxonomy1', 'posttypename', array( 'hierarchical' => true, 'label' => 'Taxonomy1'));
    register_taxonomy('taxonomy2', 'posttypename', array( 'hierarchical' => true, 'label' => 'Taxonomy2'));
    flush_rewrite_rules( false );/* Please read "Update 2" before adding this line */
}
add_action('init', 'create_custom_taxonomies' );

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.

Currently on page 1 of 512345