Ein modernes CMS erfordert keine Neuerfindung des Webs
Neue Webtechnologien sind spannend. Neue Frameworks, Rendering-Modelle, Build-Systeme und Abstraktionsschichten lösen regelmäßig echte Probleme.
Aber nicht jede neue Anwendung benötigt eine neue Anwendungsarchitektur.
WebBlocks CMS ging von einer ziemlich einfachen Frage aus:
Wie weit kann ein modernes CMS kommen, wenn wir weiterhin bekannte Webtechnologien dort nutzen, wo sie bereits gut funktionieren?
Das bedeutet PHP und Laravel für die Anwendung. Eine relationale Datenbank für strukturierte Inhalte. HTML für Markup. CSS für die Präsentation. JavaScript, bei dem das Browserverhalten tatsächlich JavaScript erfordert.
Keine dieser Ideen ist neu.
Das ist Absicht.
WebBlocks CMS ist kein Versuch, MVC neu zu erfinden, Blöcke zu erfinden, Laravel zu ersetzen oder eine andere Frontend-Architektur einzuführen. Es ist ein Versuch, ein leistungsfähiges modernes CMS zu entwickeln und gleichzeitig die zugrunde liegende Anwendung verständlich und unter der Kontrolle des Entwicklers zu halten.
Und das bedeutet in zunehmendem Maße auch, dasselbe strukturierte CMS für KI- und Automatisierungstools sicher zugänglich zu machen.
Ein CMS, das sich Ihrer Laravel-Anwendung anschließt
Eine häufige Annahme bei CMS-Produkten ist, dass das CMS selbst die Anwendung ist.
Sie installieren es, bauen alles in seiner Welt auf, befolgen seine Routing-Konventionen, verwenden sein Erweiterungsmodell und passen den Rest Ihres Projekts daran an.
WebBlocks verfolgt einen anderen Ansatz.
Es wird als Composer-Paket verteilt und kann seinin einer Laravel-Anwendung installiertSie besitzen bereits.
Die Anwendung Laravel bleibt die Anwendung.
Es besitzt weiterhin Dinge wie:
- Authentifizierung
- Datenbankkonfiguration
- Warteschlangen
- Post
- Einsatz
- Anwendungswege
- Infrastruktur
- domänenspezifische Geschäftslogik
WebBlocks fügt die Content-Management-Ebene hinzu: Seiten, Layouts, Blöcke, Medien, Navigation, Lokalisierung, Revisionen, Veröffentlichungsworkflows und den /webadmin-Arbeitsbereich.
Die Installation bleibt bewusst vertraut:
composer require fklavyenet/webblocks-cms
gefolgt von php artisan webblocks:install.
Es ist nicht erforderlich, eine zweite Frontend-Anwendung zu erstellen, nur weil das Projekt nun bearbeitbare Inhalte benötigt.
Ihr Laravel-Produkt und Ihre Website können zusammenleben
Dies ist besonders nützlich, wenn die Website nur ein Teil einer größeren Anwendung ist.
Stellen Sie sich vor, Sie haben bereits:
- ein SaaS-Produkt
- ein Kundenportal
- eine Buchungsanwendung
- ein internes Geschäftssystem
- eine Mitgliederplattform
- eine E-Commerce-bezogene Laravel-Anwendung
- oder einfach ein Laravel-Projekt mit umfangreicher benutzerdefinierter Geschäftslogik
Das Produkt selbst funktioniert möglicherweise bereits einwandfrei.
Was Sie brauchen, ist eine Möglichkeit für Redakteure, den öffentlich zugänglichen Teil davon zu verwalten: die Homepage, Produktseiten, Dokumentation, Zielseiten, Hilfeinhalte, rechtliche Seiten, Kampagnenseiten oder andere redaktionelle Inhalte.
Eine Lösung besteht darin, eine weitere Anwendung hinzuzufügen.
Ein separates CMS. Ein separates Frontend. Vielleicht ein anderes Framework, ein anderer Bereitstellungsprozess und eine andere Integrationsgrenze zwischen dem Produkt und der Website.
WebBlocks kann stattdessen zur optionalen Website- und Inhaltsschicht der vorhandenen Laravel-Anwendung werden.
Die Produktlogik bleibt dort, wo sie hingehört.
In Laravel.
Das CMS verwaltet die inhaltsorientierten Teile.
Dafür ist das Koexistenzmodell gedacht.
WebBlocks kann auch als primäres CMS für eine herkömmliche Website fungieren. Der wichtige Punkt ist, dass dadurch nicht jedes Laravel-Projekt in dieselbe Architektur gezwungen wird.
Es kann auch die öffentliche Website rendern
WebBlocks ist nicht darauf beschränkt, als Headless-Inhaltsdatenbank zu fungieren.
Es kann die öffentliche Website selbst verwalten und rendern.
Seiten haben echte öffentliche Pfade wie:
/features/contact/docs/internal-content-api
Der öffentliche Renderer arbeitet mit demselben strukturierten Seite → Layout → Slot → Blockmodell, das Redakteure im CMS verwalten.
Das bedeutet, dass eine Laravel-Anwendung sowohl Anwendungsrouten als auch CMS-verwaltete öffentliche Seiten enthalten kann, ohne eine weitere Frontend-Laufzeit ausschließlich für die Bereitstellung von Inhalten einzuführen.
Das CMS-Paket selbst erfordert weder Node, npm, Vite noch ein separates Frontend-Framework.
Das bedeutet nicht, dass JavaScript verboten ist.
Dies bedeutet, dass JavaScript dann verwendet wird, wenn etwas tatsächlich JavaScript benötigt, und nicht zur Voraussetzung für die Darstellung der Website gemacht wird.
Im gesamten Projekt gilt das gleiche Prinzip:
Nutzen Sie jede Technologie dort, wo sie etwas Nützliches beiträgt.
Seite → Layout → Slot → Block ist keine neue Erfindung
Blockbasierte Content-Systeme gibt es schon seit vielen Jahren.
Drupal hat Regionen und Blöcke. Andere CMS-Produkte verfügen über eigene Versionen von Abschnitten, Komponenten, Modulen, Widgets und wiederverwendbaren Inhalten.
WebBlocks erhebt nicht den Anspruch, dieses Konzept erfunden zu haben.
Sein Inhaltsmodell ist bewusst verständlich:
Seite → Layout → Slot → Block
Eine Seite wählt ein Layout aus.
Das Layout definiert benannte Bereiche.
Diese Slots enthalten Blöcke.
Blöcke enthalten strukturierte Inhalte und können gegebenenfalls selbst verschachtelte Strukturen unterstützen.
Der Wert besteht nicht darin, dass die Wörter neu sind.
Der Wert besteht darin, dass ein Redakteur, ein Laravel-Entwickler und ein Automatisierungstool alle über dieselbe explizite Struktur nachdenken können.
Es muss kein verstecktes Frontend-Anwendungsmodell zwischen dem CMS und der gerenderten Seite vorhanden sein.
Wiederverwendbare Inhalte sollten normal sein
Kopf- und Fußzeilen, Seitenleisten, Handlungsaufforderungen und andere sich wiederholende Strukturen sollten nicht auf jeder Seite neu erstellt werden müssen.
WebBlocks verwendet dafür Shared Slots.
Auch hier werden wiederverwendbare Inhalte nicht als revolutionäre CMS-Erfindung dargestellt. Das sollte ein praktisches CMS bieten.
Aber wiederverwendbare Inhalte bringen auch ein wichtiges redaktionelles Problem mit sich: Die Änderung freigegebener Inhalte kann sich auf viele Seiten gleichzeitig auswirken.
Aus diesem Grund nehmen Shared Slots an ihren eigenen kontrollierten Inhalts- und Revisionsworkflows teil, anstatt als unsichtbare globale Fragmente behandelt zu werden.
Wiederverwendung ist sinnvoll.
Eine geregelte Wiederverwendung ist sicherer.
Publizieren ist nicht nur ein Ein-/Ausschalter
Ein CMS wird interessanter, wenn mehr als eine Person – oder mehr als eine Art von Akteur – Inhalte ändern kann.
WebBlocks trennt den Seitenstatus von der Blockveröffentlichung, anstatt stillschweigend davon auszugehen, dass durch die Veröffentlichung einer Seite jeder unveröffentlichte Block öffentlich gemacht werden sollte.
Seiten können sich durch redaktionelle Status bewegen.
Revisions stellen Sicherheits-Snapshots auf Seitenebene bereit.
Geteilte Inhalte verfügen über einen eigenen Revisionsverlauf.
Durch die Veröffentlichung kann explizit angegeben werden, ob seiteneigene Blöcke auch öffentlich werden sollen.
Das ist wichtig für menschliche Redaktionsteams.
Dies wird noch wichtiger, sobald Automatisierung und KI in den Arbeitsablauf Einzug halten.
Multisite und Lokalisierung sind Teil des Content-Modells
Mit einer WebBlocks-Installation können unterschiedliche Sites, Domänen und Sprachen verwaltet werden, während die Site-Eigentümerschaft explizit bleibt.
Bei der Lokalisierung geht es nicht einfach darum, „die Seite zu duplizieren und zu übersetzen“.
Inhalte, Pfade und SEO-Daten können lokalisiert werden, während die überprüfte Seitenstruktur verständlich bleibt.
Dies ist nützlich für Organisationen, die mehrere Produktseiten, regionale Seiten oder mehrsprachige Websites betreiben, aber nicht für jede einzelne eine separate CMS-Installation wünschen.
Auch dies ist keine Behauptung, dass Multisite oder Lokalisierung neue Konzepte seien.
Es handelt sich dabei um etablierte CMS-Aufgaben.
Das Ziel besteht darin, sie bereitzustellen, ohne dass die Laravel-Anwendung die Kontrolle über ihre Architektur abgeben muss.
Auch Medien gehören ins CMS
Redaktioneller Inhalt ist mehr als nur Text.
WebBlocks umfasst Medienverwaltung und Bildvarianten, sodass Medien an derselben strukturierten Veröffentlichungsumgebung teilnehmen können wie Seiten und Blöcke.
In Kombination mit Navigation, Suche, Revisionen, Backups, Site-Transfer und kontrollierter Veröffentlichung soll die Absicht sein, die normalen betrieblichen Verantwortlichkeiten abzudecken, die von einem CMS erwartet werden, und nicht einen kleinen Block-Editor-Prototyp zu demonstrieren.
Diese Unterscheidung ist wichtig.
Ein Blockeditor ist eine Funktion.
Ein CMS muss auch den Lebenszyklus rund um den Inhalt verwalten.
Dann ändert KI das Problem
Hier wird die konventionelle Architektur besonders interessant.
Viele Produkte fügen derzeit KI hinzu, indem sie irgendwo in der Admin-Oberfläche ein Textfeld platzieren und es mit einem Modell verbinden.
Das kann nützlich sein, aber es ist nicht die Richtung, in die WebBlocks geht.
Die interessantere Frage ist:
Was passiert, wenn ein KI-Tool das eigentliche CMS verstehen und sicher bedienen kann?
WebBlocks stellt strukturierte CMS-Funktionen über Internal Content API bereit.
Eine vertrauenswürdige KI oder ein Bedientool kann die tatsächliche Installation überprüfen, anstatt zu erraten, wie das CMS funktioniert.
Es kann verfügbare Websites, Standorte, Layouts, Blocktypen und Inhaltsverträge ermitteln.
Es kann vorhandene strukturierte Inhalte überprüfen.
Es kann einen kompletten Seitenplan erstellen.
Es kann diesen Plan validieren, bevor der Inhalt geändert wird.
Es kann Entwurfsinhalte erstellen oder ändern.
Und das Veröffentlichen bleibt eine separate Funktion, die eine ausdrückliche Genehmigung erfordert.
Diese Unterscheidung ist wichtig.
Die KI muss die Admin-Oberfläche nicht durchsuchen.
Es müssen keine Mausklicks simuliert werden.
Es ist nicht nötig, HTML zu erfinden und zu hoffen, dass das CMS es akzeptiert.
Es kann mit demselben strukturierten Inhaltsmodell arbeiten, das das CMS selbst versteht.
KI-Zugriff muss nicht unbedingt unbegrenzten Zugriff bedeuten
Wenn man einem KI-Tool Zugriff auf ein CMS gewährt, stellt sich eine offensichtliche Frage:
Was darf es tun?
Der Internal Content API ist bewusst berechtigungsbezogen.
Inhaltsvalidierung und Inhaltsanwendung sind separate Vorgänge.
Die Anwendung von Inhalten erfolgt zunächst im Entwurf.
Für die Veröffentlichung ist eine separate content.publish-Funktion erforderlich.
Die API lehnt Vorgänge außerhalb ihrer definierten Verträge ab, anstatt die Automatisierung als Administrator mit unbegrenzter Freiheit zu behandeln.
Die Absicht ist nicht:
„Lassen Sie die KI die Website steuern.“
Es liegt näher an:
„Lassen Sie vertrauenswürdige Tools klar definierte CMS-Vorgänge innerhalb der gleichen Art von Grenzen ausführen, die wir von anderen Anwendungsakteuren erwarten würden.“
Dadurch ergeben sich interessante Möglichkeiten.
Ein KI-Tool könnte eine neue Zielseite vorbereiten und gleichzeitig die endgültige Veröffentlichungsentscheidung einem Redakteur überlassen.
Es könnte ausgewählte Entwurfsabschnitte aktualisieren, ohne die gesamte Seite zu ersetzen.
Es könnte verstehen, welche Blockstrukturen die tatsächliche Installation unterstützt, bevor Inhalte vorgeschlagen werden.
Es könnte auf einer mehrsprachigen Site funktionieren und dabei Site- und Gebietsschemagrenzen berücksichtigen.
Und da es sich dabei eher um CMS-Funktionen als um eine anbieterspezifische KI-Integration handelt, muss der CMS-Kern nicht von einem Modellanbieter abhängig sein.
Konventionell bedeutet nicht statisch
Die Nutzung etablierter Technologien bedeutet nicht, auf neue Möglichkeiten zu verzichten.
Es kann bedeuten, dass diese Fähigkeiten auf einer anderen Ebene angesiedelt werden.
HTML wird nicht obsolet, weil eine KI bei der Erstellung des Inhalts geholfen hat.
Laravel muss keine JavaScript-Anwendung werden, da ein Editor interaktive Blöcke benötigt.
Eine relationale Datenbank wird nicht dadurch ungeeignet, dass ein Automatisierungstool strukturierte Inhalte über eine API schreibt.
Serverseitiges Rendering steht modernen Redaktionsworkflows nicht im Weg.
Und eine herkömmliche Laravel-Anwendung kann immer noch maschinenlesbare Verträge offenlegen, die so ausgefeilt sind, dass KI-Tools sicher damit arbeiten können.
Diese Kombination ist das Experiment hinter WebBlocks CMS.
Was WebBlocks nicht zu beweisen versucht
WebBlocks versucht nicht, Folgendes zu beweisen:
- MVC ist neu
- Monolithische Anwendungen sind neu
- Blöcke sind neu
- Wiederverwendbare Regionen sind neu
- Neu ist das serverseitige Rendering
- CMS-Workflows sind neu
Das sind sie eindeutig nicht.
Das Projekt argumentiert auch nicht damit, dass Frontend-Frameworks, Headless-Architekturen oder JavaScript-lastige Anwendungen grundsätzlich falsch seien.
Sie lösen echte Probleme und sind für viele Anwendungen die richtige Wahl.
Die engere Frage ist, ob sie eine automatische Anforderung für jedes CMS-gestützte Laravel-Projekt sein sollten.
Die Antwort von WebBlocks besteht darin, sie optional und nicht grundlegend zu machen.
Eine bewusst langweilige Grundlage
In der Softwarebranche besteht die Tendenz, „langweilige Technologie“ als Entschuldigung zu bezeichnen.
Es kann auch ein Vorteil sein.
Ein Laravel-Entwickler, der ein WebBlocks-Projekt öffnet, sollte dennoch eine Laravel-Anwendung erkennen.
Ein Frontend-Entwickler sollte weiterhin HTML, CSS und JavaScript sehen.
Ein Redakteur sollte eher Seiten und Inhalte als die Bereitstellungsarchitektur sehen.
Und ein KI-Tool sollte explizite Schemata, Berechtigungen und strukturierte Vorgänge erkennen, anstatt eine Admin-Schnittstelle zurückentwickeln zu müssen.
Darüber hinaus gibt es viel Raum für Innovation.
Die Foundation selbst muss nicht unbekannt sein.
Probieren Sie den Ansatz und nicht die Terminologie aus
Die einzelnen Konzepte in WebBlocks CMS sind bewusst erkennbar.
Das Interessante daran ist, wie sie zusammenarbeiten:
- ein Composer-installierbares Laravel CMS,
- eine optionale Inhaltsebene für ein bestehendes Produkt,
- Rendering öffentlicher Websites,
- strukturierte Seiten und wiederverwendbare Inhalte,
- Multisite und Lokalisierung,
- Medien und Navigation,
- Überarbeitungen und kontrollierte Veröffentlichung,
- und berechtigungsbasierte APIs, die es modernen KI-Tools ermöglichen, an echten CMS-Workflows teilzunehmen.
Ob diese Kombination nützlich ist, ist eine viel interessantere Frage als die Frage, ob MVC, Blöcke oder monolithische Anwendungen zuvor existierten.
Das haben sie getan.
Das Projekt ist Open Source, die Dokumentation ist öffentlich und es gibt eine Live-Demonstration.
Der beste Weg, die Idee zu bewerten, besteht also nicht darin, zu fragen, ob die Zutaten neu sind.
Probieren Sie das CMS aus und sehen Sie, was damit erstellt werden kann.