Thread tagged as: Error, Installation, Configuration

compatibility test fails


the compatibility test fails with this error message:

Error message SQLSTATE[HY000] [1045] Access denied for user 'PERCH_DB_USERNAME'@'localhost' (using password: YES)

I've double and triple tested db name, username and password, tried both 'localhost' and '' for server.

I've created a new db, and I've also tried already existing db's with exactly the connection details as I use them in the configs of other CMS, same result.

Server details:


PHP Version: 5.4.23 MySQL Version: 5.5.32-cll-lve

This happens on a server where I've installed and run successfully Textpattern, ExpressionEngine, MODx, ProcessWire, Wordpress. It can't be that Perch among all these CMS can't be installed I think.

Nothing in the error log.

How do I get past this step?

Rene Tschannen

Rene Tschannen 1 points

  • 7 years ago
Rachel Andrew

Rachel Andrew 394 points
Perch Support

That error isn't Perch, it's MySQL. I'd suggest contacting your host.

Thanks Rachel. I'm running 12 domains on this server, each of them with a MySQL DB and I can connect fine with all of them.

Testing the connection with this method works (same credentials):


$link = mysql_connect('localhost', 'zonech_mysql', 'password', 'zonech_perch');
if (!$link) {
    die('Connection failed: ' . mysql_error());
echo 'Connection successful';


Perch is using PDO to connect. Can you help me to narrow down the issue? As the code above works, it can't be MySQL.

Rachel Andrew

Rachel Andrew 394 points
Perch Support

If you can't get the compatibility test to work I'm not sure how we can help. Perch requires the test to work to be able to run. You are getting an access denied error from mysql, that's not coming from Perch.

Rachel, since I can connect to the database by creating a new PDO object like in the code provided above, a mysql error can be ruled out, otherwise that code would fail too.

For testing, I've opened PerchDB_MySQL.class.php and did hard code the credentials and got PASS: you're all set!

Thus, definitely not a connection problem. I hope you agree.

In retrospect, the first hint is already there in the error message by which I've opened this thread:


It puts out PERCH_DB_USERNAME which is the name string of the variable, not the value I've entered.

Obviously the values I enter in step1.php are not passed on to PerchDB_MySQL.class.php, despite step1.php checks for the input. That's something your PHP code has to handle. Of course if Perch tries to connect to the db with an empty string, it throws an error. It's just not my mysql configuration that's to blame for then.

So, how do we go on from here? Are you willing to look into it now? Is it even important, is Perch using the same method to pass on input from text boxes to the database as the compatibility tool?

Drew McLellan

Drew McLellan 2638 points
Perch Support

Do you have any rewrite rules in place on the server that could be affecting this folder?

Hi Drew - no htaccess, no rewrite rules.

Drew McLellan

Drew McLellan 2638 points
Perch Support

Somewhere between the form on step1 and the handling of that form on step2, the content of the POST must be getting lost.

Do you get any of our error messages (i.e. not MySQL ones) on the page? If you load step2 directly, does the output differ?

No error messages, nothing in the error_log on the server. Output when loading step2.php directly:

The test has been unsuccessful

Reason Please provide a full set of database details. Server is the name or IP address of the server that runs MySQL. This is often localhost but not always. Check with your host. Database is the name of the database to use. When adding a new database, some hosting control panels prepend the account name to the name you specify, so double check. Username is the login name of a database user with permissions to use that database. Password is that user's password.

As we see, by loading it directly it complains not getting any input.

Drew McLellan

Drew McLellan 2638 points
Perch Support

Can you post a screen shot of the full browser window when the test fails? It's a long shot, but we're firmly into longshot territory.

The test is deliberately simple - it's not doing much at all. I can't see anything in your phpinfo that suggests why this might fail.

Hm, interesting result, in order to take a screenshot I was opening Internet Explorer, and it passed the test. My standard browser is Google Chrome (Version 35.0.1916.153 m, on Windows 8.1, 64 bit), and there it fails. I disabled all extensions, repeated the test, and it still fails.

I guess screenshots are unnecessary, as they display nothing dubious anyway.

Since I was on it, also checking with Firefox, it passes the test too.

Testing on a VM with Windows 7 32-bit / Google Chrome (Version 35.0.1916.153 m too) passes the test.

Clearing Cache and Cookies on Chrome / Win 8.1 doesn't change anything.

Really strange.

By the way, what irritates is also that I've tested the compatibility on another server, using the same Chrome Browser from my Windows 8.1 machine, and it passed. I just can't wrap my mind around how Chrome can interact differently with another server.

And on a third server, I got a different error message with localhost, but passed the test when I've used instead, also with Chrome. That was definitely related to how mysql/php is configured on that server.

It's getting weirder: Chrome 35.0.1916.141 on my Android Nexus 7 v2 Tablet fails the test too.

Google Chrome on OS X 10.9.2 passes, as Safari on iPad does too.

Drew McLellan

Drew McLellan 2638 points
Perch Support

As I say, the test is deliberately very simple. I'm not aware of anything that would cause one browser to work and another to fail. I suspect there may be external factors at play.

I did some more tests, it's not a POST issue, the content is there, I've inserted some code to display it on step2.php. I've decided there must be something weird passed on with the strings and added this block of code at line 30 in step2.php:

        $db_server = trim($db_server);
        $db_database = trim($db_database);
        $db_username = trim($db_username);
        $db_password = trim($db_password);

That solved the problem. On further examination I found I had a whitespace at the end of the DB username, and because of Chrome's autocomplete feature it got added on every test.

What I still don't understand and what set me on the wrong track right from the beginning is how it was possible that the variable name 'PERCH_DB_USERNAME' was showing up in the initial error message.

So much time wasted - mine and yours, sorry for that - with something so stupid.

Maybe you can add trim somewhere to strip off whitespace from the input so no one else runs into that trouble. At least I'm always doing that before processing user input.

I'll buy Perch now, for a project that doesn't require one of the fat CMS I use for other projects. I simply couldn't imagine how Perch could have compatibility issues on my server and was about skipping the compatibility test. I probably would have been better off doing so ... ;)