Rants, Web

It’s almost a year since the ‘Great Harddrive Fire of 2011’ and just as long when I switched over to the darkside (WP) despite my reluctance to use PHP* and yet I still find there are more ‘procedures’ for customization. Invoking maintenance mode doesn’t appear to use the server’s built-in 503 error settings so I had to create a custom maintenance 503 page. I wonder what other wonderfully roundabout ways I can enhance my installs? :/

* If there was the incentive (ie: paid) to get the manpower to create a non PHP alternative to WordPress – a dedicated team to write a better solution and a slew of powerful optional plugins – then things might change. Until then, I too join the ranks of using ‘that strange toolbox’ and ‘bemoaning the awfulness of PHP’.

Link
Web

New Year upgrade with WordPress 3.3

Upgrading my desktop is a simple matter of clicking confirm. I know it is probably possible to set up WordPress to do the same, but I like to give the least amount of rights to the web-data user over my files. Here is my quick checklist of the 3.2.x upgrade to 3.3(.1)

Database backup

Don’t skimp on this step – if for some reason the upgrade fails you have the ability to restore it to it’s preupdate state. I create a full backup of the database:

mysqldump --user=root --add-drop-database --add-drop-table --complete-insert --routines -p WORDPRESS_DB > mysqldump_WP_TODAYSDATE.sql

Note that I like using complete inserts and drop tables for ease of reading (and to closely follow more standard SQL).

New code shuffle

Download the new version of WordPress and expand the files. I don’t backup the uploaded wp-content – I simply move them from the old locations to the appropriate directories in the new codebase. This way a backup of the old code also exists. Also worth noting that before moving the directories and files you need it’s probably a good idea to set the WordPress site under maintenance.

Here is the list of items you will simply need to move over:

  • /wp-content/uploads
  • /wp-config.php – you can copy rather than move to save a backup

The other directories – /wp-content/plugins and /wp-content/themes – are a little more tedious: you compare the directory contents before you move things. However, if certain items have an update that coincides with the new WordPress then these can be upgraded directly into the new codebase.

Beware – if you have installed plugins that create their own directories outside the normal wp-content convention you will need to move these too!

Permissions

You should have all the external assets (from WordPress) in the appropriate directories of the new codebase. Now check if the permissions need to be changed – like setting the group user to the web-data user or allowing code to be executable.

After this step, it’s time for the ‘great move’.

Move and test

Move or rename the old codebase, followed by moving or renaming the new codebase to the original location. Disable the maintenance and test out your new install. If you were logged in as an administrator before the change you should be able to see if you need to confirm any database updates from the dashboard.

Hopefully all the files and plugins are still in order and your site should look…. exactly the same as it did before.

Standard
Rants, Web

Gallery3 + WordPress 3.2.1 = FFFFFFFUUUU

Gallery3+WP=FFFFUUUU

I know that a WordPress on top of Nginx isn’t all unique but unfamiliar to me, but this fiddling was ridiculous!

I have set up a Gallery3 install (since they’ve stopped maintenance of Gallery2 I believed that I should also use the most active and stable version). Oh boy, was that awful: I realized late that they have intended to depend on Javascript; signs of a design approach I am strongly against. Later, after much pain of creating a custom theme for my gallery (deserving it’s own rant mainly containing one four-letter word rhyming with ‘truck’), I wanted to be able to import images from this to WordPress using the Gallery3 Picker plugin. Given that it had rave reviews and a good method of integrating with WordPress, I thought the install would be painless. I guess anything mainstream written in PHP is going to be anything _but_..

So, after much frustrating FFFFFFFUUUUUUUUUU away from sharp pointy objects and a large crowd of random victims, I found this (gallery3-picker/picker.php line 320):

320
if ($http_status == 302)

Now, the plugin tries something smart: it first tries the /index.php then if that fails retries with the plain URL – assuming that it does SEO rewrites.

If you took a moment to examine my Nginx setup you may have noticed this line:

location ~ \.php$ {
        try_files $uri =404;

.. So if it cannot find a file, it throws a 404 – naturally. Delving into it, the final URL the plugin was after adds a /path/to/rest at the end: so the actual URL hit for me would return 404 at the first pass, not to retry the next.

I have my tweak at least:

320
if ($http_status == 404 || $http_status == 302)

Geez, it’s as if you are hungry but the only option is a greasy burger at a fast-food joint you wanted to avoid. Then you discover that your patty is underdone and they demand that you use their unintuitive stove to cook it yourself. Hmmm.. this food talk makes me slightly less angry and more hungry – time for lunch!

Standard
Web

Twenty Eleven Post Formats – What Are They and Why Should I Care? A great post explaining what the available post types are and what they do in the Twenty Eleven theme (which is the ‘parent’ of this site’s theme).

In this theme, I’ve tweaked the ‘link’ type behaviour after I surprisingly found out that the ephemera widget takes the first link in ‘link’ types. It seems to favour single links-per-posts only, and I tend to get a little wordy (like this ‘link’ post.)

Link
Web

New toys, new troubles: Nginx, FastCGI and WordPress checklist

Before ‘the great harddrive fire of 2011’ we had FastCGI running on the server for some small projects. With everything else using Apache it was rather refreshing to see that there were faster, more lightweight alternatives.

Starting from a fresh slate, we’ve waved off the slow and clunky httpd for Nginx but in exchange for the shiner newer model there’s a bit of a learning curb in how the new kid does things. In addition, an upgrade in blog/CMS was in consideration – now things were running faster perhaps there was some forgiveness in using PHP and WordPress. My starting point was aged a little, so this post documents my time with installing and securing WordPress 3.2.1. Continue reading

Standard