Suite à une mise à jour de 2.0.8g vers 2.1.2 [16017], nous constatons des erreurs dans le calcul des URLs des rubriques principales de notre site. L'ennui c'est que cela se passe de manière intermittente.
Suite à une mise à jour de 2.0.8g vers 2.1.2 [16017], nous constatons des erreurs dans le calcul des URLs des rubriques principales de notre site. L'ennui c'est que cela se passe de manière intermittente.
...
Spip est installé sur notre serveur dans un répertoire "spip" et répond à l'adresse http://domaine.tld/spip/
Je confirme ce bug que je vois passer par intermittence sur certains de mes sites depuis la 2.0 sans arriver à délimiter un scénario qui permette de le rejouer à coup sûr. Toutefois, j'ai observé la séquence suivante dans les logs:
1. un squelette S produit une page P à partir de l'espace privé (==> les URL élimine un niveau de répertoire pour être à la racine du site)
2. une page P2 demandée de l'espace privé repose sur l'inclusion du squelette S, et en l'occurrence estime que P, présent dans le cache, est ce qu'il lui faut, et on se retrouve avec les URL mal calculées.
En l'occurrence, le squelette S est un menu qui est inclus dans presque tous les autres squelettes, en particulier le 404. Un scénario plausible est donc qu'une demande d'un squelette inconnu dans l'espace privé provoque un appel au squelette 404, qui produit alors la page P et la prochaine page publique demandée va inclure ça. Mais je n'ai pas vu dans les quelques logs contemporains d'une manifestation du bug suffisamment de détails pour conforter cette hypothèse.
Dernier point: un scénario qui reproduisait assez souvent le bug utilisait le lien "voir en ligne" qui envoie vers l'espace privé avant de renvoyer vers l'espace public. Enfin, le bug apparaissait plus souvent avec Safari qu'avec Firefox.
C'est tout ce que j'ai pu recueillir comme information sur un bug qui est pour moi une arlésienne depuis au moins 2 ans. Donne le maximum de détails voir ce qu'on a en commun comme observation.
J'ai ce meme genre d'erreurs (dossier de premier niveau qui degage) sur des sites spip. Mais aussi sur des sites statiques... Ca ne viendrait pas plutôt d'apache ? ou de leur config chez OVH ?
Je confirme ce bug que je vois passer par intermittence sur certains de mes sites depuis la 2.0 sans arriver à délimiter un scénario qui permette de le rejouer à coup sûr. Toutefois, j'ai observé la séquence suivante dans les logs:
[...]
En l'occurrence, le squelette S est un menu qui est inclus dans presque tous les autres squelettes, en particulier le 404.
Il s'agit pour moi aussi d'un squelette inclus (un menu qui s'affiche sur toutes les pages). Le tout sur une configuration de type LAMP (distribution Centos). Si nécessaire, je peux obtenir des détails sur la version de MySQL, Apache, PHP.
Un scénario plausible est donc qu'une demande d'un squelette inconnu dans l'espace privé provoque un appel au squelette 404, qui produit alors la page P et la prochaine page publique demandée va inclure ça. Mais je n'ai pas vu dans les quelques logs contemporains d'une manifestation du bug suffisamment de détails pour conforter cette hypothèse.
Dernier point: un scénario qui reproduisait assez souvent le bug utilisait le lien "voir en ligne" qui envoie vers l'espace privé avant de renvoyer vers l'espace public. Enfin, le bug apparaissait plus souvent avec Safari qu'avec Firefox.
J'ai constaté le problème avec firefox 3.6.x. Je ne suis pas sûr de reproduire le lien de causalité avec le bouton "voir en ligne".
Je vous tiendrai informé si nous mettons le doigt sur quelque chose. Merci.
Salut je confirme le même problème lors d'utilisation de sous répertoire. Les urls calculées pointent vers la racine et non vers le ss rep. J'ai déjà plus de 10000 page 404. Ca doit faire des heureux
Ca doit faire des heureux 