Database not being created in any subdomain

Hello Community,

I’ve been using HestiaCP for the first time for about 20 days and everything has been fine until I tried to install WordPress on a subdomain using the “Quick App Install” feature. It generates a database with an empty dump, leading to an “Error establishing a database connection” when visiting the newly installed WordPress site. This error is not due to incorrect configuration in the “config.php” file, as all data there is correctly added as entered from the HestiaCP forms.

On the main domain domain.tld, everything works correctly when installing WordPress via “Quick App Install”.

The subdomain is correctly created, as verified by visiting the subdomain URL. SSL certificate installation and subdomain folder creation at /home/user/web/subdomain.domain.tld are also correct. Everything works perfectly, except when installing WordPress on the subdomain. The installation completes without errors, but visiting the subdomain site returns the mentioned error. The database appears to be empty, containing only what is shown in the image.

I should note, this error also occurs when creating a new database from the panel.

Is there any preliminary requirement for installing WordPress on a subdomain to avoid this database error? As mentioned, this error does not occur with main domains, only with subdomains.

Thank you.

You first need to create a new database through the hestia panel under the same user account you want to install wordpress. Only thereafter you can provide all necessary details during the wordpress installation like, database name, database user, database password, etc.

Most likely you tried to install a new wordpress installation by letting the installer create a new database for you, right?

Hello,

I had already added several main domains (domain.tld) in HestiaCP, each with its respective WordPress (WP), and verified that each domain had been installed correctly and that DNS in Cloudflare and SSL in HestiaCP were all working without problems, as has been the case. For these main domains, I simply checked the box to create a database and then added a name, user, and password for the database (passwords over 256 bits), and both WP and its database installed well and without problems.

I repeated this procedure with the first subdomain I created in Hestia, and the installation process finished correctly, but when trying to access the site, the error mentioned in this thread occurred. Upon checking everything, I found that the database was created, but without data, tables, or anything, as seen in the image.

After trying several times, I let the quick WP installation automatically generate the database without assigning a name, user, or password… and boom, WP was correctly installed just as it happened with the main domains. So far, this was the solution to a problem that, in my case, I can consider a bug in Hestia (or maybe not). After recovering the access data in the config.php, I did several tests, changing the user and password of the database, both from Hestia and from the database itself, and different types of responses occurred that were not as expected… In short, I did all this to experiment with the problem that had occurred with the subdomains.

Then, I created another test subdomain, out of curiosity about what had happened, but this time, I did it again entering the name, user, and password for the database myself, and inexplicably, WP installed correctly and as expected with its respective database. At this point, I didn’t know or understand the initial behavior with the subdomains that had the database installation problem.

But after several tests with subdomains, I realized that among the solutions to this peculiar issue, apart from installing the database with automatic credentials, I noticed that by swapping and using passwords that did work in the main domains (I emphasize that I am talking about the database password), I observed that the subdomains that installed the empty database were those to which I assigned a password close to or exceeding 256 bits, and the subdomains that did not present problems with the WP database in their installation were those to which I placed passwords that did not exceed 150 bits.

Therefore, the way I have been able to move forward with the installation of subdomains is:

  1. Install WordPress with automatic credentials, and then make manual changes in the “config.php” or make credential changes in the database itself with the data retrieved from “config.php”

or

  1. Install WordPress by assigning credentials and the name to the database, but using passwords below 150 bits in length.