/ Forside / Teknologi / Udvikling / PHP / Nyhedsindlæg
Login
Glemt dit kodeord?
Brugernavn

Kodeord


Reklame
Top 10 brugere
PHP
#NavnPoint
rfh 3959
natmaden 3372
poul_from 3310
funbreak 2700
stone47 2230
Jin2k 1960
Angband 1743
Bjerner 1249
refi 1185
10  Interkril.. 1146
PHP global systemvariabel, der indeholder ~
Fra : Kenneth Brun Nielsen


Dato : 02-04-02 01:25

Jeg har brug for at vide hvilken side browseren "ser" på et givet tidspunkt.
Dvs. specielt sti og filnavn på det pågældende php-script. Sagt på en anden
måde: hvis man betragter url'en http://www.pbk.dk/fodbold/index.php,
efterlyser jeg en (system-)variabel, der indeholder strengen
"/fodbold/index.php".
Funktionen phpinfo() afslører at $REQUEST_URI og $SCRIPT_NAME indeholder
noget, der minder om denne streng, men når jeg benytter disse i scriptet er
de tomme. Er der andre systemvariabler, der skal bruges istedet for
ovennævnte, eller har jeg bare lavet en brøler?

På forhånd tak!

Kenneth



 
 
Jonas Koch Bentzen (02-04-2002)
Kommentar
Fra : Jonas Koch Bentzen


Dato : 02-04-02 08:38

Kenneth Brun Nielsen skrev:
>
> Funktionen phpinfo() afslører at $REQUEST_URI og $SCRIPT_NAME
> indeholder noget, der minder om denne streng, men når jeg benytter
> disse i scriptet er de tomme.

Prøv med

$_SERVER["REQUEST_URI"]
$_SERVER["SCRIPT_NAME"]

eller hvis din PHP-version er mindre end 4.1.0:

$HTTP_SERVER_VARS["REQUEST_URI"]
$HTTP_SERVER_VARS["SCRIPT_NAME"]

SCRIPT_NAME indeholder filnavnet relativ til dokumentroden. REQUEST_URI
viser det samme plus en eventuel query string.

--
Jonas Koch Bentzen

http://understroem.dk/

Michael Gandrup Vend~ (02-04-2002)
Kommentar
Fra : Michael Gandrup Vend~


Dato : 02-04-02 11:09

On Tue, 2 Apr 2002 02:25:13 +0200, Kenneth Brun Nielsen wrote:

>efterlyser jeg en (system-)variabel, der indeholder strengen
>"/fodbold/index.php".

Måske jeg har misforstået noget ang. subjekt, men kan en $PHP_SELF
ikke bruges?

--
Med venlig hilsen
Michael Gandrup Vendelbo

Kristian Risager Lar~ (02-04-2002)
Kommentar
Fra : Kristian Risager Lar~


Dato : 02-04-02 16:17

> Måske jeg har misforstået noget ang. subjekt, men kan en $PHP_SELF
> ikke bruges?

$_SERVER['PHP_SELF']; // er at foretrække

--
Kristian Risager Larsen
http://www.kezze.dk - mailto:kezze@kezze.dk
"Artificial Intelligence usually beats natural stupidity."



Kenneth Brun Nielsen (02-04-2002)
Kommentar
Fra : Kenneth Brun Nielsen


Dato : 02-04-02 19:31

Tak for svarene!

Jeg har brugt lang tid på at afprøve jeres forslag, samt kombinationer af
disse, men intet af det ville virke for mig. Min php-fortolker er version
4.0.6, og det hører med til historien, at systemvariablen blev kaldt fra en
funktion, der var i en require't fil. Sidstnævnte oplysning er
tilsyneladende meget relevant (har jeg fundet ud af), idet jeg afprøvede fx.
echo $HTTP_SERVER_VARS['PHP_SELF']; direkte i et script - hvilket gav det
forventede output (sti + filnavn) - men når kommandoen blev kaldt fra den
require'de funktion var outputtet, som nævnt, NULL.
Jeg har dog fået lortet til at virke ved at benytte flg. syntax:
$path = getenv('SCRIPT_NAME');
og efterfølgende returnere indholdet af variablen...

