I’ve read quite a few articles on theme support for the new Menu functionality introduced in WordPress 3.0. However, these have all been theoretical rather than practical. I wanted a real life, working example, including support for users on older versions of WordPress. In the end, I wrote it myself.

Scope

I’m not going to delve into all the different options you can use when adding support for menus. There are enough articles out there that cover this in depth: I highly recommend you read Justin Tadlock’s excellent Goodbye, headaches. Hello, menus!.

Instead, I’m going to focus on the things missing from most articles, such as adding support for users on older versions and including support for static pages in the fallback menu. If you write themes that are used by other people, you need to include these.

Functions.php

First, this is the code to add to the functions.php file. I’ll explain it below.

// add menu support and fallback menu if menu doesn't exist
add_action('init', 'sjc_register_menu');
function sjc_register_menu() {
	if (function_exists('register_nav_menu')) {
		register_nav_menu('sjc-main-menu', __('Main Menu'));
	}
}
function sjc_default_menu() {
	echo '<ul>';
	if ('page' != get_option('show_on_front')) {
		echo '<li><a href="'. get_option('home') . '/">Home</a></li>';
	}
	wp_list_pages('title_li=');
	echo '</ul>';
}

Check If register_nav_menu Exists Before Calling It

On line 2, we add an action to call a function (from line 3 to 7). The purpose of this function is to register the menu via the register_nav_menu function.

Most tutorials out there focus on how to use register_nav_menu (line 5). Fair enough, it’s new and we’re all interested in how to use it. However, I want you to notice line 4:

if (function_exists('register_nav_menu'))


Surprisingly, most tutorials leave this out. No problem if your theme will only ever run on WordPress 3.0. However, if you have users on an older version of WordPress, your theme will crash and burn if you leave this out. Visitors will be greeted with the following error:

Fatal error: Call to undefined function register_nav_menu() ...

Not cool.

The Fall Back Menu Catering For Static Pages

Lines 8 to 15 contain a function that provides a fall back menu that is used if the user has not added a menu via the new interface. The code for the fall back menu is pretty standard stuff. I’m sure someone will point out that I could use wp_nav_menu, but we’ll call the fall back menu directly for older versions of WordPress (see below) and wp_nav_menu only exists in 3.0 and above.

It’s worth noting the IF statement on line 10, wrapping the Home link. This says to only create the Home link IF the site is NOT using a static home page. If it is, then the Home link will not be created. Why? Without this, the Home page option will appear twice in the menu (if users have a static home page).

There are other ways of dealing with this, but my way seems simplest to me.

Header.php

Moving on to header.php, we add the following code where we want the menu to appear:

<div id="nav">
	<?php
	if (function_exists('wp_nav_menu')) {
		wp_nav_menu(array('theme_location' => 'sjc-main-menu', 'fallback_cb' => 'sjc_default_menu'));
	}
	else {
		sjc_default_menu();
	}
	?>
</div>

Call The Fallback Menu Function Directly For Pre WordPress 3.0

The menu is called via the wp_nav_menu function (see line 4 above). This function is what the other articles all focus on. Once again, fair enough, this is a new function that can give us access to the cool new menus. But note the IF statement in line 3:

if (function_exists('wp_nav_menu'))

Leave this out and anyone using your theme on versions of WordPress older than 3.0 is going to be serving the following up to their visitors:

Fatal error: Call to undefined function wp_nav_menu()

Checking that the wp_nav_menu exists is obviously essential, unless you are certain that your theme will only ever run on WordPress 3.0 or above.

But what do we do if wp_nav_menu doesn’t exist (ie the user is on an older version of WordPress)? Should we serve up the original code that we originally used to create the menu pre WordPress 3.0?

Well, we’ve already moved our old code into the fall back menu function. There’s nothing to stop us from calling the fall back menu function directly (line 7) assuming it doesn’t use wp_nav_menu. Simple! And good reuse of code.

Final Thoughts

WordPress Theme developers, what have you done to ensure menu support for your users on older versions of WordPress? Is your approach different from mine? Can you see a better way of doing this?

I’d love to hear from you in the comments.

While catching up on some old podcasts, specifically Episode 82 of WordPress Weekly, I came across a discussion about WordPress beta testing. The discussion centers around the problem of bugs not being caught during beta testing because there just aren’t enough beta testers.

To me, the solution seems straightforward – but that may be because I worked in the software industry for 10 years and have experience in software release management, so I’ll take the long path and set the scene properly.

That makes it a long post, but stick with it – you need to read it all to fully understand my reasoning. First we need to consider the following question:

Should You Upgrade WordPress Immediately After A Release?

Short answer: Sometimes, but not always.

Over the last couple of years, there have been repeated calls for WordPress users to update their blogs immediately after a new version has been released. At times, the call to upgrade has almost become a frenzy.

I’ve taken this with a grain of salt and held to my belief that upgrading immediately isn’t always the correct choice. Sure, upgrade immediately if the release fixes a critical security issue – but most of the time it’s better to wait and see whether:

• there are any major bugs in the new version
• your theme works with the new version
• all of the plugins you’re using work with the new version

I’ve developed this ‘hold back’ approach while working in the software industry over the last 15 years or so – I’d contend that it’s ‘best practice’. Upgrading to a new version without testing the new version in your environment (including server, theme and plugins) is the sign of immature processes.

Some may argue that this approach is overkill for a simple blog, but there are many sites out there running WordPress that are a little more complicated.

Even simple blogs are often not that simple, especially as so many are now monetized. Ask yourself, will I lose money if WordPress doesn’t work after an upgrade? If the answer is yes, you should probably be testing new versions before upgrading.

You’re probably asking how does this relate to beta testing? Well, in a couple of ways:

1. Bugs In New Releases Mean Less People Will Upgrade

Let’s leave aside the fact that I don’t personally subscribe to the ‘upgrade immediately’ advice and assume that it’s a good thing (which it would be in the ideal world).

