Field Note: Wie ich ein unbekanntes WordPress-System übernehme

Bei einem unbekannten WordPress-System ändere ich nicht als Erstes Plugins oder Updates. Ich versuche zunächst zu verstehen, was miteinander verbunden ist.

Diese Zurückhaltung musste ich mir erst angewöhnen. Wenn ein Backend unordentlich aussieht, ist der Impuls naheliegend: veraltete Erweiterungen entfernen, Einstellungen vereinheitlichen, Updates einspielen. Aber eine sichtbare Unordnung sagt noch nicht, welche Teile entbehrlich sind. Ein Plugin kann unscheinbar wirken und trotzdem Daten, Formulare, Rollen oder einen externen Prozess zusammenhalten.

Warum ich zunächst nichts ändere

Ich behandle eine übernommene Installation nicht zuerst als Aufräumprojekt, sondern als ein System, dessen Zusammenhänge noch unbekannt sind. Mein erster Auftrag an mich selbst lautet: beobachten, fragen, nachzeichnen.

Das heißt nicht, dass ich Probleme ignoriere. Wenn sich ein konkretes Risiko zeigt, muss ich es einordnen und gegebenenfalls handeln. Aber „das sieht alt aus“ ist für mich noch keine ausreichende Begründung für eine Änderung. Ein Eingriff kann Funktionen unterbrechen, die im Backend nicht offensichtlich sind oder von Menschen außerhalb der Website genutzt werden.

Je weniger ich über eine Installation weiß, desto kleiner halte ich deshalb den ersten Schritt. Ich will unterscheiden können, was ich vorgefunden habe und was ich selbst verändert habe. Sonst wird es später schwierig, Ursache und Wirkung auseinanderzuhalten.

Was ich zuerst prüfe: Datenmodell, Rollen und externe Abhängigkeiten – nicht das Theme.

Inventur: Was ist tatsächlich Teil des Systems?

Ich beginne mit einer Bestandsaufnahme. Dazu gehören Plugins und Themes, aber ebenso eigene Inhaltstypen, Taxonomien, Benutzerrollen, geplante Aufgaben, Schnittstellen und externe Dienste. Ich frage nicht nur: „Was ist installiert?“, sondern auch: „Welche Aufgabe erfüllt dieser Teil – und wer oder was verlässt sich darauf?“

Bei Plugins achte ich darauf, ob sie sichtbare Funktionen bereitstellen, Daten verwalten, Inhalte verbinden oder Prozesse auslösen. Ein Plugin kann im Frontend kaum auffallen und trotzdem zentral für einen Import, ein Formular oder eine API sein. Umgekehrt bedeutet eine lange Plugin-Liste nicht automatisch, dass jede Erweiterung kritisch ist. Entscheidend ist ihre Rolle im Gesamtsystem.

Auch eigene Post Types und Taxonomien gehören in diese Inventur. Sie zeigen oft, dass WordPress nicht nur Seiten und Beiträge verwaltet, sondern ein bestimmtes Datenmodell abbildet. Rollen und Rechte geben Hinweise darauf, wer welche Aufgaben im System erledigt. Cronjobs und externe Schnittstellen können wiederum Prozesse markieren, die nicht durch einen sichtbaren Klick im Backend gestartet werden.

Ich notiere zunächst, was ich sicher weiß, was ich vermute und was noch offen ist. Diese Unterscheidung ist wichtig: Eine Vermutung darf nicht stillschweigend zur Grundlage für einen Umbau werden.

Abhängigkeiten, die das Backend nicht zeigt

Das Backend zeigt nur einen Teil des Systems. Daneben kann es Anwendungen, Datenquellen, externe Dienste oder manuelle Arbeitsschritte geben. Eine Schnittstelle kann Daten an eine App liefern. Ein Import kann Inhalte anreichern, die anschließend von jemandem geprüft werden. Ein Formular kann Folgearbeit außerhalb von WordPress auslösen.

Ich versuche deshalb, den Weg der Daten in beide Richtungen zu verfolgen: Wo entstehen sie? Wo werden sie gespeichert? Wer oder was verarbeitet sie weiter? Und woran erkennt jemand, dass der Prozess abgeschlossen ist?

Bei Wendewerk ist WordPress beispielsweise eine Plattform für Krankenkassen- und Leistungsdaten. Dazu gehören ein Datenmodell in ACF-Feldern, verschiedene Rollen, Besucher-Tools und eine token-authentifizierte REST-API für eine App. Außerdem werden Satzungstexte KI-gestützt extrahiert; vor dem Zusammenführen gibt es ein Staging und einen Review-Schritt. Das Beispiel macht für mich greifbar, warum eine Plugin-Liste allein kein Bild des Systems ergibt: Daten, Berechtigungen, Prüfungen und externe Nutzung gehören zusammen.

