WebBlocks Plugin-Ökosystem und Katalog

Dieses Dokument hält die Ausrichtung des WebBlocks-Plugin-Ökosystems für die nächste Phase fest, bevor die Implementierung beginnt. Es ist ausschließlich Architekturdokumentation. Es fügt keinen Laufzeitcode, keine Routen, Migrationen, Controller, API-Clients, Datenbanktabellen, Admin-Oberflächen, Deployment-Automatisierung, Release-Tags oder Versionserhöhungen hinzu.

Die WebBlocks-Plugin-Architektur sollte ökosystemweit sein, nicht nur auf das CMS beschränkt. WebBlocks CMS ist der erste Plugin-Host, da es bereits über Grundlagen des Plugin-Systems, registry-gestützte Definitionen, manuellen ZIP-Upload/-Installation, standardmäßig deaktivierte installierte Plugins, Kompatibilitätsprüfungen sowie inertes Verhalten bei deaktiviertem oder inkompatiblem Zustand verfügt. Derselbe Vertrag sollte von anderen WebBlocks-Produkten wiederverwendbar sein, wenn diese paketorientierte Erweiterungen mit klarer Ownership und sicheren Lifecycle-Regeln benötigen.

Den Vertrag nur rund um das CMS zu entwerfen, würde es später erschweren, Plugin-Identität, Paketierung, Kompatibilität, Katalog-Metadaten und Sicherheitsregeln gemeinsam zu nutzen. Die Zielrichtung ist ein gemeinsamer WebBlocks-Plugin-Vertrag, den jedes Produkt über seine eigenen Erweiterungspunkte hosten kann, während ein gemeinsames Modell für Identität, Paketinspektion, Kompatibilität, Aktivierung, Updates und Katalogsuche erhalten bleibt.

Mögliche Plugin-Hosts sind unter anderem:

• WebBlocks CMS
• QuizTem
• Herne Panel
• WebBlocks Publisher
• zukünftige WebBlocks-Produkte

Jedes Host-Produkt kann unterschiedliche Erweiterungspunkte bereitstellen. WebBlocks CMS stellt CMS-Admin-Menüs, Plugin-Routen, Berechtigungen, Einstellungen, Befehle, Migrationen, Blöcke, Assets, Health-Checks, Dashboard-Widgets und Systemkarten bereit. QuizTem, Herne Panel, WebBlocks Publisher und zukünftige Produkte können andere produkteigene Registries und Oberflächen bereitstellen.

Auch wenn sich die Erweiterungspunkte unterscheiden, sollten Plugin-Identität, Paketierung, Kompatibilität, Lifecycle und Katalog-Metadaten im gesamten WebBlocks-Ökosystem gemeinsamen Konventionen folgen. Ein Plugin kann ein Host-Produkt oder mehrere Host-Produkte unterstützen, aber die Produktkompatibilität muss vor der Aktivierung immer explizit und einsehbar sein.

Jedes Ökosystem-Plugin sollte ein stabiles Handle haben:

• in kebab-case
• global eindeutig im gesamten WebBlocks-Ökosystem
• stabil über Releases hinweg
• als Standardpräfix für Routen, Berechtigungen, Einstellungen, Befehle, Tabellen, Assets und Paketidentität verwendet

Handle-präfixierte Ownership hält das Plugin-Verhalten zuordenbar und kollisionssicher. Admin-Routen, öffentliche Routen, Berechtigungs-Strings, Einstellungs-Namespaces, Befehlsnamen, Datenbanktabellen-Präfixe, Asset-Handles, Paketnamen, Artefaktpfade und Katalogeinträge sollten alle auf das besitzende Plugin-Handle zurückführbar sein.

Die Produktkompatibilität muss explizit sein. Ein Plugin kann nur WebBlocks CMS, nur QuizTem, nur Herne Panel, nur WebBlocks Publisher oder eine unterstützte Kombination von Host-Produkten unterstützen. Nicht unterstützte Host-Produkte müssen das Plugin als inkompatibel und inert behandeln.

Das Ökosystem sollte sich auf ein gemeinsames Manifest-Konzept zubewegen, das vor der Installation und vor der Aktivierung inspiziert werden kann. Die genaue Implementierungs-API kann sich weiterentwickeln, und Host-Produkte können das Manifest in produktspezifische Registries überführen, aber Ownership und Kompatibilität müssen vor der Aktivierung einsehbar bleiben.

