Cannot Access Manager

I have a site that has been working fine since launch several months ago.

Although I have not done anything significant to the code, the site has started refusing to allow me to log in through the manager. In fact, I cannot even get the login page to show up anymore. A small change to a Formit based field within a chunk last week was all I've done in months but I can't imagine that would cause any problems with the manager not allowing me access. In fact, I even changed that Formit code back to the original version moments later. The front of the site still works fine.

So, I type the login page address and the page times out. This is true, even after I:

1. Clear browser cache.
2. Use different up-to-date browsers on different computers (all cache cleared in those).
3. Clear core/cache and make sure it is writable.
4. Repair modx_session table in the database. In fact, I tried running a repair on all tables.
5. Following Bob Ray's advice on this page: http://bobsguides.com/modx-troubleshooting.html , I've changed compress_js and compress_css settings, turning them off.
6. Making sure there is enough memory for the system to work.
7. Verify that other sites running MODx on that server allow me to log in. They do...problem is with this site only.

This has happened three times starting last week for no apparent reason. The first time it happened, I was able to get into the manager by running a repair on the modx_session table and then clearing core/cache. I thought I was in the clear but the same thing happened twice more, with this morning's third time resulting in me not being able to get in, no matter what I did.

The first time I was able to log in, I went to the error log. I'm not sure if any of this is a clue but maybe you can see something in this:



The site is running MODx v. 2.2.5-pl traditional
PHP Version 5.3.25

I appreciate any and all help.

[ed. note: waizen last edited this post 12 years, 10 months ago.]

Not sure if this is another piece of the puzzle, but I just tried dunnock's solution in this thread: https://forums.modx.com/thread/87417/revolution-manager-login-infinite-loop-workaround#dis-post-481546 and I was able to get in using this address: www.domain-name.com/manager/?a=76, although the system did not ask for my login credentials. I seemed to be logged in already. So, I logged out.

Then, I visited that same direct addressed page from other browsers/computers in the office and found myself to be already logged in through those, too. I logged out through them as well.

After that, the situation seems to have cleared itself, being able to access the page and log in and out. Still not sure why and if this will remain 'cured' or not. Or, if it was a combination of this and the table repairs and core/cache clearing I performed earlier, I don't know.

If anyone can offer an explanation, maybe I can troubleshoot better if it happens again. Thanks.

Yeah... I knew it was too good to be true.

I couldn't access the manager this morning either, although I can get in through dunnock's method outlined above. I did visit the error log once I did get in. I found more of the same type of stuff in there that I wrote in the sample error log above. This time I paid a visit to the pages that the log states as already existing elsewhere and found my client had created a bunch of pages with duplicate Resource Alias entries. I went through the site, making each unique. Then, I cleared cache through the back end and emptied core/cache again, still making sure it is writable. Browser cache cleared, as well. Some things to note:

1. I can see the login page and form when I visit it directly and it looks completely normal but when I enter login information, it just hangs there.
2. When I visit an interior manager page, as outlined in dunnock's workaround above, I get in directly, if I went there right after a normal login attempt. In other words, although the normal attempted login hangs, somehow I do find myself logged in when I then go directly into an interior manager page.
3. If I then log out and then attempt to go directly to an interior manager page, as per dunnock's method, I'm met with the login form. If I then enter the login information, the system lets me in as normal.

Could this be some kind of funky redirect issue, where the login screen has started to refuse a successful redirect to the interior of the backend when I press the Login button, but only with the initial login attempt? And, if so, how do I confirm and do something about that?

This is a particularly picky client and I really hope one of you can help here. I'm at a loss. [ed. note: waizen last edited this post 12 years, 10 months ago.]

What version of MODX?

Have you tried deleting all files in the core/cache directory and clearing your browser cache and cookies before trying to log in?

The next step would be to disable any plugins on the site.

Thank you for responding Bob.

Quote from: BobRay at Nov 08, 2013, 02:18 AM

What version of MODX?

The site is running MODx v. 2.2.5-pl traditional
PHP Version 5.3.25

Quote from: BobRay at Nov 08, 2013, 02:18 AM

Have you tried deleting all files in the core/cache directory and clearing your browser cache and cookies before trying to log in?

Yes. Multiple times. Actually, not that it matters, I don't think, is that in order to do it quickly, I change the name of the suspected bad one to, say cache__BU1 and create a new one, making sure it is fully writable. Browser cache also cleared and multiple browsers tried.

Quote from: BobRay at Nov 08, 2013, 02:18 AM

The next step would be to disable any plugins on the site.

Okay, I'll try that.

Interesting. Now the site is working normally this morning. I didn't get to try Bob's suggestion yet; was on my way to do so.

Tried logging in through multiple browsers/computers throughout the office (yes, browser cache cleared in each) and logged in/out successfully with each. I would be jumping for joy except that I believe that a problem that fixes itself is not necessarily really fixed.

Keeping an eye on it. Could it be that a combination of me making each of my client's duplicate resource aliases unique yesterday and a little time for "healthy cache" to build up (for lack of a better phrase for it) have done the trick?

Is that possible?