We’re trying to move toward installing Concrete CMS with composer and using .env files. However we’ve run into a snag, if we have the .env file in place and try to run the installer we get
Doctrine\DBAL\Exception\TableNotFoundException: An exception occurred while executing 'SELECT t0.pkgID AS pkgID_1, t0.pkgHandle AS pkgHandle_2, t0.pkgVersion AS pkgVersion_3, t0.pkgIsInstalled AS pkgIsInstalled_4, t0.pkgAvailableVersion AS pkgAvailableVersion_5, t0.pkgDescription AS pkgDescription_6, t0.pkgDateInstalled AS pkgDateInstalled_7, t0.pkgName AS pkgName_8 FROM Packages t0 WHERE t0.pkgIsInstalled = ? ORDER BY t0.pkgID ASC' with params [1]:
SQLSTATE[42S02]: Base table or view not found: 1146 Table 'lamp.Packages' doesn't exist in file /app/vendor/doctrine/dbal/lib/Doctrine/DBAL/Driver/AbstractMySQLDriver.php on line 61
Caused by
Doctrine\DBAL\Driver\PDO\Exception: SQLSTATE[42S02]: Base table or view not found: 1146 Table 'lamp.Packages' doesn't exist in file /app/vendor/doctrine/dbal/lib/Doctrine/DBAL/Driver/PDO/Exception.php on line 18
If we remove the .env file and run the installer it installs fine, but then we have the database.php in the application/config directory, which is not what we want.
Has anybody successfully installed Concrete CMS using a .env file for their database credentials?
This is the question that I asked myself few years ago.
I am not sure, if Concrete supports using .env files during installation.
I think it doesn’t? I could be wrong though.
This is how I am handling it:
My “boilerplate/skeleton” doesn’t have “database.php” present in config folder, only “live.database.php”.
“live.database.php” is filled with credentials from .env file.
Prefix “live” is added since in .env file I have set environment:
CONCRETE5_ENV=live
This could be “prod” or whatever you want.
Before Concrete installation, I am temporarily changing “live.database.php” to “temp.database.php”
After Concrete installation, I am reverting name change.
File “database.php” was automatically created by Concrete, but it can (or rather should) be safely deleted now.
All these stuff is actually nicely listed at my github:
This is similar to our workflow as well - install without the .env in place and then copy the .env.dist and populate with the details after the install has completed.
It’d be great to see this given a bit of attention
@EvanCooper I didn’t want to create an issue if this was something that other users had gotten to work and I just wasn’t finding the right documentation (sometimes very difficult) or finding the right reference in the core.