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.

I have been using Ubuntu 8.04 LTS for some time now because my Fujitsu-Siemens Si1520 laptop cannot handle the newer versions. Upgrading breaks my sound, hibernation, wlan, external monitor output and other features. That’s interesting, considering that much of my hardware is intel-based which should be well supported.

Whatever the case, after tweaking my bash configuration a couple of days ago, problems begun appearing with tab completion in bash:

$ sudo <TAB>
bash: no match: COMP_WORDS[2-1]
$ ls *<TAB>
bash: no match: '*'
bash: no match: '*'
\*
$ touch file.zip
$ unzip <TAB>
bash: no match: '!*.@(zip|ZIP|jar|JAR|exe|EXE|pk3|war|wsz|ear|zargo|xpi|sxw|ott)'

It appears that enabling failglob option in bash conflicts with bash-completion package, which is broken. The error messages shown are not actually the problem, but completion mechanism fails to find the files and has to give the error.

Luckily, these errors (and many more) have been fixed in newer bash-completion package (in 9.04 repositories at least). Unfortunately, the bug still persists in 8.04 and there has been some discussion around it at Launchpad bug report. With 8.04, it seems that in order not to break the completion system either

1. do not enable the failglob at all (it’s off by default), or
2. apply the patches provided in the Launchpad thread

I personally chose to turn the feature off because the patches provide only partial fix to the problem. However, that means I must remember to manually set it on and off in certain bash scripts. Why? Richard Neill explained it quite practically in his comment to Brian Carper’s blog post about failglob (check the first comment).

Web themes are often picked by their looks, usability and other quite visual aspects. Here’s a short and very incomplete quality criteria that is often followed:

• Usability: Allows visitors to browse site easily, find relevant information quickly, etc.
• Compatibility: Similar look and feel in different browsers, scaling to different resolutions, zooming, etc.
• Appeal: Makes people generally interested and happy to surf your site :-)

However, any good-looking theme can be internally of low-quality and raise problems when applied in other contexts than the original development environment. Therefore, it is highly important to pay attention to many other elements as well:

• Platform compatibility: Ensures compatibility with plugins, different platform versions, etc.
• Platform integration: Reliance on platform’s standard calls calls reduces need for custom code
• SEO friendliness: Improves rankings in search engines and allows people to find the site more easily
• Validity: Passed validation tells about usability and structure quality
• Integrated features and elements: Contains the relevant meta tags, RSS feeds, favicon, logo etc.
• Customization: Theme structure is clear, CSS is neat, HTML contains well formed classnames, etc.
• Maintainability: Beautiful syntax, logical structure, comments, HTML structure, etc.
• Size: Highly optimized code to keep load times at minimum, compressed CSS and Javascript, etc.

What can we tell from these? The first list contains the elements that we can review visually just by looking at a theme while the second list contains equally important elements that can only be reviewed by looking at the actual code. Quite often we browse the themes only considering the criteria of the first list, but in fact we should pay even greater attention to everything else. I think this is important: let’s not get fooled into a good-looking theme that is total disaster internally!

To summarize the two quality viewpoints:

• Design quality: visitor gets happy
• Internal quality: site owner gets happy

Therefore:

• High quality = high quality design + high quality internals = everyone’s happy :)