The eleven step process includes making a work directory (so you don't copy over your current install and all of its lovely plugins and templates) and copying over a few key files to update to the latest release:
Copy blog.original/wp-content/plugins to blog/wp-content/plugins
Copy blog.original/wp-content/themes to blog/wp-content/themes
Copy blog.original/wp-content/uploads to blog/wp-content/uploads
Copy blog.original/wp-config.php to blog/wp-config.php
Copy blog.original/.htaccess to blog/.htacces
For more information on upgrading your WordPress installation, check out this entry on their wiki.
In a new post to the Developer Tutorials blog Akash Mehta takes a look at migrating PHP4 applications up to the more recent versions of PHP5.
PHP 5 supports most of the legacy syntax features of PHP 4. Most code written for PHP 4 should function fine under PHP 5, and a comprehensive test suite could check this. However, many of the backwards-incompatible changes in PHP 5 were in regard to language quirks, and quite a few hacks rely on these in order to function.
He points out some of these hacks including changes to the object model and updates to the way variables are handled (breaking many "bad use" cases). He also points out the changes made in the latest Windows binaries as well as some of the new reserved keywords that could conflict with pre-existing code in your application.
As Ivo Janschpointed out yesterday it's a month until the fateful day that PHP4 will officially die:
It's July the 8th. Today I realized that we're exactly one month away from 8-8-8, the final blow to PHP4.
August 8th marks the point when nothing (at all) will be done to any version of PHP4 again. Full support ended back in December of 2007 with no new versions being released. 8-8-08 marks the end of that as well and PHP4 developers that discover bugs may not be able to get them fixed.
Ivo sums it it perfectly:
I'm not trying to scare you. No wait, I am. Don't let 8-8-8 become the PHP community's 6-6-6 and abandon PHP4 while you still can.
In a new post, Greg Beaver talks about a few things, the main one being a new release of the phar extension he's made - phar version 2.0.0a1 - a reworking of the previous functionality with loads of new features including:
Phar now supports tar and zip archives with the same API that is supports phar archives.
Phar has a front controller for web applications that fully handles MIME types, supports mod_rewrite-like functionality with far more flexibility
Phar supports phar:// stream wrappers in include_path for PHP 5.2+
Phar supports creation and modification of data-only tar and zip archives (no executable phar stub) via the PharData class.
There've also been updates to the manual for the project to reflect this new version of its API. You can download this latest version here: source or Windows DLL.
The Symfony project is recommending you upgrade your plugins to the latest editions - an issue with the PEAR channel caused it to load the wrong ones:
A problem in the symfony project PEAR channel made the plugin-install task always install the oldest version of the plugins, instead of the latest. If you recently installed plugins with the symfony command line, you probably installed an outdated version. Plugins installed via SVN are not affected.
You'll need to run a plugin-upgrade command for each of the plugins installed on your system to ensure that you're completely up to date. The post has complete info on how to tell which plugins you have and the exact commands to issue to being them up to date.
Version 1.6.1 is primarily a maintenance release, but does bring a handful of nice feature additions and enhancements. After a very successful 1.6.0 release, a series of bugs have been squashed and enhancements have been made that we wanted to roll out as a formal release.
The update process is just replacing a few files from your current installation. Check out the Changelog for more information on the updates made and, if you're not quite sure what you're doing on the update, check out their handy update instructions.
Further details about this release can be found in the ChangeLog.
Sebastian also includes instructions for upgrading your installation and links to some documentation to help you find out more about this popular PHP unit testing tool.
Tony Bibbscomments today about some issues that he's been having with his installation of Zend's Studio IDE ever since he made the update to a more recent version of SUSE - version 10.3.
Well, upgrading from openSUSE 10.2 to 10.3 has been a bit brutal. [...] So this morning I got to work and had a customer demo and felt I needed to have the Zend Studio IDE working to be able to make some quick changes on the fly and it would work.
His problem was with an assertion issue - the resource the software was trying to access was locked. He did find a solution, though on Chris Hope's blog involving a sudoed call to sed to replace a value in one of the shared libraries for Zend Studio, replacing one variable name with another.
Felix Geisendorfer has a reminder from developers out there - "PHP 5.2.1 was an evil release":
While I was at php|works I heard a lot of people say how bad of a release 5.2.1 was and that I should stay away from it. Well I didn't take it to seriously at this point, but when I checked what version of PHP we are running on my client project recently it turns out it was 5.2.1.
They were seeing performance issues (database related) so they upgraded to the latest version, 5.2.4, and immediately saw a performance jump of forty to sixty percent and a much lower amount of CPU usage. Upon some further research, he found a certain bug in 5.2.1 that could have been the culprit.
Marco Tabini (of php|architect) has posted some thoughts to his blog about the PHP4 end-of-life announcement and its relations to the current push to go PHP5 - mainly how it relates to hosting providers.
I'm sure that a large number are owners of small hosting firms - which, by far, provide the vast majority of PHP-powered websites that Netcraft carefully tracks for us - that sell cheap shared hosting. [...] If you provide shared-hosting plans, it's likely that your servers are still running PHP 4. Upgrading to PHP 5 is a logistical nightmare for two reasons: first, you don't necessarily know that you'll be able to properly set up and secure your systems; second, you don't know that your customers' applications will keep on running.
Both reasons can cause very different kinds of hassles for the hoster, especially when it comes to their customers. As Marco puts it "hell hath no fury like a customer scorned". When things are going smoothly, everything's good, but the second that you try to explain that the update is what's good for them, all they see are things breaking and freak out.
He suggests only one real solution - make the move and tell the customers now that things are changing. Help them all you can (with information about updated software and resources) but ultimately it's up to them to make the change.
