Technology Tales

Redirecting a WordPress site to its home page when its loop finds no posts

Since I created a bespoke theme for this site, I have been tweaking things as I go. The basis came from the WordPress Theme Developer Handbook, which gave me a simpler starting point shorn of all sorts of complexity that is encountered with other themes. Naturally, this means that there are little rough edges that need tidying over time.

One of these is dealing with errors on the site like when content is not found. This could be a wrong address or a search query that finds no matching posts. When that happens, there is a redirection to the home page using some simple JavaScript within the loop fallback code enclosed within script start and end tags (including the whole code triggers the action from this post so it cannot be shown here):

location.href="[blog home page ]";

The bloginfo function can be used with the url keyword to find the home page so this does not get hard coded. For now, this works so long as JavaScript is enabled but a more robust approach may come in time. It is not possible to do a PHP redirect because of the nature of HTTP: when headers have been sent, it is not possible to do server redirects. At this stage, things become client side so using JavaScript is one way to go instead.

Turning off the full height editor option in WordPress 4.0

Though I keep a little eye on WordPress development, it is no way near as rigorous as when I submitted a patch that got me a mention on the contributor list of a main WordPress release. That may explain how the full editor setting, which is turned on by default passed by on me without my taking much in the way of notice of it.

WordPress has become so mature now that I almost do not expect major revisions like the overhauls received by the administration back-end in 2008. The second interface was got so right that it still is with us and there were concerns in my mind at the time as to how usable it would be. Sometimes, those initial suspicions can come to nothing.

However, WordPress 4.0 brought a major change to the editor and I unfortunately am not sure that it is successful. A full height editor sounds a good idea in principle but I found some rough edges to its present implementation that leave me wondering if any UX person got to reviewing it. The first reason is that scrolling becomes odd with the editor’s toolbar becoming fixed when you scroll down far enough on an editor screen. The sidebar scrolling then is out of sync with the editor box, which creates a very odd sensation. Having keyboard shortcuts like CTRL+HOME and CTRL+END not working as they should only convinced me that the new arrangement was not for me and I wanted to turn it off.

A search with Google turned up nothing of note so I took to the WordPress.org forum to see if I could get any joy. That revealed that I should have thought of looking in the screen options dropdown box for an option called “Expand the editor to match the window height” so I could clear that tickbox. Because of the appearance of a Visual Editor control on there, I looked on the user profile screen and found nothing so the logic of how things are set up is sub-optimal.  Maybe, the latter option needs to be a screen option now too. Thankfully, the window height editor option only needs setting once for both posts and pages so you are covered for all eventualities at once.

With a distraction-free editing option, I am not sure why someone went for the full height editor too. If WordPress wanted to stick with this, it does need more refinement so it behaves more conventionally. Personally, I would not build a website with that kind of ill-synchronised scrolling effect so it is something needs work as does the location of the Visual Editor setting. It could be that both settings need to be at the user level and not with one being above that level while another is at it. Until I got the actual solution, I was faced with using distraction-free mode all the time and also installed the WP Editor plugin too. That remains due to its code highlighting even if dropping into code view always triggers the need to create a new revision. Despite that, all is better in the end.

Changing to CKEditor from FCKEditor for WordPress Content Editing

The post editor that I have been using on my WordPress-powered outdoors blog has not been TinyMCE but FCKEditor. My use of that editor has meant that WordPress’ autosave and word counting features have not been available to me but that was my choice, as strange as it will sound to some. However, there have been times when I have missed the autosaving functionality and lost work. Since FCKEditor has been replaced by CKEditor, there are plugins available for adding that editor to WordPress’ administration interface. Recently, I got to replacing the old FCKEditor plugin with a newer CKEditor one and that has gained me post or page autosaving. The more cosmetic word counting feature is not active until a draft is manually saved but I can live with that. Other than that, the interface remains familiar with all (X)HTML tags on show in the source code view without any being hidden away from view like in WordPress’ implementation of TinyMCE. That isn’t to see that WordPress is doing something wrong but just that there are alternative way of doing things that are equally valid. After all, why would there be choices if there only ever was one right way to do anything?

