That account could not be located. Check the username and re-type the password to try again.

I'm including the main error in the title so that anyone searching for this specific failure can find this thread.

That account could not be located. Check the username and re-type the password to try again.

Here's the scenario. This is not the first time I've had this message and problem, last time I did the upgrade / test process I had the same issue, i was hoping that 2.2.2 had fixed it, but no such luck.

Problem comes when importing remote live db to local dev box db,
http://rtfm.modx.com/display/revolution20/Moving+Your+Site+to+a+New+Server
following basically that procedure. This used to work alright on the first modx revolution upgrades I did, now it's not working.

So, here's the steps: export db with dump on live remote server, after clearing the cache. Note, when I went back in and tried to also clear session, I get this error:

security -> flush all sessions -> flush_sessions_not_supported

Not encouraging. So I did a basic simple logout, then shut the browser then did the db dump, then downloaded the dump sql file, and imported it to my local db, which was working fine previously, running the version of the site from the last local/remote sync.

This is to prepare for the 2.2.2 to 2.2.4 upgrade, a process that should, for me, as a paid developer, take no more than 60 minutes. Last time took about 8 hours before this issue went away, no idea what made it finally vanish, but finally it let me login.

Before I go further, please resist the urge to suggest resetting the password, that is not the problem, the problem is somewhere else, and I am posting to find if that problem is fixable, or if I have to give up on modx, since I cannot rationalize to myself spending stressful unpaid hours every time I do a cms upgrade, except that it was me who recommended modx to client, so I am somewhat obligated to stand by the software, at least until it gets just too intolerable to do, which is very close right now, unless I can find a solution.

Last time I did a variety of things on my local system to try to fix it, the obvious, clearing browser cookies, restarting browser, clearing brorwser cache, trying alternate browsers, all kinds of things, and at some point one of them worked. No idea why.

This is MODX Revolution 2.2.2-pl (advanced)

We use the option to store sessions in file location, not db.

This method works and has worked on all versions once I get past the upgrade bumps.

Local system is debian linux
apache 2.2.22
php 5.4.3-5
mysql 5.5.23

remote live site is freebsd 7
apache 2.2.22
php 5.3.13
mysql 5.0.8

I used to keep the local server closer in version with php 5.3 and mysql 5.1, but when this happened last pre upgrade db import on the dev server, failure to accept login for admin user on manager, as a last ditch desperate attempt to try anything to fix it, I upgraded apache, php, and mysql. Didn't work, but it did for some unknown reason finally let me login again an hour or so later, after a few apache restarts and various random other things, different browser finally let me in that time.

Clearly it would be highly desirable to delete the sessions as well as the cache prior to doing the mysql dump to create the file to be imported, but since that part does not work in the remote site, failing with that above error message, that avenue is gone.

To me, it's beyond worrying that the programming could fail to send a user name and password to the database for checking, then return an error message that the username does not exist, then, after you do something or other, pray, try 5 different browsers, it suddenly works. This indicates to me a serious lack of robustness in that core logic, I can't say if it's in the session handling, in the ajax, or what, but clearly sending two text strings to a database for it to check should result in a returned value of a successful login, or a failed login with some message like, you are already logged in (if it's some type of session handling error that is).

While I like modx, and the the way it handles templates and snippets, I am allegedly a professional who also allegedly does this work for money, ie, it's my job, and having these kinds of weird issues that are basically impossible to track down makes me wonder if I should just bite the bullet and tell the client that sorry, we have to move to a more robust cms, not something I want to do, not something the client wants, i'll tell you that, modx really solved our issues very neatly, very good search engine friendly url handling, very nice snippet handling, but the inconsistency and consistent lost time I am getting on these upgrades is really starting to worry me.

My first choice is to solve this direct problem, and then move on with modx, and live with the occasional glitches, but if I can't even import a remote db, do the proper path changes in it, then login back in, a task that should take me no more than about 4 minutes total without losing an entire day each time it happens, I just dont' see how I can keep running modx.

