January 23, 2009

One of the big strengths of WordPress is that there are thousands of themes available, a significant number of which contain similar solutions to similar problems. So why is it that it was even necessary to add something like wp_page_menu which is, at best, a tame solution to a very simple problem?

There are a lot of themes with really excellent solutions, but once you look under the hood you very often find that the entire solution is built as a one time only function into functions.php, or worse, into the template itself. If you want to take a menu and add a new item to it you need to hard code it, modify the code directly, or hook into the functions that output the pages in the first place. Needless to say you might be better off writing your own, and so many do.

I have long advocated the use of plugins with themes. It is a real shame that WordPress won’t look in the theme folder for plugins, but despite this, I think the ability to disable parts of the theme is a beneficial one.

First of all it is nice to be able to remove menu items that will never be used. Not essential, but nice.

Secondly, even with the UI removed the theme might still be making unnecessary database calls to verify that something doesn’t exist. It is an excellent idea to build a theme so the user has the option to override the defaults, for example the option to create a page that contains the content for the 404 response, but with a lot of these things there could be a lot of extra database calls.

Finally, of course, the ability to take a GPL theme and create a new one using some of its parts is fundamental to the success of WordPress. If you can simply state that a particular plugin is required for some of the base functions then you are already a winner.

Despite these good points the fact remains that WordPress is now a consumer product that actively discourages direct access to files and code, so if you can’t bundle plugins with the theme and rely on users to move the files above, the chances are high that they will never get installed anyway unless the theme simply cannot function without it. Even then I suspect many users will simply ditch the theme and find something that does work. Back to square one.

Even if you can’t offer the option to turn off the functions you can still code in a way that makes it modular. By abstracting functions into platform generic classes you make them as modular as it is possible to be. Is there any reason why all the presentation code for a menu should directly tap into the WordPress API to get the page details when functions.php can transfer it into a more generic class?

Wouldn’t it be better if the great developers from other platforms could contribute toward code for WordPress, and vice versa?

Navigation is the obvious area that jumps out for me because every site needs menus and once you have a generic menu class you can begin to do a lot more with it. Soon, I will let you have a look at a menu class I am developing for a theme on another platform. It will work perfectly with WordPress as well, not because it is coded for both platforms, but because it is coded for neither. There are many other areas that would do as well. What about a generic text processing class?, tag clouds, archive navigation (although that could be done via a generic navigation class anyway).

I don’t know how much of your theme code you want to share with others, or how much you want to take from others, but next time you are creating some relatively complex code to format something in your theme consider how necessary it is to connect that code directly to WordPress, and if you can, separate it, and share it.

That, after all, is the idea behind open source and community development, isn’t it?

  every 2003s, 1s ago, in 0.02s.