Architecture Modulaire

BeamReactor repose sur une architecture entièrement modulaire. Chaque fonctionnalité est encapsulée dans un plugin autonome, intégrable à n'importe quel endroit du code ou directement dans les éditeurs WYSIWYG.

Le moteur centralise l'ensemble des appels : aucun script PHP ne peut être exécuté sans passer par lui. Cette conception garantit un contrôle total sur les flux d'entrée/sortie et une isolation stricte entre les composants.

Chargement automatisé

Lorsqu'un plugin est appelé, le moteur prend en charge automatiquement :

Le chargement de la configuration (conf/plugin.conf.inc.php)
L'injection des bibliothèques (lib/plugin.lib.inc.php)
La sélection de la locale selon la langue de l'utilisateur
L'enregistrement des routes et handlers

Plusieurs plugins peuvent cohabiter sur une même page sans collision. Chaque plugin opère dans son propre espace de noms, avec ses propres ressources CSS et JavaScript.

Filtrage des données

Toute donnée entrante ou sortante passe par la classe Sanitizer\Parser. Le système valide chaque valeur contre des types stricts :

Types primitifs

Bool, Int, Float, String avec contraintes de longueur et de format.

Types structurés

Email, URL, UUID, IP, Date, JSON avec validation syntaxique.

Types riches

HTML (whitelist de balises), Markdown, SQL (requêtes préparées uniquement).

Types métier

Fichiers (MIME, taille, extension), Images (dimensions, format), Tokens.

Les interactions avec la base de données utilisent exclusivement des requêtes préparées. La concaténation directe de paramètres est structurellement interdite par l'abstraction SQL.

Gestion des privilèges

Le système implémente une hiérarchie de privilèges configurable globalement et par plugin :

OVERMIND → ADMIN → MODERATOR → HIGHUSER → USER

Chaque plugin peut définir ses propres seuils d'accès. Un plugin de statistiques peut être réservé aux administrateurs, tandis qu'un forum sera ouvert aux utilisateurs enregistrés. La granularité s'étend jusqu'aux actions individuelles au sein d'un même plugin.

Les niveaux sont définis par constantes (BASE_LEVEL_*, PLUGIN_LEVEL_*). Les valeurs numériques ne sont jamais hardcodées dans la logique métier.

Structure d'un plugin

/plugins/exemple/ ├── exemple.php # Interface principale ├── /conf/ │ ├── exemple.conf.inc.php # Configuration (auto-chargée) │ ├── exemple.moderation.json # Cartographie pour l'effacement ou l'anonymisation des données utilisateur │ └── exemple.sitemap.json # Cartographie pour le moteur de recherche ├── /doc/ │ ├── exemple.md # Documentation technique │ └── exemple.help.json # Aide contextuelle ├── /lib/ │ ├── truc.class.php # Classe chargée par l'autoloader du plugin si configuré (exemple.conf.inc.php) │ └── exemple.lib.inc.php # Bibliothèque (auto-chargée) ├── /locale/ │ ├── exemple.en.inc.php # Traduction anglaise │ └── exemple.fr.inc.php # Traduction française ├── /handlers/ │ ├── exemple.mod.php # Endpoint AJAX principal │ └── exemple_blabla.mod.php # Endpoint AJAX secondaire ├── /css/ │ └── exemple.css # Styles spécifiques ├── /js/ │ └── exemple.js # Scripts spécifiques ├── /sql/ │ └── exemple.sql # Schéma initial └── /tests/ └── exemple.test.php # Tests unitaires