The best thing about WordPress and WooCommerce is that the code and content on your site is yours to change in whatever way you want – you can modify and customize your website entirely. The flexibility this gives you is one of the greatest benefits to using WooCommerce to sell online. Plugins, extensions, and themes can be used to get a lot of the functionality you require, then you can make adjustments or add code to tailor the look and functionality of your site to your needs.
However, there are some best practices that should be followed when you make these site tweaks, and it’s not always obvious how these changes should be made. Unfortunately, there are some common missteps that will lead to headaches down the road that we’d like to help you avoid.
Why Follow Best Practices
↑ Back to topSome lessons are unfortunately learned the hard way. I first started to learn how to make modifications to my WordPress site on my own personal blog. I was really excited when I realized that I could tweak the styling and some of the functionality of my site, and learned a lot by changing (and breaking!) my own site.
Like many WordPress users, I started making changes to my theme’s stylesheet and to the functions.php
file in my theme since that’s what most articles or resources I found recommended. However, I learned one very important lesson when an update was released for my theme.
I clicked that magic “Update” button to unlock the goodness that a new version brings. Instead of the satisfaction that comes from getting new things, I felt like my stomach dropped through the floor. All of the changes I’d made had been lost. Poof. Gone. Updating the theme overrode all of my styling and functionality changes.
I learned from this lesson pretty quickly, and started to use child themes (there are also good instructions on child themes here). However, even though using a child theme is light-years ahead of modifying a theme or plugin directly, there are some things that don’t belong in a child theme either.
When you switch themes in the future, you’ll lose the functionality that’s contained in a child theme, and migrating this custom code over to a new theme can be a pain. We should decide what belongs in the child theme and what doesn’t, then find a better place to put some of our custom code.
Making Site Changes
↑ Back to topAs I mentioned, a child theme is a great starting point for site changes, but this isn’t the only place you should add custom code. In fact, it isn’t even always the best place to do so.
There are two major types of changes you typically make to your site: changes that affect the way it looks, and changes that affect what it does. These are usually treated the same way, but shouldn’t be. Each change should belong in a different place.
How to Tell The Difference
↑ Back to topLet’s say you’ve found a code snippet that changes the way WooCommerce does something – is that snippet independent of your theme? Should that change always be around, even if you change themes in the future? That’s a clue that it doesn’t belong in your child theme’s functions.php
.
For example, someone once asked me how to remove the Product SKUs from the single product page. This is a change that should be around even if the theme changes, so it’s something we want to add in a different way rather than adding it to the theme.
The only changes you want to put in your functions.php
are changes that are related to your theme. For example, let’s say you change the number of related products displayed on a product page. This change shouldn’t go with you to a different theme, as chances are your new theme will handle the number of related products in a different way and you may not need this code.
Changes that relate to the theme itself and change the way your site currently styles options are the ones that actually belong in a functions.php
file.
The Right Tool for the Job
↑ Back to topLike our SKU sample above, changes that should be theme-independent belong somewhere besides the theme. You can create a custom site plugin for this, but one of my favorite tools to use is the Code Snippets plugin. This plugin lets you add snippets to your site, write a brief description so you know what it does, and activate or deactivate these snippets as needed.
![Code Snippets Plugin](https://i.cloudup.com/gkv0ivP7wu.png)
I actually use this plugin myself for any custom shortcodes I create for my site, as I want them to be around if I ever switch themes in the future.
Your child theme’s functions.php
can be used for the changes that don’t fit this bill. I use my own functions.php
for a snippet that highlights comments from our authors at Sell with WP.
Since a new theme would probably require a different styling to achieve my comment highlights, this change should stay within my theme, and not within a custom plugin or the Code Snippets plugin.
This would also work for the “related products” example above, as it’s changing the way my theme displays WooCommerce options.
![Using Child FunctionsPHP](https://i.cloudup.com/GFXtypOfcM.png)
What if I bought a child theme?
↑ Back to topLet’s say you bought a child theme, such as a Canvas child theme or a Genesis child theme. You also may have downloaded a child theme from WordPress.org or purchased one from another site.
Chances are that these child themes aren’t updated frequently (since they’re mostly just styling), but you may still be uncomfortable adding code to these themes. You can’t make a “grandchild” theme (yet!) for these, so changing a child theme that can be updated poses the same problem as changing a parent theme – you could lose your custom code.
In cases like these, I usually recommend using the Code Snippets plugin as well, but prefixing your snippet name with Theme-ThemeName
. This way, you know to deactivate these snippets when you change themes, then only re-enable or edit them if needed.
Conclusions & Further Reading
↑ Back to topChanges that should always affect your site, regardless of your theme, don’t belong within your theme. They should be added as a custom plugin or within the Code Snippets plugin (which is far easier to use). This also helps with debugging, as you can simply deactivate custom snippets to rule out code conflicts (yes, these do happen!).
Changes that are specific to the way your theme displays or styles components should be contained in the theme’s functions.php
. Just be sure to use a child theme!
If you’d like to learn more about using Code Snippets or creating a child theme, you can check out this tutorial for some tips. Another WooThemes blog post also has some handy WooCommerce customization tips from WooNinja Remi Corson.
About
Useful article, is this going to get placed in the woocommerce documentation?
In my view, the correct place for such customisations is as an mu-plugin (i.e. a .php file in wp-content/mu-plugins). These are always run, and you can have as many as you like. Plus, you’re not dependent upon another plugin to help you manage them.
Really informative and hit home in a number of places.
Thanks again for sharing.
Excellent and useful article – this came at just the right time as I’m developing several WooCommerce sites right now!
Happy we could help!
Hi Beka a great article, If I have the following code snippet
add_filter(‘avf_title_args’, ‘fix_page_title’, 10, 1);
function fix_page_title($args) {
$args[‘title’] = get_the_title();
$args[‘link’] = get_permalink();
return $args;
}
How do I change it, so that it only affects the titles of woocommerce products. Help is much appreciated.
Hi Kevin,
You can try this:
“`
add_filter(‘avf_title_args’, ‘fix_page_title’, 10, 1);
function fix_page_title( $args ) {
if ( function_exists(‘is_product’) && is_product() ) {
$args[‘title’] = get_the_title();
$args[‘link’] = get_permalink();
}
return $args;
}
“`