TL;DR: Every WBP plugin is validated on every supported platform on every release against a fixed compatibility matrix: no RCE, PHP 7.4+ / 8.1+, <128 MB memory base, no
eval() / base64_decode(), sanitisation on input, escaping on output, cache-purge cooperation.1. Why platform standards matter
A publishing tool that works only on your dev machine is a science project. WBP is production infrastructure — the same plugin needs to behave identically on a five-dollar shared plan and on a hardened enterprise stack. That is only possible when every dependency is measured against the same platform standards on every release.
2. Cross-platform compatibility matrix
- No remote code execution — no eval(), no base64_decode() for code, no dynamic includes from user input.
- PHP 7.4 minimum, 8.1+ preferred and tested. 8.3 in CI on every release.
- <128 MB memory base on the entry-tier shared plan.
- Input sanitisation on every accepted value; output escaping on every rendered value.
- wp-cron and system cron both supported — third-party cron services (EasyCron, Cronitor) explicitly tested.
- Cache-purge cooperation with LSCache, WP Rocket, W3 Total Cache, Cloudflare, and native object cache.
3. The three tier-1 platforms
Hostinger
Shared and managed WordPress hosting. The floor: if WBP runs cleanly on entry-tier Hostinger, it runs cleanly everywhere.
Cloudflare
The edge in front of most WBP sites — cache, security, workers, R2. Every WBP asset is designed for Cloudflare's cache model.
WordPress.org
The plugin repository, the coding standards, the security policy, the review guidelines — every WBP plugin ships against them.
4. What we don't do
- We do not ship features that require RCE or obfuscated code — even for licensing enforcement.
- We do not require more than 128 MB memory for baseline functionality. Higher tiers unlock, not gate.
- We do not bypass cache invalidation. Every publish purges cooperatively; never a hard site-wide flush.
- We do not silently degrade on shared hosting. If a feature needs VPS, we say so.