LydiaCMS besteht aus 13 produktiven Composer-Paketen, einschließlich des Kerns, und drei Entwicklerwerkzeugen. Abgesehen vom Kern fügt jedes Paket eine Fähigkeit hinzu und lässt sich einzeln installieren.
Pakete
- core — Anwendungsstart, DI, Routing, Berechtigungen, Übersetzungen und die Grundlage der Administration
- menu, blog, forms, attributes, currencies, location, socials, units — Inhaltsmodule, jedes mit eigenen Entitäten, Routen und Migrationen
- integration, data, api, backup — Import aus Webdiensten, ein konfigurierbares Datenmodell mit Versionshistorie, die REST/MCP-Schnittstelle, Backups und Wiederherstellung
- phpstan, rector, ecs — Entwicklerwerkzeuge, über die im Abschnitt zur Qualität berichtet wird
Wie sich ein Paket einklinkt
- Es registriert sich über eine einzige Nette-Erweiterung (DI): Entitäten, Routen, Dienste und Migrationen gehören zum jeweiligen Paket.
- Jedes Paket hat eine Version und idempotente Migrationen. Das Aktualisieren der Datenbank ist ein Befehl,
lydiacms:upgrade.
Administration aus Metadaten erzeugen (metadata-driven CRUD scaffolding)
Grids und Formulare entstehen aus den Metadaten der Doctrine-Entitäten (über 100 Entitäten). Eine eigene Vorlage wird nur dort geschrieben, wo die Daten nicht flach sind: beim Menübaum, beim Formular-Builder oder bei den Varianten der sozialen Netzwerke. Eine Kleinigkeit wie ein Hilfetext oder ein Platzhalter wird über ein Attribut am Feld gelöst.
Mehrsprachigkeit und SEO im Datenmodell
Jeder Datensatz existiert in Sprachvarianten (derzeit CS, EN, DE, FR, ES und SK), und jede Variante ist ein eigener Datensatz in der Datenbank. Eine weitere Sprache erfordert daher keine Codeänderung. Die SEO-Angaben (Titel, Beschreibung, Bild und Slug) werden für jeden Datensatz und jede Sprache getrennt festgelegt.
Die Adressen der Seiten werden in der Datenbank samt dem gesamten Pfad über die Vorfahren gespeichert. Diese Seite liegt zum Beispiel unter /projekte/lydiacms/architektur. Eine verkürzte Adresse ohne Vorfahren wird dauerhaft (301) auf den vollständigen Pfad weitergeleitet. Ändere ich den Slug einer Seite, wird die alte Adresse auf die neue weitergeleitet.
Berechtigungen werden über den Baum der Kontexte vererbt
Die Kontexte bilden einen Baum (System → Frontend, Admin, API → Paket → Submodul → Datensatz), und jeder von ihnen ist eine Quelle für ACL. Eine Standardregel wird nur einmal für den ganzen Namensraum festgelegt (Administration und API sind geschlossen, das Frontend ist offen), und alles darunter erbt sie. Ein neues Submodul oder ein neuer Datensatz braucht deshalb keine eigenen Regeln. Die Regel an einem Paket gilt für alle seine Submodule, und eine Regel an einem Submodul, ob erlaubend oder verbietend, überstimmt sie.
- Der Zugang zur Administration wird aus den Regeln abgeleitet. Wer in der Administration irgendetwas anzeigen darf, gelangt hinein. Einen weiteren Schalter gibt es nicht.
- Eine Obergrenze der Berechtigungen. Niemand kann mehr erlauben oder vergeben, als er selbst hat, sodass sich niemand die eigenen Rechte erhöhen kann.
- Eine Vorlage für die Inhaltsarbeit ergänzt mit einem Klick die Regeln für Seiten, Blog, Menü und Medien und vergibt niemals Löschen, Export, Einstellungen oder die Verwaltung von Benutzern und Rollen. Das Ergebnis sind gewöhnliche Regeln, die sich in der Matrix weiter bearbeiten lassen.
Eine Berechtigung (anzeigen, erstellen, bearbeiten, löschen, Status ändern, exportieren) hat den Geltungsbereich Admin, Frontend oder API und kann über ein Muster mit Wildcards auf Kontexte beschränkt werden, zum Beispiel api.core.**. Dieselbe ACL gilt für die Administration und für die Schnittstelle für KI.
Medien und Cron-Jobs in der Administration
Die Mediathek zeigt bei jeder Datei, wo sie verwendet wird, sodass man sieht, was ein Löschen kaputt machen würde. Cron-Jobs haben für jeden Lauf einen eigenen Eintrag mit Ergebnis und dem Zeitpunkt der nächsten Ausführung.