Codeinwp / Codeinwp/wp-maintenance-mode

Wizard activation does not purge cached live pages

Open
#557 0 comments 0 reactions 1 assignee View on GitHub

@selul is already working on this.

Since Sep 9, 2026.

bug-report bug-report-triage
Dominant language
PHP
Stars
163
Forks
82
Avg merge
8h 31m
Merged PRs (30d)
8

Description

Summary

Activating Coming Soon mode through the setup wizard can leave a previously cached live page visible to anonymous visitors. Expected behavior is for activation to make the Coming Soon page visible after the wizard completes. Instead, visitors can continue receiving the public site from the existing cache, leaving the site's intended access restriction ineffective until that cache is cleared or replaced.

Customer context

Product / area: LightStart setup wizard and Coming Soon mode
Version: 2.6.23
Environment: WordPress site; cache implementation not provided
Integration / third party: Unknown from available evidence
Reported error / symptom: Coming Soon mode appeared activated, but the live site remained visible across browsers and devices
Impact: The public site remained accessible when the site owner expected the Coming Soon page

Reproduction notes

Repository-derived reproduction:

  1. With LightStart 2.6.23 and a supported full-page cache active, request the public homepage anonymously so the live response is cached.
  2. On a fresh install, select/import a Coming Soon template through the setup wizard, which activates maintenance mode.
  3. Request the homepage from a logged-out browser or device.
  4. Check whether the cached live response remains visible instead of the Coming Soon response.

The reported site was not reproduced directly. Its activation route and cache implementation were not provided.

Diagnosis

Conclusion

The wizard template-import path sets the active status and persists settings but omits the cache invalidation invoked by the normal General-tab activation path. This is a source-confirmed lifecycle gap capable of producing the reported cross-browser symptom when an existing full-page cache serves the live response before WordPress runs. The customer's activation route and cache layer are unknown, so the exact production attribution remains an inference.

Where this likely occurs
  • Setup wizard activation: includes/classes/wp-maintenance-mode-admin.phpWP_Maintenance_Mode_Admin::insert_template() lines 822–829 sets general.status to 1 for source=wizard and saves the option without invoking cache deletion.
  • Normal settings activation: includes/classes/wp-maintenance-mode-admin.phpWP_Maintenance_Mode_Admin::save_plugin_settings() lines 430–474 invokes wpmm_delete_cache() for active-state transitions and active-state saves.
  • Cache integrations: includes/functions/helpers.phpwpmm_delete_cache() lines 401–468 flushes WordPress object cache and supported page-cache integrations.
  • Frontend interception: includes/classes/wp-maintenance-mode.phpWP_Maintenance_Mode::__construct() lines 89–98 registers the maintenance handler when status is active; WP_Maintenance_Mode::init() lines 726–808 serves the maintenance response once WordPress receives an eligible request.
  • Git history: commit 12136dc9 introduced wizard activation; the same omission is present in release tag v2.6.23 at commit 9874709d9c118319ddd26337ae366624fb8cb722. The activation feature appears with this behavior from its introduction, so the inspected history does not establish a regression.
Engineering notes

A cache hit occurring before WordPress bootstrap does not reach the frontend interception or its no-cache handling. The plugin already treats cache invalidation as part of activation through the General tab, while wizard activation reaches a separate persistence path. The helper includes integrations for several common cache plugins plus the wpmm_delete_cache action; unsupported external caches remain outside the confirmed scope.

Test coverage status

tests/e2e/specs/maintenance-mode.spec.js lines 27–56 verifies anonymous visitors receive the maintenance response after General-tab activation. tests/page-state-test.php lines 110–148 exercises template insertion with source=tab-design, not wizard activation. No relevant coverage was found during inspection for wizard activation cache invalidation or a pre-existing page-cache response.

What to verify or explore next
  • May be worth reproducing wizard activation with one supported page-cache integration after first caching the public homepage.
  • May be worth comparing the same cached request after activation through the General tab.
  • If reproducible, checking multisite and network-activation flows may clarify whether the scope differs there.
Unknowns / follow-up
  • The feedback does not identify whether activation occurred through the wizard or General tab.
  • The feedback does not identify the cache plugin, host cache, CDN, or reverse proxy in use.

Confidence

Confidence: 87/100

The tagged 2.6.23 source contains a reachable wizard activation path that enables Coming Soon mode without the cache invalidation performed by the normal activation path, matching the cross-browser live-page symptom when a shared page cache is involved. The Site Health report has no corresponding persistent failure path, and the generic “doesn’t work” submission is not testable as a distinct defect.


Source: automated uninstall feedback — wp-maintenance-mode, 2026-09-04
Generated by bug-report-triage (ID: bug-report-triage_6a9ba20081a784.54129505)

Contributor guide

Open the contributing guide

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

Assessment

This issue has not been assessed yet.

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.