Validation de manifeste & confinement de namespace : aucun plugin ne peut masquer votre cœur
Validation de manifeste & confinement de namespace une fonctionnalité du module Plugins & API interne de Clustraly. La validation de manifeste et le confinement de namespace vérifient chaque plugin.json et enferment son code sous une racine dédiée, jamais sur le cœur.
Vous voyez ce qu'un plugin déclare avant qu'il ne s'exécute, et son code reste enfermé sous la racine Clustraly\Plugins\ impossible de masquer une classe du cœur ou de l'application.
Un plugin ne peut jamais masquer votre cœur
Chaque plugin doit déclarer un namespace qui commence par la racine Clustraly\Plugins\. Sinon, la validation le refuse avec le code namespace_not_under_plugins_root. Le code d'un plugin vit donc dans un espace réservé et ne peut pas se faire passer pour une classe du cœur ou de l'application.
- Racine Clustraly\Plugins\ obligatoire
- Aucune classe du cœur masquée
- Erreur namespace_not_under_plugins_root explicite
Un manifeste contrôlé avant que le plugin ne touche à votre site
À la découverte comme à l'installation, validate() lit le plugin.json et vérifie que les champs requis sont bien présents et bien typés : name, version, namespace et main doivent tous être des chaînes. Un manifeste incomplet ou mal formé est signalé, pas exécuté.
- Champs name, version, namespace, main requis
- Types de chaîne contrôlés
- Manifeste invalide signalé, jamais chargé
Un slug sûr, une version au bon format, une classe valide
La validation impose un slug sûr (motif ^[a-z0-9][a-z0-9-]{1,79}$) et cohérent avec le dossier du plugin, une version au format semver, et une valeur main qui est un identifiant de classe valide. Autant de garde-fous qui écartent les manifestes bancals dès la lecture.
- Slug sûr et cohérent (pas de slug_mismatch)
- Version au format semver
- main = identifiant de classe valide
Le confinement n'est pas qu'une promesse : il est appliqué au démarrage
Au boot, un unique autoloader PSR-4 est enregistré et restreint aux préfixes sous la racine des plugins. Le code hors de cette racine n'est tout simplement pas chargé par ce mécanisme : le confinement déclaré dans le manifeste devient une frontière réelle à l'exécution.
- Autoloader PSR-4 unique et restreint
- Préfixes limités à la racine des plugins
- Frontière appliquée, pas seulement déclarée
Chaque problème est nommé et remonté dans l'interface
Vous n'avez pas à deviner pourquoi un plugin est refusé. Chaque code d'erreur retourné par la validation slug invalide, champ manquant, version non-semver, namespace hors racine est remonté dans l'UI. Vous voyez exactement ce qui bloque, et vous décidez de la suite.
- Codes d'erreur affichés un par un
- Cause exacte du refus visible
- Vous gardez la décision d'activer
Le confinement par défaut, la décision pour vous
Clustraly refuse tout manifeste bancal et enferme chaque plugin sous sa racine dédiée, sans réglage de votre part. La main sur ce qui s'active, elle, vous revient toujours.
Questions fréquentes
Qu'est-ce que le confinement de namespace ?
Que vérifie exactement la validation du manifeste ?
Que se passe-t-il si un manifeste est invalide ?
Le confinement est-il réellement appliqué à l'exécution ?
Fonctionnalités liées
Des plugins qui étendent votre CMS, sans jamais s'infiltrer dans son cœur
Avec la validation de manifeste et le confinement de namespace, chaque plugin est lu, vérifié et enfermé sous sa racine dédiée avant d'être activé. Vous ajoutez des fonctionnalités en gardant une frontière nette entre le cœur de Clustraly et le code tiers et vous gardez toujours la décision d'activer.