Architecture produit du Plugin Catalog

Ce document consigne l'architecture produit et la planification du MVP de la surface proposée plugins.webblocksui.com avant le début de l'implémentation. Il s'agit uniquement de documentation. Il n'ajoute ni code d'exécution, ni routes, ni migrations, ni contrôleurs, ni clients d'API, ni tables de base de données, ni écrans d'interface, ni scripts de déploiement, ni tâches en arrière-plan, ni tags de version, ni incréments de version.

plugins.webblocksui.com est la surface publique proposée du Plugin Catalog pour l'écosystème WebBlocks. Elle doit aider les utilisateurs à découvrir les plugins, à comprendre leurs métadonnées, à voir la compatibilité avec les produits hôtes, à consulter l'historique des versions et à suivre des consignes d'installation manuelle sûres.

Le premier objectif est la découverte, les métadonnées, la visibilité de la compatibilité et des consignes sûres d'installation manuelle par ZIP. Elle ne doit pas démarrer comme une place de marché commerciale et ne doit pas laisser entendre qu'une installation distante automatique de plugins existe dans WebBlocks CMS, QuizTem, Herne Panel, WebBlocks Publisher ou tout autre produit hôte.

Le vocabulaire du produit doit distinguer trois étapes :

• Plugin Catalog : parcourir, rechercher et découvrir des plugins ; consulter les métadonnées, la compatibilité, les notes de version, les captures d'écran, la documentation et les liens de téléchargement.
• Plugin Store : plus tard, intégration de confiance de l'installation et de la mise à jour depuis les métadonnées du catalogue vers les produits hôtes.
• Marketplace : future couche commerciale avec fournisseurs, comptes, licences, paiements, approbations, notes et distribution de plugins payants.

Le produit à court terme doit s'appeler Plugin Catalog, et non Marketplace. Le vocabulaire de Marketplace doit rester réservé aux fonctionnalités commerciales reportées.

Avantages :

• frontière produit nette
• feuille de route indépendante
• maîtrise à long terme de l'API et du catalogue plus simple

Inconvénients :

• davantage de travail de mise en place et d'exploitation
• gestion de contenu, administration, déploiement et maintenance distincts

Avantages :

• réutilise les concepts de publication des mises à jour
• peut réutiliser les schémas d'artefacts, de sommes de contrôle, de métadonnées de version et de manifestes

Inconvénients :

• risque d'élargir excessivement le périmètre de WebBlocks Publisher
• les préoccupations du catalogue de plugins diffèrent de la publication des mises à jour produit
• la découverte dans le catalogue, les matrices de compatibilité et les pages publiques de plugins risquent d'éloigner Publisher de son rôle produit principal

Avantages :

• démontre les capacités de WebBlocks CMS
• les pages de contenu sont faciles à gérer
• le Plugin Catalog peut éprouver le système de plugins lui-même

Inconvénients :

• nécessite un plugin de catalogue
• exige une séparation soignée entre la gestion du contenu public et l'autorité sur les artefacts et le catalogue
• doit éviter que l'édition de contenu dans le CMS devienne l'autorité sur la sûreté des artefacts exécutables

Le modèle hybride servirait les pages publiques de marketing et de contenu depuis WebBlocks CMS, tandis que l'API du catalogue et les métadonnées des artefacts seraient servies par un service de catalogue dédié ou par un backend dérivé de Publisher.

C'est peut-être l'orientation la plus pratique à long terme, mais cela reste une orientation, non un engagement d'implémentation.

Documentez plugins.webblocksui.com comme une surface produit de l'écosystème dotée d'une frontière nette. Commencez par un MVP centré sur le catalogue : découverte, métadonnées, visibilité de la compatibilité, notes de version, sommes de contrôle, documentation et consignes de téléchargement manuel.

L'implémentation peut débuter sous la forme d'une application Laravel dédiée ou d'un plugin de catalogue propulsé par WebBlocks CMS, mais le contrat de données ne doit pas dépendre d'une seule implémentation d'interface. Les concepts de WebBlocks Publisher doivent rester réutilisables, en particulier les métadonnées de version et les idées de vérification des artefacts, sans supposer que le Plugin Catalog doive résider dans Publisher.

Les concepts suivants relèvent uniquement de la planification. Ils n'impliquent ni tables de base de données, ni API, ni modèles, ni migrations, ni écrans d'administration dans le dépôt actuel.

• handle
• libellé
• résumé
• description
• fournisseur/auteur
• URL du site web
• URL de la documentation
• URL du support
• type de licence
• catégories
• étiquettes
• statut : brouillon, référencé, non référencé, déprécié, suspendu
• date de première publication
• date de la dernière version

• nom
• slug
• site web
• contact du support
• statut vérifié
• page de profil publique
• future éligibilité commerciale, reportée

• clé du produit, par exemple webblocks-cms, quiztem, herne-panel ou webblocks-publisher
• libellé du produit
• plages de versions prises en charge
• règles de visibilité dans le catalogue

• handle du plugin
• version
• canal : stable, beta, alpha, dev
• date de publication
• notes de version
• matrice de compatibilité
• version de PHP/Laravel requise le cas échéant
• URL de l'artefact
• somme de contrôle
• futures métadonnées de signature
• notes de migration
• notes sur les changements incompatibles
• notes de sécurité
• notes de dépréciation

• chemin de stockage ou URL
• somme de contrôle
• taille
• MIME/type
• format du paquet
• métadonnées du manifeste
• statut de validation
• statut de l'analyse
• état de publication

