Produktarchitektur des Plugin-Katalogs

Dieses Dokument hält die Produktarchitektur und MVP-Planung für die vorgeschlagene Oberfläche plugins.webblocksui.com fest, bevor die Implementierung beginnt. Es ist reine Dokumentation. Es fügt keinen Laufzeitcode, keine Routen, Migrationen, Controller, API-Clients, Datenbanktabellen, UI-Screens, Deployment-Skripte, Hintergrundjobs, Release-Tags oder Versionserhöhungen hinzu.

plugins.webblocksui.com ist die vorgeschlagene öffentliche Plugin-Katalog-Oberfläche für das WebBlocks-Ökosystem. Sie soll Nutzern helfen, Plugins zu entdecken, Plugin-Metadaten zu verstehen, die Kompatibilität mit Host-Produkten zu sehen, die Release-Historie einzusehen und einer sicheren Anleitung zur manuellen Installation zu folgen.

Das erste Ziel sind Discovery, Metadaten, Kompatibilitätstransparenz und eine sichere Anleitung zur manuellen ZIP-Installation. Sie soll nicht als kommerzieller Marktplatz starten und darf keine automatische Remote-Plugin-Installation in WebBlocks CMS, QuizTem, Herne Panel, WebBlocks Publisher oder einem anderen Host-Produkt suggerieren.

Die Produktsprache sollte drei Stufen unterscheiden:

• Plugin-Katalog: Plugins durchstöbern, suchen und entdecken; Metadaten, Kompatibilität, Release Notes, Screenshots, Dokumentation und Download-Links lesen.
• Plugin-Store: spätere vertrauenswürdige Installations-/Update-Integration aus Katalog-Metadaten in Host-Produkte.
• Marktplatz: zukünftige kommerzielle Ebene mit Anbietern, Konten, Lizenzierung, Zahlungen, Freigaben, Bewertungen und Vertrieb kostenpflichtiger Plugins.

Das kurzfristige Produkt sollte Plugin-Katalog heißen, nicht Marktplatz. Marktplatz-Sprache sollte den zurückgestellten kommerziellen Funktionen vorbehalten bleiben.

Vorteile:

• saubere Produktgrenze
• unabhängige Roadmap
• langfristig einfachste Verantwortung für API und Katalog

Nachteile:

• mehr Einrichtungs- und Betriebsaufwand
• getrennte Belange für Content-Management, Administration, Deployment und Wartung

Vorteile:

• nutzt Konzepte der Update-Veröffentlichung wieder
• kann Muster für Artefakte, Prüfsummen, Release-Metadaten und Manifeste wiederverwenden

Nachteile:

• Risiko, WebBlocks Publisher zu stark auszuweiten
• die Belange eines Plugin-Katalogs unterscheiden sich von der Veröffentlichung von Produkt-Updates
• Katalog-Discovery, Kompatibilitätsmatrizen und öffentliche Plugin-Seiten könnten Publisher von seiner Kernproduktrolle wegziehen

Vorteile:

• demonstriert die Fähigkeiten von WebBlocks CMS
• Inhaltsseiten sind leicht zu verwalten
• der Plugin-Katalog kann das Plugin-System selbst produktiv erproben (Dogfooding)

Nachteile:

• erfordert ein Katalog-Plugin
• benötigt eine sorgfältige Trennung zwischen öffentlichem Content-Management und der Autorität über Artefakte/Katalog
• muss vermeiden, dass die CMS-Inhaltsbearbeitung zur Autorität für die Sicherheit ausführbarer Artefakte wird

Das Hybridmodell würde öffentliche Marketing- und Inhaltsseiten aus WebBlocks CMS ausliefern, während Katalog-API und Artefakt-Metadaten von einem dedizierten Katalogdienst oder einem von Publisher abgeleiteten Backend bereitgestellt werden.

Dies ist möglicherweise die praktikabelste langfristige Richtung, bleibt aber eine Richtung und keine Implementierungszusage.

Dokumentieren Sie plugins.webblocksui.com als Produktoberfläche des Ökosystems mit einer sauberen Grenze. Beginnen Sie mit einem katalogorientierten MVP mit Fokus auf Discovery, Metadaten, Kompatibilitätstransparenz, Release Notes, Prüfsummen, Dokumentation und Anleitung zum manuellen Download.

