[3.0] Generally stop modifying Settings.php after install

[Arantor]

So recently I had cause to look at the updateSettingsFile function. It's an impressive piece of work in some respects... but it's also solving the wrong problem.

I haven't had a problem with Settings.php being blanked out - EVER. Mostly because I made it read-only on my deployments and I edit by hand if it ever needs changing.

But in the intervening years I realised 1) this whole thing is unnecessary in most cases post-install and 2) why do none of the other forum platforms, or indeed most PHP platforms not do this?

Answer: because they put virtually all the settings in the database where they belong.

So much of the content is there in the event of sending the admin an email in the event of database issues. Well... I've seen those emails, I've never once seen them be *useful* because any or all of 1) if the problem is that the access to MySQL is transiently unavailable (e.g. host busy), there's going to be a limited amount you can do about it and 2) in any case if you don't see it and your members don't tell you about it, chances are it's non-recurring anyway, but also 3) if your mail settings are SMTP, you're not going to get the email anyway.

So you might as well do away with the email, meaning that $webmaster_email can safely go into the database as can $forum_name at that point. And you can drop db_last_error.php handling entirely.

$maintenance you have options over, whether to represent (as other platforms do), the difference between mode 0 and mode 1 as a config item in the database, and mode 2 as 'a file exists in the filesystem, so I'm not going to proceed'. You could even make that file be assumed to be HTML and display its content when present (a la mode 2) so the maintenance message could be safely in the database too.

$boarddir and $sourcedir can be inferred from __DIR__ without any problem (and ideally for 3.0, $boarddir and $sourcedir could just go away entirely and make everything autoloadable), $cachedir probably too.

Ultimately there's no need to keep anything in Settings.php except the database connection - and if you *want* to cache the settings query (not really necessary) you could keep the cache settings there too. Personally I'd suggest not caching the settings query at all, and moving everything into the database except the database connection settings.

That way the masterpiece that is 'rebuild the settings file' doesn't need any of that protection or detail because you're not modifying the settings file outside of installation, and honestly not even if you move servers.

I'm not being sarcastic with calling it a masterpiece - it is a thing of beauty. I just think it's solving the problem at the wrong level, and instead by stopping to think about the actual problem you can solve it in far less code, with far less complexity.

[Sesquipedalian]

Broadly speaking, I agree. There are a few other things that need to remain outside the database, such as $auth_secret and the image proxy stuff, but overall it would be good to simplify the content of Settings.php as much as possible.

The main reason that the current version of updateSettingsFile() is so complex is that it needs to account for code structures such as the path correction code, the error catching code, and possibly other arbitrary code inserted by third parties. In my opinion, such code has no place in a settings file and should be moved elsewhere in SMF 3.0. Once that is done, so that Settings.php contains nothing but simple values, everything will become much simpler.

Ideally, I would like to replace that collection of global variables in Settings.php with a single object named SMF_Settings (or SMF\Settings if we implement proper namespaces in 3.0), whose properties would be the values that we currently store as those global variables. Once we do that, storing and retrieving those settings will be a simple matter of exporting and importing the object using PHP's built in functionality for that, and Settings.php will contain nothing but the string representation of that object.

Even if we don't convert those global variables into an object, though, I agree that moving as much content out of Settings.php as possible—and above all, those code blocks—will allow us to make the code to update the settings file much simpler and occasions when we need to update it much rarer, both of which will be great improvements.