Bugs in new releases undermine this advice. After the recent problem with scheduled posts, introduced in the WordPress 2.9 release, there have been people questioning whether upgrading immediately was a good thing.

If beta testing was improved and caught more of these problems, then there’d be less of the ‘hold back’ people out there and more people would follow the advice, in theory making WordPress more secure. There’d be:

• less people (such as Robert Scoble) complaining about WordPress security.
• less need for Matt to write public responses outlining why people should upgrade.
• less complaints about bugs and the loss of functionality.

There’ll always be bugs in software and there’ll always be people who complain – but more comprehensive beta testing would lead to less bugs, leading to less unhappy users, leading to more sites being updated immediately, leading to less hacking, leading to even less unhappy users.

Better beta testing begets better security.

2. Balance Between Upgrade Speed Vs Security

Alternatively, if we don’t leave aside my beliefs, if we can moderate the unthinking update immediately advice, then we’re provided with a tremendous opportunity:

On a case by case basis, we can decide if an upgrade is in the “update immediately” category or in the “can wait for critical bugs to be fixed” category.

My solution, way down the bottom of this post, is going to propose delays to upgrades that are not for critical security issues, so that user experience less critical bugs. But more on that later.

The Problem: A Lack Of Beta Testers

The problem, which has been mentioned in various places including the podcast, is that although WordPress has a beta testing phase, there aren’t enough end users testing it to catch all the critical bugs. The software appears to runs fine during beta testing, but bugs rise to the surface when the release is rolled out to everyone.

First, some facts:

• Software is always going to have bugs
• Beta testing will never find all the bugs

There will always be some bugs that are only triggered when the software is run in an obscure environment or is used in a way that’s slightly different from how most people use it.

So it’s not about eliminating bugs, just about reducing the number of critical bugs that get through beta testing. The only way to do this is to get more people, using the software in different ways, on different server environments, to test the software.

How do we get more people to test the software? The answer’s coming soon (honest).

Software Release Management Anecdotes

First, let me say that I worked in the software industry (for a library management system vendor) for 10 years. For quite a bit of that time, I was the person who authorised the release of software to clients and/or agents.

I could bore you with software release management anecdotes going back to 1994. Luckily for you, I came to my senses and edited them out! I’ll just say that making sure that major releases were properly tested and free of bugs was extremely important for the following reasons:

• Loss of reputation, harming future sales: Upset users are significant in the relatively small library software marketplace.
• Direct financial loss: yes, it cost a significant amount of money to burn 5000 CDs back in 1994 (and then post them out).
• Lots of additional work: printing letters, packaging CDs and supporting users who were upgrading, etc.

Obviously, WordPress operates in a very different environment from library software industry of old and many of these points are less of an issue:

If WordPress lose one user, or even ten thousand users, because of loss of reputation, they don’t actually lose any money in sales (actually there is no they!). If they have to release an upgrade, there are no costs for CDs and postage, people just download it. There’s no surge in the amount of support they need to provide, as support is crowd sourced.

Does that mean WordPress can afford to ignore this issue?

I say No – they should care about their reputation (and their users), even if there isn’t the same financial emphasis that there is in the closed source software industry. In fact, they should look to the closed source software industry and learn from it. Solutions to this very problem have been worked on and refined for decades.

In my particular case, we had several major incidents that led to us refining our testing and release processes. We ended up moving to a process that involved three phases of testing – I’ll outline these and relate them to WordPress in the next section.

The Three Phases Of Testing

1. Developer Testing

I’m sure this is done comprehensively by the WordPress developers. Ultimately, we employed a couple of full time testers, which Automattic could possibly consider funding. They may already have some testers (besides the Chief BBQ Taste Tester), although it’s not obvious from their About page.

But the problem isn’t here and full time testers would only have limited impact, so let’s keep moving.

2. Beta Testing

This is being done, but the problem is that not enough end users are involved. WordPress could look at ways to entice more users to join the beta testing program, but many of the methods that the closed source software industry use, such as offering discounts to beta testers, won’t work in the open source world.

One idea could be to build in a "do you want to upgrade to the beta version (for the greater good)" message into the automatic update function. When a beta version is released, everyone gets this message.

It would have to be very clear that it was a beta version and that there may be some problems and it would need Yes, No and Never Ask Me Again options, but it could work. Not many would choose to upgrade, but 1% of 3 million is 30,000, which is a lot more than the number of current beta testers.

Once again, though, I don’t think the answer is here. It would be a significant improvement, but could cause a lot of negative publicity: there’d be too many people who’d choose it accidentally, then blame WordPress for upgrading them to beta software.

3. Live User Testing / Staged Release

So we come to the solution at last (I told you we would) and it’s not in the beta testing phase.

Instead, the answer lies in a staged roll-out to users: limiting new releases to a relatively small number of people until it’s proven that there are no major problems.

If any major problems are found, a decision can be made on whether they are serious enough to fix immediately, before making the software available to the rest of the users. Even if it’s decided not to fix the problems, users can be made aware of issues that may affect them before they upgrade. Even that small improvement would make a real difference to users.

The staged release approach been used for decades. I was using it 15 years ago. Google uses it today: they roll-out new features in Google Analytics or Google Adsense slowly.

How Would A Staged Release Work?

A staged roll-out of WordPress would work something like this:

1. Once the beta testing phase is complete, the automatic upgrade notice would be sent out to say 100,000 people.
2. There would then be a period of say one week, where the feedback would be monitored and any critical bugs identified and investigated.
3. At the end of the period:
   • if no critical bugs have been identified, then the automatic upgrade would appear to everyone else.
   • If critical issues have been identified, a decision would be made on whether to proceed with the release or delay it until the problem is fixed.

It goes without saying that urgent security releases would bypass this.

Now I’m not talking about physically denying the software to anyone, just manipulating who gets it through the automatic upgrade process. Anyone would still be able to visit wordpress.org and download the lastest version.

How Would A Staged Release Be Achieved Technically?

