Since WooCommerce is self hosted and self maintained software it has earned somewhat a reputation for ongoing maintenance. The degree of maintenance will vary widely. I strive to build WooCommerce powered sites to be as low maintenance as possible, but there is some maintenance responsibility. I often work on catch-up projects applying neglected maintenance and strengthening that foundation for the future.
WordPress and WooCommerce have major releases that require basic testing on each site. The WordPress team releases a major WordPress version every 3-4 months while the WooCommerce team releases a major WooCommerce version every 1-3 months. Themes and plugins have their own release schedules and upgrade risks.
With WordPress 5.5 that released yesterday we now have automatic updates on a per plugin basis within the core software. Previously one had to enable automatic updates for all plugins inside their hosting control panel setting, via a plugin or a custom function / snippet.
Automatic updates is a great feature, but some third party plugins introduce wonky licensing and update services that may not be compatible with automatic updates. I’ve had situations where one plugin can wreck automatic updates on the entire site. Removing or replacing plugins (or a theme) with wonky licensing is one of my priorities for maintenance reduction.
Before enabling automatic software updates I highly recommend getting the site cleaned-up and running quality components. Official extensions and framework tools work well. Many popular community plugins can be fine. While technically no plugins can be safely updated without prior testing, it’s exceedingly rare for a well vetted (popular, well supported) component to cause serious trouble.
I always enable automatic updates once I feel a site is clean and ready. I don’t want to waste clients time and money performing mundane, regular work just for minor updates. The only manual work should be applying major core releases after having tested them in a staging environment, which itself is included with modern managed hosting.
In another recent post I described what a typical plugin does. Spoiler alert – it’s 195 things each. Plugins are most often the culprits leading to update maintenance. Many cause database clutter, especially when the plugin is removed and it leaves behind a lot of useless settings and caches in the database.
Begin by reducing your plugin volume to 25 or less. Decide which ones can be replaced with simpler code snippets or better, perhaps more official or popular frequently updated community repository alternatives.
It’s the Pro plugins from unofficial sources that I worry the most about because they can be less vetted and try to do more things, a larger feature set to help their sales, which means greater exposure.
Templates overrides and theme files
I discussed the problem with forking WooCommerce template files in last year’s blog post Why you should avoid WooCommerce template overrides. Whenever I get a site that has a custom theme or child theme I almost always find these files and there’s almost always a few of them flagged as out of date. I’ll either plan to replace the theme or move the customizations over to PHP code to alleviate the ongoing maintenance work back-merging template files from core updates.
The smaller your custom code is, the better it will be for ongoing maintenance.
Cleaning the database
As mentioned in my post Big WooCommerce stores, WordPress and WooCommerce continually improve the database structure for performance. It’s important to run quality managed hosting that runs the latest database server software, optimizes table storage engine InnoDB, and monitors performance for any problems.
Over time WordPress and WooCommerce sites will accumulate junk in the database. The wp_options table is the most important one to clean. See my earlier post for details on that and WP Optimize. It accumulates old plugin settings and some autoload data that chews-up memory.