Jump Start and our other WordPress themes include a very extendable framework that can be modified from your child theme or custom plugins.
Throughout the this website, we reference all edits as being made from your child theme’s functions.php, but this is for the sake of clarity to the beginners. I don’t want you to think that I’m telling you that you need to use a child theme versus using a plugin.
Where you place your customizations is up to you, and although it’s an intriguing topic for sure, I don’t want to go into any kind of philosophical debate on what code should go in plugins versus the theme. Mainly, I just want to make sure you’re aware of some differences, if you choose to add theme customizations via plugins. Some of these things are pretty obvious, but are also easy to overlook for anyone.
Why You Might Use a Plugin
There’s always ongoing debates in the WordPress community on what types of functionality should be included via plugins versus the theme. Keep in mind that mainly relates to publicly distributed products, though.
Most people reading this are probably creating websites for their clients. So your development team and your clients are the ones using your setup. This means how you split up your code will depend on your needs and how you want to organize your site, and not what the WordPress community is telling you to do.
In trying to decide where to put your code, just try to think practically. For example, say you make five different websites, with five different child themes. But within all five sites, you use an identical code snippet. So maybe in this case, you could improve your workflow by adding that functionality to a plugin, which you can then manage across all of your websites.
Whether you have all your functionality tucked into your child theme, or spread across ten plugins, it really doesn’t make any kind of difference in the performance of your website. It’s all the same code running on your website. So, make your decision based on what’s best for your workflow and organization.
Making Customizations from a Plugin
Whether you’re adding your PHP code to functions.php of a child theme or to a plugin’s files, it’s all just PHP being included when WordPress loads. — So, what’s the difference?
The important thing to understand here is the order in which WordPress loads the files we’re working with.
- All plugin files are loaded.
- The child theme’s functions.php is loaded.
- The parent theme’s functions.php is loaded.
Since our goal is obviously to edit the parent theme, this can be tricky at first glance because it’s actually loaded last, in relation to the other items we’re discussing. If you’re working from a child theme, this dilemma is already solved for you by including the framework at the top, as described here. However, in working from a plugin, there are some things you’ll want to take note of.
Theme API Functions
From your plugin, because your Parent theme hasn’t actually been included yet, you can’t simply call the theme framework’s API functions. You’ll need to actually hook them in later in the WordPress loading process. A great hook to utilize here is after_setup_theme.
So, for example, let’s say you wanted to add an option to the theme options page utilizing the themeblvd_add_option function.
You could not simply place it within your plugin’s file like this:
themeblvd_add_option( 'tab_name', 'section_name', 'my_option', array() );
If you did the above, you’ll get a big, fat undefined function PHP error. So instead, you’d need use it within another function that you then hook in at after_setup_theme like this:
function my_options(){
themeblvd_add_option( 'tab_name', 'section_name', 'my_option', array() );
}
add_action('after_setup_theme', 'my_options');
Action Hooks
The last section was fairly straight-forward, as obviously if a function doesn’t exist yet, you can’t call it. However, in dealing with action hooks, this might take an extra moment of thought to consider what’s happening.
Our theme framework contains a very wide range of actions hooks for you to utilize. All of the framework’s core functionality is hooked on in some way in order to give you complete control. The thing to consider here when working within your plugin file is that since the theme framework hasn’t been loaded yet, it hasn’t actually hooked anything yet.
So, while you could add an action, you cannot technically remove any of them just yet. So, to modify one of the framework’s default action hooks, you’ll need to make sure and include your modifications in a function hooked to after_setup_theme, as well.
Let’s consider an example. — Say you’ve made a plugin that creates a new breadcrumbs function. Since the theme framework already has one hooked to themeblvd_breadcrumbs, you’ll need to first remove the default breadcrumbs function, and then hook in your own.
So, you could not do this:
function my_breadcrumbs(){
// show my breadcrumbs ...
}
remove_action( 'themeblvd_breadcrumbs', 'themeblvd_breadcrumbs_default' );
add_action('themeblvd_breadcrumbs', 'my_breadcrumbs');
If you simply did the above, you’ll essentially just end up with is two sets of breadcrumbs, first your function and then the framework’s function. The reason is because you added your action properly, but at the time you removed the framework’s function, it hadn’t actually been added yet.
So, instead, this is how you’d accomplish the task:
function my_breadcrumbs(){
// show my breadcrumbs ...
}
function my_hooks(){
remove_action( 'themeblvd_breadcrumbs', 'themeblvd_breadcrumbs_default' );
add_action( 'themeblvd_breadcrumbs', 'my_breadcrumbs' );
}
add_action('after_setup_theme', 'my_hooks');
Filters
As with actions, the same thing needs to be considered for filters, although this will come up much less often.
More often than not, you will be adding a filter, opposed to removing one. So, if you’re adding a filter, it can go whereever you want within your plugin. However, if you’re removing a filter, you’ll need to make sure your instance of remove_filter() comes from within a function hooked somewhere after the theme has been loaded, similarly to the examples we covered previously.
Conclusion
If you’re working solely from your child theme, you don’t really need to worry about what’s discussed in this article. However, if you do decide to incorporate customization tactics, discussed throughout this website, from a custom plugin you’re creating, you’ll want to consider the things discussed here.