TOPIC: WORDPRESS
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...
Trying out WordPress 2.3 RC1
The final release of the next version of WordPress is due out on Monday and because there are sure to be security fixes included, I have been giving the release candidate a go on my offline blogs. Since 2.3 is another major release, I have been doing some preparation. In fact, the WordPress project has a blog entry dedicated to such things for this release. Thankfully, I think that my hillwalking blog should emerge unscathed by this upgrade; I still need to have a go with an offline version of this blog.
The special feature in the new release is tagging, and it is good to see that it has had no impact on legacy set-ups. Though I had the same reservations about 2.2 with its inclusion of sidebar widgets, the backward compatibility was enough to see me through without any hiccups. Tagging is not something that I see myself using, with categories fulfilling much the same type of role; I am unconvinced by the idea of tag clouds, the type of thing that it powers. However, there are some useful extras here, and the filtering of posts by edit status is one of these. Having pending review as a publishing status sounds like a tweak that I might use to allow myself a cooling-off period before I publish a post for all the world to see. Revisiting something with a fresher pair of eyes might stop typographical howlers from emerging into public view...
Update: Another 2.3 feature discovered! I have picked up on multiple category widgets by virtue of the fact that category styling disappeared with the upgrade of the offline version of this blog to 2.3 RC1. Adding "-1" to the relevant CSS class definitions soon sorted things out. It does support the idea of testing before implementation, even if no other unexpected changes were spotted. I still am not sure why anyone would have multiple category listings, though.
Twelve months of WordPress
It was on this date several months ago that I moved my hillwalking blog into the world of WordPress. It's a self-hosted WordPress instance and has been for all that time. Because of the move, I was taken into the world of MySQL, one that intrudes still to this day. Most of the time for the migration was spent setting up a theme to fit in with the rest of the website, of which it forms an essential part. The matter of importing all the old posts took up time too, especially when it came to fixing glitches with the XML import. Still, it was all done within a weekend, and my website hasn't looked back since. More people now have a reason to visit, and the blog may even have surpassed the photo gallery as the site's main attraction. I kept up the old blog for a while but have dispensed with that by now; I was keeping both blogs synchronised and that became a tiring manoeuvre. Another upshot of the whole experience is that I have become more aware of the UK outdoor scene and learnt a thing or two too. It might even have encouraged me to go from day tripping to multi-day backpacking, a real-world change that is well removed from the world of technology.
Another side to hardening WordPress
A little while back, I took to using the wonders of .htaccess directives to make my WordPress deployments more secure. It does work but has the disadvantage that desktop blog editors like Windows Live Writer, Word 2007 and w.bloggar cannot be used to update your blog. Though I must have a look at getting around this, I am sticking with using WordPress itself to do the editing for now (Dean Lee's port of FckEditor for WordPress is working out very well, spurious codes notwithstanding).
FCKEditor for WordPress
Because the standard WordPress post editor got broken on this blog, my mind turned to replacing it, especially when I spied plugins for adding FCKEditor to the thing. Dean Lee's is the one that I am using, and it seems to work well so far too. As this is FCKEditor, there are more editing options than those offered by the WordPress standard and that's even with the advanced options made visible with the Alt+V/Alt+Shift+V keyboard shortcuts; the former is for IE and the latter for Firefox. We'll see how it goes from here...
Now, I know why my site layout changed on WordPress.com…
One of the caveats of using themes authored by others is that you don't quite know how things are set up. The reason that this has come home to roost for me is that I was trying to change the title of a widget last night and was wondering why it wasn't filtering through to the blog pages. When I went for a spot of googling, as you do, it dawned on me what might be going on. The plug-ins used by the Andreas09 theme are defined in its functions.php file, and I was being scuppered by a naughty piece of hard-coding in there. If it was using the standard widget from widgets.php in the wp-includes directory, then everything would have worked as expected. A quick spot of code porting resolved the issue and all was well again.
What this has to do with WordPress.com is that they seem to have encountered the same problem and fixed it using what could be viewed as a more ham-fisted approach: deleting the widget functions from functions.php for Andreas09. This would have meant that the default widgets shone through, thus explaining the changes that I had seen and why my nice categories listing now grabbed less attention. I reckon that my more surgical approach is the better one: at least, I still have my categories looking how I want them...
Tidying dynamic URL’s
A few years back, I came across a very nice article discussing how you would make a dynamic URL more palatable to a search engine, and I made good use of its content for my online photo gallery. The premise was that URL's that look like that below are no help to search engines indexing a website. Though this is received wisdom in some quarters, it doesn't seem to have done much to stall the rise of WordPress as a blogging platform.
http://www.mywebsite.com/serversidescript.php?id=394
That said, WordPress does offer a friendlier URL display option too, which you can see in use on this blog; they look a little like the example URL that you see below, and the approach is equally valid for both Perl and PHP. Since I have been using the same approach for the Perl scripts powering my online phone gallery, now want to apply the same thinking to a gallery written in PHP:
http://www.mywebsite.com/serversidescript.pl/id/394
The way that both expressions work is that a web server will chop pieces from a URL until it reaches a physical file. For a query URL, the extra information after the question mark is retained in its QUERY_STRING variable, while extraneous directory path information is passed in the variable PATH_INFO. For both Perl and PHP, these are extracted from the entries in an array; for Perl, this array is called is $ENV and $_SERVER is the PHP equivalent. Thus, $ENV{QUERY_STRING} and $_SERVER{'QUERY_STRING'} traps what comes after the ? while $ENV{PATH_INFO} and $_SERVER{'PATH_INFO'} picks up the extra information following the file name (/id/394/ in the example). From there on, the usual rules apply regarding cleaning of any input but changing from one to another should be too arduous.
Does Automattic have a penchant for strange decisions?
WordPress.com has retired its Feed Stats feature. While there might have been problems with it for some, I do find it a strange decision not to spend some time on it. After all, given the existence of Google Reader and its kind, I wouldn't be surprised to learn that more people read blogs with RSS readers than by going to the sites themselves. In fact, I peruse blogs more often with Google Reader than by visiting the websites themselves. It's enough to make me wonder if I could use Feedburner with this blog.
To follow on from this, I am beginning to wonder if that Automattic, the people behind WordPress.com, seems to be a quirky company that makes decisions that are questioned by its customers. After all, they did remove the post preview functionality from blog post editing screens, and that has generated numerous comments. On self-hosted WordPress, you can add a plug-in to correct this, but that option is not open to WordPress.com users. The answer that I got to a theme change request earlier this year adds to the impression, as does seeing a company having staff apparently work from home all over the world.
Automattic seems an unconventional beast alright; could that lead to their undoing? Though it is king of the hill with blogging world for now, there is nothing to say that will last forever.