Bosse1981

Thanks Ryan, after changing the session name I can login. If I change it back, I cannot. I assume that database sessions will solve this problem, but to install that module I needed to login first . Ok, a final comment now I have found the real issue. Using db sessions makes no difference, using 'wire' instead of session_name() still triggers the problem. After reading a comment on php.net about session_name() I checked my php.ini and session.auto_start was true. I don't know if I did that myself or it comes with a php update on debian, but setting it to false and restarting apache solved the problem of this topic.

I am only working 1 day a week on this website, so I dived a bit deeper into this issue today. Tried all the tips you posted, but no success. I see that no session file is written to site/assets/sessions although the folder is writable (tried even with chmod 777). When I refresh the login page or click the login-button, a session file is written to /var/lib/php5 which is the default session.save_path of my debian installation. My guess is that the session is written to /var/lib/php5 but processwire tries to read it from site/assets/sessions. I have been debugging through wire/core/Session.php, wire/core/SessionHandler.php and wire/modules/Process/ProcessLogin/ProcessLogin.module but I can't find the point where pw/php will write the session file. Or am I looking in the wrong direction?

Everything in site/assets/ is chmod -R 777

Already tried that because I found that as a solution in a topic where was said that PHP 4.3 differs in cryptography from PHP 5.4. But if that was the problem I would've got the error "admin - Login failed" and I get no message/error at all. Nothing happens except a reload of the login page. Edit: Forgot to mention: I also cleared all the cache, cookies etc...

Since a while I cannot login to the admin. I don't get any errors, not in de apache logs as well as site/assets/logs/errors.txt. I don't get a message on the admin page that the password is wrong or something like that, no message at all. I already removed all the code from harddisk and updated it from subversion. My colleague uses the same repository and he can login. We're on the same database. Tried to reset the admin password with the forgot password function but that didn't do it. I also cannot login from virtualbox images (windows xp & windows 7) but I can login on the webserver my colleague is running so my best guess is that it is a php or virtualhost issue. I'm running Debian Jessie (testing) with php 5.4.4 and my colleague has php 5.3.x. But I read about many succesfull installations on 5.4. I really don't know what else to check...