PHP Fatal error: Uncaught Error: Object of class WPML_Element_Translation_Package could not be converted to string. C’est le message qui apparaît, en toutes lettres, dans les journaux d’erreurs juste après la mise à jour d’une extension tierce sur un site WPML. Le site entier renvoie une page blanche, code 500, front comme back-office.
Ce message a un défaut : il pointe vers une classe interne de WPML, ce qui pousse presque toujours à soupçonner WPML en premier. Or dans l’immense majorité des cas rencontrés, WPML n’est pas fautif : il est simplement la victime d’un ordre de chargement des extensions devenu incohérent après la mise à jour.
Symptôme : tout s’arrête net après une mise à jour anodine
Le scénario type : une extension de formulaire ou de SEO se met à jour automatiquement (mises à jour automatiques activées via un filtre ou un outil de maintenance), et quelques minutes plus tard le site affiche une erreur 500. En consultant wp-content/debug.log, la trace remonte systématiquement à une méthode WPML appelée par l’extension tierce, avec une classe non trouvée ou un objet manipulé comme une chaîne de caractères.
Le réflexe de désactiver WPML pour tester est compréhensible, mais il masque le vrai problème : ce n’est pas WPML qui est cassé, c’est l’extension tierce qui appelle une classe WPML avant que celle-ci soit chargée en mémoire.
Diagnostic : l’ordre des hooks plugins_loaded
WPML enregistre ses classes principales sur le hook plugins_loaded, avec une priorité par défaut. Si l’extension tierce s’exécute plus tôt dans la même chaîne de hooks — parce qu’elle a été activée après une mise à jour qui a changé son ordre dans la table wp_options, champ active_plugins — elle peut tenter d’utiliser une classe WPML qui n’existe pas encore à cet instant précis de l’exécution.
// Ce que fait WPML, en simplifié
add_action( 'plugins_loaded', function() {
// Enregistrement des classes de traduction
new WPML_Element_Translation_Package();
}, 6 );
// Ce que fait l'extension tierce, si elle est chargée AVANT
add_action( 'plugins_loaded', function() {
// Cette classe n'existe pas encore si l'extension
// se charge à une priorité inférieure à 6
echo new WPML_Element_Translation_Package();
}, 5 );La liste des extensions activées dans wp_options est chargée dans l’ordre où elle a été enregistrée, et une mise à jour peut réordonner cette liste si l’extension a été désactivée puis réactivée automatiquement pendant le processus de mise à jour groupée.
Correctif : remonter WPML dans l’ordre de chargement
La solution la plus rapide, sans toucher une ligne de code, consiste à désactiver puis réactiver WPML en dernier depuis l’écran Extensions du back-office :
- Se connecter en FTP ou SSH pour désactiver temporairement l’extension fautive via son fichier, si le back-office est inaccessible (renommer son dossier dans
wp-content/pluginssuffit à couper l’erreur) - Revenir sur le back-office, désactiver WPML normalement
- Réactiver WPML en dernier, après toutes les autres extensions
- Réactiver l’extension tierce renommée en remettant son dossier d’origine
Réactiver WPML en dernier place son hook plugins_loaded après celui des autres extensions dans la liste sérialisée de active_plugins, ce qui garantit dans la plupart des configurations que ses classes sont bien enregistrées avant que quiconque tente de les appeler. Ce n’est pas une garantie absolue — deux extensions avec des priorités explicites peuvent toujours entrer en conflit — mais cela résout l’écrasante majorité des cas de ce message précis.
Prévention : ne jamais laisser les auto-updates actives sur un site WPML critique
Sur un site avec WPML et plus de trois extensions tierces qui touchent au contenu, je désactive systématiquement les mises à jour automatiques et je passe par un environnement de recette avant chaque montée de version, même mineure.
Les mises à jour automatiques de plugins, lorsqu’on les active (filtre auto_update_plugin ou outil de maintenance), sont une excellente nouvelle pour la sécurité, mais un vrai risque pour l’ordre de chargement sur un site multilingue complexe. La recommandation concrète : désactiver l’auto-update sur les extensions qui manipulent directement le contenu multilingue (formulaires, SEO, ACF), et garder l’auto-update uniquement sur les extensions purement techniques (sécurité, cache).
En résumé
Un message d’erreur qui cite une classe WPML ne signifie pas que WPML est cassé. Dans ce cas précis, c’est un problème d’ordre de chargement provoqué par une mise à jour, résolu en réactivant WPML en dernier dans la liste des extensions. Garder ce réflexe en tête évite de perdre une heure à réinstaller un multilingue qui n’a jamais été fautif.
