Aller au contenu

WordPress Adapter

Status: CURRENT Last consolidated by: BC-068D This document describes the current WordPress adapter boundary.

WordPress est un Adapter. Il expose les capacités de la Platform mais ne porte pas la vérité métier.

Packaging runtime

WordPress ne doit pas contenir une copie de la Platform.

Le plugin charge la Platform via un point de bootstrap technique unique qui résout l'autoload Composer canonical.

Topologie certifiée :

plugins/ccx-feeds-industrial/
        ↓
bootstrap Platform
        ↓
/opt/cmonchoix-platform/vendor/autoload.php
        ↓
/opt/cmonchoix-platform/src

Contraintes :

  • aucun require_once classe par classe ;
  • aucun namespace CMonChoix\Platform dans le plugin ;
  • aucun src/ copié dans wordpress/ ;
  • fallback legacy admis uniquement comme sécurité transitoire quand la Platform est indisponible.

Product Canonical read adapters

BC-061B2 centralise aussi la lecture du top multi-marchands dans :

CanonicalProductReadService
        ↓
CanonicalProductProjectionReader
        ↓
SqlCanonicalProductProjectionReader

La requête SQL, le filtre multi-marchands, l'ordre et la limite appartiennent à l'adapter SQL legacy. Les helpers et le snippet Product Canonical restent des wrappers/renderers WordPress sans accès direct à $wpdb.

Le wrapper de table historique délègue au helper technique commun chargé par le plugin. Aucun deuxième bootstrap Platform et aucune copie de classe sous wordpress/ ne sont introduits.

Public Frontend Boundary

Le WordPress public garde uniquement les responsabilités d'adapter HTTP :

  • enregistrer les routes et query vars ;
  • résoudre redirects/canonical/template ;
  • appeler le Read Service ou Reader canonique ;
  • rendre HTML/SEO à partir de projections ou d'un payload shimé.

Il ne doit pas exécuter d'écriture persistante pendant une requête publique. La maintenance du fingerprint des rewrites Product Models est donc portée par un bootstrap technique dédié chargé hors renderer frontend.

Les endpoints admin-post protégés suivent la même règle : lecture/sanitization de la requête, vérification de la clé/du contexte HTTP, délégation vers une façade applicative explicite, puis traduction du résultat en JSON/status HTTP. L'adapter ne doit pas appeler directement les use cases legacy de queue, health ou rebuild.

L'endpoint ?ccx_health=1 suit désormais la même frontière : includes/ccx-health.php conserve la détection init, la validation de clé, le mapping feed / limit et la réponse JSON, tandis que includes/application/http-health.php porte le rate-limit technique, l'appel à ccx_health_admin_context() et la décision de statut OK / WARNING / CRITICAL. Le transient ccx_health_lock_v5_<md5(feed:limit)> et sa fenêtre de 10 secondes restent inchangés.

BC-063E2 applique la même logique aux writes techniques WordPress encore nécessaires côté plugin :

  • les consumers legacy n'appellent plus directement update_option() pour l'état technique certifié ;
  • les consumers legacy n'appellent plus directement set_transient() pour les caches/rate-limits certifiés ;
  • les consumers legacy n'appellent plus directement SELECT GET_LOCK(...) / SELECT RELEASE_LOCK(...) pour les named locks certifiés ;
  • ces accès passent par includes/infrastructure/technical-state.php, tandis que les wrappers publics historiques gardent la même signature et les mêmes clés/TTL/timeouts.

BC-063E3 prolonge cette frontière pour la maintenance Cron et Rewrite :

  • includes/runtime/queue-runner.php garde les hooks cron_schedules et ccx_runtime_tick, mais délègue le scheduling à CCX_CronScheduleService ;
  • includes/bootstrap/frontend-route-maintenance.php garde les wrappers publics ccx_product_models_register_rewrites() et ccx_product_models_maybe_flush_rewrites(), mais délègue l'écriture technique à CCX_RewriteMaintenanceService ;
  • les hooks, routes, fréquences et fingerprints restent inchangés ;
  • aucun flush rewrite n'est exécuté sur le trafic frontend public.

