Chapitre 11.4 — Standards de code & CI/CD

⏱️ TL;DR — Un code pro respecte des standards : WordPress Coding Standards (WPCS) via PHPCS (lint PHP + sécurité), PHPStan (analyse statique/types), et le lint JS/CSS de @wordpress/scripts (ESLint/Prettier). On automatise tout dans une CI (GitHub Actions) qui, à chaque push/PR, lance lint + PHPStan + PHPUnit + Jest (+ e2e) sur une matrice de versions PHP/WordPress. Résultat : un code cohérent, sûr, compatible, et une CI verte qui rassure clients et marketplaces. Le déploiement peut aussi être automatisé (CD).

🎯 Objectifs

• Mettre en place PHPCS (WPCS) et PHPStan.
• Utiliser le lint JS/CSS de @wordpress/scripts.
• Écrire un workflow CI (GitHub Actions) avec matrice.
• Comprendre l’intérêt (qualité, compat, crédibilité).

1. PHPCS + WordPress Coding Standards

PHPCS (PHP_CodeSniffer) vérifie le style et des règles de sécurité ; les WordPress Coding Standards (WPCS) ajoutent les conventions WordPress (échappement, nonces, préfixes, i18n…).

composer require --dev wp-coding-standards/wpcs dealerdirect/phpcodesniffer-composer-installer
vendor/bin/phpcs --standard=WordPress mon-plugin/    # analyser
vendor/bin/phpcbf --standard=WordPress mon-plugin/   # corriger l'auto-corrigeable

Un fichier .phpcs.xml.dist configure les règles (standard, exclusions, version PHP cible, text domain vérifié) :

<?xml version="1.0"?>
<ruleset name="WPR">
  <rule ref="WordPress"/>
  <config name="minimum_supported_wp_version" value="6.4"/>
  <rule ref="WordPress.WP.I18n">
    <properties><property name="text_domain" type="array"><element value="wpr-books"/></property></properties>
  </rule>
</ruleset>

⚠️ Piège — désactiver les règles de sécurité pour « passer ». WPCS signale des manques d’échappement/nonce (Partie 7.7). La tentation de tout mettre en phpcs:ignore pour avoir une sortie propre masque de vraies failles. Corrigez le code plutôt que de museler l’outil ; n’ignorez une règle qu’avec une justification réelle.

2. PHPStan (analyse statique)

PHPStan détecte des bugs sans exécuter le code (types, appels invalides, propriétés inexistantes). Avec les stubs WordPress (php-stubs/wordpress-stubs), il comprend les fonctions du cœur :

# phpstan.neon
parameters:
  level: 5
  paths: [ includes/ ]
  bootstrapFiles: [ vendor/php-stubs/wordpress-stubs/wordpress-stubs.php ]

PHPStan attrape des erreurs que le lint de style ne voit pas (mauvais type passé, oubli de null). On monte le level progressivement.

3. Lint JS/CSS (blocs)

@wordpress/scripts fournit ESLint/Prettier/stylelint préconfigurés aux standards WordPress :

npm run lint:js
npm run lint:css
npm run format      # Prettier

→ code JS des blocs (Partie 8) cohérent et conforme, sans config à écrire.

4. La CI (GitHub Actions)

Un workflow lance tout à chaque push/PR, sur une matrice :

# .github/workflows/ci.yml
name: CI
on: [push, pull_request]
jobs:
  php:
    runs-on: ubuntu-latest
    strategy:
      matrix:
        php: [ '8.1', '8.2', '8.3' ]
    steps:
      - uses: actions/checkout@v4
      - uses: shivammathur/setup-php@v2
        with: { php-version: '${{ matrix.php }}' }
      - run: composer install
      - run: vendor/bin/phpcs --standard=WordPress .
      - run: vendor/bin/phpstan analyse
      - run: vendor/bin/phpunit
  js:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-node@v4
      - run: npm ci
      - run: npm run lint:js
      - run: npm run test:unit
      - run: npm run build

• Matrice PHP (8.1/8.2/8.3) : garantit la compatibilité multi-versions.
• On ajoute souvent une matrice versions WordPress (via wp-env) et un job e2e (Playwright) pour les flux critiques.
• moodle-plugin-ci… pardon — l’équivalent WordPress est le workflow ci-dessus (ou des actions communautaires « wp-plugin-ci »).

💡 Pour un dev React — C’est votre CI habituelle : lint + typecheck + tests + build, sur une matrice de versions, à chaque PR. La spécificité WordPress est la matrice PHP × WordPress (Woo/WP évoluent 2-3×/an) : tester contre les versions supportées attrape les régressions avant les clients. Une CI verte est un argument de vente (marketplace, freelance) : elle prouve que votre plugin est maintenu et compatible.

5. CD (déploiement) — aperçu

La CI valide ; la CD (continuous delivery) déploie. Pour un plugin wp.org, une action peut publier sur le SVN du répertoire à chaque tag (ch. 11.8). Pour un site client, un workflow peut déployer sur le serveur (rsync/SSH, ou l’API de l’hébergeur) après validation. Le déploiement se traite comme n’importe quel projet moderne — versionné, automatisé, réversible (Partie 11.6).

✏️ Exercices

1. Quel outil vérifie à la fois le style et des règles de sécurité WordPress ?
2. Pourquoi tester sur une matrice de versions PHP/WordPress en CI ?
3. WPCS signale un manque d’échappement. Que faites-vous (bonne et mauvaise réponse) ?

🧠 Quiz de révision

Chapitre suivant : Multisite.