WordPress Plugin Compatibility Preflight vs C-Level Testing

A plugin preflight identifies likely requirements and risks before installation. C-level testing exercises a stated critical flow in a locked WordPress stack. One cannot honestly substitute for the other.

“Compatible with WordPress” often collapses several very different statements. A plugin may declare support for a WordPress version, install without an error, render its settings screen, and still break the one checkout or multilingual workflow that matters to the customer.

Level 1: discovery

Discovery records the plugin name, upstream developer, official page or repository, license, current version, update activity, and public requirements. A plugin listed in the WordPress.org directory is not necessarily developed or endorsed by the WordPress project.

Level 2: preflight

Preflight checks information available before execution:

• minimum and tested WordPress/PHP versions;
• required extensions, services, accounts, or premium licenses;
• theme, editor, WooCommerce, multilingual, or caching dependencies;
• abandoned packages, known conflicts, and security advisories;
• database migrations and update-path risks;
• whether the requested combination can be reproduced legally.

Preflight is valuable because it can stop an obviously unsafe or unsupported combination before unknown code reaches a runtime. But it remains a risk assessment, not a working-site result.

Level 3: browser or B testing

B testing installs the plugin in an isolated WordPress environment and exercises the relevant admin and public editing path. It answers questions such as: does activation complete, does the editor load, can the setting be saved, and does the visible page render?

Level 4: C testing

C testing locks the environment and runs the customer-critical flow. For a commerce site that may include product, cart, checkout, payment sandbox, email, account, and mobile paths. For a multilingual site it may include translation, menu, canonical, language switcher, and sitemap behavior.

The report must name the versions and distinguish PASS, PASS WITH WARNINGS, BLOCKED, and UNTESTED. A warning is not hidden to make a cleaner badge.

Retest triggers

Compatibility evidence should expire or require review when WordPress, PHP, database, theme, editor, a critical plugin, host runtime, or external API changes materially. The WordPress Plugin Handbook explains plugin engineering fundamentals, while each upstream plugin remains responsible for its own published requirements.

WPbyAI’s public status language runs from DISCOVERED and PREFLIGHTED to B_TESTED, C_TESTED, and a repeated VERIFIED_PROFILE. Submit the versions and the flow that must not break; plugin names alone are not enough.