kevinrose wrote:

Sorry to avoid confusion - the actual error is at line 1145 when the incorrect $filename tries to get required.

I think you're confusing "require" with "autoloading".

The require_once() call you mention:

require_once("$IP/extensions/WikiEditor/WikiEditor.php" );

that isn't a class but an extension file. This is your own code and placed in your LocalSettings.php, correct?

AutoLoader isn't involved there.

After line 1142 $filename =
"\\server\share\mediawiki\\server\share\mediawiki\extensions\WikiEditor\WikiEditor.php"

Line 1142/1145 of which file? Assuming AutoLoader.php, why is WikiEditor listed in your autoloader configuration?

Please confirm that this is a MediaWiki related problem. Otherwise this issue should be closed.

michael wrote:

I experienced the same issue after upgrading to the latest version of GearHost.com's cloudsites platform, which too changed from local drive storage to a network share. Like the original poster, I found the same behavior. Additionally, though, I found that commenting the require_once("$IP/extensions/WikiEditor/WikiEditor.php" ); line would temporarily resolve the issue and allow MediaWiki to load, which suggests some dependency between require_once and the autoloader. I applied a similar change to the autoloader file which allowed to uncomment the require_once line successfully. I am running MediaWiki 1.19.1.

kevinrose wrote:

I forgot about this bug - upgraded my mediawiki to latest snapshot of 1.22 and the issue came back.

The issue isn't related to a particular extension, but to the use of the AutoLoader. Above the samples were with WikiEditor. This time I came across it with VisualEditor which uses AutoLoader.

In 1.22 latest snapshot 7/16/2013 line 1148-1152 of file includes\AutoLoader.php:

1. Make an absolute path, this improves performance by avoiding some stat calls

		if ( substr( $filename, 0, 1 ) != '/' && substr( $filename, 1, 1 ) != ':' ) {
			global $IP;
			$filename = "$IP/$filename";
		}

This handles the case where $filename is a linux full path (starting at /) or a windows full path (with the drive letter i.e. c:) but does not handle the case of a network share on windows (\\server\path)

Again fix in first message does address this:

if ( substr( $filename, 0, 1 ) != '/' && substr( $filename, 1, 1 ) !=
':' && substr( $filename, 0, 2 ) != '\\\\')

Adjusted to look specifically for two forward slashes in case there's some other case where one forward slash is ok?

Tagging CPT as potentially interested party in Autoloader and third-party usees of it. I'm not sure if the above is still applicable, or whether running MediaWiki on Windows from a network share is supported or not. If not, we should probaby document that. If we do, then the above bug seems easily fixable as described in the last comment.