4 Comments


  1. The cynic in me is tempted to say that I’d expect uptake from the major theme vendors to be low (especially “premium” theme vendors). By using framework-specific hooks in their themes, they are essentially creating a lock-in, similar to the lock-in created by theme- and framework-specific shortcodes. Bad for customers, bad for the community, good for the theme vendors who want make it hard for customers to switch to themes by other theme vendors. If they were to start using these standardised theme hooks they reduce lock-in and potentially reduce recurring revenue.

    I would love to be proved wrong and see some good uptake from theme vendors once a nice set of standardised hooks have been agreed on.

    Also, for anyone looking for Doug’s blog post, it’s here: http://literalbarrage.org/blog/2012/06/29/wordpress-theme-hook-alliance/


  2. I agree with @John. But encouraging theme designers to put hooks in could start an avalanche. Some themes are big/slow enough as it is if they’re encouraged to put hooks in they’ll soon start saying “with 121 action/filter hooks” just like some say “62 widget areas”.

    Customizable is one thing, but overly complicated is another.


  3. Thanks for the link, Jeff!

    I’ve just released a second draft over on the Github project (subbing in add_theme_support in place of some define’d constants).


  4. Sounds good in principal – at least as a baseline rather than being seen as a complete set. I’d imagine that a lot of theme frameworks could bring this in by simply adding new aliases for their existing hooks.

Comments are closed.