Horreur, un message d’erreur PHP ! ?

  Cela pourrait venir d’un squelette ; lequel ?


Il peut arriver que l’exécution d’une page de votre site vous affiche un message d’erreur d’origine PHP [1].

Même si vous pouvez trouver ce type de message particulièrement choquant, il y a tellement de causes possibles, que cela n’est probablement pas aussi grave que vous l’avez pensé au premier abord !

Il y a de fortes chances que cela vienne d’une erreur dans l’un des squelettes utilisés par votre site, et nous verrons quelques commandes pour débuter vos investigations.

 
 
 
 
 
 
 
 
 
 

Distinguons déjà selon les circonstances où vous êtes surpris par ce message, selon que vous venez de faire une modification à votre site (ajouter un article, un document ou un plugin), une mise-à-jour du ’core’ ou des plugins, ou bien "personne n’y a touché" !

 Personne n’y a touché !

A votre connaissance, personne n’a rien fait, mais pas plus en informatique que dans la vraie vie on ne connait de génération spontanée...
Il est possible que votre hébergement ait subi une mise-à-jour, en particulier très souvent les hébergeurs effectuent des montées de versions des logiciels de base, ce qui peut provoquer quelques changements :
- l’un des plus courants est le changement de version : version de PHP, qui montre rapidement des erreurs de PHP function deprecated ; voyez du coté Des cas..... résolus ! PHP5
à neuf cas sur dix : ou un plugin qui s’avère incompatible,ou un souci serveur, soit votre espace est saturé (Connexion impossible.... cache hé ?, soit vous avez un problème de droits : Des cas..... résolus ! PHP5 !
- il peut arriver aussi que votre hébergement soit saturé, soit votre quota disque serait épuisé, soit -parfois rencontré sur la liste- le répertoire de cache, ou celui des sessions ne s’est pas épuré, et le serveur sature : le ftp sera sans doute votre premier outil, en particulier pour Effacer les caches.

 Fatal error

Les erreurs PHP que SPIP signalent viennent le plus souvent d’une erreur dans votre squelette, ou d’un contexte particulier avec les caches :

  1. un grand classique, enduit avec de l’erreur : quelques exemples :
    Fatal error : Call to undefined function courtcircuit_calculer_balise_URL_RUBRIQUE() in I :\www\tmp\cache\skel\html_6ad633d1048b90952504c1da9cc1b1b3.php on line 524
    Fatal error : Cannot redeclare inc_yaml_to_array_dist() (previously declared in I :\www\plugins\auto\yaml\v1.5.0\yaml_fonctions.php:12) in I :\www\_Ulis\_at\ecrire\iterateur\data.php on line 638
    Fatal error : Call to undefined function cs_nettoie() in /home/conc5987/public_html/jesuiscapable/ecrire/public/composer.php(49) : eval()’d code on line 49

Dans le dernier cas, cet eval’()d code qui signifie l’impossibilité de traiter/interpréter en PHP une ligne d’un cache-squelette, n’indique pas une erreur du core (ni ici, du CS , alias le Couteau Suisse !) : mais dans les caches, il reste un lien vers une fonction php qui n’est plus disponible !
Les deux exemples précédents relèvent du même sujet : une fonction [2] n’est plus dans le meme fichier de code : mettre à jour tout !

  • deux réactions immédiates :
  • # désactiver les plugins en renommant le répertoire ./plugins
  • # puis effacez tous les caches (voir en détail Des cas..... résolus ! PHP5)
  1. plus vicieux (et cela arrive même à des plugins ’fondamentaux’)
    - le même,en plus fort :
    Parse error : syntax error, unexpected T_STRING, expecting ’)’ in /home/hebergem/public_html/jessaispas/ecrire/public/evaluer_page.php(55) : eval()’d code on line 48

Cette erreur est levée par PHP à l’exécution de la ligne de code n° 55 du fichier ecrire/public/evaluer_page.php : php évalue la variable $page['texte'] et rencontre une erreur...
C’est l’étape où spip traduit un squelette pré-compilé (un mélange de html et d’appel de fonctions php) en un source html validequi pourra étre transmis au visiteur.

