Download the PHP package nimblephp/maintenance without Composer
On this page you can find all versions of the php package nimblephp/maintenance. It is possible to download/install these versions without Composer. Possible dependencies are resolved automatically.
Download nimblephp/maintenance
More information about nimblephp/maintenance
Files in nimblephp/maintenance
Package maintenance
Short Description Maintenance mode for NimblePHP with an IP allow-list. Stores its configuration in the settings module.
License MIT
Informations about the package maintenance
nimblephp/maintenance
Maintenance mode for NimblePHP. While enabled, every request gets a 503 page
except requests from allow-listed IP addresses.
Requires nimblephp/settings — the whole configuration (on/off, message, allowed IPs, retry-after) is stored there, so this module ships no migration and no table of its own.
Contents
Module— registers the maintenance middleware, CLI commands and translationsMaintenance— facade for toggling and configuring maintenance mode (backed by settings)MaintenanceMiddleware— blocks requests with a 503 page while enabledCommands/MaintenanceCommand— CLI commandsLang/— translations (en,pl) for the maintenance page
Translations
The maintenance page title and default message are translated via the framework
translation system (keys module.maintenance.title and module.maintenance.message),
shipped for en and pl, and rendered in the current language. A custom message
set with Maintenance::enable('...') overrides the translated default.
Installation
The settings module migration must have been run (it provides the storage table).
CLI
The module ships console commands (auto-registered via the module system). A fresh
install needs nothing in the database — maintenance:on creates the settings rows:
Usage (PHP)
When enabled, MaintenanceMiddleware (registered at high priority) intercepts
requests in beforeController: allow-listed IPs pass through, everyone else gets
a 503 with a Retry-After header. The check fails open — any error while
reading the state lets the request through, so a misconfiguration can't brick the
site.
View / overriding the page
The page is rendered through the framework view service from the container, so
whatever view module is installed renders it transparently:
- Twig module installed → Twig owns the
viewservice, so the page is a Twig template. The module shipssrc/View/maintenance.twigand registers its own view directory in the Twig loader, so the default works out of the box. Custom views must be.twig. - No Twig (base renderer) → the module ships
src/View/maintenance.phtml. Custom views are.phtmlunderApp/View.
Override the page with maintenance.view:
A flat name (e.g. test) maps to App/View/test.twig under Twig or
App/View/test.phtml under the base renderer. Your view receives title,
message, lang and retryAfter. If the view service or the view file is
unavailable, a built-in 503 page is rendered as a fallback, so the module always
works — even without a view module installed.
Configuration keys (in settings)
| Key | Type | Default |
|---|---|---|
maintenance.enabled |
bool | false |
maintenance.message |
string | generic message |
maintenance.allowed_ips |
json (array) | [] |
maintenance.retry_after |
int (seconds) | 3600 |
The client IP is read from
REMOTE_ADDR. Behind a proxy/load balancer, make sure that reflects the real client (or add the proxy IP to the allow-list).