Fatal error: Cannot use positional argument after named argument. Ce message, apparu après une migration vers PHP 8, a mis à l’arrêt l’affichage complet d’une page contenant un widget Elementor personnalisé, développé plusieurs mois auparavant et jamais retouché depuis. Le code n’avait pourtant pas changé : seule la version de PHP avait évolué.
Ce cas illustre bien un type d’erreur propre à l’arrivée d’une nouvelle fonctionnalité du langage : du code qui fonctionnait silencieusement dans une ancienne version de PHP devient brutalement invalide dès qu’une syntaxe auparavant impossible devient, elle, autorisée ailleurs dans le même appel.
Symptôme : une erreur fatale à l’enregistrement du widget
Le widget en question déclarait ses contrôles via un helper interne à l’agence, une petite fonction qui simplifiait l’écriture des appels à add_control() en acceptant certains paramètres sous forme de tableau associatif. Ce helper, à l’intérieur, reconstruisait l’appel réel avec un mélange d’arguments positionnels et d’arguments nommés, une pratique qui n’existait tout simplement pas avant PHP 8.0.
// Le helper maison, simplifié
function wpm_ajouter_controle( $widget, $id, array $args ) {
$widget->add_control(
$id,
type: $args['type'],
$args // ceci provoque l'erreur en PHP 8
);
}Diagnostic : l’ordre des arguments compte désormais
La documentation officielle de PHP sur les arguments de fonction précise la règle introduite avec les arguments nommés, disponibles depuis PHP 8.0 : un argument positionnel (identifié uniquement par sa position dans l’appel) ne peut plus apparaître après un argument nommé (identifié par son nom, sous la forme nom: valeur) dans le même appel de fonction. Avant PHP 8.0, cette syntaxe nommée n’existait pas, donc ce genre de mélange ne pouvait pas se produire.
Dans le helper incriminé, l’argument type: $args['type'] était nommé, mais il était suivi par $args, un tableau passé positionnellement dans l’intention de servir de troisième paramètre classique à add_control(). Ce mélange, syntaxiquement invalide depuis PHP 8.0, provoquait l’erreur fatale dès le chargement du fichier contenant le widget.
Correctif : séparer clairement les deux styles
La correction a consisté à revenir à un appel purement positionnel, conforme à la signature réelle de add_control(), qui attend un identifiant et un tableau de réglages :
function wpm_ajouter_controle( $widget, $id, array $args ) {
$args['type'] = $args['type'] ?? \Elementor\Controls_Manager::TEXT;
$widget->add_control( $id, $args );
}Cette version évite tout mélange entre argument nommé et argument positionnel : elle place la valeur du type directement dans le tableau $args avant de le transmettre en un seul bloc positionnel à add_control(). Le widget s’est enregistré normalement dès cette correction appliquée.
Pourquoi ce genre d’erreur se répète sur d’anciens projets
Les helpers internes développés avant PHP 8.0, quand ils manipulaient dynamiquement des arguments de fonction, n’avaient jamais eu à se soucier de cette règle, absente du langage à l’époque. La migration vers PHP 8 révèle donc parfois des combinaisons d’arguments qui semblaient anodines mais deviennent explicitement invalides.
- Auditer tout helper interne qui construit dynamiquement des appels à
add_control()avant une montée de version PHP. - Préférer un tableau associatif unique en dernier argument plutôt que de mélanger arguments nommés et positionnels.
- Tester l’enregistrement de chaque widget personnalisé sur un environnement PHP 8 avant la mise en production.
Un helper interne écrit avant une nouvelle version du langage mérite toujours une relecture ciblée avant la montée de version, pas seulement un test global du site.
En résumé
Cette erreur, précise et facilement identifiable une fois sa cause comprise, rappelle qu’une migration de version PHP concerne autant le code du cœur WordPress et d’Elementor que les petits helpers internes développés au fil des projets, souvent oubliés au moment de l’audit de compatibilité.
