I recently upgraded from 1.3.1.2 to 1.4.1.3. Ever since, when using the gallery password to logon to my site, it redirects to the wrong place. That is, when I go to
http://mysite/photos/ I get the password page, I put the password in, hit logon, and get redirected to
http://mysite/photos//photos/# which doesn't exist. The installation went well. Not sure why this is happening or how to fix it. Please help. Thanks!
Comments
Where is the zenphoto installation located?
What theme are you running?
Are there any error messages in your error log?
After debugging the code, I found the problem. Custom theme password forms are deprecated.
Just try to delete the file themes/$theme/password_form.php or move the file to /tmp.
To answer your questions, my ZenPhoto installation is located at http://mysite/photos/. I'm running the Stopdesign theme, but I have the same problem with the Default theme. I don't see any error log, just a debug_log.txt, setup_log.txt, and security_log.txt in the zp-data folder. The latter records the following when I log on with the gallery password:
[Date] [Time] [IP] Admin login Failed gallery-password
[Date] [Time] [IP] Guest login Success zp_gallery
which seems reasonable.
The password_form.php file isn't there any more. It was removed upon upgrade when I gave the setup script permission to delete unnecessary files.
I recently discovered one piece of info that could help pinpoint the problem. When I log in at http://mysite/photos/, I get redirected to http://mysite/photos//photos, which returns an "Object not found" error. If I then navigate to http://mysite/photos/, I see the gallery, so the log in credentials are being accepted. If, instead, I log in at http://mysite/photos/index.php, then the log in works fine (I see the gallery), and I don't get redirected. Perhaps somebody who knows the code will know where to look? Thanks!
I tried changing it in my local installation to test, but I get a warning that I don't understand about not being able to change the headers. Could this, nevertheless, be the source of the problem? It would make sense in as much as the login from http://mysite/photos/index.php doesn't exhibit this problem: it's handled by a different case (line 4415).