With the recent release of WordPress 3.3, “Sonny”, there would most likely be issues during the upgrade process for some site administrators and deployers.

WordPress.org’s forum has a “master list” of tips and tricks to try to resolve those issues, preferably before filing an issue ticket with them.

Of course, if you’re going to undertake an upgrade, you should take the necessary precautions of backing up your site (including the database) first!

Here’s a nice post by Jane Wells (yes, the one of WordPress fame) about the requirements for WordPress 3.2 and some rationale about the system changes being implemented for the latest version of the blogging software.

The big news is actually not that big: the version of Oracle’s [ORCL] MySQL database and the PHP engine have been locked in at recent versions:

• MySQL 5.0 or higher
• PHP 5.2.4 or higher

For most site hosting services, this is not a problem. In fact, a lot of the services have been actively pushing their customers to upgrade their Web applications to PHP 5 and recent versions of MySQL for years. But a significant, popular software package like WordPress has enough impetus to push the holdout administrators over to more modern versions.

Yep, it's a video game sales ad... touting Amazon.com's limited time offer...

In case you haven’t noticed the sidebar ad for it on some of the other DevPal/Javamancy sites, you may have spotted it here, on Javamancy itself.

It’s a text ad for Amazon.com’s limited-time offer on video games (well, it actually includes PC and Mac games, as well).

We’re experimenting with some of our real estate, and why not allow you, our gentle readers, an opportunity to maximize your gaming potential and thrills at the same time?

As many of you know, WordPress depends upon a variety of software packages to do the things that it does, as a weblog product (and some of you have extended it even further…). Two of these things are foundational items: PHP, the language and operational runtime for WordPress, and MySQL, the persistence datastore that WordPress uses.

Both of these are being incremented upward to more current versions.

For many WordPress  administrators, this will not be a dramatic issue, other than confirming your settings with your site host; some may require some configuration switches being “flipped” to use PHP 5.2 and MySQL 5.0.15. There may even be some adjustments to your site’s php.ini file.

However, if you’re a big-time hacker, and you’ve been coding in some changes to the base WordPress package (and who doesn’t these days, right?), then you will need to ensure that your code has not been exploiting some of the PHP 4 quirks that have changed in PHP 5 syntax: you will have to rewrite or redesign those parts of your code. For some developers, this endeavor may not be trivial.

On the other hand, the MySQL upgrade is generally better tolerated, since a lot of PHP developers tend to use the provided MySQL connector API. Again, however, if you are one of those who enjoys spinning up your own, parallel data persistence API or are using another package in addition to the WordPress one, you will have to ascertain the LoE for modifying your code. Also, if you have crafted some stored procedures for your MySQL 4 instance(s), you may have to re-implant them into your waiting MySQL 5 instance(s) once they are ready. Code-wise, it should be a straightforward import for most developers.

N.B.

Further reading of interest:

• PHP
• MySQL (now owned by Oracle)
• WordPress

A scant couple of days ago, Subversion (the project) formally graduated from its incubation phase, becoming a full-fledged Apache project at subversion.apache.org. It seemed like almost yesterday that it had been accepted as a candidate by the Apache Software Foundation (ASF)… In fact, it was in late 2009 that the proposal to join the ASF had been filed, and just a few months later, it made its way toward acceptance.

For those of you who are unfamiliar with what Subversion is, it is an open source file-associated content versioning system. Many developers who are familiar with RCS, SCCS, and CVS have probably heard about Subversion (SVN) as the “next step” toward versioning “modernity” or “modernness”, especially for those who are transitioning from traditional code branching and merging toward changeset management techniques. For people participating in agile configuration management (CM) and coding initiatives, Subversion may have even been selected as the primary (or even, sole) versioning system.

For those of you approaching CM for the first time during this latest iteration of Web development (circa 2006 and onward), while you may be more familiar (and even using) distributed/disconnected/decentralized versioning systems like Mercurial (hg) or Git or even monotone, you also may have heard of Subversion as one of the last vestiges of centralized versioning systems that organizations that have moved onto the current system have used in the past.

