Join GitHub today
GitHub is home to over 40 million developers working together to host and review code, manage projects, and build software together.Sign up
Implements new, more robust version of updateSettingsFile() #5815
While working in 2.0.x to implement yet another attempt to fix the race condition bug that can sometimes cause Settings.php to get wiped out under situations of server stress, I came to the realization that the current version of the entire
First, the fact that we have been manually escaping values using
Second, in terms of reading and processing content, the current version does fine when the data in Settings.php is formatted as expected, but it only takes adding or removing a little bit of whitespace in unexpected places to cause issues.
Third, although moving
So, I wrote this PR.
It uses an atomic method of making backups and writing to the file in order to prevent race conditions from ever occurring. It correctly formats all variable types for inclusion in Settings.php by using
I've been testing it for quite a while now, and I have it at the place where its only requirements are:
Provided those three conditions are met, a valid, pristinely formatted copy of Settings.php should be written out every time.
If you want test it out, I recommend throwing a messy Settings.php like the following at it and seeing what happens.
Starting to read it over and it looks good.
I've got a few things I would like to test/note
First note is that Settings.php is common: https://github.com/search?q=filename%3A%22Settings.php%22&type=Code
Second note is I generally take my $db_passwd and put it in another file, then include that file in Settings.php. Simply as a fail safe should php fail and start offering text downloads instead. This will break in this case.
Third note is we do something similar in upgrade.php. We should make this code match or have the upgrade.php piggy back off this code if it can safely.
Fourth note is sometimes integrations are adding stuff to the Settings.php.
For the second case and fourth case this is something that needs to be handled. I think the second can be handled via some override trick. The fourth maybe we simply add all the extra stuff to the bottom that is a valid variable?
Regarding note 1, if that happened we'd be hooped anyway. I don't think this PR can or should do anything about that sort of situation.
Regarding note 2, I suppose I could simplify the code for the
Regarding note 3, I agree. I'll follow up with a commit doing that soon(-ish).
Regarding note 4, this code already does that. Anything unexpected is preserved as-is. Moreover, its relative position in the code is maintained, which is important. You can see this being demonstrated with the
Previously, the could add their own but could not change SMF's standard ones at all Signed-off-by: Jon Stovell <email@example.com>