Die Implementierung kann entweder als dedizierte Laravel-Anwendung oder als WebBlocks-CMS-basiertes Katalog-Plugin beginnen, aber der Datenvertrag sollte nicht von einer einzelnen UI-Implementierung abhängen. Die Konzepte von WebBlocks Publisher sollten wiederverwendbar bleiben, insbesondere die Ideen zu Release-Metadaten und Artefaktverifizierung, ohne anzunehmen, dass der Plugin-Katalog in Publisher angesiedelt sein muss.

Die folgenden Konzepte betreffen ausschließlich die Planungsebene. Sie implizieren keine Datenbanktabellen, APIs, Modelle, Migrationen oder Admin-Screens im aktuellen Repository.

• Handle
• Bezeichnung
• Kurzbeschreibung
• Beschreibung
• Anbieter/Autor
• Website-URL
• Dokumentations-URL
• Support-URL
• Lizenztyp
• Kategorien
• Tags
• Status: Entwurf, gelistet, ungelistet, veraltet, gesperrt
• Datum der Erstveröffentlichung
• Datum des letzten Release

• Name
• Slug
• Website
• Support-Kontakt
• Verifizierungsstatus
• öffentliche Profilseite
• zukünftige kommerzielle Eignung, zurückgestellt

• Produktschlüssel, zum Beispiel webblocks-cms, quiztem, herne-panel oder webblocks-publisher
• Produktbezeichnung
• unterstützte Versionsbereiche
• Regeln für die Katalogsichtbarkeit

• Plugin-Handle
• Version
• Kanal: stable, beta, alpha, dev
• Release-Datum
• Release Notes
• Kompatibilitätsmatrix
• erforderliche PHP-/Laravel-Version, sofern zutreffend
• Artefakt-URL
• Prüfsumme
• zukünftige Signatur-Metadaten
• Migrationshinweise
• Hinweise zu Breaking Changes
• Sicherheitshinweise
• Hinweise zur Abkündigung

• Speicherpfad oder URL
• Prüfsumme
• Größe
• MIME/Typ
• Paketformat
• Manifest-Metadaten
• Validierungsstatus
• Scan-Status
• Veröffentlichungszustand

• unterstützte Host-Produkte
• erforderliche Host-Produkt-Versionen
• inkompatible Host-Produkt-Versionen
• PHP-/Laravel-Einschränkungen, sofern relevant
• erforderliche Erweiterungen
• in Konflikt stehende Plugin-Handles
• erforderliche Plugin-Abhängigkeiten, falls zukünftige Unterstützung genehmigt wird

• Plugin-Handle
• betroffene Versionen
• Schweregrad
• Status
• korrigierte Version
• öffentliche Zusammenfassung
• empfohlene Maßnahme für Betreiber

Zukünftige öffentliche Seiten für die vorgeschlagene Oberfläche plugins.webblocksui.com können umfassen:

• Startseite
• Plugin-Übersicht
• Kategorieseiten
• Suchergebnisse
• Plugin-Detailseite
• Seite mit der Release-Historie
• Anbieter-Profilseite
• Kompatibilitätsseiten für Host-Produkte
• Seiten für Dokumentation / Installationsanleitung
• Seite für Security Advisories
• Hinweise zu veralteten / entfernten Plugins
• zukünftige Marktplatz-Seiten, ausdrücklich zurückgestellt

Plugin-Detailseiten sollten enthalten:

• Plugin-Name
• Kurzbeschreibung
• Screenshots
• unterstützte Host-Produkte
• neueste kompatible Version
• erforderliche Host-Produkt-Versionen
• Release Notes
• angeforderte Berechtigungen
• deklarierte Migrationen
• deklarierte Routen, Einstellungen, Befehle und Assets
• Installationsmethode
• Download- und Prüfsummeninformationen
• Sicherheits-/Abkündigungsstatus
• Support- und Dokumentationslinks

Zukünftige Betreiber-Screens für den Katalog können umfassen:

• Plugins
• Anbieter
• Releases
• Artefakte
• Kompatibilität
• Security Advisories
• Kategorien/Tags
• Review-Queue, zurückgestellt
• Kommerz/Lizenzierung, zurückgestellt

Dies sind Planungskonzepte für Katalog/Administration, keine Implementierungsaufgaben für die CMS-Administration.

Zukünftige schreibgeschützte API-Endpunkte können umfassen:

• GET /api/plugins
• GET /api/plugins/{handle}
• GET /api/plugins/{handle}/releases
• GET /api/plugins/{handle}/latest?host_product=webblocks-cms&version=...
• GET /api/host-products
• GET /api/security-advisories
• GET /api/catalog/index

