Zum Hauptinhalt
Logimetriq

Projekt

LOGIMETRIQ Architecture v2: kontrollierter Rebuild auf WordPress

Die eigene Website als technisches Beispiel: Der Fall zeigt einen früheren Entwicklungsstand – mit getrennter Inhaltslogik, getesteten Änderungen und offen beschriebenem Reifegrad.

Reifegrad: Prototyp. Der gezeigte Stand ist lokal implementiert und umfangreich getestet. Produktionsdeployment und vollständige Legacy-Migration sind noch offen.

Ausgangslage

LOGIMETRIQ begann mit einer auf Finance und Market Desk ausgerichteten WordPress-Site. Darstellung und dauerhafte Site-Logik waren im Theme vermischt. Sechs Routinen konnten beim normalen Seitenaufruf unter bestimmten Voraussetzungen Optionen, Seiten, Metadaten oder Menüs verändern. Generische Ansichten für Seiten, Archive, Suche und Fehlerseiten fehlten. Auch die vorhandene lokale Installation war noch nicht als reproduzierbare Entwicklungsbasis überprüft.

Ziel

Die neue Ausrichtung lautet „Independent Data Research · Software · Education“. WordPress bleibt erhalten. Das Theme soll Inhalte darstellen, ein kleines Site-Plugin die dauerhafte Site- und Contentbasis tragen. Explizite Inhaltsidentitäten, versionierte Kandidaten und kontrollierte Migrationen machen Änderungen nachvollziehbar, ohne den vorhandenen Bestand pauschal umzudeuten.

Architektur und Umsetzung

Das Repository ist die verbindliche Quelle für Code, Inhaltskandidaten und technische Verträge; die WordPress-Datenbank hält den jeweils materialisierten Inhaltsstand. LocalWP dient als lokale Integrationsumgebung. Theme und Site-Plugin sind getrennt angebunden. Die sechs Routinen mit möglichen Datenbankänderungen beim Seitenaufruf wurden entfernt. Änderungen am Inhaltsbestand laufen stattdessen über einen ausdrücklich gestarteten CLI-Migrationspfad mit Zustandsprüfung und Bestätigung.

Die gemeinsame Navigation, Homepage und Readerbasis wurden responsiv erneuert. Spezialisierte Ansichten wählen öffentliche Inhalte ausschließlich lesend anhand ihrer expliziten Identität und ihres tatsächlichen Veröffentlichungsstatus aus. Bestehende Legacy-Inhalte werden dabei nicht automatisch als neu geprüfte Projekte oder Artikel behandelt.

Qualitätssicherung

Die lokale Arbeitsbasis wurde mit einem Datenbank-Backup und einer echten Wiederherstellung in einer separaten Testdatenbank überprüft. Hinzu kamen Prüfungen der WordPress-Coreintegrität, der bestehenden Routen und des Verhaltens ohne aktives Site-Plugin. Browserprüfungen umfassten unterschiedliche Bildschirmbreiten, Tastaturbedienung und die erhaltene dunkle Darstellung.

Die erste Inhaltsmigration wurde als Dry-run, bestätigter Apply und erneuter Apply geprüft: Der Dry-run schrieb nichts, der Apply erzeugte ausschließlich die geplanten Änderungen, die Wiederholung keine zusätzlichen. Diese Nachweise betreffen die lokale Migration der Site Identity und nicht öffentlicher Entwürfe. Sie belegen weder einen Produktionslaunch noch eine unabhängig reproduzierte Veröffentlichung. Die Ergebnisse sind in versionierten technischen Prüfprotokollen festgehalten; eine öffentliche Bereitstellung dieser Protokolle ist noch nicht entschieden.

Mein Beitrag

Ich habe Zielbild, Anforderungen und Akzeptanzkriterien festgelegt, den Umfang begrenzt sowie Architektur- und Designentscheidungen getroffen. Zu meinem Beitrag gehören die Prüfung der vorgelegten Ergebnisse, Review- und Freigabeentscheidungen sowie die Entscheidungen über die Übernahme der Änderungen. Die Implementierung entstand mit wesentlicher Unterstützung durch Coding-Agenten; ich beanspruche nicht, den gesamten Code manuell geschrieben oder jede Codezeile unabhängig geprüft zu haben.

AI-Unterstützung

Coding-Agenten erstellten Codeentwürfe und übernahmen wesentliche Teile der Implementierung. AI unterstützte außerdem Tests, Reviewarbeit und Dokumentation. Menschliche Anforderungen, Entscheidungen und Abnahmen blieben davon getrennt. Die Agenten erteilen keine inhaltliche Veröffentlichungsfreigabe; ein autonomes Publishing wurde nicht eingerichtet.

Ergebnis

Vorhanden sind eine neue responsive Websitebasis, die getrennte Theme-/Site-Plugin-Struktur, generische Reader- und Systemansichten sowie Templates für explizit verwaltete Inhalte. Der lokale Entwicklungsprozess, die technischen Prüfungen und die erste kontrollierte Inhaltsmigration sind dokumentiert. Der Umbau zeigt damit einen überprüfbaren Implementierungsstand auf dem bestehenden WordPress-System.

Grenzen

Produktionsdeployment und vollständige Legacy-Contentmigration sind noch offen. Weitere Inhalte benötigen eigene fachliche Freigaben. Die Browser- und Tastaturprüfungen sind keine WCAG-Zertifizierung; ein vollständiger Lighthouse-/Performance-Launchnachweis steht aus. Eine vollständig automatisierte Publishingengine gehört nicht zum erreichten Stand.