Error establishing a database connection

The fix on Tanzahost: a WordPress site made here has its own database, and WordPress gets its name, user and password from the site's own settings. You never type them. So look at two things:

1. Is the site's database running? Open the site. Under Site, the Database row shows its state, and opens the database's own page. If it didn't start, the site page says so: choose Try again, which starts it again.

2. Was wp-config.php replaced? If you uploaded files from another host, its wp-config.php still names that host's database, like localhost and a cPanel user. Put back the lines that read this site's own settings.

In the file manager, open wp-config.php and make the four database lines read:

define( 'DB_NAME', getenv( 'WORDPRESS_DB_NAME' ) );
define( 'DB_USER', getenv( 'WORDPRESS_DB_USER' ) );
define( 'DB_PASSWORD', getenv( 'WORDPRESS_DB_PASSWORD' ) );
define( 'DB_HOST', getenv( 'WORDPRESS_DB_HOST' ) );

Save, and reload your site. The file manager keeps the version before each save for 7 days, one click to restore.

Why it happens

WordPress shows this page whenever it can't log in to its database. On a cPanel host the database answers at localhost, with a user you made in cPanel. On Tanzahost each site's database is beside the site, in its own sandbox, at its own name, with a user and a 32-character password we made when the site was created. They reach WordPress as the site's variables, and the wp-config.php we start with reads them.

The other reasons are rarer:

• The database is still starting, right after the site was made or restarted. Reload in a minute.

• The database ran out of memory and stopped. It has its own memory limit, apart from the site's, 512 MB to start. Raise it on the database's page, with Change limits.

• Too many connections at once. The more memory the database has, the more connections it allows. A plugin that opens many, or a burst of visitors on slow pages, can reach its limit.

How to check

1. Open the site's page and look at the Database row.

2. Open the project's logs and look at the site's lines around the time it started failing. The database's own messages aren't in them, but WordPress's and PHP's are.

3. In the file manager, search wp-config.php for DB_HOST. If it shows a name in quotes, like 'localhost', it's a copy from another host.