MODX could not create your database. Please manually create your database and then try again.

I know this question has been asked a thousand times but we never seem to get a documented answer on how to resolve it.

I've just done a fresh install of Revo 2.2.14

The database is created and logins alight, but for some reason it Modx can't create it.

→ Test database server connection and view collations.
Connecting to database server: Success!


- Checking MySQL server version: OK! Running: 5.6.16
- Checking MySQL client version: OK! Running: 5.0.10-20111026-$Id:c85105d7c6f7d70d609bb4c000257868a40840ab$

Connection character set:
Collation:

→ Create or test selection of your database.

Checking database: MODX could not create your database. Please manually create your database and then try again.

I've tried changing the charsets with no luck. Anyone know how to finally solve this?

Also, if the db is already created, why is Modx trying to create it?

This bit always drives me nuts.

Thanks

There is no definitive answer to this because it can have so many causes.

MODX is able to connect to your database server (the MySQL or MS-SQL engine). It is able to view available character sets and collations.

MODX is not able to open your specified database, so it tries to create it.

Are you sure that you have the correct database name and password? If you have more than one database, you can connect to the database engine with any of the passwords, but you can only load a database that a password is assigned to.

This may be a database connection method issue. It may be a mismatched character set issue. It may be a problem with date/timezone settings.

Hi MarkG:

I had perpetual problems with this too.

I hope this post will help others and ALSO inspire MODX devs to test future versions of MODX Revo fully with a modern, utf8mb4 charset MariaDB (or MySQL).

[As of the writing of this response, I am on ModX 2.3.3-pl-advanced, NginX 1.8.0, PHP 5.5.9 (using sockets for connection between NginX/PHP-PFM), MariaDB 10.0.18 . Issues with MODX install and related "solutions" have been consistent across earlier versions, however.]

What seems to work reliably for a properly functioning MODX install are the following steps (MODX developers, please note redundancies, necessary backtracking, incomplete error messages, etc. -- these consistent issue in the "Connection Information" manager when connecting to MariaDB/MySQL really need to be fixed! Hopefully this data will help point the way.):

1. create an empty MariaDB (utf8, latin1 or something similar)

There is still a significant problem with utf8mb4 -- creating an empty DB with such charset/collation will ultimately result in a 55 table MODX db when /setup/ populates it, WITHOUT ERROR MESSAGE. PROBLEM!! The default MODX DB seems to always have 70 tables! [MODX devs, please note, MariaDB/MySQL do NOT really offer proper UTF8 unless using the utf8mb4 variant -- see here: http://www.codeka.com.au/blog/2014/02/unicode-support-in-mysql-is-- ; https://news.ycombinator.com/item?id=7317519 ; https://mathiasbynens.be/notes/mysql-utf8mb4 ]

2. create a user for that DB with permissions NONE (i.e. on all DBs), but accessible from all hosts (localhost only does not seem to always work for purposes of MODX setup)

3. create DB permissions on the DB from step 1 for the user from step 2

4. clear your browser cache (the "Connection Information" manager is often flaky without this step!)

5. fill out DB connection information in MODX Setup and click "Test database server connection and view collations"

6. if connection shows successful AND reports DB details, you can probably* click "Create or test selection of your database"

7. finish "creating" DB in MODX setup

8. finish overall MODX setup

9. come back to user and DB permissions and "lock" them down to localhost, if desired (probably a good idea to reduce attack surface)

By the way, on a couple MODX installs I changed the DB charset to utf8mb4 after the fact with no apparent ill-effects. However, I have done that on test sites. I am not sure I would trust this on important production sites, however. While utf8 is OK, I still hope utf8mb4 will be supported properly soon. I rue the day when a MODX db can not support an "arbitrary" international character (see links above).


*In literally scores of attempts (and ultimately a fairly large number of successes) at creating MODX sites, I am convinced that the "Connection Information" manager is flaky. Rather than trying over and over again, if something (anything) fails, save time and just start over:

1. delete everything in your MODX "/core/cache/" folder
2. clear your browser cache
3. restart MODX /setup/


Even with this set of notes, while I can now (fairly) reliably get a "successful" install on the first try, I have an "uncomfortable" number of times where I end up with a 503 error when trying to access the manager after the install. "Best" solution for that seems to be to start over . . . there has to be a better way. :-(


MODX when running is superb, but installation and configuration is an absolute PITA! On the same (and other) server(s) I have various other relatively complex PHP applications running (hand coded and generated), multiple MariaDB's etc. Unfortunately, NOTHING gives me as much trouble as MODX installs/upgrades.

Thanks Felix,

at least somebody else gets it.

Like you, most of the time I install it it works, but on the occasions it doesn't it's a pain.

One thing I have recently discovered is that even if it says the connection to the db is ok and then gives you some additional OK messages such as below, this really means it's not OK.

→ Test database server connection and view collations.
Connecting to database server: Success!


- Checking MySQL server version: OK! Running: 5.6.17
- Checking MySQL client version: OK! Running: 5.0.11-20120503-$Id:bf9ad53b11c9a57efdb1057292d73b928b8c5c77$

I've found you really need to have no additional messages at this stage, just ticks before you can move on to the next stage to create the database.

Why the install process would say things are OK when they are not is confusing and obviously needs to be addressed.

There's a much better chance that these problems will be addressed if they're reported as bugs via the button on the right side of this page. Problems just reported in the Forums tend to fall through the cracks.