Missed Schedule for Posts in WordPress

As I started queuing the posts for the previous run of “Ready for 2010“-articles, I came across a problem with my WordPress installation. The scheduled articles didn’t show up when they were scheduled, and the only thing shown in the WordPress administration interface were a message about “Missed Schedule”. No shit, sherlock.

The reason behind the message is that the wp-cron.php file didn’t run as it should. WordPress usually tries to run this every now and then by inserting a reference to the file through the web site. Apparently this behavior was borked on my blog. I have a perfectly working cron implementation on my server, so instead of relying on WordPress to do some kind of magic to insert a reference to the file and kick off the processing with a web request, I added a reference to wp-cron.php in my usual crontab.

I have no idea how often wp-cron really should be run, but decided that a five minute resolution was enough for my use. The crontab entry is included here:

*/5 * * * * cd <directory of blog> && php wp-cron.php

This runs the cron script from the proper directory, and seems to work fine.

Ready for 2010: Upgrade Critical Software

You might remember than WordPress installation you did a couple of years ago and that you’ve been ignoring the “upgrade now” message for almost as long. This “Ready for 2010” message is sponsored by the “Get Your Software Up To Date” foundation.

Before starting down this road, it could be a good idea making sure your backups work. :-)

Yes. You should do these things all year around, but at least this should be a perfect occasion to take the time to check out that old server you installed just to test stuff at home, the server where you’re hosting your private blog, your mail server, etc. We geeks have some sort of weird ability to contract a couple of servers in strange places, forgetting them – but still using them for something on a daily basis.

Update and Upgrade Your Distribution

Spend a couple of hours getting the distribution up to date. For Linux-based servers this usually involves using the package systems update manager, such as apt-get or aptitude on debian or Ubuntu-based servers, up2date on Red Hat, the SUSE update manager etc. On Windows-based servers you’ll be running the update manager, getting all the recent fixes and patches into the core library of tools.

If you’re feeling a bit adventurous you should also consider upgrading your distribution to a newer version if one is available. This will make newer versions of the software you’re running available, get new features into your applications and other Good Things. It might however break a few existing features, such as the layout of certain configuration files, new default values for some settings and other, small stuff. Be sure to set aside a couple of hours for this, so don’t do this just as you’re leaving the country for a couple of months.

Find – and Upgrade – Installed Web Applications

It’s very important to keep Web applications you’ve installed, such as WordPress, up to date. As their nature makes them available through the internet, they’re often a preferred vector for automatic attacks against your server. As soon as a remote exploit has been found, you’ll start noticing attempts to break your server in your web server’s access logs. Usually the attacks require some sort of mitigating factor that requires a particular configuration, but there’s always someone who get in trouble because of just that factor. That might be you!

WordPress (and several other web applications) also contain an automagical update mode, where you can update the software simply by clicking a link in the admin interface. Be sure to spend half an hour getting the automagical update to work where it’s available, and do it now!

Upgrade Embedded Software

Our lives are filled with devices that run any sort of embedded software. Your mobile phone, your digital camera, your wireless router, your TV, your media player, your game consoles, your network attached storage disk (NAS), etc.

Check out the manufacturer’s website for the different devices (or if you’re a nerd like .. well, me, you might have exchanged the firmware with alternative firmwares) and check if there are any updates available. Several devices are also able to update themselves, so be sure to just log in to the device (and discover that you don’t remember the password you set a couple of years ago) and check if you can just click a button to make everything go Happy Happy Joy Joy.

You might also have several applications installed on your mobile phone – check for updates and any critical fixes. You do not want your mobile phone to leak private details out onto the world wide web or through Bluetooth.

Any other issues one should be sure to cover when doing this? Leave a comment below!

Read all the articles in the Ready for 2010-series

Making WPtouch and WP Super Cache Play Together

I installed a plugin for WordPress on the blog yesterday after getting a tip from Morten Røvik about WPtouch. This is a plugin which provides a custom theme for all your visitors that are using mobile devices, such as the iphone and the blackberry line of products.

The problem is that I’m already running WP Super Cache, a caching plugin that writes all the pages wordpress renders to static HTML files, and this conflicts with plugins that want to change the theme of the page on the fly. After a bit of searching (the WPtouch page mentions WP Cache, the plugin that WP Super Cache builds on) I decided to see if WP Super Cache supports the same exceptions based on user agent that WP Cache does, and lo and behold: WP Super Cache has a configuration setting just for this!

  1. Log in to WordPress
  2. Select “WP Super Cache” under “Settings”
  3. Select “Mobile device support. Plugin will enter “Half-On” mode.” in the settings list
  4. Save settings
  5. Delete the contents of the WP Super Cache by clicking “Delete Cache” in the WP Super Cache settings page (IMPORTANT if you’re going to test if things are working!).

