Comment résoudre l’erreur ‘Non-static method should not be called statiquement’ sur WordPress ? Guide complet

Comprendre l’erreur ‘Non-static method should not be called statically’

L’erreur ‘Non-static method should not be called statically’ apparaît souvent sur WordPress lorsqu’un développeur ou un plugin appelle une méthode non-statique comme si elle était statique. En PHP, une méthode non-statique appartient à une instance de classe, tandis qu’une méthode statique appartient à la classe elle-même. L’appel incorrect déclenche une notification de niveau E_STRICT ou une erreur fatale selon la version de PHP.

Cette erreur peut bloquer l’affichage de votre site, rendre certaines pages inaccessibles ou provoquer un écran blanc. Heureusement, elle se résout généralement par une correction dans le code du thème, d’un plugin ou du fichier functions.php.

Pourquoi cette erreur se produit-elle sur WordPress ?

WordPress utilise massivement la programmation orientée objet. De nombreux plugins et thèmes définissent des classes avec des méthodes non-statiques. Si un développeur utilise l’opérateur :: (double deux-points) pour appeler une méthode sans créer d’instance, PHP génère l’erreur. Par exemple :

MaClasse::maMethode(); // Erreur si maMethode n'est pas statique

Au lieu de :

$objet = new MaClasse();
$objet->maMethode(); // Correct

Les causes fréquentes incluent :

• Thème obsolète : appelle des méthodes de classes WordPress sans instance.
• Plugin mal codé : utilise des appels statiques pour des méthodes d’instance.
• Mise à jour de PHP : les versions récentes (7.0+) sont plus strictes sur ce type d’erreur.
• Fichier functions.php : contient des appels incorrects à des méthodes de classes natives WordPress.

Comment identifier la source de l’erreur

Activer le débogage WordPress

Pour localiser précisément la ligne et le fichier en cause, activez le mode débogage dans wp-config.php :

define('WP_DEBUG', true);
define('WP_DEBUG_DISPLAY', true);
define('WP_DEBUG_LOG', true);

Consultez ensuite le fichier wp-content/debug.log. Vous y trouverez le message d’erreur complet avec le chemin du fichier et le numéro de ligne.

Utiliser un outil de diagnostic

Des plugins comme Query Monitor ou Error Log Viewer peuvent afficher l’erreur directement dans la barre d’administration. Cela évite de modifier le fichier de configuration.

Désactiver les plugins un par un

Si l’erreur apparaît sur tout le site, désactivez tous les plugins. Si elle disparaît, réactivez-les un par un jusqu’à trouver le coupable. Faites de même avec le thème : passez temporairement à un thème par défaut (Twenty Twenty-Four) pour tester.

Solutions pour corriger l’erreur

Solution 1 : Rendre la méthode statique (si possible)

Si la méthode n’utilise pas $this, vous pouvez la déclarer comme statique en ajoutant le mot-clé static :

class MaClasse {
    public static function maMethode() {
        // code
    }
}

Ensuite, l’appel MaClasse::maMethode(); devient valide. Cette solution est rapide mais modifie le code source du plugin ou du thème. Attention : les mises à jour ultérieures écraseront vos modifications.

Solution 2 : Appeler la méthode via une instance

Remplacez l’appel statique par la création d’un objet :

$instance = new MaClasse();
$instance->maMethode();

Dans le contexte de WordPress, si l’erreur provient d’un fichier de thème ou de functions.php, vous devez souvent récupérer une instance existante plutôt que d’en créer une nouvelle. Par exemple, pour la classe WP_Query :

// Erreur
$posts = WP_Query::get_posts();

// Correction
$query = new WP_Query();
$posts = $query->get_posts();

Solution 3 : Utiliser un hook pour accéder à l’instance globale

WordPress fournit des instances globales comme $wpdb ou $wp. Si l’erreur concerne une de ces classes, utilisez le mot-clé global :

