What “Tested Up To” Means on WordPress.org

Tested Up To names the WordPress release a plugin maintainer reports testing.

It is useful compatibility evidence, but never a site-specific guarantee.

Read its value beside requirements, release dates, changelogs, and staging results.

What does Tested Up To mean on WordPress.org?

It identifies the WordPress version against which maintainers tested their plugin. The claim comes from plugin metadata.

It does not describe your theme, plugins, content, server, or workflows. Those combinations require separate evidence.

Find the field on the plugin page

WordPress.org displays the value within a plugin’s technical details. WordPress administration can surface related compatibility messaging. The longer version is in checking plugin compatibility before installing.

Confirm the exact plugin slug before reading any field. Similarly named plugins can have unrelated evidence.

Know where the value originates

The maintainer adds Tested Up To inside the directory readme header. WordPress.org parses the applicable stable readme.

The Plugin Handbook documents this field and parsing process. It is not generated from your site.

Understand who makes the claim

Plugin maintainers choose the version after their own testing process. WordPress.org displays the submitted value.

The directory does not independently test every plugin-site combination. Treat the field as maintainer-provided evidence.

Understand the version format

The field should contain numbers representing a WordPress release. It should not include prefixes like WP.

The handbook explains that minor versions are ignored for this field. The directory can add the current minor release.

Distinguish major and maintenance releases

A value like 6.9 represents that WordPress release line. Maintenance releases remain within the same major branch.

Do not infer testing against future major releases. A branch value does not extend indefinitely.

Do not confuse Tested Up To with Requires at least

Requires at least declares the oldest supported WordPress version. Tested Up To identifies a reported test boundary.

One describes a minimum floor. The other describes recent compatibility evidence.

Do not confuse Tested Up To with Requires PHP

Requires PHP declares the plugin’s minimum PHP runtime. Tested Up To concerns WordPress core versions.

A current Tested Up To value cannot clear a PHP mismatch. Check both conditions separately.

Do not confuse Tested Up To with Stable Tag

Stable Tag identifies the plugin release used by the directory. It does not name a WordPress version.

The plugin’s main PHP header supplies its actual version. Keep these three fields conceptually separate.

Read a matching value correctly

A match means the maintainer reports testing your WordPress release line. That is relevant positive evidence.

It cannot represent your exact component stack. Continue reviewing dependencies and critical workflows.

Read a newer value correctly

The plugin may be tested beyond your installed WordPress version. First confirm you still meet its minimum.

Then verify the plugin still supports your older release. Newer testing does not erase raised minimums.

Read an older value correctly

An older value means recent WordPress testing is not declared. It does not automatically prove failure.

Treat the gap as uncertainty. Seek stronger supporting evidence before consequential installation.

Measure the size of the testing gap

Compare the declared value with your exact WordPress release. Count meaningful major-version changes between them.

A larger gap usually deserves broader testing. Actual risk still depends on plugin behaviour.

Check when the plugin was last updated

A recent package with stale metadata creates a different question. An old package signals broader maintenance uncertainty.

Read dates with changelog quality and support evidence. No single timestamp settles compatibility.

Check whether metadata changed alone

A release can update Tested Up To without changing runtime code. That may document completed compatibility testing.

Read the changelog and release diff when available. Distinguish metadata confirmation from compatibility fixes.

Check whether code changed for compatibility

Changelog entries may mention WordPress compatibility repairs. Those changes identify areas needing focused regression tests.

Test both the corrected path and nearby workflows. A declared fix still needs site evidence.

Look for the tested plugin version

The directory field belongs to the displayed stable plugin release. Older installed releases may have different compatibility evidence.

Match the field to the exact candidate version. Do not transfer evidence across releases casually.

Check the complete release span

Updating across several plugin versions introduces every intervening change. Read their notes before trusting the latest label.

A current field cannot describe migration risk alone. Build tests from the entire release span.

Consider the plugin’s WordPress surface area

Editor extensions and deep integrations touch many changing WordPress interfaces. Simple output filters may touch fewer.

Broader surface area increases the value of current testing. It also increases site-specific uncertainty.

Consider block editor exposure

Block plugins depend on editor packages, serialization, rendering, styles, and interactions. Core releases can affect those boundaries.

Test existing and newly inserted blocks. Compare editing, saving, and public output.

Consider administration exposure

Plugins can modify screens, notices, permissions, REST routes, and scheduled tasks. WordPress changes may affect each integration.

Test actual staff roles and daily workflows. Administrator access can hide permission failures.

Consider frontend exposure

Frontend plugins interact with themes, caching, requests, scripts, and user sessions. Tested Up To cannot represent every combination.

Test representative public routes and business actions. Include anonymous and authenticated states.

Consider Multisite exposure

Ordinary WordPress compatibility does not prove Multisite behaviour. Activation, data, roles, and settings have additional scope.

Seek explicit Multisite evidence when the network needs it. Test representative sites and activation modes.

Check linked documentation

Maintainers may publish compatibility notes beyond the directory field. Look for limitations, workarounds, and tested configurations.

Confirm documentation applies to the candidate version. Archive useful evidence with the decision date.

Check relevant support reports

Search recent reports naming your WordPress and plugin versions. Prioritise reproducible facts over vague complaints.

Support reports can reveal unresolved edge cases. They cannot prove every installation fails.

Ask the maintainer a precise question

Provide plugin, WordPress, PHP, theme, and integration versions. Describe the exact workflow requiring assurance.

Ask whether the combination was tested. Preserve the response as supporting evidence.

