Order for updating WordPress, WooCommerce, plugins, themes and PHP

The update order must respect the dependencies and requirements of the specific versions. There is no universal sequence that guarantees compatibility on every website. Prepare the set of changes, rehearse it and repeat the tested procedure in production.

Before updating: essential preparation

Make a full backup

Keep files and database from a recoverable point before the change. Check the date, scope and recovery of the hosting backups. A daily backup may predate the latest orders; it is not the same as a backup taken immediately beforehand.

You can create an on-demand backup from WordPress Manager or another compatible tool. Check where it is stored and how much space it takes up; some plugins support external destinations.

Consider creating a test clone

Test the set on a protected clone, with test email and payments. Check that it uses its own data and integrations. A successful test reduces uncertainty, but it does not guarantee that production will behave the same if its data or configuration change afterwards.

The right update order

1. Check requirements and set the target PHP version

Note the current and target versions of WordPress, WooCommerce, extensions, theme and PHP. Review requirements and upgrade notes. If a component needs an intermediate version, add that step to the rehearsal.

Do not raise PHP first as a matter of routine. Update the components compatible with the current interpreter and change PHP when the whole set supports it. For very old branches, follow the staged update path.

2. Update the WordPress core

Use Dashboard > Updates when the compatibility matrix allows the jump. If a plugin needs an earlier update to work with the new core, respect that dependency. Wait for it to finish before starting another task.

Updating fixes known problems, but it does not make the whole installation secure or check every plugin. Review the result and keep any error notices that appear.

3. Update WooCommerce

Rehearse WooCommerce together with its extensions and gateways as a compatible set. In production, use a controlled window that avoids purchases during code and data changes.

If WooCommerce asks to update the database, complete that step and check its progress in the scheduled actions. Do not consider the update finished just because the plugin version changed. The official WooCommerce guide explains this process.

4. Update plugins directly related to WooCommerce

Check the compatibility of payments, shipping, taxes, invoicing and integrations. Keep to the rehearsed sequence; do not enable an extension that requires a core version not yet installed. An available update does not prove compatibility with your whole configuration.

5. Update the theme

Review overridden templates and customisations. A child theme helps keep changes separate, but it may need adapting when the parent is updated. Do not assume every customisation will keep working.

6. Update the remaining plugins

Include page builders, forms, SEO and cache. Update in identifiable steps so you can link a fault to the specific change. Check dependencies between free versions and commercial add-ons.

7. Update the translations

Install the available packs and check important texts in forms and checkout. If you have your own translations, find out where they are stored so an update does not replace them.

8. Switch PHP to a current, compatible branch

Change the clone's PHP first and check extensions and configuration, not just the version. Repeat the tests before applying it to production. See the PHP selector to select the domain and review the result.

Checks after updating

Check site health

Review Site Health, pending updates and failed tasks. A good status does not replace business testing.

Browse the main pages

Test the home page, search, products, cart, forms and user login on mobile and desktop. In the shop, complete a purchase with a suitable test method and check confirmation, stock, taxes, email and callback. Reaching the screen before payment does not prove order confirmation.

Check the admin area

Check editing, orders, file uploads and the integrations the team uses. Purge the relevant caches and check a fresh session and a logged-in one.

Review the error logs

Match the time and operation with PHP, WordPress and scheduled tasks. If you need debugging, keep the log private and turn it off when you finish.

What to do if something goes wrong

Identify the problematic component

Stop making changes and keep the error. Test reverting or selectively deactivating on the clone. Deactivating a plugin manually can restore access, but it can also stop payments or features: do not deactivate everything indiscriminately on an open shop.

If the fault persists, also review the theme, PHP, files and database; do not conclude the theme is to blame just because you deactivated plugins.

Restore from a backup

Decide which consistent set of files and data you need to recover. Some updates change the database and are not reverted just by replacing the plugin. Identify writes made after the backup and how to keep them before restoring.

Validate the recovery before reopening the shop. Investigate the incompatibility in staging and schedule another attempt once the set has passed the tests.