Auto-update `.htaccess`, `robots.txt`, or `settings.php` (when we can)

[jenlampton]

Description of the need

When .htaccess, robots.txt, or settings.php have been updated in a release, we should update them when safe/possible

Proposed solution

We could store a hash of the previous version of the file in state. When doing an update, check the hash in state to see if the contents of the file has been changed. If not, we can overwrite it (assuming Backdrop has permissions to write to files outside of core) and update the hash with the hash of the new file.

Alternatives that have been considered

• https://github.com/backdrop/backdrop-issues/issues/5911 (but I think we should do both)

Draft of feature description for Press Release (1 paragraph at most)

Backdrop core can now automatically update files outside the core directory -- assuming they have not been previously modified and that Backdrop has permission to write to those files.

[yorkshire-pudding]

Just wondering further about this... Updating a modified .htaccess file would be very difficult, but what if the customisations could be done in config? Enter https://www.drupal.org/project/htaccess - would an implementation of something like this mean that most customisations would be simply activating pre-defined rules and the config for this would tell an updater what needed to apply. Perhaps it could even have dedicated zones (in several places as sometimes the order of .htaccess rules matters) for customisation that wouldn't be touched in an upgrade? If all the custom rules were in config and all if defined areas, could this make it possible to update standard areas. If one of the switchable rules changed, this could be updated with the switch state intact.

[klonos]

That's an interesting idea @yorkshire-pudding! 👍🏼

Although providing something that would allow people to edit/generate things from the admin UI is better left for contrib, we could be providing a .htaccess.custom file. We could then have a notice at the top of our .htaccess file that says:

DO NOT edit this file directly - add your custom settings/overrides in the .htaccess.custom file instead.

That would mean that perhaps it would be safer to auto-update .htaccess (auto-(re)generate it actually), since people wouldn't be touching the one core provides/generates). We could also perhaps be able to do the re-generation via update hooks.

I would like us to explore this option! 👍🏼

[yorkshire-pudding]

Although providing something that would allow people to edit/generate things from the admin UI is better left for contrib,

I would argue that the following settings might be the only thing touched by 80%+ of sites:

• Set redirection to www or non www.
• HTTPS support (redirect all request to HTTPS or support both protocols).

If those were core config, and you had the ability to have custom, would that be simple enough for core?

[izmeez]

I had an issue that I haven't had time to trace or report, where the line: $database_charset = 'utf8mb4'; was not detected in the settings.php file. On examination of the file, it had been added but to the very end of the file after the block for settings.local.php and was not detected. Ideally, it should be in the database section at the top of the file. Does backdrop use sed to update files?

[yorkshire-pudding]

I had an issue that I haven't had time to trace or report, where the line: $database_charset = 'utf8mb4'; was not detected in the settings.php file. On examination of the file, it had been added but to the very end of the file after the block for settings.local.php and was not detected. Ideally, it should be in the database section at the top of the file. Does backdrop use sed to update files?

@izmeez - this issue (a feature request) relates to improving the process when we update those files as part of a release. I think what you are referring to is quite different and possibly a bug if backdrop is writing that line but then can't read it. Perhaps search to see if anyone else has raised this and then raise a bug if not.