VZC System v.3.7.4 - Warum Performance-Tools manchmal die schlimmsten Feinde sind

Es gibt Momente in der Entwicklung, da starrt man auf den Bildschirm und versteht die Welt nicht mehr. Unser News-Manager der tief im Backend von vzcsystem.at eigentlich bis heute immer perfekt war, hat heute Morgen schlichtweg die Arbeit verweigert.

Metadaten wie Titel oder Autor wurden zwar noch geladen, aber der eigentliche Content – die Text- und Bildblöcke im Story Builder – blieben leer. Wer versuchte, etwas zu veröffentlichen, produzierte nur digitale Leere!

Die Fehlersuche: Von Zeichenkodierung bis zum JS-Desync

Zuerst vermuteten wir ein Problem in der internen Logik. Wir haben den Code auf JavaScript-Ebene analysiert, um ID-Kollisionen auszuschließen.

Dabei haben wir direkt zwei Sicherheitsnetze eingezogen:

• Zufalls-IDs im JS-Editor: Um doppelte Container zu verhindern, generiert das System nun kryptografische Zufalls-IDs für jeden Block.
• Bild-Synchronisation: Der "uploadIdx" wurde korrigiert, um den Desync zwischen dem Hochladen im Frontend und der Verarbeitung im Backend zu eliminieren.

Doch der Editor blieb leer. Die nächste Vermutung: BOM (Byte Order Mark). Unsichtbare Zeichen am Dateianfang verhinderten, dass unser PHP-Parser die Header wie "TITEL:" oder "DATUM:" korrekt matchen konnte. Wir haben daraufhin eine robuste Filterung implementiert:

Zusätzlich erzwingen wir nun eine saubere UTF-8-Konvertierung, um Encoding-Problemen vorzubeugen.

Die finale Erkenntnis: Der Rocket Loader als Saboteur

Nachdem wir sogar überlegten, das gesamte System auf ein JSON-basiertes State-Management umzustellen, kam der entscheidende Hinweis: Die kürzliche Aktivierung von Cloudflare.

Eigentlich soll der Rocket Loader von Cloudflare die Ladezeiten optimieren, indem er JavaScript asynchron lädt. Doch bei komplexen Editoren wie Quill.js führt das zur Katastrophe. Der Editor versuchte den Inhalt zu laden, bevor die notwendigen Skripte überhaupt bereit waren, oder wurde von Cloudflares Optimierung schlicht blockiert.

„Es ist die klassische Ironie der Webentwicklung: Ein Tool, das die Performance verbessern soll, zerstört die Ausführungsreihenfolge eines hochsensiblen Editors.“

Die Lösung und dauerhafte Absicherung

Die Lösung war so simpel wie effektiv: Wir haben den Rocket Loader deaktiviert und den Cache einmal komplett geleert („Purge Everything“). Damit das System für Besucher schnell bleibt, aber für uns im Backend stabil arbeitet, wurden spezifische Page Rules eingerichtet. Diese schalten jegliche Performance-Optimierungen und das Caching in unserem Bereich aus.

Ehrlich gesagt, waren das Stunden purer Frustration. Jede Datei, jede Zeile PHP und HTML wurde seziert, nur um am Ende festzustellen, dass eine „Optimierung“ im Netzwerk-Layer alles lahmgelegt hat. Aber genau das macht Technik aus: Man lernt erst dann richtig, wie stabil ein System ist, wenn man es unter Druck reparieren muss. Der News-Editor läuft jetzt stabiler als je zuvor, inklusive „Notfall-Airbag“ im Code.