Quality + PHPcs + Not only Memcached

[herewithme]

• Code changes for PHPCS compliance: WordPress Coding Standards (WordPress-Extra, WordPress-Docs), formatting, PHPDoc, and targeted rule exclusions for drop-in layout

• Add PHP quality tooling: Composer dev dependencies (WPCS, PHPCompatibility-WP, PHPStan with WordPress stubs), .phpcs.xml.dist, phpstan.neon, .editorconfig; composer lint, composer format, composer analyze

• Development: add DDEV for local WordPress environment; add .ddev/config.yaml, .ddev/docker-compose.plugin.yaml (plugin mount at wp/wp-content/plugins/batcache)

• Docs: add TESTING.md with DDEV one-time setup, manual testing steps, Redis/Memcached section; document Redis Object Cache installation via WP-CLI and wp-config (WP_REDIS_HOST, WP_CACHE)

• Fix: in batcache.php, guard now checks isset( $wp_object_cache ) and is_object( $wp_object_cache ) before method_exists() to avoid PHP 8 TypeError when object cache is not available (e.g. CLI, headless)

• Development: no automated tests (manual testing only)

• Admin bar: add "Purge Batcache" button for users with manage_options; purges entire batcache group via wp_cache_flush_group() when the object cache supports it (e.g. Redis)

• Document compatibility with any WordPress object cache API backend (Redis, Memcached, etc.), not only Memcached

• Update code comments and docs to use "object cache" instead of "memcached" where generic

• Readme: add Object cache backend section; cite Memcached as reference setup and original dependency

[tomjn]

@herewithme this is a huge PR, can you split it out into separate topics? E.g. 1 for PHPCS etc 1 for CI additions, another for each bug fix, etc

Note that some of the additions, e.g. the admin bar purge button, would probably be rejected as this has direct impacts on a large number of hosts that use batcache internally. Likewise for memcached and other major refactors/features. I'd also question DDEV support, as valuable as it might be (and as much as I like DDEV) you might get an automattician wanting WP Env instead.

[herewithme]

@herewithme this is a huge PR, can you split it out into separate topics? E.g. 1 for PHPCS etc 1 for CI additions, another for each bug fix, etc

Note that some of the additions, e.g. the admin bar purge button, would probably be rejected as this has direct impacts on a large number of hosts that use batcache internally. Likewise for memcached and other major refactors/features. I'd also question DDEV support, as valuable as it might be (and as much as I like DDEV) you might get an automattician wanting WP Env instead.

Too complex — bringing the codebase into PHPCS compliance would effectively require a very large rewrite: for styling, but also to apply changes like Yoda conditions, etc.

What could be removed is the flush button indeed.

Regarding wp-env, I considered it, but the lack of Redis/Memcached support makes it unsuitable.

Apart from checking whether a variable exists (which is more in the realm of code quality/static analysis, e.g., PHPStan), there are no other changes.

[tomjn]

Too complex — bringing the codebase into PHPCS compliance would effectively require a very large rewrite: for styling, but also to apply changes like Yoda conditions, etc.

not bringing the entire codebase into compliance, just the PHPCS related changes in the PR you've already made

[herewithme]

I’m not sure I understand — do you mean a PR that only adds the tooling, without aiming to make the whole codebase compliant?

And in that case, do you want it with or without the auto-fix corrections (formatting / PHPCS autofixes)?