Standardising WordPress theme hooks
I’ve been working on integrating our SEO plugins more deeply with Genesis the last few weeks and something dawned on me. Ever since I wrote my post on Genesis 2.0, I’ve been thinking: Genesis started a small revolution, but we should open that up. More theme developers should start doing a Schema.org API and if they do, we should make sure they’re interoperable.
In short: Genesis 2.0 added a Schema.org API, with hooks like:
- genesis_attr_entry
- genesis_attr_entry-title
- genesis_attr_entry-content
These hooks are very consistently named, which is very important. There’s one “issue” though: they’re namespaced. They all start with “genesis_”, which is a good practice by the Genesis community and one most theme authors use. But let’s think about this from a plugin authors perspective: if I add support for Genesis Schema.org API and say WooThemes decides to adopt it as well but prefixes it with “woo_”. And then 10 other theme vendors do the same thing. Instead of having one line of code that filters a specific hook’s output, I have 10 add_filter lines to add, and I need to do that for every change.
The same is true with some other hooks that loads of us plugin developers need but WordPress core refuses to add. I’ve had lengthy discussions about the need for a body_open hook in core, but the core team has all sorts of reasons not to want that. I see why, but that doesn’t stop us, as the WordPress community, with coming up with our own standards for hooks and standardizing them in a proper fashion.
WordPress theme hook standardisation board
I think we should be able to get the big theme guys together and come up with a proper standard for these things and it wouldn’t even need much work. Because genesis naming is so elegant, everyone could copy their schema.org API and prefix it with their own standard prefix. The only thing we have to decide on together is a constant we define for the theme prefix.
I’d say WP_THEME_NAMESPACE would be good. What that would allow is for Genesis to define that constant as “genesis”, and for me as a plugin author to hook into that:
[code lang=”php”]add_filter( WP_THEME_NAMESPACE . ‘_attr_entry’, ‘yoast_filter_function’ );[/code]
This would then work with every theme that has support for that API and has defined the theme’s namespace. For other hooks it might be a bit more work, what I’d call “body_open” is in Genesis as “genesis_before”, which is semantically a bit weird in my opinion, but we should discuss.
I’d love to come up with a proper standard for these things. Which is why I’m calling for the formation of a WordPress theme hook standardisation “board”. I’d love to standardise hooks that all big themes have in such a way that plugins can start to rely on them. We shouldn’t “rely” on the core team to do this, in my opinion. I’d love to get StudioPress, WooThemes and all of the other theme people on board and do this together. If you represent a theme company and would like to join, jump in in the comments and I’ll contact those of you who “register” their support to come up with a proper way of discussing this.
Update: of course 10 seconds after publication @nacin tells me something like this already exists in part: the Theme Hook Alliance. We should probably all work together :)
Coming up next!
-
Event
WordCamp Netherlands 2024
November 29 - 30, 2024 Team Yoast is at Sponsoring WordCamp Netherlands 2024! Click through to see who will be there, what we will do, and more! See where you can find us next » -
SEO webinar
The SEO update by Yoast - October & November 2024 Edition
26 November 2024 Get expert analysis on the latest SEO news developments with Carolyn Shelby and Alex Moss. Join our upcoming update! 📺️ All Yoast SEO webinars »
Theme hook alliance is great.
Hi Joost Thanks for sharing your experience great to meet this post.
Hi, I use your plugin and finally I found your writing sample.
The plugin help me for onpage optimization.
Thanks
Hi Joost. What is your opinion on Theme Hook Alliance? I’m curious ;)
While the theme hook alliance has promise, it’s not really what was suggested here.
What Joost is suggesting is more than just standard hooks, but a markup system that is extensible using filters, so plugins can reliably modify key theme markup.
That’s something the THA isn’t really addressing.
great idea, I will surely get this now imedialtely.
thanks for sharing this, this will surely help me alot.
thanks
Sounds great, I will consider adding this concept in our free and opensource drag and drop Nexus Themes framework too.
Great initiative Yoast. Interested to see how far the Alliance team can take the project going into the future.
Thanks Yoast. I plan on purchasing a copy of Genesis this weekend using your aff link. I know I will have plenty of work ahead of me once I get it uploaded and activated.
Having standardized hooks would be wonderful. I didn’t know The Hook Alliance, just had a look after reading this article. I liked the idea of using a namespace constant, but if THA is already in place, why not give it a shot and push it forward. The set of hooks is pretty good. My only question is what about the community involvment? I can’t see any information about who’s in and how many developers are pushing the project.
Another vote for the Theme Hook Alliance! :)
This trac ticket is also worth following, I think.
Thanks for contributing the link to the alliance site, will check it out.
great share, Jeremy, thanks.
As an advocate of WordPress and open source in general I would really like to see this pushed forward by developers of themes.
We need some kind of standard for these hooks which means all kinds of plugins can do much more with much less code – it’s not just Yoast that will benefit from this move but all kinds of other plugins and of course the themes too.
I personally am a huge fan of WooThemes, the hooks they use across their most recent themes are pretty constant – but they aren’t of the same style as genesis or studio or elegant … indeed they all have their own style and whether you are a plugin dev, a web dev or otherwise it can cause issues.
there are a few reasons not to do this, mainly business reasons, but there are lots and lots of reasons to do this. We just need to push this conversation and have a discussion between the big dev theme houses (and lots of us smaller devs) to get a standard we can be happy with both now and in the future.
Sounds like a great idea, thanks for sharing :) i still don’t understand why wordpress won’t let us customize our site our own way! there’s always a problem! i have built my own theme (the first one ive created as a test!) i but still have some problems!
i would like to join!
keep up the great work Yoast!
Yoast:
Nacin beat me to the punch. Pull requests are welcome!