Available for projects & agency overflow · Quick reply, from the person who does the work

Send a message contact@allaux.fr
FR EN TR
allaux.
Emergency Discuss my project

Checking plugin compatibility before an update

Before clicking "update", I want to know what’s likely to break. Three sources exist: the compatibility flag shown in the admin, the plugin’s last-updated date on the WordPress.org directory, and a test on a clone of the site. Only the third gives a reliable answer.

Describe my issue Send a message

What "tested up to" actually means

Under Plugins > Installed Plugins, each plugin shows a line such as "tested up to WordPress 6.7". This is useful but misleading if taken as a guarantee: it’s a claim the plugin author has entered in their own readme.txt file, not an automated check run by WordPress.org. An author can declare compatibility without having actually tested the latest release against the new WordPress version, or simply leave the field unchanged even though the code works fine.

The second source, the plugin’s last-updated date on its WordPress.org directory page, is a better long-term risk indicator than an immediate compatibility signal. A plugin untouched for over a year isn’t necessarily broken, but the lack of active maintenance increases the odds that an issue will never get fixed if the new WordPress version changes a behaviour that plugin relies on.

The only genuinely reliable check remains testing on a copy of the site, under the same conditions as production: same active plugins, same theme, same data. That’s the only way to catch a plugin crashing, a white screen appearing, or a form breaking before it happens to a visitor.

Where incompatibilities most often show up

  • Payment plugins calling a WordPress or WooCommerce core function deprecated in the new version
  • Plugins that intervene in the checkout (extra fees, custom fields, shipping modules)
  • Plugins abandoned for years, still active only because they’d kept working so far
  • Premium themes edited directly, whose custom code has never faced the new version
  • Plugins loading their own JavaScript that conflicts with a library updated by core

How I check before an update

  1. List the plugins actually active

    I start from what’s activated in production, not everything installed. A plugin disabled long ago isn’t worth checking.

  2. Cross-reference the declared compatibility status

    For each active plugin, I note the "tested up to" line and the last-updated date on WordPress.org. That’s for prioritising, not deciding.

  3. Prioritise the sensitive plugins

    I test payment, checkout and authentication first: these are the functions where a failure blocks a sale, not just a display glitch.

  4. Test on a clone of the site

    I duplicate the site (files and database) onto a test environment, apply the update there, and walk through the critical journeys before considering production.

  5. Update production once the clone is validated

    This is the point of no return: once the update is applied to production without the clone having been validated, rolling back means a full restore rather than a single click.

Related pages

Describe your need in one minute

A few targeted questions so I can reply with an estimate rather than another questionnaire.

origine
catalogue
extensions-premium (facultatif)
conserver (facultatif)
Please provide an email or a phone number so I can get back to you.

Please provide an email or a phone number so I can get back to you.

Frequently asked questions

Is the "tested up to" flag enough to update without testing?
No. It’s a claim entered by the plugin author in their readme, not an automated check. It’s for prioritising checks, not for replacing a test on a clone.
Is a plugin untouched for a year necessarily incompatible?
Not necessarily, but the lack of active maintenance raises the risk that an issue introduced by a new WordPress version never gets fixed. It’s a signal to watch, not proof of failure.
Do I need to test every active plugin before each update?
I prioritise plugins touching payment and checkout, where a failure blocks a sale. Purely cosmetic or secondary plugins can be checked faster.
How long does this check take?
It depends on how many plugins are active and how complex the checkout is. A site with few plugins can be checked in a few hours; a shop with custom payment and shipping modules needs more functional testing.
What if a critical plugin turns out incompatible on the clone?
I first look for an update to that plugin itself, then an equivalent alternative if it’s abandoned. Updating core without resolving the incompatibility first isn’t an option on a live shop.

Related pages