Un bug PHP arrive en production, souvent au pire moment. Le réflexe naturel est de corriger vite, dans le code métier, sans se demander d'où vient vraiment le problème. C'est là qu'un correctif peut rater sa cible : on traite le symptôme dans Drupal alors que la cause se trouve parfois un cran plus bas, dans PHP lui-même. De bons drupal bug fixes commencent justement par cette vérification : savoir où regarder avant de toucher au code.
Avant de corriger Drupal, vérifiez que le bug n'est pas déjà corrigé dans PHP
Un cas documenté sur drupal.org l'illustre bien. Un crash suivait une notice de dépréciation PHP 8.1, et l'équipe a d'abord cherché la faute dans le code core. Il s'agissait en réalité d'un bug du moteur PHP lui-même, présent de la version 8.1.0 à 8.1.5, corrigé par la mise à jour vers PHP 8.1.6 (issue drupal.org 3258987). Avant de patcher votre code, vérifiez que le bug n'est pas déjà corrigé dans une version de PHP plus récente.
Cette vérification change l'ordre des opérations. Au lieu de modifier un module custom pour contourner un symptôme, vous isolez d'abord la couche responsable.
Isoler le problème : construire un repro minimal pour des drupal bug fixes qui tiennent
Repartir d'une installation Drupal propre, retirer le superflu
La documentation officielle des contributeurs Drupal est claire sur la méthode : reproduisez le bug sur un site de test propre, puis listez les étapes exactes dans une liste numérotée, précise et courte (guide des contributeurs Drupal). Un site de test propre signifie sans vos modules métier, sans votre thème custom, sans la configuration accumulée depuis des années. Si le bug disparaît sur cette installation nue, la cause est probablement dans votre code, pas dans Drupal ni dans PHP.
Réduire le code PHP au strict minimum qui déclenche encore le bug
Quand la piste mène vers PHP lui-même, la règle du projet est stricte : un code de reproduction ne doit presque jamais dépasser dix lignes (bugs.php.net, comment rapporter un bug). Retirez une ligne à la fois, relancez le test, jusqu'à ce que retirer quoi que ce soit fasse disparaître le bug. Ce qui reste est votre repro minimal. Il sert à confirmer que le problème est réel et à donner à qui le lira, collègue ou mainteneur, un cas qu'il peut exécuter en quelques secondes.
Qualifier l'environnement avant d'écrire le ticket
Vérifier la version PHP supportée par votre version de Drupal
Aucune version supportée de Drupal ne fonctionne avec PHP 7 (exigences PHP de Drupal). Du côté récent, Drupal 11.3 supporte PHP 8.3, 8.4 et 8.5, mais pas PHP 8.1 ni 8.2. Si votre bug apparaît sur une version de PHP que votre Drupal ne supporte pas officiellement, ce n'est pas un ticket que le projet prendra en charge : traitez d'abord l'incompatibilité. Nous détaillons la trajectoire de migration par palier vers PHP 8.5 dans notre article sur la préparation de Drupal face au pic de PHP 8.5.
Lister les extensions PHP en jeu
Toutes les extensions PHP ne pèsent pas pareil dans un diagnostic. PDO doit être activée pour que Drupal 9 et les versions suivantes s'installent et fonctionnent correctement : sans PDO, Drupal ne s'installe pas et ne fonctionne pas correctement. GD, ou une bibliothèque d'images équivalente, est elle aussi une extension requise pour la manipulation d'images. JSON doit être compilé dans le PHP utilisé. cURL, en revanche, est requis pour les tests automatisés et certains modules contrib, pas pour le fonctionnement général de core. mbstring fournit des fonctions utiles au multilingue sans être qualifiée de requise au même titre que PDO ou GD. OpenSSL est recommandée pour les requêtes sortantes en HTTPS, et devient requise dès que l'Update Manager est utilisé (source : exigences PHP de Drupal). Avant d'écrire un ticket, listez précisément lesquelles sont actives sur votre environnement : une extension absente sur un seul serveur d'un cluster suffit à produire un bug qui semble aléatoire.
Ouvrir un ticket exploitable, sans exposer de données sensibles
Les bons champs sur drupal.org : catégorie, version, étapes numérotées
Sur un ticket drupal.org, le champ Category se choisit parmi Bug report pour un problème, Feature request pour une idée nouvelle, Task pour une tâche, et Plan pour une décision à prendre. Un bug PHP reproductible relève du Bug report. Le champ Version, lui, se laisse à sa valeur par défaut : pour Drupal core, c'est la branche « main » (guide des contributeurs Drupal). La version précise de votre installation s'indique plutôt dans le résumé du ticket, pas dans ce champ.
Assainir logs et chemins avant de les joindre
Avant de joindre des logs à un ticket drupal.org, retirez toute information personnelle et remplacez les chemins réels par des versions anonymes, par exemple « /var/www/monsite » devient « [chemin vers le site] » (guide des contributeurs Drupal). Un nom de domaine client, une adresse e-mail ou un identifiant de base n'ont rien à faire dans un ticket public, même tronqués.
Cas particulier : une faille de sécurité ne se documente jamais en public
Si ce que vous observez ressemble à une vulnérabilité plutôt qu'à un bug fonctionnel, la procédure change entièrement. Une faille de sécurité Drupal ne se publie jamais dans le tracker public, et ne se discute jamais sur IRC ni Slack (procédure de signalement sécurité Drupal). C'est la seule situation où le repro minimal reste chez vous, hors de tout canal public, jusqu'à ce que l'équipe de sécurité ait répondu. Nous revenons sur le séquencement des correctifs PHP et Drupal dans notre article sur la sécurité PHP et Drupal.
Drupal.org ou GitHub Issues (php-src) : où porter le bug quand la cause remonte à PHP
Quand votre repro minimal pointe vers PHP et non vers Drupal, le ticket ne se dépose plus sur bugs.php.net : ce tracker historique n'accepte plus de nouveaux rapports (bugs.php.net). Les bugs PHP se déposent désormais sur GitHub Issues, dans le dépôt php/php-src (guide de contribution php-src). Avant d'ouvrir ce ticket, vérifiez qu'une branche PHP activement supportée est bien affectée : la politique du projet demande explicitement de ne pas signaler un bug non sécuritaire sur une branche qui ne l'est plus (bugs.php.net, comment rapporter un bug).
Bonus : patcher temporairement sans diverger de l'amont
Appliquer un patch local avec composer-patches en attendant le correctif amont
En attendant qu'un correctif remonte dans une release officielle, un patch local déclaré via composer-patches permet de tenir sans éditer le code installé à la main : le patch est versionné dans composer.json et réappliqué à chaque installation ou mise à jour du paquet, au lieu d'une retouche dans vendor/ que le prochain composer install effacerait. Pour drupal/core spécifiquement, le niveau de patch doit être forcé à -p2, car ce paquet n'embarque qu'un sous-répertoire du dépôt amont d'origine (documentation composer-patches). Autre point à connaître : par défaut, un patch qui échoue à s'appliquer est simplement ignoré, en silence. L'option composer-exit-on-patch-failure force l'arrêt immédiat du build si un patch ne s'applique plus, ce qui évite de déployer sans savoir que le correctif temporaire a sauté. Notre article sur le réglage de PHP-FPM pour Drupal revient sur d'autres réglages à ne jamais laisser filer en silence.
Ce qu'un patch temporaire ne doit jamais devenir
Un patch composer-patches est une rustine, pas une correction amont acceptée ni un fix fusionné dans Drupal core ou dans PHP. Il doit rester lié au ticket qui l'a motivé, avec une date de retrait prévue dès sa pose. Un patch temporaire que personne ne revient vérifier n'est plus une rustine : c'est une dette créée volontairement, qu'un audit finira par redécouvrir.
Ce qui décide un mainteneur à agir sur votre ticket
Isoler un bug PHP avant de toucher au code Drupal change la nature de votre ticket. Un mainteneur reprend un ticket quand il peut reproduire le bug en quelques minutes sans deviner votre configuration : un cas exécutable en quelques lignes, les versions de PHP et de Drupal en jeu, les extensions actives et des étapes numérotées. Un ticket qui manque un seul de ces éléments attend plus longtemps, ou dort.
Si un bug PHP vous bloque en production et que vous voulez qu'une équipe habituée à ce travail d'isolation s'en occupe : Demander un diagnostic.