Bootstrap et contextes d’exécution¶
Objectif¶
Le plugin charge des composants différents selon le contexte d’exécution : runtime WordPress, frontend, administration, worker ou CLI.
Cette modularité évite de charger toute la plateforme pour chaque requête, mais elle rend certaines dépendances moins visibles pendant le diagnostic.
Point important : WP-CLI et PHP CLI¶
Le bootstrap CLI vérifie un contexte WP-CLI réel :
defined('WP_CLI') && WP_CLI
Une commande PHP classique telle que :
php -r 'require "/var/www/html/wp-load.php"; ...'
ne satisfait pas cette condition. Le chargement de WordPress seul ne garantit donc pas que les fonctions de reconstruction des modèles et spécifications soient disponibles.
Chargement de l’application Product Models¶
Les fonctions d’enrichissement sont définies via :
includes/bootstrap/product-models-application.php
↓
includes/application/product-model-enrichment.php
La fonction suivante doit être disponible après bootstrap :
ccx_product_specs_rebuild('smartphone');
Exécution manuelle en PHP CLI¶
Lorsque WP-CLI n’est pas installé dans le conteneur, charger explicitement l’application :
docker exec -it ccx-wordpress php -r '
require "/var/www/html/wp-load.php";
require_once WP_PLUGIN_DIR . "/ccx-feeds-industrial/includes/bootstrap/product-models-application.php";
ccx_bootstrap_product_models_application();
var_dump(function_exists("ccx_product_specs_rebuild"));
print_r(ccx_product_specs_rebuild("smartphone"));
'
Le résultat attendu commence par :
bool(true)
Diagnostic du chargement¶
Vérifier d’abord l’activation du plugin :
docker exec -it ccx-wordpress php -r '
require "/var/www/html/wp-load.php";
print_r(get_option("active_plugins"));
'
Puis vérifier la fonction avant et après le bootstrap explicite.
Règle de maintenance¶
Toute nouvelle commande opérationnelle doit documenter :
- le contexte nécessaire ;
- le fichier bootstrap à charger ;
- les fonctions rendues disponibles ;
- les dépendances à WordPress, WP-CLI ou au worker ;
- une commande reproductible dans les conteneurs du projet.