Vue d'ensemble des plugins

Les plugins étendent Flexweg CMS en s'accrochant au flux de publication, en contribuant des blocs d'éditeur, des cartes de tableau de bord, des pages de réglages et des traductions. Le système est

Les plugins étendent Flexweg CMS en s'accrochant au flux de publication, en contribuant des blocs d'éditeur, des cartes de tableau de bord, des pages de réglages et des traductions. Le système est largement inspiré du modèle filtres / actions de WordPress — les plugins enregistrent des callbacks que l'admin invoque à des points de cycle de vie connus.

Trois catégories de plugins

Catégorie Où ils vivent Toggleable Toujours chargés
Intégrés src/plugins/ (dans le source admin), livrés avec le build ✓ — toggle on/off depuis la page Plugins Seulement si activés
Must-use (mu) src/mu-plugins/ (dans le source admin) ✗ — pas de toggle Toujours
Externes ZIP uploadé, vit dans /admin/plugins/<id>/ sur Flexweg ✓ — comme les intégrés, plus désinstallables Seulement si activés et installés

En production, les plugins intégrés et externes sont chargés de la même façon — les deux sont des bundles ESM pré-compilés fetchés au boot via le loader runtime. La différence est seulement comment ils sont arrivés là : les intégrés sont livrés avec dist/ de l'admin, les externes sont uploadés par l'utilisateur.

Les must-use sont bundlés directement dans le chunk JS principal de l'admin et tournent inconditionnellement — c'est pour des comportements sans lesquels le CMS ne peut pas vraiment tourner.

Plugins intégrés

Cinq plugins intégrés livrés avec l'admin. Tous toggleables, désactivés par défaut sauf indication contraire :

Plugins must-use

Cinq plugins must-use livrés avec l'admin. Toujours actifs, pas de toggle :

Plus :

  • flexweg-import — import drag-and-drop de contenu (markdown ou WordPress XML)

Plugins externes

Les plugins externes sont distribués en ZIP et installés à chaud. Voir :

Plugins externes notables :

  • flexweg-multilang — site multilingue avec traductions de posts/pages/catégories, hreflang, sitemaps + RSS par langue

Comment les plugins sont chargés

Boot de l'admin
    ↓
loadAllExternalEntries() fetch external.json
    ↓
Pour chaque entry : dynamic-import bundle.js → registry in-memory
    ↓
applyPluginRegistration(enabledFlags) tourne dans CmsDataContext
    ↓
Pour chaque plugin activé : manifest.register(api) appelle addFilter/addAction/registerBlock/...
    ↓
L'UI et le pipeline lisent la registry et appliquent ce qui est enregistré

À chaque changement de settings (activer/désactiver un plugin, changer une config), applyPluginRegistration re-tourne et réécrit la registry.

Configuration de plugin

Chaque plugin peut déclarer une page de réglages à /settings/plugin/<id>. La sidebar Réglages liste tous les plugins activés qui ont une page.

Le config est persisté à settings.pluginConfigs[<id>]. Lecture via useCmsData().settings.pluginConfigs?.[<id>] côté UI, et via ctx.settings.pluginConfigs?.[<id>] dans les handlers de publication.

Le cycle de vie d'un plugin externe

  1. Build par l'auteur : npm run build<id>.zip
  2. Distribution : où vous voulez (GitHub release, marketplace tiers, etc.)
  3. Install par l'admin via la page Plugins → Install plugin → drag du ZIP
  4. Activation : par défaut un plugin externe est activé à l'install, mais peut être désactivé sans uninstall
  5. Configuration : si le plugin a une page de réglages
  6. Upgrade : drag d'une nouvelle version du ZIP fait un upgrade in-place (préserve la config)
  7. Désinstallation : bouton Uninstall — supprime les fichiers + l'entrée registry. La config persistée est conservée pour une réinstallation future.