Suddenly unable to log into manager

I checked some file permissions yesterday and they looked ok. Just checked again and found that files and folders are all 755 (host is probably playing around?)

memory_limit was 32M so I changed it to 128M (FYI here’s my current phpinfo() from the manager directory)

.htaccess and index.php files are unchanged - nothing hacked

No blocks or failedlogincounts in user_attributes

Thanks for your continued support - how long can this go on?

Did you try resetting the Manager login or adding a new manager via MySQL?

http://wiki.modxcms.com/index.php/Manager_Lockout

Yes I’ve tried that before - but added another new user just now anyway - same issue.
If I enter the WRONG password, it tells me so (as expected). If I enter the CORRECT password, it adds a row to manager_log (action=58 message=’Logged in’) but just displays the login box again.

At this point, we’re grasping at straws.

I know how frustrating things like this can be.

Did you change the files to 644? Especially the manager/includes/config.inc.php and index.php files.

You might ask the host to change the error reporting level to see if that gives you anything.

You can change it yourself in /index.php, /manager/index.php, and manager/includes/config.inc.php

Change it from:



to



(Don’t forget to change it back later.)

As a last resort, I would do an upgrade install. It might fix things, or give you a helpful error message.

I know this can be insanely frustrating -- if you want, send me a personal message with your server login details and I can take a look.

Still no joy. The host has had a poke around and decided it was a MODx problem - which I’m sure it isn’t.

Briefly, they poked around in login.processor.php and thought that because there was no ’manager_login_startup’ entry for the user in user_settings.setting_value, this was the problem as it was redirecting back to /manager/ (the login form). I’ve explained that this is an optional setting, and going to /manager/ should show the backend GUI when logged in. So the ball’s back in their court.

I’ve changed permissions back to 644 for all files in /manager, /manager/includes and manager/processors

Changed the error reporting level - no difference.

Everett - thanks for the offer to have a look, but I’d rather not (at this stage anyway). I’m happy to try anything else you can suggest though.

My next plan is to upgrade to MODx Evo 1.0.0 as BobRay suggested (after COB = 6 hours from now). I’ll let you know how it goes.

PROGRESS!

I removed the php.ini from /manager and now I can get in! There’s a fair bit of whoopin’ and hollerin’ going on around here right now!

The reason for having the php.ini there was to allow uploads larger than 2M (which I still need). Unfortunately upload_max_filesize and post_max_size can’t be set with ini_set() so I will need
to get it working with a php.ini file.

At least now I have something a bit more concrete to talk to the host about.

I’m dying to know what was in that php.ini file. Did you remove it, or just rename it?

I just renamed the php.ini. The only thing it contained was:

I had played around with adding more stuff, like session.save_path and memory_limit but they didn’t solve the problem so I removed them.

It seems that having a php.ini when running PHP as CGI means that the php.ini doesn’t just change a few settings, but REPLACES the system php.ini. So I suppose I’ll need to use a copy of the host’s main php.ini, and just change the bits I want?? Either way, it still doesn’t explain why it has been working ok up until now.

After speaking with someone smarter than me...

Due to the limited architecture of PHP, the php.ini has certain settings that can’t be over-ridden, and the upload_max_filesize is one of them. So tinkering with the php.ini file or the .htaccess file won’t work... it’s set at the global level only (so I’m told).