Patchen im Mehrmandantenbetrieb folgt einer einfachen Rechnung. Mehrere Portale auf einem gemeinsamen Kern zu betreiben, spart Pflegeaufwand, weil jede Verbesserung nur einmal anfällt. Dieselbe Rechnung gilt für Fehler: Ein Fehler in einer Vorlage ist kein Einzelfall, er steht in jeder Installation. Was das in der Praxis bedeutet, zeigt die Durchsicht, aus der die Fassung 1.0.127 des SEO CMS entstanden ist. Wie mehrere Websites auf einem Kern grundsätzlich funktionieren, beschreibt der Beitrag Ein System, viele Websites.
Ein Fehler, sieben Portale
Bei der Durchsicht fiel auf, dass das öffentliche Eintragsformular sich nicht abschicken ließ. Ursache war ein fehlendes Skript für die Auswahlfelder in Verbindung mit einem versteckten Pflichtfeld, das dadurch leer blieb. Der Browser bricht in diesem Fall ab, ohne dem Besucher etwas anzuzeigen. Den Mechanismus beschreibt der Beitrag Formulare ohne JavaScript.
Die betroffene Vorlage war in allen Portalen auf diesem Kern identisch. Das ist die gute und die schlechte Nachricht zugleich. Der Fehler stand in jedem Portal, und eine einzige geprüfte Fassung räumte ihn überall weg. Dieselbe Vorlage enthielt übrigens noch einen zweiten Serienfehler: Die Zählung für Matomo war mit einer festen Site-ID eingetragen, und sieben Portale meldeten ihre Eintragungsseite an dasselbe fremde Konto.
Systematisch suchen statt durchklicken
Zwei Suchläufe finden einen großen Teil dieser Fehlerklasse, ohne dass jemand jede Seite aufrufen muss.
Aufrufe gegen Definitionen
Alle statischen Methodenaufrufe im Code einsammeln und gegen die tatsächlich vorhandenen Methoden prüfen. So kam ein Aufruf ans Licht, den es nie gab: Die Moderationsseite prüfte den Sicherheitsschlüssel mit einer Methode, die in der zuständigen Klasse nicht existierte. Jedes Absenden auf dieser Verwaltungsseite endete mit einem Programmabbruch, Freigeben und Ablehnen waren unmöglich. Der Suchlauf fand außerdem einen Kommentar, der auf eine längst entfernte Methode verwies.
Ausgaben ohne Maskierung
Alle Vorlagen nach Stellen durchsuchen, die ein Datenbankfeld ohne Maskierung ausgeben. Gefunden wurden vier Stellen nach demselben Muster, alle in Listenfeldern, die die Redaktion füllt, etwa die Kurzfakten eines Lexikoneintrags. Eine spitze Klammer in einem solchen Feld führte der Browser als Markup aus, statt sie anzuzeigen. Im Lexikon der Website seo-cms.seo-manager.info betraf das sechs Einträge. Bei einem davon verschluckte ein geöffnetes script-Element den Rest der Zeile.
Beide Suchläufe dauern Minuten. Die Arbeit liegt darin, sie überhaupt anzustoßen und die Treffer einzeln zu bewerten. Nicht jeder Treffer ist ein Fehler: Manche Felder sollen bewusst HTML enthalten, etwa der Haupttext eines Beitrags. Für jede Fundstelle muss deshalb jemand entscheiden, ob dort Text oder Markup hingehört. Diese Entscheidung schreibst du am besten gleich in einen Kommentar an der Stelle, damit beim nächsten Suchlauf klar ist, dass die Stelle schon geprüft wurde.
Noch eine Frage offen?
In der gratis Sprechstunde beantworten wir Fragen zu SEO live, jeden ersten Samstag im Monat um 18 Uhr. Oder du rufst einfach an.
Die naheliegende Korrektur ist die gefährlichste
Bei den unmaskierten Ausgaben lag eine schnelle Lösung nahe: das Feld vor der Ausgabe mit strip_tags von Markup befreien. Das hätte in Einträgen, die HTML-Beispiele erklären, Teile des Satzes gelöscht, ohne Fehlermeldung und ohne dass es jemand bemerkt hätte. Ein Satz über das Canonical-Element hätte das Element einfach verloren. Die PHP-Dokumentation warnt selbst, dass strip_tags HTML nicht prüft und bei unvollständigen oder fehlerhaften Tags mehr entfernen kann als erwartet, und rät für den Schutz vor eingeschleustem Code zu htmlspecialchars [1].
Auch reines htmlspecialchars hätte nicht gereicht, weil ein Teil des Bestands seine Beispiele schon als Entities schreibt. Die wären dann doppelt maskiert worden. Der neue Helfer löst deshalb zuerst Entities auf und maskiert danach. Das entspricht dem Grundsatz von OWASP: Sollen Daten genau so erscheinen, wie sie eingegeben wurden, gehört in den HTML-Zusammenhang eine Entity-Kodierung [2].
Die Lehre daraus: Zu jedem Sammelpatch gehört ein Vergleich gegen den tatsächlichen Bestand. Zwei echte Zeilen aus zwei Seed-Dateien, durch beide Varianten der Korrektur geschickt, hätten in wenigen Minuten gezeigt, welche die richtige ist.
Was zur Auslieferung gehört
- eine neue Fassungsnummer, damit erkennbar ist, welche Installation hinterherhinkt,
- eine Liste der geänderten Dateien,
- die Angabe, was zur Laufzeit wirkt und was erst nach einem neuen Bau,
- eine Stichprobe nach dem Einspielen, an den Stellen, die korrigiert wurden.
Bei statisch erzeugten Seiten ist der dritte Punkt der Unterschied zwischen "sofort behoben" und "behoben, sobald gebaut wurde". Was in 1.0.127 und 1.0.128 im Einzelnen geändert wurde, steht im Beitrag SEO CMS 1.0.127 und 1.0.128, die Werkzeuge für Wartung und Diagnose unter Backend, Wartung und Diagnose. Wer eher eine klassische Website mit WordPress betreut, findet die Grundsätze der laufenden Pflege bei der WordPress Wartung.
Du betreibst mehrere Websites auf einem gemeinsamen Kern und willst deine Prüfroutine schärfen? In der gratis Sprechstunde sprechen wir über deine Abläufe.
- Organisation strip_tags. PHP-Handbuch, The PHP Group. Stand 31.10.2026. abgerufen am 31.10.2026
- Organisation Cross Site Scripting Prevention Cheat Sheet. OWASP. Stand 31.10.2026. abgerufen am 31.10.2026
Häufige Fragen
Lohnt sich ein gemeinsamer Kern trotzdem?
Nach unserer Erfahrung ja. Der Aufwand für eine Verbesserung fällt einmal an, und die Fehlerbehebung ebenso. Voraussetzung ist, dass Unterschiede zwischen den Portalen über Einstellungen laufen und der Programmcode frei von Sonderfällen bleibt.
Wie oft sollte man solche Suchläufe machen?
Vor jeder Auslieferung und nach jeder größeren Umbauarbeit. Beide dauern Minuten. Aufwendig ist nur, sie einmal sauber aufzuschreiben, damit sie jeder wiederholen kann.
Was tun, wenn ein Fehler schon Daten beschädigt hat?
Erst den Umfang feststellen, dann korrigieren. Wie viele Datensätze betroffen sind, beantwortet meist eine einzige Abfrage, und davon hängt ab, ob eine Korrektur genügt oder eine Sicherung zurückgespielt werden muss.
Warum reicht strip_tags nicht zum Absichern?
Die Funktion entfernt Tags, prüft aber kein HTML und kann bei fehlerhaften Tags mehr löschen als gewollt. Die PHP-Dokumentation empfiehlt zum Schutz vor eingeschleustem Code htmlspecialchars oder eine passende Maskierung für den jeweiligen Zusammenhang.
Noch eine Frage offen?
In der gratis Sprechstunde beantworten wir Fragen zu SEO live, jeden ersten Samstag im Monat um 18 Uhr. Oder du rufst einfach an.
Zuletzt geprüft am 03.11.2026, nächste Prüfung spätestens im November 2027. Fehler entdeckt? Schreib uns.
