Chargement isolé au démarrage : un plugin défaillant n'arrête jamais votre site
Chargement isolé au démarrage une fonctionnalité du module Plugins & API interne de Clustraly. Le chargement isolé au démarrage ne boote que vos plugins actifs et valides, chacun confiné à son namespace, sans jamais interrompre la requête.
Vos extensions démarrent chacune dans leur couloir. Celle qui échoue part dans les logs, pas dans votre page le reste de Clustraly continue de répondre.
Un plugin qui plante n'emporte jamais votre page
Au démarrage, chaque plugin s'exécute sous filet. Plugin absent, classe introuvable, contrat non respecté ou register() qui lève une exception : l'incident est journalisé, et la requête continue.
Vous gardez un site qui répond, même quand une extension déraille. L'erreur va dans vos journaux, pas au visage de vos visiteurs.
- Tout le boot encadré par try/catch
- Chaque incident journalisé, jamais masqué
- La requête n'est jamais interrompue
Seuls vos plugins actifs et valides démarrent
PluginManager::boot() s'exécute avant le cœur (action cms.boot) et ne charge que les plugins à la fois actifs et valides. Ce que vous avez désactivé reste inerte : ses fichiers demeurent, son chargement s'arrête.
Vous décidez de ce qui tourne. Rien ne démarre dans votre dos.
- Double condition : actif ET valide
- Désactivé = inerte, sans rien supprimer
- S'exécute avant le boot du cœur
Chaque plugin reste dans son namespace
Un unique autoloader PSR-4 est enregistré, restreint aux préfixes sous Clustraly\Plugins\. Avant de tourner, la classe principale de chaque plugin est instanciée et doit implémenter PluginInterface alors seulement register() est appelé.
Résultat : aucune extension ne peut masquer une classe du cœur, et seul un plugin conforme au contrat s'enregistre.
- Un seul autoloader, préfixe Clustraly\Plugins\
- Contrat PluginInterface exigé
- register() appelé après vérification
Zéro namespace en double, de façon déterministe
Deux plugins actifs réclament le même namespace ? Un garde anti-shadowing ignore le second, toujours de la même manière. Le premier arrivé garde la main.
Vous obtenez un résultat identique à chaque démarrage : aucune surcharge silencieuse, aucune surprise sur le code qui répond.
- Namespace déjà pris = plugin ignoré
- Comportement déterministe à chaque boot
- Pas de surcharge silencieuse
Un démarrage qui tient, même à moitié installé
Avant même que la table plugins existe nouvelle installation, migration en attente le boot renvoie proprement une liste vide au lieu de planter.
Votre CMS démarre sur une base nue, et vous ajoutez vos extensions quand vous êtes prêt.
- Table manquante = retour vide, pas d'erreur
- Boot fonctionnel avant migration
- Aucun prérequis bloquant au démarrage
Vous activez, le démarrage isole
Clustraly ne charge que ce que vous avez activé et met chaque plugin dans son couloir. Vous gardez la main sur ce qui s'exécute ; le boot garde le contrôle sur la casse. L'IA propose, vous décidez.
Questions fréquentes
Que se passe-t-il si un plugin plante au démarrage ?
Un plugin désactivé est-il encore chargé au démarrage ?
Deux plugins peuvent-ils revendiquer le même namespace ?
Un plugin peut-il accéder aux classes du cœur du CMS ?
Fonctionnalités liées
Découverte & liste des plugins
Scanner • Lister • Afficher statut • Afficher badges
DécouvrirValidation de manifeste & confinement de namespace
Valider • Confiner • Signaler erreurs
DécouvrirActivation & installation automatique
Activer • Installer • Migrer • Vérifier version CMS • Rejeter conflit • Journali
DécouvrirDes plugins qui étendent votre CMS sans jamais le fragiliser
Le chargement isolé au démarrage vous donne un socle d'extension prévisible : seuls vos plugins actifs et valides démarrent, chacun confiné à son namespace, chaque erreur journalisée plutôt que fatale. Vous étendez Clustraly en confiance, et gardez la main sur ce qui s'exécute.