Keyboard overload

I recently wrote about quality-criteria for choosing a Wordpress theme. Trying to select a theme for my own blog, I took a quick glance at several Wordpress themes to understand how much they differ internally (HTML, CSS and PHP). The results are interesting: looking at the header files (header.php) alone makes clear that there are a lot of differences (meta tags, media linkages, functions, even html tag definitions and of course, programming styles). Including all the details is not the point of this post and I cannot tell which of the themes are of the highest quality. It is just interesting to note, that the different themes do not follow standard structures and that each use custom code for fetching and displaying content. After all, if Wordpress is supposed to be just a blogging platform, and furthermore a relatively simple one, and HTML design can be modified quite flexibly with CSS, why is custom code so popular?

It seems that many have re-invented the wheel (also, while it is common to copy some code, it is bad to store the same code in different places). It is especially interesting to note that differences to the default wordpress theme (Kubric) are major. I always imagined the default theme to provide a solid and flexible basis for theme customization, and to work as a great reference thanks to up-to-date API calls and SEO optimization. Turns out I was wrong and developers have seen it necessary to do major tweaking in their themes. (Oh by the wat, why does not Wordpress come with an already optimized default theme?)

Don’t get me wrong. Some differences between themes are vital, for sure, but losing the KISS principle and recyclability is bad. Highly customized themes simply require more effort to work with (customization is hard, maintaining is difficult, size increases, etc.). Does it have to be like this?

Definitely not. As many other platforms, Wordpress employs the concept of child themes which allow to simply override elements from the parent. However, many of us are reluctant to rely on someone else’s theme as a parent and often they are simply not suitable. Therefore, people have come up with theme frameworks, which work as a parent theme and integrate many usable features such as:

• Improved functions for displaying data in a better format
• Wrapper functions to call internals better
• CSS reset
• CSS and Javascript frameworks
• Existing open-source modules for common features such as drop-down menus, embedding flash, etc.
• Base graphics such as icon set
• Localization

Needless to say, these features cut down the development effort once they are served conveniently out of one package.

A quick look at the frameworks tells the four most feature-rich and appealing are (in random order):

• Hybrid
• The Buffet framework
• WP Framework
• Sandbox

For a complete list of frameworks, see Wordpress Codex. As usual, I cannot tell which is the best, but I would suggest doing the decision by looking at their packages and judging by documentation, file structure, syntax, project update pace, adaptation and other similar things instead of solely looking at the features.

Developing on basis of a theme framework can boost efficiency and enable rapid application development. However, does a simple blogging platform really need theme frameworks? For blogging purposes, maybe not really, but they can become a good aid when doing something more complex. A theme framework, like any other framework, provides existing solutions to common dilemmas, improves what we could not even think of and highly improves re-usage of code. However, frameworks can also work against the developer by giving undesirable output, containing bugs, being too limited or bloated, and generally being unsuitable for needs. Using someone else’s code, we always have at least three options:

• Report a bug / whinge the developer to include your desirable feature
• Ignore the framework and do it manually
• Branch the framework and customize it

Of these alternatives, the third looks most appealing. With the modern distributed version control systems such as Git, Mercurial and Bazaar, it is easy to branch the code, customize it and keep pulling changes from the master branch. And even better, we might be able to contribute to the project by suggesting our improvements to be merged into the master branch.

Overall, I give a thumb to theme frameworks. I’ve built websites over Joomla!, Mambo, Drupal, Wordpress and even on the monstorous Plone, but haven’t actually bumped into actual theme frameworks before this. Having quickly reviewed a couple of them now, it would feel stupid to start a theme construction from scratch. Although it’s clear that they can also increase management effort and probably should not be used only on resource-hungry projects, or on continuous basis.

Related posts:

1. Quality-criteria for choosing a (Wordpress) theme