Das sichtbare Problem war nicht die Ursache
Nach dem Wechsel auf PHP 8 verlor das Forum unregelmäßig neue Beiträge und Einstellungen. Backups mussten zurückgespielt werden. Einzelne Schreibvorgänge funktionierten scheinbar, weshalb ein UI-Fehler oder ein bestimmtes Formular als Ursache nahelag.
Die Diagnose begann deshalb mit Reproduktion unter Konkurrenz. Mehrere simulierte Schreiber erzeugten parallel Beiträge. Das Ergebnis war eindeutig: Von 360 erzeugten Beiträgen blieben im Ausgangszustand null dauerhaft erhalten. Diese Zahl beschreibt einen gezielten Testaufbau. Sie ist keine Aussage darüber, dass im realen Forum jeder Beitrag verloren ging.
Im Bestand fanden sich zwei zusammenwirkende Ursachen. Ein automatisches Migrationswerkzeug hatte beim PHP-8-Umbau 73 Ausdrücke falsch verändert. Dadurch lief Wartungslogik bei jedem Seitenaufruf über die dateibasierte Ablage. Gleichzeitig konnten mehrere Requests dieselben Dateien ohne ausreichende Sperren verändern. Der sichtbare Datenverlust entstand aus dem Zusammenspiel von übermäßig häufigem Schreiben und unsicheren Parallelzugriffen.
Atomar schreiben heißt auch, den alten Betrieb zu verstehen
phpFK speichert zentrale Daten in Dateien und lief auf bestehendem Shared Hosting. Eine sofortige Migration auf Datenbank, neues Framework und neue Infrastruktur hätte viele Variablen gleichzeitig verändert. Zuerst musste der aktuelle Betrieb sicher werden.
Die Korrektur baut neue Inhalte vollständig in einer temporären Datei auf, synchronisiert sie und ersetzt anschließend die Zieldatei atomar. Sperren verhindern, dass parallele Schreiber denselben Stand gleichzeitig überschreiben. Fehlerhafte Wartungsaufrufe wurden auf die vorgesehenen Bedingungen zurückgeführt.
Im identischen Paralleltest blieben danach 360 von 360 Beiträgen erhalten. Das ist ein starker, weil reproduzierbarer Vorher/Nachher-Beleg. Trotzdem wird daraus keine unbegrenzte Skalierungsaussage. Andere Dateien, Dateisysteme oder Serverlast können eigene Grenzen haben. Der Test beantwortet präzise die Frage, ob dieser bekannte Konkurrenzfehler im nachgestellten Ablauf weiter auftritt.
Modernisierung ohne Komplettaustausch
Erst nach der Stabilisierung folgte der Stil „sector“. Navigation, Seitenbreite, Beitragsaufbau, Suchzugang und mobile Ansichten wurden neu geordnet. Neue Funktionen wie Abzeichen, „Gefällt mir“, Geburtstagsansicht und Newsletter fügen sich in den bestehenden Betrieb ein.
Der Entwurf musste eine Besonderheit respektieren: Das Forum ist nicht nur eine Sammlung aktueller Seiten. Es ist ein über Jahre gewachsenes Archiv mit vertrauten Wegen, Rollen, Zitaten, Bildern und individuellen Signaturen. Ein radikaler Neustart hätte technische Altlasten reduziert, aber auch URLs, Gewohnheiten und Community-Kontext gefährdet.
Die Umsetzung verändert deshalb in Schichten. Ein neuer Stil kann live gehen, während Kernabläufe und Datenformat erhalten bleiben. Spätere technische Arbeiten lassen sich getrennt priorisieren. Das ist langsamer als ein vollständiger Neubau auf leerem Papier, reduziert aber das Migrationsrisiko.
Warum die Website keinen ungeprüften Vorher/Nachher-Screenshot zeigt
Die vorhandenen Entwicklungsaufnahmen enthalten Mitgliedsnamen, Profilbilder und konkrete Beiträge. Sie sind als internes Arbeitsmaterial geeignet, aber nicht automatisch als öffentliches Portfolioasset. Ein Vergleichsbild erscheint hier erst, wenn eine geschwärzte Fassung freigegeben ist.
Für die Veröffentlichung braucht es entweder eine freigegebene Aufnahme, eine sorgfältig redigierte Fassung oder einen neu erzeugten Zustand mit Testdaten. Der neutrale Header belegt bereits den visuellen Kontext. Er ersetzt jedoch nicht den technischen Nachweis, der aus Reproduktion, Korrektur und wiederholtem Paralleltest besteht.
Was diese Arbeit für ähnliche Aufträge zeigt
Die Fallstudie zeigt, wie CIDIX mit geschäftskritischem Altbestand umgeht: zuerst Verhalten beobachten, dann die kleinste belastbare Ursache isolieren, den Datenpfad absichern und erst danach die sichtbare Modernisierung ausrollen.
Nicht jedes alte System sollte erhalten bleiben. Die Entscheidung hängt von Datenwert, Integrationen, Betriebszugang und Migrationsrisiko ab. Beim 914-Forum war die schrittweise Reparatur auf vorhandenem Hosting der passende Weg. Bei einem neuen Auftrag werden diese Randbedingungen dokumentiert und Reparatur, Teilmigration und Neubau anhand derselben Risiken verglichen.