global $wpdb;
$resultats = $wpdb->get_results("SELECT * FROM wp_posts");

Évitez d’appeler $wpdb::get_results() qui est incorrect.

Solution 4 : Corriger le code du plugin ou du thème

Si vous avez identifié le fichier incriminé, ouvrez-le et cherchez les appels utilisant ::. Remplacez-les par des appels via -> après avoir créé une instance ou utilisé une instance existante. Pour les plugins, pensez à signaler l’erreur à l’auteur ou à utiliser un correctif temporaire (surcharge de classe via un plugin de personnalisation).

Exemples concrets d’erreurs et leurs corrections

Exemple 1 : Erreur dans un thème enfant

Supposons que le fichier functions.php de votre thème enfant contienne :

MyTheme::setup();

Si setup() n’est pas statique, l’erreur apparaît. Corrigez en instanciant d’abord :

$theme = new MyTheme();
$theme->setup();

Exemple 2 : Appel à une méthode de classe WordPress

Un plugin peut tenter d’utiliser WP_List_Table::prepare_items(). Comme cette méthode n’est pas statique, il faut d’abord créer une instance :

$table = new WP_List_Table();
$table->prepare_items();

Bonnes pratiques pour éviter cette erreur à l’avenir

• Respectez la programmation orientée objet : utilisez self:: ou static:: pour les méthodes statiques, et $this-> pour les méthodes d’instance.
• Testez votre code avec PHP_CodeSniffer : des règles comme Generic.PHP.NoSilencedErrors ou WordPress.NamingConventions détectent les appels incorrects.
• Mettez à jour PHP et WordPress : les versions récentes affichent des avertissements clairs.
• Utilisez un environnement de développement : activez WP_DEBUG en local pour repérer les erreurs avant la mise en production.
• Préférez les plugins et thèmes bien codés : vérifiez les avis et la fréquence des mises à jour.

Checklist de résolution rapide

1. Activer le débogage WordPress pour obtenir le message d’erreur complet.
2. Identifier le fichier et la ligne incriminés.
3. Désactiver les plugins et le thème pour isoler la source.
4. Appliquer la correction appropriée (rendre statique ou instancier).
5. Tester la correction sur une copie du site ou en local.
6. Désactiver le débogage en production.

Questions fréquentes (FAQ)

Puis-je ignorer cette erreur si mon site fonctionne ?

Non, même si le site s’affiche, l’erreur peut ralentir les performances et causer des problèmes de sécurité. De plus, avec PHP 8, elle devient une erreur fatale.

Dois-je modifier le code du plugin ou du thème ?

Si vous êtes à l’aise, oui. Sinon, contactez le développeur ou cherchez une alternative. Utilisez un plugin de surcharge pour appliquer des correctifs sans perdre les mises à jour.

L’erreur peut-elle provenir d’un conflit entre plugins ?

Oui, parfois deux plugins tentent d’appeler la même méthode de manière incorrecte. Désactivez-les un par un pour identifier le conflit.

Comment corriger l’erreur sans accès au code source ?

Utilisez un plugin comme Code Snippets pour ajouter un correctif temporaire, ou remplacez le plugin par un équivalent mieux codé.

Cette erreur affecte-t-elle le SEO ?

Indirectement, oui : si l’erreur provoque un écran blanc, les moteurs de recherche ne pourront pas indexer vos pages. Corrigez-la rapidement.

Recommandations pour un site WordPress stable

Pour éviter ce genre d’erreur, privilégiez des plugins et thèmes régulièrement mis à jour, respectant les normes de codage WordPress. Utilisez un environnement de staging pour tester les mises à jour. Enfin, formez-vous aux bases de la POO en PHP : comprendre la différence entre statique et instance est essentiel pour maintenir un site performant.

Si l’erreur persiste après ces étapes, n’hésitez pas à consulter les forums WordPress ou à faire appel à un développeur spécialisé. La résolution de ce problème est généralement rapide et vous évitera des maux de tête futurs.