Wp Compat Laravel Package

Product Decisions This Supports

• Setting and defending a "minimum supported WordPress version" policy. The package turns a vague support statement into an enforceable, CI-checkable contract. A PM can say "we support WP 6.2+" and have a build failure — not a customer bug report — as the consequence of drifting from it.
• Build vs. buy vs. ignore for compatibility QA. Rather than standing up a full WordPress version matrix (multiple PHP/WP combos, wp-env or Docker, slow end-to-end runs), this gives a fast static gate on the most common class of breakage: calling a function, class, or method that simply doesn't exist in older core.
• Roadmap sequencing for "raise the floor" initiatives. Before committing engineering time to dropping old WordPress support, you can measure how much of the codebase actually depends on newer APIs. That converts a gut-feel argument into a scoped estimate (e.g., "12 call sites across 4 files must be refactored or feature-gated").
• Release gating and regression prevention. As a PHPStan rule set, it slots into existing PR checks, so support-floor regressions are caught at review time instead of surfacing as a support ticket from a long-tail install running an older core.
• Support-cost and segmentation analysis. Knowing which APIs your product truly requires helps you reason about the tail of users on old WordPress versions and whether supporting them is worth the maintenance and testing overhead.
• Use cases it fits well: WordPress.org-hosted plugins/themes with a broad, slow-updating install base; freemium plugins where the free tier must run on older core; agency/distribution products with contractual minimum-version commitments; any codebase already running PHPStan in CI.

When to Consider This Package

Adopt when:

• You ship a WordPress plugin or theme (not a standalone app) and publicly declare a minimum supported WordPress version.
• PHPStan is already, or can cheaply be, part of your CI — this is an extension, not a standalone tool, so the marginal cost is configuration, not a new pipeline.
• Your compatibility risk is dominated by API availability (new functions, classes, methods introduced in later core releases) — the most common and most mechanical failure mode.
• You want a cheap first line of defense before investing in a full runtime test matrix against multiple WordPress versions.
• You value a well-known maintainer in the WordPress ecosystem (John Blackbourn) and MIT licensing with no vendor lock-in.

Look elsewhere or treat as insufficient when:

• You need behavioral compatibility, not just symbol existence. This will not catch changed hook signatures, altered default behavior, deprecations, REST API schema shifts, or block editor / @wordpress/* package breakage. Those still require integration tests against real WordPress versions.
• You have no static analysis baseline. If PHPStan isn't in place, the real cost is adopting PHPStan first; budget for that, plus the base WordPress stub package this builds on (e.g., szepeviktor/phpstan-wordpress) — they're complementary, not alternatives.
• You need PHP-version compatibility. That's a separate concern (PHPCompatibilityWP); this targets WordPress API surfaces.
• Governance is strict. ~25 stars and a single maintainer is a real bus-factor and maintenance-lag risk: the tool's value depends on stubs keeping pace with each WordPress release. For a large org, plan to validate it yourself and be prepared to fork or vendor.
• Your product is JS/React-heavy (blocks, editor). Coverage of that surface is out of scope.
• You only support the latest WordPress version. Then the constraint is trivial and the tooling adds little.

How to Pitch It (Stakeholders)

Executives / leadership (one line): A low-cost, MIT-licensed CI check that enforces the WordPress version we promise to support, converting avoidable compatibility bugs into build failures and giving us hard data on what it costs to raise our minimum supported version.

Engineering: A PHPStan extension that pins the WordPress API surface to our declared minimum version, so any use of a function or class introduced in a later release fails static analysis in the PR rather than in production. It's a dev dependency, requires no runtime footprint, and drops into the PHPStan setup we should already have. Roughly a day of integration plus a policy decision on the minimum version, with ongoing cost limited to keeping the dependency current.

Product / support: Reduces a class of "works on my site, fatal on theirs" tickets. It also gives us an evidence-based answer when deciding whether to drop support for older WordPress releases, instead of guessing.

Honest caveats to state up front: narrow scope (API availability only — it complements, not replaces, a version-matrix integration test), a small single-maintainer project, and dependence on the stub data tracking WordPress releases. Recommend a pilot on one plugin, measured by compatibility tickets avoided over a release cycle, before standardizing across the portfolio.