I’m not the best person to answer that, but I’d imagine it wouldn’t be too hard to do. It would require the automatic upgrade function to be modified: instead of WordPress installations asking "is there a new version", they’d ask "is there a new version and can I have it".

On the server side, it would check the download count and, when it reached the threshold, start saying no. You could make it complicated (checking whether it’s been downloaded from this IP address before), but it would be best to keep it simple.

There exists the potential that some users may be unhappy about either getting the new version before it’s been through live testing, or having to wait until after. The key here is that users are not getting the beta version, they’re getting the real version that’s been through beta testing, just as they would now. It’s just that it’s being rolled out slowly to further protect users.

This would need to be well communicated.

Of course, it could be made it opt-in. The first 100,000 users could be shown the message: "WordPress 3.1 is available! Update or Wait". If they choose Wait, it won’t ask them again until the live release testing is complete. The rest of the users would be shown: "WordPress 3.1 is available, but we recommend you wait for moment. Wait or Upgrade anyway".

Final Thoughts

So the solution to the beta testing problem isn’t actually within the actual beta testing phase. It’s just to roll out the upgrades slowly, giving time for critical bugs to be caught before they affect too many people. This would protect the majority of users from any serious bugs.

Personally, I have doubts that this would ever be adopted: I think it would be seen as too complicated. But really, it wouldn’t be that hard to do and would make life better for the vast majority.

What do you think? Am I crazy? Do you disagree with me? Do closed source practices have no place in the open source world? Do you have a better idea? Let me know!

Go to Posts -> Edit in the WordPress Admin area and you’ll see a list of all the posts you have. There is a dropdown list called View all categories, which allows you to select a single category to view posts from. But…

What if you want to view posts from more than one category, or better yet, want to exclude posts from certain categories? Can’t do it right? Well not through the WordPress interface, but you can do it through URL parameters.

Finding Out Your Category Numbers

To make this work, you’ll need to know the category numbers for your categories. You can find these through either of the following two methods:

1. Go to Posts -> Category screen and hold your mouse over the category in question. In your browser’s status bar you will see a URL which ends in ID=xx (xx is the number of the category).

OR

2. While still in Posts -> Edit, select the category you want in the dropdown list and click Filter. You’ll be taken to a page showing only posts from that category. In the browser’s address bar you’ll see that the URL contains cat=xx (xx is the number of the category).

The first method is quicker if you want to look up multiple category numbers (you may want to write them down). The second method is better if you’re just after one or two category numbers – you’ll need to do this step anyway.

First Step

By default, the Posts -> Edit screen has a URL that ends in wp-admin/edit.php with no parameters, eg:

http://www.scratch99.com/wp-admin/edit.php

Rather than typing all the parameters, it makes sense to start with a URL that includes them.

If you haven’t already, select one of the categories you want to include / exclude in the dropdown list and click Filter. You’ll be taken to a page showing only posts from that category, but you will now have a URL that looks like this:

http://www.scratch99.com/wp-admin/edit.php?s&mode=list&action=-1&m=0&cat=92&action2=-1

We’re going to be changing the cat=xx part of the URL.

Displaying Posts From More Than One Category

Perhaps I want to display posts from more than one category – in my case, I may want to see all the posts from my WordPress and Web Development categories, but not from the rest of my categories (too much noise).

Easy. Simply edit the URL and change the cat=xx to cat=xx,xx (where xx is the category numbers that you want). In my case, I change the URL to the following (note the cat=4,65):

http://www.scratch99.com/wp-admin/edit.php?s&mode=list&action=-1&m=0&cat=4,65&action2=-1

Want posts from three categories? That’s right:

cat=xx,xx,xx

You’ve got it now!

Excluding Posts From Certain Categories

It’s also possible to exclude posts from certain categories from appearing in the Posts -> Edit screen.

Why would I want to exclude posts from certain categories? Actually, that’s how I started looking into this issue. I haven’t been posting much recently and, as a result, my weekly automatic lifestream digest posts pretty much filled up the screen:

I was having trouble seeing my real posts!

Thankfully it’s easy to exclude the category that these posts are in. Simply edit the URL and change the cat=xx to cat=-xx (where xx is the category number you want). In my case, I change the URL to the following (note the minus sign, eg: cat=-92):

http://www.scratch99.com/wp-admin/edit.php?s&mode=list&action=-1&m=0&cat=-92&action2=-1

The result:

Want to exclude posts from more than one category? That’s right:

cat=-xx,-xx,-xx

Final Thoughts

That’s all – it’s a fairly long post for a fairly simple tip. It’s probably not something that will be needed often, but in some circumstances it’s very useful to have greater control over which posts appear on the Edit Posts screen.

Happy New Year to all! A year ago, after looking at my Google Analytics stats for the year, I wrote a post reviewing 2008. I figure I may as well do it again for 2009 and also take the opportunity to explain the direction of this site.

The Top Ten Visited Posts In 2009

According to Google Analytics, the top ten visited posts in 2009 (with the home page and plugin pages stripped out) were:

1. Creating A JavaScript Array Dynamically Via PHP (2008)
2. Blogger – How To Add Adsense Inside Single Posts Only (2009)
3. How To Display Ads Only To Search Visitors (2008)
4. Poll – Which WordPress Theme Framework To Use? (2009)
5. WordPress – Simple CSS Text Boxes In Posts (2007)
6. WordPress – Most Viewed – Sidebar Widget (2007)
7. WordPress – Rounded Text Boxes in Posts (2007)
8. Custom Page Templates – Calling An External CSS File (2009)
9. Setting Cookies In WordPress – Trap For Beginners (2008)
10. How To Avoid Adsense Smart Pricing On Blogs (2008)

While I feel some of those posts deserve to be there, there are some that I don’t feel are particularly deserving.

Also, as you can see, there’s only 3 posts written in 2009 in that list. The others were written in 2008 (4 posts) or 2007 (3 posts). I guess that’s not too surprising as a lot of my traffic comes from search engines and old posts are just as likely to rank well as new ones.

