Zusammenfassung des bisherigen Verlaufs

1. Admin-Layout und Navigation

Das Admin-Menü wurde logisch sortiert und bereinigt. Ziel war eine klarere Struktur im ACP, ohne bestehende Funktionen zu zerstören.

Reihenfolge im Menü: Dashboard, Statistik, Audit, Seiten, Beiträge, Projekte, Downloads, Einstellungen.

2. Einstellungen-Seite mit Tabs

Die Seite /admin/settings war zu unübersichtlich. Deshalb wurde ein Tabsystem eingeführt.

Die Tabs wurden in Bereiche aufgeteilt:

Allgemein
Hero
Branding

Dafür wurde eine zusätzliche CSS-Datei verwendet, damit das bestehende admin.css nicht beschädigt wird.

3. Fehler bei den Tabs

Die Tabs ließen sich anfangs nicht wechseln, weil das Umschalten nur über JavaScript funktionierte und das Script nicht sauber geladen oder ausgeführt wurde.

Daraufhin wurde das Tab-JavaScript in eine eigene Datei ausgelagert.

4. Fehler bei URL-Validierung in den Einstellungen

Beim Speichern der Einstellungen trat mehrfach der Fehler „ungültige url“ auf.

Ursache war nicht das Tabsystem selbst, sondern die Backend-Validierung in /src/service/settingsService.js.

Leere optionale URL-Felder wurden wie Pflichtfelder behandelt.

Die Datei wurde so angepasst, dass:

optionale URLs leer sein dürfen,
interne Pfade mit / erlaubt sind,
logo_url, favicon_url und hero_button_secondary_url korrekt behandelt werden.

5. Problem mit Logo/Favicon

Zwischendurch wurden Logo und Favicon beim Speichern gelöscht.

Ursache: Die Felder waren auf disabled gesetzt und wurden dadurch nicht mitgesendet.

Das Verhalten wurde korrigiert, damit bestehende Werte erhalten bleiben.

6. Branding-Upload im Settings-Bereich

Der Upload für Logo / Favicon sollte logisch in den Bereich Branding verschoben werden.

Das wurde in der Oberfläche umgesetzt. Dabei gab es den Hinweis, dass verschachtelte <form>-Elemente technisch unsauber sind und später sauber getrennt werden sollten.

7. Öffentliche main.hbs überarbeitet

Die Datei main.hbs der Website wurde strukturell bereinigt.

Das Menü wurde logisch sortiert und der Code lesbarer gemacht.

Die sinnvolle Reihenfolge wurde auf etwa folgendes gebracht:

Home
News
Blog
Projekte
Downloads
dynamische Menüeinträge

8. CMS-Name und Versionierung

Das CMS bekam einen vorläufigen Arbeitsnamen: Sitevra CMS.

Der Name ist aktuell nur ein Arbeitsname und kann später geändert werden.

Zusätzlich wurde eine Versionslogik eingeführt:

eigene Versionsdatei,
Abgleich beim Start des Node-Servers,
Übernahme neuer Versionsdaten in die Datenbank, wenn die Datei aktueller ist.

9. Versionsanzeige im Admin-Dashboard

Im Dashboard sollte ein neuer Bereich erscheinen, der die CMS-Daten anzeigt:

CMS-Name
Version
Release
letzter DB-Abgleich

Dafür wurden passende Settings vorbereitet:

cms_name
cms_version
cms_version_label
cms_released_at
cms_last_update_at

10. SQL-Erweiterung für bestehende Datenbank

Da die Datenbank bereits existierte, wurde nur das nötige INSERT IGNORE für die neuen CMS-Versions-Settings ausgegeben.

11. Hero-Bereich der Startseite

Die vier kleinen Bereiche rechts im Hero waren bisher starr im Template und nicht über das ACP steuerbar.

Das wurde als ungeeignet bewertet, weil ein veröffentlichbares CMS hier datenbankgebunden arbeiten muss.

11.1 Erste Umsetzung

Es wurde eine eigene Tabelle hero_cards vorgeschlagen und umgesetzt, damit die rechten Hero-Boxen nicht als einzelne Settings missbraucht werden.

Zusätzlich kamen:

Model für Hero-Karten,
Service für Hero-Karten,
eigene Admin-Routen,
eigene Admin-Views für Liste und Bearbeitung.

11.2 Aktueller Stand

Die Hero-Karten liegen aktuell separat und nicht direkt in /admin/settings.

Das wurde als technisch sauberer Schnellweg umgesetzt, obwohl der Wunsch war, alles unter Einstellungen zu bündeln.

Später kann das Frontend im ACP wieder unter einem gemeinsamen Settings-Tab zusammengeführt werden, während die DB-Struktur getrennt bleibt.

12. Problem mit Hero-Icons

Aktuell waren die Hero-Icons zunächst hart im Code definiert.

Das wurde als ungeeignet für eine Veröffentlichung erkannt, weil andere Benutzer dafür sonst den Code anpassen müssten.

Als bessere Lösung wurde festgehalten:

Icons aus Dateien laden,
z. B. aus /public/icons/hero/,
im ACP auswählbar machen,
später idealerweise auch per Upload verwaltbar machen.

13. server.js und Versionsabgleich

Zwischendurch fiel auf, dass der Versionsabgleich in einer späteren server.js-Fassung wieder verschwunden war.

Das wurde korrigiert. Danach wurde die bestehende Version mit cmsVersionService.syncWithDatabase() wieder als richtige Basis bestätigt.

Anschließend sollte zusätzlich die Hero-Route sauber in dieselbe server.js eingebunden werden.

14. Allgemeines Arbeitsmuster

Es wurde mehrfach betont, dass Änderungen immer als komplette Dateien im Codeblock ausgegeben werden sollen und nicht als Download oder als unvollständige Patches.

Außerdem wurde darauf geachtet, bestehende Styles und Funktionen möglichst nicht unnötig zu zerstören.

Aktueller Gesamtstand

Sitevra CMS hat jetzt:

einen vorläufigen Namen,
eine Versionslogik mit DB-Abgleich beim Start,
eine überarbeitete Settings-Seite mit Tabs,
eine bereinigte öffentliche main.hbs,
einen DB-basierten Ansatz für die rechten Hero-Karten,
und die Grundlage für eine spätere saubere Veröffentlichungsstruktur.

Offen bzw. als nächster sinnvoller Schritt bleiben:

Hero-Karten wieder optisch in die Settings integrieren,
Hero-Icons dateibasiert und uploadbar machen,
den Hero-Hauptbereich links ebenfalls sauberer aus den Global-Settings herauslösen oder besser strukturieren.