The “Half-On” mode means that WP Super Cache caches the files with a small block of PHP code at the beginning instead of the pure HTML files, so that it can check the user agent of the client before deciding which files to return to the user. This is a performance hit (although much smaller than leaving things uncached), so if you suddenly end up with a very, very large amount of hits in a short time, switch the plugin back to full mode.

First Impression of the WordPress 2.7 Wireframes

I’ve done a few posts about WordPress Usability Issues before (and the original wordpress usability post..), documenting my experiences with starting to use WordPress from scratch. I still manage to publish loads of posts without tags and categories, so I’ve been eager to find out if there is anything in the new version of WordPress that will solve this issue for me.

Then a couple of days ago an article appeared on wordpress.org containing a collection of wireframes for how the layout in WordPress 2.7 is currently planned. Sadly enough, it seems to place the tags and categories part of the layout to a location which is even harder to notice: Below the items in the sidebar at the right. I just discovered that I have a “Shortcuts” and “Related” menu items there, so I’m quite sure that this will be a place that’ll leave me missing the tags and categories even more often than today.

If the placement is set in stone, I’d strongly suggest adding some kind of visual hint to the Save/Publish buttons that indicate that tags and categories are missing; at least if you’ve enabled an option in the settings part of wordpress. It seems as the boxes are draggable in the wireframes, but for fresh users, this will still be confusing.

I guess most people at least want to add a category for their posts, but the wordpress guys probably have a lot of usage statistics on this from wordpress.com. It’d be very interesting to see any change in the usage of tags and categories between the different layouts, and the number of edits that simply add tags and categories within the first 24 hours after a post has been published.

(and yey! I remembered tags/categories on this one.)

Followup on WordPress Usability Issues

I’ve now spent a fair amount of time with WordPress since I ported my blog over to it from Serendipity. My first experiences were collected in my post titled WordPress Usability Issues, and I’ll further extend on this here.

  • I’ve gotten used to having the “Save”-button on the right side, but this comes from having to learn the location by hand. I still move to the bottom of the page from time to time, but I’m not lost like I were earlier.
  • The location of the “Save”-button has however trigged another problem: since I now move my focus to the right of the page when I’m done writing my post, 9 of 10 times I fail to give my posts any tags or assign any categories to it. This is done beneath the text of the post, but since I no longer move vertically to progress from the post field (my eyes now move horizontally to the save/publish button instead), I never think about adding those. Guess I’ll have to learn that too, instead of following the flow of the application.
  • “Preview this Post” does not save the post before showing the preview. That means I’ll have to press Save, then “Preview this Post”, even though “Preview this post” is placed all by itself and seem to function independent of the other buttons.
  • Not a usability-issue, but probably a simple bug: some times my posts does not allow for comments, and I’ll have to enable them manually by going to the details of the post. I’m pretty sure that I’m not turning them off by accident, as the option is buried even further down from the tags and categories that I’m already having trouble finding without thinking explicitly about it.

WordPress Usability Issues

