One of the things that I appreciate about certain application development frameworks is their approach to convention over configuration.
By that, I mean that they tend to take the approach of “a place for everything, and everything in its place” rather than setting a ton of variables in a set of different files to tell the core system where everything is located.
In my opinion, WordPress is a little bit of hybrid of this kind of stuff, but I tend to look at it in the direction of modifying configuration files.
After all, we have both `wp-config.php` and we have `functions.php`. Both of these serve their purpose, but `functions.php` can get specifically cluttered as a theme or an application grows.
Introducing Helper Files in WordPress
As far as WordPress configuration goes, messing with `wp-config.php` really isn’t all that bad in comparison to how many lines and/or how many files you have to tweak for certain pieces of software.
Aside from the usual database credentials, there are very few variables even designers and developers may tweak.
Still, it is a file that needs to be edited to I wanted to mention it.
Unfortunately, I’ve found `functions.php` to be a completely different beast. Over time, this file becomes a bit of bit of a wasteland of functions all of which served a purpose at some point in time.
Generally speaking, I think that we – as theme authors – aim to keep the file as lean as possible focusing only on the functions that are needed for our theme; however, as themes or applications grow (and they do), the file begins to collect a variety of functions that are suitable for whichever release.
Then, as is with a lot of refactoring efforts (or lack thereof, really), the file begins to collect a lot of logic that’s no longer needed, or that could be cleaned up to lean out the file for easier maintenance, readability, and performance.
That said, I’m still a fan of the `functions.php` model – but I think that the structure of themes and/or applications that use it heavily can more effectively employ some type of helper files that aim to keep code organized, and to help us define “a place for everything, and everything in its place.”
Core Functions, Specialized Functions, Helpers, and More
For example, in a couple of projects that I’m working on right now, I am only using `functions.php` to define logic related to core WordPress theme functionality. This includes (but isn’t limited to):
- Post Formats
- Content Width
- Automatic Feed Links
- Navigation Menus
- Stylesheets and JavaScript sources
- …and things like that.
But when it comes to other more coherent ideas, I’ve been keeping them in their own files.
Specifically, I define an `includes` directory that may, ahem, include files like this:
- `class-theme-nav-walker.php`
- `theme-customizer.php`
- `helpers.php`
The Navigation Walker class a subclass of the default WordPress Navigation Walker and includes all of the logic necessary to customize WordPress menus within the context of my project.
`theme-customize.php` contains all logic required to integrate the theme customizer into a theme as well as where to define sections, settings, and controls.
And finally, `helpers.php` contains small functions that help to enhance basic theme functionality. For example, some of the function names that I have in the file for Mayer include the following:
- `mayer_add_post_class_to_single_post`
- `mayer_is_paginated_post`
- `mayer_custom_password_form`
- `mayer_add_more_link_class`
- ..and so on.
But how do we continue to decide what goes where?
It’s a Matter of Cohesion
One of the concepts that we hear about all of the time in software development is the idea of cohesion. As with most of other things in computing, it’s a big word for a relatively simple idea.
In short, cohesion is about to level of which functions or pieces of code are related to one another. So, to that end, I believe that our file organization should reflect this.
This means that functions that are all related to the, say, Theme Customizer, should belong in `theme-customizer.php`. When it comes to general utility functions, the code belongs in `helpers.php`.
You get the idea.
This goes completely against the typical method of dropping everything in `functions.php` because if every type of function is contained in a single file, then the file has no real identity.
And for the sake of maintenance, readability, and even some performance improvements, I think it’s important to group our functions in a logically consistent way.
Then again, this is nothing new to any given programming paradigm, but it’s something that we fail to practice as much as we preach.
Leave a Reply
You must be logged in to post a comment.