Koexistenz

Dieses Dokument beschreibt, wie WebBlocks CMS mit einem anderen Laravel-Host-Produkt in derselben Anwendung koexistieren sollte. Es hält nur die Architekturrichtung fest; es implementiert selbst keine Änderungen an Routen, Konfiguration, Migrationen, Modellen, Controllern, Installer, Registrierung, Einladung oder Authentifizierung.

WebBlocks CMS kann als eigenständiges CMS laufen, bei dem das CMS die zentrale Admin-Erfahrung, das öffentliche Site-Rendering und die Inhaltsoperationen der Anwendung besitzt.

WebBlocks CMS kann auch neben einem anderen Laravel-Host-Produkt installiert werden. In diesem Modell behält das Host-Produkt seine eigenen Produktverantwortlichkeiten, während das CMS optionale Website- und Content-Management-Funktionen bereitstellt.

In Koexistenz-Installationen ist das CMS eine optionale Website- und Content-Schicht. Es sollte weder die Domänenentscheidungen des Host-Produkts noch dessen Autorisierung oder Admin-Routen übernehmen.

Das CMS sollte paketorientiert bleiben und Kollisionen mit Routen, Konfigurationsschlüsseln, View-Namespaces, Tabelleneigentum und anderen Anwendungsgrenzen der Host-Anwendung vermeiden.

Die Paketinstallation muss in geteilten Hosts fortsetzbar sein. Bevor neue CMS-Migrationen ausgeführt werden, erkennt webblocks:install einen teilweisen CMS-Tabellenzustand und meldet vorhandene CMS-Tabellen, Zeilenanzahlen, passende Migrationszeilen und bekannte Fremdschlüsselkonflikte. Leere teilweise CMS-Tabellen dürfen nur über das explizite Installer-Flag --repair-partial umbenannt werden. Nicht leere Tabellen erfordern eine manuelle Prüfung und dürfen nicht automatisch gelöscht, umbenannt oder als CMS-eigen behandelt werden.

Das CMS-Admin-Präfix sollte konfigurierbar sein.

Für Koexistenz-Installationen ist das empfohlene CMS-Admin-Präfix /webadmin. Die Host-Anwendung kann /admin besitzen, und das CMS darf nicht davon ausgehen, dass /admin immer verfügbar oder CMS-eigen ist. Das Pfadsegment /cms ist für statische CMS-Assets wie /cms/css, /cms/js und /cms/brand reserviert.

Eigenständige Installationen verwenden jetzt /webadmin als kanonisches CMS-Admin-Präfix. Dokumentation, Design und künftige Implementierungsarbeiten sollten das aktuelle Verhalten und die längerfristige Richtung eines konfigurierbaren Präfixes klar voneinander trennen.

CMS-Admin-Präfixe dürfen niemals ein physisches öffentliches Asset-Verzeichnissegment wiederverwenden. In v1.32.56 wurde das kanonische Admin-Präfix zu /webadmin verschoben, weil Nginx try_files /cms/ als das physische Verzeichnis public/cms/ auflösen kann, bevor Laravel die Route sieht. /cms muss ausschließlich für Assets bleiben: Fügen Sie keine CMS-eigenen /cms-Admin-Aliase oder -Weiterleitungen hinzu und stellen Sie keine CMS-eigenen /admin-Routen wieder her.

Die endgültige Lösung vermeidet die Routen-/Dateisystemkollision vollständig, anstatt sich auf eine public/cms/index.php-Übergabe oder eine Front-Controller-Brücke zu stützen. public/cms/index.php muss sowohl in den öffentlichen Root-Assets als auch in den öffentlichen Paket-Assets abwesend bleiben.

Öffentliche Seiten verwenden den path der Seitenübersetzung als kanonische URL und können Pfade mit Schrägstrichen enthalten, etwa /docs/internal-content-api. Öffentliche Seiten-Catchalls müssen weiterhin /webadmin, /webadmin/api, /cms, /search, /search.json, /contact-messages, /install und die Auth-Routen des Hosts den zuständigen Routendateien überlassen. /p/... dient nur der Legacy-Kompatibilität und darf nicht als neue kanonische URL erzeugt werden.

CMS-Browser-Admin-Routen verwenden /webadmin, während /webadmin/api für token-geschützte JSON-APIs reserviert ist. Ressourcen-URLs sollten vorhersehbar sein:

• Sammlung: /webadmin/{resource}
• Erstellen: /webadmin/{resource}/create
• Bearbeiten: /webadmin/{resource}/{id}/edit
• Element-Aktion: /webadmin/{resource}/{id}/{action}
• Sammlungs-Aktion: /webadmin/{resource}/{action}

Die Seitenvorschau ist eine Element-Aktion: GET /webadmin/pages/{page}/preview. Fügen Sie keine CMS-Seitenvorschau-Routen unter /admin, /cms, /webadmin/api, /webadmin/pages/preview/{page} oder /webadmin/preview/pages/{page} hinzu.

Authentifizierte Admin-Vorschauen müssen das öffentliche Routing getrennt halten. Sie dürfen für autorisierte CMS-Benutzer seiteneigene Inhalte im Entwurfs- oder Prüfstatus rendern, aber die öffentliche Seitenroute muss weiterhin nur veröffentlichte Seiten und veröffentlichte öffentliche Inhalte ausliefern.

