pattern/statamic-business-mode
A Statamic addon that adds a configurable business mode: define opening hours, set a timezone, and display a live open/closed status or custom notice. Manage schedules and messaging from the control panel with simple template tags.
What it appears to be (and what we must confirm). Based on the name and description, this is a Statamic CMS addon that toggles a "business mode" state — most plausibly a site-wide maintenance/closed state (holding page, disabled forms/checkout, or scheduled open/closed hours). The README is the actual spec; the description alone is insufficient to commit. A TPM should not scope work until the following are confirmed: what the mode actually gates (routing, content visibility, form submissions, e-commerce endpoints), how it is toggled (Control Panel toggle, config file, env var, schedule), and what response it emits (a rendered template vs. an HTTP 503 vs. a redirect).
Architecture fit. It is a Statamic 3-era addon, so it follows the standard Statamic addon conventions: a Laravel service provider with auto-discovery, optional config publish, and registration of a middleware, tag, or CP utility. That is a comfortable fit for any Statamic 3 application and requires no architectural change to the host app. It is not a general Laravel package — it presumes Statamic's runtime, its service container boot order, and its addon registry. If our roadmap includes leaving Statamic for plain Laravel or another CMS, this dependency is dead weight.
Integration feasibility. Low effort in principle: composer require from VCS, publish config, wire the middleware into the HTTP kernel or the layout, done. The real feasibility question is version compatibility. The last release was May 2021, which predates Statamic 4 and 5. Statamic's major versions have shifted PHP minimums, the addon manifest/registration mechanics, and several templating and CP APIs. Expect composer require to fail on constraint resolution against a current Statamic install, and expect at least a small amount of code change if it installs at all.
Technical risk. High, concentrated in three areas:
Key questions for the maintainer/README review. Does it support the Statamic and PHP versions we run? Is the toggle cached, and is the cache invalidated correctly on save? Does it short-circuit before or after routing — i.e., does it also block the Control Panel, the API, and asset requests? Does it return 503 with Retry-After (correct for maintenance) or 200 (an SEO problem)? Does it exempt authenticated CP users and health checks? Can it be scheduled, and is the schedule timezone-aware? Is there any test suite?
Stack fit. Appropriate only if we are on Statamic 3 with no near-term plan to upgrade. On Statamic 4/5, treat this as a code sample, not a dependency: read the ~200 lines, reimplement the behavior as a first-party middleware or a small internal addon. A site-wide availability toggle is small enough that ownership beats adoption. The cost of forking is measured in hours; the cost of debugging an abandoned global middleware during an incident is measured in revenue.
Migration path. Two viable paths, and the choice should be made before any code lands:
statamic/business-mode repository with Composer VCS or a private Packagist entry, pin to a tag we control, add a test suite covering the failure modes above, and update the Statamic constraint ourselves. This preserves the addon's semantics and gives us a maintenance home.Either way, avoid a bare composer require against the upstream repo as a production dependency — an unreleased branch of an abandoned repo is not a version constraint.
Compatibility work. Verify the addon's composer.json constraints against our locked Statamic and PHP versions first; that single check usually decides between the two paths above. Then check for deprecated Statamic APIs (facade access patterns, addon boot sequence) and for any use of removed Laravel helpers.
Sequencing. (1) Read the source and confirm behavior and blast radius. (2) Attempt install in a throwaway branch against our real composer.lock and note failures. (3) If it installs, write the test matrix — CP user, anonymous user, crawler, API request, scheduled window boundary, cache-warm and cache-cold. (4) Decide fork vs. port. (5) Ship behind a feature flag with the toggle defaulting to off, and dry-run the "on" state in staging including a full cache clear. (6) Document the runbook for the on-call engineer before enabling anywhere in production.
Maintenance. This is the headline cost. With no upstream activity, routine upkeep — Statamic major upgrades, PHP minor bumps, security advisories in the surrounding stack — becomes ours by default. Budget it explicitly: a small but recurring line item, and a hard dependency on someone on the team being able to read Statamic addon internals. If we fork, we also inherit the obligation to re-evaluate the fork at each Statamic release, which is easy to forget precisely because it works.
Support. There is no support channel, no issue triage, and no security disclosure process. That matters more than usual here: a site-availability toggle is an attractive target and an easy way to accidentally take the site down. We should treat any discovered defect as ours to fix, not ours to report.
Scaling. Negligible from a compute standpoint — a config read and a branch on every request, cached, so effectively free even under load. The scaling concern is operational rather than computational: the toggle is binary and site-wide, so it cannot be scoped to a segment, a region, or a storefront while leaving the rest up. If we ever need per-locale or per-brand business states, this addon will not provide them and we should know that before promising the capability.
Failure modes to design against. The maintenance page being served to search crawlers without a proper 503 and Retry-After, damaging indexing. The toggle appearing to be off (cached config or cache not cleared on save) while the site is still gated — or the reverse. The Control Panel or health-check endpoints being caught by the middleware, removing our ability to turn it back off or causing the load balancer to deregister healthy instances. Logged-in staff being locked out during an incident. And the simplest one: whoever is on call at 2 a.m. does not know the toggle exists. That is a documentation and runbook problem, and it is the most likely cause of a long outage.
Ramp-up. Low for a Laravel-fluent engineer — the whole addon is likely readable in under an hour, and the integration is a middleware registration plus a template. The ramp-up that matters is organizational: the on-call rotation needs to know the switch exists, where it lives, what it affects, and how to reverse it. If the toggle is CP-driven, that is a support-team responsibility and needs a one-page runbook with screenshots. Plan for half a day of engineering to evaluate and integrate, and a half-day of documentation and staging rehearsal that is easy to skip and should not be.
Recommendation. Proceed to a timeboxed spike (roughly a day) to read the source and test install against our actual lockfile. Do not adopt upstream as a live dependency. If the behavior matches a real need, fork or port it, add tests and a runbook, and own it. If the need is "show a maintenance page," weigh that against a handful of lines of first-party middleware that we will never have to wonder about.
How can I help you explore Laravel packages today?