debug = 1

Niveau intermédiaire

Joomla cassé après une mise à jour : activer le debug et lire l'erreur

Après une mise à jour, Joomla affiche une erreur sans détail. Comment activer le debug même sans accès à l'administration, et où lire l'erreur.

Une mise à jour Joomla qui se passe mal laisse rarement un message utile. Le site affiche une page blanche, ou une erreur générique, et l'administration devient parfois inaccessible en même temps. Ce dernier point est ce qui met les gens en difficulté : le réglage à changer se trouve précisément dans l'administration.

Il existe une porte de service.

Activer le debug sans passer par l'administration

Le fichier configuration.php, à la racine du site, contient toute la configuration. Ouvrez-le en FTP et modifiez deux lignes :

public $debug = '1';
public $error_reporting = 'maximum';

Rechargez : l'erreur s'affiche, avec le fichier et la ligne.

C'est la manœuvre à connaître, parce qu'elle fonctionne quand plus rien d'autre ne fonctionne. Les mêmes réglages sont accessibles dans Système puis Configuration globale puis onglet Système quand l'administration répond encore.

À remettre en place aussitôt. Un Joomla laissé en debug = 1 affiche ses chemins, ses requêtes SQL et la liste de ses extensions à tout visiteur. C'est un plan détaillé offert à qui cherche une faille.

Les trois causes d'un Joomla cassé après mise à jour

Une extension incompatible. La plus fréquente. Une extension écrite pour une version antérieure appelle une classe ou une méthode qui a disparu. L'erreur désigne alors un fichier dans components/, modules/ ou plugins/, et le nom du dossier vous donne l'extension coupable.

Un template dépassé. Même mécanique, mais le fichier fautif est dans templates/. Le symptôme typique est un site public cassé alors que l'administration fonctionne parfaitement, parce que l'administration utilise un autre template.

Une mise à jour de base interrompue. Le schéma est à moitié migré. Les erreurs parlent alors de colonnes ou de tables inconnues, et elles apparaissent de façon erratique selon les pages.

Où est le journal

Joomla écrit dans le dossier défini par $log_path dans configuration.php, généralement administrator/logs/. Le fichier utile est error.php.

Attention : ce fichier ne contient que ce que Joomla a réussi à journaliser. Si l'erreur survient avant le chargement du framework, typiquement une erreur de syntaxe dans configuration.php, il restera vide. La réponse est alors dans le journal PHP de l'hébergeur.

C'est la même logique que sur WordPress : un journal applicatif vide veut dire que l'application n'a jamais démarré, et qu'il faut monter d'un cran.

Le dépannage en aveugle, quand rien ne répond

Si le site et l'administration sont tous deux inaccessibles :

1. Activez le debug dans configuration.php comme ci-dessus.
2. Si l'erreur désigne un template, forcez le template par défaut en renommant le dossier du template actif dans templates/. Joomla se rabat sur celui du cœur.
3. Si elle désigne un plugin, renommez son dossier dans plugins/. Joomla passe outre ce qu'il ne trouve plus.
4. Si l'erreur parle de base de données, allez dans Système puis Panneau de mise à jour puis Base de données une fois l'administration revenue, et lancez la correction du schéma.

L'étape 4 est spécifique à Joomla et méconnue. Cet outil compare le schéma réel à celui attendu par la version installée, et propose de corriger. Il répare seul beaucoup de mises à jour interrompues.

Refermer

Repassez $debug à '0' et $error_reporting à 'default'. Videz le cache dans Système puis Vider le cache.

Si l'erreur désigne une extension commerciale dont vous n'avez plus la licence, il existe presque toujours un contournement propre qui ne consiste pas à modifier le cœur de Joomla. Décrivez-moi la trace.