BC-063E4 applique la même règle à la surface schema/install/migration :

  • includes/schema.php reste le wrapper historique, mais délègue désormais à CCX_SchemaInstallService ;
  • la migration structurelle legacy reste exécutée derrière CCX_MigrationRunner ;
  • les tables temporaires actives de Taxonomy V2 passent par CCX_TemporarySchemaService ;
  • l'option de version de schéma garde sa clé et sa valeur, mais passe par le store technique ;
  • aucun bootstrap passif WP_CLI ou admin read-only ne doit suffire à installer ou migrer le schéma.

La page WordPress Sync Runtime suit maintenant la même doctrine d'adapter mince :

  • includes/interfaces/admin/sync-runtime.php enregistre les hooks admin, vérifie capability/nonce, mappe les inputs, délègue aux façades et gère redirects/notices ;
  • includes/application/admin-sync-runtime-read.php prépare le view model read-only ;
  • includes/application/admin-sync-runtime-actions.php centralise enable/disable/tick/maintain/start/resume/cancel ;
  • includes/interfaces/admin/sync-runtime-view.php rend l'HTML admin sans SQL, write, runner ni pipeline.

Le contrôleur et la vue ne doivent pas recalculer la vérité runtime. Les writes legacy restent tolérés uniquement derrière la façade d'actions tant que BC-062B4 n'a pas encore remplacé cette couche procédurale.

BC-062B4 démarre la même séparation sur WP-CLI pour ccx sync :

  • includes/interfaces/cli/sync-runtime.php conserve le parsing des arguments, la validation, le format JSON et l'exit code ;
  • includes/application/cli-sync-runtime-read.php centralise les reads status, slow-batches, snapshots status et health ;
  • l'adapter CLI ne contient plus d'appel inline à ccx_sync_health_snapshot(), ccx_feed_snapshot_status() ni de lecture repository directe pour ces sous-commandes ;
  • le bootstrap Quality n'est plus chargé au scope du fichier CLI, seulement via la façade read-only ciblée.

BC-062B4C étend cette frontière aux writes/orchestrations Sync :

  • includes/application/sync-runtime-actions.php porte le noyau commun des actions runtime réutilisables ;
  • includes/application/cli-sync-runtime-actions.php adapte ce noyau aux commandes WP-CLI Sync ;
  • includes/application/admin-sync-runtime-actions.php réutilise maintenant le même noyau pour start, resume, cancel, tick et maintain ;
  • includes/interfaces/cli/sync-runtime.php conserve le parsing/validation, le format JSON et les exit codes, mais ne construit plus directement le runner ni le pipeline pour les commandes Sync traitées dans B4C.

BC-062B4D applique la même règle à ccx taxonomy-v2 :

  • includes/interfaces/cli/taxonomy-v2.php conserve uniquement l'enregistrement WP-CLI, le parsing/validation, la réponse JSON et les erreurs d'arguments ;
  • includes/application/taxonomy-v2-actions.php porte l'orchestration audit, dry-run, apply, cleanup et rollback ;
  • l'adapter CLI taxonomy ne contient plus de SQL, $wpdb, installation de schéma, transaction ou gestion de tables temporaires inline ;
  • audit et dry-run restent des commandes à effets techniques potentiels : elles peuvent installer le schéma ou créer des tables temporaires via l'infrastructure taxonomy, et ne doivent donc pas être présentées comme de simples reads.

BC-062B4E clôt la frontière CLI WordPress :

  • profile n'est plus runner-direct dans includes/interfaces/cli/sync-runtime.php et passe par la façade d'actions Sync ;
  • les adapters CLI certifiés sont maintenant sync-runtime.php et taxonomy-v2.php ;
  • les écritures, la qualité ciblée, le pipeline ciblé, le schéma et l'orchestration taxonomy sont tous sortis des callbacks CLI ;
  • la dette restante est limitée au bootstrap CLI global, documentée pour BC-062C, sans bloquer la certification de la frontière adapter.

