functions.php vs plugin vs mu-plugin for WordPress

It is common for articles on writing WordPress code to refer to adding the code to the functions.php file in the active theme. This is one location where code can be added but it isn’t always the best.

Places to Add WordPress Code

• a new file in wp-content/mu-plugins
• a new plugin in wp-content/plugins
• the functions.php in the active theme

File in mu-plugins

The mu-plugins directory is not included in a WordPress installation by default but WordPress is hard-coded to look for files here if the directory exists. Therefore, you can create the wp-content/mu-plugins directory and then any file you drop into the directory will be automatically executed.

e.g. wp-content/mu-plugins/run-me-everytime.php

New Plugin

In the wp-content/plugins directory, you can add a new plugin by:

• creating a new folder (e.g. wp-content/plugins/my-plugin)
• creating a new file inside this folder with the same name (e.g. wp-content/plugins/my-plugin/my-plugin.php)
• add the required lines to the beginning of my-plugin.php (see WordPress plugin header documentation)

Once this file is created, you’ll need to activate this plugin through the wp-admin Plugin menu (the same way you activate any other plugin).

functions.php

The code in functions.php of the active theme will be always be executed when WordPress runs.

When Code Runs

All of the code across the different files of WordPress can be thought of as one big list of instructions. The code is run line by line starting at the beginning of this list through to the end of this list. The order is essentially.

• the WordPress core code
• mu-plugins
• plugins
• functions.php
• the theme code for the specific template being displayed

Hooks

Because WordPress runs line by line, problems can occur when you try to access information that WordPress has not yet determined. For example WordPress conditional tags (e.g. is_front_page()) do not yet have enough information to provide the response when the mu-plugins code is being executed.

To allow programmers to control when their code is run, WordPress allows you to “hook” into the code (i.e. run your code early but tell WordPress, “do not execute this code until you get to this point later in the code”).

e.g.

add_action( 'wp_footer', 'fe_output_text_in_footer');

function output_text_in_footer() {
    echo '<p>This code is not run until WordPress is displaying the footer.</p>
}

What Type of Code Where

Typically, I try to follow this general pattern in determining where to place my code.

functions.php

Only theme specific code goes here, which is typically the code that controls how things are displayed. If the code should still be active when the theme is changed, this is the wrong place for the code.

plugin

I’ll often create a single plugin for a project that contains things like custom post types, custom post meta fields, and advanced functionality. Often this code is loosely related to the theme code (I put all my CSS in the theme). If the theme changes the resulting output will look “wrong” but it will still be part of the site.

mu-plugin

I don’t use mu-plugins a lot (instead putting my code in the single project plugin listed above). Generally, I like having the ability to deactivate a plugin when troubleshooting. Depending on the project, one advantage of an mu-plugin is it can not be deactivated, which could make it a good place to add something like a custom post type to ensure it can not be deactivated.

Image Credit

pxhere

Sal Ferrarello (@salcode)

Sal is a PHP developer with a focus on the WordPress platform. He is a conference speaker with a background including Piano Player, Radio DJ, Magician/Juggler, Beach Photographer, and High School Math Teacher. Sal can be found professionally at WebDevStudios, where he works as a senior backend engineer.