Leichtbau: Was das CMF nicht hat
Software-Projekte scheitern selten an fehlenden Features. Sie scheitern an Komplexität. An Abhängigkeiten, die sich gegenseitig blockieren. An Updates, die etwas kaputt machen, das vorher funktioniert hat. An Frameworks, die schneller veralten als die Projekte, die darauf aufbauen.
Das CMF ist bewusst leicht gebaut. Es hat keine Abhängigkeiten außer PHP selbst. Und das ist kein Kompromiss – es ist das Designprinzip.
Was bewusst fehlt – und was man dadurch gewinnt
Nicht im System
- Kein Framework (kein Laravel, Symfony, etc.)
- Keine Datenbank (kein MySQL, SQLite, etc.)
- Keine Build-Tools (kein Webpack, Vite, npm)
- Kein JavaScript-Framework (kein React, Vue)
- Keine Composer-Abhängigkeiten
- Keine externen CDN-Einbindungen
- Kein ORM, kein Template-Engine
- Keine Magic Methods oder Konventionen
Was man dadurch gewinnt
- Null Abhängigkeits-Konflikte
- Kein composer update das etwas zerstört
- Kein node_modules mit 300 MB
- Keine Sicherheitslücken in Drittcode
- Deployment = Dateien kopieren
- Läuft auf jedem 3-Euro-Webspace
- Jeder PHP-Entwickler versteht den Code
- Kein Framework-Lock-in
Was trotzdem da ist
- Vollständige REST-API mit 30 Endpunkten
- Block-basierter visueller Editor
- Theme-System mit CSS-Variablen
- Blog mit Kategorien und Karten-Grid
- Medien-Upload mit Einbindungsprüfung
- Export/Import als ZIP
- CSRF-Schutz und HTML-Sanitizing
- Automatische Sitemap und Navigation
Der Stack: PHP + JSON + HTML
Drei Technologien, ein System
Das gesamte System besteht aus reinem PHP. Keine Abstraktionsschichten, keine ORMs, keine Template-Engines. PHP rendert HTML. JSON speichert Daten. CSS stylt die Ausgabe.
JavaScript gibt es nur für die Admin-Navigation, die Suche und den Block-Editor – und selbst das ohne Framework. Kein jQuery, kein Alpine, kein Stimulus.
Das bedeutet: Jeder PHP-Entwickler kann den Code lesen und verstehen. Kein Framework-spezifisches Wissen nötig, keine Convention-over-Configuration-Rätsel.
Im Vergleich
| CMF | WordPress | |
|---|---|---|
| PHP-Dateien | ~25 | ~1.500 |
| ZIP-Größe | ~3 MB | ~70 MB |
| Datenbank | keine | MySQL Pflicht |
| Abhängigkeiten | 0 | npm + Composer |
| Setup-Zeit | Upload, fertig | DB + Config + Wizard |
| API-Referenz | 190 Zeilen | ~2.000 Seiten Doku |
Leichtbau im Alltag
Was bedeutet Leichtbau konkret, wenn man damit arbeitet? Hier sind fünf Alltagssituationen:
Deployment
Dateien per FTP hochladen. Fertig. Kein SSH, kein Git-Hook, kein CI-Pipeline. Kein npm run build, kein composer install.
Geht auch per ZIP-Export und -Import zwischen Servern – komplett über die API.
Backup
Den Ordner kopieren. Das ist das komplette Backup. Keine Datenbank-Dumps, keine Export-Plugins, keine vergessenen Config-Dateien.
Oder im Backend: Einstellungen → ZIP exportieren. Eine Datei, alles drin.
Updates
Systemdateien überschreiben, eigene Inhalte bleiben erhalten. Kein Migrations-Script, kein Datenbank-Update, kein Breaking-Change-Risiko.
Oder direkt im Backend: Einstellungen → automatisch prüfen und einspielen.
Debugging
Inhalt falsch? Die JSON-Datei öffnen und nachschauen. Seite sieht komisch aus? Die CSS-Datei prüfen. API gibt einen Fehler? Die PHP-Datei lesen.
Kein Stack-Trace durch 47 Abstraktionsschichten. Der Code ist dort, wo man ihn erwartet.
Serverwechsel
Ordner kopieren, auf den neuen Server laden. Keine Datenbank migrieren, keine PHP-Version prüfen (ab 8.1), keine Extensions nachinstallieren.
Funktioniert auf jedem Webspace der PHP kann – vom 3-Euro-Hosting bis zum dedizierten Server.
Warum Leichtbau langfristig gewinnt
Haltbarkeit
Ein System ohne Abhängigkeiten veraltet nicht. Es gibt kein Framework das in 2 Jahren deprecated wird. Keine Datenbank-Version die mit dem nächsten Hosting-Update inkompatibel ist. Keine npm-Packages mit Sicherheitslücken die man patchen muss.
PHP selbst wird seit 30 Jahren weiterentwickelt und wird das auch in 30 Jahren noch. JSON ist ein offener Standard. HTML5 ist abwärtskompatibel. Ein CMF-Projekt von heute wird in 10 Jahren noch genauso funktionieren – ohne dass jemand etwas anfassen muss.
Kontrolle
Wer das CMF nutzt, besitzt seine Webseite wirklich. Keine Vendor-Locks, keine Abo-Modelle, keine Plattform-Abhängigkeit. Die Daten liegen als JSON-Dateien auf dem eigenen Server – lesbar, kopierbar, portierbar.
Keine Cloud-API die abgeschaltet werden kann. Kein SaaS-Dienst der seine Preise verdreifacht. Kein Ecosystem das man verlassen muss wenn der Anbieter die Richtung ändert. Die Webseite gehört dem, der sie baut.
Das beste Feature eines Systems ist, dass es funktioniert. Nicht, dass es 500 Optionen hat. Sondern dass die 20 Dinge, die es kann, zuverlässig und vorhersagbar funktionieren.