• produits hôtes pris en charge
• versions requises du produit hôte
• versions incompatibles du produit hôte
• contraintes PHP/Laravel lorsque c'est pertinent
• extensions requises
• handles de plugins en conflit
• dépendances de plugins requises, si une prise en charge future est approuvée

• handle du plugin
• versions affectées
• gravité
• statut
• version corrigée
• résumé public
• action recommandée à l'opérateur

Les futures pages publiques de la surface proposée plugins.webblocksui.com peuvent inclure :

• Page d'accueil
• Liste des plugins
• Pages de catégories
• Résultats de recherche
• Page de détail du plugin
• Page d'historique des versions
• Page de profil du fournisseur
• Pages de compatibilité avec les produits hôtes
• Pages de documentation / guide d'installation
• Page des avis de sécurité
• Consignes sur les plugins dépréciés ou retirés
• Futures pages de marketplace, explicitement reportées

Les pages de détail de plugin doivent inclure :

• nom du plugin
• résumé
• captures d'écran
• produits hôtes pris en charge
• dernière version compatible
• versions requises du produit hôte
• notes de version
• permissions demandées
• migrations déclarées
• routes, réglages, commandes et ressources déclarés
• méthode d'installation
• informations de téléchargement et somme de contrôle
• statut de sécurité/dépréciation
• liens de support et de documentation

Les futurs écrans de l'opérateur du catalogue peuvent inclure :

• Plugins
• Fournisseurs
• Versions
• Artefacts
• Compatibilité
• Avis de sécurité
• Catégories/Étiquettes
• File de revue, reportée
• Commercial/Licences, reporté

Il s'agit de concepts de planification pour le catalogue et son administration, et non de tâches d'implémentation de l'administration du CMS.

Les futurs endpoints d'API en lecture seule peuvent inclure :

• 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

L'API V1 doit être en lecture seule pour les produits hôtes. Les réponses de l'API ne doivent jamais provoquer à elles seules une installation distante, l'activation d'un plugin, l'exécution de migrations, l'application d'une mise à jour, une installation Composer arbitraire ni aucun comportement exécutable.

Les futurs endpoints destinés aux publieurs/opérateurs sont distincts et reportés :

• publier une version de plugin
• téléverser un artefact
• approuver une fiche
• suspendre une fiche
• émettre un avis

WebBlocks CMS et les autres produits hôtes peuvent consommer le Plugin Catalog pour :

• parcourir le catalogue depuis l'administration de l'hôte
• afficher la compatibilité du plugin avant le téléchargement ou l'installation
• renvoyer vers le téléchargement manuel du ZIP
• comparer les versions des plugins installés avec les versions du catalogue
• afficher les avertissements de sécurité/dépréciation pour les plugins installés
• prendre en charge des flux d'installation/mise à jour contrôlés uniquement lorsque les produits hôtes revérifient les métadonnées d'artefacts de confiance, contrôlent les sommes de contrôle, valident les paquets et exigent des actions explicites de l'opérateur

La consultation du catalogue ne doit pas exiger que la gestion des plugins installés soit en ligne. La gestion des plugins installés doit fonctionner sans disponibilité du catalogue. Les produits hôtes doivent mettre en cache les métadonnées du catalogue de manière défensive, et les métadonnées distantes ne doivent jamais être considérées comme un comportement exécutable de confiance.

Le futur flux mainteneur/opérateur peut inclure :

• préparer l'artefact du plugin en local
• valider le manifeste du plugin
• valider la structure du paquet
• calculer la somme de contrôle
• téléverser l'artefact et les métadonnées
• le catalogue vérifie la compatibilité et la sûreté de l'artefact
• la version n'est référencée qu'après approbation explicite de l'opérateur ou via un flux de publication interne de confiance

Cela ressemble aux idées de WebBlocks Publisher sur les métadonnées de mise à jour, mais la publication dans le catalogue de plugins doit rester une capacité distincte, sauf si une décision ultérieure les fusionne.

Un premier MVP réaliste doit inclure :

• des entrées de plugins statiques ou gérées par le catalogue
• des pages publiques de liste et de détail des plugins
• des métadonnées de version des plugins
• une matrice de compatibilité
• des liens de téléchargement manuel
• des sommes de contrôle affichées
• des liens vers la documentation
• aucune installation distante automatique côté CMS
• aucune marketplace payante
• aucune gestion de licences
• aucune publication en libre-service par des tiers
• aucune application automatique des mises à jour

Cette phase de planification n'inclut pas :

• l'implémentation dans cette tâche
• le déploiement en production
• l'installation distante automatique de plugins
• l'activation automatique de plugins
• l'exécution automatique des migrations de plugins
• l'application automatique des mises à jour de plugins
• l'installation Composer arbitraire
• une marketplace payante
• un serveur de licences
• un portail en libre-service pour les fournisseurs
• les notes et avis
• l'automatisation de la publication des artefacts en production
• la vérification sur le site en production

• plugins.webblocksui.com doit-il démarrer comme une application Laravel dédiée ou comme un plugin de catalogue propulsé par le CMS ?
• WebBlocks Publisher doit-il prendre en charge la publication des artefacts de plugins, ou le Plugin Catalog doit-il disposer de son propre flux de publication ?
• Les plugins internes et tiers doivent-ils suivre des flux d'approbation différents ?
• Comment les signatures de plugins doivent-elles être gérées ?
• Comment introduire plus tard des licences commerciales sans modifier le contrat du catalogue ?
• Comment représenter les plugins privés ou internes ?
• Comment les plugins multi-hôtes doivent-ils déclarer leurs providers et leur compatibilité par hôte ?