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 ... :)

[ghost]

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?

[ghost]

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.

[artemklevtsov]

This workground does not work on the my wiki.
I set in LocalSettings.php
$wgScriptPath = "";
$wgServer = "http://psylab.info";
$wgArticlePath = "/$1";
$wgUsePathInfo = true;
and in Collection.body.php under 1030-1031 rows:
#'base_url' => wfExpandUrl( $wgScriptPath, PROTO_CURRENT ),
'base_url' => empty($wgScriptPath) ? $wgServer : wfExpandUrl( $wgScriptPath, PROTO_CURRENT ),
Mediawiki: 19.1 (git branch);
Collection: 1.6.1 (latest git version);
URL: http://psylab.info

[l13t]

this workground does not work for me too.
i've found solution that help me.

LocalSettings.php:
$wgScriptPath = "";
$wgServer = "http://wiki.***.";

Collection.body.php:
/'base_url' => wfExpandUrl( $wgScriptPath, PROTO_CURRENT ),/
'base_url' => "http://wiki.***.",

MediaWiki 1.20alpha (e41e273)
Collection (Version 1.6.1) (8bb822c)
PHP 5.3.10-1ubuntu3.2

Updated:
Also this solution worked for me on:
freebsd
MediaWiki 1.19.0
PHP 5.4.4
Collection (Version 1.6.1)

mediawiki & collection were downloaded from site. not from git.

[ghost]

Tried the workaround posted by I13t above. I was able to generate a PDF document using this method, however the "Rendering" and "Rendering finished" pages displayed all their respective HTML tags instead of actually using the markup to format the page.

I would post an example but github uses the HTML tags if I copy/paste them.

Edit:
MediaWiki 1.19.2
PHP: 5.3.8
MySQL: 5.5.16
Collection: 1.6.1

[larspohlmann]

For everyone who couldn't make the workaround work, don't forget this:

to use this workaround you have to make the $wgServer global

To do this, go to the beginning of the function renderCollection in Collection.body.php and add $wgServer to the list of global variables.

[j0lly]

I would like to add a further more step:
If you have $wgserver set as relative-url like //example.com
The above situation will fail.
Instead, use the $wgCanonicalServer variable; by default it takes $wgserver value but expand it in HTTP if a relative-url is porvided (set it at https:// if you need the other situation).

[scmc]

This issue seemed to occur after our upgrade to 19.4 ? Was working fine previously. Not sure what the issue is.

I have the fix above implemented still not working.

error occurred on the render server: RuntimeError: RuntimeError: command failed with returncode 256: ['mw-zip', '-o', '/home/pp/cache/08/08dba64a84c4d0ac/collection.zip', '-m', '/home/pp/cache/08/08dba64a84c4d0ac/metabook.json', '--status', 'qserve://localhost:14311/08dba64a84c4d0ac:makezip',

....

[juhi24]

codedaves solution helped me forward and now experiencing the 1% problem. Is there a fix for that also?

[benmadin]

Thanks @tierra for fixing this - it has caused us plenty of grief! cheers Ben

[tierra]

Don't cheers me just yet, that fix works, but it's not actually applied to MediaWiki yet.

I have a patch in review on Gerrit for this that has changed a bit from the solution in my commit referenced above (but does still accomplish the same fix):
https://gerrit.wikimedia.org/r/#/c/87293/

[tierra]

Oh, and also check out this patch for core too (as it attempts to fix this problem with the core wfExpandUrl() method:
https://gerrit.wikimedia.org/r/#/c/87482/

[cs6bps]

Hi,

I know this thread is quite old but, like scmc, I encountered this "RuntimeError: command failed with returncode 256" problem and none of the suggested fixes worked for me. Just in case anyone else has the same issue still, I thought I'd post my solution.

I'm running a private render server on the same server as our Wiki.
CentOS 6.5 x64
MediaWiki 1.22.6
PHP 5.3.3
MySQL 5.1.73
Collection Version 1.6.1

The first step is to ensure SELINUX is disabled. If it was not, the curl_exec($ch) didn't work for me (and I couldn't figure out how to make it work with SELinux).

The second step is to edit

$IP/extensions/Collection/Collection.body.php

In the function

static function mwServeCommand( $command, $args ) {

Replace

$serveURL = $wgCollectionMWServeURL;

with

$serveURL = 'myservername:8899/';

For me, this got rid of the "RuntimeError: command failed with returncode 256" error as it seems that, regardless of what is set in LocalSettings.php, $wgCollectionMWServeURL was being set to pediapress. However, I was then left with the "The POST request to server:8899/ failed ($2)" error. I fixed this by replacing

$response = Http::post($serveURL, array('postData' => $args));

with

$boundary = '--myboundary-bps';
$retval= '';
foreach($args as $key => $value){
    $retval .= "--$boundary\nContent-Disposition: form-data; name=\"$key\"\n\n$value\n";
}
$retval .= "--$boundary--";
$body = $retval;
$ch = curl_init();
curl_setopt($ch, CURLOPT_HTTPHEADER, array("Content-Type: multipart/form-data; boundary=$boundary"));
curl_setopt($ch, CURLOPT_URL, $serveURL);
curl_setopt($ch, CURLOPT_POST, true);
curl_setopt($ch, CURLOPT_POSTFIELDS, $body);
curl_setopt($ch, CURLOPT_RETURNTRANSFER, true );
$response = curl_exec($ch);

I got the code from this site and tweaked it
http://scraperblog.blogspot.co.uk/2013/07/php-curl-multipart-form-posting.html

[rodsmr]

What is the best practise to resolve this issue? I read and I tried all the solution on this page but they didn't function. Can someone help me?

I use: MediaWiki 1.27.0 on Apache/2.4.10 with Debian OS and PHP PHP 5.6.24-0+deb8u1

[saper]

This bug should actually be fixed already

[rodsmr]

@saper What is the solution? How can I implement it?

[saper]

What error are you getting? What is in the debug log?