Offizielle Neuentwicklung für WebsiteBaker - Brainstorming und Diskussion

[Tommy]

1. Einleitung
Ich wurde der Neuentwicklung von WebsiteBaker (WB) zugeteilt. Diese Arbeit hat keinen Einfluss auf die Entwicklung der aktuellen Versionen. Was folgt, ist das Ergebnis umfangreicher Überlegungen und Recherchen zu Problemen von WB und anderen CMS‑Systemen. Der Text dient als Diskussionsgrundlag e – nichts ist final.

2. Warum eine Neuentwicklung?
WB ist in die Jahre gekommen. Der Wartungsaufwand steigt, neue Features lassen sich nur schwer integrieren. Die Codebasis ist für ihr Alter solide, aber langfristig brauchen wir einen Ersatz, bevor WB 2.x an seine Grenzen stößt.

3. Grundprinzipien & Ziele
    • Sicherheit
    • Stabilität
    • Geschwindigkeit
    • Einfache Bedienbarkeit
    • Flexibilität ohne unnötige Komplexität
    • Weiterhin voll lauffähig auf klassischen Webhostern (PHP‑FPM, kein eigener Port)
Moderne Features wie WebSockets sind unter diesen Bedingungen nicht realisierbar – das ist akzeptabel.

4. Entwicklungsprozess
Die Neuentwicklung soll offen erfolgen. Wir sammeln gemeinsam Anforderungen, Wünsche und Ideen – auch solche, die früher technisch nicht möglich waren. Plugin‑Entwickler sollen den Fortschritt sehen können.

5. Technischer Ablauf (Lifecycle)
Request → Boot → Routing → Seitengenerierung → Response
Boot
Konfigurationen und Dienste müssen bei jedem Request neu geladen werden. Ziel: Minimale I/O durch zusammengefasste Konfigurationsdatei en und schnelle Maps. Ein Config‑Cache reduziert unnötige Dateizugriffe.
Routing
Eine einfache Map ordnet Routen den zuständigen Plugins zu. Beispiel: /news → News‑Plugin /api/user → API‑Plugin
Seitengenerierung
Ein flexibles Cache‑Konzept ist zentral: Plugins definieren, wie lange Inhalte gültig sind. Cachebar als Ganzes oder in Teilen – je nach Content.

6. Architektur: Core & Plugins
Der Core enthält nur unverzichtbare Bestandteile:
    • Konfiguration
    • Log‑API
    • Pluginverwaltung
    • Routing
    • Event‑System
    • Abhängigkeitsverwal tung
    • Template‑System (nicht die Engine)
    • Datenbankzugriff
Alles andere – Seiten, Content, Backend‑Module, Userverwaltung – wird als Plugin umgesetzt. Dadurch erhält kein Plugin Sonderstatus und kann vollständig ersetzt werden.
Das System wird mit einem Basissatz an Plugins ausgeliefert, bleibt aber modular.

7. Log‑API
Ein einheitliches Logging für Core und Plugins. Log‑Einträge werden an beliebige Log‑Plugins weitergereicht. Zusätzlich: ein einfaches Core‑Log und ein File‑Log, das ohne Abhängigkeiten schon ab dem ersten Request funktioniert.

8. Pluginverwaltung
Plugins sind die Bausteine des Systems. Wichtig sind:
    • Installation
    • Updates
    • Deinstallation
    • Abhängigkeitsauflös ung
Beispiel: „News 4.5.6 benötigt Foo 4.5, aber Forum 2.2.3 ist nur mit Foo 3.x kompatibel.“
Pluginquellen können flexibel sein: (S)FTP, GitHub Packages, Composer usw.

9. Routing im Detail
Plugins melden sich für bestimmte Routen oder Muster an. Der Core verwaltet eine Map und findet schnell das passende Plugin. Auch das klassische WB‑Page‑System lässt sich damit abbilden.

10. Templates
Templates sind einfach, aber flexibel:

Quellen:
    • Plugin‑Templates
    • Seiten‑Templates
    • Template‑Erweiterungen
    • User‑Templates

Überschreibreihenfo lge:
    1. Plugin
    2. Seite
    3. User

Der Core baut daraus ein virtuelles Template. Plugins beziehen Templates über den Core, z. B.: WB→templates→gibMir(„einzelansichtKlein.html“, „newsModulXY“)
Die Template‑Engine ist austauschbar (Twig oder eigene Engine).

11. Backend
Das Backend ist ein Rahmen mit Menüstruktur. Plugins liefern ihre eigenen Oberflächen. Pages, Log, Pluginmanager, Userverwaltung usw. sind alles Plugins.

12. Abschluss
Mit einer guten Codebasis wird vieles einfacher. Flexibilität entsteht durch klare, einfache Strukturen. Alle erweiterten Funktionen bleiben optional. Das System soll so klein wie möglich bleiben.


Was meint ihr? Welche Ideen oder Wünsche habt ihr für das neue System?