Technology Tales

Work locally, update remotely

Here’s a trick that might have its uses: using a local WordPress instance to update your online blog (yes, there are plenty of applications that promise to edit your online blog but these need file permissions to the likes of xmlrpc.php to be opened up). Along with the right database access credentials and the ability to log in remotely, adding the following two lines to wp-config.php does the trick:

define('WP_SITEURL', 'http://localhost/blog');

define('WP_HOME', 'http://localhost/blog');

These two constants override what is in the database and allow to update the online database from your own PC using WordPress running on a local web server (Apache or otherwise). One thing to remember here is that both online and offline directory structures are similar. For example, if your online WordPress files are in blog in the root of the online web server file system (typically htdocs for Linux), then they need to be contained in the same directory in the root of the offline server too. Otherwise, things could get confusing and perhaps messy. Another thing to consider is that you are modifying your online blog so the usual rules about care and attention apply, particularly with respect to using the same version of WordPress both locally and remotely. This is especially a concern if you, like me, run development versions of WordPress to see if there are any upheavals ahead of us like the overhaul that is coming in with WordPress 2.7.

An alternative use of this same trick is to keep a local copy of your online database in case of any problems while using a local WordPress instance to work with it. I used to have to edit the database backup directly (on my main Ubuntu system), first with GEdit but then using a sed command like the following:

sed -e s/www\.onlinewebsite\.com/localhost/g backup.sql > backup_l.sql

The -e switch uses regular expression substitution that follows it to edit the input with the output being directed to a new file. It’s slicker than the interactive GEdit route but has been made redundant by defining constants for a local WordPress installation as described above.

Remove Revisions 2.2

There is already a post on here devoted to version 1.0 of this plugin and that very much tells you what it does. The new version will work with the forthcoming WordPress 2.7 (itself a release that’s had a development cycle with such upheavals that it would make you want to watch from the relative safety of the sidelines) and has been made to be a little more user friendly in its actions; in fact, it behaves more like any other plugin now.

Download Remove Revisions 2.2

Dean’s FCKEditor for WordPress plugin, a wish list

I must admit that I have a liking for FCKEditor over and above what comes as standard with WordPress and the FCKEditor for WordPress plugin has been addressing my preference for a while now. However, its most recent release dates from last April and its integration with WordPress 2.6.x has been leaving a lot to be desired. In that vein, I have decided to collect a few of them here:

1. Automatic saves: the idea behind this feature of WordPress is that you aren’t hitting the save button that often at all. In fact, given that hitting save creates a revision and an extra record in your database, it really isn’t something that you should be doing very often anyway. Unless, you don’t mind a bloated database, it’s probably best to avoid that habit of saving every few minutes like I do when using Word.
2. Word count: this doesn’t update without saving a revision while it should update periodically in a manner akin to the automatic saves.
3. Insertion of media such as images: this is just broken and it takes away the possibility of having galleries and captions without manual work.

What I have above are the major inconsistencies but there have always been annoyances like the adding unwanted   entities allover the place, probably a habit of FCKEditor itself anyway. Nevertheless, it’s the integration work that really shows the lack of attention. Maybe, it’s time to move Dean Lee’s labour of love over to a fully community-maintained course of development. I know that it’s hard to see your “baby” leave you and take flight but I am inclined that it’s the best way forward when you considered how rapidly WordPress has been changing over the last year. Some moves have been made towards this but they really do need to go further.

A radical new look on the way for WordPress’ administration area

One thing that you can never say about Automattic is that it stands still for very long. That may generate adverse commentary from some but it’s bad to leave things stagnate too. In fact, resting on laurels also generates flak so you can’t please everyone all the time.

Earlier on this year, the WordPress administration screens went through something of an overall for version 2.5. In hindsight, it wasn’t terribly dramatic, but the prospect had me checking out what was happening with the development version and contributing to the project in my own small way. Now, it seems that a bigger upheaval is in prospect with wireframes and what not being brought into play on the design side.

The first change that anyone will notice is that the navigation has moved from the top to the side and that some things have been moved around and renamed. Another thing that you’ll see soon enough is that there is a QuickPress section added to the dashboard screen for those really quick and short postings. Sticking with the subject of content creation, alterations to post and page editing screens and the link creation screen are obvious too. What really comes to mind here is the level of customisation on offer so you can make yourself feel right at home: some of the screen furniture can be moved about and you can remove what you feel is nothing but useless clutter. Content generates comments, so the addition of keyboard shortcuts for comment moderation should be a boon for those with very active readers.