Håber ovenstående giver mening. Er der iøvrigt nogen, der har et fornuftigt
bud på, hvorfor jeg ikke kan få de nævnte forslag til at virke? I så fald
vil jeg gerne høre det!

Kenneth



[5000] Jesper Brunho~ (03-04-2002)
Kommentar
Fra : [5000] Jesper Brunho~


Dato : 03-04-02 08:00

[Jeg er ikke datalog, så vær søde bare at rette mig hvis jeg tar fejl ]

Kenneth Brun Nielsen wrote:
> ...systemvariablen blev kaldt fra en
> funktion, der var i en require't fil. Sidstnævnte oplysning er

Så vidt jeg ved så er require() en cachende funktion, man kan således
ikke forvente at den re-evaluerer alle funktioner etc hver gang den
anvendes - i modsætning til include()

/Jesper B


Jonas Koch Bentzen (03-04-2002)
Kommentar
Fra : Jonas Koch Bentzen


Dato : 03-04-02 08:58

[5000] Jesper Brunholm skrev:
>
> Så vidt jeg ved så er require() en cachende funktion, man kan således
> ikke forvente at den re-evaluerer alle funktioner etc hver gang den
> anvendes - i modsætning til include()

Forskellen på include og require har ændret sig lidt gennem PHP's
levetid. På nuværende tidspunkt er den eneste forskel mellem include og
require den fejl, det giver, hvis filen ikke findes. include giver en
advarsel, mens require giver en fatal fejl.

--
Jonas Koch Bentzen

http://understroem.dk/

Per Thomsen (03-04-2002)
Kommentar
Fra : Per Thomsen


Dato : 03-04-02 22:22


"Kenneth Brun Nielsen" <kenneth@pbk.dk> skrev i en meddelelse
news:a8cte5$1br$1@eising.k-net.dk...
> Tak for svarene!
>
> Jeg har brugt lang tid på at afprøve jeres forslag, samt kombinationer af
> disse, men intet af det ville virke for mig. Min php-fortolker er version
> 4.0.6, og det hører med til historien, at systemvariablen blev kaldt fra
en
> funktion, der var i en require't fil. Sidstnævnte oplysning er
> tilsyneladende meget relevant (har jeg fundet ud af), idet jeg afprøvede
fx.
> echo $HTTP_SERVER_VARS['PHP_SELF']; direkte i et script - hvilket gav det
> forventede output (sti + filnavn) - men når kommandoen blev kaldt fra den
> require'de funktion var outputtet, som nævnt, NULL.
> Jeg har dog fået lortet til at virke ved at benytte flg. syntax:
> $path = getenv('SCRIPT_NAME');
> og efterfølgende returnere indholdet af variablen...
>
> Håber ovenstående giver mening. Er der iøvrigt nogen, der har et
fornuftigt
> bud på, hvorfor jeg ikke kan få de nævnte forslag til at virke? I så fald
> vil jeg gerne høre det!

Ja... den relevante information er ikke at dine forsøg ligger i en fil, som
du requirer - den relevante information er at din forsøg var/er inden i en
funktion. Hvis du kører PHP 4.0.6, bør du anvende
$HTTP_SERVER_VARS['REQUEST_URI'], men $HTTP_SERVER_VARS er ikke en
superglobal som $_SERVER er det - og $_SERVER er først tilgængelig fra PHP
4.1.x. Der er tre måder du kan løse det problem på, du kan umiddelbart
inden, du forsøger at tilgå $HTTP_SERVER_VARS fortælle at den er i global
scope, ved at skrive:
global $HTTP_SERVER_VARS
eller du kan vælge at anvende den superglobal der er, og så tilgå variablen:
$GLOBALS['HTTP_SERVER_VARS']['REQUEST_URI'],
eller du kan bruge den metode som du har brugt med at anvende funktionen
getenv('REQUEST_URI'), som jeg personligt ville foretrække, fordi der er
størst sandsynlighed for at denne også virker efter næste gang PHP folkene
for en fiks ide om hvordan tingene bør gøres (indsæt selv små irriterede
lyde og brok over "PHP-folkene" her).

