Customer Baseline

Zentrales Plugin für die WordPress-Basis-Konfiguration aller Kunden- Installationen. Ziel: unnötigen Ballast entfernen und Betriebsverhalten (Update-Mails, Revisionslimit) einheitlich steuern — zentral gepflegt statt als Sammlung einzelner Snippets pro Site, mit automatischen Updates über GitHub.

Hinweis zur Architektur: Das ist bewusst ein reguläres Plugin, kein Must-Use-Plugin. Grund: MU-Plugins nehmen nicht am WordPress-Update- Mechanismus teil — es gibt für sie keine automatische Update-Erkennung. Da sowohl InfiniteWP als auch das Plesk WordPress Toolkit ihre Bulk-Update-Funktionen über den normalen WP-Update-Mechanismus abwickeln, ist ein reguläres Plugin hier der einzige Weg zu "Update kommt automatisch auf allen ~100 Sites an". Trade-off: ein reguläres Plugin könnte theoretisch über die Plugins-Seite deaktiviert werden — bei zentral über InfiniteWP/Plesk verwalteten Sites ist dieses Risiko in der Praxis gering.

Einmalige Einrichtung (vor dem ersten Rollout)

1. GitHub-Repository customer-baseline unter github.com/beniafe anlegen (öffentlich, da keine sensiblen Daten enthalten sind — vermeidet die Verwaltung von Zugriffs-Tokens für private Repos).
2. Code committen und pushen.
3. Ein GitHub-Release mit Tag passend zur aktuellen Version erstellen (Version im Plugin-Header und im Tag müssen übereinstimmen).

Einstellungen pro Website

Unter Einstellungen → Customer Baseline gibt es drei Bereiche:

Immer aktiv (grün, Punkte 1–6): reine Infoliste, nicht abschaltbar (Emoji-Support, Feed-Links, RSD-Link, Shortlink, oEmbed-Discovery, Generator-Tag).

Betriebsentscheidungen (gelb, Punkte 7–10): vier Ein/Aus-Schalter, alle standardmäßig aktiv (Ein):

• Update-Benachrichtigungs-Mails unterdrücken (Core, Plugins, Themes) — betrifft nur Erfolgsmeldungen, Fehlschläge werden immer zugestellt
• Admin-E-Mail-Check-Erinnerung abschalten
• Revisionslimit aktivieren (fest auf 5 Versionen)
• Kein automatisches Bundled-Theme bei Core-Updates

Nur nach Prüfung (rot, Punkte 11–19): neun Ein/Aus-Schalter mit erklärendem Text direkt auf der Einstellungsseite, gemischte Defaults:

Zusätzlich fest aktiv (grün, kein Schalter):

• Punkt 21: Selbst-Pingbacks deaktivieren
• Punkt 22: Generische Login-Fehlermeldung

Hinweis zu Punkt 20-22: Laufen bewusst parallel zum auf allen Sites installierten iThemes-/Solid-/Kadence-Security-Plugin, das dieselben Funktionen ebenfalls bietet. Die Dopplung ist gewollt, damit die Einstellung nicht von der Security-Plugin-Konfiguration der jeweiligen Site abhängt.

Hinweis zu den Revisionen: Das Limit wirkt nur auf künftig gespeicherte Revisionen. Bereits in der Datenbank vorhandene, überzählige Revisionen werden dadurch nicht rückwirkend gelöscht — das ist ein separater Bereinigungsschritt (noch offen).

Hinweis zu Punkt 12: Ursprünglich als "REST API einschränken" im Maßnahmenkatalog geführt, aber bewusst auf einen konkreten, risikoarmen Fall verengt (Sperren der Nutzerauflistung für nicht eingeloggte Anfragen), statt die REST API pauschal einzuschränken.

Hinweis zu Punkt 14 (Heartbeat-API): Noch nicht umgesetzt, da unklar ist, wie sich das pro Website sauber verifizieren lässt. Sobald ein konkretes Verhalten feststeht (z. B. Heartbeat nur im Editor zulassen), wird der Punkt ergänzt.

Struktur

