“I am trying to port a WordPress theme over to Habari the only way I know how. Step 1- Make mess. Step 2- Flail around making mess worse. Step 3- Somehow clean up mess miraculously. Step 4- Make another mess and repeat process.”
This kind of thing is an indictment of what Habari is all about. our community has been struggling for some time to produce themes as easily as some other publishing systems. Since there are a lot of themers coming from WordPress looking into Habari, they’re looking for similar features in Habari’s theming system that aren’t quite ripe for use. There are actually a lot of places in Habari’s theming system that could use some work.
One of the places that people get confused a lot coming from WordPress is with the “more” functionality. This functionality in Habari is provided by the Format system as controlled by the theme. The reason this is associated with the theme is because some themes will want to display a specific amount of information in certain places. For example, when displaying your home page, the first post may show the first three full paragraphs, but the subsequent listing of posts may only show the first sentence or two. With Habari’s formatting system, this is possible. But more importantly, this preference would only be for that theme – if you switched to a theme that wanted to lay out your posts differently, you would almost certainly not want to use those lengths of truncation. The interesting part is that there’s a weird mix of flexibility versus coherency.
Another thing that is evolving in Habari theming is what I like to refer to as “WordPress versus Drupal theme styles”. By this, I don’t mean that Habari will be able to use themes from either of those systems. What I’m referring to is the style of construction whereby those themes are built.
For example, WordPress themes are built such that every template file is designed to output virtually a full page. Each template includes a header, footer, and the content. For displaying a single post, there is one template. For displaying many posts in a list, there is a different template.
By contrast, Drupal has a single page template that has a kind of hollow body for content. The content area is filled with the type of content that fills a request. So if you request a single post, the same template is used to generate the wrapper, but the template that renders a single post is used to render that post’s content, and it is inserted into the hollow space in the wrapper. Likewise, if you request a listing of posts, each list item is rendered using a template based on the type of item it is, and the accumulation of these is output into the wrapper.
These styles of rendering are two completely different mindsets. Habari supports both.
Even with the potential for goodness in the Habari theme system, there’s still a lot more ground to cover. What we should really do is build some functions into the theme system that make it as easy to work with as some of the WordPress “template tags”. I’m not suggesting that we move away from the OOP approach and go functional. I am suggesting that we provide a more complete basket of template-building tools, including more primitives for output.
At the same time, we need to expand and revise support for things that we already do in a strange way. For example, the pagination functions are just odd. There isn’t a clear path for expanding on them, and I think they’re sometimes faulty. These things should be themeable, so that theme authors can easily make the pagination look like whatever they want.
Also, there are some things that are completely missing. I’m hoping that for version 0.7, we can add some impressive new features like content areas and blocks. A block would be a chunk of content that can be placed, and an area would be a place in a theme pre-determined for the placement of blocks. Blocks could be provided by plugins or the core system, and would be configurable in the theme settings for the theme. They could be used to display all of the standard stuff: Tag clouds, blogrolls, “about me”, Flickr badges, etc. And the blocks themselves would be themeable, so if you had a plugin that provided a block with a basic template, you could make it fit into your theme better by providing a custom template explicitly for that block.
There are many other theme-building enhancements that we should consider for 0.7, and making theming easier is a good focus for the next release of Habari. Making it possible to more easily translate themes from other systems will make it easier for theme developers to produce a Habari version of their themes at the same time as their WordPress or Drupal versions.
