Bekijk Volledige Versie : PHP Sessions werken niet op Tran
Bjorn Couwenberg
15/05/13, 18:27
Al een tijdje draai ik zonder problemen een aantal websites op een BladeVPS X1 van TransIP. Op deze VPS draait Plesk als softwarepakket.
Ik loop er alleen tegen aan dat de $_SESSION functionaliteit van PHP niet werkt. Ik weet zeker dat het een configuratie probleem is want op een ander server (die DirectAdmin gebruikt) werkt het systeem zonder problemen.
Heeft iemand een tip waar ik naar moet gaan kijken? Helaas kon TransIP mij niet helpen, en ik heb zelf echt GEEN idee!
Zeer raar want out-of-the box werkt dat direct. Als je er niet uitgeraakt pm me maar even...
Vergelijk eens de output op beide servers eens van
echo phpinfo();
Hier staat oa "Session support: enabled", als het goed is. Andere mogelijk heeft apache geen schrijfrechten op de map waarin de sessie bestandjes worden opgeslagen.
dennis0162
15/05/13, 19:50
Als ze in /tmp worden weg geschreven kan het zijn dat de /tmp partitie vol zit.
Bjorn Couwenberg
15/05/13, 19:55
Zie hier (http://wauwwebdesign.nl/ecommerce/phpinfo.php) de phpinfo.
Ik heb geen wijzigingen gedaan aan php.ini of php settings.
Je zegt dat sessions niet werken omdat 'het systeem' het op plek B niet doet. Hoe weet je dat het aan de session ligt? Probeer dingen zo klein mogeliojk te maken om dingen uit te sluiten en conclusies te kunnen trekken.
Probeer anders even iets simpesl zoals dit:
<?php
error_reporting(E_ALL);
session_start();
if ( $_SESSION['sessie_test'] ) {
echo 'Sessie bestaat!';
} else {
echo 'Sessie niet gevonden, laten we hem proberen in te stellen. Ververs deze pagina om te testen of het werkt...';
$_SESSION['sessie_test'] = true;
}
session_write_close();
?>
Bjorn Couwenberg
15/05/13, 20:16
Vergeten te melden maar zo'n test had ik al uitgevoerd.
Heb hem hier (http://wauwwebdesign.nl/ecommerce/test.php) ook even online gezet. Geen resultaat.
Bestaat session.save_path /dir/tmp ?
Lijkt mij een raar pad
Bjorn Couwenberg
16/05/13, 10:47
Bestaat session.save_path /dir/tmp ?
Lijkt mij een raar pad
Ik ben helaas niet zo thuis in de console :crying:
Hoe moet dat :)?
doe eens een cd /dir/tmp en kijk of je ergens uitkomt of dat hij al zegt dat het niet bestaat...
Waarom neemt iedereen toch unmanaged VPSen terwijl ze niet eens met een console overweg kunnen ... *zucht*
Bjorn Couwenberg
16/05/13, 13:57
Directory werd niet gevonden, dus heb deze aangemaakt.
Probleem was hierdoor (ook niet na een reboot via console) opgelost.
Viel me wel op dat op deze server dit staat:
Registered serializer handlers php php_binary wddx
En bij de andere server dit:
Registered serializer handlers php php_binary sqlite
de andere server heeft niet eens een save_path gedefinieerd.
Dat verschil in serializer handlers lijkt me niet zo belangrijk, de meeste applicaties die aan zoiets behoefte hebben zullen de standaard PHP-handler wel gebruiken. Als save_path niet is gedefinieerd dan gebruikt PHP een compile-time default en dat is meestal /tmp. Ik vermoed dat dat de plek is waar je de sessies zult vinden op de oorspronkelijke server.
Bjorn Couwenberg
16/05/13, 18:40
Ik heb ondertussen (via tips van een collega) de save_path naar een default waarde kunnen zetten. Deze folder bestaat en is schrijfbaar. Echter.. Session werkt nog steeds niet! Ik snap er echt helemaal niets van.
Wat denk je van over te stappen op een managed VPS? Vele hier zullen je er eentje kunnen aanbieden...
Ik heb ondertussen (via tips van een collega) de save_path naar een default waarde kunnen zetten. Deze folder bestaat en is schrijfbaar. Echter.. Session werkt nog steeds niet! Ik snap er echt helemaal niets van.
Als je via pm contact opneemt wil ik er wel even kosteloos naar kijken.
Bjorn Couwenberg
17/05/13, 10:35
Als je via pm contact opneemt wil ik er wel even kosteloos naar kijken.
Ik denk... done? Ook al blijft verzonden berichten hier leeg haha!
Bjorn Couwenberg
17/05/13, 11:35
Het probleem is inmiddels met hulp van Golden opgelost! Bedankt.
Het probleem is inmiddels met hulp van Golden opgelost! Bedankt.
Je bent welkom!
Wellicht handig om te vermelden wat het probleem was, alsmede toegepaste oplossing (voor anderen) :)
Wellicht handig om te vermelden wat het probleem was, alsmede toegepaste oplossing (voor anderen) :)
Waren enkel rechten en incorrecte mappen. :). Dus de default map (volgens zijn server) kon niet beschreven worden door betreffende users. Dus gewoon andere sessionpath opgegeven en rechten gecorrigeerd.