# 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.

- Source canonique : [https://allaux.fr/en/wordpress-woocommerce/mise-a-jour/verifier-extensions-avant-mise-a-jour](https://allaux.fr/en/wordpress-woocommerce/mise-a-jour/verifier-extensions-avant-mise-a-jour)
- Langue : EN
- Dernière mise à jour : 2026-09-30

## Direct answer

> Open Plugins, Installed Plugins and note, from each plugin page on the WordPress.org directory, the “Tested up to” line and the date of the last update. Both are declarative: they rule out the obvious cases, they prove nothing. The only check that counts is a clone of the site where you apply every update and then walk through the full checkout flow.

## 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.

## The directory flag isn’t a test

> "Tested up to X.X" is a claim made by the plugin’s author, not an automated check. Use it only to prioritise your testing, never to decide to update without testing.

## Related pages

- **Duplicating a WordPress site into staging** — The full method for building a faithful test clone before any work. ([/wordpress-woocommerce/migration/dupliquer-en-preproduction](/wordpress-woocommerce/migration/dupliquer-en-preproduction))
- **Updating WordPress to a major version** — What actually breaks during a major version jump, beyond plugin compatibility alone. ([/wordpress-woocommerce/mise-a-jour/version-majeure-wordpress](/wordpress-woocommerce/mise-a-jour/version-majeure-wordpress))
- **Restoring a site after a failed update** — The method for getting back to a working state if a plugin breaks despite the checks. ([/wordpress-woocommerce/mise-a-jour/restaurer-apres-mise-a-jour-ratee](/wordpress-woocommerce/mise-a-jour/restaurer-apres-mise-a-jour-ratee))
- **Backing up a shop before any intervention** — What to back up, and how, before touching a single file. ([/guides/sauvegarder-boutique-avant-intervention](/guides/sauvegarder-boutique-avant-intervention))

## FAQ

### 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.