Use staging to close important gaps

Build a representative environment matching production’s important components. Install the exact candidate version there.

Test critical workflows and surrounding regressions. Record failures, logs, screenshots, and saved data.

Test the declared WordPress release

Testing your actual release matters more than testing a nearby one. Include its maintenance version and configuration.

Use a supported PHP combination too. WordPress compatibility depends on the complete runtime.

Test after WordPress updates

A future core update can move beyond the plugin’s declared boundary. Recheck metadata and release notes first.

Run plugin-specific regression tests on staging. Update production through the normal controlled process.

Use current values as one positive signal

Maintained current values suggest compatibility testing accompanies releases. That practice supports confidence when other evidence agrees.

Still examine requirements, changelogs, support, and staging. Metadata freshness is not product quality.

Do not reject stale values automatically

A maintainer may test successfully yet delay the directory update. Simple plugins may continue working unchanged.

These possibilities reduce certainty, not risk automatically. Seek evidence proportional to consequences.

Do not accept current values automatically

A current field may reflect narrow maintainer testing. Your plugin stack may expose different failures.

Verify important output, data, permissions, and integrations. High consequences demand direct evidence.

Compare candidate plugins fairly

Use the same WordPress target and evidence date for comparisons. Note different release schedules and feature complexity.

Do not rank plugins through this field alone. Compare maintenance, architecture, support, and site fit.

Build an evidence matrix

Record Tested Up To, Requires at least, plugin version, and update date. Add relevant changelog and support findings.

Mark confirmed facts, unresolved questions, and staging results. Assign ownership for consequential gaps.

Record the decision boundary

Approve the exact plugin, WordPress, PHP, and integration combination reviewed. Add the decision and testing dates.

Trigger review after relevant core or plugin changes. Compatibility evidence ages with the environment.

Know the honest weak case

A stale value may reflect delayed metadata rather than defective code. Small stable plugins can need few changes.

That possibility never proves compatibility. Run proportionate tests before important production use.

Account for WordPress maintenance releases

Maintenance releases usually repair defects within an existing WordPress branch. They can still change observable behaviour. Read their release notes. Retest affected plugin journeys.

The directory’s display may advance the maintenance number automatically. That display does not prove fresh maintainer testing. Preserve the underlying branch meaning. Verify consequential changes directly.

Account for WordPress major releases

Major releases can introduce new APIs, interfaces, and deprecated behaviour. Plugins with deep integrations face more exposure. Review field freshness before upgrading. Read plugin guidance too.

Test the release candidate when your operational process supports it. Early testing creates useful remediation time. Repeat against the final stable release. Record all version differences.

Account for automatic core updates

Automatic maintenance updates can move a site within its release branch. Monitor plugin behaviour after those changes. Keep critical verification fast and repeatable. Escalate unexpected differences.

Tested Up To should not become your only monitoring control. Watch errors, integrations, and customer journeys. Preserve rollback options where practical. Update the evidence record afterwards.

Check vendor products outside WordPress.org

Premium-only plugins may publish compatibility claims on vendor pages. Their field names can resemble directory metadata. Confirm the vendor’s exact definition. Record the applicable product version.

Do not assume WordPress.org parsing rules govern outside systems. Ask how testing was performed. Seek changelogs and requirements. Verify the candidate on staging.

Check whether the plugin supports older branches

A current test boundary does not define every older supported branch. Requires at least provides only the minimum floor. Documentation may narrow practical support. Security updates may differ too.

Ask which branches receive routine testing and fixes. Test your actual installed branch. Plan a platform update when support weakens. Avoid indefinite unsupported operation.

Check whether your host changes the environment

Hosts can update PHP, caching, security rules, or server modules. Those changes sit outside Tested Up To. They can alter plugin behaviour substantially. Track them beside WordPress changes.

Ask for maintenance notices and relevant platform documentation. Reproduce the hosted configuration on staging. Test critical integrations after changes. Record host-specific limitations.

Teach teams the field’s limits

Document the field inside plugin procurement and update procedures. Explain its source and evidence boundary. Provide examples of stale and current values. Require supporting checks for both.

A shared interpretation improves consistent decisions. It also prevents automatic rejection or acceptance. Review the procedure after incidents. Keep examples current with directory behaviour.

Use the Tested Up To checklist

Review this checklist whenever WordPress or the plugin crosses a meaningful release boundary. Preserve previous results for comparison. Replace assumptions with dated evidence. Escalate every unresolved critical mismatch. Keep records.

1. Confirm the exact plugin slug.
2. Record the candidate plugin version.
3. Record the displayed Tested Up To value.
4. Record your exact WordPress version.
5. Measure the meaningful release gap.
6. Separate Tested Up To from minimum requirements.
7. Separate Tested Up To from Stable Tag.
8. Check the plugin’s last update date.
9. Read relevant changelog entries.
10. Determine whether compatibility code changed.
11. Check the plugin’s WordPress integration surface.
12. Review current compatibility documentation.
13. Search versioned support evidence.
14. Ask precise questions about critical gaps.
15. Build a production-like staging environment.
16. Test the exact target WordPress release.
17. Exercise plugin-specific critical workflows.
18. Inspect errors, logs, requests, and saved data.
19. Compare related site regressions.
20. Record unknowns and accepted risks.
21. Approve only the tested combination.
22. Set future compatibility review triggers.

Frequently asked questions

The verdict

Compatibility claims deserve context. Compare the $299 lifetime suite using your actual environment.