Zukünftige gemeinsame Manifest-Metadaten sollten Folgendes enthalten:

• handle
• label
• vendor oder author
• version
• unterstützte Host-Produkte
• erforderliche Host-Produkt-Versionen
• erforderliche PHP- und Laravel-Versionen, sofern zutreffend
• Provider-Klassen pro Host-Produkt, sofern erforderlich
• Berechtigungen
• Admin-Menü-Beiträge
• Routendeklarationen
• Befehle
• Migrationen
• Blöcke oder Block-Packs
• Assets
• Einstellungen
• Health-Checks
• Release Notes
• Prüfsummen- und Signatur-Metadaten

Das Manifest sollte einem Host ermöglichen, Sicherheitsfragen zu beantworten, bevor Code aktiviert wird: welche Produkte das Paket unterstützt, welche Produktversionen erforderlich sind, welche Provider gebootet werden dürfen, welche Routen und Befehle registriert würden, welche Berechtigungen erstellt würden, welche Tabellen und Einstellungs-Namespaces in Besitz genommen werden, welche Migrationen für die explizite Einrichtung angeboten werden können und welche Artefakte verifiziert werden können.

plugins.webblocksui.com ist die vorgeschlagene zukünftige Katalog-/Store-Oberfläche. Dieses Dokument impliziert nicht, dass die Domain existiert, bereitgestellt oder live ist.

Die Begriffe sollten klar voneinander getrennt bleiben:

• Plugin-Katalog: Discovery, Metadaten, Kompatibilität, Dokumentation, Screenshots, Support-Links, Release-Metadaten, Sicherheitsstatus und Download-Links.
• Plugin-Store: spätere Installations-/Update-Integration aus vertrauenswürdigen Katalog-Metadaten in ein Host-Produkt.
• Marketplace: zukünftige kommerzielle Funktionen wie Konten, Lizenzierung, kostenpflichtige Plugins, Bewertungen, Freigabe-Workflows, Publisher-Profile und Umsatz-Workflows.

Der erste Meilenstein sollte ein Plugin-Katalog sein, kein vollständiger kommerzieller Marketplace. Ein Katalog kann den Metadaten-Vertrag, die Kompatibilitätsmatrix, Artefakt-Prüfsummen, Dokumentationslinks und einen sicheren manuellen Download-Pfad etablieren, ohne Remote-Installation, automatische Updates, kostenpflichtige Lizenzierung oder kommerzielle Freigabe-Workflows hinzuzufügen.

Zu Produktpositionierung, MVP-Umfang, möglichen Implementierungsmodellen, öffentlichen Website-Oberflächen, Operator-Konzepten und API-Planung für das vorgeschlagene Katalogprodukt siehe Plugin Catalog Product Architecture.

1. Phase 1: Dokumentations- und Metadaten-Vertrag.
2. Phase 2: Planung von Katalogserver/Datenmodell für plugins.webblocksui.com.
3. Phase 3: Schreibgeschützte Browse Plugin Catalog-Oberfläche im CMS-Admin. Implementiert als /webadmin/plugins/catalog, unter Verwendung von WEBBLOCKS_PLUGIN_CATALOG_BASE_URL / webblocks-plugins.catalog.base_url mit dem Standardwert https://plugins.webblocksui.com.
4. Phase 4: Manueller ZIP-Download-/Installationsablauf, verlinkt aus Katalog-Metadaten.
5. Phase 5: Kontrollierter Install from Catalog-Ablauf, nach der Installation weiterhin standardmäßig deaktiviert.
6. Phase 6: Plugin-Update-Prüfungen und Update-Verfügbarkeit. Implementiert für CMS System -> Plugins -> Registered Plugins, wenn installierte Plugin-Handles neuere kompatible Katalog-Releases mit vollständigen Artefakt-Metadaten haben.
7. Phase 7: Kontrollierter Ablauf zum Anwenden von Plugin-Updates. Implementiert als Super-Admin-POST-Aktion, die die Katalog-Prüfsummenverifikation und die Plugin-ZIP-Validierung wiederverwendet, dabei den Lifecycle-Zustand bewahrt und Migrationen explizit belässt.
8. Phase 8: Marketplace-/Lizenzierungs-/kommerzielle Funktionen.