By the way, the cause of my deciding to start the upgrade process was another old bug resurfacing on the live modx, an office admin reported a looping page add submit sequence (the updating dialogue just keeps repeating ... saving page then skipping back), something I'd noted the day before too when saving a page, though mine actually went through. This was a degradation, the site had been running decently well before that, especially once we pinpointed the huge page load slowdown to using live wayfinder menuing on the cached pages, after we fixed that, caching actually worked right, and was very quick.

Sorry for being verbose, but if you see this from my perspective, each time now I am settling down to do an upgrade, I set my timer, start it, then this time, hit the same bug as last time, and start watching my hours dribble away, unpaid, and it's certainly no fun for anyone involved, so if there is a solution, great, let's figure it out, and have this thread be a fix that people can find and point to, if there isn't, well that's something I need to know too.

In a sense I could throw caution to the winds and just apply the upgrades live on the remote live server, and not test them at all, but I think that's horribly irresponsible for me to do, and since I've already suffered one upgrade issue with revolution in the past that knocked off entire live contents until we figured out to set a switch in the manager for some friendly url thing that didn't need to be set on my local server (worrying in itself there too), I really can't trust an untested live upgrade. Though last time, I did note that the remote site upgraded just fine in the end, took very little time, and it was all fine.

But that is just so risky to do, it's a real site, with real traffic, and doing that is in my opinion not very professional on my part.

Any ideas or suggestions appreciated, but I want to note, when this happened last time, eventually something clicked somewhere, and, using a different browser, I was finally able to login to the local site with the imported remote db, but the total randomness of that event is very worrying. So it's not an issue with resetting passwords or any such thing, there's something that gets stuck somewhere unknown, that the remote db is looking for on the local system, but that something appears after a while if you do the right things to get unstuck, randomly.

I waited, by the way, 24 hours to post this, in case something was just stuck in sessions or something else. I'm using a dedicated firefox session and clearing cookies, as well as testing on other browsers, so if this is a session issue, then the way modx is handling sessions is so irregular and unpredictable it worries me, to be honest. And besides that, when you submit a form to a database to login, the sessions should not interfere with such a simple event. Which suggests that the event is not in fact simple at all. I've done enough hacking on phpbb login stuff to have a decent idea of what this code should be like, and there's no place for such a failure in it that I can think of, but modx code is another story, I don't have any familiarity with it.

I've generated a step by step copy and paste set of steps to avoid error for the upgrade procedure, along with all the other steps to do to try to avoid error, it's getting very long, but I'm still not able to get reliable upgrades and db syncs, for example now, the only way I can get back into my local modx dev site is to restore the db from backup, dump all the sessions, and hope I can login again, that's what I did last time, a few times, before the db import finally worked and i could login.
[ed. note: lizardx last edited this post 14 years, 3 months ago.]

I've also had trouble moving a remote site to localhost (though I've never encountered that exact problem). It seems that going the other way is much smoother.

I'm assuming that all the paths in config.inc.php and the three config.core.php files are correct and you've manually deleted all files in the core/cache directory.

Is the admin user there in the modx_users table (with a username and password) when you check in PhpMyAdmin?

Did you use FTP to transfer the files to your local machine?



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

I can completely feel your frustration... sometimes things fall apart and it's very difficult to pinpoint what caused the trouble.

Given your scenario, I have to offer the perfunctory advice of being very wary of running vastly different versions of PHP and MySQL between your dev and prod servers. That's a recipe for disaster -- it's just not good for professional development. It's hard enough to troubleshoot ONE system, yet you are forced to troubleshoot TWO systems, and at an extremely vulnerable time of transferring a site. My gut feeling here is that these wonky problems may stem from your environment(s). MODX is environment intensive (e.g. recall how having your timezone settings misconfigured in php.ini can goof up MODX sessions and cause white-screens in the manager?). The point is that with MODX, any hiccup you have with the environment might get magnified more than if you were using a less intensive system. E.g. WordPress does not natively use sessions, so it will happily run on servers that don't have them set up or have them misconfigured. Not so with MODX.