It also doesn’t help that I only wrote 20 posts in 2009 (not counting automatic lifestream posts), but more on that later.

My Top 5 Posts From 2009

Last year, I included a list of the 10 posts that I thought were my best in 2008. If I were to do this again for 2009, I’d only go with 5 articles that I was particularly happy with. There are others which are okay, but don’t particularly stand out for me.

So, here are my top 5 posts written in 2009:

1. Subscribe To Comments & Protected Wp-admin Folder
2. Blogger – How To Add Adsense Inside Single Posts Only
3. Show Adsense To Search Visitors Only – On Blogger
4. XAMMPLite Virtual Directory And WordPress Permalinks
5. Sharepoint As A CMS – Microsoft Tech.Ed Australia 2009

Other Interesting Stats From Google Analytics

Google Analytics also provided some interesting statistics for 2009 on this site.

Traffic

The site had significantly more traffic in 2009 than in did in 2008. There were 75,343 Visits and 113,016 Pageviews in 2009, up from 46,488 Visits and 74,916 Pageviews in 2008.

That said, the first half of 2009 was the best: traffic tailed off slightly in the second half of 2009 (since I disabled my DoFollow plugin).

It will be interesting to see what will happen in 2010. Unlike last year, I’m not particularly concerned about whether traffic will increase in 2010.

I now consider this site as an area for me to write about my WordPress plugins and my Greasemonkey scripts – I no longer have any grand ambitions about creating a thriving blog.

Browser Breakdown

The vast majority of visitors were using Firefox. That isn’t surprising given the nature of this blog, as it appeals to web developers and bloggers, groups given to using FireFox. The full breakdown is as follows:

1. Firefox – 67.62%
2. Internet Explorer – 17.65%
3. Chrome – 6.24%
4. Safari – 4.75%
5. Opera – 2.30%

Of the Internet Explorer users, 20.66% were using IE6 (about 3.6% of all visitors). Too many! The numbers are roughly the same as last year, but with a slight drop for IE and a 5% increase for Chrome.

Operating systems

The major operating systems used by visitors was virtually the same as last year, being dominated by Windows. The full breakdown is as follows:

1. Windows – 82.92%
2. Macintosh – 12.28%
3. Linux – 4.25%

Top 10 Screen Resolutions

The screen resolution of visitors is always important to web developers. I’ve included the top 10 resolutions below.

1. 1024×768 – 21.23%
2. 1280×800 – 19.57%
3. 1280×1024 – 15.07%
4. 1440×900 – 11.88%
5. 1680×1050 – 11.06%
6. 1920×1200 – 5.21%
7. 1152×864 – 2.36%
8. 800×600 – 1.76%
9. 1366×768 – 1.50%
10. 1280×768 – 1.46%

Interesting things to note are:

• 800×600 has actually moved up one place, despite me proclaiming last year that it had almost dropped off the list at last. It’s hanging in there grimly.
• 1024×768 is still the most popular, but it’s 5% lead in to 2009 has been reduced to just 2% in 2009. Will it hang on in 2010?

Top 10 Countries

1. US (by far)
2. India
3. UK (London was the top city)
4. Canada
5. Australia
6. Philippines (Hi RT)
7. Germany
8. Indonesia
9. France
10. Netherlands

Not much change here.

Report Card For 2009

I didn’t meet many of my goals for 2009, as I changed my objectives during the course of the year. Here’s a brief rundown on how I did for each of my 2009 goals.

Post More Often

I published 52 posts in 2007, followed by 41 posts in 2008. One of my 2009 goals was to post more often. I failed big time, only publishing 20 posts in 2009. As I said last year:

It’s not for lack of ideas – I have lots of half written posts that I just need some time to finish off. I tend to spend more time working on my projects than writing about what I’m learning.

That’s still true, but I’m more comfortable with it now. I’ll probably post more this year, but won’t sweat it if I don’t.

Post On Topic

Last year I wrote:

It’s noticeable in my top 10 posts above that many are my Make Money Online posts. I’d like to keep posting on that topic as I learn more about it, but I want to post more often on my Web Development efforts (and WordPress of course).

I didn’t post often in 2009, but I was probably more aligned with my core topics than in 2008.

Update My Current Wordpress Plugins

I had planned to overhaul my my existing WordPress plugins and move them into the official WordPress plugin directory. Didn’t happen. The new ones are going into the official directory, but the old ones haven’t been touched. Still on my list for 2010.

Release Some New WordPress Plugins

Last year I wrote:

I started off by writing that I’d like to release another 4 WordPress plugins this year (I already have 4 half finished plugins that I want to finish off). However, thinking of my workload, I changed it first to 3 plugins, then to 2 plugins! So we’ll have to see how many I can actually get out.

Spot on! I released 2 new plugins in 2009. I’m sure more will follow in 2010.

Release A WordPress Theme

I had been thinking that I’d release a WordPress theme in 2009. Didn’t happen. This is now far down on my priority list. I may release one in future if I create my own theme framework for my sites, but it’s not likely anytime soon.

Release Some Greasemonkey Scripts

I released a couple of Greasemonkey scripts in 2009 and plan to release more in future. Greasemonkey rocks! I write little scripts for it all the time, although I haven’t released many of them (yet).

Changing Goals For 2010

I don’t really have many goals for this site in 2010. As I mentioned above, I’d like to update my old WordPress plugins and move them into the official directory, release some new WordPress plugins and release some new Greasemonkey scripts, but that’s about it.

I have other projects, which I won’t mention here, that are more of a focus for me in 2010. This is just going to become the ‘portal’ to the software I release, with the occasional post thrown in.

Final Thoughts

Well that’s a quick look at the year that was and the year that will be here at More Than Scratch The Surface. I hope all your endeavours for 2010 are successful! If you have any big plans for your blog, feel free to share in the comments.

After listening to recent episodes of the WordPress Weekly podcast (episodes 67 and 68), I was surprised to learn that in future versions of WordPress, the Delete link will be replaced with Trash.

