Introduction
Gallery organizes my vast collection of personal photos but its theme system is not easy to modify. Although my site was redesigned three months ago, a large percentage of it remained untouched. To complete the site and bring closure to my redesign, a consistent look and feel was absolutely necessary. I just wanted the same colors, fonts, and formatting. Instead, I got the Tale of Two Themes. It’s a quick look at the complexity, usability, and costs of two open source applications and their themes.
First Impressions
WordPress and Gallery have two distinct methods of implementing a theme system. Both applications use CSS, HTML, and various template files but there the similarities stop. While Gallery uses Smarty, WordPress contends with PHP at every turn. That last difference is a big one. These open source projects take drastically different approaches to theme development.
Gallery imposes a strict regime of access to template methods. Its selection is almost Soviet. Meanwhile, WordPress throws caution to the wind and lets PHP rule with impunity. It’s a broad generalization but Gallery imposes a police state form of security while WordPress trusts its developers and users to bring anything on the plane. These two applications show software design is clearly about tradeoffs.
A Brief Comparison
There’s no limit to lines to code. Code can be written to impose a detailed design scheme, or permit an absurd level of extensibility. The real question is: What’s the role of this software? When the developers of Gallery and WordPress addressed this question they directly affected how theme developers would do their jobs.
Gallery
Gallery uses Smarty. If you’re unfamiliar with this tool, then you’re not alone. This is the first obstacle I faced when writing a Gallery theme for my site. It takes all the PHP code out of the theme and generates it for you. It sounds great. Unfortunately, it imposes a lot of up front time investment to learn a new tool. Productivity doesn’t climb until you can reasonably manipulate its tags. Look forward to the following:
{if isset($theme.photoFrame)}
{g->container type="imageframe.ImageFrame"
frame=$theme.photoFrame
width=$image.width height=$image.height}
{g->image id="%ID%" item=$theme.item image=$image
fallback=$smarty.capture.fallback class="%CLASS%"}
{/g->container}
{else}
{g->image item=$theme.item image=$image fallback=$smarty.capture.fallback}
{/if}
Gallery uses plug-ins. This is the trend for most applications these days. It’s great for open source because it allows other developers the chance to add capabilities not originally supported. Unfortunately, adding features means a purpose-built application can quickly devolve into a slow, bloated monster. A Gallery plug-in integrates just enough theme customization to be useful…for one theme only.
Each plug-in has a set of templates expressly built for theme usage. Within each plug-in’s template directory you can create a “local” sub-directory which overrides the default template. It sounds good, but when you apply a customization, say, to add some header text, it affects every theme. Themes cannot specify which local template to utilize. Thus, the designer is not truly free to make modifications.
WordPress
Unlike Gallery, the role of plug-ins in WordPress is diminished because the core capabilities are all I require. Storing text, comments, and providing RSS feeds is the extent of a blog. I only use three plug-ins in WordPress compared to over 20 in Gallery. The plug-ins I’m using for WordPress leave the theme mostly untouched.
Themes and templates in WordPress are a set of files containing CSS, HTML, and PHP. There’s nothing more to it. The following is a sample of what you’ll see in WordPress themes:
<h3 id="comments"><?php comments_number('No Comments', 'One Comment', '% Comments' );?> on “<?php the_title(); ?>”</h3>
Template functions make repetitive tasks easier and, yes, they’re functions written in PHP. The example above uses comments_number and the_title to get the number of comments for a post and the post’s title. Accomplishing anything via WordPress involves PHP and there are downfalls to embedded code:
- Design and code are not separated. It’s not easy to separate data, interface, and design. WordPress attempts it but only marginally succeeds. This is important in large software teams when the share of work must be divided.
- Breaks from the WordPress loop are not constrained. What amount of PHP code is necessary to escape the security measures put in place? If you allow any code, then you’ve already opened the possibility.
- Version compatibility with PHP. This problem should not be caused by files on the theme-level of the site. Your theme designer wants access to something in PHP 5 and the coder refuses to support anything beyond PHP 4.
The Path of Least Resistance
My strategy was simple: create the theme for WordPress then design the Gallery template to finalize the remainder of my site. This is exactly how it happened but unequal weight was given to Gallery in the final effort. It took a couple weeks here and there after work to finish the WordPress theme. By comparison, the theme and template development for Gallery was dragging on for a month. My Gallery theme was completely based upon my initial WordPress theme. This sounds fine but the format was not right for displaying photos. I was reworking multiple plug-in templates, fudging the CSS, and finally cut my sunk costs. I looked at the long term maintenance of the modifications and could no longer rationalize my initial design. The present Gallery theme is a derivative of the Matrix theme.
When the site was finished I realized too many plug-ins complicated my experience with Gallery. Smarty is an excellent tool and a great idea for separating work share. However, it greatly slows development for the individual. WordPress keeps things simple (almost simplistic) at the cost of security and stability. Remember, developers, PHP can work against you as easily as for you.
I enjoy working with code, but when too much stands in the way of my goal, it becomes frustrating and tiresome. Do yourself and the open source community a favor and ask yourself: Do I really need that extra plug-in?
Write a Comment