Like any WordPress plugins, those replacing the default content editor in WordPress can be vulnerable to changes in the publishing platform and there is one of those in the pipeline for 3.2: a minimalist post/page editor that is billed as being non-distracting. That planned new feature is drawing inspiration from the likes of QuietWrite, where you can write content and transfer it over to WordPress or leave it where it was written. Even with bigger changes like this, my experience never has been that design decisions made for new WordPress releases have restricted to any great extent how I use the thing. That’s not to say that my usage hasn’t changed over time but I have felt that any decisions were mine to make and not all made for me. In that light, I can foresee CKEditor continuing to work on WordPress 3.2 but I’ll be doing some testing ahead of time to be sure that is the case.

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 in order to incorporate tagging.

Dashboard Editor no longer fully functional

The move to JQuery meant that some of the things for which its 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.

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. 2.3 is another major release so I have been doing some preparation.  In fact, WordPress have 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. I had the same reservations about 2.2 with its inclusion of sidebar widgets but 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 of 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, a world 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 a very important 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. I must have a look at getting around this but 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

The standard WordPress post editor got broken on this blog so my mind turned to replacing and 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…

More useful WordPress plug-ins

Apart from a widget that puts a login form onto a blog sidebar, I am not really on the lookout for WordPress plug-ins but here are two that came to my attention recently. I have found them to be useful; maybe you will too.

The first is WordPress Admin Themer. This allows you to store wp-admin.css in your blog’s theme folder, out of harm’s way from future upgrade cycles. A neater way of otherwise storing your customisations of admin pages -- I keep changing the logout destination to the front page of my blogs -- would be a bonus but the style plug-in is a good step forward.

One use to which I was going to put WordPress Admin Themer was to hide some elements of the WordPress dashboard page but I happened accross another plug-in that does just this kind of thing: Dashboard Editor. Activating this gets you an extra admin page where you can select the components that you want to see using the tick (check) boxes. You can even take things further by having your very own dashboard instead of what WordPress offers or by activating widgets for using with your dashboard. It’s all good stuff and I have got rid of extraneous pieces such as Planet News and the getting started section (I have using WordPress long enough that I should know my way around by now…).

TechnologyTales.com has moved server…

The last week on WordPress.com has featured decisions that some may question, to say the least. For instance, the death of Feed Stats was something that I saw as a retrograde step. Next, I saw a slight change to the appearance of my blog that led me to take full control of the situation; a previous discussion with WordPress.com staff about changing a theme to the way that I wanted it to be got me nowhere so I wasn’t about to try again… I might miss having advance notice of where WordPress goes next but I am not sure that I want to be a guinea pig either.

So, you now find this hosted by Streamline.net and, apart from a lengthy hiatus (at least, it felt like forever thanks to recurring thoughts of PageRank loss; yes, I know that sounds silly…) spent awaiting FTP access to be sorted out, the set up ran smoothly enough; I think that my request for transfer from a Windows server to a Linux one might have been the cause of the delay. Setting up a MySQL database was a breeze and it’s part of the package too. In fact, the Pro package that I am using is £31.99 ex VAT per annum, not bad at all, and, teething problems out of the way, it’ll be interesting to see how things will fare from now on.

Having a self-hosted WordPress installation is nothing new to me since I do it for my hillwalking blog and everything came together very quickly this time around. knowing what plug-ins add real value was a definite help: Bad Behaviour and Ultimate GA headed the list but a Spam Karma 2 is another option. Feedburner integration is another potential item on the configuration list. I have stuck with the Andreas09 theme but am unsure as to how far I will take customising it; it’s not a high priority right now. In fact, I may find another three-column layout that takes my eye now that I am not limited to the offerings available from WordPress.com.

The posts from the old blog have arrived over here and that seems to have worked fine first time around thanks the WordPress’ import/export functionality. I still have to get the images over but there’ll be time for that yet. Another thing on the to do list is to transfer over the links and set up any text and RSS widgets that have been a feature of the previous rendition of the blog. That means linking to wp-links-opml.php on the old blog using the import links functionality. There is no other link export function and you can only import into a single category; a link import/export plug-in that retains the link category information would be a bonus.

While I wonder if I have made a rod for my own back with my having two self-hosted WordPress blogs, it does feel good to have more control and it’ll be interesting where where this journey goes next.