So what does Trash mean? After looking it up in the dictionary, I find it means the same thing as rubbish (or garbage)!

Ahh, I see. Items will not actually be deleted in future, they’ll be sent to the ‘Trash can’. The WordPress team don’t want to use the term Delete, as it implies that the item will be deleted and can’t be recovered. This may cause confusion amongst users.

The WordPress team’s thinking is commendable and I’m glad that over the last year or so they’ve put a lot of effort into usability. I actually think Jane Wells’ appointment is the best thing to happen to WordPress in a long time.

The only problem is that in this case, they are replacing a term that is used universally in the English speaking world, with a term that is North American centric: Trash is not commonly used in Australia or the UK.

This may cause confusion in it’s own right. It probably won’t, because we’ve all seen American movies and know what it means – I didn’t really need to look up trash in the dictionary!

Actually I’m not upset about it. I just felt like making a point.

That’s probably because at one time in the past, I was the International Product manager for a library software company and had to ensure it was localised properly for Australia, UK and the US. It was little things like this that we needed to be careful about – we didn’t want to alienate our customers.

Of course they were paying customers, which means you have to cater for them a little more than for users of open source software, who are getting a great product for free. But it would be better to find a term that is used by everyone.

For my part, I’d be happy with keeping the term Delete. I’ve been using Windows for 15 years or so and I’m quite comfortable with the action of Delete actually sending things to the Recycle Bin. But I’m sure I’ll adjust if I have to take out the Trash in future.

