Flarum setup with preset config file and use .env

clarkwinkelmann

If you are going to create a .env file anyway... What's the benefit over naming it config.php ?

I feel like there's a definite use case for using only environment variables, but when it comes to text config files I have never had any issue mapping/copying config.php on my production servers and excluding it from source control. I don't have any experience with Docker+Flarum specifically though.

Or is it because the .env can be placed elsewhere outside of the project root?

luceos

We are using Flarum on kubernetes, which demands a docker image, at Blomstra. To get this done (aside from a custom skeleton) we actually seed a clean SQL dump into the database. You can then easily configure the config.php with your env variables.

Anyone really wanting to pursue this set up probably should be able to figure out how to do this, otherwise feel free to ask. I think at some point we'll create a docker based skeleton, but that's not anywhere close for now.

chinmaypurav

When a docker container restarts, all data is lost except volumes, secrets attached to it. So if I go via normal setup mode, the config.php file is created but it will be lost the moment container restarts. Hence, .env serves the purpose.
Also while setting up the staging environment, I faced SSL issue. I could not see the option for SSL config. (My colleague had setup the whole Flarum application on local, without docker, so she had it up and running, until we reached this stage where we needed a docker setup)
luceos , I faced similar problem, So even I used that local dump on my staging environment. So yes, like you said, to mitigate the need for SQL dump, I am having a rough thought process:
- If the config file exists, then we move to the next step i.e. the DB migrations.
- Or we could remove the need for config file check and make it static committed to into the package; that would certainly mean a breaking change. The idea is inspired from Laravel

I also moved a few other things like debug, url, etc to .env

<?php

return [
    'url' => env('APP_URL', ''),
    'debug' => env('APP_DEBUG', false),
    'database' => [
        'driver' => 'mysql',
        'host' => env('DB_HOST', '127.0.0.1'),
        'port' => env('DB_PORT', 3306),
        'database' => env('DB_DATABASE', 'flarum_db'),
        'username' => env('DB_USERNAME', 'flarum_user'),
        'password' => env('DB_PASSWORD', ''),
        'unix_socket' => env('DB_SOCKET', ''),
        'charset' => 'utf8mb4',
        'collation' => 'utf8mb4_unicode_ci',
        'prefix' => env('DB_PREFIX', ''),
        'strict' => false,
        'engine' => null,
        'prefix_indexes' => true,
    ],
    'paths' => [
        'api' => 'api',
        'admin' => 'admin',
    ],
    'headers' => [
        'poweredByHeader' => true,
        'referrerPolicy' => 'same-origin',
    ],
    'cookie' => [
        'path' => '/',
        'domain' => env('APP_DOMAIN', ''),
    ],
];

luceos

chinmaypurav When a docker container restarts, all data is lost except volumes, secrets attached to it. So if I go via normal setup mode, the config.php file is created but it will be lost the moment container restarts. Hence, .env serves the purpose.

Yes that's true. It is easier to have an existing config.php and create the database with a dump as mentioned before luceos.

chinmaypurav Also while setting up the staging environment, I faced SSL issue. I could not see the option for SSL config. (My colleague had setup the whole Flarum application on local, without docker, so she had it up and running, until we reached this stage where we needed a docker setup)

You would need to use env vars to change the value of the url in the config.php to have https when a certificate is installed.

chinmaypurav Or we could remove the need for config file check and make it static committed to into the package; that would certainly mean a breaking change. The idea is inspired from Laravel

You can do whatever you want with your installation. Flarum core is just a dependency that can be updated. Our motto is to be available to shared hosting, so we don't follow everything Laravel.

chinmaypurav

luceos I am saying the idea is derived from Laravel, due the problems I faced during the Docker setup. So basically the SQL dump is sort of dependency I have to manage. Now if we still want the existing workflow, that is easily doable, where we write that to .env and not config, because config will be hard coded. Thoughts?

luceos

chinmaypurav So basically the SQL dump is sort of dependency I have to manage.

A GitHub workflow or your CI/CD can generate a dump by installing Flarum from the commandline and then dumping the database? There are ways around this I guess.

chinmaypurav

luceos But the migrations will be a one time thing for the setup. I won't require it every time. Now I am thinking from a perspective, if any new developer joins my team, he should be seamlessly able to setup the app, just by adding the env .

luceos

chinmaypurav you can make your docker image run an entrypoint that runs migrations every time. If there are none left, there are none left.

Here's mine:

#!/bin/bash

# Workaround for permissions issues running the docker images on Ubuntu
usermod -u 1000 www-data

cd /var/www

if [[ -f "config.php" ]]; then
  php flarum migrate
  php flarum cache:clear
  php flarum assets:publish
else
  php flarum install -f install.yml
fi

# Reset permissions
chown -R www-data:www-data /var/www/storage/ && chmod -R g+w /var/www/storage/ && chmod -R 755 /var/www/storage/

# Start apache
apache2-foreground

chinmaypurav

luceos Okay so now I would like to share another problem which I faced,

Even I tried this approach before the SQL dump import, I received this error when I ran

php flarum migrate

Base table or view not found: 1146 Table 'flarum.settings' doesn't exist

Am I missing anything over here? Or is this bug?

luceos

chinmaypurav the settings table only exists after installation. You need to install flarum first, this is possible if the config.php doesn't exist and either using the web interface or the php flarum install command. Or you can have the config.php file and seed a database dump into the database. Then the migrate command will be able to run mutations on the (existing) database.

chinmaypurav

luceos I getting the same error on php flarum install or even php flarum list It seems that if the config file is present, the database is assumed seeded. Now again I am in that loop, I will need to seed the DB from somewhere else. I want to solve this problem.

luceos

chinmaypurav It seems that if the config file is present, the database is assumed seeded.

Yes that's the case. You can seed the database in the same entrypoint step.. Or in your workflow or CI/CD.

chinmaypurav

Okay. I will look into this. I think I will need to dig a bit into the process. Thanks a lot!