Most of the customization of WooCommerce is achieved with your design and content, WooCommerce settings, and your usage of the official WooCommerce extensions*. Beyond that, you may find yourself in search of a more unique or custom solution. After all, customizability is a huge selling point of WooCommerce as an eCommerce platform.
Custom functionality belongs in custom plugins that create a thin layer of customization to meet the needs of your shop.
You also have the option of developing code inside your child theme. This is acceptable, though I recommend just making a plugin from the outset. It’s best to keep your child theme just that – global design customizations and CSS overriding your main theme or framework.
Avoid forking WooCommerce templates! It’s very tempting to copy a default WooCommerce template into your child theme and modify it there. If you do that, you’re taking on a perpetual maintenance item to maintain (code speak: back-merge) your copy with all future releases of WooCommerce. Have a look at the WP Admin > WooCommerce > Settings > Status page to see if you already have this problem. The only time I’d recommend adding this overhead is when you’ve found no suitable hooks and you are overriding the template solely to add a custom hook for further use by your custom plugin.
One plugin should add only one service to WooCommerce. Your feature may be comprised of many logical functions, but offers no more than one essential feature you would expect to activate or deactivate on a given site. If the feature is more complex, be sure to add a settings panel to toggle each element, as this will be essential to debugging down the road. While there are many tools available for debugging web applications, in WordPress and WooCommerce the convention is deactivating and reactivating plugins or toggling settings to pinpoint issues.
The simpler you make your plugin, the easier it will be to regression test it with the constant development of WooCommerce, WordPress, your theme, child theme, and other plugins and extensions.
Somebody always does the testing – your developer, yourself, or your end users. Go easy on your testing resources and keep things as straightforward and predictable as possible.
A note to enterprise users: In these architectures, your code base (your lot of theme, child theme, plugins and extensions) becomes a middle layer for an upstream used to feed many sites. Each feature / plugin must therefore be discrete to support variations amongst your properties.
Similar to developing plugins for WordPress CMS, developing plugins for WooCommerce uses the native hook / action and filtering API to make extending the platform easy yet highly interoperable. You are likely to use WordPress and WooCommerce native hooks, possibly even existing plugin or extension hooks as well, and in rare cases even defining your own.
Here’s some examples of areas we tend to customize in WooCommerce using code:
- Checkout form fields – adding, removing, or relocating them
- Checkout page design – moving things around a bit
- Modifying button copy
- Payment gateways – adding custom gateways or features like Apple Pay, subscriptions / memberships, refunds, or fraud management features to existing gateways
- Integrations with additional shipping / carriers or warehousing management systems
- Integrations with marketing services such as analytics, mailing lists, product ratings / social proof, abandoned carts, customer loyalty programs, split testing tools and conversion trackers
- Orders custom fields – customer facing or administrative
- Product custom fields – customer facing or administrative
- Changing standard behavior, such as having the add-to-cart action redirect to the Checkout page instead of the Cart page
- Adding or removing sections from the My Account dashboard
- Adding dynamic widget sidebars
- Adding custom reporting for Shop Managers
- Adding short codes to display dynamic content or functionality onto other pages or posts, such as landing pages
- Automating routine business operations
