One of the things that I my team and I are often asked is if we’re ever going to place hooks in our core theme files for Standard. The short answer is “no,” but there’s actually a few reasons why I’m personally against placing custom hooks in WordPress themes.

Although this is stemming largely from building and managing a commercial theme, the discussion isn’t limited to that particular scenario. Rather, this is something that I’ve actually discussed with a number of other WordPress users and developers.

Overall, I’m generally against placing custom hooks in WordPress theme files, so I thought I’d share my reasons why I’m not a fan of doing this.

1. The Purpose Of Hooks

As defined by WordPress in the Codex:

Hooks are provided by WordPress to allow your plugin to ‘hook into’ the rest of WordPress; that is, to call functions in your plugin at specific times, and thereby set your plugin in motion.

Simply put, hooks exist that allow our themes and our plugins to modify core WordPress behavior. This is usually done by actions and/or filters.

Actions allow us to do something during the WordPress page lifecycle, and filters allow us to modify data before it’s written to the database, written to the screen, or written somewhere else.

It’s powerful, sure, but hooks existing in the WordPress application core for themes to modify. Custom hooks shouldn’t exist at the theme level for other developers to modify.

2. This Negates Child Themes

The reason that custom hooks should not exist at the theme level is because it negates the need for child themes.

Again, from the Codex:

A WordPress child theme is a theme that inherits the functionality of another theme, called the parent theme, and allows you to modify, or add to, the functionality of that parent theme.

If a parent – or base – theme is developed using WordPress best practices, then extending it is a matter of creating a child theme and customizing the templates and having the developer manage hooks in his or her own customization.

The responsibility of a theme developer is to make sure his or her work is child theme-ready. From there, future developers can extend the theme by customizing templates and leveraging existing WordPress hooks – not custom theme hooks.

3. It Perpetuates a Poor Practice

Introducing custom hooks and filters into your theme is perpetuating a poor practice. This goes against “the WordPress way” of building themes by allowing users to customize their theme in non-standard WordPress ways.

Unfortunately, there are a number of themes – and very popular ones, at that – that have been doing this for sometime now. And when a successful theme does this, others build the same functionality into their theme. After all, if Successful Theme has done this, why shouldn’t we?

But this damages the WordPress community by perpetuating a poor practice. Aside from “doing it wrong,” it gives less experienced developers the idea that this is an acceptable practice and sets a level of expectation for customers that should not have to be met.

It becomes a bit of a vicious cycle: themes that start off by doing this and gaining success are locked into continuing to do this because their customer base is leveraging the existing hook system. On top of that, those customers expect other themes who are “doing it right,” to introduce this functionality into their core product.

This creates a completely unnecessary segmentation in the WordPress market based solely on a poor practice.

The Plugin Exception

A quick word about plugins: plugins are different in themes in that plugin developers may want to support add-ons for their work. Specifically, they are looking to make their plugin extensible.

Because there is no notion of “child plugins” nor facilities for easily extending plugins, then plugins should have a hook system in place that allows developers to do exactly that.

But plugins are different than themes and aren’t meant to play by the same rules.

Anyway, it’s clear that I dislike this practice and I’d love for it to stop, but the fact of the matter is that as long as there are developers who care more about shipping a product that works with a disregard for the best practices than building the best product possible using the best possible standards, and as long as there are people who are willing to pay their hard-earned money for it, I don’t see it stopping.

With that said, the work that both my team and I do personally will not follow these practices. They’re against the fundamental WordPress way of doing things and I’d rather contribute something positive and educate our customers than arm them with something that’s setting them up for doing it the wrong way.