This is related to the changes in https://gerrit.wikimedia.org/r/c/mediawiki/core/+/757744/ (T300301).

It has affected at least three people now, https://lists.wikimedia.org/hyperkitty/list/mediawiki-l@lists.wikimedia.org/thread/MU3ERMTPQRMJOCLMEVSRU76TVQA5NJL4/, so it's not just one person's weird config (though it may be related to leftover config weirdness from old installs generally).

I think we've found the issue: https://lists.wikimedia.org/hyperkitty/list/mediawiki-l@lists.wikimedia.org/message/VS2JW3KZRZIEBZCKEQTFRKUVYTEQVXIM/

LocalSettings.php files generated before 1.17 have "require_once( "$IP/includes/DefaultSettings.php" );" Loading DefaultSettings.php twice was harmless before, but it now seems to cause problems because the order of initialization has changed.

Can we come up with a way to handle this, or at least to make the fix obvious for people who run into it?

Instead of this (found in Setup.php on line 262-267),

if ( $wgBaseDirectory !== MW_INSTALL_PATH ) {
	throw new FatalError(
		'$wgBaseDirectory must not be modified in settings files! ' .
		'Use the MW_INSTALL_PATH environment variable to override the installation root directory.'
	);
}

put this in Setup.php instead:

if ( $wgBaseDirectory !== MW_INSTALL_PATH ) {
	$wgBaseDirectory = MW_INSTALL_PATH;
}

Any reasons why this small patch wouldn't work? (The "if" check probably isn't even neccessary, just hardcode it.)

In T311966#8089582, @The_Silent_Ones wrote:

Any reasons why this small patch wouldn't work? (The "if" check probably isn't even neccessary, just hardcode it.)

It would fix the error, but it would not behave as the user expects. If I assign a value to $wgBaseDirectory, I expect that value to be used. Just ignoring it is confusing.

What the error is really saying is "you cannot change the base directory!".

In T311966#8091593, @daniel wrote:

In T311966#8089582, @The_Silent_Ones wrote:

Any reasons why this small patch wouldn't work? (The "if" check probably isn't even neccessary, just hardcode it.)

It would fix the error, but it would not behave as the user expects. If I assign a value to $wgBaseDirectory, I expect that value to be used. Just ignoring it is confusing.

What the error is really saying is "you cannot change the base directory!".

$wgBaseDirectory was introduced in 1.38. It's likely meant to act as a base for things like, custom upload and extension directories. (Used to be $IP's job) and this is a 1.38 issue.
Likely intended usage:

$wgUploadDirectory = "$wgBaseDirectory/vault";

Bad usage:

$wgBaseDirectory = "[insert any path that is not MW_INSTALL_PATH]";

The $wgBaseDirectory check should just set it if it's not MW_INSTALL_PATH, not halt MediaWiki.

This same issue affected me as well. My original installation was far before 1.17 so there is undoubtedly much old cruft in my LocalSettings file that has accumulated. I would love to start with a clean, modern LocalSettings file and re-configure it but one of those is not provided in the Git repo or anywhere else I can find. I think there should probably be a clean, current LocalSettings file available somewhere that we can use as a template to start over again. Also, there probably needs to be more detailed upgrade instructions related to changes to LocalSettings.

In T311966#8049615, @Emufarmers wrote:

I think we've found the issue: https://lists.wikimedia.org/hyperkitty/list/mediawiki-l@lists.wikimedia.org/message/VS2JW3KZRZIEBZCKEQTFRKUVYTEQVXIM/

LocalSettings.php files generated before 1.17 have "require_once( "$IP/includes/DefaultSettings.php" );" Loading DefaultSettings.php twice was harmless before, but it now seems to cause problems because the order of initialization has changed.

Nice find! Yeah, I can reproduce this as well. Note that if you don't set $wgExtensionDirectory explicitly, like the OP did, it'll be set to empty string, so any wfLoadExtension() (or $wgStyleDirectory/wfLoadSkin()) call will fail and throw an exception.

Can we come up with a way to handle this, or at least to make the fix obvious for people who run into it?

I would suggest in DefaultSettings.php, where we currently log a deprecation message, to 1) improve the message and 2) use something that's enabled by default like trigger_warning or error_log. AIUI nothing in MediaWiki should intentionally load DefaultSettings still, right? Bonus points would be using debug_backtrace() and looking to see if the file that loaded DefaultSettings was named LocalSettings, and output a customized error based on that...