The floors#
| Requirement | Minimum |
|---|---|
| WordPress | 6.4 |
| PHP | 8.1 |
Both are declared in the plugin’s own header (Requires at least: 6.4, Requires PHP: 8.1), so a host that doesn’t meet them refuses to activate the plugin at all rather than activating into a broken state. The plugin is tested against WordPress up to the version current at each release — currently 7.0 — which is a ceiling the plugin has actually been run against, not just a floor it happens to work above.
PHP 8.1 is not caution for its own sake: the codebase is written with declare(strict_types=1) throughout, typed properties, match expressions and readonly semantics, and the alternative to requiring 8.1 is shipping code that silently behaves differently — or not at all — on an older runtime. WordPress 6.4 is a floor for a similar reason: it’s where the block and REST infrastructure the admin screens and the Divi modules depend on has settled enough to build against reliably.
What happens if the floor isn’t met#
Composer’s autoloader is required at the entry point — the plugin bails out immediately if it’s missing rather than half-loading with some classes available and others not. A release archive always ships vendor/ with the autoloader inside it, so this only matters if you’re working from an incomplete copy of the plugin rather than the distributed release.
How updates arrive#
The free plugin updates through WordPress.org like anything else in your plugin list — no separate account, no key. Pro updates through the licence you activated: the update check is the only outbound request Pro makes on your behalf for this purpose, and it stops working once the licence lapses. The build you already have keeps running exactly as it was; it just stops receiving new releases until the licence is renewed.
Before a major update#
Take a backup, and if the release notes mention a schema change, run it on staging first. Schema upgrades are forward-only and each one runs once, tracked against a stored version number rather than replayed on every request — a site that’s already current does no extra database work checking. The upgrades themselves are written to be idempotent (built on dbDelta, which diffs the schema rather than blindly reapplying it), so a request that’s interrupted mid-upgrade and simply runs again on the next page load picks up where it left off rather than corrupting anything. Idempotent isn’t the same as risk-free, though — an affiliate programme holds money owed to real people, and that’s the wrong place to discover you’re the edge case a migration didn’t anticipate.
Checking your version#
The installed version of both the free plugin and Pro, if active, shows on the ordinary WordPress Plugins screen the same way any plugin’s version does. If you’re troubleshooting something with support, the plugin version and whether Pro is active and licensed are the two facts worth having ready.