Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Open
dnhutchins opened this issue Dec 16, 2011 · 28 comments

Comments

Projects
None yet
@dnhutchins
Copy link

commented Dec 16, 2011

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

This comment has been minimized.

Copy link
Contributor

commented Dec 27, 2011

many thanks for tracking this down.

@jst68

This comment has been minimized.

Copy link

commented Jan 4, 2012

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

@codedave

This comment has been minimized.

Copy link

commented Jan 4, 2012

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

This comment has been minimized.

Copy link
Contributor

commented Jan 4, 2012

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

This comment has been minimized.

Copy link

commented Jan 4, 2012

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

This comment has been minimized.

Copy link
Author

commented Jan 4, 2012

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

@dnhutchins dnhutchins closed this Jan 4, 2012

@schmir schmir reopened this Jan 5, 2012

@schmir

This comment has been minimized.

Copy link
Contributor

commented Jan 5, 2012

we still need to fix that.

@saper

This comment has been minimized.

Copy link
Contributor

commented Jun 23, 2012

Also filed to Wikimedia as bug 37868.

@schmir

This comment has been minimized.

Copy link
Contributor

commented Jun 23, 2012

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

This comment has been minimized.

Copy link
Contributor

commented Jun 27, 2012

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

@ghost

This comment has been minimized.

Copy link

commented Jul 2, 2012

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

This comment has been minimized.

Copy link
Contributor

commented Jul 4, 2012

Thanks. Which MediaWiki version are you using currently?

@ghost

This comment has been minimized.

Copy link

commented Jul 6, 2012

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 comment has been minimized.

Copy link

commented Jul 15, 2012

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 comment has been minimized.

Copy link

commented Aug 2, 2012

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

This comment has been minimized.

Copy link

commented Oct 19, 2012

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

This comment has been minimized.

Copy link

commented Jan 7, 2013

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

This comment has been minimized.

Copy link

commented Jan 24, 2013

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 comment has been minimized.

Copy link

commented Apr 2, 2013

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

This comment has been minimized.

Copy link

commented Jul 6, 2013

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

@benmadin

This comment has been minimized.

Copy link

commented Oct 24, 2013

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

@tierra

This comment has been minimized.

Copy link

commented Oct 24, 2013

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

This comment has been minimized.

Copy link

commented Oct 24, 2013

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

This comment has been minimized.

Copy link

commented Jun 2, 2014

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

This comment has been minimized.

Copy link

commented Aug 23, 2016

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 comment has been minimized.

Copy link
Contributor

commented Aug 23, 2016

This bug should actually be fixed already

@rodsmr

This comment has been minimized.

Copy link

commented Sep 14, 2016

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

@saper

This comment has been minimized.

Copy link
Contributor

commented Sep 16, 2016

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.