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.

If you have been following along about the upcoming PHP and MySQL upgrade requirements for WordPress, you may have wondered, “Hey, is my WordPress site ready for the upgrade?”

There is a way to tell (more-or-less conveniently): try the Health Check plugin for WordPress. While the description for the plugin declares that there will be more checks in the future, it currently looks at your PHP and MySQL version numbers to see if you are ready for the upgrade.

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

Jeff Chandler, at the Weblog Tools Collection blog, posts that WordPress 2.9.1 beta version will be available shortly to address a WordPress core bug in the 2.9 version.

While undoubtedly version 2.9.1 will include additional bug fixes, there is a bug fix reported in WordPress’ Trac issue tracker:
http://core.trac.wordpress.org/attachment/ticket/11505/ticket-11505-full.patch

So those of you who wish to assemble your own bug fix instead of rolling back to your pre-installation backup can give it a try.

Note: Since this is PHP code, it would be helpful to be familiar with PHP.

By now, gentle readers, you have probably seen the Javamancy mini post about the one-liner deletion for .svn files.

I really like Adam Bien. He seems like a nice guy, and I occasionally drop by his blog, on a lark, to read his stuff, which is often focused on Java and NetBeans, one of our favorite IDE’s that we use regularly for DevPal and Javamancy dev work, especially for Java and PHP. Now, I have never met him personally (which is unfortunate, since the inevitable Formidable Brain-Pick would come out, and I’d be picking his brain with it furiously (figuratively, ‘natch)), nor have I observed his programming, CM, and shell skills in action.

So I thought it was curious that he posted about how to delete all .svn files with a “one-liner”. Being a collector of snazzy UNIX scripting that make my life easier, I just had to look…

The Debated Script

Now, keep in mind that Adam mentions that he found the one-liner elsewhere, but he liked it enough to post it.

Here is what he suggests as the one-liner:

find . -name ".svn" -exec rm -rf {} \;

And this would be fine, under normal circumstances, if you are considering a relatively small population of .svn files that you want to remove and you do not care if somebody mistakenly named something on the filesystem as “.svn” despite it not being a Subversion directory.

But if you are like me, and/or you have at least one of several different CM structures that you support within one or more different versioning systems, and/or you have both people and automata that frequently access and modify those CM structures, you are most likely going to have thousands, tens of thousands, hundreds of thousands, or perhaps millions of .svn directories that you have to account for. And you may have noticed that when you feed a large parameterized file list to the rm command directly causes it to choke after only a few hundred (or in some cases, several thousands, depending on your OS) entries.

What DevPal Does

So here’s an excerpt from one of my scripts that leverages the xargs utility to spoon-feed the rm command with smaller digestible chunks from the potentially huge file list that the find command readily retrieves:

find . -type d -name .svn | xargs rm -rfv

Like Adam’s snippet, I want to use the current directory position, but if you want to parameterize that to some other location (i.e., other than “.”), you certainly could.

Also, note that I’m only interested in directory names… I am not interested in non-directories that match “.svn“. This may or may not be the behavior you are supporting, so you may want to change the filetype specifier (say, to “f“) or drop it altogether.

Now, for the rm command switches: I tend to like to see what is going on during the deletion process, so in addition to inducing recursion through directories and forcing deletion without confirmation, I also want a bit of on-screen verbosity to show me what is being deleted. In this way, if I want to log the behavior, I can certainly redirect the output to a file or to a remote service. Anybody Hudson’ing, or just Ant’ing or Maven’ing with this?

Script or Not?

Technically, while Adam offered up the one-liner as just that… a one-liner… I would guess that many of you have wondered about whether it makes more sense to wrap a script around it and give it a snazzy name. My recommendation is, of course, yes.

N.B.

.svn as a directory

You may have noticed that there seems to be an interchangeable use of “files” and “directories” when referring to the .svn content. Which is correct? Both, actually, and it depends on your approach or perspective.

Contents of the .svn directory

Whenever you browse your local directories within your sandbox, you will see that the .svn entries are actually directories. But if you peek into those directories, you will notice that there appears to be a set naming scheme to the files in there… as if they are arranged in a certain way to allow something (like a local database engine or parser ( )) to efficiently access and modify the metadata for the versioned content. So, when referring to the .svn structure and contents, the UNIX-y notion of directories being also files can be more-inclusive.

By the way, this notion is also applicable for other versioning systems, including CVS (Subversion’s forebear).

The Setup

“What should you do when that Ol’ Tester Magic grabs a hold of you?”

Dunno.

But what you can do is sit around at a nearby coffeehouse, drink your coffee, finish your coffee, get a refill and drink that one, and then declare to all the other crazies sitting around you that you’re going to set up a bunch of publicly accessible test/preview sites.

The Premise

We’ve been doing plenty of testing internally for a variety of stock and commissioned software products and components, which is all great and fine… at least on the Java side. It’s a fairly well-understood, documented, regimented series of cooperating workflows that mesh well.

But what about the PHP code that we’ve been trickling out into the public? Or Web sites, like Javamancy, that have a structural aspect alongside the content (such as this post) that require careful feeding and maintenance over its lifetime? Don’t they also deserve a more extensive set of tests, previews, new concepts and integrations, etc.?

The short answer is: yes.

The Action

The plan is simple: starting soon (ostensibly in April 2009 if we stick to the initial development schedule), we’ll be setting up a few test/preview sites for Javamancy, among others, so that our kind and gentle readers will have an opportunity to see new features as they enter our pipeline for the public-facing (and some commissioned) Web-based products. These activities should not significantly alter many of your current work habits (at least, hopefully not), and it should not deter our Java folks from continuing with their favorite products and services that they know and love.

Just think of this as something “extra”.

Because when that Ol’ Tester Magic grabs a hold of you, odd things seem to happen…

It’s been awhile in coming, but it’s finally here: NetBeans 6.5.

Like many of you, I’ve been itching to have a plethora of development capabilities integrated into a single unified interface that does not require me to constantly scour the Internet, or several different vendors’ sites, or even just constantly ping around various different “repositories”, for the latest updates and fixes.

Not to take anything away from Eclipse (the other heavy hitter in the IDE arena), but having to manage the massive amount of Eclipse-lets or fall in line with a specific distribution has brought along its own synchronization issues. In the past, it had gotten so onerous that I had to create a team to manage our Eclipse configurations. In contrast, my NetBeans-using teams were able to just get along with their single image and a select set of add-ons, getting their work done.

Of course, there’s a lot of convergence between NetBeans and Eclipse; that will undoubtedly continue well into the future, until perhaps the two projects merge into a single product(?).

One of the big things that NetBeans 6.5 brings to the table is the long-awaited official support for more dynamic languages. This production release brings some of them to us, especially PHP (which previewed on a beta of 6.5 for awhile).

Check out the NetBeans release at the NetBeans.org site. You can also read about its features and even watch a few screencasts to familiarize yourself with the product prior to installing it.

Or you can just click on the download banner in this blog entry to start fetching your own copy.

N.B.

Yes, I advocate the use of NetBeans as part of the primary development rig at DevPal and Javamancy. Now comes the fun part: testing the IDE for its appropriate integration with the rest of the dev rig, as well as the CM and project control platforms.