Håber at jeg har ret i at det er det der er galt, og at du kan bruge svaret
til noget - selvom det kommer lidt sendt.

MVH Per Thomsen,
http://www.pert.dk/


>
> Kenneth
>
>



Kenneth Brun Nielsen (03-04-2002)
Kommentar
Fra : Kenneth Brun Nielsen


Dato : 03-04-02 23:46


"Per Thomsen" <pert@pert.dk> skrev i en meddelelse
news:a8frt4$2tsk$1@news.cybercity.dk...

Der er tre måder du kan løse det problem på, du kan umiddelbart
> inden, du forsøger at tilgå $HTTP_SERVER_VARS fortælle at den er i global
> scope, ved at skrive:
> global $HTTP_SERVER_VARS
> eller du kan vælge at anvende den superglobal der er, og så tilgå
variablen:
> $GLOBALS['HTTP_SERVER_VARS']['REQUEST_URI'],
> eller du kan bruge den metode som du har brugt med at anvende funktionen
> getenv('REQUEST_URI'), som jeg personligt ville foretrække, fordi der er
> størst sandsynlighed for at denne også virker efter næste gang PHP folkene
> for en fiks ide om hvordan tingene bør gøres (indsæt selv små irriterede
> lyde og brok over "PHP-folkene" her).
>
> Håber at jeg har ret i at det er det der er galt, og at du kan bruge
svaret
> til noget - selvom det kommer lidt sendt.
>
Det kan jeg - til at stille min nysgerrighed! Tak for det udførlige svaret -
jeg tænkte nok det var et-eller-andet med de finurlige globale variabler..

Kenneth



Kristian Risager Lar~ (03-04-2002)
Kommentar
Fra : Kristian Risager Lar~


Dato : 03-04-02 22:38

> disse, men intet af det ville virke for mig. Min php-fortolker er version
> 4.0.6, og det hører med til historien, at systemvariablen blev kaldt fra
en


Hvad med at opgradere php så du ikke skal tænke på workarounds?

--
Kristian Risager Larsen
http://www.kezze.dk - mailto:kezze@kezze.dk
"Artificial Intelligence usually beats natural stupidity."



Kenneth Brun Nielsen (03-04-2002)
Kommentar
Fra : Kenneth Brun Nielsen


Dato : 03-04-02 23:42


"Kristian Risager Larsen" <kezze@kezze.dk> skrev i en meddelelse
news:a8fsnc$mee$1@sunsite.dk...
> > disse, men intet af det ville virke for mig. Min php-fortolker er
version
> > 4.0.6, og det hører med til historien, at systemvariablen blev kaldt fra
> en
>
>
> Hvad med at opgradere php så du ikke skal tænke på workarounds?
>
Det er jo ikke MIN webserver! Den styres af en flok frivillige her på
kollegiet - og hvis man er frivillig, gider man ikke sådan noget som en
opgradering, der ikke er tvingende nødvendig

Kenneth



Kristian Risager Lar~ (03-04-2002)
Kommentar
Fra : Kristian Risager Lar~


Dato : 03-04-02 23:51

> Det er jo ikke MIN webserver! Den styres af en flok frivillige her på
> kollegiet - og hvis man er frivillig, gider man ikke sådan noget som en
> opgradering, der ikke er tvingende nødvendig

Hvis du byder root på en bajer tror jeg gerne han compiler php4.1.2 for dig
:)

For mig virker det bare skørt at køre med en forholdsvis gammel version af
php. Der er jo kommet en del nye funktioner og forbedret sikkerhed i
php4.1-serien.

--
Kristian Risager Larsen
http://www.kezze.dk - mailto:kezze@kezze.dk
"Artificial Intelligence usually beats natural stupidity."



Søg
Reklame
Statistik
Spørgsmål : 177559
Tips : 31968
Nyheder : 719565
Indlæg : 6408938
Brugere : 218888

Månedens bedste
Årets bedste
Sidste års bedste