Updates, backups and roles

Module 6: Management and security · Reading time: 11 minutes

Learning objective: After this lesson you can update and back up a WooCommerce shop without losing orders, and divide rights so that everyone can only do what they need to.

Key concepts: major and minor update, database update, extensions and compatibility, template overrides, outdated templates, backup before the update, orders between backup and restore, HPOS tables, the roles Shop manager and Customer, least privilege, showing versions, xmlrpc.php

Why a shop is different from an ordinary site

The WordPress course (lessons 7.2, 8.1 and 8.2) explains how to update WordPress, how to make backups and how to restore them. All of that applies to a shop too, with one big difference: the database changes all day long. Every order, every customer, every stock change and every payment goes into it. On an information site, restoring yesterday's backup costs you at most one post. On a shop, you lose orders that have already been paid for.

So there are two rules of thumb for this lesson:

1. In a shop, restoring is the last step, not the first.
2. Update with a plan, not "quickly in between on a Friday afternoon".

WooCommerce updates

WooCommerce releases new versions regularly, with small fixes in between. The version number has three parts, such as 11.2.2. A change in the last number is a small fix or security update; a change in the first or second number brings new features and sometimes changes that extensions or your theme have to adapt to.

Three things happen during a WooCommerce update that you see less often with an ordinary plugin:

• A database update. Sometimes WooCommerce has to adjust its tables. You then see a notice in the dashboard that the database is being updated; this runs in the background via the scheduled actions (lesson 7.3). Don't interrupt it, and check under WooCommerce > Status whether it has finished.
• Extensions have to keep up. Payment plugins, shipping integrations and accounting integrations state which WooCommerce version they have been tested up to. The plugins screen shows a warning if an extension doesn't mention a newer version. Read the changelog of your payment plugin before you update: a payment plugin that breaks means a shop that doesn't sell.
• Template overrides. Many themes have their own copies of WooCommerce templates (the woocommerce/ folder in the theme). If WooCommerce changes the original, the copy becomes outdated. Under WooCommerce > Status (System status), the theme section at the bottom shows which templates it overrides and which are outdated. Outdated templates may lack new fields or cause errors. Update the theme, or ask its developer for an update.

Install minor updates (last number) quickly, preferably automatically, because they often fix security flaws. Test major updates on staging first (lesson 7.3), at a quiet moment, with a backup made just beforehand.

Backups: what disappears when you restore

An example. Theehuis Example makes a backup every night at 03:00. On Tuesday at 10:00 the administrator updates WooCommerce, and afterwards the product page shows an error. Between 03:00 and 10:00, six orders came in, paid via the payment provider. If you now restore the 03:00 backup:

• those six orders have disappeared from the database, while the money is still with the provider;
• the shop no longer knows that stock is lower;
• the shop may later still receive notifications (webhooks) from the provider about orders it doesn't know.

Therefore:

• Make a backup just before an update, not only at night. That keeps the gap as small as possible.
• When restoring, note which orders came in after the backup (from the "New order" emails and your provider's dashboard) and re-enter them by hand afterwards, or export them beforehand.
• Preferably restore only the files (the old plugin or theme folder) if the problem is in the code, and leave the database alone. You can often roll back an update by installing the previous version of the plugin; the WordPress course, lesson 8.2, shows how to restore selectively. If the update has already updated the database, the old version may no longer work with it: that's why you test on staging first.
• Back up more often than for an ordinary site: a shop with orders all day long needs a database backup at least daily, preferably more often, plus a copy off the server (3-2-1 rule, WordPress course lesson 8.1).

Since WooCommerce 8.2, new shops store orders in their own tables (HPOS, lesson 1.2), such as wp_wc_orders. A backup plugin that only includes "posts" or selects tables by name must include these tables too. During a restore test (WordPress course, lesson 8.2), check that the orders really are in it.

At WebOké, WebOké Backups makes a backup every night, kept for 30 days in another data centre (DA 16.1); in addition, you can make your own backup in DirectAdmin or Installatron before an update. Other hosts work in a similar way; ask how often and for how long.

Roles: who can do what

WooCommerce adds two roles to WordPress (WordPress course, lesson 3.3):

• Customer: a customer with an account. Can only see their own orders and details. Never give this role admin rights.
• Shop manager: can manage products, orders, customers, coupons and the WooCommerce settings, but cannot install plugins or change the theme.

For staff who pack orders, answer customer questions or enter products, Shop manager is enough. Administrator is only for whoever handles the technical side. Give every staff member their own account, with two-factor authentication (WordPress course, lesson 7.3); no shared "shop" account. A shop manager sees all customer data, so remove accounts when someone leaves.

API keys (lesson 2.4) are a form of rights too: give an integration read-only access if it doesn't need to write anything, and delete keys that are no longer used.

What your shop shows to everyone

Attackers look for shops running an old version of WooCommerce or a payment plugin with a known vulnerability. By default WooCommerce puts a line <meta name="generator" content="WooCommerce 11.2.2"> in the source code, and the version also appears after stylesheets (?ver=). Hiding it is a small gain; updating is a big one. A shop that is properly up to date has little to worry about from a visible version number. A shop that lags behind gives itself away.

The file xmlrpc.php is an old interface that apps use to log in to WordPress. It is widely abused to guess passwords. If you don't use an app or service that needs it, close it (at WebOké it is closed by default, KB 169). An open xmlrpc.php responds to an ordinary browser request with "XML-RPC server accepts POST requests only." and status 405. Closed gives 403 or 404.

Summary

• A shop database changes all day: restoring costs you orders that have already been paid.
• Minor updates quickly, major updates on staging first; watch the database update, extensions and outdated templates under WooCommerce > Status.
• Back up just before an update and more often than for an ordinary site; check that the order tables are included.
• Staff get Shop manager, not Administrator; each with their own account and two-factor authentication.
• Hiding versions helps little, updating helps a lot; close xmlrpc.php if you don't use it.

Quiz

Exercise

Exercise A6.2: Does your shop show version numbers? Enter your shop's address, your WordPress version (Dashboard > Updates) and your WooCommerce version (Plugins). The program requests the homepage and the feed, and the file /wp-content/plugins/woocommerce/readme.txt (only the first 2 kB, the "Stable tag" line). It looks for WordPress and WooCommerce version numbers in the generator lines and after ?ver= on the WooCommerce stylesheets, and fetches the latest versions from wordpress.org. Green if your versions are the latest and what is visible matches them. Orange if only a minor update is pending, or if the version is visible but up to date. Red if you are a major version behind, if the visible version differs from what you entered (something else is running than you think), or if the input is invalid.

Exercise A6.2b: Is xmlrpc closed? Enter your shop's address and tick the box if you use an app or service that needs xmlrpc.php. The program requests /xmlrpc.php with an ordinary GET, without sending anything. Green for 401, 403, 404, 410, a redirect or an ordinary HTML page. Red for 405 with the text "XML-RPC server accepts POST requests only." without the box ticked; orange if you indicated that you need it. It also checks whether the list of usernames via /wp-json/wp/v2/users is public (orange if names are visible).

A green tick means this check is correct right now, not that your shop is secure.

Further reading

Steps in a control panel apply to WebOké; other providers work in a similar way.

• Free WordPress course 7.2: Keeping updates on track
• Free WordPress course 8.1: Backups: what, where and how often
• Free WordPress course 8.2: Restoring and testing
• Free WordPress course 3.3: Users and roles
• DirectAdmin guide 16.1: Which backups are available at WebOké
• WebOké Backups: viewing, restoring, or downloading a backup
• WordPress xmlrpc.php access not working
• High Performance Order Storage (developer.woocommerce.com): https://developer.woocommerce.com/docs/features/orders/high-performance-order-storage/