Some functionality currently added by plugins is getting incorporated in the main application. An example is automatic upgrades of WordPress itself. In the development version, it installs the latest nightly build but I am certain that it can be made to point to the latest stable release. That makes it more convenient for keeping a backseat eye on things rather than getting stuck into the hurly-burly of checking on what’s in Subversion.

There are some pieces that remain incompletely functional at present, such as the Inbox and Media added to this post pieces, but I have seen nothing that used to work to be broken. So, while the development version of WordPress is more of a work in progress than I have seen for a while, it will do what you need it to do. You always need to be cautious and I’d advise you to keep away until it’s ready for the big time until you have the knowledge to put things back should the undesirable befall your blog. I had an automatic WordPress update kick in maintenance mode without turning it off again. Nothing happened to the database, so a manual re-installation was all that was required to restore order. Otherwise, the development installation remains relatively stable though there are display problems in IE6 that do not afflict either Firefox, Opera or even IE8 Beta2.

All in all, these changes will make the next major WordPress a very big one and I have little doubt that the new administration interface will make for many comments. I must admit that I wasn’t too taken with it when I first glimpsed it in the crazyhorse branch but it now seems to be growing on me. The biggest change on the aesthetic front is that there’s a lot less whitespace about which may or may not float your boat. In any event, you can always change the colours like I have to make things more amenable. Even so, I reckon that WordPress 2.7 will be a major step forward when it comes and I think that I could like it. Saying that, I reckon that the release date is a good while away yet and the fact that 2.6.2 is being readied for release is telling in itself. Leaving plenty of time to remove any roughness is never a bad thing and especially so when you see the changes that are being made. In the meantime, I am certain that most people can wait.

Oops!

It’s amazing what a misplaced wp-config.php file can cause. Today, one ended up travelling in here while I was setting up a test blog for seeing how WordPress 2.7 was coming along. The result was that content more appropriate to my hillwalking blog turned up on web browsers and in feeds instead of what should have made its appearance. I’ll have to be more careful in future…

P.S. I realise that I have been quiet over the last few weeks but that’s down to my being away in Scotland hiking on some of its islands and catching up with some friends in Edinburgh. I have some ideas for new posts so they should manifest themselves sooner rather than later.

Another way to look through WordPress code

At times in the past, I have complained about there not being sufficient documentation of the actual code used in WordPress itself. True, there is the venerable Codex but that can be incomplete and any extra help is always useful. Peter Westwood (a.k.a westi) has generated documentation from the code itself and put it up on the web for all to peruse. While we are on the subject of information on the more advanced aspects of WordPress, blogs by Mark Jaquith and Andrew Ozz are also worth a look. As the cliché goes, every little helps…

An alternative use for Woopra

Google Analytics is all very fine with its once a day reporting cycle but the availability of real time data dose have its advantages. WordPress.com’s Stats plugin goes some way to serving the need but Woopra trumps it in every way apart from a possible overkill in the amount of information that it makes available. The software may be in the beta phase and it does crash from time to time but its usefulness remains more than apparent.

One of its uses is seeing if there are people visiting your website at a time when you might be thinking of making a change like upgrading WordPress. Timing such activities to avoid a clash is a win-win situation: a better experience from your visitors and more reliable updates for you. After all, it’s very easy to make a poor impression and an unreliable site will do that faster than anything else so it’s paramount that your visitors do not get on the receiving end of updates, even if they are all for the better.

WordPress plugin for removing post revisions from database

WordPress 2.6 added post revisions as a new feature that is turned on by default. In an earlier post, I described how you could control this by editing wp-config.php and there are a number of plugins that purport to provide the same level of control through the administration screens. Even so, I decided to look at things from the housekeeping side of things and create my own plugin for clearing the database of revisions at one swoop. Currently, it takes out all revisions but I am thinking of adding the facility for selecting which revision to keep and which to delete. It goes without saying that you should back up your database first in case anything might go wrong.

Download Remove Revisions 1.0

Technical considerations regarding the discussion aspect of blogging

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 know what you are doing 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 who 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 reckon that the latter is probably the channel where most of the detritus travels and various anti-spam solutions 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 sticking 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 gets 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 I 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 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 were 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 is only an interim approach while I consider what the way forward will be.

New version of my Countrytones plugin

Now that WordPress 2.6 is out, it is time to introduce a new version of Countrytones to the public. A few CSS tweaks have been needed to the original version after the changes that have been made to the administration interface for 2.6. Those screens still look largely the same with this release as they did before but for the styling of things like the bubble that alerts you to the availability of plugin upgrades, among other things.

Download Countrytones 1.0.1