Migrate install_files scripts to PHP and add more config to .env

[qwerty287]

Allow to change some config options via .env and migrate the install_files to PHP (see #1323 (comment)). Also fixes a deprecation.

[codecov]

Codecov Report

Merging #1361 (f540021) into master (68d60df) will decrease coverage by 0.88%.
The diff coverage is n/a.

[nagmat84]

Overall I am in favor of the PR. I added some remarks and suggestions, but nothing severe.

[nagmat84]

This comment is for the whole script not just this line. I am not sure, if this script works nicely on Windows. Obviously, nobody has ever being bothered by this question, because the old file was a .sh-script which obviously has never been working with Windows.

But now, after the script has become runnable for Windows we should maybe also ensure that it runs nicely. Here are the two things, I am not sure about:

1. We use \n as the new line character. PHP offers the constant PHP_EOL which is \n\r on Windows, because Windows needs an additional carriage return. However, I do not know if this is only required for text files our for output to the command line, too. I would suspect the letter, because the programmer cannot know if the STDOUT targets the screen or is redirected to a file. So probably, we should use PHP_EOL.
2. I am not sure, if Windows can handle the ANSI escape sequence and color codes.

[qwerty287]

Not tested, but Windows seems to support ANSI. See https://gist.github.com/mlocati/fdabcaeb8071d5c75a2d51712db24011 for example.

[nagmat84]

Great! Then we can keep the color codes. I feared that Windows would get confused in such a way that it would totally break console output. Glad to hear that it is the other way around!

But I still believe we need PHP_EOL instead of \n.

Moreover, another thought crossed my mind. I somehow remember that you figured out that the ANSI color codes are either only supported by echo or by printf. I don't remember what script you repaired and what the correct solution was, but have you checked that?

[d7415]

Looks good. I think it's worth adding some of the missing variables to the example .env, so that users know what's available.

[qwerty287]

I wouldn't add them to .env, instead, use the docs for this task (LycheeOrg/LycheeOrg.github.io#56).

[d7415]

LycheeOrg/LycheeOrg.github.io#56 (comment)

I'm very in favour of complete examples (ideally with the default values - I suggested changing those to match elsewhere).

As a user, having to copy every directive is a pain, and then you'd probably want to add context in case you need to edit later.

[qwerty287]

I understand this and agree with you, but I wouldn't add the experimental/advanced settings to the example. And the non-experimental are all available there already.

[d7415]

Looking again at the list, I think I mostly agree. At which point it doesn't need to be in this PR.

FWIW, the one that caught my eye was SESSION_SECURE_COOKIE, which seems like a reasonable thing to expose at some point.

[sonarqubecloud]

Kudos, SonarCloud Quality Gate passed!   

0 Bugs
0 Vulnerabilities
0 Security Hotspots
0 Code Smells

No Coverage information
0.0% Duplication

[kamil4]

Untested but looks good.