Technology Tales

WordPress 2.6 out in the wild

Though there was a time when I tested out a new WordPress release when it made its appearance, I now keep tabs on development versions too. It helps me to be ready in ample time and avoid any ugly stuff appearing on either here or my hillwalking blog. On the surface, the changes made don't seem so dramatic after the revamp of the administration interface that came with 2.5. Under the bonnet, many bugs have been fixed, and many behind-the-scenes features have been included for the first time. I'll leave it for you to go to Planet WordPress or check out the relevant entry on the WordPress Development blog. You'll find a Flash video tour of the latest version from Automattic below.

Of course, WordPress development doesn't stop here and there are some considerable changes to the administration interface to come at some point if they ever make out into the mainstream from the crazyhorse branch. I'll be continuing to keep an eye on how things go from here to be ready for whatever might be in the offing. For now, enjoy 2.6, though it'll be interesting to see where it all goes from here.

Some nice things coming through...

While everyone is making good use of WordPress 2.5.x, development continues apace for future releases of the popular blogging platform and there are some goodies coming through on the functionality front. Google Gears are being brought into play for speeding up the administration dashboard; this started out being more prominent before being made more unobtrusive. The other big change has been an overhaul of the theme gallery and, if the theme is compatible, an overview facility has been added too. So WordPress is being tweaked and improved in the background to make 2.6 an interesting release.

A spot of WordPress 2.5 administration panel colouration

Though the final release of WordPress 2.5 isn’t out yet, that hasn’t stopped me playing around with it and spotting a bug or two. Along the way, I have taken the chance to create a plugin that takes the old Earthtones palate into the new world. To accomplish this, I have taken the WordPress Classic stylesheet defining colours along with some template code from planetOzh and tweaked it accordingly. While I may not have got to every possible nook and cranny for colouration, I hope to have covered most of them. You may even find it useful yourself.

Download Countrytones

Hosting more than one WordPress blog on your website

An idea recently popped into my head for my hillwalking website: collecting a listing of bus services of use and interest to hillwalkers. Being rural, these services may not get the publicity that they deserve. In addition, they are generally subsidised, so any increase in their patronage can only help maintain their survival.

Currently, the list lives on several pages page in the blog, but another thought has come to mind: using WordPress to host the list as a series of log entries, a sort of blog if you like. Effectively, that would involve having two blogs on the same website. One way is to set up two instances of WordPress in the same place, where they could work from the same database; the facility for this is allowed by the ability to use different table prefixes for the different blogs so that there are no collisions. While there's nothing to stop you having two databases, your hosting provider may charge extra for this. This set up will work, but there is a caveat: you now have two blogs to maintain and, with regular WordPress releases, that means an extra overhead. Apart from that, it's a workable approach.

Another option is to use WordPress MU. That would cut down on the maintenance, but there are costs here too. Its need for virtual hosts is a big one. If my experience is any guide, you probably need a dedicated server to go down this route, and they aren't that cheap. I needed to do a spot of Apache configuration and some editing of my hosts file to get my own installation off the ground; I don't reckon that would be an option with shared hosting. Once I sorted out the hosts with a something.something.else address, set up was very much quick and easy.

Apart from a tab named Site Admin, the administration dashboard isn't at all that different from a standard WordPress 2.3.x arrangement. In the extra tab, you can create blogs and users, control blogs and themes as well upgrade everything in a single step. Themes and plugins largely work as usual from an administration point of view. With plugins, you have just to try them and see what happens; one adding FCKEditor threw an error while the editor window was loading, but it otherwise worked OK. I had no trouble at all with themes, so all looks very well on that front.

Importing and editing posts worked as usual but for two perhaps irritating behaviours: tags are, not unreasonably, removed from titles and inline styled and class declarations are removed from tags in the body of a blog entry. Both could be resolved by post-processing in the blog's theme, but the Sniplets plugin allows a better way out for the latter and I have been putting it to good use.

In summary, WordPress MU worked well and looks like a very good option for multi-blog sites. However, the need for a dedicated server and the quirks that I have seen when it comes to handling post contents keep me away from using it for production blogs for now. Even so, I'll be retaining it as a test system anyway. As regards the country bus log, I think that I'll be sticking with the blog page for the moment.

