Which WordPress and PHP versions Gillish runs on.

Where the floors sit today#

Two axes, two declared minimums:

The minimums are exercised on every push to our floor smoke environment, so we know the plugins actually run at the declared floors. We do not just declare a number and hope for the best.

How a floor moves#

Three triggers lift a floor:

1. A specific WordPress or PHP feature unlocks work we want to ship. When Cairnstone's Block Bindings work needed the block_bindings_supported_attributes filter, a WordPress 6.9 addition, we lifted the WordPress floor to 6.9. Without that lift, every code path using the filter would need a fallback for sub-6.9 sites, friction we would carry forever.
2. The current floor blocks a clean implementation. Holding PHP 8.2 when we would otherwise reach for json_validate(), a PHP 8.3 function, means hand-rolling what core already provides. We would rather lift than wrap.
3. Posture consistency. When we lift WordPress aggressively, holding PHP at an older version is a discipline-drift signal. The floors move together.

When a floor lifts, we update the plugin headers, bump the plugin version, write a changelog entry, and document the technical reason in our decision log. The lift is permanent in practice. We do not reverse a floor decision short of a major architectural pivot.

What this means if you run a Gillish plugin#

WordPress and PHP have one-click updates now. The friction of staying current is much lower than it was a few years ago. Most hosts let you switch PHP through their control panel; WordPress core auto-updates if the option is enabled.

Floors move forward, not backward. Plan around the floor being where it is or higher in the future. A change like the same-day WordPress 6.6 to 6.9 lift, with PHP 8.2 to 8.3 alongside, is unusual but not impossible.

If your site runs below a current floor and you cannot update right now, the older version of the plugin that supported your stack remains installable from the plugin's release history on WordPress.org. We do not backport fixes to those versions.

Why we are this aggressive#

Each backward-compat path we do not write is a path we do not have to debug, document, or update later. The site-owner audience for a 30-plus-block Gutenberg plugin with custom MCP integration self-selects strongly for modernity; sites running pre-floor PHP or WordPress are a vanishing fraction of installs. Carrying compatibility for them would add measurable maintenance load against a near-zero installed base.

The aggressive posture is not arbitrary. Each floor-lift decision is recorded with its technical justification in our internal log. When you see a Gillish plugin require PHP 8.3 or WordPress 6.9, that requirement traces back to a specific, dated decision and a specific feature we wanted to use cleanly.