When making a start in the world of blogging, there are so many things to consider that you almost need a trial run first to learn the lingo. In fact, getting up to speed by using a service like that offered by Blogger or WordPress.com seems a very sensible starting point. Even so, the business is like building a house in that you only really what you are knowing after you have done the deed and made all the mistakes. That is particularly true when you go down the self-administered blog route. For starters, it’s so easy to pick the wrong domain name or hosting provider. Selecting your blogging software is the next step but that may not be so tricky; WordPress does a reasonable job and there’s always Movable Type, Expression Engine, Drupal (yes, really) or Habari.

That mention of blogging software brings me to something that I encountered recently: commenting functionality. I am coming around to the idea that this is probably something that needs to be considered up front because of the nature of blogging. After all, anyone that reads The Blog Herald regularly should be familiar with the idea of blogging conversations and that means that the technology to make it happen should be easy for visitors to use and easy for bloggers to administer. However, the two can collide. For one thing, there are a myriad of choices available to the blogger and the blight of comment spam is ever pervasive and growing.

When it comes to comment spam, it is best to realise that there are two sources of responses to a blog post: visitor comments or trackbacks (pingbacks?) from other blogs. I am of the opinion that the latter is probably the channel where most of the detritus travels and various anti-spam solutionss are on offer to curb its spread. Names from the WordPress world like Akismet, Spam Karma, Simple Trackback Validation and Bad Behaviour come to mind. The former can also be used, particularly when the unscrupulous make use of low cost labour in low cost countries, and that’s when the thorny questions of user registration and CAPTCHA’s arise. There is something to be said for not going to extremes with these and just stick with less onerous rules and filtering on the server side.

I must admit to having staggering into forcing visitors to register prior to adding a comment and then making them log in thereafter. I think that it’s for security reasons but WordPress creates a password and then sends it to the person who is registering rather than displaying on a web page. That can create another problem: what happens if the email fails to arrive? In the last week, this has happened with a visitor to my hillwalking blog and there could be a number of reasons for the non-arrival of the relevant email. One is ironic: being an automated email, it is getting stuck in the spam filters of the recipient’s mailbox and so never gets to them. It could also be a bug with WordPress itself (I have raised a ticket and am awaiting what Automattic might have to say to it) or a consequence of some setting made by a hosting provider. All of that makes it hard to track down the cause of the issue but it kicks off other thoughts as to its resolution. One is to remove the needed for registration and logging in in the first place but there are third party services that may help too. The former has turned out to be the case for this blog and it seems to be performing well enough so it is an acceptable option.

When it comes to using third party comment handling systems, what needs to be considered is how well they work with your blog. For instance, I gave Disqus a quick whirl and soon realised that I needed to update the themes for my WordPress blogs if I was to use it on an ongoing basis. Otherwise, it worked fine but I was left wondering if it would have been better to have brought it in when I started a blog rather than part way through and with comments made using the existing WordPress functionality. There’s also Intense Debate and I am almost certain that there are more like it but I’ll be sticking with what WordPress offers for now. The theme for my hillwalking blog has been modified to allow prospective commenters to get in touch with me if they are having problems. That’s is only an interim approach while I consider what the way forward will be.

Yesterday, this blog got a bumpy ride from its hosting provider, Fasthosts. For several hours, it was down and there have been occasional errors returned since then. I’ll be keeping an eye on this but I hope that things stabilise sooner rather than later. There’s no question of moving things lock, stock and barrel at this time; patience is a very important virtue when it comes to these things…

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 a 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 it can be done. One way is to set up up two instances of WordPress and 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. There’s nothing to stop you having two databases but 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. It’s need of 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 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.