Cette variable contenant les résultats de compilation de squelettes de SPIP contient donc un truc pas net (voire louche) :
cela peut être dû à l’utilisation mal maîtrisée de code php dans un
squelette, à une fonction perso mal codée, à l’utilisation d’un plugin
erroné.....

Il faut repérer le squelette [3] d’où provient cette erreur
(var_mode=inclure est bien utile), puis en décortiquer le code ;
jeter un œil sur var_mode=debug peut aussi ouvrir quelques pistes...

Reste que de nettoyer le cache du serveur (y compris parfois par FTP sur les plugins) reste une mesure de principe immédiat : Connexion impossible.... cache hé ? et Cache-cache Internet : certains problèmes semblent juste dus à un fonctionnement interrompu de SPIP, qui disparaitront en relançant le recalcul de la page...

Sinon, disons que la majorité des cas d’erreur PHP sont simplement dus à des erreurs dans un squelette : le processus de SPIP "plante" l’affichage de la page, mais sans remettre en cause le fonctionnement du site ou sa sécurité.
Les squelettes ne sont pas contrôlés syntaxiquement par SPIP (ce qui alourdirait trop l’exécution,mais une erreur de syntaxe sera décelée rapidement, et de nombreux outils sont proposés par SPIP pour "déverminer" votre environnement, voir : http://www.spip.net/fr_article4453.html.


Et sinon ?

 Foutues Dates : la Zone

Avec les toutes dernières versions de PHP (5.1+ [4]), l’écriture de logs peut générer quelques messages d’erreurs PHP [5]...


Warning : date() [function.date] : It is not safe to rely on the system’s timezone settings. You are *required* to use the date.timezone setting or the date_default_timezone_set() function. In case you used any of those methods and you are still getting this warning, you most likely misspelled the timezone identifier. We selected ’Europe/Paris’ for ’1.0/no DST’ instead in I :\www\_SPN\spippourlesnuls.fr3\ecrire\inc\log.php on line 62

 [6] ;-)

La solution est rapidement précisée sur la liste : voir mes_options (en particulier, le réglage des options de debuggage peut bien vous aider ! )

Créer un fichier « mes_options.php » à placer dans le répertoire « config/ »
et contenant :

  1. <?php
  2. if (function_exists('date_default_timezone_set')){
  3. date_default_timezone_set('Europe/Paris');
  4. }
  5. ?>

Télécharger

 Un parasitage inattendu

Un autre cas d’erreur -pas évident à trouver- provient de traitements sous-jacents, en l’occurrence sur l’affichage d’images chargés par un script php !

La cause en était un reste de ..htaccess faisant appel à des règles de rewriting.

 Diagnostic ?

Un rappel, avant de vous laisser poursuivre votre lecture : les messages d’erreur apparent ne sont pas toujours évidents, ni significatifs : si vous n’êtes pas spécialiste du php, vous aurez probablement plus vite fait de rechercher dans les pages du Web, le même libellé d’anomalie correspondant au symptôme que vous voyez...


Merci de nous signaler les coquilles ou erreurs qui figureraient dans cette page.

[1Disons qu’il n’y a pas de semaine sans qu’une telle question survienne, et c’est toujours aux débutants que cela arrive !!

[2Fonction php, c’est-à-dire du code interne des programmes SPIP

[3S’assurer qu’il n’y a sur le site en cause que les fichiers d’origine d’une version SPIP unique, eventuellement avec une réinstallation complete (sans scories anciennes donc).

[4Voir en php la doc. date-default-timezone-set.php.

[5Des exemples sur Spip Forum en 2.1.19

[6SPN est encore en 2.1.19, meme si le message est obtenu par une version de test en local SPIP 3.0.5 ;-)

[7Disons qu’il n’y a pas de semaine sans qu’une telle question survienne, et c’est toujours aux débutants que cela arrive !!


Liens visibles seulement pour les inscrits.

Article publié le 5 juin 2012, et actualisé en octobre 2014 .

Répondre à cet article