I'm with you 100% that MODX needs more unit tests for environment variables, and they need to be exposed to the manager. There are a handful of ones that get run when you run the setup (e.g. during an upgrade), but I think there needs to be more checking of the environment since even a small environmental glitch can cause huge ripples in the application.

I've never had substantial problems during migrations so long as I had SSH access on the servers... when you say you are "basically" following the procedure outlined @ http://rtfm.modx.com/display/revolution20/Moving+Your+Site+to+a+New+Server what do you mean exactly? Are you skipping or modifying steps?

Just wanted to say that I had this issue as well (without moving the website) and I have lost one day trying to figure out what I was doing wrong. At the end I thought I had forgotten the password so I changed it directly with a copy-paste from an Evolution database, then I realized Revo didn't use MD5 so I installed another Revo to copy the password from there. That didn't fix it, and after many hours, I don't know how, I managed to get into the manager and I never encountered the error again. It was with Revo 2.2.0

Another time I've lost all chunks because I had deleted the category folder, I had to assign the chunks to another category from the database to restore them. Is this a known bug?

I agree re the php/mysql versions, but that isn't the problem, they were fairly close the first time this issue happened, and I tried upgrading them as literally my last ditch attempt to fix it before giving up. Didn't fix it, but something started working a while later and I finally managed to login. And that is the key right there to fixing the bug in my opinion, look for the thing that can make a form submission of the simplest nature fail to reach the db properly, where is that and why? That is where the bug lies.

To clarify some points, I'm not moving the site, the site is developed locally, the office admin adds pages to the remote, and when I'm going to resync them, I just import the remote db to the local db, the code or pages don't change. until I apply the upgrade on each version, local and remote.

Once that step is done, I upgrade the local version, to see how that goes, then I update the remote version. I agree re php/mysql versions not being the same not being ideal, and in fact, I'd kept them fairly close for a while for that reason, until nothing else seemed to work and I tried updating the local versions to current in debian. They will come more or less back in sync the next major os/server upgrade on the remote site I believe.

When I say 'basically' I mean I am not actually doing anything but the database update part, since both sites have the same version and upgraded at the same rough time, first the local dev version, after importing the current db, then the remote version. In theory I could skip the import of the remote db and just test the actual software upgrade part, but I like the two sites to be pretty much identical.

So maybe I'll just skip the db upgrade since it appears that something just doesn't work reliably with importing the db into the local server, but of course, my fear there is if I ever need to export it to another server, it would be the same possible issue, assuming the core bug, which this must clearly be, is not fixed.

microcipcip, it is precisely that type of randomness that I fear, that simply should not be happening if the system was solid. A password is a password and a username is a user name, there's not special characters or anything involved, this is ascii text basically. The problem is that under certain circumstances of db import, modx simply decides to totally ignore the db itself, and that could be such a wide range of reasons I can't really guess.

I would worry about the mysql / php mismatch, except the first time I hit this issue, they weren't really mismatched by much, and in the end, the only thing that ended up letting me finally login to the dev server was u pgrading all the stuff, doing this then that then more of this, randomly more or less, until it worked. Not my idea of fun.

It could be environmental variables, sure, it's a freebsd system on one end, but a debian testing/sid system on the other. But why? I've never seen that issue anywhere with anything else before, is there something too complicated going on internally? It sounds like it to me.

I'd have to read the code to really see, but to me, the logic should be simple, check if logged in, if not, log in. If logged in, show error that you are logged in, if not, log in. Not sure why more than this would be needed, but clearly something else is going on, and tha tsomething is random and related to something very difficult to figure out.

My intuition is and was that it is a session issue as you note above, but I just do not understand why the sessions cannot be made more foolproof, a login should log you in, not do something or other else.

all paths etc are correct since both sites are running live.

But that reminded me, now I see, I checked a content page and it's blank.... cleared web cache folder manually.

However this type of delicateness really adds more layers, if I have to run precisely the php/mysql/apache version as on the live server, it means I have to create a dedicated vm for just modx, which is even more work, then keep that in sync with the remote versions, none of which I've ever needed to do for any other web app before, which means, really, quite objectively, I really could not justify in time or my expenses etc a decision to use modx for clients, if I were billing him for the last few day's lost time, he'd be looking at between 500 and 1000 dollars for the upgrade, at which point really there could be no objective excuse to be running this stuff or recommending it to use commercially. Maybe as a hobby platform, I don't know.