customer-baseline/
├── customer-baseline.php        <- Haupt-Plugin-Datei (Header, Update-Checker, Modul-Loader)
├── plugin-update-checker/        <- Bibliothek von Yahnis Elsts (github.com/YahnisElsts/plugin-update-checker)
├── modules/
│   ├── settings.php              <- Einstellungsseite + Helper-Funktionen
│   ├── cleanup.php                <- Punkte 1-6 (fest) + 15-18 (optional)
│   ├── updates.php                <- Punkte 7, 8, 10
│   ├── revisions.php              <- Punkt 9
│   ├── feeds.php                  <- Punkt 11 (optional)
│   └── security.php               <- Punkte 12, 13, 19 (optional)
└── README.md

Kein Unterordner-Problem mehr wie bei MU-Plugins: reguläre Plugins dürfen beliebig viele Unterordner haben, WordPress lädt nur die im Plugin-Header benannte Hauptdatei.

Rollout auf ~100 Sites

Erstinstallation (einmalig pro Site):

• ~50 Sites über InfiniteWP: Plugin als ZIP hochladen und auf die gewünschten Sites verteilen (Bulk-Install), danach einmalig aktivieren.
• Sites über Plesk WordPress Toolkit (2 Instanzen): Ein "Plugin Set" mit dem hochgeladenen Plugin anlegen und per Ein-Klick-Installation auf die ausgewählten WordPress-Installationen ausrollen.

Updates (laufend): Sobald ein neues GitHub-Release getaggt ist, erkennt WordPress auf jeder Site automatisch die neue Version — sichtbar und bulk-aktualisierbar direkt über die normale Update-Funktion von InfiniteWP bzw. Plesk WordPress Toolkit. Kein manuelles Nachziehen pro Site mehr nötig.

Enthaltene Module (Stand v1.3.0)

Wichtig zu Feeds: cleanup.php entfernt nur die Feed-Links aus dem <head> (Punkt 2, fest aktiv). Das komplette Abschalten der Feed- Endpunkte selbst ist Punkt 11 in feeds.php, separat und standardmäßig aus.

Wartung (Werkzeuge → Customer Baseline Wartung)

Vier getrennte, manuell auszulösende Buttons (jeweils mit Bestätigungs- Dialog, nie automatisch):

• Alle Plugins: Auto-Updates aktivieren: setzt einmalig "Automatische Updates aktivieren" für alle aktuell installierten Plugins (derselbe Options-Wert, den WordPress sonst manuell pro Plugin setzt). Kein dauerhafter Automatismus/Filter — einzelne Plugins lassen sich danach jederzeit ganz normal über die Plugins-Seite manuell wieder abschalten.
• Alle Themes: Auto-Updates aktivieren: analog für Themes.
• Sprachdateien bereinigen: zeigt alle gefundenen Sprachen außer Deutsch mit Dateianzahl. Standardmäßig sind alle nicht angehakt (= werden gelöscht) — gezielt anhaken, was behalten werden soll. Deutsch (de_DE, inkl. Varianten wie de_DE_formal) wird nie gelöscht und taucht daher gar nicht erst in der Liste auf. Betrifft das Dateisystem (wp-content/languages/, .../plugins/, .../themes/), nicht die Datenbank.
• Revisionen kürzen: löscht bestehende, überzählige Revisionen (mehr als 5 pro Beitrag) aus der Datenbank. Läuft in Schritten von maximal 300 pro Klick, um Zeitüberschreitungen auf großen Websites zu vermeiden — bei Bedarf mehrfach klicken, die Seite zeigt an, ob noch Beiträge mit Überzahl übrig sind.

Noch nicht enthalten

• Punkt 14 (Heartbeat-API): noch kein konkretes, verifizierbares Verhalten festgelegt.

Neues Release veröffentlichen

1. Version in customer-baseline.php (Header und die Konstante CUSTOMER_BASELINE_VERSION) anheben, z. B. auf 1.1.0.
2. Changelog unten ergänzen.
3. Committen, pushen, GitHub-Release mit Tag v1.1.0 erstellen.
4. WordPress erkennt das Update innerhalb von bis zu 12 Stunden automatisch (oder sofort über "Nach Updates suchen" auf der Plugins-Seite einer einzelnen Site).

SemVer-Konvention: 1.0.0 → 1.1.0 bei neuen Modulen, 1.0.1 bei Bugfixes.