# PHP 8.2 et Elementor : quand un widget personnalisé sème des dépréciations

> Message d'erreur précis rencontré sur un widget maison lors d'une montée vers PHP 8.2, diagnostic et correctif appliqué au code du widget.

- Auteur : WordPress Développement
- Publié le : 2023-02-05
- Mis à jour le : 2023-02-05
- Catégorie : Elementor
- URL : https://www.wpmoderne.fr/elementor/php-82-elementor-widgets-personnalises-depreciation/

## L’essentiel

- Symptôme identifié dans les logs PHP
- Cause liée à une propriété dynamique
- Correctif sans casser la compatibilité descendante

`Deprecated: Creation of dynamic property Widget_Compteur::$cache_key is deprecated in /wp-content/plugins/widgets-maison/widget-compteur.php on line 34`. Voilà le message qui a rempli le fichier de log PHP en quelques minutes après le passage d'un environnement de recette vers PHP 8.2, sur un site construit avec Elementor et une dizaine de widgets personnalisés développés en interne au fil des années.

PHP 8.2 introduit la dépréciation des propriétés dynamiques : toute propriété assignée à un objet sans avoir été déclarée explicitement dans la classe déclenche désormais un avertissement, même si le code continue de fonctionner. Sur un widget Elementor hérité, ce genre de propriété ajoutée « au fil de l'eau » est fréquent, surtout dans du code écrit avant que la classe `Widget_Base` ne serve de base stricte à toutes les extensions internes.

## Reproduire le problème isolément

Avant de corriger quoi que ce soit, il fallait isoler la source exacte : sur ce projet, dix widgets personnalisés coexistaient, et les logs ne remontaient pas systématiquement le nom du fichier en environnement de production avec l'affichage des erreurs désactivé. Le passage temporaire de `WP_DEBUG_LOG` à `true` sur l'environnement de recette, combiné à un filtre sur `error_log`, a permis d'identifier précisément la classe fautive.

Le widget en cause, `Widget_Compteur`, affichait un compteur animé et stockait une clé de cache calculée à la volée directement en tant que propriété d'instance, sans jamais la déclarer dans l'en-tête de la classe.

## Le code fautif

```
class Widget_Compteur extends \Elementor\Widget_Base {

    public function get_name() {
        return 'widget-compteur';
    }

    protected function render() {
        $this->cache_key = 'compteur_' . $this->get_id();
        // ... utilisation de $this->cache_key plus loin
    }
}
```

> L'essentiel à retenir : Symptôme identifié dans les logs PHP ; Cause liée à une propriété dynamique ; Correctif sans casser la compatibilité descendante

Ici, `cache_key` n'existe nulle part dans la déclaration de la classe : PHP l'autorisait en création dynamique jusqu'à PHP 8.1 inclus, et PHP 8.2 la signale désormais comme dépréciée, en prévision d'une suppression future du comportement.

## Le correctif appliqué

La correction tient en une déclaration de propriété typée ajoutée en tête de classe, sans toucher à la logique du widget :

```
class Widget_Compteur extends \Elementor\Widget_Base {

    protected string $cache_key = '';

    protected function render() {
        $this->cache_key = 'compteur_' . $this->get_id();
    }
}
```

Ce correctif ne modifie ni le comportement fonctionnel du widget, ni sa compatibilité avec les versions de PHP antérieures : une propriété typée déclarée explicitement fonctionne identiquement de PHP 7.4 à PHP 8.2 et au-delà.

## Généraliser le correctif aux autres widgets

Sur les neuf autres widgets du parc, la même recherche a révélé quatre cas similaires, tous liés à des propriétés de cache ou de compteur ajoutées après coup. Une revue systématique du code source de chaque widget personnalisé, en cherchant les occurrences de `$this->` suivies d'un nom de propriété absent de l'en-tête de classe, a permis de traiter l'ensemble en une seule session de travail.

- Rechercher chaque assignation `$this->propriete = ...` dans les widgets personnalisés
- Vérifier que chaque propriété est déclarée dans l'en-tête de la classe
- Ajouter un typage explicite (`string`, `int`, `array`) plutôt qu'une déclaration nue
- Rejouer les tests de recette sur PHP 8.2 avant bascule en production

## Ce que cet article ne couvre pas

D'autres dépréciations existent en PHP 8.2, notamment autour des méthodes magiques ou de certaines fonctions de manipulation de chaînes, sans lien avec ce cas précis. La migration des extensions tierces (plugins non maison) suit un chemin différent, dépendant du rythme de mise à jour de chaque éditeur, et n'entre pas dans le périmètre de cet article centré sur du code interne.

> Une propriété dynamique qui « marche quand même » reste une dette technique : PHP 8.2 se contente de la rendre visible avant qu'elle ne devienne bloquante.

## En résumé

Ce cas illustre un principe simple à retenir pour toute équipe qui maintient des widgets Elementor personnalisés : déclarer explicitement chaque propriété de classe coûte une ligne de code et évite des centaines d'avertissements lors de la prochaine montée de version PHP. Un correctif ponctuel comme celui-ci prend quelques minutes ; le repérer sans audit préalable peut prendre bien plus longtemps.