The Flow of Consciousness

A couple of months ago, I wrote an article entitled SVN is so WordPress 2.0: Using git to manage a WordPress 3.0 installation. This article explained how to migrate an existing WordPress installation to a git-managed installation, much like using Subversion to manage it.

That post detailed how to migrate and the instructions could very easily be adapted to create a new installation. This post details how to upgrade to the latest release of WordPress whenever it is released.

Unfortunately, I’ve found that the WordPress team, perhaps git-svn, doesn’t import svn tags, so we need to do some sleuthing to find out exactly which tag to use.

The first stop is finding out the last svn revision used for the tag. Use this command to do so. Replace the version number with the one applicable to the upgrade you wish to perform.

svn log -v -q --stop-on-copy http://svn.automattic.com/wordpress/tags/3.0.1/ | less

The output of that for me is this:

------------------------------------------------------------------------
r15479 | nacin | 2010-07-29 17:57:26 -0400 (Thu, 29 Jul 2010)
Changed paths:
   M /tags/3.0.1/wp-includes/capabilities.php
   M /tags/3.0.1/wp-includes/version.php
------------------------------------------------------------------------
r15477 | ryan | 2010-07-29 17:09:29 -0400 (Thu, 29 Jul 2010)
Changed paths:
   A /tags/3.0.1 (from /branches/3.0:15476)
------------------------------------------------------------------------

Looking at the revisions, I’m looking for a revision 15479 or shortly there after.

Next, I use the WordPress Codex entry for the release to find what date it was released. Version 3.0.1 was released July 29, 2010, so that gives me a pretty good approximate date for the last commit. The svn log above also shows this date, but I figured there might be some lag between the final commit and when the release came out. You could probably skip this step. Don’t judge me.

I then go to WordPress’s Github’s commit history on its master branch and look for a commit on the date above. There are two: 20812cf38b99a40a0e3c1d3dd5c2b3d20fb893b5 and 2f27661e1afffe16ecfbaf7a5b02db8f47e46482. Looking at the log for each, I see this line:

git-svn-id: http://core.svn.wordpress.org/trunk@15480 1a063a9b-81f0-0310-95a4-ce76da25c4cd

Revision 15480 is approximately right at the above, and looking at the changeset shows that this is probably what I want.

I do wish there was a commit which was right on, though.

So, now that I know the commit id, I can use it with git.

The rest is easy! Well, sorta. For the love of $deity, back up your blog, both the files and the database, before you do anything past here.

Once I’m in my git-versioned WordPress directory, I had a little bit of cleanup to do. I’d inadvertently added some files in wp-content/cache, so I had to manually remove them with git rm and also update my sitemap.xml and sitemap.xml.gz with git add sitemap.xml* and git commit.

Then, I could proceed.

git fetch gh
git merge 2f27661e1afffe16ecfbaf7a5b02db8f47e46482

Remember that you really only need to use enough of the commit id hash to uniquely identify the commit. If I recall correctly, seven characters is usually enough, and git will warn you if your choice is ambiguous. I used the full one because I copied and pasted.

Here’s my transcript from these commands so you know what it should look like:

[colin@convoy blog]$ git fetch gh
remote: Counting objects: 860, done.
remote: Compressing objects: 100% (591/591), done.
remote: Total 749 (delta 568), reused 202 (delta 155)
Receiving objects: 100% (749/749), 312.70 KiB, done.
Resolving deltas: 100% (568/568), completed with 104 local objects.
From git://github.com/wordpress/wordpress
   c39484b..6e44120  master     -> gh/master
