Galette

As discussed quickly on discord, yes, I think we can improve that - installer has been made for "standard" installations, not for "docker-ized" ones.

Just a few remarks following.

Chris Christiansen a écrit :

There is a lot of clicking, walking you through compatibility screens and various checks, but they require no input. Only the database connection input is required.

There is only one screen (compatibility checks) with no input. Second step is the choice between install and update (and that must be kept, we cannot know what user really wants to do), and just after you have to provide database information.

Also, I'm not in favor of any fully automatic install. Installation is destructive, if all connection data are automatically set, anyone will just have to call the installer URL to remove all instance data.
Of course installer may (and should) be protected; but asking the admin the database password is the last protection - I'm not in favor of removing that.

As far as I've understood; you must provide an empty config file; and that currently prevents automatic redirection to installer. We can fix that.

Maybe I miss something, but I don't think you cannot provide any pre-filled configuration file if the database is not embed.
So, if you provide a complete config file; that means you're in the case Galette docker is embedding database; and in that case database should have been completely installed, therefore there is no no need for any installation process. This will maybe require some work on Galette side; maybe not so much (I'll have to check).

Johan Cwiklinski a écrit (#note-1):

As discussed quickly on discord, yes, I think we can improve that - installer has been made for "standard" installations, not for "docker-ized" ones.

Great :)

There is only one screen (compatibility checks) with no input. Second step is the choice between install and update (and that must be kept, we cannot know what user really wants to do), and just after you have to provide database information.

Ok, my bad. Maybe I have just seen it so many times lately, that I forgot or "auto clicked"

Also, I'm not in favor of any fully automatic install. Installation is destructive, if all connection data are automatically set, anyone will just have to call the installer URL to remove all instance data.
Of course installer may (and should) be protected; but asking the admin the database password is the last protection - I'm not in favor of removing that.

Fair enough. Completely unattended install is not so important, so the title of the feature request may be misleading now ;)

As far as I've understood; you must provide an empty config file; and that currently prevents automatic redirection to installer. We can fix that.

Great.
Even better: If I provide a functioning config.inc.php it should just be accepted and the screen where you provide info is prefilled with that info.

Maybe I miss something, but I don't think you cannot provide any pre-filled configuration file if the database is not embed.

That is possible. I have mariadb running in another docker container ready to receive connections from galette. It has a database, user and password that I pre-defined. So it is not embedded, but pre-existing. I think this is actually common for non-docker setups as well.

In docker contexts, you would setup a docker-compose that makes a postgres or mariadb database container and a php-apache container with galette files on it. The database container has predefined and running database for galette including a username and password. This information is shared directly with the galette container during the creation of it using docker-compose.

In "I'm and linuxadmin"-contexts you have something similar. Instead of docker-compose, you have a script that creates your database, user and password and then passes the info on to galette's config.inc.php, so nobody types the 32 character password wrong ;)

So, if you provide a complete config file; that means you're in the case Galette docker is embedding database; and in that case database should have been completely installed, therefore there is no no need for any installation process. This will maybe require some work on Galette side; maybe not so much (I'll have to check).

This could be the case. But I think this is moving into auto-determining if you are upgrading or installing? Basically
if (config.inc.php does not exist) : installing
if (config.inc.php exists but is empty) : installing
if (config.inc.php exists but does not allow db connection) : installing
if (config.inc.php exists and allows DB connection AND DB tables do not exist): installing
if (config.inc.php exists and allows DB connection AND DB tables do exist): upgrading

This is still very dangerous as you point out, so let's keep the install wizard and only do this:

if (config.inc.php exists and is valid and works, but database tables do not exist): redirect to installer from root index
and
if (config.inc.php exists and is valid): prefill database page with data in the installer

I think this would very satisfying and not add any danger.

So basically this feature request should be renamed now:
Allow prefilled database connection info
If use adds config.inc.php before accessing galette for the first time there are two problems:

1. root index does not redirect to installer
2. installer's database page is not prefilled with data, on the database data page

Chris Christiansen a écrit (#note-4):

#1822 is solved

Yes, because it was a quite huge change that should not be done after a RC release.

Current issue is not solved - I did not have time to take an eye on this yet; but fixing it won't produce BC changes.

Chris Christiansen a écrit (#note-4):

2: when adding /installer.php you can get around problem 1. But when you get to the database part of the installer. The values are still not pre-filled, even though you provided the config.inc.php (see attached screenshot "galettedb.jpg")

I've just fixed this one.

As for the original one; changing the way Galette checks if it's installed or not may finally produce BC changes. I cannot do that in 1.1.0.

Sounds good. I will check it in connection with Docker on the next RC or release :)