A while ago I read this post by Yoast on implementing standardized theme hooks in WordPress so that plugin developers have a unified way to insert their content into a specific theme location. The ideas Yoast included there were, in my opinion, amazing – and I immediately thought that a thing like this should be pushed forward. I also found an interesting Github repository of a thing called “Theme Hook Alliance”, but unfortunately I was not able to contact anyone there and I had the impression that it is not maintained any longer. Although discussions exist about including standardized theme hooks in WordPress Core, it currently doesn’t look like such a feature could possibly be added soon. That’s why, based on the resources mentioned above, I took some time to figure out a set of guidelines that, like I think, would vastly improve the WordPress infrastructure if people maintained this standard: The “WP Theme Standardization Panel” defines these guidelines (in the Github repository you’ll find instructions and a reference file on how to implement them). There is no file that you must necessarily include in your theme, it is just a standard you should maintain in your theme. I hope that this makes its way around so that WordPress developers start discussing about it, adding useful ideas and (best case) implementing it into their themes. And this is in no way a finished set of ideas – please take part in improving as much as there is to improve!
What is such a standard?
Alright, you certainly know what standards are. So let me try to explain it from the WordPress point of view: In fact, there are many standards that WordPress itself tells us to maintain. For example, every theme must include the ‘wp_head’ action. This allows plugin developers, but also child theme developers to add content to the website’s head section. Further examples are the ‘wp_footer’ action or the ‘get_header’ function call which automatically fires the homonymous action. There are also other kinds of standards, for example what the difference between actions and filters is – the WordPress Codex is full of standards. Well, I just mentioned actions and filters which leads us to the next important question.
Why are standardized theme hooks a required step?
First, please read this extract from the WordPress Codex:
Custom Filters differ from custom Actions because custom Actions allow you to add or remove code from existing Actions. Whereas custom Filters allow you to replace specific data (such as a variable) found within an existing Action.
And now consider the way many plugins insert their content into the WordPress theme: They use the filter ‘the_content’ to add their stuff right before or after the post content, for example social sharing buttons. While this certainly works from a developer’s perspective, it is not very coherent and it certainly does not stick to the definition from above – yet many plugins do it, even those that come straight from the creators of WordPress (take a look at the Jetpack source code, for example concerning sharing and like buttons). But why do they do it? Because there is no other way! Currently there is no standard that tells us to include an action hook after the post content, and that would be a valid use-case for standardized theme hooks. But there are more points.
Some people claim that theme hooks are not necessary at all (for example, check out this post by Justin Tadlock). While I definitely agree with him in the point that child theme developers should use templates to modify their parent themes, I am nevertheless convinced that theme hooks are required. Purists argue that themes should be responsible for the content whereas plugins should contain additional functionality, but the truth is (and every WordPress developer must have realized it) that themes and plugins interact with each other. Many plugins include functionality that should be printed out to the user, so they need a way to insert it into the theme. That’s where standardized theme hooks would help.
Plugins, however, are not the only reason that we need theme hooks. Many developers prefer modular programming, and most of them like to keep their code clean and organized, separated into different PHP classes or files. For example, when I have a class ‘Meta’ which holds all functions related to post meta, I would like to include it before or after the actual post content. This is another use-case for standardized theme hooks. Some developers even allow users to turn modules of their theme on and off individually (so that a module is only loaded if it is activated), and at this point theme hooks make even more sense.
In fact, many themes and frameworks for WordPress use theme hooks, but the problem is that they are not standardized. Plugin developers don’t necessarily know the names of these hooks, and furthermore they are not willing to adjust their plugin to a thousand different themes (which I totally understand), so theme hooks as they are currently used are only for internal use within the theme. This needs to change!
How does the WP Theme Standardization Panel fit in there?
This initiative defines standards for using theme hooks in WordPress. It is of course not an official Automattic thing, but if they do not implement it in Core, we should push forward our own standard. The guidelines in the WP Theme Standardization Panel can be read in the Github repository, I will not include them in this post. The most important thing is that it defines 10 basic hook names where each hook is used twice, one time in a ‘before’ hook and the second time in an ‘after’ hook. So if your theme should support all these, you would need to implement 20 hooks. But this just sounds weird when reading it here, please take a look at the Github repository to see how it works exactly. Feel free to tell me your opinion or if you have any improvements. These standards are fully customizable and extendable, can easily be implemented into a WordPress theme and allow plugin developers to check for their existence.
So if you are interested in standardized theme hooks, in any way, please participate in the discussion, implement these guidelines if you like, open an issue on Github if you have something to criticize – and really important for a standard, share it with your fellow WordPress developers! What is your opinion about this topic in general or about the WP Theme Standardization Panel specifically?