After moving from s9y to WordPress, I encountered a few usability issues that I’d like to highlight. While WordPress has a very neat color scheme, large letters and in general does quite a good job of keeping everyone happy, there were a few issues that I stumbled across.

  • The “Save” button is only available at the right side of the post. When entering text in a post, the Save/Publish buttons are placed just to the right of the text field where you write your post. This is fine if I only were to save my post and be done with it, but usually I go through several sets of plugins, tags, categories etc. for the post. After doing this, my eyes and focus are on the bottom of the post column, and I have to searching for how I’m going to get my post posted. This still happens after writing several posts in wordpress.

    How about having just a save and publish button that replicates the function in the rightmost column on the bottom too?

  • After logging into the admin interface, the “Right now!” header with “write a page” and “write a post” is in a reddish (dark orange) background. Red should indicate errors, not “start here, do this!” as the current meaning is. I also wrote a post as a page once, as my eyes just read “write a post” for the first button. I’ll admit that that was me, but as I’ve learnt over the years, if I’m having trouble doing stuff, others will have too. “They’ll figure it out” means they never will.

    How about changing the color of the bar, and instead making the “Write a new post” link to a button all by itself?

    The “Write a Page” button could instead be moved beneath the other button to signify lesser importance. (just noticed that in the “create a new post” page, the bold button is to the right, the opposite of the first login page. Inconsistency is never good.)

  • I registered for an account at WordPress.com to receive my Akismet API key. After entering my details, I got a page with really large text telling me what my username and password was. If I were sitting at a computer lab or at work, people three rows behind me could probably see both my password and my username. I know my password, that’s why I’m writing it two times when registering (.. and then it only shows as ****** as usual…).

    Remove the password from the display page, and we nerds won’t be scared.

    (Am I the only one who finds it a bit akward to see their own password in clear text?)

  • When setting up the text on the right side of this blog, I used a simple “Text” widget from the regular wordpress repository. Works great, but it also have a few usability quirks. I entered my text, and clicked “Change”, and went happily along with my usual business. But the text never changed. Turns out there’s a “save” button further down (which was not visible when the Text widget was expanded). Unless you also press save, the text is actually not changed (even though pressing “Change” indicates that it should be changed).

    You already have a “cancel” link in the upper right corner, but that should probably be placed where “remove” is placed now. “Change” and “Cancel” has opposite meanings but work together, so they should be placed close to each other. Now you have two functions (store the post, don’t store the post) which are shown diagonally across from each other, in completely different context.

    Make the “Change” button actually change the text, and if needed, add an undo mode instead.

  • The last issue is an issue I had with the WordPress.org website. Yet again they use red buttons to indicate “download this!” links. While they do stand out neatly, a friend of mine had trouble actually finding the download link. But it’s right there, in the middle of the page with large red letters. But red isn’t a good color to indicate something we want, and it signifies more “HELP HELP EVERYTHING HAS GONE BANANAS!” than “eeyh! i want to start a new and better blogging life!”.

    My problem was something similiar, but I were lucky enough to already have downloaded WordPress. When trying to install the Highlight Source Pro Plugin for WordPress, I couldn’t for the love of <insert your choice of higher power> find the download link. Guess why? It’s placed as a red button, out to the right over the information about the plugin. I think my mind expected to find passive information there, not a download link. I searched the page visually four or five times trying to find a way to download the plugin, but my mind simply wouldn’t get it. I ended up going to the homepage of the plugin and clicking the “download” link there, which simply triggered the download from wordpress.com.

    Add a download-link in the menu at the top about the plugin and add a download button/link at the bottom together with the tags for the plugin.

    (after reading about the plugin, you usually want to download it or move away, the last option you’ll just use your back button for or scroll to the top to find something else on the same site).

I’m by no means an usability expert, but these were just my small annoyances when trying to use WordPress from scratch. I’ve tried it out a couple of times before, but this is the first time I’ve installed the 2.5 branch.

The Story of Migrating From Serendipity (s9y) to WordPress

As I posted a couple of days ago, I’ve moved the blog from Serendipity to WordPress. The reasen for this was detailed in the other post, as I simply weren’t too happy about how s9y worked in regards to pingbacks/trackbacks and the general quality of the code. Anyways, this is a general post for those who wish to make the same move, and are wondering about how.

After installing WordPress, delete all the existing posts in the database and reset the AUTO_INCREMENT value (needed if you want to keep your old links working). If you do not do this, your ID values may be skewed by 2 or more. Download and install the Serendipity importer for WordPress. After installing it you’ll have a new option under “Manage” -> Import that enables you to import your posts from s9y. Do the import, and check that your posts got the same IDs as they had under s9y.

Then you’ll have to do some fiddling with the .htaccess file, so that mod_rewrite knows about your old URL scheme. These rules worked for my installation of s9y, your milage may vary (and please, if you find any problems, post a comment or a pingback to your fixes). Add the following lines together with the existing WordPress rules:

RewriteRule ^archives/([0-9]+)\-[a-zA-Z\-_]+.html$ /index.php?p=$1 [L]
RewriteRule ^feeds/index.rss2$ /feed/ [L,R=301]
RewriteRule ^feeds/index.rss1$ /feed/ [L,R=301]
RewriteRule ^feeds/index.rss$ /feed/ [L,R=301]

This should also keep most of the RSS-readers out there happy, but you might want to change the feed addresses if you have several different formats of the RSS available. This does not include the category/ etc. links from s9y, but those will be reindexed at a later time by any search engine anyways. The most important thing is to ensure that people who are looking for your old posts still are able to find them.