Keeping an eye on WordPress development III

If the milestone date was to be believed, WordPress 2.5 was due yesterday. However, it has yet to show up, and a brief look at WordPress Trac reveals why: loads of outstanding tickets relating to bugs. In fact, there seem to be more tickets associated with this than other releases. I suppose that we can expect the new release when we see it then. Interestingly, the administration screen theming references have been removed from the pre-release version, so that's a functionality for a future release, and it's not difficult to see why. Otherwise, the style of the screens in the latest Subversion revision looks a bit smarter and my blog themes are not getting broken. For my online blogs, I'll be sticking with 2.3.3 for now.

Alternatives to WordPress

Movable Type was the leading blogging platform before Six Apart disappointed their users with their licensing and WordPress came into being. Now that WordPress would seem to be king of the hill, it's tempting to conclude that there's nothing else out there for those wanting a self-hosted blog. In fact, nothing could be further from the truth.

These days, Movable Type is available as an open source entity and I have been giving it a quick whirl. Importing from a WordPress export file is very swish and a quick spot of tinkering gets you a running in no time. Getting the thing set up can be a little confusing because the processing is done by CGI scripts, and they need to live in your website's cgi-bin directory while the actual blog is instantiated in another location. Aside from that complexity, things are not that off-putting, and the style of the administration and content management dashboard could show WordPress a thing or two. It's partitioning of trackbacks from comments is another useful feature in this world pervaded by comment spam.

Habari is another option that I have encountered, and it seems like early days for this one. The first impression that struck me was its minimalist feel, but it will do most of what you ask of it when it comes to blogging. Nevertheless, importing and exporting is one area that needs more development and its handling of themes is a matter that warrants more exploration on my part. In summary, it seems to offer most of your needs, even if there is nothing to make it stand out from the crowd at this time.

I encountered another alternative platform in the pages of PC Plus called Expression Engine. It is commercial software, yet there is a free cut down version available without some of the modules. There is a bit more to the offering than blogging, but you have to buy it to get features like wikis, forums and the like. As it happens, the blogging capability in the free version is creditable, and it appears that you can manage multiple blogs through the same interface, a feature that has potential when it comes to using the software as a kind of CMS. It cannot directly import from WordPress, but a Movable Type export file is accepted without a bother. Regarding changing the look and feel of the blog, I found that editing the index and stylesheet files through the administration interface produced good results quite easily and quickly. Maybe creating a new theme might be a worthwhile project to see how one can make a blog's appearance fall into line with the other parts of a website. After all, Ellis Labs claims that the software should work the way that you do.

I only have done a quick spot of fiddling with any of the above, but there is potential for further investigations to see what else they have to offer. I am sure that there are other alternatives and the CMS Drupal comes to mind for its having a blogging module, even if I didn't find the main CMS functionality to be sufficiently flexible for my needs when I last tried it (a new version made it appearance recently); overly complex CSS was one bugbear for me. Even with all the possibilities, I won't be spending too much of my time exploring this area. Suffice it to say, it's not a completely WordPress world...

Keeping an eye on WordPress development II

While I don't know if this might become a series, a sequel to an earlier post might be a sign of things to come. When I was pulling another version of WordPress from Subversion, I noted a lot of updated files coming through, more than usual. Curiosity led to my having a look and there have been a few obvious tweaks. The most noticeable of these is that the Plugins portlet was now active, making its role clearer.

The role? Apparently, it feeds a random selection of WordPress plugins from those included in WordPress.org's own listings. It might be useful or an annoying diversion, but we'll see what comes; it is not configurable for now. Otherwise, the admin screens look a little sharper, especially the ones for editing and managing content. I'll continue to await the arrival of the ability to apply admin screen themes: it's a "TODO" on the dashboard screen and could be interesting if it were to come about. We'll see...

Keeping an eye on future WordPress releases

While I haven't mentioned WordPress in a while, it's now heading for version 2.5 after 2.4 was skipped. Because I want to ensure that upgrading doesn't cause problems for my blogs, I have been picking up nightly builds with Subversion from WordPress.org. The following is the command to be used, which it works fine on my Ubuntu system in the folder where I want the WordPress installation directory to live. If you wish to find out more about Subversion, there is a free book on the web.

