Hello,
Sous 2.1 svn 14465, je n'obtiens rien de cette page, sinon le contenu effectif, mais pas l'interface de débug attendue (ça fonctionne en 2.0.9) :
spip.php?page=porte_plume.js&lang=fr&var_mode=debug
Si je remplace «porte_plume.js» par «article», le debug s'affiche bien.
Le changement de langue étant bien pris en compte si je mets spip.php?page=porte_plume.js&lang=en&var_mode=debug, je ne pense pas que ça vienne d'un changement sur l'interprétation des urls.
Quelqu'un reproduit ?
ceci n'est pas un squelette, le debusqueur n'a donc rien à en dire.
Committo,Ergo:Sum
page=truc amène toujours à truc.html
donc c'est *forcément* un squelette.
ici "porte_plume.js.html"
Je me suis mal exprimé: il y a certaines situations où l'appel au débusqueur semble inopportun à SPIP.
Je ne sais plus trop les critères pour ça, ça peut éventuellement se changer, mais ce n'est pas nécessairement un bug.
Committo,Ergo:Sum
Je me suis mal exprimé: il y a certaines situations où l'appel au débusqueur
semble inopportun à SPIP.
à part la page de login, qui pose un problème spécifique, c'est la
première fois que j'entends parler de ça (et des sentiments de SPIP)
Je ne sais plus trop les critères pour ça
mais en effet quelque chose a changé, puisque je ne peux plus
débugguer non plus mon squelette crayons.js.html en 2.1 (en 2.0 ça
marche, j'ai vérifié)
reste à trouver pourquoi SPIP est confus
-- Fil
reste à trouver pourquoi SPIP est confus
C'est http://trac.rezo.net/trac/spip/changeset/14404 qui faisait une
confusion entre $affiche_boutons_admin (faux dans le cas des fichiers
js, css etc) et l'autorisation de debugguer;
logique corrigée en [14468], mais tout de même à vérifier dans tous
les cas possibles (erreur squelette en étant connecté ou pas,
var_mode=debug connecte ou pas, etc)
-- Fil
Je fais souvent des confusions, mais pour le coup ça n'en était pas une:
je souhaite que les pages de debug aient une belle apparence graphique,
ce qui exclut son utilisation par les scripts qui ne passent pas proprement par public.php,
autrement dit qui commencent à envoyer leur CSS etc avant que SPIP ait eu le temps de dire ouf.
Dans certains cas d'ailleurs, l'appeler quand même ne servait pas à grand chose car il s'affichait
à l'intérieur d'une div de taille ridicule avec overflow hidden et autre joyeusetés.
Si c'est pour rendre un service aussi minable, je trouve préférable de dire clairement:
vous n'utilisez pas SPIP de manière conventionnelle, ses outils de mise au point ne sont donc pas opérationnels.
Bon, actuellement les page de debug n'ont pas un aspect graphique follement sexy, je ne vais pas réclamer un retour à l'état antérieur, mais le pb se reposera tôt ou tard.
Committo,Ergo:Sum
* Committo,Ergo:sum tapuscrivait, le 05/09/2009 13:40:
reste à trouver pourquoi SPIP est confus
C'est http://trac.rezo.net/trac/spip/changeset/14404 qui faisait une
confusion entre $affiche_boutons_admin (faux dans le cas des fichiers
js, css etc) et l'autorisation de debugguer;Je fais souvent des confusions, mais pour le coup ça n'en était pas une:
je souhaite que les pages de debug aient une belle apparence graphique,
ce qui exclut son utilisation par les scripts qui ne passent pas proprement par public.php,
autrement dit qui commencent à envoyer leur CSS etc avant que SPIP ait eu le temps de dire ouf.
Dans certains cas d'ailleurs, l'appeler quand même ne servait pas à grand chose car il s'affichait
à l'intérieur d'une div de taille ridicule avec overflow hidden et autre joyeusetés.
Si c'est pour rendre un service aussi minable, je trouve préférable de dire clairement:
vous n'utilisez pas SPIP de manière conventionnelle, ses outils de mise au point ne sont donc pas opérationnels.Bon, actuellement les page de debug n'ont pas un aspect graphique follement sexy, je ne vais pas réclamer un retour à l'état antérieur, mais le pb se reposera tôt ou tard.
Actuellement, les pages de debug ont un styllage (auquel j'ai participé) dont l'objectif était de simuler des frames.
Mais ça n'en a pas le comportement au clic.
En effet, je scrolle dans la partie du haut, je clique sur une des options (boucle, résultat...) et j'arrive sur une nouvelle page sur laquelle je dois de nouveau scroller pour arriver à l'endroit que je viens de quitter dans la partie haute.
C'est très peu pratique.
Est-ce qu'éclater cette page de débug en 2 frames pourrait être envisageable (avec un choix de séparation verticale ou horizontale : dans mon cas, avoir une séparation verticale serait plus pratique puisque je travaille avec une résolution de 1920 de large !).
reste à trouver pourquoi SPIP est confus
C'est http://trac.rezo.net/trac/spip/changeset/14404 qui faisait une
confusion entre $affiche_boutons_admin (faux dans le cas des fichiers
js, css etc) et l'autorisation de debugguer;Je fais souvent des confusions, mais pour le coup ça n'en était pas une:
je souhaite que les pages de debug aient une belle apparence graphique,
Le mieux est encore que le debug envoie sa propre css quand il est sollicité.
On se moque assez eperdument que ce ne soit pas xhtml valide dans ce cas.
Cela supposera par contre que la css soit suffisament bien pensée pour ne pas se faire polluer par les css environnantes.
ce qui exclut son utilisation par les scripts qui ne passent pas proprement par public.php,
autrement dit qui commencent à envoyer leur CSS etc avant que SPIP ait eu le temps de dire ouf.
Dans certains cas d'ailleurs, l'appeler quand même ne servait pas à grand chose car il s'affichait
à l'intérieur d'une div de taille ridicule avec overflow hidden et autre joyeusetés.
Si c'est pour rendre un service aussi minable, je trouve préférable de dire clairement:
vous n'utilisez pas SPIP de manière conventionnelle, ses outils de mise au point ne sont donc pas opérationnels.
Je trouve que c'est un peu abuser que de refuser le debug aussi généralement
Au pretexte qu'il sera parfois inutilisable sur des cas tordus, on se prive d'un outil dans plein de cas ou il est fort utile.
Par ailleurs les squelettes calculés qui renvoie autre chose que du html sont légions, y compris dans le core, et considérer que ce n'est pas une utilisation conventionnelle de SPIP me parait vraiment un point de vue peu défendable.
Cédric
Je propose que désormais on adapte SPIP à tes besoins alors...
* cedric.morin@yterium.com tapuscrivait, le 05/09/2009 15:41:
dans mon cas, avoir une séparation verticale serait plus pratique puisque je travaille avec une résolution de 1920 de large
Je propose que désormais on adapte SPIP à tes besoins alors...
C'est si gentiment proposé, merci 
PS : je parlais bien sûr de la page var_mode=debug et pas des informations de debug affichée sur une page du site public.
* RealET tapuscrivait, le 05/09/2009 15:48:
* cedric.morin@yterium.com tapuscrivait, le 05/09/2009 15:41:
dans mon cas, avoir une séparation verticale serait plus pratique puisque je travaille avec une résolution de 1920 de large
Je propose que désormais on adapte SPIP à tes besoins alors...
C'est si gentiment proposé, merci
PS : je parlais bien sûr de la page var_mode=debug et pas des informations de debug affichée sur une page du site public.
D'ailleurs, plus sérieusement, est-ce que mon idée de frames est pertinente ?
Si oui, j'ai bien envie d'essayer de l'implémenter...
Actuellement, les pages de debug ont un styllage (auquel j'ai participé)
Ah, c'est toi le coupable
Est-ce qu'éclater cette page de débug en 2 frames pourrait être envisageable
Le débusqueur est à présent surchargeable, donc chacun peut développer ce qu'il veut comme interface graphique sous forme d'un plugin. A la limite, on pourrait le retirer de la distribution standard dès à présent. Il y a encore qq trucs d'interface qui me chiffonnent, mais au moins les appels à erreur_squelette sont stabilisés.
Committo,Ergo:Sum
Le mieux est encore que le debug envoie sa propre css quand il est sollicité.
Mais enfin il le fait depuis longtemps, la question n'est pas là !
On se moque assez eperdument que ce ne soit pas xhtml valide dans ce cas.
Ni là !
Je trouve que c'est un peu abuser que de refuser le debug aussi généralement
Au pretexte qu'il sera parfois inutilisable sur des cas tordus, on se prive d'un outil dans plein de cas ou il est fort utile.
Par ailleurs les squelettes calculés qui renvoie autre chose que du html sont légions, y compris dans le core, et considérer que ce n'est pas une utilisation conventionnelle de SPIP me parait vraiment un point de vue peu défendable.
C'est excessif sans doute, mais il y a vraiment des abominations graphiques qui font honte.
Je crois qu'on va régler le pb autrement: puisque le débusqueur est à présent surchargeable, on va déplacer le test d'utilisabilité dans le débusqueur lui-même, chacun pourra choisir son compromis laideur/nécessité, et essayer de réduire la première en l'améliorant.
Committo,Ergo:Sum
rien compris !
les deux page=... dont nous avons parlé passent par le flux normal de
SPIP. Je ne vois pas en quoi l'utilisation de la balise officielle
#HTTP_HEADER{Content-Type: ...} devrait nous exclure du
var_mode=debug.
-- Fil
* Committo,Ergo:sum tapuscrivait, le 05/09/2009 15:57:
Actuellement, les pages de debug ont un styllage (auquel j'ai participé)
Ah, c'est toi le coupable
Est-ce qu'éclater cette page de débug en 2 frames pourrait être envisageable
Le débusqueur est à présent surchargeable, donc chacun peut développer ce qu'il veut comme interface graphique sous forme d'un plugin. A la limite, on pourrait le retirer de la distribution standard dès à présent. Il y a encore qq trucs d'interface qui me chiffonnent, mais au moins les appels à erreur_squelette sont stabilisés.
Ouh là.
En l'état, j'ai regardé http://trac.rezo.net/trac/spip/browser/spip/ecrire/public/debusquer.php#L397 et de ce que j'en vois, il y a une seule fonction qui produit pour spip.php?article1&var_mode=debug :
- et la zone du haut qui permet de choisir le type d'affichage de la zone du bas
- et la zone du bas
Donc, éclater ça en 3 (la page chargeant les 2 frames) et les 2 frames va être un peu chaud, non ?
Surtout que la partie du haut gère 2 cas au moins : debug ou validation
Ah oui, il y en a qui l'utilisent pour mettre le Content-Type que SPIP met de toutes façons par défaut.
Bon ok, je vais améliorer ça.
Committo,Ergo:Sum
les deux page=... dont nous avons parlé passent par le flux normal de
SPIP. Je ne vois pas en quoi l'utilisation de la balise officielle
#HTTP_HEADER{Content-Type: ...} devrait nous exclure du
var_mode=debug.Ah oui, il y en a qui l'utilisent pour mettre le Content-Type que SPIP met
de toutes façons par défaut.
Euh franchement, les dialogues de sourds, pffff, hein...
SPIP ne met pas et n'a jamais mis le content-type text/javascript ou
text/css par défaut. Il met par défaut text/html, sauf si on l'indique
explicitement (et c'est très bien comme ça).
-- Fil
En effet c'est un dialogue de sourds, je n'ai jamais dit ça.
Committo,Ergo:Sum
En effet c'est un dialogue de sourds, je n'ai jamais dit ça.
non, de fait tu as écrit :
Ah oui, il y en a qui l'utilisent pour mettre le Content-Type que SPIP met
de toutes façons par défaut.
-- Fil, inquiet