Extending WooCommerce: Custom Plugin or Snippets?

• A setting. Check whether WooCommerce or an existing extension already does it. A surprising amount of custom code exists because nobody looked.
• A hook or filter. WooCommerce has an enormous number of them, and code that hooks in survives updates cleanly.
• A template override, copied into your theme. Necessary sometimes, and it comes with an ongoing maintenance cost.
• Editing WooCommerce's own files. Never. The change disappears at the next update and you won't remember it was there.

When you override a template, you copy a file from WooCommerce into your theme. From that moment, your copy is frozen: WooCommerce's improvements, bug fixes and security patches to that file never reach you.

WooCommerce helpfully tells you when an overridden template is outdated, under Status → Templates. On stores that have been running a few years, that list is often long and nobody has looked at it.

A hook has none of that. You attach a function to a documented point, WooCommerce keeps improving the surrounding code, and your change keeps working.

So before copying a template, look for the hook. Woo's templates are dense with action hooks precisely so you rarely need to copy them — a great many overrides exist only because the developer didn't know the hook was there.

The same applies to removing output. Rather than copying a template to delete a section, find the action WooCommerce used to add it and remove that action.

The subtlety is timing: you have to remove the action after it was added, which usually means hooking your removal on init or later rather than running it at the top of your file.

This is one of the highest-value techniques on a Woo store, because most customisation requests are 'remove this thing' rather than 'add something'.

Not in the theme's functions.php. This is the rule that matters most, and the one broken most often.

A store's customisations are business logic: the checkout fields you collect, the rules about what can be bought, the integration with your courier. If a redesign would break the checkout, the code is in the wrong place.

Put it in a site-specific plugin — a folder in wp-content/plugins with a name like yourstore-customisations, a plugin header, and files organised by concern. It takes five minutes to create and it makes the theme genuinely replaceable.

The exception is genuinely presentational code: enqueuing the theme's styles, a template part the theme provides. That belongs in the theme.

Plugins that let you add PHP snippets through the admin are popular, and they're a mixed blessing.

The good: no FTP, no deploy, and a non-developer can add a snippet from a tutorial. For a store with no developer, that's genuinely useful.

The bad: the code lives in the database, so it isn't in version control, doesn't deploy between environments, and can't be reviewed in a pull request. Staging and production drift apart. And a syntax error in a snippet can take the site down, though better snippet plugins guard against that.

The security dimension matters too: a snippet plugin means any administrator can execute arbitrary PHP through the dashboard, which is a significant escalation if an account is compromised.

My position: fine for a store without a developer, or for a quick diagnostic. Not where a store's real business logic should live long-term.

• Copy it to your theme keeping the woocommerce/ path exactly, or WooCommerce won't find it.
• Record which WooCommerce version you copied from, in a comment at the top.
• Change as little as possible, so diffing against a future version is easy.
• Check Status → Templates after every WooCommerce update, and diff the ones flagged as outdated.
• Revisit periodically to see whether a hook has since been added that would let you drop the override.

• Adding a checkout field: hooks, in a site-specific plugin. There are filters for the fields array and actions for saving and displaying the value.
• Changing the 'Add to cart' text: a filter.
• Hiding a payment method under some condition: a filter on available gateways.
• Changing the number of products per row: usually a theme setting or a filter, not a template.
• Restructuring the product page layout: this is where template overrides become genuinely necessary.
• Custom pricing rules: hooks, and carefully — price filters run often and cheap code matters.
• An integration with a courier or an ERP: a plugin, queued and retried, never inline in the order process.

The worst thing about store customisations is not that they break — it is that nobody can find them when they do. A price behaving oddly, with the reason three layers deep in a filter somebody added two years ago, is a genuinely expensive afternoon.

• One file per concern inside the plugin: checkout.php, pricing.php, shipping.php, integrations.php. Not one 2,000-line file.
• A comment above each customisation saying what it does and, more importantly, why it exists. The business reason is the part nobody can reconstruct.
• Keep the plugin in version control, so the history says when a rule changed and what it replaced.
• Note anything that depends on a specific extension, so removing that extension does not fail silently.
• Keep a short readme listing the customisations in plain language. It is the first thing a new developer asks for and the thing that is never written.

Store code touches money, so test it more carefully than you would a content site.

• Test on staging with a copy of real product data, not three test products.
• Test the whole purchase flow after any customisation that touches cart or checkout.
• Test as a logged-out customer, a logged-in customer and an administrator — behaviour differs.
• Re-test after every WooCommerce update, because hooks do occasionally change.
• Keep customisations small and separable, so one can be disabled without unpicking the rest.