[colin@convoy blog]$ git status
# On branch master
nothing to commit (working directory clean)
[colin@convoy blog]$ git merge 2f27661e1afffe16ecfbaf7a5b02db8f47e46482
Auto-merged readme.html
Merge made by recursive.
 readme.html                                        |    2 +-
 wp-activate.php                                    |    2 +-
 wp-admin/admin-ajax.php                            |   22 +-
 wp-admin/admin.php                                 |   12 +-
 wp-admin/edit-attachment-rows.php                  |    4 +-
 wp-admin/edit-tags.php                             |    7 +
 wp-admin/edit.php                                  |   11 +-
 wp-admin/export.php                                |   12 +-
 wp-admin/import.php                                |    2 +-
 wp-admin/includes/bookmark.php                     |    4 +-
 wp-admin/includes/class-wp-importer.php            |    5 +-
 wp-admin/includes/class-wp-upgrader.php            |   33 ++-
 wp-admin/includes/dashboard.php                    |    4 +-
 wp-admin/includes/deprecated.php                   |   10 +-
 wp-admin/includes/export.php                       |    2 +-
 wp-admin/includes/media.php                        |    2 +-
 wp-admin/includes/meta-boxes.php                   |    4 +-
 wp-admin/includes/ms.php                           |   48 ++--
 wp-admin/includes/nav-menu.php                     |    2 +-
 wp-admin/includes/plugin-install.php               |   13 +-
 wp-admin/includes/plugin.php                       |    3 +-
 wp-admin/includes/post.php                         |   20 +-
 wp-admin/includes/schema.php                       |    9 +-
 wp-admin/includes/template.php                     |  288 ++++++++---------
 wp-admin/includes/theme.php                        |    6 +-
 wp-admin/includes/update.php                       |    6 +-
 wp-admin/includes/upgrade.php                      |   12 +-
 wp-admin/includes/user.php                         |    8 +-
 wp-admin/install-helper.php                        |   10 +-
 wp-admin/install.php                               |    2 +-
 wp-admin/menu.php                                  |    4 +-
 wp-admin/ms-edit.php                               |   13 +-
 wp-admin/ms-sites.php                              |    5 +-
 wp-admin/nav-menus.php                             |   15 +-
 wp-admin/options-discussion.php                    |    2 +-
 wp-admin/options-permalink.php                     |   51 +---
 wp-admin/plugins.php                               |   23 +-
 wp-admin/press-this.php                            |    2 +-
 wp-admin/update-core.php                           |    4 +-
 wp-admin/user-new.php                              |    4 +-
 wp-app.php                                         |    2 +-
 wp-content/themes/twentyten/attachment.php         |   12 +-
 wp-content/themes/twentyten/editor-style.css       |    8 +-
 wp-content/themes/twentyten/functions.php          |   58 ----
 wp-content/themes/twentyten/header.php             |   16 +-
 .../themes/twentyten/languages/twentyten.pot       |  123 ++++----
 wp-content/themes/twentyten/loop.php               |   33 +-
 wp-content/themes/twentyten/page.php               |    8 +-
 wp-content/themes/twentyten/style.css              |  340 +++++++++-----------
 wp-includes/canonical.php                          |   14 +-
 wp-includes/capabilities.php                       |   12 +-
 wp-includes/category-template.php                  |    4 +-
 wp-includes/class-http.php                         |   54 ++--
 wp-includes/classes.php                            |    2 +-
 wp-includes/comment-template.php                   |   46 +++-
 wp-includes/cron.php                               |    8 +-
 wp-includes/default-filters.php                    |    2 +-
 wp-includes/default-widgets.php                    |    2 +
 wp-includes/deprecated.php                         |   19 +-
 wp-includes/feed.php                               |    2 +-
 wp-includes/formatting.php                         |   14 +-
 wp-includes/functions.php                          |   15 +-
 wp-includes/general-template.php                   |   11 +-
 wp-includes/kses.php                               |    4 +-
 wp-includes/link-template.php                      |    6 +-
 wp-includes/media.php                              |    2 +-
 wp-includes/meta.php                               |    2 +-
 wp-includes/ms-blogs.php                           |   20 +-
 wp-includes/ms-deprecated.php                      |   14 +-
 wp-includes/ms-functions.php                       |   27 +-
 wp-includes/ms-load.php                            |    7 +-
 wp-includes/nav-menu-template.php                  |   35 ++-
 wp-includes/nav-menu.php                           |   17 +
 wp-includes/post-thumbnail-template.php            |    2 +-
 wp-includes/post.php                               |   26 +-
 wp-includes/query.php                              |    3 +-
 wp-includes/taxonomy.php                           |   34 +-
 wp-includes/theme.php                              |    4 +-
 wp-includes/update.php                             |   47 ++--
 wp-includes/user.php                               |    4 +-
 wp-includes/version.php                            |    4 +-
 wp-includes/wp-db.php                              |    9 +-
 wp-signup.php                                      |    5 +-
 xmlrpc.php                                         |   10 +-
 84 files changed, 903 insertions(+), 872 deletions(-)
[colin@convoy blog]$ git status
# On branch master
nothing to commit (working directory clean)

The last thing to do is go to /wp-admin/upgrade.php in your browser. You’ll likely be redirected there when you hit the admin panel anyway, so it’s likely easier simply to do that.

Is managing the installation with git easier than managing it with svn? So far, not really. Subversion’s svn switch and WordPress’s use of SVN tags makes using git with it a little frustrating. If WordPress were ever to switch to git for real, then they’d likely use tags and all this searching would be moot. One could just switch branches and be done with it.

Got an easier way? Tell me in the comments.

Using Subversion to manage my WordPress installation was convenient and mindless. Whenever there was a new release of the blog software, I could hop to a terminal, back up my filesystem and database, and run svn sw http://svn.automattic.com/wordpress/tags/(new.version.number).

This worked great all through WordPress 2.x. However, when I tried to switch from 2.9.2 to 3.0, things broke. As in, “white screen with PHP failure message” broken. I hit the dreaded is_multisite error because something didn’t come in right or I’d accidentally modified something or maybe even the tag was out of date.

