Plugin compatibility is not a one-time spreadsheet. Vendors update Tested up to declarations, release notes, known issues, and hotfixes after WordPress 7.1 ships. An automatic green status based on a repository header can hide a site-specific regression, while an old declaration can make a proven plugin look unsafe.
Use this for managed WordPress fleets and important sites that need a daily compatibility delta rather than a static pre-release plugin list.
Quick answer
Snapshot the installed plugin slug, version, source, Tested up to value, vendor release note, support issue, site journey, local test result, owner, and rollback package. Compare the snapshot daily for declaration, version, issue, and evidence changes. Treat vendor support as one input. Promote only when the installed version and the site's own fixtures pass. Send every changed row to a named review queue.
Test scenarios to run
Run the same controlled fixture across these branches. Write down the expected result before testing so a surprising response is easy to identify.
| Scenario | Fixture | Expected result |
|---|
| Declaration changed | Tested up to 7.1 | Rerun affected fixtures |
| Version changed | Vendor hotfix | Verify package and changelog |
| No declaration | Custom plugin | Local owner evidence required |
| Issue opened | Known regression | Hold or scoped workaround |
Diagnostic table
Use this table to connect the observed behavior to evidence and a verification step.
| Action | Evidence to collect | How to verify |
|---|
| Create a canonical plugin inventory with package source and owner. | Export active, network-active, mu-plugin, drop-in, and must-run dependencies with exact versions and package sources. | Every active dependency has a version, source, affected journey, and owner. |
| Fetch support declarations and vendor changes on a scheduled cadence. | Capture repository Tested up to values plus vendor changelogs and known-issue pages with retrieval timestamps. | Daily snapshots show declaration, release, advisory, and local-result changes. |
| Map each delta to affected journeys and the smallest useful fixture set. | Join every plugin to the editor, media, form, account, search, checkout, REST, cron, email, and cache journeys it can affect. | Changed rows trigger focused tests rather than an unreviewed global status. |
| Retest changed rows and record evidence separately from vendor claims. | Highlight support declarations, releases, advisories, and local test results that changed since the previous snapshot. | Unsupported and unreachable vendors remain visible with a mitigation plan. |
What to check first
- Export active, network-active, mu-plugin, drop-in, and must-run dependencies with exact versions and package sources.
- Capture repository Tested up to values plus vendor changelogs and known-issue pages with retrieval timestamps.
- Join every plugin to the editor, media, form, account, search, checkout, REST, cron, email, and cache journeys it can affect.
- Highlight support declarations, releases, advisories, and local test results that changed since the previous snapshot.
- Keep unsupported, abandoned, custom, and license-blocked packages in an explicit owner queue.
Field notes
- Use synthetic IDs and examples that can be traced from the first request to the final record.
- Keep a before and after result for every changed setting or deployed version.
- Review the evidence again after caches, queues, and scheduled work have had time to settle.
Useful command or data shape
Adapt paths, IDs, and privacy handling to the site before running commands or storing data on production.
plugin,installed,tested_up_to,vendor_release,journey,local_result,delta,owner
forms-pro,2.10.5,7.1,2.10.5,lead,pass,declaration,forms
cache-pro,3.23.2.2,7.1,hotfix,public,pass,version,platform
custom-pay,1.8,unknown,none,checkout,hold,issue,commerce
Why this usually happens
- Repository metadata can lag a vendor's paid distribution channel.
- A declaration says what a vendor claims, not what this site's configuration proves.
- Transitive add-ons and mu-plugins may not appear in normal plugin exports.
- License failures can stop a hotfix from reaching production.
Decision rule
A plugin is release-ready only when the exact installed package passes its affected site journeys and any vendor declaration or issue delta has been reviewed by an owner.
Production verification checklist
- Every active dependency has a version, source, affected journey, and owner.
- Daily snapshots show declaration, release, advisory, and local-result changes.
- Changed rows trigger focused tests rather than an unreviewed global status.
- Unsupported and unreachable vendors remain visible with a mitigation plan.
Safe fix order
Use a sequence that makes each result easy to prove. Stop when new evidence changes the scope or owner of the problem.
- Create a canonical plugin inventory with package source and owner.
- Fetch support declarations and vendor changes on a scheduled cadence.
- Map each delta to affected journeys and the smallest useful fixture set.
- Retest changed rows and record evidence separately from vendor claims.
- Hold automatic updates only for owned exceptions, then close each exception after proof.
Mistakes to avoid
- Changing production before recording exact versions, UTC timestamps, stable fixture IDs, settings, and a reproducible baseline.
- Treating one successful screen as proof that APIs, caches, jobs, roles, reports, and downstream records agree.
- Testing only an administrator session instead of the devices, roles, networks, data states, and failure branches customers use.
- Closing the task without a named owner, rollback point, observation window, and contextual incoming link from an established guide.
Questions teams ask during testing
Can this be tested on production?
Use production for read-only confirmation and one narrow synthetic fixture that cannot charge a card, email a real customer, expose personal data, or alter inventory. Run upgrades, schema changes, cache changes, and destructive repairs on staging first.
What evidence should the report keep?
Keep exact versions, UTC timestamps, stable synthetic IDs, expected and actual results, the decision owner, rollback point, and final verification. Redact credentials, tokens, customer data, addresses, and private infrastructure details.
When is the task complete?
Complete it when the primary user path passes, downstream records reconcile, failure branches are understood, monitoring is active, and an established owner page links to the new guide in context.
What to tell the client or owner
Give the site owner the affected versions, exact synthetic fixture, UTC timeline, before and after evidence, cause class, decision, rollback point, unresolved risks, and next review date. State which measurements prove success and which observation window remains open.
When HandL WP should help
Bring in help when this affects leads, checkout, search visibility, security, paid media reporting, or a client production site. HandL WP can trace the issue through WordPress, hosting, cache, tracking, and Search Console, then verify the workflow after the technical fix.
If this is active on a production site, monitor WordPress plugin compatibility.
Related HandL WP guides
Use these related guides when the same issue touches tracking, security, checkout, or crawler visibility.
Helpful references