The latest major release of our favorite blogging platform – WordPress 3.0 – has brought quite a few new features to the table. Among them, the custom navigation menus and the post thumbnails (featured image), the latter being available since version 2.9 came out. This started a whole new trend between theme developers, most of them rushing to announce WordPress 3.0 ready themes.
In all this rush, some of the themes released suffered from one big problem: backward compatibility. Why is that important and how can we give some backward compatibility to our WordPress 3.0 ready themes?

Importance of backward compatibility

While I feel that generally offering some sort of backward compatibility is just a common sense policy, in this case it’s more than that. Let me explain why.
Not everyone uses the latest WordPress release, and that is for various reasons:

• Failed to update, or waiting to make sure it’s “stable”;
• Doesn’t really get the importance of an up to date software;
• Certain plugins they use are not yet 3.0/3.0.1 compatible.

This doesn’t mean they don’t want to try and use your beautiful 3.0 ready WordPress theme, or that they shouldn’t. But you see, the biggest trick resides right here, in this terminology: “3.0 ready”. The actual meaning of this is that the theme is compatible with the 3.0 version, not that it requires 3.0 or higher to function properly, and this leads a lot of people into a trap that will cause their blogs and websites to break.
So, the common sense thing to do would be to take the time and apply certain checks and fallback solutions to our themes. Lets see how we can do that.

Adding WordPress 3.0 features with fallback support

Both of the above mentioned features – custom menus and post thumbnails – are based on a WordPress function added once 2.9 was released: add theme support();

Adding post thumbnails support

In order to add post thumbnail support to your theme, you’d write this in your functions.php file:
Simple adding this will cause any WordPress installation prior to 2.9 to break, as the add_theme_support() function was not part of the WordPress core back then. The fix? As easy as this:

Adding custom menus support

In order to also add support for the custom menus feature, you’d normally write this:
In this case, we obviously need to check for core support of both functions: add_theme_support() and register_nav_menus(). Let see how we can do that, also including in this check the post thumbnails:
In case you wonder why I chose to add support for menus only after checking if register_nav_menus() is defined, it’s simply because there’s no point in adding support for a feature that you won’t be able to use. Remember, add_theme_support() was added in 2.9, while register_nav_menus() became available only in 3.0.
But how about adding compatibility in the front-end of your theme?
When using post thumbnails, never call them without checking if the function exists first:
For the custom menus, the thing is just a tad trickier, but simple as well. I’m usually using a function that I wrote to specifically check for custom menus support, and even though the wp_nav_menu() function provides a fallback solution, defaulted to wp_page_menu(), this fallback will only activate for 3.0 installations without any menus created and allocated to the reserved space. The fallback won’t set off if you’re using a version prior to 3.0.
Due to my preference of wp_list_pages() over wp_page_menu() – for more customization options – the following function will apply a compatibility fallback to wp_list_pages:
Now, in the front end. instead of calling your menu with wp_nav_menu() you’ll now use my_nav_menu() to display a backward compatible version.

Conclusions

Caught in the rush of doing something nice and new, like a child discovering a shiny new toy, we can miss out some of the most basic problems. Most of them are really easy to solve, like the above mentioned and it would be common sense to make use of them.
And remember: if ( function_exists(function_name) ) is your geeky B.F.F.