This is perhaps my most overdue post ever – a review of Vladimir Prelovac’s book, WordPress Plugin Development (Beginner’s Guide) [note: that's an affiliate link].

I’ve had other posts that I’ve promised to write that I’ve had trouble finding time to deliver. In this case however, I actually accepted a review copy of the book, so I really should have written about it before now.

In my defence, we had a new addition to the family and we’ve been undergoing major changes at work, so I’ve been spread pretty thin.

Also, because I live in Australia, Packt Publishing could only send me the eBook version. In many ways, I prefer ebooks – no more leaving books behind when you change country! In this case however, having a physical book in front of me would have meant I’d have been more likely to pick it up.

Anyway, enough with the excuses and on to the review!

Book Details

• Title: WordPress Plugin Development: Beginner’s Guide
• Author: Vladimir Prelovac
• Publisher: Packt Publishing
• Paperback: 278 pages [191mm x 235mm]
• Release date: February 2009
• ISBN: 1847193595
• ISBN(13): 978-1-847193-59-9

Who The Book Is For

I’ll just quote the book on this one:

This book is for programmers working with WordPress, who want to develop custom plugins and to hack the code base. You need to be familiar with the basics of WordPress and PHP programming and believe that code is poetry; this book will handle the rest.

That seems to be WordPress Plugin developers, WordPress Theme developers, those providing web development services based on WordPress and maybe some power users wanting to push the boundaries a little.

If you don’t have any experience with PHP (or jQuery for that matter), you might just get by, but I’d advise you to at least read up on the basics before you jump into this book.

What The Book Covers

The book covers most of what you’ll need to get started writing WordPress plugins – the right way. The topics covered include (in no particular order):

• The basics of the WordPress plugin architecture and the API used to hook into the WordPress functionality and manipulate it.
• Interacting with the WordPress database
• The use of custom fields to store data.
• Creating widgets (though not using the new WordPress 2.8 widget api)
• How to use both jQuery and AJAX within a WordPress plugin
• Working with third party APIs such as Flickr
• WordPress Plugin security
• User roles and permissions
• Localising WordPress plugins (ie to support other languages)
• Managing the plugin options.
• Maintaining WordPress plugins (including adding them to the WordPress Plugin repository)

In short it covers a LOT. As I said, everything you need to know to write WordPress plugins.

The Positive

I’ll be honest – I haven’t read the book from cover to cover. I have read the first 3 chapters in their entirety and have skimmed the rest of the book, digging into some areas a little more. However, I’ve seen enough to get a good feel for the book and to know that I like what’s in it.

The book’s tagline is "Learn by doing: less theory, more results". It teaches by example, rather than pushing a whole lot of theory at you.

The book walks step by step through the development of 6 real life WordPress plugins, covering the various issues that arise for each plugin and how to resolve them. Using real life examples makes it much easier to understand the concepts that Vladimir is teaching.

In my opinion, Vladimir has done a great job of choosing plugins which allow him to demonstrate all the things he needs to, without having to contrive situations just to demonstrate something. He weaves all the complex information together, giving you a little bit at time but building on it and reinforcing it later.

The source code is available for download, allowing you to try it out yourself without typing it – although if you’re a beginner I’d recommend that you do the hard way and type it. You’re much more likely to remember things that way. The source code is also a great starting point for you to start experimenting on your own.

I learnt quite a few things from the book – mostly things I’d heard of before, but hadn’t gotten around to learning about – but the book laid them out in a simple straight forward way making it easy for me to quickly understand.

Perhaps the best feature of the book is that Vladimir follows ‘best practice’ methods for creating WordPress plugins. Are you not quite sure about any of the following:

• using nonces to make plugins more secure (and other security issues)
• using wp_enqueue_script to load scripts rather than just calling them directly
• localizing your WordPress plugin so that it can easily be translated into other languages
• using shortcodes to call plugin functionality directly from the post body

This book will make it clear just how to use these features and so much more. Whatever Vladimir does in the book, he uses best practice methods.

This is great both for new plugin authors (who’ll learn to do things the right way) and for existing plugin authors (such as myself) who need a refresher on the best way to do things in WordPress. There are plenty of us out there who have written plugins that work, but which could be written better.

I’ve been planning to go back and update my plugins to take this into account. When I get around to doing so, I’ll be consulting this book again for a good overview of what I need to do (and why).

The Negative

There are very few negatives with the book. The content, by and large, is excellent.

I did notice a few spelling errors. That’s always possible with large books, but ideally the editor should have picked them up.

The only other thing I noticed is that the order (within each section) takes a little getting used to. Vladimir pushes through the example, then explains what happened afterwards. For me this approach is a little counter-intuitive. However, you get used to it and isn’t a big problem. In fact some even think that this is a strong point:

Each mini-tutorial (”Time for action”) section is followed by a “What just happened?” section that let’s you take a breather to understand what you just did and why you did it. I believe that this pause for explanation is the key reason why it is so easy to learn from this book.

Other reviews have mentioned that the book is a little fast paced. Perhaps, but it didn’t worry me and of course you can work through the examples at your own pace.

Question Marks

I do have some concerns about this book – not to do with the content, which is excellent, but to do with the very concept of a book on WordPress plugin development.

Out Of Date Content

I didn’t put this in the Negatives section, but I easily could have. WordPress is being updated all the time at an astonishing rate. Can the book keep up with this? The widget api was been overhauled as part of WordPress 2.8, meaning that section of the book is out of date already.

Vladimir will be on top of such changes and I’m sure there will be revised editions of the book, but the nature of a book on WordPress is that it will be behind from almost the minute it’s published.

Free Alternative Information

All of the information contained in this book is available free of charge elsewhere online.

Sure it may not be available in one place and ordered in such a useful way, but there are volumes written on WordPress plugin development. I’ve always found that a combination of the WordPress Codex, Google and the source code have been enough to tell me everything I need to know. I probably wouldn’t have gone out and spent money on this book because I’m comfortable with finding information through these alternative sources.

That’s not to say that such a book doesn’t have a place: It would be very useful for someone starting out on WordPress development who wants all the information up front without having to go out and search for it. The way I see it, this book is not a necessity, but is a luxury that will save you time.

Size Of Target Audience

Lets face it – when you round up all the WordPress plugin authors, there’s not too many of us and many won’t buy such a book.

There are more WordPress theme developers out there and I suspect that they will be a big target audience for this book – many of them are looking to extend their WordPress skills and to build more plugin-like functionality into their themes. However, there are other books coming that may appeal to theme developers more, as they are less plugin specific.

Perhaps the key to the success of this book is the rapid growth in the use of WordPress by web development agencies to provide solutions to clients. Is it enough to sustain several books on the topic (particularly in light of the other concerns above)? Only time will tell.

Conclusion

WordPress Plugin Development: Beginner’s Guide is a very good book. It covers everything you need know about writing WordPress plugins and it teaches by example rather than by lecturing.

That said there are question marks about the book – most notably how quickly it will go out of date due to the pace of development of the WordPress core.

For me, it won’t replace the WordPress Codex and Google as my prime source of information, but it would be very handy to have on a shelf to turn to from time to time. It would also be an excellent starting point for those just getting started with WordPress related development.

Earlier today I received an email from an irate commentator, accusing me of spamming him and threatening to report me. He was receiving emails from my blog, via the Subscribe To Comments plugin, but he thought couldn’t unsubscribe. The cause: my wp-admin folder is password protected.

As it happens, the commentator had successfully blocked notifications from my site. However, he thought he hadn’t because he received a username / password prompt when he clicked the Unsubscribe link in the email.

Cause – Subscribe To Comments Calling Wp-admin.css

I wasn’t sure why this was happening. The URL used for the Unsubscribe link didn’t appear to be going to the wp-admin folder and I couldn’t see any reason why it would need to. I rolled my sleeves up and jumped into the Subscribe To Comments code. I quickly found the reason on line 951 (in version 2.1.2):

@import url( <?php echo get_settings('siteurl'); ?>/wp-admin/wp-admin.css );

The plugin is calling a CSS file from the wp-admin folder, which invokes the password prompt. As the user doesn’t know the password, they will probably click Cancel and the CSS file will not be served.

This CSS file is only used to style the Unsubscribe page. It does not affect the functionality of the Unsubscribe / Block function. It will continue to run and will unsubscribe the user. The only negative outcome will be it won’t look quite as nice. Well, not the only negative outcome:

The user will be confused as hell because of the password prompt.

Solution – Excluding Wp-admin.css From Protection

I had to resolve this issue. The easiest solution would have been to just hack the code of the Subscribe To Comments plugin and remove the call to the CSS file. However, if the plugin is ever updated, then it would have overwritten my hack and we’d be back where we started.

The sensible alternative seemed to be to exclude the wp-admin.css file from the password protection. A CSS file is highly unlikely to be used in any attack on my site.

There didn’t seem to be anyway to exclude the file via CPanel, but I knew there’d be a way to do it by editing.htaccess. I’m no .htaccess expert, so I did a search on the topic, finding the answer in Brett Batie’s Password Protect All but One File post.

That post tells you how to exclude a file in general terms, so here are the instructions for excluding wp-admin.css file.

Go to the wp-admin folder (make sure it is the wp-admin folder) on your server and edit the .htaccess file. It will probably look something like:

AuthType Basic
AuthName "Authorised Only"
require valid-user
AuthUserFile "<path-to-site-root>/wp-admin/passwd"

Leaving the first 4 lines exactly the same, add the following 4 lines directly after them:

<Files "wp-admin.css">
  Allow from all
  Satisfy any
</Files>

That’s telling Apache to allow access to wp-admin.css. The final .htaccess (in the wp-admin folder), should look something like:

AuthType Basic
AuthName "Authorised Only"
require valid-user
AuthUserFile "<path-to-site-root>/wp-admin/passwd"

<Files "wp-admin.css">
  Allow from all
  Satisfy any
</Files>

Problem solved. My visitors can now unsubscribe again (though why would they want to!). I still have the hardened security provided by password protecting the wp-admin folder. I haven’t had to hack Subscribe To Comments, which would cause problems when the plugin is upgraded.

Final Thoughts

Mark Jaquith, if you read this, many thanks for a great plugin - but could you consider copying the wp-admin.css file into the plugin folder and calling it from there? I’m fine with you making this post redundant!

Note: Not long after writing this post, I discovered that the best way to load external CSS files is by using the wp_enqueue_style function. Similarly, the best way to load JavaScript files is by using the wp_enqueue_script function. The method outlined below is not necessary – although it may still be useful for other things to be added to the head section.

Custom page templates are a powerful feature of WordPress that can be used to make pages (not posts) do something different from normal. You can make them do pretty much anything. Obviously, this can greatly increase the flexibility of your site.

Amongst other things, I’ve used custom page templates to create a basic photo wall and a dynamic listing of jobs in China.

However, because of the way most WordPress themes are created, calling an external CSS file from a custom page template is not straightforward. Here, I explain the problem, look at the options and explain how to use ‘plugin functionality’ to overcome the problem.

Creating Custom Page Templates

Much has been written about creating custom page templates, so I won’t cover it in detail here. Briefly, you need to do the following:

1. Create a php file in your theme directory, containing the functionality you want (I normally start with an existing template and modify it).
2. Ensure there is a comment at the top of the file, so WordPress knows it’s a template. For example (and don’t forget to change the name):

   <?php
   /*
   Template Name: My Page
   */
   ?>
   

3. In the Admin panel, edit the page you want to use the custom template with and set the Template field to the template you created.

That’s it in a nutshell. For more detailed instructions, please see:

• WordPress tips and tricks – custom templates by Binary Moon
• How to use custom page template in WordPress themes by Vladimir Prelovac

Calling An External CSS File

There may be times when you want to include something in the head section of the HTML document. The most obvious example is a call to an external CSS file to provide custom styling for the page.

Adding the style information to the main CSS file would add unnecessary weight to every page / post, when it’s only needed on one page. Inline CSS should be avoided where possible. So the best solution is an external CSS file that is called only for that page (ie called by the custom page template).

The Problem With Adding Items To The HTML Head

It sounds simple enough: I just call the CSS file from the custom page template, right? Right in theory, but in practice you can’t easily do this because of the way most WordPress themes are designed.

The external CSS file must be called from the head section of the HTML document. In most WordPress themes, the entire head section is contained in the header.php file. This is normally called from the custom page template using the get_header() function in the following manner:

<?php
/*
Template Name: My Page
*/
?>
<?php get_header(); ?>

This calls header.php, which will probably have a variation on the following:

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html xmlns="http://www.w3.org/1999/xhtml" <?php language_attributes(); ?>>
<head profile="http://gmpg.org/xfn/11">
<meta http-equiv="Content-Type" content="<?php bloginfo('html_type'); ?>; charset=<?php bloginfo('charset'); ?>" />
<title><?php bloginfo('name'); ?> <?php if ( is_single() ) { ?> » Blog Archive <?php } ?> <?php wp_title(); ?></title>
<link rel="stylesheet" href="<?php bloginfo('stylesheet_url'); ?>" type="text/css" media="screen" />
<link rel="shortcut icon" href="<?php bloginfo('stylesheet_directory'); ?>/images/favicon.ico" />
<link rel="pingback" href="<?php bloginfo('pingback_url'); ?>" />
<?php wp_head(); ?>
</head>
<body>
<div id="page">
<div id="header">
	<div id="headerimg">
		<h1><a href="<?php echo get_option('home'); ?>/"><?php bloginfo('name'); ?></a></h1>
		<div class="description"><?php bloginfo('description'); ?></div>
	</div>
</div>
<hr />

If you try to call the CSS file before the get_header() function, for example:

<?php
/*
Template Name: My Page
*/
?>
<link rel="stylesheet" href="<?php bloginfo('stylesheet_directory'); ?>/includes/mypage.css" type="text/css" media="screen" />
<?php get_header(); ?>

then the additional code will appear BEFORE the code in header.php. In the case above, it will appear before the DOCTYPE line, which is obviously no good.

If you try to call the CSS file after the get_header() function, then the additional code will appear after the code in header.php. In the case above, it will appear after <hr />, which is in the body of the HTML document and also no good.

There are several solutions to this problem.

Rejected Solution 1 – Don’t Use Header.php

One possible solution is to copy and paste the code from header.php into the custom template, instead of calling it via get_header(). You can then easily edit the code to add the call to the external file. Great!

The problem is that if you ever change header.php, you’ll have to remember to come back and change the equivalent code in the custom page template. That’s messy (and the chances are you’ll forget).

Rejected Solution 2 – Edit Header.php

Another possible solution is to edit header.php and use a conditional statement to only include the CSS file on the page in question. For example, if we only wanted to use the custom template on the page with an ID of 7830 we could add the following to header.php:

<?php
if ($post->ID == 7830) {
	echo '<link rel="stylesheet" href="'.get_bloginfo('stylesheet_directory').'/includes/mypage.css" type="text/css" media="screen" />';
}
?>

This would only call the external CSS file for the page with the specified ID. Note that the IF condition can be adapted to our needs. If we wanted to call the same external stylesheet for multiple pages, we could check for the existence of a custom field, or perhaps a certain tag, etc. The possibilities are endless.

The problem with this solution is that it’s messy. What if you plan to use multiple custom page templates and want a different stylesheet for each one? Your header.php will be filled with conditionals. It’s far better to find a solution where you can call the external CSS file from the custom page template.

My Solution – Add_action Function With Wp_head Hook

Although I’m starting to play with WordPress themes, my background is in WordPress plugins. If I wanted to call an external CCS file from a plugin, I’d use the add_action function with the wp_head hook. There’s really no difference between plugins and themes when using WordPress functions, so this technique works just as well in a custom page template.

Here’s how to do it:

<?php
function mypage_head() {
	echo '<link rel="stylesheet" type="text/css" href="'.get_bloginfo('stylesheet_directory').'/includes/mypage.css">'."\n";
}
add_action('wp_head', 'mypage_head');
?>
<?php get_header(); ?>

First, we define a simple function called mypage_head that echos the HTML code calling the external stylesheet. That’s all it does. Of course, you could echo anything here, such as a call to a JavaScript file, a meta tag, etc.

Next, we use the add_action function, with the wp_head hook, to call the mypage_head function. This tells WordPress to run our function whenever the wp_head function is called (this is called by your header.php).

Lastly, we call header.php using the get_header function. This calls wp_head and WordPress remembers to the mypage_head function and your code is added.

It’s not messy, because all the code is in the custom page template. You can leave header.php as it is. But it doesn’t require you to remember to change code if you change header.php, because you’re re-using header.php.

Final Thoughts

That’s my solution: to use the add_action fuction to add something to the header. What do you use? I know there are other solutions out there (including plugins), so I’d be interested in hearing what you do.

So far, my WordPress development work has consisted of writing WordPress plugins and occasionally hacking themes. I’ve always said that I wanted to write a WordPress theme from scratch, but never had time to do so. One of my sites is going to need a redesign shortly, so here’s my big opportunity.

However, with the rise of the WordPress theme framework and the limited time available to me, I’ve started thinking that the sensible thing to do is use a theme framework. But which one?

What Is A Theme Framework?

I’m not going to answer this definitively, because it’s too large a topic!

The short answer is that a Wordpress theme framework is a base that can be used to write a WordPress theme on top of. Most of the work is already done for you. There’s generally no need to call WordPress functions. All you need to do is create the style (via CSS) and add any custom functions you might need.

Of course, it’s not really that simple, as many theme frameworks extend WordPress by creating hooks that can be used for advanced customisation and make use of child themes, so you can upgrade the theme framework core without your changes being affected.

What Are The Choices?

There are quite a few WordPress theme frameworks out there, but the most popular ones seem to be:

• Ian Stewart’s Thematic
• Justin Tadlock’s Hybrid
• Alex King’s Carrington
• Ptah Dunbar’s WPFramework

There are also Premium WordPress Theme Frameworks, such as Chris Pearson’s Thesis, but I’m not going to pay for one when there are so many great free options.

It’s worth acknowledging Scott Wallick’s Sandbox which is the granddaddy of the theme framework concept and which influenced many of the theme frameworks listed above.

Tell Me Which Theme Framework You Would Use!

There’s too much choice! I don’t know the difference between these theme frameworks, so I’m not sure which way to go. They all seem good and are created by WordPress developers with great reputations.

I’m leaning toward Thematic or Hybrid at the moment. For some reason, I have the feeling that Carrington is over the top for what I need, but I may be totally off base here. I’m also tempted by the Sandbox (sometimes I have to fight my instinct to do things the hard way!).

I’m rather short on time, so rather than spend days trying and comparing these frameworks, I thought I’d ask you – which framework would you use? If you have an opinion, please take part in the poll:

Final Thoughts

It’s exciting times for theme developers. WordPress theme frameworks can save us a lot of time. It’s just a little confusing to know which one to use. I hope this poll can help show what the community is thinking at the moment.

When I’m working on WordPress related development (ie themes and plugins), I like to run WordPress locally. This is great for trying things out before it goes live and also lets me squeeze in some development time in on the train!

My web server package of choice is XAMMP Lite, the Apache distribution that contains PHP and MySQL. Works great in general, but I had some problems with WordPress permalinks and XAMMP Lite. Here’s the solution.

My XAMMPLite / WordPress Environments

It’s important to note that I keep the XAMMPLite and WordPress environments separate. Rather than copying each WordPress site into the XAMPP Lite structure, I keep it in a separate folder and set up a Virtual Directory pointing to it. This makes it easier to keep track of things.

For example, rather than putting the WordPress installation for the site I’m working on in c:\xampplite\htdocs, I store it in c:\dev\sites\sitename. I then set up a Virtual Directory so that XAMPP Lite’s Apache installation can find the folder and can serve it via http://localhost/sitename.

Now, I’m no Apache expert, but setting up a Virtual Directory was pretty easy: I simply added the following lines to the Apache configuration file (C:\xampplite\apache\conf\httpd.conf), substituting sitename with the appropriate name:

Alias /sitename "C:\dev\sites\sitename"
<Directory "C:\dev\sites\sitename">
    Options Indexes MultiViews
    AllowOverride None
    Order allow,deny
    Allow from all
</Directory>

This gave me a virtual directory that worked, but I couldn’t get the WordPress permalinks to work properly.

The Permalink Problem

What was the problem with the permalinks? For me, all of my posts and pages returned a 404 error. Great!

There’s a workaround: put /index.php/ at the start of the permalink structure (ie /index.php/%postname%/). However, while this works, it means that the local permalink structure will be different from that on the live site.

That’s no good for me. The menu links for my themes are often hardcoded, at least to the extent that they will break if the permalink structure changes. I don’t want to have to recode the theme to run it locally!

At least the root cause of the problem was obvious: XAMMP Lite was ignoring the .htaccess file created by WordPress. I just needed to get XAMMP Lite to respect the WordPress .htaccess file. I knew there had to be a way to do this.

The Solution

It turned out the problem was caused by the code I used to set up the Virtual Directory. As I said, I’m no Apache expert! I found the solution on rudy egenias jr’s site. Instead of the code above, I should have entered the following (in the C:\xampplite\apache\conf\httpd.conf file):

Alias /sitename "C:\dev\sites\sitename"
<Directory "C:\dev\sites\sitename">
    Options Indexes FollowSymLinks Includes ExecCGI
    AllowOverride All
    Order allow,deny
    Allow from all
</Directory>

Note the differences: AllowOverride has changed from None to All. Options has changed from Indexes MultiViews to Indexes FollowSymLinks Includes ExecCGI.

Problem almost solved. There’s one more thing to check to make sure that the WordPress permalinks work: In the httpd.conf file we have to make sure that the following line is uncommented (ie remove the ; before it):

LoadModule rewrite_module modules/mod_rewrite.so

Once that’s done, WordPress Permalinks should work perfectly with XAMMP Lite. Mission accomplished.