For others, the folks who have been using commercial versioning products like StarTeam or ClearCase, you may be scratching your head and wondering what all the fuss is about.

And for those you who’ve been deep in the CM trenches for awhile, you’re probably thinking, “Yeah, it’s about time.”

There are benefits and disadvantages to the features that Subversion provides, and depending on your development requirements, it may be 100% the tool to use, or it may cover enough of the features that you need that it’ll do the trick, or it may be insufficient to match your needs. But it always seems to be on everybody’s short list for consideration, replacing the position that the venerable CVS once held.

For public repository access, Subversion is very popular because a couple of its access methods involve leveraging HTTP rather than a proprietary protocol. For that matter, you may find site hosting services offering Subversion as a way to manage versioned content for Web sites due to its support for WebDAV (however incomplete) as well as to support development codebases, big and small.

So, we’re tickled pink that Subversion has made its way to ASF as a full-fledged graduated project at this time. Kudos!

You may have noticed that we’re starting to use the Tell.im service in some of our links, including in this post.

What is Tell.im?

It is a URL shortening service, similar to many of the others floating around that help to take a very long URL and dramatically chop-it-down-to-a-shorter-length (hopefully). This will make some of our outbound links more uniform and reasonably shorter, so they are ready-to-digest by other services like Twitter. When you activate a Tell.im link, you are redirected by Tell.im to the real destination, whatever that may be.

Admittedly, this may make trackbacks and pingbacks toward Javamancy and other blogs unsightly or unavailable, depending on the other systems’ ability to follow and manage transitive linking.

N.B.

Other related Javamancy mini posts (in reverse chronological order):

• Tell.IM is Now Tell.im
• Tell.im Activity is Becoming Noticeable…

Yesterday, WordPress 2.9.2 was released to correct a bug in which “trashed” blog posts are visible by potentially unauthorized users.

According to Ryan, this can occur when logged-in users attempt to browse the trash area; these users can view posts that belong to others, so sensitive or private information may be inappropriately accessible. Thomas Mackenzie first mentioned this on his blog a few days ago (with a lot of interesting details). An “unofficial” WordPress diff patch was posted for it to address the defect, and WordPress 2.9.2 was released shortly afterward in a couple of days.

This is a good upgrade for WordPress sites which allow for multiple users to log into the system and use different authorization levels to govern various user roles.

N.B.

You may have noticed that we’re starting to use the Tell.im URL shortener in some of our links, including in this post…

UPDATE: Thomas points out that this post had incorrectly attributed the unofficial diff patch to him. According to him, it originated from the WordPress folks.

WordPress 2.9.1 was released yesterday, after a relatively short beta and RC1 pair of cycles.

Some of you may recall the controversy surrounding WordPress 2.9, surrounding some defects that were discovered shortly after its release– although some people have mentioned that the problems, they felt, were present even in the previous versions of the software. As mentioned by Ryan at the WordPress development blog, those noticed defects were addressed by this release, as well as a few other minor issues selected to be included.

Operations Recommendations and Notes

Apparently, since the recent series of posts about WordPress 2.9 and the 2.9.1 beta came out, many of you have been sending E-mails and messages about providing more guidance to prod-ops teams and developers. The following recommendations should not be taken as gospel, since I strongly advocate sound development practices and practical management processes and more than a little common sense: rather, they should be considered in context with your current situation and deployment strategy.

Recommendation for Standard Operations Teams

At this time, the recommendation is that it is a worthwhile upgrade for most technically savvy production operations teams, as well as developers accustomed to using and manipulating WordPress. However, the customary testing procedure is strongly advised: download it, set it up in your testing environment and vet it through your test suite(s), prepare your CM machinery to handle the new version if it passes your tests, and deploy it to your production environment.

Recommendation for Agile Operations Teams