Regardless, I decided that in order to fix the problem, I needed to wipe out every file or directory which began with wp in my /blog directory and copy over from a fresh download of the package.

I mindlessly did this, then realized: “Oh crap, now I can’t upgrade with Subversion any more.”

I queried Twitter, asking So I went and deleted all of the .svn directories in my wp install. Is there a way I can put it back on svn without having to recopy stuff?. @steveklabnik quickly replied, jokingly, @colindean yeah, you just run ‘git init .’ .

A troubleshooting conversation ensued, and then I found that WordPress maintains a GitHub repository.

Then it hit me: maintaining my WordPress installation with Subversion is so…WordPress 2.0. I’m on WordPress 3.0 now, it’s time to embrace modern distributed version control systems and use Git!

Steve, being an intrepid Rubyist friend and Git user, suggested how I could version my existing blog directory and add a git remote, then fetch and rebase, thereby syncronizing my local installation with an easy to use versioning system!

However, because it’s a development repository without any “tags”, I’ll have to remember to look for a specific commit whenever I upgrade.

I changed things up a bit and corrected order of things. Here’s what I did to get it working. Note that I’m a git newb and very open to suggestions if there’s a more succinct or overall better way to do this.

Note that I used git protocol for the repository (Github’s HTTP git seems to have problems completing transfers to my server).

Initialize the local repo and add what you have already:

git init
git add .
git commit

Add the remote, fetch and rebase:

git remote add gh git://github.com/wordpress/wordpress.git
git fetch gh
git rebase gh/master

At this point, I was informed that I had some files in wp-content/cache which needed to be deleted/updated. A quick git status showed that I’d versioned these cache files. Oops! You’ll have to do git rm <filename> for each of those, or just do git rm wp-content/cache.

Next, I added a few directories to .gitignore using my text editor of choice:

wp-content/cache/*
wp-content/uploads/*
wp-content/plugins/*
wp-content/themes/*

Then, I needed to merge in the 3.0 commit.

git merge 7cee95b6bba8bc867023ae0831e7538a8419a9f5

There were a few conflicts, but all were easily resolved. Use git add on each file needing resolved, then git commmit to finalize your changes. Once you commit, you’ll be up-to-date and merged with that version.

I’ll update this post or make another when the next release of WordPress is out to report how well the actual upgrade goes.

This is hot off the presses, folks.

Google, Yahoo, and Microsoft announced today that their search engines will honor a new value for the rel attribute of link elements commonly found in the head element of a web page. This new specification aims to reduce content duplication via redundant URLs.

For instance, WordPress posts can be accessed always through the URL example.com/index.php?p=3 and often through a URL such as example.com/2009/02/12/search-engines-to-honor-canonical-urls or the like. Search engines see these separate URLs and usually think that they are duplicate content at different URLs, thus reducing the site’s ranking because of the duplicate content.

The new functionality acts not unlike a soft 301 redirect.

Check out the very informational post at Search Engine Land on the new canonical URLs. A big thanks to @badmacktuck for bringing it to my attention!

Joost de Valk wrote a WordPress plugin called wp-canonical which adds such a link element to any WordPress blog. I’m using it now. He’s also written a Drupal plugin and an informative blog about about canonical URLs, too. That was quick!

I recently noticed that WordPress added support for Gears, as have a few other sites, including ZohoOffice and MySpace.

Gears is essentially offline storage for rich Internet application data. GoogleOS has a list of Gears-enabled sites/applications. Read more on Gears at Wikipedia.

Much to my dismay, the only officially-available Firefox extension supports only 32-bit operating systems. I’m a 64-bit Linux user. Specifically, I use Ubuntu 8.10 Intrepid with my ASUS M3A32-MVP motherboard and 8 GB of DDR2 RAM (4GB of Geil and 4 GB of OCZ).

Fortunately, Gears is an open source project and one intrepid developer made a Gears Firefox extension package which supports 64-bit Linux.

I downloaded and installed the package by dragging and dropping it onto the Firefox Addons dialog, then restarting Firefox when prompted. I archived the Gears extension package on my own site in the event the package is suddenly no longer available. Be sure to check for new versions though, since this package may be out of date if you’re reading this post more than a few days after publication (though unlikely).

Huzzah for open source.

WordPress 2.5.1 has been released. It fixes a serious security vulnerability and more than 70 fixes and enhancements.

There’s also something highlighted in the release which I did not know had been added in 2.5. From the release:

Since 2.5 your wp-config.php file allows a new constant called SECRET_KEY which basically is meant to introduce a little permanent randomness into the cryptographic functions used for cookies in WordPress. You can visit this link we set up to get a unique secret key for your config file. It’s unique and random on every page load. Having this line in your config file helps secure your blog.

For my readers who, like me, are managing WordPress using subversion, the upgrade is a simple svn sw http://svn.automattic.com/wordpress/tags/2.5.1 away. If you’re not managing WordPress using subversion—and you really should if you have come kind of shell access to your server—then go to WordPress.org to get the newest release.

WordPress 2.5 was released yesterday. The upgrade path is very, very easy for existing 2.3.3 installations–it’s a simple copy-and-upgrade.php procedure.

For those who use Subversion to manage their installations of WordPress, such as myself, the upgrade was even easier:

svn sw http://svn.automattic.com/wordpress/tags/2.5

I then ran /wp-admin/upgrade.php and was in business. I had a few plugins to update, but my theme is 2.5-ready and so are the remainder of my plugins.

The new administration panel, of which there are screenshots all over the web, is quite different but much easier to use. It took me a moment to reorient myself and find that the Options tab is now the Settings tab and that the Categories selector for writing posts is now below the entry box instead of beside it.

For the first time since I started this blog, I’ve devised a new theme: Fluid Colinese. It’s based on Fluid Blue by Srini G. and uses a primarily brown and dark orange theme. Sean Potter said it reminded him of Ubuntu’s color leanings. I agree. Honestly, the blog looks as intended with the fonts FreeSerif and FreeSans installed. Both are available on most Linux distributions, and font files for Windows are linked (however, the fonts looks terrible on Windows, at least to me). It looks acceptable for Windows Vista users or XP users who have acquired the font Segoe UI. Otherwise, the body text looks alright and the headlines default to Arial, which is alright.

Also, this theme is made for WordPress 2.3, so it can use all of the widgets and whatnot. I know WordPress 2.5 is coming out soon, but the only real changes to the theme side of things is the inclusion of avatars. I haven’t decided if I want to enable them, but I’ll decide when I see how annoying they are when WordPress 2.5 is actually released.

I’m working on enabling OpenID for commenting. I’d wanted to use it for my previous theme, but I couldn’t ever get it to play nicely. My old theme was made for WordPress 1.5, I think. Anyway, I’m running into a few issues because of conflicting versions of OpenID and Yadis in the plugin source and in /usr/share/php, which is used by my own OpenID server.

You’ll also notice the addition of some widgets. I’ve added the tag cloud and some RSS feeds from sites for which I write.

I’m going to take a little time here and there and reorganize the categories, too. I’ve got some categories which have one or two posts, such as the battlefield and g15 categories. I’m also going to get rid of the Uncategorized tag left over from Ultimate Tag Warrior’s shenanigans.

If you read my blog regularly and know me, either in person or through some organization, drop me a line and we can do a link exchange of sorts. Please, though, I prefer people whom I’ve met in person and who update their blog regularly. I tend to remove links to blogs which haven’t updated in months. Really, I should just import the OPML file from Liferea, my preferred Linux feed reader.

The URL for my blog won’t change, but the RSS URL will. I’m planning to rename the blog, as it’s no longer the Flow of Consciousness it was in the past. I’m almost out of that phase of my life, so it’s time to move on to more professional and responsible blogging.

Tell me your thoughts, folks. ¿Te gusta? ¿No te gusta?

The latest patch version of WordPress is available. Be sure to download and upgrade!

If you’re awesome like I am, then you’re using Subversion to manage releases. There aren’t any major changes to the structure, but you should always backup your wordpress directory just-in-case. Then, issue svn sw http://svn.automattic.com/wordpress/tags/2.3.2 and you’re running the latest version.

I upgraded to WordPress 2.3 last night.

Know what I did to do so?

1. Backed up the database using wp-db-backup.
2. Backed up the WordPress directory at a terminal with a simple tar czvf blogbackup.tar.gz.
3. Upgraded a few plugins and removed others according to the official plugin compatibility list.
4. Executed svn sw http://svn.automattic.com/wordpress/tags/2.3/

Done.

Took me about ten minutes, and most of that 10 minutes was spent reading the compatibility list.

By the way, I love tags.

I hate with a passion WordPress updates. It’s a great blogging platform, yes, but like many pieces of software, manual updates are needlessly long and painful. Backups are essential even with automated updates, but human error is much more devastating sometimes.

So, I decided to switch how I update WordPress. Instead of logging into my shell, wgeting http://www.wordpress.org/latest.tar.gz, and doing the update manually, I’m now using Subversion to track updates.

The WordPress Code has a fantastic write-up on updating WordPress with Subversion. I migrated using the instructions and had a full upgrade in less than three minutes. When WordPress 2.3 comes out later this month, a simple svn sw http://svn.automattic.com/wordpress/tags/2.3/ migrates my entire blog with very little effort. I’ll still need to check for upgrades now and then with svn up.

So, if you’ve got shell access and can use svn, give it a try!