Archief - PHP vs JS: Vorige pagina...

Het archief is een bevroren moment uit een vorige versie van dit forum, met andere regels en andere bazen. Deze posts weerspiegelen op geen enkele manier onze huidige ideeën, waarden of wereldbeelden en zijn op sommige plaatsen gecensureerd wegens ontoelaatbaar. Veel zijn in een andere tijdsgeest gemaakt, al dan niet ironisch - zoals in het ironische subforum Off-Topic - en zouden op dit moment niet meer gepost (mogen) worden. Toch bieden we dit archief nog graag aan als informatiedatabank en naslagwerk. Lees er hier meer over of start een gesprek met anderen.

Fr3aK

Legacy Member
Ik heb dus altijd al gewerkt met
PHP:
header("Location: ".$_SERVER['HTTP_REFERER']);
om bij een error de persoon terug te sturen naar de vorige pagina, maar sinds kort werkt het maar half en half :eek:
Als ik via POST iets verstuur wil het wel werken maar als ik iets via GET verstuur wil het niet werken.
Nu heb ik als alternatief
PHP:
echo "<script>history.go(-1)</script>"
maar ik weet niet of dit een degelijke oplossing is, maw het werkt wel maar is het wel veilig en gebruiksvriendelijk?
Graag jullie antwoord :)

Greetz

servi

Legacy Member
header('Location: '.$_SERVER['HTTP_REFERER'].$_SERVER['argv'][0]);

DarkBone

Legacy Member
Tweede methode zal gewoon niet werken als de gebruiker JavaScript heeft uitgeschakeld.

Fr3aK

Legacy Member
servi zei:
header('Location: '.$_SERVER['HTTP_REFERER'].$_SERVER['argv'][0]);
Kheb wa zitten testen en dit werkt evenmin, $_SERVER['HTTP_REFERER'] geeft em ni mee en die $_SERVER['argv'][0] wordt gewoon "x=comments&id=9", dit is de staart van de url waar ik me "nu" bevindt dus da werkt ni echt ;)

DarkBone zei:
Tweede methode zal gewoon niet werken als de gebruiker JavaScript heeft uitgeschakeld.
Das waar maar hoeveel % van de surfers zet hun javascript uit ???

=(X)=RaVen=

Legacy Member
Ik maak een link van "klik om terug te keren als u niet automatisch..."
en dan de javascript erbij :)
khaat het dat er geen output boven die header mag staan ;)
(met includes enzo is dit best wel lastig)

Fr3aK

Legacy Member
=(X)=RaVen= zei:
Ik maak een link van "klik om terug te keren als u niet automatisch..."
en dan de javascript erbij :)
khaat het dat er geen output boven die header mag staan ;)
(met includes enzo is dit best wel lastig)
Maar output boven je header mag/kan wel als je alles buffert dmv ob_start(); in het begin van je php bestand te plaatsen ;)
Tis gewoon dat hij bij mij geen referer meegeeft :confused:

killgore

Legacy Member
Met sessies werken op je site:

$_SESSION["prevget"] = $_SERVER["QUERY_STRING"]; --> op het einde v/d pagina

dan wordt je header zoiets:
PHP:
header('Location: '.$_SERVER['HTTP_REFERER']."?".isset(
$_SESSION["prevget"])?$_SESSION["prevget"]:"");

Fr3aK

Legacy Member
killgore zei:
Met sessies werken op je site:

$_SESSION["prevget"] = $_SERVER["QUERY_STRING"]; --> op het einde v/d pagina

