fswp-maintainer

FSWP Maintainer

Fondamental (toujours appliqué) : fswp-developer/references/lean-coding.md (écrire moins, réutiliser d'abord), fswp-developer/references/coding-standards.md (normes de codage, documentation, i18n, accessibilité) et fswp-security-engineer (entrée, sortie, autorisation).

Le code existant est la spécification. Exécute une fiche de modification approuvée par fswp-architect (qui a déjà exécuté detect_wp_project.py). Suivez les propres conventions du projet, sauf si elles sont dangereuses ; les modèles maison sont pour les nouveaux projets, pas pour réécrire le style de quelqu'un d'autre.

Mode A : Mettre à jour un plugin ou thème existant

1. Lire d'abord. Lisez les fichiers que la modification touche, leurs appelants et leurs tests. Notez le préfixe, la dénomination, le style de gestion des erreurs et la manière dont les options et les données sont stockées.
2. Reproduire. Pour un bogue, écrivez les étapes et le résultat observé ; confirmez l'échec avant de modifier quoi que ce soit. Pour une fonctionnalité, énoncez le critère d'acceptation.
3. Le plus petit changement qui fonctionne. Corrigez la cause dans le code partagé, pas dans un seul site d'appel. Ne reformatez pas le code non modifié ; les diffs bruités cachent les vraies modifications et brisent le blame.
4. Protéger la surface publique. Les noms de hooks, les noms de fonctions et de classes, les clés d'options, les clés de meta, les routes REST et leurs formes, les attributs de shortcodes et les surcharges de modèles sont des contrats. Pour en changer un, dépréciez d'abord : gardez l'ancien fonctionnel, appelez _deprecated_function() / _deprecated_hook() (ou _deprecated_argument()), documentez le remplacement et ne supprimez pas avant une version majeure ultérieure.
5. Chemin de mise à niveau. Si les données ou le schéma changent : augmentez une option de version stockée, exécutez une migration au chargement (pas seulement à l'activation), rendez-la idempotente et testez la mise à niveau à partir des données de la version précédente sans réactiver.
6. Compatibilité. Respectez les Requires at least et Requires PHP déclarés ; protégez les nouvelles fonctions avec function_exists()/vérifications de version ou augmentez délibérément le minimum et dites-le.
7. Passage sécurité sur le code touché (fswp-security-engineer) : une correction de bogue ne doit pas ajouter un nouveau point d'entrée sans autorisation, nonce, assainissement et échappement.
8. Version et journal des modifications. Correction = correctif, fonctionnalité = mineur, rupture = majeur. Faites évoluer la version du plugin/thème, la constante, la balise Stable de readme.txt et le journal des modifications ensemble.
9. Livrer sous forme de correctif ou de diff pour le dépôt dans lequel l'utilisateur travaille, ou un zip lorsqu'il déploie des fichiers. Incluez le résultat de la checklist de conformité.

Thèmes : préférez un thème enfant ou des modifications de theme.json/variations de style plutôt que d'éditer un thème parent qui reçoit des mises à jour. Les modifications directes sur un parent, et les modifications sur les fichiers de plugins tiers, sont perdues lors de la prochaine mise à jour.

Mode B : Extension pour un produit que vous ne possédez pas

Une extension est un plugin séparé (ou une petite couche de thème) qui étend un hôte. Structurez-la avec fswp-plugin-developer (étapes 1 à 3 et 8), puis appliquez ces règles :

1. Étendre via l'API publique de l'hôte. Utilisez les actions, filtres, registres et routes REST documentés. Ne modifiez jamais les fichiers de l'hôte et évitez d'appeler des parties internes marquées comme privées ou non documentées ; si vous devez le faire, isolez l'appel dans une classe d'adaptation unique et protégez-la.
2. Déclarer la dépendance. Ajoutez Requires Plugins: host-slug dans l'en-tête lorsque l'hôte est sur WordPress.org (WordPress 6.5 et ultérieur l'impose). Détectez également à l'exécution : vérifiez la présence d'une classe, fonction ou constante, ou d'une constante de version, pas le chemin du fichier du plugin.
3. Charger au bon moment. Initialisez sur plugins_loaded (ou le hook ready propre à l'hôte) après avoir confirmé l'existence de l'hôte ; enregistrez-vous sur les hooks de registre de l'hôte, pas avant.
4. Échouer proprement et clairement. Hôte manquant ou trop ancien : ne faites rien d'autre, affichez une notification d'administration expliquant ce qui est nécessaire et ne provoquez jamais d'erreur fatale.
5. Plage de versions. Indiquez les versions de l'hôte prises en charge dans le readme et le plan. Testez la plus basse et la plus récente prise en charge.
6. Déclarations de compatibilité. Certains hôtes vous obligent à déclarer la prise en charge de fonctionnalités. Exemple : WooCommerce attend des extensions qu'elles déclarent leur compatibilité avec le High-Performance Order Storage et le panier et paiement basés sur des blocs. Lisez la documentation développeur de l'hôte pour les appels de déclaration actuels.
7. Propriété des données. Stockez vos données sous votre propre préfixe ; n'écrivez pas dans les tables ou options de l'hôte. La désinstallation ne supprime que vos données.
8. Licence et dénomination. Suivez les règles de marque et de nom de l'hôte pour les noms ; utilisez un style descriptif "pour X" plutôt que de suggérer qu'il est officiel.

Vérifier

Remettez à fswp-qa-engineer avec la liste de conformité de la fiche de modification et le tableau de compatibilité comme source de scénario. Le fichier references/safe-change-checklist.md est la liste rapide de pré-livraison.