Without a plugin? The functions.php myth.
A comprehensive user guide.


State of the file

There’s a wide spread digital myth in the WordPress microverse about the functions.php file and that it’s a code snippet container. Let’s take a look at the opinions of some developers who think that this is plain wrong.

Konstantin Kovshenin has posted an article, which can be summed up that using this file instead of plugins makes code harder to maintain, port, share and debug. Then Rodolfo Buiaz posted a meme on G+ that had one interesting line:

Hello Dolly?! One line in functions.php IS A PLUGIN!

And he’s quite right with that. The functions.php is what one could define as a Themeplugin container. Or at least it now mainly is used as such.

The origins

Let’s now take a look at what purpose it originally served:

  • Holds all custom Template Tags your theme defines
  • Loads the theme textdomain and translation files
  • Loads additional theme files that the author uses for code organization (menus, etc.)
  • Has filter or action callbacks that modify the internal behavior of WordPress core
  • Registers and enqueues the themes stylesheets and javascript files
  • Defines custom backgrounds, Header images
  • Registers option pages or Theme Customizer settings

And it still serves those purposes. So, as you can see, there’s already a lot going on in the functions.php file.

Why are you still misusing it?

As we already discussed the cons of stuffing snippets, we should take a look at the pros. The only pro that I’ve ever heard of was that it might be easier to add something to the functions.php than to add a new plugin. This might be the case, if you are using the built in WordPress theme editor instead of a desktop texteditor. At a first glance, this might be convenient, but it only makes one thing easier: Adding code. When you finally want to switch your theme, you’ll have a hard time, as you need to port all your code snippets over to the new theme and test each if it works or if it collides with some part of your new theme. And then there’s this thing that you might have forgotten what part of the functions.php was something that you added and what part was already in the theme when you installed it. And that’s a pain in the censored.

Alternatives? A nano scale tutorial.

As in nearly every case in every situation in every part of the world, there’re alternatives that will help you to get most of both sides. In this case, you’ll even get everything of both sides. And this in less than five minutes.

  • Open your texteditor. Something like Notepad++ or Proton is fine enough.
  • Add a new file named functions.php and save it to your desktop.
  • Now add a plugin header comment on top. We’ll go with the minimum, the Plugin Name: part. The following lines only do three things: 1) Open the PHP file 2) Deny direct file access for security 3) Give the plugin a name.

    1. <?php
    2. defined( 'ABSPATH' ) OR exit;
    3. /** Plugin Name: Custom code snippets container */
  • Now use a zip program like Winrar, Winzip or 7zip, make an archive and go to your admin/plugins page.

  • Choose upload, select the file on your computer and upload your new plugin.

  • Activate it.

  • Done.

From the beginning to the end you shouldn’t have needed more than some minutes to complete this tutorial. You now have officially created your first plugin. So don’t be afraid, it doesn’t slow down your system – that’s just part of the myth. It’s absolutely equal in loading speed and execution time as if you’d still stuff snippets in your functions.php file.

What’s next? Now open your plugin file in your WordPress admin UI plugins editor. Then start moving all your custom snippets from your Themes functions.php to your new Plugin functions.php file. And you’re done! Congratulations! You just saved yourself some hours when switching themes, have a secure place for your snippets as they can’t get lost during Theme updates and you have even secured a file against direct file access (if this was possible before).


Now that you’re beyond level 1 of professional WordPress usage, you might consider taking a step further. There’re several routes that you can walk from here on. Each one will make your life even more easy, as you will be left with the option to activate or deactivate single snippets in case you get the ☠ white screen of death – or a nasty error message in case you got WP_DEBUG set to true in your wp-config.php file more about debugging here.

…or move straight to the pro level:

  • (S)FTP to your server and navigate to the ~/wp-content directory
  • Add a new folder named mu-plugins
  • Done.

What have you got now? The answer is simple, but pretty unknown: A M(ust) U(se) plugins container. To shed some light on this, here’s a short explanation what will happen and how this might help you. You’ll get an additional tab on the admin UI plugins page. It will appear after you (S)FTP-ed your first plugin there. Then you’ll notice that you can’t activate or deactivate any plugins in there. WordPress activates them automagically for your. And if you own and run a multisite setup, it will even activate them on every single site in your network.

There’s only one minor drawback to this solution: You’ll have to use your (S)FTP browser as there’s no upload interface for such plugins. But I guess you can live with that.

What is a plugin?

One thing that sometimes comes up in discussions about plugins vs. functions.php as plugin container: “Is this plugin material?”. In any case the answer is simple and always the same: Yes. Look at the following example that deactivates the admin toolbar. In fact it’s just a single line of code. And it belongs in a plugin file. Why? Easy: Because it does add functionality and not style. If you need to add style, go with a Child Theme.

