☆ A M B ☆
Bad idea. This is a very complex situation, and can easily trash your data. As long as your config.inc.php has the connection_charset set to match your database, you should be all right.
I assume by changing the latin1 -> utf8, this would fix my issue, correct? Now, two things. I can easily change over the charset collation option on the "homepage" for phpMyAdmin, but what SQL command should I use to change the Collation option under Table options? And I see a bunch of options --- should I use utf8_swedish_ci, or utf8_unicode_ci?
latin1_swedish_ci is the default connection collation for almost every US/Europe based servers, as long as the connection-collation differs from charset you will have crazy issues in those tables that db needs to transfer a mismatching collation/charset data.
basically you have to set utf8_general_ci (preferably) or utf8_unicode_ci in case you need to make a connection over utf8 charset db.
I had a serious issues like this a multiple times in early days of configuring the correct set of db settings to cooperate fairly with MODx configuration and yet couldn’t find any SQL command to make change to individual tables, so i just decided to double check the db environmental settings to meet a true utf8 compatible site at the time of MODx installation.
I remember that susan has implemented a nice db colation check tab in MODx manager interface but unfortunately i don’t have a reference link right now, she is here so she can possibly find it and give you the reference, then only you can check whether every thing is set as you preferred to by that.
BTW, thanks for your help in explaining that. I *think* I’m starting to understand all this charset stuff now. 
)
Soshite, Iirc, your problem was that new users were being seen as *already in* the database. I don’t see any way that charset encoding could cause that problem. Charset problems usually manifest themselves as odd-looking characters on the screen or sometimes unrecognized usernames and/or passwords for people using less-common languages. If you’re not seeing those symptoms, the character set settings are probably fine and trying to fix them could really mess things up.
You wouldn’t be the first person who, on having a mysterious database-related problem in MODx, got drawn into the soul-sucking, endless black hole of MySQL character sets and collations.
Bob
So what was causing the issue of users already being seen in the database w/ WLPE, or the "username isn’t entered" error w/ WebSignup? I would think that would be something related to either the database or the PHP settings.
I attached an image of the Report page, which has the database-related info that susan created a "hack" to show. The other one is from the Configuration tab. Is there an issue w/ this setup? It seems odd that the database says latin, while MODx says UTF-8. BTW, there’s only latin3 and latin9 in the Config tab.
What does the line in your manager/includes/config.inc.php file say?
Bob
)
☆ A M B ☆
It seems odd that the database says latin, while MODx says UTF-8. BTW, there’s only latin3 and latin9 in the Config tab.It is my understanding that this does not mean much. The top image is the database server settings (this is used for connecting to the database and other behind the scenes stuff). While the second is the specific database setting. In modern databases these can be different since they are used for different things. My understanding is from the docs at Mysql. I will look for the exact page that led me to believe this.
