Bonjour,
Je constate que SPIP 2.0.8 SVN [14286] (pas testé sur d'autres) renvoie une erreur 404 quand le contenu retourné par le squelette est vide.
Je ne trouve pas cela correct, une page vide étant bien différente d'une page non trouvée.
Qu'en dites-vous ?
-Nicolas
* Nicolas Hoizey tapuscrivait, le 27/07/2009 16:08:
Bonjour,
Je constate que SPIP 2.0.8 SVN [14286] (pas testé sur d'autres) renvoie une erreur 404 quand le contenu retourné par le squelette est vide.
Ça fait longtemps que SPIP se comporte comme ça.
Je ne trouve pas cela correct, une page vide étant bien différente d'une page non trouvée.
Tu peux très bien utiliser <//B_> pour spécifier ce qui doit être affiché si la page est "vide"...
* Nicolas Hoizey tapuscrivait, le 27/07/2009 16:08:
Bonjour,
Je constate que SPIP 2.0.8 SVN [14286] (pas testé sur d'autres) renvoie une erreur 404 quand le contenu retourné par le squelette est vide.Ça fait longtemps que SPIP se comporte comme ça.
OK, j'avais jamais vu.
Je ne trouve pas cela correct, une page vide étant bien différente d'une page non trouvée.
Tu peux très bien utiliser <//B_> pour spécifier ce qui doit être affiché si la page est "vide"...
Et si mon squelette ne contient qu'une balise et aucune boucle ?
-Nicolas
* Nicolas Hoizey tapuscrivait, le 27/07/2009 16:28:
peut-être :
[(#MABALISE|non)<p>Mabalise est vide</p>]
pierre
Mouais, mais du coup pas moyen d'avoir un contenu vide, ce qui ne me semble pas correct.
Une erreur "204: No Content" serait plus explicite, parce que là j'ai cherché partout pourquoi j'avais une 404 alors que mon squelette existait bien et était bien pris en compte par SPIP...
-Nicolas
Non mais c'est quoi ton problème réel ?
Une page html vide que tu veux présenter au visiteur, c'est un cas absurde.
Une page vide que tu veux renvoyer à un script ajax, ça se comprend.
Dans ce cas, il suffit de spécifier le #HTTP_HEADER avec le content-type pour que SPIP ne produise pas une 404 toute propre et te laisse une page blanche.
Cédric
Non mais c'est quoi ton problème réel ?
Que j'ai cherché pendant un certains temps pourquoi j'avais une erreur 404, donc un contenu non trouvé, alors que c'est tout simplement que ma balise renvoyait un contenu vide, faute d'avoir activé le plugin.
C'est le plugin "langue_preferee" qui a pour mode d'action de mettre dans le squelette sommaire.html uniquement la balise #LANGUE_PREFEREE_SECTEUR_REDIRECTION, donc si le plugin n'est pas activé, le sommaire donne une erreur 404. Pas intuitif.
Je vais ajouter dans la doc la suggestion de mettre plutôt [(#LANGUE_PREFEREE_SECTEUR_REDIRECTION|sinon{activer le plugin langue_preferee})], mais bon... il y a une nuance à mon avis importante entre "contenu non trouvé" et "contenu vide".
Une page html vide que tu veux présenter au visiteur, c'est un cas absurde.
Il n'y a pas que les humains qui récupèrent des pages Web.
Une page vide que tu veux renvoyer à un script ajax, ça se comprend.
Par exemple.
Dans ce cas, il suffit de spécifier le #HTTP_HEADER avec le content-type pour que SPIP ne produise pas une 404 toute propre et te laisse une page blanche.
Ca marcherait avec un "Content-type: text/html" pour de l'AJAH ?
-Nicolas
Non mais c'est quoi ton problème réel ?
Que j'ai cherché pendant un certains temps pourquoi j'avais une erreur 404, donc un contenu non trouvé, alors que c'est tout simplement que ma balise renvoyait un contenu vide, faute d'avoir activé le plugin.
C'est le plugin "langue_preferee" qui a pour mode d'action de mettre dans le squelette sommaire.html uniquement la balise #LANGUE_PREFEREE_SECTEUR_REDIRECTION, donc si le plugin n'est pas activé, le sommaire donne une erreur 404. Pas intuitif.
Heu, une page blanche serait plus intuitive ?...
J'ai du mal à le croire.
Plus sérieusement, de toute évidence, ton plugin fonctionne mal car il oblige à massacrer le squelette sommaire.html et sa simple désactivation casse tout le site ...
Il faut que tu procède autrement. S'il s'agit d'une simple redirection, alors je vois pas pourquoi tu obliges à faire cela, plutot que, au choix :
- prendre la main dans mes_options et rediriger quand on demande la page=sommaire
- te brancher sur le pipeline styliser, et reorienter sur le bon squelette quand on demande la page sommaire.
Je vais ajouter dans la doc la suggestion de mettre plutôt [(#LANGUE_PREFEREE_SECTEUR_REDIRECTION|sinon{activer le plugin langue_preferee})], mais bon... il y a une nuance à mon avis importante entre "contenu non trouvé" et "contenu vide".
Donc, tu préfèrerai que ce squelette envoi une page blanche ?
Une page html vide que tu veux présenter au visiteur, c'est un cas absurde.
Il n'y a pas que les humains qui récupèrent des pages Web.
Une page vide que tu veux renvoyer à un script ajax, ça se comprend.
Par exemple.
Dans ce cas, il suffit de spécifier le #HTTP_HEADER avec le content-type pour que SPIP ne produise pas une 404 toute propre et te laisse une page blanche.
Ca marcherait avec un "Content-type: text/html" pour de l'AJAH ?
Oui
Cédric
S'lt
Une page html vide que tu veux présenter au visiteur, c'est un cas absurde.
Le cas est peut être absurde mais rien ne l'interdit, un créateur de
squelettes peut vouloir retourner une page au contenu vide.
Je ne crois pas que SPIP est en droit de deformer ce resultat en
erreur 404. Sur le coup je suis d'accord avec NH bien qu'on peut
trouver ce souhait bizarre et absurde.
Heu, une page blanche serait plus intuitive ?...
La page blanche sera plus intuitive du moins pour le créateur, son
squelette existe bien mais ne fait rien. Pas pareil qu'un 404 car la
page n'existe pas. On peut retorquer que c'est une erreur de
conception mais on ne peut pas dire que ce soit faux.
Km
Non mais c'est quoi ton problème réel ?
Que j'ai cherché pendant un certains temps pourquoi j'avais une erreur 404, donc un contenu non trouvé, alors que c'est tout simplement que ma balise renvoyait un contenu vide, faute d'avoir activé le plugin.
C'est le plugin "langue_preferee" qui a pour mode d'action de mettre dans le squelette sommaire.html uniquement la balise #LANGUE_PREFEREE_SECTEUR_REDIRECTION, donc si le plugin n'est pas activé, le sommaire donne une erreur 404. Pas intuitif.
Heu, une page blanche serait plus intuitive ?...
J'ai du mal à le croire.
Et pourtant.
Plus sérieusement, de toute évidence, ton plugin fonctionne mal car il oblige à massacrer le squelette sommaire.html et sa simple désactivation casse tout le site ...
Ce n'est pas du tout une obligation, juste une possibilité, qui facilite grandement la mise en place du système d'orientation automatique vers la bonne langue (ou la plus probablement bonne), et ainsi éviter les pages d'accueil multilingues incompréhensibles.
Il faut que tu procède autrement. S'il s'agit d'une simple redirection, alors je vois pas pourquoi tu obliges à faire cela, plutot que, au choix :
- prendre la main dans mes_options et rediriger quand on demande la page=sommaire
Qu'appelles-tu « prendre la main dans mes_options » ? C'est un pipeline ?
- te brancher sur le pipeline styliser, et reorienter sur le bon squelette quand on demande la page sommaire.
Dans les deux cas que tu cites, en quoi serait-ce moins « obligatoire » que ma proposition, si ce n'est pas mis volontairement par l'utilisateur, mais imposé par le plugin ?
Je vais ajouter dans la doc la suggestion de mettre plutôt [(#LANGUE_PREFEREE_SECTEUR_REDIRECTION|sinon{activer le plugin langue_preferee})], mais bon... il y a une nuance à mon avis importante entre "contenu non trouvé" et "contenu vide".
Donc, tu préfèrerai que ce squelette envoi une page blanche ?
Oui.
Une page html vide que tu veux présenter au visiteur, c'est un cas absurde.
Il n'y a pas que les humains qui récupèrent des pages Web.
Une page vide que tu veux renvoyer à un script ajax, ça se comprend.
Par exemple.
Dans ce cas, il suffit de spécifier le #HTTP_HEADER avec le content-type pour que SPIP ne produise pas une 404 toute propre et te laisse une page blanche.
Ca marcherait avec un "Content-type: text/html" pour de l'AJAH ?
Oui
OK.
-Nicolas
Cédric te parle de l'obligation de modifier tes squelettes. Avec le pipeline styliser tu n'as PAS à forcer l'utilisateur à modifier ses squelettes. Donc que le plugin soit là ou pas, rien ne plante. Alors que ta méthode d'obliger l'utilisateur à modifier son squelette en fonction de ton plugin fait que lorsqu'il n'est plus là, ça merde.
Dans les deux cas que tu cites, en quoi serait-ce moins « obligatoire »
que ma proposition, si ce n'est pas mis volontairement par
l'utilisateur, mais imposé par le plugin ?Cédric te parle de l'obligation de modifier tes squelettes. Avec le pipeline styliser tu n'as PAS à forcer l'utilisateur à modifier ses squelettes.
Oui, mais si je mets en route le pipeline, je ne laisse plus le choix. Je le répète, ma balise n'est PAS obligatoire pour l'utilisation du plugin, c'est juste une aide proposée à l'utilisateur.
Donc que le plugin soit là ou pas, rien ne plante. Alors que ta méthode d'obliger l'utilisateur à modifier son squelette en fonction de ton plugin fait que lorsqu'il n'est plus là, ça merde.
Bon, je regarderais ce pipeline.
Mais le fond de la question n'est pas là, c'est un peu facile de m'accuser de coder comme un sagouin quand je signale ce que je pense être un bug de SPIP.
-Nicolas
Oui, mais si je mets en route le pipeline, je ne laisse plus le choix.
Je le répète, ma balise n'est PAS obligatoire pour l'utilisation du
plugin, c'est juste une aide proposée à l'utilisateur.
Ben si, puisqu'avec le pipeline, tu peux alors faire une config activer/désactiver ton aide directement dans l'espace privé, sans modifier de fichiers. Par exemple en allant tester une valeur de CFG durant le pipeline.
Mais le fond de la question n'est pas là, c'est un peu facile de
m'accuser de coder comme un sagouin quand je signale ce que je pense
être un bug de SPIP.
Ah moi je ne t'accuse de rien, je suis même d'accord avec le fait que c'est un faux résultat de renvoyer obligatoirement une 404 lorsque c'est vide.
Mais bon on s'en fiche un peu puisque c'est un cas super rare et lorsqu'on le rencontre, il y a toujours moyen de forcer les entêtes HTTP pour retourner ce qu'on veut. Donc je trouve acceptable la solution de SPIP qui gère le cas le plus courant afin que la majorité des utilisateurs n'aient pas à se poser de questions.
Dans les deux cas que tu cites, en quoi serait-ce moins « obligatoire »
que ma proposition, si ce n'est pas mis volontairement par
l'utilisateur, mais imposé par le plugin ?Cédric te parle de l'obligation de modifier tes squelettes. Avec le pipeline styliser tu n'as PAS à forcer l'utilisateur à modifier ses squelettes.
Oui, mais si je mets en route le pipeline, je ne laisse plus le choix. Je le répète, ma balise n'est PAS obligatoire pour l'utilisation du plugin, c'est juste une aide proposée à l'utilisateur.
Ben si, rien ne t'empeche que cette option soit configurable, et de tester si elle est active ou pas avant de rediriger
Donc que le plugin soit là ou pas, rien ne plante. Alors que ta méthode d'obliger l'utilisateur à modifier son squelette en fonction de ton plugin fait que lorsqu'il n'est plus là, ça merde.
Bon, je regarderais ce pipeline.
Mais le fond de la question n'est pas là, c'est un peu facile de m'accuser de coder comme un sagouin quand je signale ce que je pense être un bug de SPIP.
Ca n'est pas un bug , mais une fonctionnalité.
Pour résumer et clore le sujet :
- par défaut, une page vide provoque une 404, ce qui correspond à 98% des besoins
- il est possible de sortir de ce cas en envoyant un HTTP_HEADER, y compris text/html
Cédric
Oui, mais si je mets en route le pipeline, je ne laisse plus le choix.
Je le répète, ma balise n'est PAS obligatoire pour l'utilisation du
plugin, c'est juste une aide proposée à l'utilisateur.Ben si, puisqu'avec le pipeline, tu peux alors faire une config activer/désactiver ton aide directement dans l'espace privé, sans modifier de fichiers. Par exemple en allant tester une valeur de CFG durant le pipeline.
Oui, pas bête, mais j'avoue qu'ajouter des dépendances avec CFG alors qu'il bouge beaucoup, c'est pas ma tasse de thé. Mais la solution de l'activation configurable reste intéressante, je creuserais.
Mais le fond de la question n'est pas là, c'est un peu facile de
m'accuser de coder comme un sagouin quand je signale ce que je pense
être un bug de SPIP.Ah moi je ne t'accuse de rien, je suis même d'accord avec le fait que c'est un faux résultat de renvoyer obligatoirement une 404 lorsque c'est vide.
OK.
Mais bon on s'en fiche un peu puisque c'est un cas super rare et lorsqu'on le rencontre, il y a toujours moyen de forcer les entêtes HTTP pour retourner ce qu'on veut. Donc je trouve acceptable la solution de SPIP qui gère le cas le plus courant afin que la majorité des utilisateurs n'aient pas à se poser de questions.
Mais justement, quel webmestre ne se posera pas de question en voyant une erreur 404 s'il est sûr que son squelette est bien là ? Une 204 serait plus instructive, tant pour le webmestre que pour les visiteurs, à mon avis.
-Nicolas
Dans les deux cas que tu cites, en quoi serait-ce moins « obligatoire »
que ma proposition, si ce n'est pas mis volontairement par
l'utilisateur, mais imposé par le plugin ?Cédric te parle de l'obligation de modifier tes squelettes. Avec le pipeline styliser tu n'as PAS à forcer l'utilisateur à modifier ses squelettes.
Oui, mais si je mets en route le pipeline, je ne laisse plus le choix. Je le répète, ma balise n'est PAS obligatoire pour l'utilisation du plugin, c'est juste une aide proposée à l'utilisateur.
Ben si, rien ne t'empeche que cette option soit configurable, et de tester si elle est active ou pas avant de rediriger
OK, même réponse qu'à RastaPopoulos, c'est intéressant, je regarderais.
Pour tout dire, le code actuel est une pluginisation assez brutale de la librairie phpLang que j'avais codée en 1998, donc il y a forcément matière à amélioration... 
Donc que le plugin soit là ou pas, rien ne plante. Alors que ta méthode d'obliger l'utilisateur à modifier son squelette en fonction de ton plugin fait que lorsqu'il n'est plus là, ça merde.
Bon, je regarderais ce pipeline.
Mais le fond de la question n'est pas là, c'est un peu facile de m'accuser de coder comme un sagouin quand je signale ce que je pense être un bug de SPIP.
Ca n'est pas un bug , mais une fonctionnalité.
Hum...
Pour résumer et clore le sujet :
- par défaut, une page vide provoque une 404, ce qui correspond à 98% des besoins
Je ne suis pas convaincu, mais je ne vais pas me battre...
- il est possible de sortir de ce cas en envoyant un HTTP_HEADER, y compris text/html
OK.
-Nicolas
Pour résumer et clore le sujet :
- par défaut, une page vide provoque une 404, ce qui correspond à 98% des besoins
Je ne suis pas convaincu, mais je ne vais pas me battre…
La différence entre les codes d’erreur 204 et 404 est subtile
La 204 permet de renvoyer une page avec un éventuel changement des meta données associées mais dont le contenu vide, sans préciser si quelque chose existe ou non.
La 404 indique que l’url demandé n’existe pas.
Les 2 messages d’erreur traite donc de 2 notion distinctes.
Sur une page (url,squelette) classique de SPIP le contenu correspond au résultat d’un boucle principale qui peut avoir un argument dans l’url. Cette page est donc directement associé à un type d’objet SPIP (rubrique, article, auteur)…
Une page vide correspond donc dans ce cas à une instance d’objet inexistante donc plutôt en accord avec la notion exprimée par une erreur 404.
Les possibilités nouvelles de SPIP permettant de faire des squelettes qui s’éloignent de cette notion de page=contenu amènent des cas où un 204 serait plus approprié, car simplement lié à un contenu que l’on veut garder vide avec un vide qui a un sens (vide <> null).
Ceci étant dit, je ne suis ni pour ni contre bien au contraire !
Le principal étant que le comportement soit clairement défini pour éviter des changements involontaires en cours d’évolution de notre sciuridé. A chacun d’adapter ensuite son code en fonction de ça.
a+
Personnellement, d'après mon avis, quand j'ai testé pour la première fois les squelettes de SPIP j'ai pensé que ça ne marchait pas car j'avais juste crée une simple page HTML vide (squelettes/sommaire.html) et SPIP m'a retourné une 404. Je pense que c'est plutôt illogique de renvoyer une 404 pour une page blanche, on a bien le droit de mettre des pages blanches sur nos sites sans avoir besoin de mettre du code SPIP dedans ?
C'est juste mon avis.
Mais TU PEUX.
Seulement comme ça correspond à un cas extrêmement rare, ce n'est pas le comportement par défaut.
C'est si difficile à comprendre que ça le fait que SPIP facilite avant tout l'utilisation de la majorité ?
Surtout qu'il ne pénalise pas les 2% restant puisqu'on peut modifier le comportement par défaut. Alors il n'y a aucun problème.