For the heavier types of agile development, if you have already cleared WordPress 2.9, you should be able to layer 2.9.1 on top of your previous iteration and restart your testing segment and merge back to your expected path. Once you have cleared it, you should be ready to deploy it to your staging/production environments.

For the aggro types, you probably have been tracking beta and RC1 versions of WordPress 2.9.1, but the latest changes for it should be considered as overriding the previous two changesets. If you are sweeper types, overlay 2.9.1 onto your outbound segment and restart testing. If you are satisfied with the results, you should be ready to deploy it to your staging/production environments.

Recommendation for Continuum Operations Teams

Yes, I know: this is somewhat redundant. But a couple of you have asked about continuum development recommendations, so here ’tis:

You most likely already know the outcome of your tests, but the question is in which order should your production environments be refreshed. The easy answer would be to use the exact order you have been using all along; however, some teams do have highly variable distribution orders, so the prevailing advice here would be to deploy into production prioritizing first in order of increasing code complexity and then in order of increasing network or traffic load. So your simpler outbound segments with lower traffic and integrations with other packages would be rolled out first, then you proceed upward in complexity and then frequency/traffic/load. For this version, avoid simultaneous or near-simultaneous rollouts unless your tests have already proven 0.00% disruption.

Hint: our tests showed ~4.33% disruption across all outbound segments, > 120.

N.B.

Other related Javamancy posts (in reverse chronological order):

• Stop the Insanity! Or, WordPress Development for 2010, a New Year’s Resolution
• Complaining About WordPress: Does That Make You a Bad Person?
• Uh-Oh: WordPress 2.9.1 Coming Soon?
• WordPress 2.9 Released

Other related Javamancy mini posts (in reverse chronological order):

• WordPress 2.9.1 Now Available
• WordPress 2.9 Now Available

WordPress 2.9 was released yesterday, and with it comes several new features.

As announced by Matt at the WordPress development blog, WordPress 2.9 has come out of its release candidate status into FCS.

Unlike the previous several “minor” point releases of WordPress, which have been devoted toward security and stability fixes, WordPress 2.9 is intended to bring online new features… in addition to the expected security and stability fixes.

Recommendation for Production/Operations Teams

Of course, a new release like this will probably have a few bugs that may make you think twice before deciding whether to deploy it for production use.

Our recommendation is that you should withhold using this version until your QA or GPL-OSS test group has cleared the software.

Recommendation for Developers

On the other hand, for developers and readers who are savvy in their appreciation (and usage) of WordPress, our recommendation is a bit different. If you have a version of your site where you typically try cutting-edge software, or if you are already using one of the beta or release candidates of WordPress 2.9, congratulations: you will probably already be aware of the stability conditions of the software.

More importantly, you are probably already prepared to deal with any unusual behavior of the version, or you have already made your determination of it. Thus, our recommendation is to continue with your current course of action.

Javamancy Operations

Javamancy will not be upgrading to this latest version at this time; instead, it will be deployed to a few internal cycle beds for closer examination while we interpret some recent integration changes that are specific to our configurations.

Thanks for being patient, folks! Until then, version 2.8.6 will be in circulation for a while longer.

For those of you who were wondering whether to upgrade to WordPress 2.8.5, given the relative stability of 2.8.4, wonder no longer: you might as well upgrade to 2.8.6 instead. Yesterday, WordPress 2.8.6 was released, to address a couple of security vulnerabilities found since 2.8.5. Ryan discusses the fixes being provided in 2.8.6: our recommendation is that it is a worthwhile upgrade, particularly if you provide login privileges to some/all of your readers.

In summary: If you operate WordPress blogs and did not yet upgrade from an earlier version of WordPress 2.8.x, you should strongly consider upgrading to this version. The customary testing procedure is recommended: download it, set it up in your testing environment and vet it through your test suite(s), prepare your CM machinery to handle the new version if it passes your tests, and deploy it to your production environment.