svn co http://svn.automattic.com/wordpress/trunk/

The main event is the new dashboard, and that seems to be taking cues from Movable Type (I gave that a whirl recently, so I may say something here about it yet). Everything is still there, along with tantalising hints of prospects for customisation. In the interim, you can change the front page feeds so that they originate from other than the world of WordPress, not a bad thing given that I found WordPress Planet feeds were annoying often. Alternate theme support for the dashboard seems to be on the to-do list, as is something for plugins; we'll see what comes of the latter. Otherwise, nothing seems to be changed or, more importantly, broken, and I am able to get a mirror of my outdoors blog up and running with the only problems of any note coming from the new web address, not at all major. For now, I'll continue to keep tabs on what's happening; being forewarned of any future problems is a big bonus.

Update:

Recently, I found a good summary of what to expect on Blog Herald. This is one for a return visit, methinks.

Setting up a test web server on Ubuntu

Installing all the bits and pieces is painless enough so long as you know what's what; Synaptic does make it thus. Interestingly, Ubuntu's default installation is a lightweight affair with the addition of any additional components involving downloading the packages from the web. The whole process is all very well integrated and doesn't make you sweat every time you need to install additional software. In fact, it resolves any dependencies for you so that those packages can be put in place too; it lists them, you select them and Synaptic does the rest.

Returning to the job in hand, my shopping list included Apache, Perl, PHP and MySQL, the usual suspects in other words. Perl was already there, as it is on many UNIX systems, so installing the appropriate Apache module was all that was needed. PHP needed the base installation as well as the additional Apache module. MySQL needed the full treatment too, though its being split up into different pieces confounded things a little for my tired mind. Then, there were the MySQL modules for PHP to be set in place too.

The addition of Apache preceded all of these, but I have left it until now to describe its configuration, something that took longer than for the others; the installation itself was as easy as it was for the others. However, what surprised me were the differences in its configuration set up when compared with Windows. There are times when we get the same software but on different operating systems, which means that configuration files get set up differently. The first difference is that the main configuration file is called apache2.conf on Ubuntu rather than httpd.conf as on Windows. Like its Windows counterpart, Ubuntu's Apache does use subsidiary configuration files. However, there is an additional layer of configurability added courtesy of a standard feature of UNIX operating systems: symbolic links. Rather than having a single folder with the all configuration files stored therein, there are two pairs of folders, one pair for module configuration and another for site settings: mods-available/mods-enabled and sites-available/sites-enabled, respectively. In each pair, there is a folder with all the files and another containing symbolic links. It is the presence of a symbolic link for a given configuration file in the latter that activates it. I learned all this when trying to get mod_rewrite going and changing the web server folder from the default to somewhere less susceptible to wrecking during a re-installation or, heaven forbid, a destructive system crash. It's unusual, but it does work, even if it takes that little bit longer to get things sorted out when you first meet up with it.

Apart from the Apache set up and finding the right things to install, getting a test web server up and running was a fairly uneventful process. All's working well now, and I'll be taking things forward from here; making website Perl scripts compatible with their new world will be one of the next things that need to be done.

Changing the appearance of WordPress admin pages

There appears to be a percolation of plugins that aim to change the appearance of WordPress administration pages from their day-glow blue to something more pleasing; Earthtones is the one that I use for this blog, but I have also been known to use WP Tiger Administration as well. Both options work well, though the latter needs some adjustments to work as well with WordPress 2.3 as it does with the 2.2 line.

One area that they both fail to influence is the appearance of the upload screen. It doesn't help that upload.php, the underlying PHP script, is a dual-purpose animal: used in an iframe in the post editing page and standalone for upload management. Curiously, you can only upload files on the post editing page and not on the upload management screen, a definite quirk. The thing that really stops these admin theme plugins gaining any sort of purchase with upload.php is that it also uses an auxiliary stylesheet, upload.css, that is called after the WordPress function hook has been defined; if it came before this, then the styles in upload.css could be overridden.

While you could edit upload.php and edit the replacement stylesheet, the former activity would require repeating at every WordPress upgrade. I chose to edit upload.css and will keep that is a safe place so that I can replace the file following an upgrade. If upload.php was treated like every other admin script, then this would be unnecessary. A useful suggestion for Automattic, perhaps?