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:
- 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”
- Install WordPress by assigning credentials and the name to the database, but using passwords below 150 bits in length.