Wartungsmodus

Das Maintenance-Mode-Modul versetzt eine Subsite in den Wartungsmodus. Besucher werden auf eine automatisch erstellte, konfigurierbare Wartungsseite weitergeleitet – Administratoren sehen standardmäßig weiterhin die normale Seite und können ungestört weiterarbeiten.

Allgemein

Zeitplan

Der Wartungsmodus kann mit einem optionalen Start- und Endzeitpunkt versehen werden. Vor dem Start bleibt die Seite trotz aktivierter Checkbox normal erreichbar, nach dem Endzeitpunkt schaltet sich der Wartungsmodus beim nächsten Seitenaufruf automatisch selbst wieder aus.

Ausnahmen

Bestimmte WordPress-Seiten (per Checkliste) oder frei eingegebene Pfade können vom Wartungsmodus ausgenommen werden – z. B. eine Kontaktseite oder ein Webhook-Endpunkt, der weiterhin erreichbar bleiben muss. Zusätzlich lässt sich per Checkbox erlauben, dass alle eingeloggten Nutzer die Seite normal sehen (nicht nur Administratoren, die ohnehin immer durchgelassen werden).

Vorschau & Test

Ein spezieller Vorschau-Link (?weinhold_maintenance_preview=1) erzwingt den Wartungsmodus nur für den eigenen Aufruf, ohne ihn für alle anderen Besucher zu aktivieren – zum schnellen Gegencheck der Wartungsseite.

Konfiguration

Alles wird im Dashboard unter Weinhold → Maintenance Mode konfiguriert. Kein Shortcode nötig – das Modul arbeitet vollständig automatisch.

Dateien

modules/maintenance_mode.php – einzige Datei des Moduls: Einstellungen, Wartungsseiten-Erzeugung/-Pflege, Weiterleitungslogik, Admin-Oberfläche, Cleanup.

Für Entwickler

Wartungsseite als echte WordPress-Seite

Bei der ersten Aktivierung wird automatisch eine normale WordPress-Seite mit dem Slug maintenance-mode angelegt (weinhold_create_maintenance_page()), deren Inhalt aus den konfigurierten Zeitfenster- und Beschreibungstexten zusammengesetzt wird. Bei jeder Einstellungsänderung wird ihr Inhalt aktualisiert (weinhold_update_maintenance_page()). Beim Deaktivieren wird die Seite bewusst NICHT gelöscht, sondern bleibt erhalten (eigener Löschen-Button in der Admin-Oberfläche für den expliziten Fall).

Ablauf

Hängt an template_redirect. Reihenfolge: Ist das Endzeitfenster bereits erreicht, wird der Wartungsmodus automatisch deaktiviert und die Funktion bricht ab. Dann werden Systempfade (Admin, AJAX, REST, XML-RPC, Cron sowie fest ausgenommene technische Pfade wie wp-login.php, wp-json, robots.txt) immer durchgelassen. Danach greift die Admin-Ausnahme, die allow_logged_in-Ausnahme und zuletzt die konfigurierten Ausnahmepfade. Bleibt keine Ausnahme übrig, liefert die Wartungsseite selbst HTTP 503 mit Retry-After-Header, alle anderen URLs werden per 302 dorthin weitergeleitet.

Einstellungen (Option weinhold_maintenance_mode_settings)

Schlüssel	Bedeutung
enabled	Wartungsmodus aktiv
allow_logged_in	Alle eingeloggten Nutzer zusätzlich zu Administratoren durchlassen
start_date,end_date	Optionales Zeitfenster
description	Freitext, der auf der Wartungsseite erscheint
page_id	ID der automatisch erzeugten Wartungsseite
exception_page_ids,exception_custom_paths	Ausgenommene Seiten bzw. frei eingegebene Pfade

Besonderheiten

Weder IP-basierte noch rollenbasierte Ausnahmen vorhanden – Bypass funktioniert ausschließlich über Administratorrechte, die allow_logged_in-Option (alle eingeloggten Nutzer pauschal) und Pfad-Ausnahmen. Eine feingranulare Steuerung nach Rolle oder IP-Adresse gibt es nicht.

