Page blanche ?

  des pistes d’investigation pour s’en sortir


Votre SPIP est installé, et soudainement....
page blanche ! ? !

Quelques pistes, pour trouver et corriger l’erreur (simple, mais gênant) !

 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 

Autrefois l’angoisse de la page blanche était réservée aux examens... et aux auteurs  !
Mais ce phénomène survient aussi sur le Web ; c’et assez dérangeant, et sous SPIP, il peut y avoir bien des causes ; a priori, il s’agit d’une erreur fatale du calcul de pages de php , mais d’où cela vient-il !

Si la réponse brutale "c’est une erreur PHP , affiche-la en inscrivant :

  1. <?php> // .config/mes_options.php
  2. error_reporting(E_ALL^E_NOTICE);
  3. ini_set ("display_errors", "On");

Télécharger

dans mes_options n’est pas satisfaisante, voici déjà quelques pistes...

 Quelques interrogations

On énumère ci-après quelques questions, dont les réponses éclaireront le diagnostic à porter :
- déjà, avez-vous noté les dernières manipulations que vous avez faites sur votre site SPIP (ajouts de plugins, transfert de fichiers, migrations ou modifications de squelettes...) ?
- en particulier, un ajout ou un nouveau paramétrage de plugin peut révéler des conflits internes inattendus [1] car les plugins surchargent et se greffent à SPIP aux endroits les plus inattendus..
- cette page blanche qui vous bloque, et vous interloque, concerne-t-elle le site public ou bien une commande de l’interface privée, et plus précisément est-ce pour l’Accès à l’interface privée : le back-office ou étiez-vous déjà en espace privé ?
- la version de PHP a changé, et ne reconnait plus votre vieille version de SPIP ; avec l’évolution du PHP, certaines versions ne sont plus acceptées par les hébergeurs, et SPIP plante brutalement : visualiser le source HTML [2] vous montre un arret brusque de l’envoi, avec un tag html incomplet.
Vérifier la version Php par #connaitre_votre_version. Peut-être va-t-il falloir quand meme Mettre SPIP à jour : comment ? ?
- votre hébergement serait-il en cause : problème de capacité (quotas disque, nombre de requêtes BdD, le cache ?), ou -peut-être- des modules additionnels manquants [3], comme xml, mysqli ou autres...
- voir évidemment Des cas..... résolus ! PHP5

 Quelques manipulations en remède

- dans l’interface privée : essayer une autre commande, ou fournir un paramètre ./ecrire/?exec=toto inexistant vous permettra parfois de retrouver ou de contourner l’accès interdit à la page d’accueil.
- rajouter un paramètre de débug à votre URL (cela marche tout aussi bien dans l’interface privée) cf. Se faire aider pour debugger un squelette !
- auriez-vous récemment changé l’URL d’accès (revoir la Configuration / Identité par./ecrire/?exec=configurer_identite [4]), l’emplacement du domaine ou les zones d’accès DNS !
- une mise-à-jour ou l’effacement d’un plugin perturbe l’affichage privé : penser à nettoyer par FTP, jusqu’y compris les ./local/cache*..
- par FTP : supprimer le cache, voire supprimer le contenu des sessions d’auteurs connectés dans ./tmp/sessions/
- le dernier transfert FTP aurait-il rencontré quelques erreur sans prévenir
- vos paramètres de transfert FTP n’auraient-ils pas altéré les fichiers transmis (gestion des caractères de fin, modification inconsciente de codes binaires des images, transformation de la casse de noms de fichiers depuis Windows..) ou altération de fichiers incomplètement transmis... à recommencer !

 Ce n’est pas vous, quoique ?

Il est aussi possible que vous n’y soyez pour rien !
Enfin -indirectement- si SPIP a rempli son disk quota, il ne va plus pouvoir préparer vos pages : pensez à vider le cache par FTP.
Mais si cette "page blanche" arrive aléatoirement, ou seulement sur certains articles ou pages, suspectez aussi les images !
En effet, une autre source de blocage souvent oubliée [5] provient des traitements annexes, des images déposées dans le site, que ce soit par le webmestre, ou simplement par un rédacteur.
Et il faut reconnaitre que le traitement préalable d’images (c’est-à-dire avant leur téléchargement dans SPIP n’est pas pratiqué par tout le monde...

Le serveur doit effectuer ses traitements graphiques, en fonction de sa Configurer SPIP 2 : 3. Fonctions avancées.
Or une image trop importante (ou plusieurs, pour des raisons de time-out du serveur) peut saturer la réponse du serveur, qui ne renvoie finalement ...qu’une page blanche, assez déroutante.

Pour éliminer ces perturbations, du moins les identifier, deux possibilités :
- passer voir dans la Médiathèque ( Edition / Documents en SPIP 3 ) pour regarder si quelques gros documents n’ont pas été insérés récemment...
- vérifier par FTP la taille des plus gros fichiers dans l’arborescence ./IMG/....
- une autre solution, récemment suggérée sur la liste : changer de gestionnaire d’images dans Configurer SPIP 2 : 3. Fonctions avancées : changer le moteur de gestion graphique [6] pour utiliser par exemple convert / imagemagik si disponible...

Pour s’en protéger quelque peu, on peut vouloir fixer des limites par les variables de personnalisation : _IMG_MAX_SIZE travaillera au moment du téléchargement [7], _IMG_MAX_WIDTH et _IMG_MAX_HEIGHT fixeront des limites de cadrage par le moteur SPIP/


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

[1le Couteau Suisse si décrié parfois, propose "pour le pire des cas, un lien permettant de réinitialiser complètement le plugin, en désactivant l’ensemble des outils et en supprimant toutes les variables stockées dans la base de données ecrire/?exec=admin_couteau_suisse&cmd=resetall à utiliser en dernier recours...

[2Souvent par Ctrl+U ou Affichage Source dans votre navigateur...

[3Si quelqu’un peut fournir en référence, la liste des modules obligatoires pour SPIP...

[4Particulièrement lors du retour de l’espace privé vers le site public lors d’une migration de la base de donnée.. je m’y fais prendre souvent ;-) !

[5Y compris par l’auteur /qui ne rencontre pas souvent ce cas ;-)

[6GD et GD2 -souvent recommandés- sont très sensibles à la taille des images traitées, car travaillant dans l’espace PHP !

[7Sans être une sécurité absolue, car la mémoire nécessaire au traitement ci-après dépend de la taille de la photo et non de son poids, lui-même fonciton de la compression evenutelle du fichier image.


Liens visibles seulement pour les inscrits.

Article publié le 3 juin 2015, et actualisé en février 2017 .

Répondre à cet article