Drupal 4.7 RC1 is released and you're looking at it! The upgrade from 4.6 couldn't have been easier--delete the old files, insert the new files, run an upgrade script, update modules and done. It took me about 15 minutes on this site. I have a few other Drupal sites that use modules that haven't been released for 4.7 yet so I'll probably wait on those.

What's new in Drupal 4.7? Here are the changes from the changelog that I thought were most interesting (my comments in red)

• added free tagging support. woohoo!
• added a site-wide contact form.
• added the PHPTemplate theme engine
• reworked the 'request new password' functionality.
• reworked the node and comment edit forms These are much nicer now!
• made it easy to add nodes to the navigation menu.
• added site 'offline for maintenance' feature.
• added support for auto-complete forms (AJAX).
• added support for collapsible page sections (JS).
• added support for resizable text fields (JS).
• improved file upload functionality (AJAX).
• made it possible to alter, extend or theme forms.
• added support for "mass comment operations" to ease repetitive tasks.
• reworked the revision functionality.
• added a block to display author information along with posts.
• added support for private profile fields.
• added the ability to track page generation times.
• made it possible to block certain IPs/hostnames.
• added support for theme-specific block regions.
• made the aggregator module parse Atom feeds.
• made the aggregator generate RSS feeds.
• added RSS feed settings.
• added 'loose caching' option for high-traffic sites.
• improved performance of path aliasing.
• made indexer smarter and more robust. Nice. This needed major work.
• added advanced search operators (e.g. phrase, node type, ...).
• added customizable result ranking.

Over all a huge release with alot of features that have been much anticipated. I'd say that this release probably should have been Drupal 5.

PHPList is a free mailing list/newsletter software written (not surprisingly) in PHP. I set it up for a company that has not yet launched--I wanted people to be able to sign up for a notification of the launch.

• Installation - It wasn't too bad. PHPList assumes that you'll be installing it in the root directory of your site which I thought was a bit odd, but it wasn't too hard to get it to install elsewhere. The trick is to remember that the only folder that really matters is the "lists" folder, the rest don't necessarily have to be below your site root (although once you get it working, you should move them there, or remove them altogether).

• Setup - Getting PHPList to recognize the Database and getting the first user entered was painless.

• Configuration - Configuration wasn't as easy. Some of the config is done through the file inc/config.inc, some was done through a rather long configure page in the web interface. Most of the options were understandable, but I did find myself going back to that page to change things fairly often. I think the configuration could be greatly simplified by splitting up these screens into several pages with related options.

• List creation - Creating and configuring mailing lists was fairly painless as well. The feeling I got was that the software lets you do the same thing in multiple places and that the workflow was difficult to follow. After doing it a couple times I began to get the feel for it.

• Customization - Making HTML emails and text emails is no problem, nor is changing the look of the subscribe pages.

Looking over the above, I think that what isn't conveyed is that this software isn't something that you'll have set up and running in an hour. Expect to spend about 3-4 hours minimum the first time around. From there, creating lists, email and managing users is a breeze.

Downsides - I realize this is free, open source software released under the GPL. No one is making money off it. That having been said, my biggest problem with PHPList is that there are "Powered by" notices everywhere. They appear on subscribe/unsubscribe pages, in the meta tags and essentially every place the user could possibly view. I've got no problem with giving some credit, but this time I found it a little overwhelming. I spent quite a bit of time toning down the "Powered by" notices. I'd suggest making them a little less obvious and ubiquitous by default and if people choose to do so, let them remove them. Most people will probably choose to leave the credits.

Upsides - It's free. It's fully featured--I didn't find any feature that I saw in other mailing lists/newsletter software missing here. Kudos to the author - Michiel Dethmers for doing such a great job and releasing it as open source.

I'd recommend PHPList if you've got some time to spare to learn the interface and experience in setting up PHP scripts on the server. It's not simple, but it's the most powerful open source/free newsletter management software available (that I know of), matching (and often exceeding) many of the features of commercial mailing list solutions I investigated.

A lesson that I've learned after installing many content management systems is that me and Perl (a programming language) don't get along well. I've found that web applications written in Perl have two characteristics

1. They're usually the most powerful and full-featured and
2. They're the hardest to install and keep running right.

Examples:

Twiki - If you're looking for a Wiki that does it all and does it extremely well, look no further than Twiki, billed as "an Enterprise Collaboration Platform" it lives up to its title. Installing it however took me 2-4 hours a day for a solid week. I kept thinking it was good to go, then I'd start using it and yet another problem would show up. It was a seemingly endless cycle of tinkering, asking questions and trying anything I could think of. Apparently there are people who can get it up and running solidly since Yahoo!, Cingular, Disney and Motorola have all found uses for it.