Solche Zusammenhänge frage ich nach, statt sie aus der Oberfläche abzuleiten. Mit wem spreche ich, wenn eine Funktion unklar ist? Welche Arbeit geschieht nach dem Speichern eines Inhalts? Gibt es eine Person, die Importe oder Freigaben begleitet? Menschen, die mit dem System arbeiten, kennen oft Abläufe, die in keiner technischen Übersicht stehen.

Das Datenmodell und die Arbeit der Menschen verstehen

Bevor ich etwas ersetze oder entferne, möchte ich wissen, welche Dinge das System überhaupt abbildet. Sind Inhalte einfache Seiten, oder gibt es eigenständige Objekte mit Beziehungen und bestimmten Feldern? Welche Informationen sind Pflicht? Welche Werte kommen aus einer Quelle, welche werden redaktionell gepflegt? Und welche Verknüpfungen hängen an IDs, Slugs oder Taxonomien?

Das ist keine abstrakte Modellierungsübung. Wenn ich das Datenmodell nicht verstehe, kann ich schwer beurteilen, ob eine Erweiterung wirklich überflüssig ist oder ob sie eine wichtige Verbindung herstellt. Auch ein scheinbar kleiner Umbau kann beeinflussen, wie Daten gesucht, exportiert, angezeigt oder über eine Schnittstelle weitergegeben werden.

Genauso wichtig ist der menschliche Ablauf. Ich frage nach den Schritten vor und nach einer Änderung: Wer liefert Informationen? Wer prüft sie? Wer darf sie freigeben? Was passiert, wenn etwas unvollständig ist? Ein System kann technisch funktionieren und trotzdem auf stille Absprachen oder manuelle Kontrollen angewiesen sein. Wenn ich diese Arbeit übersehe, entferne ich möglicherweise nicht nur Technik, sondern auch einen Teil des tatsächlichen Prozesses.

Was ich festhalte – und wann ich ändere

Meine Notizen sollen nicht jede Einstellung beschreiben. Sie sollen die Entscheidungen vorbereiten, die später anstehen. Ich halte fest, welche Komponenten welche Aufgabe haben, welche Datenflüsse ich nachvollziehen konnte, welche Rollen beteiligt sind und welche Abhängigkeiten noch ungeklärt sind. Dazu gehören auch offene Fragen und Annahmen, die noch überprüft werden müssen.

Erst wenn dieses Bild ausreichend klar ist, entscheide ich, ob etwas gelöscht, ersetzt oder umgebaut werden sollte. Dann formuliere ich die Änderung möglichst konkret: Was soll sich ändern? Welche Funktion oder Daten könnten betroffen sein? Wie prüfe ich nachher, ob das Ergebnis stimmt? Für mich gehört der Nachweis zur Änderung dazu. Eine Anpassung ist nicht allein deshalb gelungen, weil sie technisch umgesetzt wurde.

Das bedeutet nicht, dass ich alles unangetastet lasse oder jede gewachsene Lösung dauerhaft akzeptiere. Manche Teile lassen sich vereinfachen, andere müssen neu geordnet werden. Der Unterschied liegt im Zeitpunkt und in der Begründung: Ich räume nicht auf, um ein Backend auf den ersten Blick ordentlicher aussehen zu lassen. Ich ändere etwas, wenn ich verstanden habe, welche Aufgabe es erfüllt und woran sich die Wirkung prüfen lässt.

Inzwischen ist diese Reihenfolge für mich selbstverständlich: erst den Zustand erfassen, dann eine begrenzte Änderung planen und schließlich prüfen, was sie bewirkt. Bei einem unbekannten WordPress übernehmen heißt für mich deshalb nicht, möglichst schnell Kontrolle durch Eingriffe zu zeigen. Es heißt, zuerst genug Kontrolle über die Zusammenhänge zu gewinnen.

Meine Faustregel: Je unordentlicher ein WordPress-System aussieht, desto weniger räume ich am ersten Tag auf. Erst verstehen, was verbunden ist – dann entscheiden, was sich ändern darf.

Weiterführend

• Field Note: Was eine gute Übergabe enthält
• WordPress technisch dokumentieren
• Know → Change → Prove: Wie WordPress-Änderungen sicher werden