Die V1-API sollte für Host-Produkte schreibgeschützt sein. API-Antworten dürfen für sich genommen niemals eine Remote-Installation, Plugin-Aktivierung, Migrationsausführung, Update-Anwendung, beliebige Composer-Installation oder ausführbares Verhalten auslösen.

Zukünftige Publisher-/Betreiber-Endpunkte sind separat und zurückgestellt:

• Plugin-Release veröffentlichen
• Artefakt hochladen
• Listing freigeben
• Listing sperren
• Advisory herausgeben

WebBlocks CMS und andere Host-Produkte können den Plugin-Katalog nutzen, um:

• den Katalog aus der Host-Administration zu durchsuchen
• die Plugin-Kompatibilität vor Download/Installation anzuzeigen
• auf den manuellen ZIP-Download zu verlinken
• installierte Plugin-Versionen mit Katalog-Releases zu vergleichen
• Sicherheits-/Abkündigungswarnungen für installierte Plugins anzuzeigen
• kontrollierte Installations-/Update-Abläufe nur dann zu unterstützen, wenn Host-Produkte vertrauenswürdige Artefakt-Metadaten erneut prüfen, Prüfsummen verifizieren, Pakete validieren und explizite Betreiberaktionen verlangen

Das Durchstöbern des Katalogs darf nicht voraussetzen, dass die Verwaltung installierter Plugins online ist. Die Verwaltung installierter Plugins muss auch ohne Katalogverfügbarkeit funktionieren. Host-Produkte sollten Katalog-Metadaten defensiv zwischenspeichern, und entfernten Metadaten darf nicht als ausführbarem Verhalten vertraut werden.

Der zukünftige Ablauf für Maintainer/Betreiber kann umfassen:

• Plugin-Artefakt lokal vorbereiten
• Plugin-Manifest validieren
• Paketform validieren
• Prüfsumme berechnen
• Artefakt und Metadaten hochladen
• der Katalog prüft Kompatibilität und Artefaktsicherheit
• das Release wird erst nach expliziter Betreiberfreigabe oder einem vertrauenswürdigen First-Party-Veröffentlichungsablauf gelistet

Dies ähnelt den Ideen zu WebBlocks Publisher/Update-Metadaten, aber die Veröffentlichung im Plugin-Katalog sollte eine separate Fähigkeit bleiben, sofern nicht eine spätere Entscheidung beides zusammenführt.

Ein praktikables erstes MVP sollte umfassen:

• statische oder katalogverwaltete Plugin-Einträge
• öffentliche Plugin-Übersichts- und Detailseiten
• Plugin-Release-Metadaten
• Kompatibilitätsmatrix
• manuelle Download-Links
• angezeigte Prüfsummen
• Dokumentationslinks
• keine automatische Remote-Installation auf CMS-Seite
• kein kostenpflichtiger Marktplatz
• keine Lizenzierung
• kein Self-Service-Publishing durch Dritte
• keine automatische Update-Anwendung

Diese Planungsphase umfasst nicht:

• Implementierung in dieser Aufgabe
• Live-Produktionsdeployment
• automatische Remote-Plugin-Installation
• automatische Plugin-Aktivierung
• automatische Ausführung von Plugin-Migrationen
• automatische Anwendung von Plugin-Updates
• beliebige Composer-Installation
• kostenpflichtiger Marktplatz
• Lizenzserver
• Self-Service-Portal für Anbieter
• Bewertungen/Rezensionen
• Automatisierung der Produktions-Artefaktveröffentlichung
• Verifizierung der Live-Site

• Soll plugins.webblocksui.com als dedizierte Laravel-App oder als CMS-basiertes Katalog-Plugin starten?
• Soll WebBlocks Publisher die Veröffentlichung von Plugin-Artefakten verantworten, oder soll der Plugin-Katalog einen eigenen Veröffentlichungsablauf haben?
• Sollen First-Party- und Third-Party-Plugins unterschiedliche Freigabeabläufe haben?
• Wie sollen Plugin-Signaturen gehandhabt werden?
• Wie soll kommerzielle Lizenzierung später eingeführt werden, ohne den Katalogvertrag zu ändern?
• Wie sollen private/interne Plugins repräsentiert werden?
• Wie sollen Multi-Host-Plugins Provider und Kompatibilität je Host deklarieren?