Install Errors when Testing MySQL Database

Hi...

I'm trying to install MODX 2.2.9 at Domain Hostmaster (same configuration as GoDaddy or Wild West Domains' servers) in a Linux environment with MySQL 5.5 and I received the following errors when testing the database:

Connecting to database server:
Could not connect to the database server. Check the connection properties and try again.

[2013-09-08 19:45:07] (ERROR in xPDOConnection::connect @ /home/content/04/11050604/html/websites/s-dakota.com/core/xpdo/xpdo.class.php : 3031) SQLSTATE[HY000] [2019] Can't initialize character set (path: /usr/share/mysql/charsets/)

[2013-09-08 19:45:07] (ERROR in xPDOConnection::connect @ /home/content/04/11050604/html/websites/s-dakota.com/core/xpdo/xpdo.class.php : 3031) SQLSTATE[HY000] [2019] Can't initialize character set (path: /usr/share/mysql/charsets/)

I hope someone has a solution because I keep coming back here and never getting MODX installed on any of my new domains, for a very long time, now.

I liked MODX when it was Evolution, but then the jump to Revolution seemed impossible because of all my scripts and the changes I had to make to get them going. But everytime I try a clean install on a new domain I come here for help and no one ever replies.

I would appreciate the help, and thank you kindly in advance. -DP

I hope it won't offend you if I restate the basics here.

What you're seeing is almost always the result of either an incorrect database server name, database name, database username, database user password -- or the database user not having sufficient rights to the database.

These values get stored in core/config/config.inc.php, so it may be easier to edit them there.

First, make sure you're not using your MODX Manager username and password -- you need the db username and db user password at this point.

The database server name is almost always 'localhost', but there are exceptions.

Note that the database name and database username are not necessarily what you entered when you created the database. Many hosts will add a prefix to them.

It's also easy, in cPanel's database manager, to create the user but forget to connect the user to the MODX database, or forget to give the user full rights.

My apologies if you've already investigated all these possibilities.

Quote from: BobRay at Sep 09, 2013, 12:20 AM

I hope it won't offend you if I restate the basics here.

Not at all.

Quote from: BobRay at Sep 09, 2013, 12:20 AM

What you're seeing is almost always the result of either an incorrect database server name, database name, database username, database user password -- or the database user not having sufficient rights to the database.

I've already changed the Database password (the only thing I can not visually verify) and then used it right away in the script. I do have the right db name/user/host.

Well, I had to reload the page and wound-up starting from the beginning. This time it worked.

Quote from: BobRay at Sep 09, 2013, 12:20 AM

These values get stored in core/config/config.inc.php, so it may be easier to edit them there.

First, make sure you're not using your MODX Manager username and password -- you need the db username and db user password at this point.

The database server name is almost always 'localhost', but there are exceptions.

Yeah, all that checks out, but I have a server address instead of 'localhost'

Quote from: BobRay at Sep 09, 2013, 12:20 AM

Note that the database name and database username are not necessarily what you entered when you created the database. Many hosts will add a prefix to them.

Mine are the same. No biggie. Not arguing, just conversing.

Quote from: BobRay at Sep 09, 2013, 12:20 AM

It's also easy, in cPanel's database manager, to create the user but forget to connect the user to the MODX database, or forget to give the user full rights.

Yeah, you got that right. Nope, not on CPanel any longer.

Quote from: BobRay at Sep 09, 2013, 12:20 AM

My apologies if you've already investigated all these possibilities.

No apology necessary. I don't know what went wrong, but obviously something was screwed up because I got to the point where I pick out a connection character set and a collocation.

I'm an American but I want this site to have international character support, so I am thinking UTF, but there is UTF-8, UTF-16, UTF-32, UTF-mb4? Or should I choose Latin-1?

Not sure. What is Colocation?

Holy ****... I have never needed that info before. LOL I want to get this right, but have no idea what the heck, I have never seen this option before.

That's 'collation.'

It basically tells the database server how to sort things (so strings with accented characters will be sorted correctly).

The official MODX recommendation is UTF-8, but you have to set the database to that before your put any data in it.

I use utf8_general_ci for the collation, but some people use utf8_unicode_ci. I researched the difference once and thought the former was a better choice, but I can't remember why.

In examples like German where two symbols represent the same letter, or Hebrew where text may be used that has letters using the "nikkud" or vowel points, a collation like utf8_unicode_ci works better, as the letters with nikkud have a different code than those without, but technically are the same letter for sorting and comparing purposes.

Bin, on the other hand, only goes by the binary code, so even if in your language a == a+, a collation of utf8_bin_ci will sort them by their binary code, and return a != a+ in a comparison. Sometimes in Hebrew this is desirable behavior, if you want to sort or compare the letters with vowel points differently.

http://stackoverflow.com/questions/2344118/utf-8-general-bin-unicode
http://stackoverflow.com/questions/10929836/utf8-bin-vs-utf-unicode-ci
http://forums.mysql.com/read.php?103,187048,188748
http://dev.mysql.com/doc/refman/5.0/en/charset-unicode-sets.html
[ed. note: sottwell last edited this post 13 years ago.]

That jogs my memory a bit. My sites are all in English, so utf8_general_ci seemed a better fit.

Wow, what great info, sottwell, Thanks!

I decided to use UTF-8 & UTF 8 unicode ci because even though all content will be in english (even user input because I cannot moderate languages I don't know). My reason is because I design fonts and want the right character showing up in the fonts. So more accurate is key. Besides, it is a small site that speed won't make much of a differnce on, anyway. I think.

After that, every single thing had a green checkmark and everything installed. Except, after finishing and deleting the setup directory, I was presented with a heading menu and a tiny scrollable window, or iframe, under it that almost didn't allow me to read more than a line or two of text.

I selected 'Dashboards' and only had a blank page under the drop-down menu bar header. I select other things and all I get is a heading with a blank page.

It looks like something is wonky in the css, or something.

So it is installed, but I have no viewable control panel in the manager, just a menu that doesn't seem to take Me anywhere.

Correction, I can get here but it is opening a new window, when I select the forums in support.

I should probably open a new topic, it is a new issue to deal with. Thanks, Bob & Sottwell, for all your help!

Try clearing your browser cache and cookies.

Also, turn off the compress_js and compress_css System Settings. If you can't do it in the Manager, you can do it in the modx_system_settings table in the DB in PhpMyAdmin (via cPanel).