Fix: register cache-invalidation hooks under WP-CLI when there is no request URI

[thisismyurl]

Hey Donncha,

#1007 — the report is that scheduled posts published through WP-CLI don't clear the cache, and that's exactly what's happening.

wp_cache_postload() bails as soon as $wp_cache_request_uri is empty, which is the normal state under WP-CLI (there's no request). The early return is right for the serving side — there's no page to serve on the CLI — but it also skips wp_cache_phase2(), and that's where wpsc_register_post_hooks() wires up publish_post, transition_post_status, and the rest. So when wp-cron fires under the CLI and a scheduled post goes live, nothing is listening, and the stale page survives.

The fix registers just the invalidation hooks on that empty-URI path and leaves the serving path skipped as it was. It leans on the existing wpsc_register_post_hooks() — that only wires the content-change hooks, not the serving ones, and it's guarded by a static $done, so calling it here can't double-register on a normal request. Four lines, and they only run when there's no request URI.

For the test I added a small smoke case (WpCachePostloadTest) that sets an empty request URI, runs postload, and asserts the invalidation hooks registered. It needed add_action/has_action doubles, which the smoke bootstrap didn't have yet, so I added them next to the existing add_filter one. I checked it's a real guard — with the fix the hooks register, and reverting the four lines makes the test fail.

One thing I'm not sure about: whether you'd rather scope the registration more tightly — only under WP_CLI — instead of "whenever there's no request URI." I went with the no-URI condition because it's the actual precondition for the bug and it's what the function already branches on, but I'm happy to switch to a CLI-specific guard if you'd prefer.

Fixes #1007

(full disclosure: AI helped me identify the issue and verify my work)

[Copilot]

Pull request overview

This PR fixes cache invalidation when WordPress runs without a request URI (notably WP-CLI / some cron runners) by ensuring the post-change invalidation hooks are still registered even though the cache-serving path is skipped.

Changes:

• Register wpsc_register_post_hooks() from wp_cache_postload() when $wp_cache_request_uri is empty (and caching is enabled), restoring invalidation behavior for CLI/cron contexts.
• Add a smoke test to assert invalidation hooks are registered in the empty-URI path, plus minimal add_action() / has_action() hook doubles for the smoke tier.
• Add a changelog entry documenting the fix.

Reviewed changes

Copilot reviewed 4 out of 4 changed files in this pull request and generated 1 comment.

File	Description
wp-cache-phase2.php	Registers invalidation hooks even when request URI is empty, while still skipping cache serving.
tests/php/smoke/WpCachePostloadTest.php	Adds regression smoke coverage for hook registration under empty request URI.
tests/php/bootstrap-smoke.php	Extends smoke bootstrap with add_action() / has_action() doubles backed by the existing filter registry.
changelog/fix-cli-cache-invalidation	Notes the WP-CLI scheduled-post cache invalidation fix.

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.