dan wordt je header zoiets:
PHP:
header('Location: '.$_SERVER['HTTP_REFERER']."?".isset(
$_SESSION["prevget"])?$_SESSION["prevget"]:"");
Zoiets zou werken moest em nog iets meegeven met HTTP_REFERER ;)
Die referer krijgt soms geen waarde mee, kweet ook ni hoe da komt :(

Homer

Legacy Member
omdat sommige browsers dit uitschakelen en/of gewoon niet meegeven
HTTP_REFERER is dus browser afhankelijk en niet altijd "reliable"

maT'

Legacy Member
freak, test het verschil eens met je script op een local-server en een degelyke webserver van een host.
Bij mij lag het verschil daarin, omdat lokaal die HTTP_REFERER ook niets meegaf.

dJeez

Legacy Member
Homer zei:
omdat sommige browsers dit uitschakelen en/of gewoon niet meegeven
HTTP_REFERER is dus browser afhankelijk en niet altijd "reliable"
De meeste browsers geven die wel gewoon door hoor, maar er zijn een pak personal firewalls en proxies die die extra info weghalen uit de requests (oa Norton PF dacht ik)... In een sessie telkens de laatst opgevraagde URL opslaan lijkt mij ook wel de simpelste oplossing, tenzij je op voorhand weet naar welk script je moet redirecten, dan vul je gewoon die URL in. En hier lijkt dat laatste mij de simpelste oplossing, aangezien er blijkbaar toch steeds naar 't zelfde script geredirect moet worden (tenzij er ergens extra - user afhankelijke - parameters in 't spel zijn uiteraard).

killgore

Legacy Member
Nullius zei:
Probeer $_SERVER['REQUEST_URI']
Als die leeg is, gebruik je $_ENV['REQUEST_URI']

Dus om terug te gaan:
header("Location: ". ($_SERVER['REQUEST_URI']) ? $_SERVER['REQUEST_URI'] : $_ENV['REQUEST_URI'] );

Meer info te vinden op:
http://www.php.net/manual/nl/language.variables.predefined.php
edit: note: gebruik liever de empty functie hierop dan een gewone check, is correcter ;).

En moest je nu eens 2 keer nadenken voor je comments geeft: ik gaf enkel methode voor get-vars op te slaan, een beetje doordenken biedt de oplossing aan he: voeg de url er op die pagina aan toe. Dan heb je enkel problemen met externe links (als dat al een probleem voor jou is ;)).

Nullius

Legacy Member
killgore zei:
edit: note: gebruik liever de empty functie hierop dan een gewone check, is correcter ;).
Ik gebruik bijna nooit empty.
Dezelfde waarde wordt verkregen in dit geval (true als er iets instaat en false als ie leeg is) en in mijn geval kan je altijd met 'false' werken (bv bij return uit functies).
Dus er zijn wel enkele voordelen aan mijn methode :)

killgore

Legacy Member
Nullius zei:
Ik gebruik bijna nooit empty.
Dezelfde waarde wordt verkregen in dit geval (true als er iets instaat en false als ie leeg is) en in mijn geval kan je altijd met 'false' werken (bv bij return uit functies).
Dus er zijn wel enkele voordelen aan mijn methode :)

tbh, !empty() en gewone evaluatie hebben zelfde effect, maar empty is duidelijker om te lezen imho (en ook correcter). empty werkt dus ook met booleanse waarden ;).
Jouw methode zou wel een notice kunnen krijgen als de var niet geset is, met empty heb je dit niet. dus ==> mijne is correcter en doet hetzelfde :p.

meer info: http://be2.php.net/manual/en/types.comparisons.php
Het archief is een bevroren moment uit een vorige versie van dit forum, met andere regels en andere bazen. Deze posts weerspiegelen op geen enkele manier onze huidige ideeën, waarden of wereldbeelden en zijn op sommige plaatsen gecensureerd wegens ontoelaatbaar. Veel zijn in een andere tijdsgeest gemaakt, al dan niet ironisch - zoals in het ironische subforum Off-Topic - en zouden op dit moment niet meer gepost (mogen) worden. Toch bieden we dit archief nog graag aan als informatiedatabank en naslagwerk. Lees er hier meer over of start een gesprek met anderen.
Terug
Bovenaan