Not Another WordPress Upgrade


Exit Sign

Finally WordPress 2.7 is released, but don’t you just hate all the endless upgrades, especially if you have code base modifications in place.

Whether or not you like WordPress as a blogging platform is debatable, but you have to agree that it does have a large slice of the market share.  And when you get to be a tall poppy like WordPress, just in shear numbers you will get (that is find) your security problems as people poke holes in your product.

This can have a distinct downside in the endless upgrades that the wordpress development community puts out.  It seems that you can be forever upgrading, testing it all works and then doing it all again.

There must be a better way. Well there is.  Don’t use WordPress (joking). No seriously, there are better ways than the constant manual upgrade of hundreds of files:

  • Automatic Update Plugin – You can get WordPress to upgrade itself for you, with the WordPress Automatic upgrade plugin. From version 2.7 this is automatically included as a core feature.  Now personally I’d be a little hesitant on this one, given the volume of sub releases that are fixes for previously introduced bugs and the like.
  • Use Subversion – If you are a developer and are subversion savvy this would be a way to go using subversion (SVN) to upgrade at your request.
  • Use the Trac – Did you know you can find out which specific files have changed and even the lines of code with them that has changed from version to version.  So you may only have to download a handful of files to install not hundreds in a full release. You can do all this with the WordPress Trac facility.

How to Use WordPress Trac

Trac can be very confusing with all its version numbers, revisions, tags  and trunks.  Sure you can go spread a while working it all out.  But really if you just want to know what has changed from one version to another and if it’s going to effect your code base then you maybe going a little too far.

Trac Changes Dialog PageFigure 1 – Trac Changes Search Page

So how do you work out what files have changed and what hasn’t:

  1. Go to the ChangeSet Page (follow the link or press the View Changes Button on the bottom of the Browse Source Page).
  2. On this page is two fields for Select Base and Target for Diff, they are labeled From and To (see figure 1).
  3. If you want to see the differences between for example: WordPress 2.6.3 and WordPress 2.6.5

    Type in the first field:  tags/2.6.3

    And the next field:  tags/2.6.5

    Yeah the secret is the “tags/” bit then the version number.

  4. Now press the View Changes button.   Ignore the “At Revision” fields leave them as their default.
  5. You will be presented with the results (see figure 2) this is a list of files (at the top), and the changes to the files. It is important to look for files that have been moved and removed as well as these may give you grief later.
  6. At the very bottom of this page is a link Zip Archives under the heading Download in other formats. This link will allow you to download just the changed files and apply or modify them as required.

Trac Results PageFigure 2 – Trac Results Page

Note sometimes you really just want to do the full upgrade like from version 2.6.3 to 2.7.  But at least now you have the option to find out what has really been changed in WordPress.

Tags: , , , ,


  1. This is basically why I use Blogger 😉

  2. Well to be fair Blogger is a hosted solution like

  3. Unless has changed since I looked at it a while back, they’re not precisely the same. With Blogger the app is hosted but your content doesn’t have to be. You can have it FTP static files onto your own server.

  4. @ben okay thats neat you get FTP control of the file space. That would be very handy. You’re right is more of a noob solution.

  5. Hay Gary, just to clarify what Ben’s getting at; you don’t get FTP access to the blogger servers, you give them FTP access to yours and they will upload static files to yours (based on the content you enter though their hosted control panel).

    Also just wanted to add another way to keep WordPress updated a little bit easier is to use “fantastico” which is a package manager for cPanel.

  6. The best way to avoid manually upgrading WordPress would be to bite the ‘drag and drop into Filezilla and wait 10 seconds’ bullet – upgrade to 2.7, then use the automatic upgrade feature that is now implemented, and was widely known about long before the release… This shouldn’t cause a problem unless for some strange reason you’ve edited the WP core files, which can always be avoided if you know what you’re doing.

    And to that end, WP 2.7 also went through a few beta and RC releases, using that massive and supportive market share of developers to iron out any bugs or security holes and unless Automattic are making big changes, there usually isn’t any threat of holes developing anyway. Messing with the core files yourself is far more likely to cause security issues.

    I’d also far prefer a framework that stays on top of technology, with 2.7 implementing many new features in both the back and front ends to make things easier and neater – and this upgrade also demonstrates why WordPress is a far better platform to stick with; Automattic have said that they started from scratch with the dashboard because of the negative reaction to 2.5, and they’ve delivered something that feels solid and thought out.

  7. @Josh, yes true, but you have assumed that “quality code” of the core will continue into the future. It’s always a good idea to know what the changes are exactly. Nothing stopping a few holes appearing in the future.

    Also consider a large RC testing group in most cases is not really a solid user test just a moderate user acceptance test. 99%+ of RC people just don’t respond with the errors that occur.

    It is nice to see a professional design being approached logically and with vigor in version 2.7 dashboard compared to version 2.5.

  8. I don’t think that 99% of RC and Beta users wouldn’t speak up – if they go to the effort of downloading the pre-releases, they’re going to be at least a little inclined to help out.

    You’d have to agree that WordPress has only improved since early versions too. That ‘quality code’ isn’t going to get scrapped if it is just that – there’s only been one large alteration in the structure that I’ve seen widely talked about (i.e. deprecated codex entries) – and the result was a massive improvement. And unless you’ve got massive issues with haters, waiting for you to slip up and impair your website’s security – the very large majority of WordPress users will never be effected by security issues with the platform.

    I guess it takes a little faith – but if you’ve stuck with WordPress as long as I have you realise after a while that Automattic’s pretty damn good at what they do – and they have an authentic interest in their users and community, which is pretty rare.

Comments are now closed, move along, nothing to see here.