next »

[brandsavvy]

I have several sites installed in The RackSpace Cloud Mosso and it seems that the new instances are running a different version (or configuration) of PHP. On all new instances the MODx manager login will not work. Basically, it immediately returns you to the login form once processed.

Info on PHP for the instance that works: http://www.schuylkillhealth.com.php5-2.dfw1-1.websitetestlink.com/info.php

Info on PHP for the instance that DOES NOT work: http://www.haselden.com.php5-3.dfw1-1.websitetestlink.com/info.php

modxCMS - 0.9.6.3
RedHat Linux

Apache - 2.2
PHP - 5.2.6
MySQL - 5.1.11

Any help is much appreciated.

[rthrash]

Looks like they're both running PHP 5.2.6. PHP 5.3 is still in RC status so I can't see Mosso deploying that in production beyond limited testing yet.

[brandsavvy]

Ryan, yes I see that. I got confused about the Mosso naming convention on the new instances: "HTTP_X_MOSSO_DT  PHP5-3" versus the instances that do work that say: "HTTP_X_MOSSO_DT  PHP5-2 ".

I did notice that the variable configurations are not the same. Do you think that just a PHP configuration change could cause this issue?

[brandsavvy]

OK, my problem is solved. Here is the deal:

Evidentially, by default the servers store all sessions in a /tmp/ directory and that can cause an issue depending on how the server is configured. This /tmp/ directory is shared by all websites on the cloud. By changing where the session goes, it pulls the session away from the file system garbage collecting.

There are two lines that need to be added to the .htaccess file that do two things:

1.   Saves our sessions into a directory in our structure
2.   Extends the session time longer


# Write the sessions into a directory specific to the server instance
php_value session.save_path /mnt/stor2-wc1-dfw1/396360/398509/www.haselden.com/web/content/sessions/
php_value session.gc_maxlifetime 28800

Implementing this solution solved my issue.

[rthrash]

That's great information. I think I'll rename and sticky this topic in the thread for future reference for others. Thanks for doing the research brandsavvy.

[codedoc]

Thanks Guys!  Was having the same problem and pulling my hair out.  All is good now.

[sbRyGuy]

THANK YOU!!!! 

I was trying to get this issue working after reading this page:

http://svn.modxcms.com/docs/display/MODx096/Friendly+URL+Solutions

What I was doing was not using the full server path of my site.  My manager kept logging me out and it was driving me nuts.  This seemed to have solved it.  Question though; do we need to change the folder permissions whatever directory we use for sessions?

Just curious here.  Again this post kept me from pulling the few remaining head hairs I have!   

[brandsavvy]

It may not be necessary but it doesn't hurt to add read/write access to the sessions folder.

[ewilkes]

I'm having the same issue (when trying to login it says "...is currently editing these settings. Please wait until the other user has finished and try again."

I have made the changes to the ht.access file and continue to get the message.  Is there something that I'm doing incorrectly?

Here's what I added:

# Write the sessions into a directory specific to the server instance
php_value session.save_path /home/domainName/public_html/assets/sessions/
php_value session.gc_maxlifetime 28800

thanks for any help!

[sharkbait]

I have made the changes to the ht.access

did you rename ht.access to .htaccess? otherwise it won't work
http://modxcms.com/forums/index.php?topic=28454.0

[ewilkes]

when I make those changes I get a 500 internal server error.

[twz]

when I make those changes I get a 500 internal server error.

Your server might be running suExec - if so, you'll need to remove these lines from .htaccess

Code:

php_value session.save_path /home/domainName/public_html/assets/sessions/
php_value session.gc_maxlifetime 28800

and put them in a php.ini file as

Code:

session.save_path = /home/domainName/public_html/assets/sessions/
session.gc_maxlifetime = 28800

[felikz]

Probably worthwhile storing the session files outside the webroot.

[hgw]

Hello,

thanks for the discussion here. I managed to store the session file in a direcory within the own structure, files are saved there, but after login there still is the message "user xy ... is working on these settings ...". MODx doesn't log out me, via QuickEdit I can edit pages, but the manager is still not accessible. Can't empty MODx site cache or do something else there. Browser cache has bee emptied, too.

It's MODx 1.0.0, PHP Version 5.2.10.

Should I change some records in the MODx tables in the database?

Thanks!
Heinz-Guenter

[hgw]

Just an update to my post above: I deactivated JavaScript, called the manager configuration via index.php?a=17, then could after activating JS again remove blocks.

[juliebug]

A huge THANK YOU to the posters on this thread. I was tearing my hair for several hours before I found this. Problem solved.

[clunch]

UPDATE:

Switched hosting, problems evaporated.  Got a better deal with faster servers too!!



Argh.

Thank you for this thread..and I hope my problem is just some bonehead problem on my part.  

So, I'm hosted on FatCow.  I followed the instructions that Diz T. Wiz posted here: http://modxcms.com/forums/index.php/topic,31875.0.html                      

It works great, except that when I click login, it just reloads the page..  If I then click on forgot password, I'm promptly logged in.  This has been the case for quite some time, and I haven't been able to figure it out.  Since the session.save_path thing is part of those FatCow install instructions (it goes into the php.ini file), putting it into a .htaccess just yields the dreaded 500 Internal Server Error.  I've tried changing it from the default of /document root/cgi-bin/tmp to /document root/sessions, and it just barfs session_start() failure type stuff (i.e. it can't save to that /sessions folder, despite it having the correct permissions)

I am kinda stumped.  Any thoughts?

Thanks!

[rhepungus]

I was having the same issue (very random success when trying to log into Manager) when I copied a site from a GoDaddy server to a Rackspace server.  I didnt get the usual Manager errors, so I ruled out needing to re-Install MODx, but after a few hours of trying everything i decided to re-Install MODx (v1.0) over my existing installation (v1.0) and that did the trick.  I no longer have issues logging into the Manager.

Hope this helps.

[Major7up]

I came across this thread after encountering some login issues with rackspace cloud sites. My problems is that I cannot login to the manager from IE7 or IE8 (have not tested IE6 yet) and just keep getting thrown back to the login form everytime. But on FireFox I can login just fine (although when saving documents I am greeted with a blank content area). I have tried implementing the suggestions here of altering the location of session storage to no avail (either in .htaccess or php.ini). This is the first site I have setup using ModX 1.0.x on rackspace cloud (have plenty with older versions) and was surprising given that this was not the first site setup with this ModX version, just the first one at rackspace. Anyone have any other suggestions?

[OpenGeek]

I came across this thread after encountering some login issues with rackspace cloud sites. My problems is that I cannot login to the manager from IE7 or IE8 (have not tested IE6 yet) and just keep getting thrown back to the login form everytime. But on FireFox I can login just fine (although when saving documents I am greeted with a blank content area). I have tried implementing the suggestions here of altering the location of session storage to no avail (either in .htaccess or php.ini). This is the first site I have setup using ModX 1.0.x on rackspace cloud (have plenty with older versions) and was surprising given that this was not the first site setup with this ModX version, just the first one at rackspace. Anyone have any other suggestions?

That sounds like a problem with validation of your site design TBH. Logging in is a server-side activity that should not be affected by what browser initiates the request. Start by validating and go from there.