Before updating a business website, identify which versions must work together and which customer tasks depend on them. Check the release notes and requirements for the proposed change, make sure a recoverable backup exists, and test the important journeys on a representative staging copy. A compatibility label is useful evidence, but it cannot prove that every combination of plugins, settings and external services will work.
Start with the change and its dependencies
List the current and proposed versions of WordPress, PHP, the theme and plugins involved. For an online shop, include the shop software, payment and shipping extensions. A page builder may have separate add-ons and a theme that depend on it. Record who supplies each component and where its release notes and support information live.
Check the supplier’s stated minimum requirements and any specific compatibility notices for the intended versions. Look for changes to the functions your site actually uses, such as a form integration or checkout extension. Check whether a premium licence still provides updates and support. If a dependency has been abandoned or cannot support the proposed version, identify a supported route before changing it.
For a practical version map, put each component on a separate line: current version, proposed version, required WordPress and PHP versions, and the supplier’s evidence. Add a “depends on” note for extensions that require a particular shop plugin or page builder. If a payment extension supports the planned shop version but the shop version requires a newer PHP release, both requirements have to be resolved before the proposed combination is ready. Ask the host which PHP versions are available and check every affected component, not only the one showing an update button.
Release notes deserve a closer look when they mention a database upgrade, a removed feature or a change in an integration. Ask whether the data migration is reversible and whether the previous plugin version can still read the upgraded data. Reinstalling older files is not necessarily equivalent to restoring a matching database. If the supplier cannot establish a safe route, document the unknown and seek a supported plan before applying that change.
“Untested with your version” means the published compatibility information does not confirm that combination. It is a reason to investigate and test, not proof that the plugin is broken. Conversely, a stated compatible version does not test your own configuration.
When the information is incomplete, look at the supplier’s documentation and support channel for the exact version pair and note the date of the evidence. If there is no answer, test the proposed combination on staging and ask the maintainer to assess the result. If the functionality cannot be exercised there, record that gap in the release decision rather than labelling the update fully tested.
Choose what to test from business impact
An update to a visual theme needs checks beyond the homepage. Inspect representative templates, navigation, mobile layout and any custom design elements. For an enquiry site, follow the form through to the expected confirmation and verify the intended notification using an agreed safe test. For a shop, include a provider-supported test checkout, stock and order status, and the integrations on which fulfilment relies.
Write the expected result before testing. “The button opens” is weaker than “a visitor can select a service, submit the agreed test and see the correct confirmation.” Record a failure with the steps, versions and screen affected. Test external services in their supported test mode and prevent staging from sending real customer messages.
Decide the order and keep a recovery route
Check whether the supplier specifies an update order for dependencies. On staging, make a controlled change and repeat the relevant tests so the team can identify which change introduced a problem. Keep a current, retrievable backup of files and database and know who can restore it. A rollback or restore can affect data written since the backup; agree how recent orders, bookings and enquiries will be protected before any live recovery.
A security update may need prompt attention. If a compatibility issue prevents the normal route, discuss a temporary mitigation and supported fix with the maintainer or provider; leaving a vulnerable component unchanged indefinitely is not a plan. If the change is safe on staging, schedule its live release with an owner and a way to verify the customer journey afterwards.
When a test fails
Record the exact symptom, change and versions, then isolate the cause on the copy. A conflict may involve two components or a setting, and a staging environment can differ from live. Avoid deleting a plugin merely because it appeared near the error: it may hold settings or data needed by the business. Ask the supplier or maintainer about the supported fix, and repeat the affected task after the remedy.
Our staging guide covers creating the test environment and releasing changes safely. If you need help planning a WordPress website or its handover in Formby, Freshfield or L37, contact Formby Web Design to discuss what support is appropriate.
Further reading: WordPress plugin management.
