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!
I'm not trying to log in as full admin. I'm testing the gallery password to see how the site appears to guests with whom I share the password.
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 looked at the code. Please forgive if I misunderstand something, but it looks like the extra case added in 1.4.1.3 since version 1.3.1.2 (line 4432) in the function getPageRedirect in zp-core/template-functions.php is responsible for adding the extra /photos path.
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).
I finally (two months after you fixed it) updated (to 1.4.1.6), and, indeed, the fix worked. Thanks a million! You guys are definitely on my Christmas list. Happy holidays and a joyful new year!