Maintenance Mode Command Laravel Package

Product Decisions This Supports

• Release process: manual click-ops vs. scripted deploys. This command turns "put the site in maintenance mode" from a person remembering to do something in a browser into a deterministic, exit-code-bearing step in a deploy pipeline. That is a direct input to the decision of whether to invest in automated release tooling for WordPress properties.
• Build vs. buy (buy, and for near-zero cost). The capability is a three-verb CLI surface (activate, deactivate, status) under MIT, maintained inside the official WP-CLI org and shipped with the WP-CLI bundle most teams already install. Writing and maintaining this in-house is strictly negative ROI unless requirements diverge (see next section).
• Incident response and rollback design. A repeatable status check and a scriptable toggle let you define what "we are in maintenance" means operationally — and lets on-call automate the toggle during a bad release instead of relying on an admin being awake with wp-admin access.
• Multi-environment and multi-site fleet rollouts. Consistent command semantics across staging, production, and client sites make maintenance windows a parameterized operation rather than a per-site runbook, which is the gating question for taking on more sites per operator.
• Roadmap scoping for customer-facing downtime. Once toggling is cheap and auditable, the roadmap question shifts from "how do we take the site down" to "what do users see during downtime" — that's a separate product decision (holding page, status comms, SLA language) this package deliberately does not own.

Signal interpretation for planning: 11 stars and 0 dependents are not adoption evidence against it. This is an extracted slice of WP-CLI core's maintenance-mode command, distributed via the WP-CLI bundle rather than installed per-project — star counts on such packages are structurally meaningless. Weight the organizational backing (WP-CLI), the MIT license, and the tiny surface area instead.

When to Consider This Package

Adopt when:

• WordPress deployments already run through WP-CLI (or a host/CI runner that shells out to it), so this adds no new dependency or credential model.
• You need maintenance mode to be checked programmatically — pre-deploy gates, health checks, smoke tests, or a "is anything still down?" dashboard.
• You operate multiple sites/environments and want one uniform, scripted maintenance procedure.
• You need a defensible audit trail of who toggled downtime and when, via CI logs rather than human memory.
• Your maintenance page requirements are "whatever the active theme renders" — i.e., you are not trying to control the user-facing experience.

Look elsewhere when:

• You need a branded, custom, or communicated holding page. This package controls state, not presentation. That is a theme/plugin concern, and pretending otherwise will produce a bad customer experience during exactly the moment customers are watching.
• You need granular bypass rules — per-role, per-IP, allow-list for internal QA, or "admins see the site, everyone else sees the holding page." Those semantics belong in a maintenance-mode plugin with a UI, not in a CLI verb.
• The hosting platform already owns this. Managed WordPress hosts frequently enforce maintenance behaviour themselves; adding a second, competing toggle creates a confusing source of truth.
• You need a guarantee of vendor support or a security response SLA. There is a single-purpose command here with no commercial backing; treat it as a small utility, not a supported product.
• Your deploy story is not CLI-shaped. If releases happen through a dashboard or a page builder, this package has no insertion point.

Adoption risk is low but non-zero: the command surface is small and the code is linted, statically analysed, and covered by Behat acceptance tests per the repo's contribution standards, so upgrade risk is minor. Pin it and move on. Note the release cadence is versioned but not a support commitment.

How to Pitch It (Stakeholders)

For executives: "Today, taking a WordPress site down for a release depends on a person remembering to click a button, and nobody can prove afterwards whether it happened. This is a small, free, MIT-licensed command that is part of the official WP-CLI toolset — the same one our deploys already use. It makes 'put the site in maintenance mode' a scripted, logged step. No new vendor, no procurement, no new credentials. The realistic outcome is fewer botched releases and a cheaper incident response, not a new product capability."

For engineering: "wp maintenance-mode activate|deactivate|status. Official WP-CLI package, MIT, no runtime dependency beyond the WP-CLI you already have in the deploy image. WP-CLI coding standard, PHPStan, and Behat acceptance coverage in CI; the command surface is three verbs, so integration cost is hours, not a sprint. Wire status into your pre-deploy gate and wrap the toggle in the release job so a failed deploy cannot strand the site in maintenance. Two deliberate non-goals: it does not render a custom holding page and it does not do per-role or per-IP bypass — if we need either, that's a separate decision and we should make it explicitly rather than stretching this."

The one-line ask: approve adding it to the deploy image and to the release runbook; revisit the customer-facing holding page as its own initiative.