- gros travail sur le debuggueur : les boutons de debug s'affichent
maintenant dès qu'une erreur php a été détéctée dans l'exécution de la page,
les erreurs 'parse error' ou 'fatal error' sont traitées (ce qui n'a pas été
facile...)
- les fichiers du cache sont stockés en mode compressé (quand c'est
possible)
- la compression auto est redéconnectée des post-traitements de page (trop
de problèmes, notamment sur spip-contrib)
par ailleurs petites corrections, suppression de code mort, etc.
notamment, il devient {possible} de mettre 'spip2' comme préfixe de cookies
(ça évitera des troubles)
J'espère que le déroulé des opérations dans inc-public - inc-cache -
inc-calcul - inc-calcul-squel est plus lisible maintenant ; la partie
"affichage des boutons d'admin", en revanche, est vraiment méchante
OK, j'attaque
mais d'abord, merci de faire ce travail aussi vite. La balise pour le formulaire admin marche enfin
- spip_login.php?lang=fr:
la page s'affiche bien et je peux me logguer, mais, en bas, il y a écrit:
"Erreur dans le squelette login.html"
- ça va avoir l'air bête comme exemple, mais ça m'arrive dans d'autre squelette bien plus complexe. Si je fait un fichier Test.html, qui inclus Test2.html comme suit:
Test.html:
<INCLURE(Test2.php)>
Test2.html:
<? ?>
j'ai cette erreur:
Warning: array_push(): First argument should be an array in /Users/andrews/Sites/inc-public.php on line 12
Warning: array_pop(): The argument should be an array in /Users/andrews/Sites/inc-public.php on line 16
- spip_login.php?lang=fr:
la page s'affiche bien et je peux me logguer, mais, en bas, il y a écrit:
"Erreur dans le squelette login.html"
Ca c'est sans doute parce qu'un des fonctions appelées fait un exit(), ce
qui déclenche la détection d'erreur... donc il faut nettoyer les exit(), ou
modifier le mécanisme de détection d'erreurs : je m'explique, pour savoir si
la page a été parsée correctement ou pas, je lui ajoute une ligne de php
<?php define(...) ?>, que je teste ensuite. Si exit(), la ligne en question
n'est pas vue.
La solution serait d'utiliser un vrai error_handler qui lèverait un drapeau
global.
j'ai cette erreur:
Warning: array_push(): First argument should be an array in
/Users/andrews/Sites/inc-public.php on line 12
Warning: array_pop(): The argument should be an array in
/Users/andrews/Sites/inc-public.php on line 16
- spip_login.php?lang=fr:
la page s'affiche bien et je peux me logguer, mais, en bas, il y a
écrit: "Erreur dans le squelette login.html"
Même erreur + le formulaire login boucle sur lui-même au mot de passe avec
un contenu de page vide (si je rajoute &recalcul=oui à l'URL, je reviens sur
la mire mot de passe).
Je précise que j'ai vidé le cache.
Par contre, à la racine du disque dur qui contient le site (je suis sous
W2000), j'ai un fichier de cache qui est créé (hors de dossier CACHE, donc
!?!)
Le voici : d41d8c-908412d189a2501e.tmp
<!-- a:1:{s:11:"process_ins";s:3:"php";} -->
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN"
"http://www.w3.org/TR/html4/loose.dtd">
<html lang="fr">
<head>
<title>accès à l'espace privé</title>
<meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1">
<link rel="stylesheet" href="spip_style.css" type="text/css">
</head>
<body dir="ltr" bgcolor="#ffffff" text="#000000" link="#e86519"
vlink="#6e003a" alink="#ff9900">
<br><br><br><center><table width="400"><tr><td width="400">
<div align="center">
<h3 class="spip">Services de création de sites avec SPIP<br>
<small>accès à l'espace privé</small></h3>
<div align="right"><?php
include_ecrire("inc_lang.php3");
echo menu_langues("var_lang_ecrire", $menu_lang);
?></div>
</div>
<?php include('inc-login.php3'); login('', 'prive'); ?>
</td></tr></table></center>
</body>
</html>
Ça, c'est un bug, un vrai de vrai ! Que fait ce fichier en dehors du site
web ?
- spip_login.php?lang=fr:
la page s'affiche bien et je peux me logguer, mais, en bas, il y a
écrit: "Erreur dans le squelette login.html"
.../...
Ça, c'est un bug, un vrai de vrai ! Que fait ce fichier en dehors du
site web ?
quant à mon dossier cache, il contient bien des fichier (genre
spip_login.ec6a47f2 et spip_login.ec6a47f2.NEW), mais ceux-ci sont de taille
0 et vide (comme il se doit avec une pareille taille).
Suite au commit de 1h16, il n'y a plus le problème de l'affichage de erreur
dans le fichier login.html.
Mais j'ai toujours un bouclage sur la page de login avec un retour sur une
page blanche (et dans le cache, spip_login.ec6a47f2 est à 0 octect)
Ça va venir...
Mais j'ai toujours un bouclage sur la page de login avec un retour
sur une page blanche (et dans le cache, spip_login.ec6a47f2 est à 0
octect)
Les fichiers du cache ne sont-ils pas gzipés ?
Avec les dernières modifs de cette nuit (5h54) (que j'ai dans
mes_options.php3 $GLOBALS['compresser_cache'] = false; ou non) les fichiers
sont tous de taille 0.
Je suis sous easyphp 1.7 sous W2000 avec php 4.3.8.
L'extension php_zip est activée.
J'ai fait l'expérience de refaire une installation complète. Là, ça passe :
j'arrive dans ecrire/ et j'ai même pu naviguer dedans.
Par contre, je suis allé voir les fichiers du cache : ils sont eux aussi
tous à taille 0 (zéro).
Selon Fil (mercredi 25 ao�t 2004, 23h58 (+0200)) :
- gros travail sur le debuggueur : les boutons de debug s'affichent
maintenant dès qu'une erreur php a été détéctée dans l'exécution de la
page, les erreurs 'parse error' ou 'fatal error' sont traitées (ce qui
n'a pas été facile...)
Par rapport à mon problème de diff qui déconne avec des trop gros
paragraphes (ou avec un paragraphe qui se repete à fond, voir le
testdiff.php posté ici-même hier) :
- comme on voit les fatal error, ca affiche maintenant :
Fatal error: Allowed memory size of 8388608 bytes exhausted (tried to
allocate 35 bytes) in /var/www/spip/doc/ecrire/inc_diff.php3 on line 65
- j'ai pris le diff.php de spip-lab (qui semblait tourner via le
testdiff.php que j'ai posté hier) et l'ai adapté en inc_diff.php3
(s/include_spip/include_ecrire/) mais ça me donne la même erreur.
Le code de inc_diff.php3 est un peu trop complexe pour que j'ai le temps
d'y plonger...
c'était en fait normal, car le mode compressé n'était pas activé par défaut
(j'ai changé ça histoire de bien tester partout)
Avec les dernières modifs de cette nuit (5h54) (que j'ai dans
mes_options.php3 $GLOBALS['compresser_cache'] = false; ou non) les fichiers
sont tous de taille 0.
Attention les fichiers .NEW sont toujours de taille 0, ils ne sont là que
comme des drapeaux. Les autres, par contre, ne doivent pas être vides.
Pour voir ce qui se passe essaie de décommenter les spip_log() [et d'en
ajouter au besoin pour visualiser les paramètres] dans la fonction
ecrire_fichier() de ecrire/inc_version.php3
PS: le mail qui part vers ton adresse boutinesque m'est systématiquement
renvoyé en erreur : refuser les mails, c'est une technique favorisant
l'isolement ?
Désolé si ma remarque est comme un cheveu sur la soupe, j'ai fort peu de
temps disponible en ce moment et je lis vos messages un peu en
diagonale, je me pose juste la question de la durée de vie des grosses
modifs en question compte tenu que ça représente beaucoup d'énergie, et
quitte à entreprendre de tels travaux... mais je suis prêt à entendre
que je suis à côté de la plaque
c'était en fait normal, car le mode compressé n'était pas activé par
défaut (j'ai changé ça histoire de bien tester partout)
Avec les dernières modifs de cette nuit (5h54) (que j'ai dans
mes_options.php3 $GLOBALS['compresser_cache'] = false; ou non) les
fichiers sont tous de taille 0.
Attention les fichiers .NEW sont toujours de taille 0, ils ne sont là
que comme des drapeaux. Les autres, par contre, ne doivent pas être
vides.
Pour voir ce qui se passe essaie de décommenter les spip_log() [et
d'en ajouter au besoin pour visualiser les paramètres] dans la
fonction ecrire_fichier() de ecrire/inc_version.php3
Bon, après pas mal de tatonnements, la lecture de la doc de fopen et rename,
j'en suis arrivé à ceci :
--- D:\wwwrootDev\spip.net\spip\ecrire\inc_version.php3 Thu Aug 26 06:43:27
2004 UTC
+++ D:\wwwrootDev\spip.net\testspipcvs\ecrire\inc_version.php3 Thu Aug 26
16:30:19 2004 UTC
@@ -908,7 +908,6 @@
//
// zippe les fichiers .gz
function ecrire_fichier ($fichier, $contenu) {
Par rapport à mon problème de diff qui déconne avec des trop gros
paragraphes (ou avec un paragraphe qui se repete à fond, voir le
testdiff.php posté ici-même hier) :
- comme on voit les fatal error, ca affiche maintenant :
Fatal error: Allowed memory size of 8388608 bytes exhausted (tried to
allocate 35 bytes) in /var/www/spip/doc/ecrire/inc_diff.php3 on line 65
Mmmh, bon, l'exemple que tu utilises est en fait un cas pathologique :
phrase très longue sans ponctuation contenant toujours les mêmes mots,
du coup la combinatoire de l'algorithme de diff explose un peu...
Je vais envoyer un palliatif sur spip-lab, qui rend beaucoup plus
raisonnable la quantité de mémoire utilisée dans ces cas extrêmes, en
espérant que cela ne ralentit pas trop le fonctionnement courant.
Selon Antoine (vendredi 27 ao�t 2004, 01h19 (+0200)) :
> Par rapport à mon problème de diff qui déconne avec des trop gros
> paragraphes (ou avec un paragraphe qui se repete à fond, voir le
> testdiff.php posté ici-même hier) (...)
Mmmh, bon, l'exemple que tu utilises est en fait un cas pathologique :
phrase très longue sans ponctuation contenant toujours les mêmes mots,
du coup la combinatoire de l'algorithme de diff explose un peu...
Je vais envoyer un palliatif sur spip-lab, qui rend beaucoup plus
raisonnable la quantité de mémoire utilisée dans ces cas extrêmes, en
espérant que cela ne ralentit pas trop le fonctionnement courant.
Mon cas pathologique ne pose plus de soucis sur la version CVS lorsque
j'y remplace le inc_diff.php3 par celui de spip-lab... donc tu as gagné.
Coté rapidité je n'ai pas d'outils pour mesurer précisément...
