99% des cas résolu
Une fois que vous êtes identifié sur le site, dans l’espace privé
1° Aller voir la page de gestion des plugins :
- https://URL_SITE/ecrire/?exec=admin_plugin.
Il n’y a rien à faire dans cette page, juste la visiter.
2° Vider le cache de SPIP
Pour vider le cache de SPIP, rendez-vous dans
- https://URL_SITE/ecrire/?exec=admin_vider
Cliquez sur le premier bouton Vider le cache.
Vous pouvez alors visiter le site et constater que tout va bien.
Problème d’affichage Espace public
Cela n’a pas suffit ?
- Débranchez votre répertoire "squelettes", en renommant le répertoire /squelettes en /squelettes_old
Pour confirmer que le bug, ne vient pas d’une de vos personnalisations.
Le problème persiste ?
==> Alors oui vous pouvez demander de l’aide.
Le problème a disparu ?
==> Alors une de vos personnalisations a créé le défaut, cherchez dans votre répertoire /squelettes le fichier fautif.
- Comment faire ?
- En renommant répertoire par répertoire pour trouver celui dans lequel se trouve le groupe de fichier incriminé,puis renommer fichier par fichier pour trouver le fautif.
Bien entendu entre chaque manipulation, le cache aura été vidé, et les répertoires ou fichiers redisposés avec leur bon nom.
Problème d’affichage Espace privé
Cela n’a pas suffit ?
https://URL_SITE/ecrire/?exec=base_repair
Le problème persiste ?
==> Alors oui vous pouvez demander de l’aide.
Veuillez penser à nous transmettre
l’URL du site
une copie d’écran si possible
Pour aller plus loin ... dans l’analyse
SPIP propose nativement quelques fonctionnalités pour venir en aide au webmestre lors de la phase de débuggage (ou débogage) des squelettes.
Ces fonctions d’information sont accessibles en passant des variables spécifiques dans l’url de la page appelée.
var_mode=calcul et var_mode=recalcul
L’appel de « var_mode=calcul » régénère le code html (lance l’exécution du code déjà compilé) et rafraîchit le cache (crée les fichiers html qui n’auront plus qu’à être lus lors des prochains appels de la page).
L’appel de « var_mode=recalcul » régénère le code php (effectue une nouvelle compilation du squelette), puis régénère le code html (lance l’exécution du code qui vient d’être compilé) enfin rafraîchit le cache (crée les fichiers html qui n’auront plus qu’à être lus lors des prochains appels de la page).
le recalcul de la page régénère aussi les CSS et scripts JavaScript compressés.
le recalcul ne s’applique pas aux images (vignettes, images-typo, ...)
Premier clic appelant « var_mode=calcul »
un second clic appelant « var_mode=recalcul ».
Attention :
On pourrait être tenté d’utiliser &var_mode=recalcul dans des liens de ses squelettes (pour forcer la mise à jour de CSS ou JavaScript par exemple). C’est une très mauvaise pratique qu’il faut éviter car elle est consommatrice de ressources du serveur (re-compilation du squelette).
L’appel de « var_mode=inclure » affiche le nom et le chemin de chaque noisette (« inclure » ou « modèle ») qui compose la page.
Ceci permet de vérifier que les « inclure », réellement appelés par le squelette de la page, sont bien ceux que l’on y a spécifiés.
L’appel de « var_profile=1 » affiche le détail des requêtes SQL et les temps de calcul de chacune. Les requêtes sont classées de la plus gourmande en temps d’exécution à la plus rapide.
Cette fonction est particulièrement utile pour comprendre ce qui peut rendre une page excessivement lente à s’afficher.
Elle permet de visualiser les requêtes SQL générées par chaque boucle du squelette (y compris les squelettes inclus) ainsi que les requêtes hors boucle (notées « Hors Compilation ») générées par SPIP.
Attention :
Penser à calculer la page (&var_profile=1 & var_mode=calcul) pour éviter que ce ne soit le cache qui soit lu, faussant ainsi le résultat affiché.)
L’appel de « var_mode=preview » depuis l’espace privé permet de visualiser dans l’espace public un article de statut « proposé à la publication » sans avoir besoin de le publier.
L’appel de « var_mode=urls » force la mise à jour de toutes les URLs de la page.
L’appel de « var_mode=debug » détaille la génération d’une page (boucles spip - requêtes SQL - code php - statistiques des requêtes SQL).
Très utile en période de debugage, la constante _LOG_FILELINE permet d’ajouter dans les logs le nom du fichier, le numéro de la ligne et le nom de la fonction d’où le log est généré.
Il est possible de déclarer cette constante dans votre fichier config/mes_options.php (voir l’article qui lui est consacré) :
// pour debugage précis
define(’_LOG_FILELINE’, true) ;
Un fichier de log est limité à 100 kilo octets par défaut. Au delà de cette taille, le fichier courant est renommé avec l’extension .log.1 et un nouveau fichier est créé.
l’éventuel .log.1 existant est renommé en .log.2 avant l’opération ci-dessus.
De même,
l’éventuel .log.2 existant est renommé en .log.3 avant l’opération ci-dessus.
Enfin,
l’éventuel .log.3 existant est supprimé avant l’opération ci-dessus.
Tout d’abord sachez qu’il existe les logs du serveur et les logs de SPIP
prenons comme exemple le serveur où est hébergé la plate-forme de SpipFactory.
Côté Serveur : /home/www/spipfactory/log/
access-spipfactory.log
logs d’accès Apache
error-spipfactory.log
log d’erreur Apache
php-error.log
logs d’erreur PHP
php-fpm-slowlog-site.log
logs des processus php/fpm
Côté SPIP
/home/www/spipfactory/public_html/tmp/
spip.log
/home/www/spipfactory/public_html/tmp/log/
mysql.log
mysqlmysql.log
spip.log
Côté SPIP mutualisation : /home/www/spipfactory/public_html/sites/spipfactory.com/tmp/log/
maj.log
spip.log
spip_error.log
sqlite.log
sudo tail -78 Nom_du_fichier.log (n’affichera que les 78 dernières lignes du fichier)
sudo head -128 nom du fichier ( affichera les 128 premières lignes du fichier)
cat nom du fichier lira tout le fichier
cat | more (lira page par page (appuyer sur la touche space pour faire défiler)
fgrep 500 access-xxx.log | grep -v 200 (je ne sais pas à quoi ça sert !)
Le fichier de configuration ecrire/inc_version.php définit la taille maximale des fichiers de log. Lorsqu’un fichier dépasse la taille souhaitée, il est copié sous un autre nom, par exemple prive_spip.log.n (n s’incrémentant). Ce nombre de fichiers copiés est aussi réglable. Il est aussi possible de désactiver les logs en mettant une de ces valeurs à zéro dans mes_options.php.
$GLOBALS[’nombre_de_logs’] = 4 ; // 4 fichiers au plus
$GLOBALS[’taille_des_logs’] = 100 ; // de 100ko au plus
Une constante _MAX_LOG (valant 100 par défaut) indique le nombre d’entrées que chaque appel d’une page peut écrire. Ainsi, après 100 appels de spip_log() par un même script, la fonction ne « log » plus.
et puis
_LOG_FILTRE_GRAVITE
Cette constante définit le niveau maximal de gravité des informations à enregistrer dans les fichiers de log de SPIP.
Par défaut seuls les logs d’erreur sont enregistrés pour réduire la verbosité. Lors de la phase de développement il peut être nécessaire d’ajouter dans votre fichier config/mes_options.php
// définir le niveau maximum de verbosité des logs
define(’_LOG_FILTRE_GRAVITE’, 8) ;
L’écriture historique spip_log(’message’), sans précision du niveau reste supportée mais dépréciée.
Le niveau par défaut est dans ce cas de 5.
Les différentes valeurs de cette constante sont (du moins verbeux au plus verbeux) :
0 (_LOG_HS)
1 (_LOG_ALERTE_ROUGE)
2 (_LOG_CRITIQUE)
3 (_LOG_ERREUR)
4 (_LOG_AVERTISSEMENT)
5 (_LOG_INFO_IMPORTANTE)
6 (_LOG_INFO)
7 (_LOG_DEBUG)
Obtenir encore plus d’informations pour le debugage
En ajoutant dans config/mes_options.php :
< ?php
define(’_NO_CACHE’, 1) ;
?>
ou en cliquant sur le bouton nativement présent depuis SPIP 3 : "Désactiver temporairement le cache"
< ?php
define(’_INTERDIRE_COMPACTE_HEAD_ECRIRE’, true) ;
?>
< ?php
error_reporting(E_ALL^E_NOTICE) ;
ini_set ("display_errors", "On") ;
?>
< ?php
define(’SPIP_ERREUR_REPORT’,E_ALL) ;
?>
< ?php
$GLOBALS[’taille_des_logs’] = 5000 ;
?>
< ?php
define(’_LOG_FILELINE’,true) ;
?>
< ?php
define(’_LOG_FILTRE_GRAVITE’,8) ;
?>
< ?php
define(’_DEBUG_AUTORISER’, true) ;
?>
< ?php
define(’_DEBUG_SLOW_QUERIES’, true) ;
?>
< ?php
define(’_BOUCLE_PROFILER’, 5000) ;
?>
