WordPress Theme Hook Alliance

Konstantin Kovshenin posted an interesting piece decrying WordPress theme frameworks1 and the extra amounts of work that they (can) require to get working Just The Right Way. Essentially, his complaint comes down to having to re-learn a system of hooks and filters in order to be cognizant of, if not competent with each of the frameworks in use. Konstantin calls out Genesis, which, to be frank, is the absolute best of the bunch2, as far as I’m concerned. Genesis, whenever and wherever possible, asks “What Would Core Do?” and then implements its innovations in a way as close to Core standards as is feasible.
I’ve actually been bothered by the same thing over time and have noticed that the net effect is that certain WordPress designers and even whole firms tend to pick at most 2-3 theme frameworks to specialize in. This leads to a bit of a “siloing” effect — designers and devs become experts in a certain way of doing things but ultimately end up being at least partly constrained by their choice of framework[s].
This also has the end effect of locking site owners into particular theme frameworks, making migrations and redesigns complicated and potentially expensive in terms of time and money.
So what can be done? I can see two approaches, the merits of which I will discuss below.

WordPress Core adds more hooks

WordPress already has quite a few hooks available, in the form of both regular action hooks and an extensive variety of template tags. These provide developers and designers with a consistent set of entry points to target for theme and site customization. If we could convince upstream WordPress to define a standard set of theme hooks, theme authors could code to a Core-supplied benchmark which would allow plugin developers greater opportunities to extend WordPress in new and better ways. Further, this would allow users in general to more easily change their theme-of-choice.
There are (at least) three decided downsides to this approach.

  1. Core Bloat WordPress Core has been getting both larger and more complex as time goes by. While there have been great leaps in performance over the past few versions, it’s indisputable that the size of a WordPress download has been creeping ever upwards, to the point that several previous pieces of Core functionality (such as the various importers) have been stripped out in order to allow WordPress to even install in certain low-memory hosting situations. Further, stripping the images out of the Twenty[Ten|Eleven] themes and moving core JavaScript libraries to an external CDN have been bandied about as ways to further fight bloat.

    While the actual size of the additions would likely be small (in terms of kilobytes added to the download), there’s no denying that additional hooks would greatly increase the complexity of the underlying code.

  2. Explicit dependence on WordPress release cycles WordPress itself is released on a (fairly) static schedule, with roughly 2.5-3 releases occurring per year. In the event that additional theme hooks were needed, theme authors would need to wait for the next WordPress release in order to be able to rely upon the hooks being in wide use.
  3. This isn’t something core WordPress is/should be concerned with Frankly, the whole concept of theme hooks is self-evidently not a core WP issue. Themes currently implement their own hook regimes in order to allow for customization and flexibility precisely because WordPress itself doesn’t supply these points of articulation. This is no knock against WordPress itself, but rather this reflects one of its core strengths: the Plugin API allows for almost unlimited customization opportunities. Core WordPress should limit itself, wherever possible, to providing users and developers with the tools for customization and extension and should get out of the way so that such customization is as “frictionless” as is feasible.

Theme developers agree upon an independent set of hooks

This option makes more sense to me. As I pointed out, these hooks are something that various and sundry theme development shops have taken to implementing on their own because they want more and/or different capabilities than WordPress template tags and action hooks offer by default. Heck, I have quite a few hooks on offer in Elbee Elgee for precisely this reason (all prefixed with lblg_, of course).
By taking this task out of the hands of the WordPress Core, we would gain quite a few advantages:

  1. Version independence Hook alliance member themes could debate the merits of various useful hooks and their places within themes on a timetable completely their own. There would be no need to have to wait for a lengthy Trac process and a new major dot-revision of WordPress — theme devs would be free to implement them whenever a consensus was reached.
  2. Know your role, jabroni!3 I’m drawing a bit of a blank on how best to summarize this thought other than “theme concerns generally exist at a level of abstraction above WordPress itself”. The code present in WordPress itself is concerned primarily with “how do we save and/or retrieve information from the database in a meaningful and orderly fashion?”4 It falls to the themes to determine
    1. Where each piece of retrieved information appears on-screen
    2. How each piece of retrieved information looks once on-screen
  3. Another thing to argue about, unendingly, in a place that isn’t Trac Okay, maybe that’s not a true advantage at first glance, but work with me here. How many arguments have cropped up on Trac or on the wp-hackers mailing list over issues that would be covered by the hook alliance? If a standard Core Trac reply could be “That’s a theme hook issue and not a Core one. Have you suggested something over there?”, would we not all benefit? This would allow Core developers to focus on the get/retrieve aspects where they excel and allow theme devs much greater control over their own destiny.
  4. Coordination with the Theme Review Team Not to put too fine a point on it, but the current incarnation of the WordPress Theme Review Team is the best example of a true community investment opportunity WordPress has going. Goals and standards are well-defined and the team itself is a large group of people working unapologetically towards making themes hew to a uniform code of quality, reliability, and security. Chip, Otto, Emil and Edward (among countless others) are to be commended for their ongoing efforts in this respect. The TRT could offer invaluable feedback in developing a uniformly useful set of agreed-upon hooks.

Implementation details

A simple first step would be to agree upon a standard prefix/namespace for Theme Hook Alliance hooks. I might suggest tha_ as a good place to start. I would also suggest a few simple hooks whose purpose should be quite obvious, such as

  • tha_before_header
  • tha_after_header
  • tha_before_content
  • tha_before_sidebars
  • tha_after_sidebars