WebGUI - I mentioned WebGUI recently, so I won't go on too much about it, but it's powerful. Templating in WebGUI is phenomenal, asset management and user managment are as well. Installing and upgrading it are surprisingly difficult. WebGUI taught me to hate CPAN (an archive of Perl code libraries)--they rarely seemed to install correctly and I don't know enough about Perl to intuitively know why. I've spent dozens of hours reading documentation and compiling Perl libraries trying to get WebGUI going correctly. In the end, it was worth it but really... there has to be a better way.

MovableType - I actually can't complain too much about the popular blog software MovableType, but it is much more difficult to install than WordPress in my experience. Once it's up and running it's excellent.

Interchange - Interchange is "an open source alternative to commercial commerce servers and application server/component applications"--basically an ecommerce platform. I installed it once on RedHat 9 and it took all day one day and part of another. Once it's up, it's solid and powerful but good luck getting it running.

Maybe you're thinking--"you just don't know Perl or Linux." Maybe you're right, I have no idea, but I do know that I can get pretty much any PHP or Ruby application installed in under an hour. But even after a couple years of experience, Perl still seems to require at least a couple days of my time pecking away in the "black box" of the terminal before any magic happens.

Since this is a site on Content Management, it begs the question, "what content management system do you use?" I picked Drupal. Some of the reasons I felt it would be the best tool for the job (and one case where I don't recommend using Drupal) are:

1. The taxonomy system. Drupal is extremely powerful when setting up categories, sub-categories, vocabularies and anything that has to do with taxonomies. Although stories are currently only sorted by "CMS Type", I could just as easily add "CMS Platform", "Programming language" or any other specific and sort stories by those classifications.
2. Permissions and roles in Drupal are simple and very granular. I really like how easy it is to set up a new role and check a few boxes to give members of that role permission to do as much (or as little) as I feel they should be able to do.
3. Modules and built in functionality. Currently this site is a very simple blog, but later if I want to add forums or other advanced features it's as simple as enabling (or installing) an additional module. Most important modules are bundled, but those that aren't couldn't be much easier to install, you just unzip them in a folder and you're done.

I also picked Drupal because though I'd worked with Drupal before, I hadn't used for one of my own websites and was curious to put it through its paces. So far, I couldn't be happier. The community of developers and users is extremely active, making support a breeze. The default templates look great and are simple to modify. I highly recommend Drupal as a very capable community site CMS. In fact, from my experience, I'd say Drupal is best in breed.

A note if you're not creating a community driven website--one thing that I don't like about Drupal is that it relies on the all-too-common "left and right columns" paradigm. For community-type sites this is fine, but when you're creating a more static site that doesn't necessarily have news posted to it semi-regularly, templating and editing content becomes very tricky. It's possible to get multiple chunks content to display wherever you want them to, but setting it up feels like a hack and knowing where to go to edit the content afterwards isn't intuitive.

WebGUI has always been one of my favorite content management systems because it is the most customizable of any CMS I've used. If you'd like to read about the strong points of WebGUI, over a year and a half ago I wrote a glowing review on my blog. This article isn't so much of a review, but suggestions for what needs to improve for me to be able to continue recommending WebGUI.

1. Simplify installation and upgrades. Every time I install or upgrade it seems like I have to wrestle for an hour with CPAN or some other Perl extension that I have to compile. I absolutely hate dealing with dependencies trying to get WebGUI to work. I've been using WebGUI for years, have access to Ruling WebGUI and paid support, yet I still don't feel comfortable upgrading.
2. Fix PlainBlack.com. The design isn't bad, but navigation is atrocious. WebGUI is the main product PlainBlack offers, but nowhere to be seen on the front page is "About WebGUI" or "Demo WebGUI" or "Why Use WebGUI." There is a banner-ad looking link that says "Find out if WebGUI is right for you" but the font is small and it's easy to overlook. That information should be immediately apparent. I'd suggest redesigning the entire site navigation based on questions and destinations users might have in mind when they first go to the site. I'd also suggest using one url rather than spreadwebgui.com and plainblack.com. Personally, I feel that spreadwebgui.com is what plainblack.com should look like. [update - since writing this, it appears they've started doing exactly what is suggested here--kudos!]
   
3. Stop releasing unstable software. Releasing early and often is one thing, but make sure it's working. I'd suggest only advertising releases of stable versions on the front page (or any easily accessible portion of the site) and saving the betas for developers or people who aren't using WebGUI for production sites. I'd suggest totally dropping the use of alpha, beta, gamma and complex version numbers and moving to a more easily understood "beta" and "stable" and simple versioning - 6.0, 6.5, 7.0.

I could go on, but basically, WebGUI is excellent software that is currently suffering from several buggy releases, a bloated and hard to navigate website and very difficult installs and upgrades. Right now my recommendation with WebGUI would be "keep an eye on it." It's still the most customizable CMS I know of, but I wouldn't recommend it for live websites.