Innerhalb eines gemeinsamen Laravel-Hosts liegen Login und Registrierung in der Verantwortung der Host-Anwendung. Die gemeinsame users-Tabelle ist die Identitäts- und Login-Schicht.

Das CMS sollte in gemeinsam installierten Anwendungen keine doppelte Benutzeridentität erfordern. Wenn paketeigene CMS-Auth-Routen aktiv sind, müssen CMS-Admin-Gast-Weiterleitungen und CMS-Auth-Bildschirme den CMS-eigenen /webadmin/login-Routennamen webblocks.auth.login anstelle des globalen Routennamens login verwenden, da das Host-Produkt login für Pfade wie /quiztem/login besitzen kann. Hosts, die die CMS-Auth bewusst ersetzen, dürfen weiterhin ihren eigenen Login-Ablauf besitzen, aber Paket-CMS-Views und -Middleware müssen bei paketeigenen Routennamen bleiben.

Die Authentifizierung beweist nur, dass ein Benutzer angemeldet ist. Sie gewährt keinen CMS-Zugriff.

Die CMS-Autorisierung muss vom CMS-Mitgliedschafts- und Rollensystem entschieden werden. Der CMS-Superadmin-Status macht den Benutzer nicht zum Admin des Host-Produkts, und der Admin-Status im Host-Produkt macht den Benutzer nicht zum CMS-Superadmin.

Die users-Tabelle ist die Identitätsschicht in einem gemeinsamen Laravel-Host. CMS-Zugriff wird durch CMS-eigene Mitgliedschafts- oder Rolleneinträge abgebildet, nicht durch das Anlegen eines zweiten Benutzers für dieselbe Person.

CMS-Installer-, Registrierungs- und Einladungsdesigns dürfen keine doppelten users-Zeilen für dieselbe E-Mail-Adresse anlegen.

Installer-, Einladungs- und Registrierungsabläufe, die CMS-Zugriff gewähren, sollten diese Reihenfolge verwenden:

1. Nach einem bestehenden Host-Benutzer mit derselben E-Mail-Adresse suchen.
2. Diesen Benutzer wiederverwenden, wenn er existiert.
3. Einen neuen Benutzer nur anlegen, wenn kein passender Host-Benutzer existiert.
4. Den CMS-Mitgliedschafts- oder Rolleneintrag hinzufügen, nachdem der Identitätseintrag aufgelöst wurde.

Der Superadmin-Status ist eine CMS-Mitgliedschafts- oder Rollenzuweisung, keine besondere Art von users-Eintrag.

Übliches Koexistenz-Routing sollte um klare Eigentumsverhältnisse herum entworfen werden:

• /login -> Host-Identität und -Login
• /admin -> Admin des Host-Produkts, sofern das Host-Produkt einen besitzt
• /webadmin -> WebBlocks-CMS-Admin, empfohlen für Koexistenz-Installationen
• /webadmin/login -> paketeigener CMS-Login, wenn Paket-CMS-Auth-Routen aktiv sind
• /webadmin/forgot-password und /webadmin/reset-password/{token} -> paketeigene CMS-Bildschirme zum Zurücksetzen des Passworts, wenn Paket-CMS-Auth-Routen aktiv sind
• /cms/... -> statische WebBlocks-CMS-Assets
• öffentliche Site-Routen -> öffentliches CMS-Rendering, wenn das CMS die öffentlichen Inhalte für die Anfrage besitzt

Eigenständige CMS-Installationen verwenden /webadmin für CMS-eigene Admin-Routen, wobei künftige konfigurierbare Präfix-Einstellungen weiterhin eine Zielrichtung sind.

Paketeigene CMS-Auth-Views müssen für CMS-eigene Bildschirme CMS-präfixierte Auth-Routen verwenden: webblocks.auth.login, webblocks.auth.logout und die bestehenden webblocks.auth.password.*-Namen. Wenn das Paket-Auth-Routen-Set keine CMS-Registrierung bereitstellt, sollte der CMS-Login den Registrieren-Link weglassen, statt auf eine host-eigene Root-Route /register zu verweisen.

Die aktuelle Implementierung verwendet /webadmin als kanonisches CMS-Admin-Präfix und stellt CMS-Admin-Verhalten nicht absichtlich über /admin oder /cms bereit.

Die Zielrichtung bleibt ein konfigurierbares CMS-Admin-Präfix mit /webadmin als Standard, sodass ein Host-Produkt /admin für seinen eigenen Verwaltungsbereich behalten kann und CMS-Assets unter /cms bleiben können.

Bis die Implementierung nachzieht, sollten Dokumentation und Entwürfe ausdrücklich angeben, ob sie das aktuelle Verhalten oder die Zielarchitektur beschreiben.

• Dieses Dokument macht das CMS nicht für die Autorisierung des Host-Produkts verantwortlich.
• Dieses Dokument verlangt nicht, dass Host-Produkte vom CMS abhängen.
• Dieses Dokument implementiert selbst keine Routen- oder Migrationsänderungen.