I'll poke around a bit more, I've sadly, because I have a good relationship with client, already emailed him letting him know the situation.

I can give up on the db data syncs, they aren't stricly necessary for crude upgrade testing, we only use two packages extra, on purpose, since did not want to increase the risk, but the degree of care and effort I have to put out to maintain modx on a commercial level I just don't find easy to justify at this point.

By the way, last time when I was testing and trying to get it to work, I did try to delete the modxcore/cache contents, but when I deleted everything in there, nothing worked at all if I remember right, not even the login page appeared. So I only delete the cache/resource/web/resources directory now.

Again, odd stuff, if I followed the advice to delete cache contents totally, all directories, then the entire install just failed to work, which strikes me as another odd irregularity among a few too many. [ed. note: lizardx last edited this post 14 years, 3 months ago.]

My other option is to accept the limitations and pickiness of modx, build out a new subdomain on the dev server, use it to to test the modx upgrades, which is much less convenient and more time consuming, and certainly isn't a good model in terms of establishing methods for a reasonably wide user base, but I think I will do that, I don't see any other real option now any longer, if that fails, or if I experience any further upgrade glitches, I think I'll have to recommend we drop modx, with sadness on my part. But I'll give it that one more shot, that will cover the apache/mysql/php differences, it will cover the environnment differences, etc.

But I would strongly recommend you start thinking about making modx a bit more resilient and robust, this delicacy level is really not something that is desirable at all in web software, I've never seen anything like it, and I would consider it a bug, a weakness, not a feature, something that is, to be fixed. I've long suspected the modx session handling for various reasons, because I had to watch it very closely when doing some dev work on some features we use, and what I saw I found very worrisome, it just didn't make sense in a normal way of handling sessions.

So I'll see how that goes, pain, but better than spending more days trying to dev my local site, but man, trying to work remotely on programming stuff is a royal pain in the butt.

I think however this is going to be the last modx install I do, I was hoping for maybe some trick or fix, but if there isn't one, this isn't something I can justify ever to a paying client, and certainly I can't to myself, this isn't my idea of a fun way to spend my weekends, unpaid, I can do my own free software projects if I want to do that, and I do. Just did in fact, added a few features to something, works, clean code, easy to debug and work on...

There were a lot of red-flags in your response there: versions were "were fairly close", not "mismatched by much", "pretty much identical" etc. Just because you think the differences don't matter doesn't mean you can overlook them -- coding is not about approximations. I strongly suspect that your cutting corners here is biting you.

I bet Jason has a thorough explanation of how and why some of this might be causing you trouble, but here's my guess: by skipping some of the upgrade/migration steps, something in the MODX sessions and/or in the database does not get updated, and thus retains some kind of fingerprint from the old environment. Eventually the mis-matched session expires, and you're able to log in. MODX does a lot of security things to encrypt passwords and sessions making it a much more secure application, so skipping some of the upgrade/migration steps is not updating those fingerprints correctly and you're left locked-out and frustrated. If you start doing any penetration testing by trying to hack MODX, you'll realize how robust some of these things are because they make the application so much more difficult to hack, but the flip side of that is you have to follow the rules in order for that stuff to keep working.

If you give me access to a copy of your site, I'd like to try updating and or migrating it. You can contact me at http://fireproofsocks.com/contact/

microcipcip: re password resetting -- http://rtfm.modx.com/display/revolution20/Resetting+a+User+Password+Manually

Quote from: Everettg_99 at Jun 24, 2012, 12:39 PM

microcipcip: re password resetting -- http://rtfm.modx.com/display/revolution20/Resetting+a+User+Password+Manually

Thanks

@lizardx: I asked these earlier, but maybe you missed them:

Is the admin user there in the modx_users table (with a username and password) when you check in PhpMyAdmin?

Did you use FTP to transfer the files to your local machine?

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