defined( 'ABSPATH' ) OR exit;
/** Plugin Name: Disable the admin bar */
add_filter( 'show_admin_bar', '__return_false' );


We’ve now discussed all the pros and cons of different solutions, have stepped into several levels of snippet handling and left you back with a bunch of options. Now only one question remains:

Are you going to use it?


    1. Would you tell us why exactly? And would you mind to add a disclaimer in case you’re related to the plugin (for e.g.: the author)?

  1. I wouldn’t consider SFTP pro level, if you’d said something like automated git deployments on push to repo I could have let it slide =p

  2. Plugin/Snippet management tools mentioned are nice but it would be even better if WordPress itself had build in features. Like ability to group plugins, better sorting/filtering.

    I know Plugin Organizer does this http://wordpress.org/plugins/plugin-organizer/ but hmm, a bit overkill. Definitely a job for core not add-on.

    Also adding notes to each plugin, some HTML even, is covered http://wordpress.org/plugins/plugin-notes/ but again a job for core.

    For now I think those management helpers are better than putting lipstick on plugin page – but one day in 2017 they are hopefully not necessary :)

    1. Fully understand your needs. With 250+ home brewed plugins I got a need for that as well. So I asked a question on WPSE and Christopher Davis came up with a super elegant solution, which I improved a bit. You can download WP Plugin Directories on GitHub. Give it a test drive. :)

      1. Been there, though I am not sure which I tried :) Works fine. There are always short cuts and fixes for those who know how. I am more thinking of “no coding required” majority. They might understand need for plugins, also vs. themes, but demand EASY 24/7. That force will always win over arguments. If not feeling happy they stay with monster themes or do not actively use plugin page = issues follows. Like “without a plugin” ideas. Plugins are not seen as little friends :) I actually doubt even a perfect plugin manager will be super popular, must be baked in core to be used.

        Theme page has infinite scroll?, menu editing page is also getting new paint in 3.6, so plugin page could in theory get focus. I do not know of WordPress roadmap but we will see.

  3. One thing that often trips people up is that code run in an mu-plugin, or a regular plugin, or even as in the code snippets plugin (thanks for mentioning it btw) is run much earlier than code in functions.php.

    This means that a line of directly executed code such as add_editor_style() will run fine in functions.php, it will cause an error in one of the other methods. Of course, the solution here is to always wrap your code in a filter/action hook instead of executing it directly, but not all snippets are distributed in this way.

    1. Have you already tried delaying those snippets until after_setup_theme? At least this is the hook everyone should use for functions.php snippets.

  4. Super-comprehensive guide, Franz! I updated my post and I hope many users will take the advice and either use a Meta-Plugin like Toolbox, or follow your tutorial and create their own plugin out of their existing functions.php. This pretty much sums it up for me:

    […] it’s just a single line of code. And it belongs in a plugin file. Why? Easy: Because it does add functionality and not style. If you need to add style, go with a Child Theme.

    I guess another reason why users might drop code into their theme instead of using a plugin might be they just want that one function tailored to their need to be executed without having to worry about a bloat of settings and optional stuff to take care of.

    There used to be a fairly wide-spread belief amongst plugin developers that a plugin needs to have a settings page to gain attention. Fortunately, that belief seems to dissolve lately. If it does one thing and it does it right, I’d say it’s brilliant, period.

    Last but not least, you have those plugin authors who either don’t give a sh*t about “doing it right” (a.k.a. using the tools WordPress offers them to extend its functionality), or they aren’t mature enough developers to do so.
    Among other things it’s the mess their code creates that can give users the impression it might be more risky in general to install a plugin than pasting that one function into their theme.

    I don’t mean to blame anyone with good intentions, of course. Open source is sharing and learning. Creating a mess sometimes seems to be an inevitable part of the creative process. The ball rebounds to the user really who should get involved and provide feedback to the plugin author to help them improve their code.

    1. You’re absolutely right, saying…

      There used to be a fairly wide-spread belief amongst plugin developers that a plugin needs to have a settings page to gain attention.

      That’s the reason why none of my plugins have options. Or at least none that the user sees as such and needs to tweak before using a plugin. Might be a good topic for another article.

  5. The company I work for is just starting a move from a custom built internal CMS to WordPress — and as we are moving faster than we probably should, haven’t had time to sit down and work out the best approach to things. Your article provided me with a major step down that road. Thank you!

  6. I am a WordPress developer (Meme buster) and I aprove of this message :o[)

    Yes, we can go wild, dozens of mu-plugins. And to enable/disable change the extension to .php1 or .bak

    Excellent article and addition to bring down this MEH.

Comments are closed.