In the mid-20th Century, the concept Form Follows Function came out of the architecture industry. The basic idea is that the outside of the building should reflect the functional interior. This means designing the interior structure before designing the outward appearance of the building.
When building a WordPress website, you have two main parts to code. We can also think of these as Form and Function. The Form is the visual aspects of the website that the user sees and interacts with, and the Function is the code that the visual and interactive components are built upon.
We can also look at it as themes are the Form and plugins are the Function. But what goes into a theme and what should be in a plugin? Well, this is a matter of contention. Every web developer approaches their code in a different way. There are no solid rules that say what is supposed to be included in a theme and what’s supposed to be in a plugin. If you were to look at commercial themes, like what you can find in theme shops like ThemeForrest, you might come to the conclusion that everything goes into the theme.
There are commercial themes out there where the author crams as much functionality as possible into their themes. This can be very advantageous for the theme author, but a lot of WordPress developers consider this bad practice because of the possible pitfalls of updates breaking the themes and authors abandoning the themes, leaving everyday users with no recourse for support.
Now, I’d like to make this clear. As I stated before, the concept of Form vs. Function in web design is an opinionated one. There are some general concepts that have been adopted by the majority of the WordPress community, and there are developers that don’t follow these practices at all. There is no real correct answer. The concept of form and function can blur the lines in web development. What one developer can consider function, another can consider form.
From here on in, I’m going to discuss this in the way I approach WordPress development. If you disagree with me, that’s OK. I’m not claiming to be absolute in my opinion. I enjoy hearing different opinions. I feel that if I were to outright dismiss another’s opinion, I may miss the opportunity to learn something new and discover a new approach that I may never have thought of on my own.
So what does go into a theme and what should be separated into a plugin? I approach this by asking myself a set of questions.
Would I Put It in a Style Guide?
If the code I’m writing could be included in a style guide then it should be part of the theme. Let’s say I have a function that retrieves a list of all the users that are authors. Well, that function would only be generating data. I wouldn’t include data in a style guide, so I would place that function into a plugin. Then I’d call that function in the theme and style the markup and the text outputted by that function.
Can I Switch Themes?
The goal here is to have the ability to switch themes without having to copy the files that create the functionality. Let’s say I have a special holiday theme that will only be used for one month out of the year, while the main theme is used the remainder of the year. On the website, I have a gamification system that awards users for their interactions on the site. Something like this can change by adding new rewards or changing the criteria for receiving rewards. If I were to build this system into the themes, I would have to copy over all that code every time I switch to the holiday theme. That isn’t a very effective way of doing things; so by putting the gamification system in a plugin, it can be updated without having to worry about it breaking when I switch themes.
Can This Be a Standalone Plugin?
Can I Find It?
I’m a big proponent of code organization. There’s nothing worse than having to pore over a file with 1,000+ lines of code to find just one function that’s causing a bug. The more you can group together and organize your code, the better. You want to be able to glance at your files and plugins and just know where some bit of functionality is going to be. By placing all the code for an events calendar into a separate plugin, you know that when something goes wrong, you’ll be able to find it quickly.
If you were to put all, or even worse, some of that functionality in a theme, you may have to do some digging around to find it. If you only call the functions in the theme and kept all the working parts in a separate plugin, then you (and possibly other developers) would be able to easily find what you’re looking for. The same logic can be applied to the theme, too. If you have an animation that is triggered when the user clicks on a button that no longer works, you’ll know to look in the theme since it’s a visual and interactive part of the website.
The last thing I want to mention is what I think is the biggest advantage I see by separating your Form from Function. It’s reusability. Being able to toss a plugin into a new site you’re developing and get actually what you want is priceless. If you developed a plugin for one site and your new client says that they want the exact same functionality on their site, you could save yourself hours of work if that functionality was already in a separate plugin. Then all you would need to do is match the styles to the new site.
Separating your Form from Function in WordPress development can improve your workflow and make developing WordPress websites an even more enjoyable experience.