Wedge

That file is always created by wedge so it shouldn't have permission problems.
However if you're importing from SMF, you'll need to chown the file or ensure your apache config allows you to edit the file any other way through php.

While your solution is certainly more elegant than what I ultimately chose to do (and I really, really wanted to just do that include!), ultimately this is the installer we're talking about, the entry point into Wedge, and I just don't have the time to commit to testing whether using the 'default' version will work in the installer. There has to be a reason why SMF (or whatever old version of Wedge) didn't just do include('Subs-Admin.php') to load the updateSettingsFile function and instead chose to re-declare it, so I'm not going to bother for now...

Feel free to test your own patch thoroughly, i.e. go through the painful steps of installation several times, and convince me to use it... The less code, the better. :^^;:

[Commit revision e300c92]
Author: Nao
Date: Tue, 06 Jan 2015 11:50:04 +0100
Stats: 1 file changed; +6 (insertions), -1 (deletion)

• More minor CSS changes, this time to Wilde... (skins/Wilde/extra.css)

[Commit revision eedf086]
Author: Nao
Date: Sat, 03 Jan 2015 23:40:13 +0100
Stats: 1 file changed; +4 (insertions), -4 (deletions)

• Updated to Bad Behavior 2.2.16 (behav_invalid_via test is now only run in strict mode.) (Security.php)

---

[Commit revision 0b351e7]
Author: Nao
Date: Mon, 05 Jan 2015 16:18:02 +0100
Stats: 1 file changed; +2 (insertions), -1 (deletion)

• Added a $separator_col variable. (common.css)

---

[Commit revision f11a6c2]
Author: Nao
Date: Mon, 05 Jan 2015 16:18:10 +0100
Stats: 1 file changed; +12 (insertions), -5 (deletions)

• CSS property break-inside isn't supported in Firefox, so it needed an extra hack... Meh. (index.css)
• Minor improvements to root skin. (index.css)

This shouldn't happen BTW.. Settings.php is created by Wedge itself, so you should have the rights to it...

Unless you installed it before my rewrite a few months ago... Dunno.

Also make sure to purge the cache just in case.

Which makes me realize I forgot to force purge CSS and js files where I'm force purging HTML files... Oops! I'll deal with that later. In the meantime, purge manually!

[Commit revision b44db28]
Author: Nao
Date: Tue, 30 Dec 2014 15:12:50 +0100
Stats: 1 file changed; +1 (insertion), -1 (deletion)

• Forgot to commit the Subs-CachePHP change in Subs-Template.php. (Subs-Template.php)

---

[Commit revision 05bdbfd]
Author: Nao
Date: Tue, 30 Dec 2014 15:36:22 +0100
Stats: 1 file changed; +25 (insertions), -23 (deletions)

• Modding wasn't applied to early-loaded files, only caching, due to accessing $context['enabled_plugins'] before it was potentially initialized. I wasn't drunk, I assure you. Thanks to CerealGuy again for being the only one to bother testing file modding... (Including me.) (Subs-CachePHP.php)
• Added $no_caching parameter to apply_plugin_mods, to allow more freedom in modding any files, including those that shouldn't be cached in gz/app or gz/html. (Subs-CachePHP.php)
• Renamed that function's parameters to $source and $dest, for readability. (Subs-CachePHP.php)