Page MenuHomePhabricator

$wgServer can't be set properly with --server attribute in command line tools
Closed, ResolvedPublic

Description

Author: sergey.chernyshev

Description:
Looks like a workaround with setting $wgServer using --server attribute in command line tools like this:

$wgServer = $options['server'];

doesn't work properly for some cases like the one described for Semantic MediaWiki extension in bug 19077.

The problem is that commandLine.inc is included before $wgServer = $options['server']; can be set ($options array is generated in commandLine.inc). It means that all extensions are loaded before $wgServer is corrected.

It breaks in cases when $wgServer variable (as well as $wgServerName) are used during original include of the extension code (which happens through commandLine.inc). In most cases it works as majority of extensions use $wgServer/$wgServerName only in hooks or in any post-init function calls, but it will break for all extensions that use it in original include.

Will appreciate any feedback on this bug and possible workarounds for specific case of bug 18007 for Semantic MediaWiki (e.g. any way to "late bind" $wgServer / $wgServerName).


Version: unspecified
Severity: enhancement

Details

Reference
bz19593

Event Timeline

bzimport raised the priority of this task from to Medium.Nov 21 2014, 10:42 PM
bzimport set Reference to bz19593.
bzimport added a subscriber: Unknown Object (MLST).

sergey.chernyshev wrote:

Sorry, mentioning of bug 18007 is incorrect - should be same bug 19077 instead...

demon added a comment.Jul 9 2009, 12:30 AM

Could be worth tagging for cleanup in the maintenance-work branch.

tagging for cleanup

I added "blocks bug 19133"

Noting inconsistent use of --server, just in case one day somebody
wants to unify them:

maintenance/generateSitemap.php:481: --server=<server> The protocol and server name to use in URLs, e.g.
maintenance/dumpBackup.php:87: --server=h Force reading from MySQL server h
maintenance/dumpTextPass.php:518: --server=h Force reading from MySQL server h

All I know is in
http://www.mediawiki.org/wiki/Manual:Wiki_family#Ultimate_minimalist_solution
I set $wgServer in LocalSettings.php.

sergey.chernyshev wrote:

Hmm. Maybe it's worth setting $wgServer and $wgServerName in AdminSettings.php so command line scripts catch them properly. I'll check if those will work on my test case-wiki.

demon added a comment.Jul 11 2009, 6:37 PM

Ew ew no. Nothing should use AdminSettings ever again.

sergey.chernyshev wrote:

OK, setting $wgServer and $wgServerName in AdminSettings.php doesn't work, but setting them in LocalSettings.php above extension includes works (not very surprising).

Not sure if this is the right approach as it enforces users to set their hostname in LocalSettings.php (partially, that's what I'm trying to avoid).

I wonder if there is any better way to do this.

See also bug 9675.

OK, using

$ echo 'var_dump(get_defined_vars());'|php maintenance/eval.php|grep -B 1 localhost

I have now perfected the

if($wgServerName=='localhost'){$wgServer=$wgInternalServer=$wgProto.'://'.($wgServerName=$site[1]);}#for maintenance scripts

I use in
http://www.mediawiki.org/wiki/Manual:Wiki_family#Ultimate_minimalist_solution

I bet there is no general solution for a maintenance
script to determine the sitename.

sergey.chernyshev wrote:

Yes, this is understandable as CLI environment has no idea which virtual host we're working on, but is there any way for scripts to set the value earlier in the game so they work or setting the value in LocalSettings.php is the only way?

Essentially, this means that setup script at /config/ should be writing $wgServer and $wgServerName value into the LocalSettings.php during initial setup.

(In reply to comment #8)

Essentially, this means that setup script at /config/ should be writing
$wgServer and $wgServerName value into the LocalSettings.php during initial
setup.

Indeed, otherwise MediaWiki is guilty of negligence.

And the certainly always wrong "localhost" guess in
DefaultSettings.php should instead be a die(), with message "Unable to
determine server name, please specify in LocalSetting.php, mainly for
maintenance scripts", as any function that actually ends up using this
wrong "localhost" value will do something bad.

Hmmm, perhaps open a new bug with Component: Installation...

demon added a comment.Jul 13 2009, 1:57 PM

No, we don't need a new bug. Nor do we need to die when the server name is localhost (that breaks a good number of dev setups!).

I kind of like the idea of finding/setting this at config-time, rather than trying to rely on potentially broken $_SERVER values which are almost always wrong when running PHP from the command line. Also, going to add a --server param to the maintenance-work branch, for manual overriding as needed.

sergey.chernyshev wrote:

Is it possible to add --server to work early in execution path so it works before all the extensions are included?

More over, is it possible for it to set $wgServerName as well (it's kind of stupid that we set $wgServer to http://www.example.com/ and don't set $wgServerName to www.example.com)?

demon added a comment.Jul 13 2009, 3:20 PM

(In reply to comment #11)

Is it possible to add --server to work early in execution path so it works
before all the extensions are included?

Yes. All of the arguments in $argv are processed prior to setting up a MW environment, so this is pretty easy. We do this already so we can override core DB settings with command line arguments (note: this is only in the branch, not true in trunk yet).

More over, is it possible for it to set $wgServerName as well (it's kind of
stupid that we set $wgServer to http://www.example.com/ and don't set
$wgServerName to www.example.com)?

See bug 8866.

demon added a comment.Mar 15 2010, 9:35 AM

(In reply to comment #10)

I kind of like the idea of finding/setting this at config-time...

Actually, I don't like this anymore. See bug 61 comment 10.

We note:

  • Removed $wgServerName. It doesn't need to be set anymore and is no longer available as input for other configuration items, either.

OK, I'll comment out

if($wgServerName=='localhost'){$wgServer=$wgInternalServer=$wgProto.'://'.($wgServerName=$site[1]);}#for maintenance scripts

from my LocalSettings.php. Hope nothing breaks.

OK, I'll now use

#for maintenance scripts here on our Wiki Family https://bugzilla.wikimedia.org/show_bug.cgi?id=19593#c14 :
if($wgServer=='http://localhost'){$wgServer=$wgInternalServer=$wgProto.'://'.($wgServerName=$site[1]);}

and update http://www.mediawiki.org/wiki/Manual:Wiki_family

demon added a comment.Oct 29 2010, 4:34 PM

Done in r75650.

(In reply to comment #11)

Is it possible to add --server to work early in execution path so it works
before all the extensions are included?

There were two choices here. One was doing it before LocalSettings.php is included (and thus extensions). But if it indeed was set in LocalSettings.php, it would override what we set with --server, which is unintuitive. The other was putting it after (which I did), which means extensions are stuck with using the bad $wgServer if they must use it in their included file.