Best practices, in spite of their name, are rarely used. When it comes to add any code piece for WordPress, that becomes evident.

Perhaps 99% of web designers and even some devs have been widely using the theme’s (or the child’s, for God sake) functions.php to include their own snippets.

While this sounds like safe and a good practice, using any of the theme’s files, or even those from a child, can be taken as serious work in terms of WP development.

Why? Two reasons: one of them regarding the basic approach, and another really technical.

What approach?

WP has been thought, and that’s maybe its forte, to be a CMS that admits any extension through adding plugins. These modules, if you will, allow devs to create all sorts of features and modify WP’s behaviour as they want.

Themes, on the other hand, figure as WP’s views. Ideally, they should be just taking care of the frontend. However, when you add new coding snippets to its files, part of that related to the backend, that is just wrong.

In practical terms, if a system admits modules to change or improve its behaviour, why the hell are you NOT using them for developing, for crying out loud?

That sounds easier to just sprinkle some code lines within the theme, but they might be failing – and that’s because of the second main reason you should be using a plugin.

WordPress’ firing sequence

WordPress’ code is basically organized in a sequence. As most PHP servers are incapable of performing concurrent jobs, the code must be executed in a sort of timeline.

For adding new features to its code, WordPress allow devs to hook their code into certain moments or routines. However, if you miss the train, that piece of code you have just put up won’t work at all.

As previously told, theme are more involved with the frontend. So there is no technical need for them to be executed before the user access the website. So, everytime you add code to a theme, you incur in the risk of missing the train.

Straightforwardly, if you add a code that should be running in the backend or WP’s boot, there is a huge chance it doesn’t work at all.

So, technically, plugins start running much before the themes, and that will be the reason you should be coding in a plugin, no in functions.php or any other theme file.

Bad excuses

Nonetheless, web designers and so-called devs keep adding code to the theme’s files. All kinds of excuses are given to that:

  • It is harder (creating a plugin, actually, is easier and faster than making a theme)
  • One shouldn’t be messing up with plugins (that’s right, but nobody is telling you to change an existing plugin, but creating a new one)
  • You can always change the theme (yeah, and also deactivate a plugin)
  • That’s dev’s job (so messing up with functions.php does)

Some other excuses include an alledged complexity of developing a plugin. Well, if you can put up a child theme, creating a new plugin will be even easier – it requires a single file to do so. Also, one can find a number of boilerplates around.

So what should I use the child theme for?

Ideally? For nothing. But if you insist, and even WordPress docs encourages the practice sometimes, use it for strictly theme-related tweaks.

For including or modify template files, enqueue theme related assets or add support to a particular feature.

Don’t forget that lately some theme developers, especially from those loved theme from Envato, decided to provide updates not only for the parent themes, but also for children (???). In my opinion that completely kills the purpose and reinforces my core argument: keep distance from plugins.php.