Cleaning up functions.php – sanity check

By now my functions.php resembles something along the lines of that monkey reproducing shakespeare by consequence of keeping everything in a single place ad infinitum. So I started thinking about cleaning things up. Using comments to maintain structure only really goes so far, I found out.

There's a lot of things which - these days - have to be inside the functions.php in order to deal with both native WP as well as Third Party plugin elements and sensitivities, for example emoji's, but also things like Yoast's generated JSON-LD. Also, keeping functions handy for testing can take up a lot of space, making it harder to navigate the contents - for example an output function listing UIKit components loaded.

In my /assets folder I created a subdirectory called helpers. In there I now have two files:

• cleaner.php
• tester.php

The cleaner.php contains everything (I think) WP native, Third Party Plugin partials, but also things like removing page comments. The tester.php contains a snippet Thierry was kind enough to provide at an earlier date, inserting a UI element which uses off-canvas to display which UIkit components (core & add-on) are loaded on a page.

Thing is, I'm not sure on how cleaning things the way I know may or may not impact Beans core strengths - like speed. At the same time, coming from a background of little experience, I wonder whether there are better practices to achieve the same. Also, it may very well be possible that I am overlooking some things which Beans already handles or can handle natively.

Feedback, thoughts, suggestions - all very welcome!

Hey J.C.

Cleaning your PHP functions.php is and excellent thing. In fact, theoritically your functions.php should only be the root of your "three" where you load files, which might further load more files and so on.

Using require_once is basic PHP and uses extremely little memory usage so you would even notice a difference in the spead load.

I am very happy to see how your dev skills have improved how you are thinking about clean up your code and caring about performance 🙂

Happy coding,

Heh, cheers 😛 You have no idea 😛 In one way it is one hell of a fun puzzle, in other ways it can be frustrating as hell - it's why I ended up using cloud9 (quicker and more flexible than a local wamp) and github to keep track of things.

The performance part is an extremely important topic, it's something where beans really stands apart when checking where it stands in relation to how the big search providers determine some, eh, interesting parts of their routines. It's in sharp contrast to popular perceptions where it comes to more traditional frameworks, some of which pride themselves on seo yet frequently are penalised.

So it makes sense to adhere to the strong points. One thing I noticed was that one experiment, the pmo child theme performed measurable worse than another one. Turns out that there's a lot of variables which can be turned into best practices. One thing which really stood out is how functions.php is used for design.

The next part is probably going to be more tricky in these matters: shifting a functionality and design focus towards page templates. There isn't a lot of examples in terms of going beyond the general template markup. But we'll see 🙂

Nice idea J.C.

I use a standard functions.php on all my different themes. With your "cleaners" and my other stuff, like shortcodes.

I was thinking about to move all the Beans stuff to a file called /assets/functions_beans.php.

The same idea, but a different way. But I will copy your tester.php 🙂

Hey J.C.

In applications, the assets folder is usually used only for assets (CSS, JS, LESS). The structure I would suggest which may varie from one site to another is the following:

• theme/functions.php include Beans framework and all the other application files. It may contain PHP constants declaration and other stuff relating to booting your application.
• theme/global.php contains all the global document modifications.
• theme/assets/assets.php contains all the global enqueue and assets logic.
• theme/assets/js/... contains the JavaScript if any.
• theme/assets/css/... contains the CSS files if any.
• theme/assets/less/... contains the LESS files if any.
• theme/{$template-file-name}.php each template file contains modifications specific to a view.
• theme/includes/... each file contains the application functionalities such as a PHP classes, maybe some shortcodes (more plugin territory) etc.
• theme/admin/... each file contains functionalities which should only load in the admin such as post meta registration etc.

The structure above is a "boilerplate" and may change depending your needs.

Hope that helps,