Again, that’s just a sampler. I think there are a ton of other points of articulation that would be invaluable.
So, who’s with me in this idea? Am I crazy? Does anyone else see any utility? Who wants to argue over the utility of tha_before_content()?
UPDATE (10:03 AM): Chip points out on Twitter that this idea is not novel: it was discussed over on WP Tavern about three years ago. I think it’s time to resurrect it. *grin*


1Yes, I know the arguments about what constitutes a “framework” versus a “parent theme”. I’m working with the terms in play. Please don’t write me angry letters.
2“the bunch”, here, meaning “commercial and/or widely-used theme frameworks”.
3Do you smell what the Rock is cookin’?
4Yes, I know: gallery shortcodes and widget headers. Please don’t write.

Elbee Elgee Version 1.3/1.3.1 Aka “The Tabbed One”

After a healthy delay, I’ve released Elbee Elgee 1.3 to the Dot Org Theme Repository. I’ve added a few things worth noting.

Tabbed Admin Options

Elbee Elgee Settings  Elbee Elgee  WordPress
The first change that I’m rather proud of is the inclusion of tabbed admin interface elements. While the code powering this setup could use some optimization and simplification, this tabbed step lays the groundwork for some other exciting features I have planned for forthcoming releases.
As you can see in the screenshot above, Elbee Elgee will now detect whether you have BuddyPress and/or bbPress installed and active and will separate out admin elements relating to their functionality into separate tabs. They’re simple examples but they demonstrate the power of this approach.

The Beginnings Of Theme-Wide PHPDoc Documentation

Phpdoc 1
I’ve started documenting the ins and outs of the master parent theme in an effort to both assist my lousy memory and to give pointers to users and (hopefully) other theme devs that choose to use Elbee Elgee as a basis for child themes. All files that originated in this theme should eventually have a PHPDoc doc block at their top and all functions will eventually have associated doc blocks as well.
This is very much a work-in-progress but I hope to have the theme thoroughly documented within the next couple of revisions.

BuddyPress 1.5 Support

The recently-released BuddyPress version has radically changed the way many of BP’s core functions work. I’ve adjusted the included theme templates included in Elbee Elgee to compensate for this and am fairly confident that this theme is one of the few freely-available themes out there to offer such.

bbPress 2.0 (Final) Support

There have been some minor revisions in support for bbPress. Not much changed between 2.0 betas and the final release, so not much has changed internal to Elbee.

bbPress Single-Column Layout Support

Disabling bbpress
Tucked away in the new bbPress tab you will see the options shown at right.
Previously, theme users employing 2- and 3-column layouts were potentially constrained in their forum views. Personally, I feel like bbPress tends to feel a bit “cramped” in the cases where it has to contend with sidebars.
In order to address this, I added the ability to disable the default sidebars and default footer widget areas.
Check out the examples below for a taste of what I’m talking about.

Regular Layout

Allactive
Here we have an example of the standard 2 column layout.

No Sidebars

Sidebar disabled
And here’s what it looks like without sidebars. Much breezier, no?

No Nothin’

All disabled 1
Here we have both sidebars and footers disabled, for those who really dislike widget areas cramping their style.

CSS-Only Drop-Down Multi-Level Menu Support

Drop downs 1
Previously, Elbee Elgee had no support for drop-down/multi-level navigation menus, so I simply limited the main menu display to the top level. However, version 1.3/1.3.1 have addressed this flaw in the default stylesheet (ng.css). This menu setup should work in all modern browsers — no JavaScript needed. Please let me know if you find otherwise.

1.3 And 1.3.1? Huh?

1.3, the version currently available in the WordPress.org theme repository, actually contains a small bug that will incorrectly limit layout options if you have bbPress enabled. I’m in the process of getting 1.3.1 approved and your auto-updaters should pick up the update as soon as it’s cleared by the Theme Review Team.
In the meantime, if you want to grab a copy of 1.3.1 to install directly:

  1. Click over onto the Bitbucket download.
  2. Unzip the zipfile. This should create a directory zamoose-elbee-elgee-0e0b34ec56d6.
  3. Rename zamoose-elbee-elgee-0e0b34ec56d6/ to elbee-elgee/.
  4. Remove/set aside your existing elbee-elgee/ directory under wp-content/themes/.
  5. Upload that local elbee-elgee/ directory to your wp-content/themes/ directory.
  6. Visit the theme settings page and make sure that everything seems correct.

Issues? Problems? Bugs?

As always, please drop me a line in my support forums. Thanks!

Announcing: Elbee Elgee

I’m excited to announce the first public release of my oft-delayed theme, Elbee Elgee. It’s available right now over at its page on WordPress.org. I’ve been working on this for the better part of the last few years, picking at the code here and there but never with any real drive towards a release.

Why Release A “New” Theme?

As I said above, I’ve been kicking this theme around for several years. It’s been the engine powering Literal Barrage (in various incarnations) and I’ve always meant to release it, though I’ve always lacked the motivation.
Then came Oenology and Ghostbird.
Chip and Michael’s respective theme releases lit a fire under my butt and I decided to get the theme into shape for release.
I wanted to make sure I understood the WordPress theme development process from front to back and I wanted to integrate some ideas that had been floating around in my head since I published my original theme options page tutorial.
After several rounds of bugfixes and refinements, I cleared the WordPress Theme Review Team’s review process and, well, you can see the result over at the official demo site (or you can check out your current surroundings — Literal Barrage is running a child theme of Elbee Elgee).

What’s so exciting about Elbee Elgee?

I’m pretty psyched about several noteworthy features that I’ve included in this theme. Check ’em out below.
Continue reading “Announcing: Elbee Elgee”