BC-062C réduit maintenant ce bootstrap CLI global :

  • includes/bootstrap/cli.php ne charge plus includes/bootstrap/runtime.php ;
  • un bootstrap dédié includes/bootstrap/runtime-cli.php enregistre uniquement les dépendances runtime réellement nécessaires aux commandes CLI ;
  • le CLI simple ne charge plus les stacks admin, health HTTP ni sync monitor par simple bootstrap ;
  • queue-runner.php, bootstrap/pipeline.php et bootstrap/mapping.php ne deviennent plus disponibles dans un wp CLI passif ;
  • le Pipeline reste chargé à la demande uniquement par les façades d'actions Sync qui exécutent réellement une écriture/runtime action.

BC-062C3 réduit ensuite les bootstraps admin/HTTP :

  • includes/bootstrap/admin.php ne charge plus includes/runtime/bootstrap.php pour une page admin read-only ;
  • un bootstrap dédié includes/bootstrap/runtime-admin.php fournit seulement les classes/runtime helpers nécessaires aux façades admin ;
  • ccx-health-reconcile.php n'est plus chargé sur toute page admin par défaut ; il est réservé au monitor admin ciblé et au health public chargé à la demande ;
  • includes/bootstrap/http.php ne charge plus le runtime générique au simple bootstrap HTTP ;
  • includes/interfaces/http/bootstrap.php ne charge le runtime HTTP ciblé et le Pipeline qu'après détection de route valide, validation du groupe et validation de la clé ;
  • includes/application/http-admin-post-actions.php charge le Pipeline uniquement pour l'action worker, pas pour enqueue_all, sync_health ni rebuild_chain.

BC-062C4 réduit enfin le point d'entrée plugin :

  • ccx-feeds.php ne charge plus directement includes/frontend/catalog-view-registry.php ;
  • ccx-feeds.php ne charge plus directement includes/bootstrap/frontend-route-maintenance.php ;
  • un bootstrap technique dédié includes/bootstrap/route-maintenance.php porte désormais ces dépendances ;
  • includes/bootstrap/plugin.php reste le seul point qui connaît ce bootstrap technique ;
  • le loader includes/bootstrap/product-models-application.php garantit aussi le chargement du registry pour les contextes frontend/CLI qui consomment encore les fonctions Product Models legacy.

BC-062C5 clôt la certification bootstrap WordPress sans changement fonctionnel :

ccx-feeds.php
  -> bootstrap/platform.php
  -> bootstrap/plugin.php

bootstrap/plugin.php
  -> bootstrap/route-maintenance.php
  -> bootstrap/worker.php
  -> bootstrap/http.php
  -> bootstrap/admin.php
  -> bootstrap/cli.php
  -> bootstrap/frontend.php

bootstrap/admin.php -> bootstrap/runtime-admin.php
bootstrap/http.php  -> interfaces/http/bootstrap.php -> bootstrap/runtime-http.php (+ Pipeline seulement sur worker autorisé)
bootstrap/cli.php   -> bootstrap/runtime-cli.php
bootstrap/worker.php -> bootstrap/runtime.php

Matrice finale certifiée :

Contexte Bootstrap Capacités chargées Pipeline Frontend Admin Worker
frontend public frontend.php routing + renderer + Product Models/public navigation non oui non non
admin read-only admin.php + runtime-admin.php façades/runtime admin minimaux non non oui non
admin action admin.php + façades admin runtime admin + Pipeline ciblé selon action ciblé non oui non
HTTP feed http.php -> adapter HTTP runtime HTTP ciblé seulement worker autorisé non non non
HTTP health ccx-health.php + http-health.php auth + façade health non non non non
CLI simple cli.php + runtime-cli.php manifestes CLI + runtime minimal non non non non
CLI sync/taxonomy cli.php + façades CLI runtime minimal + Pipeline à la demande ciblé non non non
worker / cron worker.php + runtime.php runtime commun oui si nécessaire non non oui

Dette restante connue : aucune dette bootstrap bloquante dans BC-062C. Les dettes résiduelles éventuelles concernent des couches legacy derrière les façades, pas la frontière bootstrap elle-même.