Jede Phase muss die standardmäßig deaktivierte Installation, kompatibilitätsorientiertes Verhalten und explizite Einrichtungs- oder Migrationsaktionen bewahren. Remote-Metadaten können Benutzern helfen, Plugins zu entdecken, zu bewerten, zu installieren oder explizit zu aktualisieren, aber sie dürfen Plugins nicht stillschweigend aktivieren, keine Migrationen ausführen, keine Updates anwenden und keine Host-Produkt-Kompatibilitätsregeln umgehen.

Der CMS-Katalogbrowser listet öffentliche, mit WebBlocks CMS kompatible Katalog-Plugins und die Metadaten des neuesten kompatiblen Releases auf. Das CMS verfügt jetzt über explizite Super-Admin-Aktionen zur Kataloginstallation/-aktualisierung für vertrauenswürdige ZIP-Artefakte mit vollständigen Prüfsummen-Metadaten, aber das Durchsuchen des Katalogs selbst installiert keine Composer-Pakete, aktiviert keine Plugins, führt keine Migrationen aus, registriert keine Routen, Befehle, Provider oder Berechtigungen und aktiviert keinen Plugin-Zustand aus Remote-Daten.

Nichtverfügbarkeit von Katalog/Store darf die Verwaltung installierter Plugins nicht beeinträchtigen. Die Auflistung installierter Plugins, Aktivierungs-/Deaktivierungssteuerungen, Einrichtungshinweise, Health-Status und Deinstallationsverhalten sollten weiterhin aus dem lokalen Zustand funktionieren.

Remote-Katalogdaten dürfen Plugins nicht automatisch aktivieren. Remote-Katalogdaten dürfen nicht automatisch Migrationen ausführen. Remote-Katalogdaten dürfen Updates nicht automatisch anwenden. Katalog-gestützte Updates erfordern eine explizite Super-Admin-POST-Aktion und vertrauenswürdige Artefakt-Metadaten. Die automatische Installation beliebiger Composer-Pakete ist außerhalb des Umfangs, sofern nicht eine zukünftige Architekturentscheidung sie ausdrücklich genehmigt.

ZIP-Artefakte müssen vor der Installation verifiziert werden. Die Verifikation sollte Path Traversal, versteckte Metadaten-Dateien, das Ausbrechen aus dem Wurzelverzeichnis, unerwartete öffentlich ausführbare Dateien, Routenkollisionen, Berechtigungskollisionen, Tabellenpräfix-Kollisionen, Kollisionen an Host-Produkt-Grenzen, Symlink-Ausbrüche, verbotene Installationsziele, fehlerhafte Manifeste, inkompatible Host-Produkte sowie Prüfsummen- oder zukünftige Signatur-Abweichungen blockieren.

Inkompatible, deaktivierte, unsichere Plugins oder Plugins mit fehlenden Dateien müssen inert bleiben. Sie dürfen keine Routen, Befehle, Menüs, Berechtigungen, Einstellungsrouten, Migrationen, geplanten Jobs, Blöcke, Assets, Widgets, Health-Reporter oder anderes aktives Laufzeitverhalten registrieren.

Die Deinstallation bleibt deaktiviert-zuerst und speicherbasiert. Eine gewöhnliche Deinstallation darf nur das speichereigene Plugin-Paketverzeichnis und die lokalen Aktivierungszustands-Einträge entfernen. Sie darf keine plugin-eigenen Datenbanktabellen löschen, es sei denn, ein zukünftiges destruktives Bereinigungswerkzeug wird bewusst mit expliziter Bestätigung entworfen.

Das Überschreiben von Core-Views bleibt standardmäßig verboten. Plugin-Erweiterungen müssen dokumentierte Registries oder Erweiterungs-Slots verwenden. Plugins dürfen keine Paket-Views ersetzen, keine Produktdienste per Monkey-Patching verändern, keine versteckten Routendateien hinzufügen und sich nicht auf beliebige Include-Nebeneffekte verlassen.

Plugin-Katalog-Einträge sollten Folgendes enthalten:

• Plugin-Listing-Metadaten: Handle, Label, Beschreibung, Vendor/Autor, Kategorien, Tags, aktuelles stabiles Release, Dokumentations-URL, Screenshots, Support-URL sowie Quell- oder Issue-Tracker-URL, sofern verfügbar
• Release-Metadaten: Version, Veröffentlichungsdatum, Release Notes, Artefakt-URLs, Prüfsummen, zukünftige Signaturen, Mindestanforderungen an den Host, Upgrade-Hinweise und Deprecation-Status
• Kompatibilitäts-Metadaten: unterstützte Host-Produkte, unterstützte Versionseinschränkungen der Host-Produkte, erforderliche PHP-/Laravel-Versionen sofern zutreffend, unterstützte Plattformdienste und Migrations-/Einrichtungsanforderungen
• Sicherheitshinweis- und Deprecation-Metadaten: betroffene Versionen, gepatchte Versionen, Schweregrad, Advisory-Links, Unsicher-Kennzeichnungen, veraltete Releases, Ersatzempfehlungen und blockierter Installations-/Update-Status
• Artefakt-Verifikations-Metadaten: Prüfsummenalgorithmus, Prüfsummenwert, Artefaktgröße, zukünftige Signaturdaten, Identität des Signaturschlüssels und Integritätsstatus
• Dokumentations-, Screenshot- und Support-URLs: öffentliche Dokumentation, Changelog, Einrichtungsanleitung, Screenshots, Support-Kontakt, Issue-Tracker und Vendor-Profil
• Host-Produkt-Kompatibilitätsmatrix: eine Zeile pro unterstütztem Host-Produkt, einschließlich Produkt-Handle, Produkt-Label, kompatibler Versionseinschränkungen, Provider-Klassen-Metadaten sofern erforderlich, verwendeter Erweiterungspunkte, Einrichtungsanforderungen und bekannter Einschränkungen

Katalog-Metadaten sollten vor dem Download, vor der Installation, vor der Aktivierung, vor Einrichtung/Migration und vor dem Anwenden von Updates nützlich sein.

Der zukünftige Plugin-Katalog kann Ideen aus dem bestehenden WebBlocks Publisher-/Update-Metadaten-Ablauf wiederverwenden, einschließlich Release-Metadaten, Artefakt-Prüfsummen, Manifesten und Konzepten der gehosteten Distribution. Das Veröffentlichen in den Plugin-Katalog sollte dennoch als separate Produktfähigkeit dokumentiert werden.

Dieses Dokument setzt keine Implementierung innerhalb des aktuellen WebBlocks Publisher-Codes voraus. plugins.webblocksui.com kann später durch WebBlocks Publisher, eine dedizierte Katalog-Anwendung oder eine WebBlocks CMS-Site mit einem Katalog-Plugin betrieben werden. Die Implementierungsentscheidung sollte getroffen werden, nachdem der Katalog-Metadaten-Vertrag und die Produktgrenze klar sind.

Siehe Plugin System für die aktuelle WebBlocks CMS-Plugin-Host-Architektur.

Der manuelle ZIP-Upload/-Installation im CMS bleibt die derzeit unterstützte Methode zur Plugin-Installation. Hochgeladene Plugins werden unter speichereigenen Pfaden installiert, bleiben standardmäßig deaktiviert und erfordern explizite Aktivierung sowie Einrichtungs-/Migrationsaktionen. Deaktivierte und inkompatible Plugins bleiben inert.

Katalog-/Store-Arbeiten sollten auf dem bestehenden CMS-Plugin-Lifecycle aufbauen, statt ihn zu ersetzen. Zukünftige Katalogsuche, manuelle Download-Links, Install-from-Catalog-Abläufe, Update-Prüfungen und kontrollierte Update-Anwendungsaktionen sollten dieselben Regeln für Handle, Kompatibilität, Standardmäßig-deaktiviert, Einrichtungspflicht, Schema-Bereitschaft, Berechtigungen, Routen-Ownership und Deinstallationssicherheit wiederverwenden.

Diese Phase umfasst nicht:

• Laufzeit-Implementierung
• automatische Remote-Installation
• automatisches Anwenden von Plugin-Updates
• kostenpflichtiges Marketplace-Verhalten
• Lizenzserver-Verhalten
• Freigabe-Workflow für Drittanbieter
• Automatisierung des Produktions-Deployments
• Verifikation der Live-Site