What version of 68 Classifieds are you running? v4.2.1 developer What template are you using? Default Please describe in detail the issue you are having: I just migrated my clients' site over to a new server. Most of the site seems to be working properly, but people are unable to actually log into their 68C user accounts--if you try logging in, when you hit submit it simply goes back to the login page. Oddly, I'm able to log into the *administration* section without any issues--but logging in as a front-end *user*, even with the administrative account info, keeps bouncing you back. I should note that it first *claims* that I've been logged in successfully, but then bounces back to the login screen without me actually being logged in. The most substantive difference between the old and new servers that I know of is that the new server includes PHP 5.3 instead of 5.2. Any advice/suggestions would be greatly appreciated.
Are you sure there has ben no file corruption due to the migration. Try uploading some key directories again like the includes folder and the files like login.php. File corruption happens often - i just had the same experience on a migration.
Thanks, although I didn't receive any error messages during the automated transfer (I transitioned from a Plesk 8.6 server to a Plesk 10.3 server using the same hosting service), and as I said, everything else seems to be working properly, including the back end, listing searches, etc. However, I did try re-uploading both the included directory and login.php files per your suggestion to no avail.
This type of issue is almost always a corrupted file. With the functionality intact for all other aspects including the administration (which uses different php files including the login), indicates that all of your settings are correct, including db access. Have you checked the files directly, especially the login.php and userindex.php files (the redirected location upon successful login) on your local computer before uploading? In other words, are the file(s) corrupted on your copy that you are uploading. You might also want to empty your "templates_c" directory (smarty cache directory).
Well, I've made some substantial progress: --Emptying the "templates_c" directory didn't help anything. --However, since I had to update it from 4.21 to 4.23 anyway, I just went ahead and did this (which of course replaces all the files with fresh, clean versions anyway), and now have the following situation: --If you check off the "Remember my Login" box, it now logs you in properly. --However, if you *don't* check off "Remember my Login" it does the same thing, claiming you've logged in successfully, but then bouncing you back to the login page??? (On a separate note, I should also note that your Version Upgrade instructions don't mention that all listing photos/thumbnails will have to be re-uploaded! Fortunately I still have the old server running so I was able to re-upload them from there...)
That is true that it doesn't say that in readme, however it does specifically state: "For a complete description of how to upgrade 68 Classifieds please see the upgrading section of the documentation." Which clearly gives you specific directory by directory instructions. I've not heard of this issue and it hasn't been reported by others. Curious which version of php5.3 you're running on the server (5.3.0 had bugs that were fixed in subsequent releases). Sounds like it might be time to submit an official support ticket to 68 Classifieds directly, including your ftp info, login details and detailed description of the issue.
Yep, I saw the detailed documentation after I upgraded. My bad I also had to re-upload the modules, but no biggie The server is actually running 5.3.5. I've already submitted a support ticket with my original issue, but I'll update it with the changes I've made and the FTP info, thanks!
If you have uploaded those core files again and it still does not work then send a support ticket. It is not obvious what it could be otherwise and as Mike said, the problem has not surfaced previously to my knowledge.
Hi Charles - It seems that your session directory is not writable. John's replying to your support request now with a link to a file within your site that confirms this. I don't think this has anything to do with the session problem but I noticed some other sessions that were created while looking into this problem. The sessions are being created from a company called "specificclick(dot)net". I did some googling and it appears that there are a lot of people out on the web who don't care too much for the companies practices. Look into it yourself and decide whether you want to continue to use that site's services. Thanks-
Blair-- I received John's response; however, before I contact my hosting service, is this an issue that can be solved by simply changing the CHMOD settings for a "session" directory in the httpdocs directory, or does it have to be done via SSH, and if so, does this pose any security issues for other sites on the server? I can't ask him directly because he's closed the ticket (which seems a bit premature to me; what if I wanted to just thank him or ask for clarification...like I'm doing here?). I'll check into the specificclick issue, thanks.
Tickets are closed automatically. You should be able to reply to reopen it. The folder that stores session file is outside of your httpdocs directory. The path to the directory that was provided in John's reply is relative to the server root. I doubt you have access to it. I'd recommend contacting your host. They should know what to do
OK, yes, I see it now. I actually have root access, and am reasonably comfortable making CHMOD changes. However, my concern is that since this is at the root level, not the individual site level, that changing permissions here will cause security or other issues with other sites as well (that is, is it set this way for a good reason?) It says I have to create a new ticket to reply, which seems absurd to me...
The session directory has to be writable in order to use PHP sessions. You can modify the directory for sessions via php.ini to another directory to get around the directory being shared across domains. session.save_path = /path/to/dir
Problem solved! I tried turning session.use_only_cookies off to no avail, but sure enough, changing the permissions for the session directory did the trick (and was recommended by the host, so I'm guessing it's not an issue). Thanks to all!
