TOPIC: WORDPRESS
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?
What about a book on WordPress development?
Here's something that I would really appreciate: a book on code cutting for WordPress customisation and extensions. Having the Codex is all very fine, but having a dead tree compendium that you can peruse at your leisure is a definite bonus. If there was a way to get the Codex on PDF and print it all off for easier reading, that would be progress. Though I believe that a publisher did plan to bring to the market something like what I want, the author and publisher parted company, a pity. It would be great to see something like Apress' Pro Drupal Development for WordPress. What about it, Automattic folks?
On Blogrolling.com
I was ambling around the web and came across a website that, while it appeared to be a blog, isn't one in the vein of that to which we are accustomed. It does, however, have a blogroll and that is where Blogrolling.com comes into this piece. Blogrolls are very much a feature of the blogging (WordPress calls them that anyway) world and act as a repository of useful links relevant to the subject of the blog. I also use them as a bookmarking station for myself and a way to return the favour when someone links to my blog. For a blogroll, you generally need a database sitting behind in the background, or you end up creating a list of links in (X)HTML.
Blogrolling.com offers another option: placing your links at an external website and including them on your webpages, using a piece of code to pull in the information. RSS, JavaScript and PHP are among the methods on offer from Blogrolling.com; I used PHP when I gave the service a whirl on one of my offline blogs and that really does give you a lot of customising power over and above using CSS. That's not to say that there aren't customisation functions on offer from Blogrolling.com, I found a few of these distinctly useful: ordering of links in a blogroll is just one. When it comes to categorising your links, you don't get the category option, but you do get to create as many blogrolls as you want, so there is a workaround; moving links from one blogroll to another is mouse intensive but straightforward. Also, because you are reading each blogroll in turn, you can order the categories as you want them. With WordPress' category approach, ordering categories involves widgets and plugins or getting your hands dirty with some code cutting. All in all, Blogrolling.com seems to offer an intriguing and useful service.
Quoshing WordPress 2.3 upgrade gremlins…
Primarily because of the WordPress plugins that I use, a few inconsistencies have leaped out of the woodwork that needed to be fixed. Here are the issues that I encountered:
Database errors appearing in web pages
This was a momentary discovery along the upgrade trail, entirely caused by the way in which I was doing things. As usual, I went and copied over the WordPress 2.3 files to my web server, so I saw these errors before I ran the upgrade script. Then, they were banished, confirming that WordPress 2.3 code was trying to access a WordPress 2.2 type database; 2.3 has made some database changes to incorporate tagging.
Dashboard Editor no longer fully functional
The move to JQuery meant that some of the things for which it was looking had changed. They also changed the incoming links provider from Technorati to Google, now that the former is having a tougher time of it. It took a while to track down why I was unable to remove components from the front page of my dashboard as before, but a quick comparison of 2.3 code with its 2.2.3 forbear revealed all. I can make a copy of the updated code available for those who need it.
WordPress Admin Themer
The plugin works as before and does its job so well that you end up applying an old stylesheet (in the blog's theme folder) to the latest release. It only took a spot of tweaking to put everything in order.
I am not complaining about any of these, partly because they were easy to resolve and, in any event, I don't mind a spot of code cutting. However, I can foresee some users being put out by them, hence my sharing my experiences.
Update: Dashboard Editor has since been updated by the author. Even so, I will stick with my own version of the plugin.
Running SQL scripts with MySQL
Here's another of those little things that you forget if you aren't using them every day: running MySQL scripts using the Windows command line. Yes, you can also run SQL commands interactively, but there's a certain convenience about scripts. I am putting an example here so that it can be found again easily:
mysql -u username -p databasename < script.sql
Though I wouldn't be at all surprised if the same line worked under Linux and UNIX, I haven't needed to give it a try.
WordPress database error: [Can’t create table … (errno: 121)]
When I was trying to upgrade one of my test blogs to WordPress 2.3 RC1, I got error messages like the above littering the screen during the installation. The PHP functions mysql_noerr (or mysqli_noerr) and mysql_error (or mysqli_error) seem to have been busily at work. These messages told me that the upgrade hadn't worked, so I went off googling as usual and perusing the MySQL tomes in my possession. Not for the first time, the web yielded nothing but dross and, in the end, I tried deleting the relevant database and starting from scratch again. That resolved the problem.
The reason for database deletion sorting things out is that MySQL got confused when there was a mismatch between what was in the file system and what its InnoDB table was saying. Now, I think that the cause of this was that I naively copied in tables using Windows Explorer. Deleting the database cleared the air and all was well once I allowed WordPress to do the needful in its time-honoured way. With another lesson learned for the future, I wish that frustration wasn't part of the learning experience too...