Is this new or is this a bug, hestia seems to now only install wordpress via the quick install action to public_html and does not allow me to specify a subfolder like I was able to previously.
I don’t know the reason, but it was removed in PR #4694 and merged on Feb 27, 2025.
Hi everyone,
I’m experiencing an issue with the WordPress automatic installer / Quick Install after updating HestiaCP to version 1.10.4.
Before the update, the WordPress installer was working normally.
Now, when I try to install WordPress using the automatic installer, the installation fails with an error indicating that the database could not be added/created.
What is interesting is that the installer still creates and extracts the WordPress files correctly into:
public_html
However, the database is not created.
As a result, the installation cannot continue because WordPress has no database available.
Current behavior
-
I start a WordPress installation using the HestiaCP automatic installer.
-
The WordPress files are successfully downloaded/extracted into
public_html. -
The installer reports an error when trying to create/add the database.
-
No database is created in HestiaCP.
-
If I manually create the database from the DB section of HestiaCP and then configure WordPress to use that database, everything works normally.
So the problem seems to be specifically related to the automatic database creation step of the WordPress installer, rather than MySQL/MariaDB itself.
Environment
-
HestiaCP: 1.10.4
-
OS: Ubuntu 24.04 LTS
-
WordPress: latest version available through the HestiaCP installer
-
Database: MySQL/MariaDB
-
Web server: Nginx + PHP-FPM
The issue was noticed after updating HestiaCP to 1.10.4.
Has anyone else experienced this behavior with HestiaCP 1.10.4?
Is there any known issue with the WordPress Quick Install / Web App installer failing to execute the database creation step?
Thanks!
It works fine here.
Check if you see the error in /var/log/hestia/nginx-error.log
Updated to HCP v1.10.5. Now is working again. Thanks
There was an issue when the server was behind a router / nat so the loopup was made to wards an external ip instead local ip
