Locked out of the Manager with

We've got a locked-out-of-the-manager situation similar to the one lizardx encountered here - which is discouraging, because that user never actually figured out what was wrong; he only came up with a set of migration steps that worked for him, which he hasn't got round to publishing yet.

The initial setup:

• A MODx Revo 2.1.3 site in two instances, one local and one remote. I can post the server software version numbers for each if necessary.
• A special PHP script we use constantly to sync MODx sites. It does the files through rsync and the database through MySQLdump.
• A rather broken version of the Gallery snippet on the remote site, which prompted us to download the site with our PHP script and try to fix it.

Which brings us to...


What happened:

• We downloaded the site successfully.
• There turned out to be multiple issues with the Gallery installation. We fixed those and upgraded Gallery to the latest version.
• We also upgraded MODx to the latest version, 2.2.4.
• The local version now works completely.
• We ran the sync script to push the local version to remote. On the first attempt, the database didn't seem to come through properly as all the resources were missing. We quickly redid the database sync. The remote site now works correctly on the frontend just like the local one, including the Gallery part.

And this brings us to the problem: Not being able to log in to the Manager.

Here is what we have already checked and tried:

• Verified that the main account still exists in the DB.
• Repeated the sync operation, both files and database, making sure that cache was cleared and sessions were flushed on the local version first.
• Tried the manager's "reset password" function. A reset link and temp password are issued, but the same account-not-found error is returned when we try to use them.
• Re-uploaded the entire site in a Zip file, changing only core/config/config.inc.php to match the server settings. The frontend site worked in this case but the manager still didn't. Also, Gallery showed no entries. When the former production files were restored, the site went back to working as before.

I think the most likely problem is that you copied one or more of these local files to the remote:

.htaccess
core/config/config.inc.php
One or more of the four config.core.php files:
§ MODX root directory
§ /manager/
§ /connectors/
§ /setup/includes/

Also, check the path in the modx_workspaces table in the remote DB.

There are probably paths in the Gallery system settings and/or properties too that would need to be different on the remote.



------------------------------------------------------------------------------------------
PLEASE, PLEASE specify the version of MODX you are using.
MODX info for everyone: http://bobsguides.com/modx.html

Bob:

Thanks for the reply. Our sync system is set up with both file and DB table exceptions to cover all the things you mentioned, with the exception of setup/includes/config.core.php because we use a fresh setup directory anytime we need one. I have also double-checked everything on your list and it is all the correct, remote versions.

So, I'm afraid it isn't anything that simple.

With regard to Gallery, there are some paths that are different on local from remote I think. However, I have trouble believing that Gallery could prevent manager login. Just in case, I did try setting the GalleryCustomTV plugin to disabled in the database, and the login behavior did not change. [ed. note: polrbear last edited this post 14 years, 3 months ago.]

Well, we have met the enemy and he is us.

But it was a subtle problem.

Remember those table exceptions to which I referred above? Turns out that one of those exceptions was the modx_users table. We don't normally update that when we do the sync on the site, in case new users have registered since the site was downloaded. Which normally doesn't cause a problem, but... MODx 2.2.4, to which we upgraded from 2.1.3 on the local version, introduced 3 new fields to the modx_users table. The remote version had a table with all the users all right, but it didn't have those three fields - and that's why login was failing. Once we added the columns to the database, everything was fine and cool once more.

Glad you got it sorted. That is definitely subtle. Congratulations on finding that and thanks for reporting back, I'm sure your post will help others.