Issue with the base_url variable not getting passed when $wgScriptPath is empty

[dnhutchins]

When mediawiki is configured and running from the top directory of the web server using the following variables:

$wgServer = "http://www.example.com"; # whatever the real site name is
$wgScriptPath = ""; # empty for serving the wiki from / on the server

Where wgScriptPath is empty and all scripts are in the root directory of the server, base_url does not get set in Collection.body.php when being set via wfExpandUrl( $wgScriptPath, PROTO_CURRENT ). Simply moving all the wiki files into one directory deeper and setting wgScriptPath to the new directory confirms this behavior.

[schmir]

many thanks for tracking this down.

[jst68]

We encountered the same issue. Is there an update for this? It stalls our current installation efforts.

[codedave]

instead of copying the files into an created directory i used following workaround:

'base_url' => empty($wgScriptPath) ? $wgServer : wfExpandUrl( $wgScriptPath, PROTO_CURRENT )

to use this workaround you have to make the $wgServer variable global and make sure that it does not ends with an "/"

@edit - i use this workaround only in the function renderCollectionat the moment (Collection.body.php)

[schmir]

Please use the workaround as suggested by codedave at the moment.

The mediawiki developers change the internal mediawiki API in ways which make it hard to make the collection extension work with multiple mediawiki versions. We'll provide a fix in the current trunk version but you'll have wait for the next mediawiki release in order to use that. Given that mediawiki and the collection extension is managed in a subversion repository with a rather bizarre layout there's not much hope for the fix being backported.

It's a shame and I'm really sorry about that. I'm not quite sure if it makes sense to discuss the issue with the mediawiki developers, but I consider doing that.

Besides I should learn some PHP and get commit rights :)

[jst68]

Thanks codedave and schmir!

codedave's solution moved us forward. We are now encountering the 1% issue... ;)

schmir, it seems that having issues with a core field like base_url should be a big thing for both mediawiki and collection developers to work out. It is hard to imagine that this doesn't affect other extensions as well. I also think it is quite common to install something in the root directory rather than using a sub directory.

Anyhow, I appreciate both of you taking the time to reply to me! :)

[dnhutchins]

Yep, that works great for me. Thanks for the work!

[schmir]

we still need to fix that.

[saper]

Also filed to Wikimedia as bug 37868.

[schmir]

I have zero motivation to fix that bug given the overhead of going through gerrit.

@saper: Do you care enough to fix this? I'll make sure you'll receive a coupon for a pediapress book.

[saper]

Will have a look. I have some books from PP already and well ... :)

The workaround provided by codedave does not seem to resolve this issue for us. Just to confirm I have done the steps of the workaround correctly:

1.Set $wgServer to global in LocalSettings.php and ensure the value does not end in a "/" character.

2.Add the line 'base_url' => empty($wgScriptPath) ? $wgServer : wfExpandUrl( $wgScriptPath, PROTO_CURRENT ), to Collection.body.php in the function renderCollection($collection, $referrer, $writer) within the section $response = self::mwServeCommand( 'render', array(

3.Comment out the line 'base_url' => wfExpandUrl( $wgScriptPath, PROTO_CURRENT ), in the same function. Note that I also tried it without commenting out that line.

If I have made a mistake in implementing this workaround, please let me know. Otherwise my organization cannot move forward with upgrading to a newer mediawiki until this is resolved.

[saper]

Thanks. Which MediaWiki version are you using currently?

Currently using 1.15.1 where the rendering is working correctly. The upgrade is to 1.18, tested on 1.18.1 and 1.18.4, same results either way.