Tag: theme development

Konstantin Kovshenin posted an interesting piece decrying WordPress theme frameworks¹ 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 bunch², 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!³ 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?”⁴ 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*

---

¹Yes, 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.
²“the bunch”, here, meaning “commercial and/or widely-used theme frameworks”.
³Do you smell what the Rock is cookin’?
⁴Yes, I know: gallery shortcodes and widget headers. Please don’t write.