krijg S_Session niet werkend
Code (php)
1
2
3
4
2
3
4
<?php
$_SESSION['username'] = $row['username'];
echo "Ingelogd als :". $_SESSION['username'] ;
?>
$_SESSION['username'] = $row['username'];
echo "Ingelogd als :". $_SESSION['username'] ;
?>
Dat wordt mooi geprint "Ingelogd als :...". dus daar werkt het nog
Dan probeer ik dit in een ander php weer op te halen via de code:
Code (php)
Maar dit geeft fout, krijg melding
je bent NIET ingelogd als
Notice: Undefined variable: _session in bp.php on line 10.
Het zit dus in: echo $_session['username'];
Wat doe ik fout? Iemand een idee?
Edit:
Ik heb de juiste code-tags geplaatst. Gelieve dit in het vervolg zelf toe te voegen aan je bericht.
Zie ook: Veel gestelde vragen: Welke UBB-codes kan ik gebruiken.
Zie ook: Veel gestelde vragen: Welke UBB-codes kan ik gebruiken.
Gewijzigd op 04/06/2018 21:59:14 door - Ariën -
Hoofdletters!
Variabelen zijn case sensitive = hoofdletter gevoelig in PHP. Het moet dus $_SESSION zijn (en niet $_session - dat is voor PHP heel wat anders).
Code (php)
1
2
3
4
5
6
7
2
3
4
5
6
7
<if (isset($_SESSION['username'] )) {
echo "je bent ingelogd als ".$_SESSION['username'];
} else {
echo "je bent NIET ingelogd als ";
echo $_SESSION['username'];;
}
maar krijg nog steeds: je bent NIET ingelogd als
Notice: Undefined index: username in bp.php on line 10
Na aanpassing naar hoofdletters, komt nu melde undefined index
Je maakt $_SESSION['username'] niet aan. Mogelijk doe je dit op een andere pagina waar de session_start(); mist.
Aha de session_start() had ik niet op pagina waar aan de $_SESSION['username'] een waarde werd toegekend. Het werkt nu ! Bedankt Ariën en Rob
Sowieso kun je in je else-block geen gebruik maken van $_SESSION['username'], omdat je 100% zeker weet dat die niet zal bestaan. Dat heb je immers in je if-conditie al getest.
Willem vp op 05/06/2018 13:43:27:
Sowieso kun je in je else-block geen gebruik maken van $_SESSION['username'], omdat je 100% zeker weet dat die niet zal bestaan. Dat heb je immers in je if-conditie al getest.
Niet helemaal waar, $_SESSION['username'] (de key "username" in het superglobale $_SESSION array) kan best bestaan, maar isset levert toch false op ingeval de waarde hiervan gelijk is aan NULL (misschien is !empty() dan een betere check?). Ik ben het met je eens dat het gebruik van $_SESSION['username'] in het else-statement niet erg zinnig is.
Thomas je gooit isset en empty door elkaar volgens mij? Iig kijkt isset gewoon of een variabele of element in een array geinitialiseerd is. Empty of is_empty wat is het eigenlijk? Die gebruik ik zelf nooit omdat deze functie voor verwarring kan zorgen.
https://secure.php.net/manual/en/function.isset.php voorbeeld 1,5 (tussen #1 en #2 in - specifiek over arrays, zie 'hello'). Als je wilt weten of een key bestaat (ook als de waarde null is) moet je array_key_exists() gebruiken.
@Frank: Dat, of het gebruik van NULL-waarden in arrays verbannen ;).
Thomas van den Heuvel op 05/06/2018 15:07:07:
Niet helemaal waar, $_SESSION['username'] (de key "username" in het superglobale $_SESSION array) kan best bestaan, maar isset levert toch false op ingeval de waarde hiervan gelijk is aan NULL (misschien is !empty() dan een betere check?).
Inderdaad. Overigens is dit een designfout (een van de vele) in PHP. isset() zou true moeten teruggeven als de variabele is geset, maar de waarde NULL heeft. Vaak maakt dat niet zoveel verschil, bijvoorbeeld als je de waarde probeert te printen, maar er zijn situaties waarin je verschil zou willen kunnen maken tussen "niet geset" en "wel geset, maar met waarde NULL". Met empty() of is_null() kun je dat ook niet ondervangen.
De enige manier die ik kan bedenken is om via get_defined_vars() te kijken of er een variabele met de betreffende naam is gedefinieerd, maar dat vind ik best wel een paardenmiddel. En omslachtig. En enigszins off-topic in dit draadje. ;-)
/offtopic
- isset() geeft bij mij altijd een beetje "code smell": alsof je niet zeker weet of een var (of key) al bestaat, en het dan maar "voorzichtig probeert".
- null vind ik een prima waarde. Ik initialiseer altijd alle properties expliciet op null (ondanks dat dat impliciet al gebeurt). Bij een getter is het dan ook:Beide "voorkeuren" zullen wel voorkomen uit het feit dat ik ooit in Pascal ben begonnen (strong typed).
Misschien niet een heel sterk voorbeeld, maar "zelfs" het gebruik van @ is soms geoorloofd. Dit als je verwacht dat er dingen fout kunnen gaan en meldingen wilt onderdrukken, maar deze moet je dan ook ondervangen uiteraard. Iets soortgelijks geldt voor isset(), dit is niet per definitie "fout" of "not done" - uit het gebruik moet blijken of dit een gezond iets is. En als je beweegredenen goed zijn, maakt het eigenlijk niet uit hoe je iets aanpakt, implementatie is ondergeschikt aan motivatie.
Je kunt beter een slechte (maar werkende) implementatie hebben van een goed idee dan een goede implementatie van een slecht idee, aan het eerste kun je altijd nog schaven :p.
Gewijzigd op 05/06/2018 20:56:17 door Thomas van den Heuvel
Ik wist helemaal niet dat isset bij een null waarde false zal geven. Het is eigenlijk enigzins teleurstellend. (Over designfouten gesproken) Wel fijn om dit nu te weten. Ik kan dan naar array_key_exist uitwijken. Bedankt voor jullie inspirerende teksten :-)
Gewijzigd op 05/06/2018 20:56:49 door Frank Nietbelangrijk