La commande
<a href="<?php echo '$HTTP_REFERER' ?>"> Retour</a>
est l'équivalent de
<a href="javascript:history.go(-1)">Retour</a>
mais j'ai lu quelque part (désolé, sais plus où ...) qu'elle n'était pas
fiable.
Est-ce vrai ? Mes essais avec EasyPHP me donnent systématiquement la
réponse :
"Firefox ne peut trouver le fichier à l'adresse /D:/Chantier PHP/<?php
echo '$HTTP_REFERER' ?>"
IL y est pourtant, au même niveau que la page appelante.
Existe-t'il une variante et, question subsidiaire, un équivalent à
<a href="javascript:history.go(-x)">Retour</a> ?
Cordialement,
--
docanski
- Les Côtes du nord de la Bretagne par le sentier des douaniers
- Memento des champignons : le guide le plus complet du Web
- Et d'autres sujets encore sur ----> http://armorance.free.fr
Enlève déjà les guillemets simples avant et après $HTTP_REFERER. -- Fredchou mailto:
Olivier Miakinen
La commande <a href="<?php echo '$HTTP_REFERER' ?>"> Retour</a> est l'équivalent de <a href="javascript:history.go(-1)">Retour</a>
Bof.
Cela suppose que : 1) HTTP_REFERER est transmis par le navigateur ; 2) register_globals est à On (mais sinon on peut utiliser les variables superglobales) ; 3) JavaScript est actif sur le navigateur ; 4) On arrive sur la page via un lien et pas, par exemple, via un autre history.go(-1), ni une URL saisie par l'utilisateur.
mais j'ai lu quelque part (désolé, sais plus où ...) qu'elle n'était pas fiable.
Cf. points 1, 2 et 4 ci-dessus.
Existe-t'il une variante et, question subsidiaire, un équivalent à <a href="javascript:history.go(-x)">Retour</a> ?
Tout navigateur qui se respecte offre un bouton Retour, voire la possibilité de revenir de plus d'un niveau dans l'historique (et même de repartir en avant quand on est revenu en arrière). Ceci est mille fois préférable à un lien généré en JavaScript, et dix mille fois préférable à un lien généré à partir du HTTP_REFERER.
Le plus que tu peux offrir en PHP, en revanche, c'est de fournir un lien vers la page qui est « logiquement » avant ou après la page en cours, indépendamment du parcours qu'a suivi l'utilisateur pour y arriver.
La commande
<a href="<?php echo '$HTTP_REFERER' ?>"> Retour</a>
est l'équivalent de
<a href="javascript:history.go(-1)">Retour</a>
Bof.
Cela suppose que :
1) HTTP_REFERER est transmis par le navigateur ;
2) register_globals est à On (mais sinon on peut utiliser les variables
superglobales) ;
3) JavaScript est actif sur le navigateur ;
4) On arrive sur la page via un lien et pas, par exemple, via un autre
history.go(-1), ni une URL saisie par l'utilisateur.
mais j'ai lu quelque part (désolé, sais plus où ...) qu'elle n'était pas
fiable.
Cf. points 1, 2 et 4 ci-dessus.
Existe-t'il une variante et, question subsidiaire, un équivalent à
<a href="javascript:history.go(-x)">Retour</a> ?
Tout navigateur qui se respecte offre un bouton Retour, voire la
possibilité de revenir de plus d'un niveau dans l'historique (et même
de repartir en avant quand on est revenu en arrière). Ceci est mille
fois préférable à un lien généré en JavaScript, et dix mille fois
préférable à un lien généré à partir du HTTP_REFERER.
Le plus que tu peux offrir en PHP, en revanche, c'est de fournir un lien
vers la page qui est « logiquement » avant ou après la page en cours,
indépendamment du parcours qu'a suivi l'utilisateur pour y arriver.
La commande <a href="<?php echo '$HTTP_REFERER' ?>"> Retour</a> est l'équivalent de <a href="javascript:history.go(-1)">Retour</a>
Bof.
Cela suppose que : 1) HTTP_REFERER est transmis par le navigateur ; 2) register_globals est à On (mais sinon on peut utiliser les variables superglobales) ; 3) JavaScript est actif sur le navigateur ; 4) On arrive sur la page via un lien et pas, par exemple, via un autre history.go(-1), ni une URL saisie par l'utilisateur.
mais j'ai lu quelque part (désolé, sais plus où ...) qu'elle n'était pas fiable.
Cf. points 1, 2 et 4 ci-dessus.
Existe-t'il une variante et, question subsidiaire, un équivalent à <a href="javascript:history.go(-x)">Retour</a> ?
Tout navigateur qui se respecte offre un bouton Retour, voire la possibilité de revenir de plus d'un niveau dans l'historique (et même de repartir en avant quand on est revenu en arrière). Ceci est mille fois préférable à un lien généré en JavaScript, et dix mille fois préférable à un lien généré à partir du HTTP_REFERER.
Le plus que tu peux offrir en PHP, en revanche, c'est de fournir un lien vers la page qui est « logiquement » avant ou après la page en cours, indépendamment du parcours qu'a suivi l'utilisateur pour y arriver.
Mihamina Rakotomandimby (R12y)
docanski wrote:
mais j'ai lu quelque part (désolé, sais plus où ...) qu'elle n'était pas fiable.
D'apres moi, elle n'est pas fiable dans la mesure ou HTTP_REFERRER est lié à HTTP.
Dans ton cas, tu navigue dans les fichiers en local et non au travers d'un serveur HTTP (l'URL est bien de la forme "file://" et non "http://"?)
Je ne pense pas que dans ces conditions HTTP_xxx soit renseigné.
docanski wrote:
mais j'ai lu quelque part (désolé, sais plus où ...) qu'elle n'était pas
fiable.
D'apres moi, elle n'est pas fiable dans la mesure ou HTTP_REFERRER est lié à
HTTP.
Dans ton cas, tu navigue dans les fichiers en local et non au travers d'un
serveur HTTP (l'URL est bien de la forme "file://" et non "http://"?)
Je ne pense pas que dans ces conditions HTTP_xxx soit renseigné.
Enlève déjà les guillemets simples avant et après $HTTP_REFERER.
Ah oui, aussi. Je n'avais même pas vu ça. ;-)
docanski
Alors que les eleveurs et agriculteurs polluent toujours la Bretagne, Olivier Miakinen nous narre ce qui suit en ce 21/05/2007 17:46 :
Cela suppose que : 1) HTTP_REFERER est transmis par le navigateur ; 2) register_globals est à On (mais sinon on peut utiliser les variables superglobales) ; 3) JavaScript est actif sur le navigateur ; 4) On arrive sur la page via un lien et pas, par exemple, via un autre history.go(-1), ni une URL saisie par l'utilisateur.
Oui dans 3 des points, le numéro 2 étant pour moi un inconnu.
Existe-t'il une variante et, question subsidiaire, un équivalent à <a href="javascript:history.go(-x)">Retour</a> ?
Tout navigateur qui se respecte offre un bouton Retour,
Oui mais le but est de pouvoir *aussi* utiliser ces pages en réseau et en plein écran (bornes d'informations à disposition du public), en éliminant donc toute possibilité d'utiliser les outils du navigateur, pour des raisons de sécurité.
Ceci est mille fois préférable à un lien généré en JavaScript,
C'est pourquoi je tente d'éliminer JS au profit de PHP.
et dix mille fois préférable à un lien généré à partir du HTTP_REFERER.
Ça c'est l'argument qui tue toute vellétié de poursuivre dans cette voie. La solution me paraissait pourtant universelle, du moins pour les navigateurs graphiques.
Le plus que tu peux offrir en PHP, en revanche, c'est de fournir un lien vers la page qui est « logiquement » avant ou après la page en cours, indépendamment du parcours qu'a suivi l'utilisateur pour y arriver.
C'est ce que je tente d'obtenir. Il y a donc un autre moyen ? Le recours à ce genre de commande est dicté par le fait que ces pages peuvent être appelées à partir de 5 menus différents + des liens internes existants dans d'autres pages. Une barre de navigation est ainsi, au moins pour cette dernière raison, impossible à envisager. Je suis donc preneur de toute autre solution mais n'avais trouvé que celle-là dans la doc.
Cordialement, -- docanski
- Les Côtes du nord de la Bretagne par le sentier des douaniers - Memento des champignons : le guide le plus complet du Web - Et d'autres sujets encore sur ----> http://armorance.free.fr
Alors que les eleveurs et agriculteurs polluent toujours la Bretagne,
Olivier Miakinen nous narre ce qui suit en ce 21/05/2007 17:46 :
Cela suppose que :
1) HTTP_REFERER est transmis par le navigateur ;
2) register_globals est à On (mais sinon on peut utiliser les variables
superglobales) ;
3) JavaScript est actif sur le navigateur ;
4) On arrive sur la page via un lien et pas, par exemple, via un autre
history.go(-1), ni une URL saisie par l'utilisateur.
Oui dans 3 des points, le numéro 2 étant pour moi un inconnu.
Existe-t'il une variante et, question subsidiaire, un équivalent à
<a href="javascript:history.go(-x)">Retour</a> ?
Tout navigateur qui se respecte offre un bouton Retour,
Oui mais le but est de pouvoir *aussi* utiliser ces pages en réseau et
en plein écran (bornes d'informations à disposition du public), en
éliminant donc toute possibilité d'utiliser les outils du navigateur,
pour des raisons de sécurité.
Ceci est mille
fois préférable à un lien généré en JavaScript,
C'est pourquoi je tente d'éliminer JS au profit de PHP.
et dix mille fois
préférable à un lien généré à partir du HTTP_REFERER.
Ça c'est l'argument qui tue toute vellétié de poursuivre dans cette voie.
La solution me paraissait pourtant universelle, du moins pour les
navigateurs graphiques.
Le plus que tu peux offrir en PHP, en revanche, c'est de fournir un lien
vers la page qui est « logiquement » avant ou après la page en cours,
indépendamment du parcours qu'a suivi l'utilisateur pour y arriver.
C'est ce que je tente d'obtenir. Il y a donc un autre moyen ? Le recours
à ce genre de commande est dicté par le fait que ces pages peuvent être
appelées à partir de 5 menus différents + des liens internes existants
dans d'autres pages. Une barre de navigation est ainsi, au moins pour
cette dernière raison, impossible à envisager.
Je suis donc preneur de toute autre solution mais n'avais trouvé que
celle-là dans la doc.
Cordialement,
--
docanski
- Les Côtes du nord de la Bretagne par le sentier des douaniers
- Memento des champignons : le guide le plus complet du Web
- Et d'autres sujets encore sur ----> http://armorance.free.fr
Alors que les eleveurs et agriculteurs polluent toujours la Bretagne, Olivier Miakinen nous narre ce qui suit en ce 21/05/2007 17:46 :
Cela suppose que : 1) HTTP_REFERER est transmis par le navigateur ; 2) register_globals est à On (mais sinon on peut utiliser les variables superglobales) ; 3) JavaScript est actif sur le navigateur ; 4) On arrive sur la page via un lien et pas, par exemple, via un autre history.go(-1), ni une URL saisie par l'utilisateur.
Oui dans 3 des points, le numéro 2 étant pour moi un inconnu.
Existe-t'il une variante et, question subsidiaire, un équivalent à <a href="javascript:history.go(-x)">Retour</a> ?
Tout navigateur qui se respecte offre un bouton Retour,
Oui mais le but est de pouvoir *aussi* utiliser ces pages en réseau et en plein écran (bornes d'informations à disposition du public), en éliminant donc toute possibilité d'utiliser les outils du navigateur, pour des raisons de sécurité.
Ceci est mille fois préférable à un lien généré en JavaScript,
C'est pourquoi je tente d'éliminer JS au profit de PHP.
et dix mille fois préférable à un lien généré à partir du HTTP_REFERER.
Ça c'est l'argument qui tue toute vellétié de poursuivre dans cette voie. La solution me paraissait pourtant universelle, du moins pour les navigateurs graphiques.
Le plus que tu peux offrir en PHP, en revanche, c'est de fournir un lien vers la page qui est « logiquement » avant ou après la page en cours, indépendamment du parcours qu'a suivi l'utilisateur pour y arriver.
C'est ce que je tente d'obtenir. Il y a donc un autre moyen ? Le recours à ce genre de commande est dicté par le fait que ces pages peuvent être appelées à partir de 5 menus différents + des liens internes existants dans d'autres pages. Une barre de navigation est ainsi, au moins pour cette dernière raison, impossible à envisager. Je suis donc preneur de toute autre solution mais n'avais trouvé que celle-là dans la doc.
Cordialement, -- docanski
- Les Côtes du nord de la Bretagne par le sentier des douaniers - Memento des champignons : le guide le plus complet du Web - Et d'autres sujets encore sur ----> http://armorance.free.fr
docanski
Alors que les eleveurs et agriculteurs polluent toujours la Bretagne, Fredchou nous narre ce qui suit en ce 21/05/2007 17:46 :
Enlève déjà les guillemets simples avant et après $HTTP_REFERER.
Ça n'y change rien. Ce qui est curieux, c'est que même ôtés, le passage du curseur sur le lien de retour affiche la commande *avec* ces guillemets simples dans la barre d'état.
Cordialement, -- docanski
- Les Côtes du nord de la Bretagne par le sentier des douaniers - Memento des champignons : le guide le plus complet du Web - Et d'autres sujets encore sur ----> http://armorance.free.fr
Alors que les eleveurs et agriculteurs polluent toujours la Bretagne,
Fredchou nous narre ce qui suit en ce 21/05/2007 17:46 :
Enlève déjà les guillemets simples avant et après $HTTP_REFERER.
Ça n'y change rien.
Ce qui est curieux, c'est que même ôtés, le passage du curseur sur le
lien de retour affiche la commande *avec* ces guillemets simples dans la
barre d'état.
Cordialement,
--
docanski
- Les Côtes du nord de la Bretagne par le sentier des douaniers
- Memento des champignons : le guide le plus complet du Web
- Et d'autres sujets encore sur ----> http://armorance.free.fr
Alors que les eleveurs et agriculteurs polluent toujours la Bretagne, Fredchou nous narre ce qui suit en ce 21/05/2007 17:46 :
Enlève déjà les guillemets simples avant et après $HTTP_REFERER.
Ça n'y change rien. Ce qui est curieux, c'est que même ôtés, le passage du curseur sur le lien de retour affiche la commande *avec* ces guillemets simples dans la barre d'état.
Cordialement, -- docanski
- Les Côtes du nord de la Bretagne par le sentier des douaniers - Memento des champignons : le guide le plus complet du Web - Et d'autres sujets encore sur ----> http://armorance.free.fr
docanski
Alors que les eleveurs et agriculteurs polluent toujours la Bretagne, Mihamina Rakotomandimby (R12y) nous narre ce qui suit en ce 21/05/2007 17:46 :
Dans ton cas, tu navigue dans les fichiers en local et non au travers d'un serveur HTTP (l'URL est bien de la forme "file://" et non "http://"?)
En fait j'essaye les deux. Lorsque j'ai le message d'erreur précédemment cité, il s'agit bien d'une url retournée en "file://" mais j'utilise également le serveur de EasyPHP pour les essais. Dans ce cas l'adresse est bien http://127.0.0.1/etc ... Le problème est qu'alors j'ai le plus souvent l'erreur 403 signalant : "You don't have permission to access /Chantier PHP/< on this server." Ni dans la doc, ni dans la FAQ du logiciel je ne trouve de réponse à ce problème :-( Peut-être est-ce un problème de paramétrage mais je n'ai pas réussi à mettre la main sur un tuto capable de me renseigner.
Cordialement, -- docanski
- Les Côtes du nord de la Bretagne par le sentier des douaniers - Memento des champignons : le guide le plus complet du Web - Et d'autres sujets encore sur ----> http://armorance.free.fr
Alors que les eleveurs et agriculteurs polluent toujours la Bretagne,
Mihamina Rakotomandimby (R12y) nous narre ce qui suit en ce 21/05/2007
17:46 :
Dans ton cas, tu navigue dans les fichiers en local et non au travers d'un
serveur HTTP (l'URL est bien de la forme "file://" et non "http://"?)
En fait j'essaye les deux. Lorsque j'ai le message d'erreur précédemment
cité, il s'agit bien d'une url retournée en "file://" mais j'utilise
également le serveur de EasyPHP pour les essais. Dans ce cas l'adresse
est bien http://127.0.0.1/etc ...
Le problème est qu'alors j'ai le plus souvent l'erreur 403 signalant :
"You don't have permission to access /Chantier PHP/< on this server."
Ni dans la doc, ni dans la FAQ du logiciel je ne trouve de réponse à ce
problème :-(
Peut-être est-ce un problème de paramétrage mais je n'ai pas réussi à
mettre la main sur un tuto capable de me renseigner.
Cordialement,
--
docanski
- Les Côtes du nord de la Bretagne par le sentier des douaniers
- Memento des champignons : le guide le plus complet du Web
- Et d'autres sujets encore sur ----> http://armorance.free.fr
Alors que les eleveurs et agriculteurs polluent toujours la Bretagne, Mihamina Rakotomandimby (R12y) nous narre ce qui suit en ce 21/05/2007 17:46 :
Dans ton cas, tu navigue dans les fichiers en local et non au travers d'un serveur HTTP (l'URL est bien de la forme "file://" et non "http://"?)
En fait j'essaye les deux. Lorsque j'ai le message d'erreur précédemment cité, il s'agit bien d'une url retournée en "file://" mais j'utilise également le serveur de EasyPHP pour les essais. Dans ce cas l'adresse est bien http://127.0.0.1/etc ... Le problème est qu'alors j'ai le plus souvent l'erreur 403 signalant : "You don't have permission to access /Chantier PHP/< on this server." Ni dans la doc, ni dans la FAQ du logiciel je ne trouve de réponse à ce problème :-( Peut-être est-ce un problème de paramétrage mais je n'ai pas réussi à mettre la main sur un tuto capable de me renseigner.
Cordialement, -- docanski
- Les Côtes du nord de la Bretagne par le sentier des douaniers - Memento des champignons : le guide le plus complet du Web - Et d'autres sujets encore sur ----> http://armorance.free.fr
Florian Sinatra
*docanski* @ 21/05/2007 14:00 :
"Firefox ne peut trouver le fichier à l'adresse /D:/Chantier PHP/<?php echo '$HTTP_REFERER' ?>"
Tu es sûr d'avoir lancé ton serveur Apache ?
*docanski* @ 21/05/2007 14:00 :
"Firefox ne peut trouver le fichier à l'adresse /D:/Chantier PHP/<?php
echo '$HTTP_REFERER' ?>"
"Firefox ne peut trouver le fichier à l'adresse /D:/Chantier PHP/<?php echo '$HTTP_REFERER' ?>"
Tu es sûr d'avoir lancé ton serveur Apache ?
docanski
Alors que les eleveurs et agriculteurs polluent toujours la Bretagne, Florian Sinatra nous narre ce qui suit en ce 21/05/2007 23:47 :
Tu es sûr d'avoir lancé ton serveur Apache ?
Ben oui : à l'ouverture du logiciel, la fenêtre signale bien le démarrage d'Apache et de MySQL (feux au vert) avec la confirmation "démarrage des serveurs".
Cordialement, -- docanski
- Les Côtes du nord de la Bretagne par le sentier des douaniers - Memento des champignons : le guide le plus complet du Web - Et d'autres sujets encore sur ----> http://armorance.free.fr
Alors que les eleveurs et agriculteurs polluent toujours la Bretagne,
Florian Sinatra nous narre ce qui suit en ce 21/05/2007 23:47 :
Tu es sûr d'avoir lancé ton serveur Apache ?
Ben oui : à l'ouverture du logiciel, la fenêtre signale bien le
démarrage d'Apache et de MySQL (feux au vert) avec la confirmation
"démarrage des serveurs".
Cordialement,
--
docanski
- Les Côtes du nord de la Bretagne par le sentier des douaniers
- Memento des champignons : le guide le plus complet du Web
- Et d'autres sujets encore sur ----> http://armorance.free.fr
Alors que les eleveurs et agriculteurs polluent toujours la Bretagne, Florian Sinatra nous narre ce qui suit en ce 21/05/2007 23:47 :
Tu es sûr d'avoir lancé ton serveur Apache ?
Ben oui : à l'ouverture du logiciel, la fenêtre signale bien le démarrage d'Apache et de MySQL (feux au vert) avec la confirmation "démarrage des serveurs".
Cordialement, -- docanski
- Les Côtes du nord de la Bretagne par le sentier des douaniers - Memento des champignons : le guide le plus complet du Web - Et d'autres sujets encore sur ----> http://armorance.free.fr
Olivier Miakinen
Cela suppose que : 1) HTTP_REFERER est transmis par le navigateur ; 2) register_globals est à On (mais sinon on peut utiliser les variables superglobales) ; 3) JavaScript est actif sur le navigateur ; 4) On arrive sur la page via un lien et pas, par exemple, via un autre history.go(-1), ni une URL saisie par l'utilisateur.
Oui dans 3 des points, le numéro 2 étant pour moi un inconnu.
RTFM ;-)
Ça doit être la question qui est revenue le plus souvent toutes catégories confondues depuis que la valeur par défaut pour register_globals est passé de Off à On dans la 4.2.0.
Voir http://www.php.net/register_globals
Tout navigateur qui se respecte offre un bouton Retour,
Oui mais le but est de pouvoir *aussi* utiliser ces pages en réseau et en plein écran (bornes d'informations à disposition du public), en éliminant donc toute possibilité d'utiliser les outils du navigateur, pour des raisons de sécurité.
Que ne le disais-tu ? Les bornes d'information, je suppose que tu maîtrises ce qu'il y a dessus, et donc que tu peux t'assurer aussi bien de la présence de JavaScript que de l'envoi du HTTP_REFERER.
En tout cas, pour une gestion d'historique il n'y a pas photo : le HTTP_REFERER ne permettra jamais de revenir de plus d'une page en arrière.
et dix mille fois préférable à un lien généré à partir du HTTP_REFERER.
Ça c'est l'argument qui tue toute vellétié de poursuivre dans cette voie. La solution me paraissait pourtant universelle, du moins pour les navigateurs graphiques.
Un exemple tout bête pour te montrer à quel point c'est faux. Le visiteur part de page1, puis va sur page2, page3 et page4. Il clique ensuite quatre fois sur le bouton retour.
Avec JavaScript page4 -> go(-1) -> page3 page3 -> go(-1) -> page2 page2 -> go(-1) -> page1 page1 -> go(-1) -> on ne bouge pas (historique vide)
Le plus que tu peux offrir en PHP, en revanche, c'est de fournir un lien vers la page qui est « logiquement » avant ou après la page en cours, indépendamment du parcours qu'a suivi l'utilisateur pour y arriver.
C'est ce que je tente d'obtenir. Il y a donc un autre moyen ? Le recours à ce genre de commande est dicté par le fait que ces pages peuvent être appelées à partir de 5 menus différents + des liens internes existants dans d'autres pages. Une barre de navigation est ainsi, au moins pour cette dernière raison, impossible à envisager.
D'accord. C'est donc vraiment l'équivalent du bouton BACK du navigateur que tu cherches à réaliser, et pas indiquer une navigation qui soit juste« logique ». Seul le navigateur lui-même pouvant savoir de façon fiable quel était l'historique de navigation, je te conseille le lien JavaScript à l'exception de toute autre méthode.
Cela suppose que :
1) HTTP_REFERER est transmis par le navigateur ;
2) register_globals est à On (mais sinon on peut utiliser les variables
superglobales) ;
3) JavaScript est actif sur le navigateur ;
4) On arrive sur la page via un lien et pas, par exemple, via un autre
history.go(-1), ni une URL saisie par l'utilisateur.
Oui dans 3 des points, le numéro 2 étant pour moi un inconnu.
RTFM ;-)
Ça doit être la question qui est revenue le plus souvent toutes
catégories confondues depuis que la valeur par défaut pour
register_globals est passé de Off à On dans la 4.2.0.
Voir http://www.php.net/register_globals
Tout navigateur qui se respecte offre un bouton Retour,
Oui mais le but est de pouvoir *aussi* utiliser ces pages en réseau et
en plein écran (bornes d'informations à disposition du public), en
éliminant donc toute possibilité d'utiliser les outils du navigateur,
pour des raisons de sécurité.
Que ne le disais-tu ? Les bornes d'information, je suppose que tu
maîtrises ce qu'il y a dessus, et donc que tu peux t'assurer aussi
bien de la présence de JavaScript que de l'envoi du HTTP_REFERER.
En tout cas, pour une gestion d'historique il n'y a pas photo : le
HTTP_REFERER ne permettra jamais de revenir de plus d'une page en arrière.
et dix mille fois
préférable à un lien généré à partir du HTTP_REFERER.
Ça c'est l'argument qui tue toute vellétié de poursuivre dans cette voie.
La solution me paraissait pourtant universelle, du moins pour les
navigateurs graphiques.
Un exemple tout bête pour te montrer à quel point c'est faux. Le
visiteur part de page1, puis va sur page2, page3 et page4. Il clique
ensuite quatre fois sur le bouton retour.
Avec JavaScript
page4 -> go(-1) -> page3
page3 -> go(-1) -> page2
page2 -> go(-1) -> page1
page1 -> go(-1) -> on ne bouge pas (historique vide)
Le plus que tu peux offrir en PHP, en revanche, c'est de fournir un lien
vers la page qui est « logiquement » avant ou après la page en cours,
indépendamment du parcours qu'a suivi l'utilisateur pour y arriver.
C'est ce que je tente d'obtenir. Il y a donc un autre moyen ? Le recours
à ce genre de commande est dicté par le fait que ces pages peuvent être
appelées à partir de 5 menus différents + des liens internes existants
dans d'autres pages. Une barre de navigation est ainsi, au moins pour
cette dernière raison, impossible à envisager.
D'accord. C'est donc vraiment l'équivalent du bouton BACK du navigateur
que tu cherches à réaliser, et pas indiquer une navigation qui soit
juste« logique ». Seul le navigateur lui-même pouvant savoir de façon
fiable quel était l'historique de navigation, je te conseille le lien
JavaScript à l'exception de toute autre méthode.
Cela suppose que : 1) HTTP_REFERER est transmis par le navigateur ; 2) register_globals est à On (mais sinon on peut utiliser les variables superglobales) ; 3) JavaScript est actif sur le navigateur ; 4) On arrive sur la page via un lien et pas, par exemple, via un autre history.go(-1), ni une URL saisie par l'utilisateur.
Oui dans 3 des points, le numéro 2 étant pour moi un inconnu.
RTFM ;-)
Ça doit être la question qui est revenue le plus souvent toutes catégories confondues depuis que la valeur par défaut pour register_globals est passé de Off à On dans la 4.2.0.
Voir http://www.php.net/register_globals
Tout navigateur qui se respecte offre un bouton Retour,
Oui mais le but est de pouvoir *aussi* utiliser ces pages en réseau et en plein écran (bornes d'informations à disposition du public), en éliminant donc toute possibilité d'utiliser les outils du navigateur, pour des raisons de sécurité.
Que ne le disais-tu ? Les bornes d'information, je suppose que tu maîtrises ce qu'il y a dessus, et donc que tu peux t'assurer aussi bien de la présence de JavaScript que de l'envoi du HTTP_REFERER.
En tout cas, pour une gestion d'historique il n'y a pas photo : le HTTP_REFERER ne permettra jamais de revenir de plus d'une page en arrière.
et dix mille fois préférable à un lien généré à partir du HTTP_REFERER.
Ça c'est l'argument qui tue toute vellétié de poursuivre dans cette voie. La solution me paraissait pourtant universelle, du moins pour les navigateurs graphiques.
Un exemple tout bête pour te montrer à quel point c'est faux. Le visiteur part de page1, puis va sur page2, page3 et page4. Il clique ensuite quatre fois sur le bouton retour.
Avec JavaScript page4 -> go(-1) -> page3 page3 -> go(-1) -> page2 page2 -> go(-1) -> page1 page1 -> go(-1) -> on ne bouge pas (historique vide)
Le plus que tu peux offrir en PHP, en revanche, c'est de fournir un lien vers la page qui est « logiquement » avant ou après la page en cours, indépendamment du parcours qu'a suivi l'utilisateur pour y arriver.
C'est ce que je tente d'obtenir. Il y a donc un autre moyen ? Le recours à ce genre de commande est dicté par le fait que ces pages peuvent être appelées à partir de 5 menus différents + des liens internes existants dans d'autres pages. Une barre de navigation est ainsi, au moins pour cette dernière raison, impossible à envisager.
D'accord. C'est donc vraiment l'équivalent du bouton BACK du navigateur que tu cherches à réaliser, et pas indiquer une navigation qui soit juste« logique ». Seul le navigateur lui-même pouvant savoir de façon fiable quel était l'historique de navigation, je te conseille le lien JavaScript à l'exception de toute autre méthode.
