Registries

L'admin maintient cinq registries runtime qui contiennent ce que les plugins / thèmes contribuent. Tous les cinq partagent un cycle de vie similaire : vidés à chaque pass applyPluginRegistration(), puis re-peuplés.

Cette page documente ce que chaque registry contient, quand il est reset, et comment consommer son contenu.

Les cinq registries

Les quatre premiers sont reset ensemble à chaque toggle de plugin / changement de réglages. Le cinquième est indépendant — il track ce qui est installé sur disque, séparément de ce qui est actuellement enregistré.

Plugin registry (filtres + actions)

Le plus utilisé. Contient tous les handlers de filtre et d'action, indexés par nom de hook + priorité.

API

addFilter<T>(hook, fn, priority?)
addAction(hook, fn, priority?)
applyFilters<T>(hook, value, ...args)
applyFiltersSync<T>(hook, value, ...args)
doAction(hook, ...args)

Cycle de vie

resetRegistry() est appelé par applyPluginRegistration(enabledFlags) qui tourne dans CmsDataContext chaque fois que les réglages changent. Donc les plugins doivent re-enregistrer leurs handlers à chaque pass — manifest.register(api) est appelé de nouveau pour chaque plugin activé.

Block registry

Contient les blocs d'éditeur, indexés par id (<namespace>/<block-name>).

API

registerBlock(manifest)              // plugin
registerCoreBlock(manifest)          // pour les blocs de cœur — survit aux reset
listBlocks()                          // tous les blocs disponibles
getBlock(id)                          // par id
listBlocksByCategory()                // groupés pour l'inserter

Cycle de vie

resetBlocks() est appelé par applyPluginRegistration. Les blocs de cœur (enregistrés via registerCoreBlock) sont préservés.

Dashboard card registry

Contient les cartes du tableau de bord, ordonnées par priority.

API

registerDashboardCard({ id, priority?, component })
listDashboardCards()                  // pour le DashboardPage

Cycle de vie

Reset à chaque applyPluginRegistration. Re-enregistré par chaque plugin actif.

Regeneration target registry

Contient les entrées du menu Thèmes → Regenerate ▾.

API

registerRegenerationTarget({
  id, labelKey, descriptionKey, priority?,
  run: async (ctx, log) => { … }
})
listRegenerationTargets()

Cycle de vie

Reset à chaque applyPluginRegistration. Re-enregistré par chaque plugin actif.

External entries registry

Contient la liste live des plugins / thèmes externes importés depuis external.json. Indépendant des autres registries.

API

registerExternalPlugin(manifest)
registerExternalTheme(manifest)
unregisterExternalPlugin(id)
unregisterExternalTheme(id)
listExternalPlugins()
listExternalThemes()
subscribe(callback)                    // pour la PluginsPage / ThemesPage

Cycle de vie

• Au boot : loadAllExternalEntries() fetche dist/admin/external.json, dynamic-import chaque bundle, enregistre chaque default export.
• À l'install : installFromZip extrait le ZIP, upload sur Flexweg, écrit dans la registry du backend, re-enregistre in-memory.
• À l'uninstall : uninstallExternal retire du backend, supprime les fichiers sur Flexweg, désenregistre in-memory.

Le registre du backend (Firestore settings/externalRegistry ou SQLite config row externalRegistry) est la source de vérité persistante. Le registry in-memory est dérivé au boot puis muté par les opérations install / uninstall.

Garanties d'ordre

Les filtres et actions tournent dans l'ordre des priorités (lower first). Les blocs sont matchés dans l'ordre d'enregistrement pour isActive() (le premier qui matche gagne). Les dashboard cards et regeneration targets sont triés par priority pour l'affichage.

Donc l'ordre des register(api) appels à l'intérieur d'un plugin importe seulement pour les blocs ; ailleurs, la priority explicite décide.