BC-062D5 clôt ensuite la certification d'isolation des contextes WordPress :

  • aucun adapter WordPress ne doit dépendre d'un autre adapter WordPress ;
  • les globals transport restent confinés à leurs adapters :
  • $_GET, $_POST, $_REQUEST, $_SERVER dans les adapters HTTP/admin seulement ;
  • WP_CLI dans les adapters CLI seulement ;
  • les headers / redirects / réponses JSON dans les adapters HTTP/admin seulement ;
  • les services partagés (sync-runtime-actions, admin-sync-runtime-actions, cli-sync-runtime-actions, http-admin-post-actions, http-health, taxonomy-v2-actions) restent sans output transport ni dépendance frontend/admin/CLI croisée ;
  • le worker / cron reste isolé de frontend, interfaces/admin et interfaces/cli ;
  • le cron passif ne charge pas le Pipeline ;
  • le Pipeline n'est chargé qu'après preuve d'une action explicite ou d'un run reprenable.

Matrice finale certifiée :

Contexte Frontend Admin CLI HTTP Worker Pipeline
frontend request 1 0 0 0 0 0
admin read-only 0 1 0 0 0 0
admin action 0 1 0 0 0 ciblé
CLI simple 0 0 1 0 0 0
CLI write/read ciblé 0 0 1 0 0 ciblé selon commande
HTTP forbidden / health 0 0 0 1 0 0
HTTP worker autorisé 0 0 0 1 1/service ciblé
cron passif / queue vide 0 0 0 0 1 0
worker job simulé 0 0 0 0 1 ciblé

BC-062D peut ainsi être considéré fermé. La suite naturelle devient BC-062E, dédiée à la certification finale de frontière WordPress.

BC-062E clôt ensuite la certification globale WordPress Adapter :

  • ccx-feeds.php reste borné à la config locale éventuelle, au bootstrap Platform puis au bootstrap Plugin ;
  • les bootstraps WordPress restent techniques : sélection de contexte, chargement ciblé, aucun SQL, aucun write, aucune logique métier ;
  • les adapters WordPress restent limités à la traduction transport / WordPress :
  • Frontend : routing, canonical, rendu SEO/HTML à partir de lectures ;
  • Admin : hooks, capability/nonce, mapping d'inputs, redirect/notices ;
  • HTTP : auth, validation, mapping, JSON/status ;
  • CLI : parsing, validation, output WP-CLI ;
  • Worker/Cron : hooks runtime, déclenchement ciblé ;
  • les services/façades communes restent transport-neutral ;
  • aucun adapter public ne contient de SQL direct ni de write inline ;

État courant consolidé :

  • WordPress reste remplaçable ;
  • les bootstraps restent techniques ;
  • les hooks ne portent pas de logique métier ;
  • les écritures passent par des façades ou services explicites ;
  • aucun renderer public ne devient source de vérité métier.
  • le frontend public reste projection-first ;
  • les writes legacy restants appartiennent à des action services, au runtime ou à l'infrastructure, et alimentent la suite BC-063 plutôt que BC-062.

Dette restante explicite après fermeture BC-062 :

  • certaines écritures legacy existent encore derrière des façades ou dans des couches runtime/infra ciblées ;
  • la compatibilité de shape Product Canonical et Catalog legacy reste volontairement conservée ;
  • ces sujets ne remettent pas en cause la frontière Adapter WordPress mais constituent la matière de BC-063.

BC-063E5 clôt ensuite la certification globale des writes techniques WordPress :

  • les writes techniques directs (options, transients, locks, cron, rewrite, schema) restent confinés à leurs adapters dédiés ;
  • aucun chargement passif d'adapter ou de page admin read-only ne doit déclencher de write technique opportuniste ;
  • les derniers install helpers techniques encore actifs passent par le schema adapter ;
  • la dette résiduelle restante est explicitement limitée aux contextes legacy temporaires strict/taxonomy exécutés via commandes ou flux explicites.