HTTP-Statuscode ist korrekt 503 (nicht 200 oder 302) mit Retry-After-Header, wenn die Wartungsseite direkt aufgerufen wird – wichtig für Suchmaschinen, damit die Seite währenddessen nicht aus dem Index fällt. Bei allen anderen URLs erfolgt dagegen ein 302-Redirect zur Wartungsseite.

Das andere 404-Weiterleitungs- und das Login-Redirect-Modul prüfen jeweils selbst, ob der Wartungsmodus aktiv ist, und greifen dann nicht ein – die Module sind bewusst so verzahnt, dass Wartungsmodus stets Vorrang hat.

Versionshistorie

Version	Datum	Änderung
1.0.0	22.09.2026	Einführung der Versionierung.

Maintenance Mode

The Maintenance Mode module puts a subsite into maintenance mode. Visitors are redirected to an automatically created, configurable maintenance page — administrators continue to see the normal site by default and can work undisturbed.

General

Schedule

Maintenance mode can be given an optional start and end time. Before the start, the site remains normally reachable despite the checkbox being enabled; after the end time, maintenance mode automatically switches itself off again on the next page load.

Exceptions

Specific WordPress pages (via a checklist) or freely entered paths can be excluded from maintenance mode — e.g. a contact page or a webhook endpoint that must remain reachable. You can additionally allow all logged-in users to see the site normally via a checkbox (not just administrators, who always get through regardless).

Preview & Testing

A special preview link (?weinhold_maintenance_preview=1) forces maintenance mode only for your own request, without activating it for all other visitors — for a quick check of the maintenance page.

Configuration

Everything is configured in the dashboard under Weinhold → Maintenance Mode. No shortcode needed — the module works fully automatically.

Files

modules/maintenance_mode.php – the module’s only file: settings, maintenance page creation/updates, redirect logic, admin UI, cleanup.

For Developers

The Maintenance Page Is a Real WordPress Page

On first activation, a normal WordPress page with the slug maintenance-mode is automatically created (weinhold_create_maintenance_page()), its content assembled from the configured time window and description text. On every settings change, its content is updated (weinhold_update_maintenance_page()). On deactivation, the page is deliberately NOT deleted, it’s kept around (a separate delete button in the admin UI covers the explicit case).

Flow

Hooks into template_redirect. Order: if the end time window has already passed, maintenance mode is automatically disabled and the function returns. Then system paths (admin, AJAX, REST, XML-RPC, cron, plus fixed technical paths like wp-login.php, wp-json, robots.txt) are always let through. Next comes the admin exception, the allow_logged_in exception, and finally the configured exception paths. If none apply, the maintenance page itself returns HTTP 503 with a Retry-After header; all other URLs are redirected there via 302.

Settings (Option weinhold_maintenance_mode_settings)

Key	Meaning
enabled	Maintenance mode active
allow_logged_in	Let all logged-in users through in addition to administrators
start_date,end_date	Optional time window
description	Free text shown on the maintenance page
page_id	ID of the automatically created maintenance page
exception_page_ids,exception_custom_paths	Excluded pages or freely entered paths

Special Cases

No IP-based or role-based exceptions exist — bypass works purely through administrator rights, the allow_logged_in option (all logged-in users at once), and path exceptions. There’s no fine-grained control by role or IP address.

The HTTP status code is correctly 503 (not 200 or 302) with a Retry-After header when the maintenance page itself is requested directly — important for search engines, so the site doesn’t fall out of the index in the meantime. All other URLs instead get a 302 redirect to the maintenance page.

The 404-redirect and login-redirect modules each check themselves whether maintenance mode is active and back off if so — the modules are deliberately interlocked so maintenance mode always takes precedence.

Version History

Version	Date	Change
1.0.0	22.09.2026	Introduction of versioning.

maintenance-mode