Last modified: 2010-11-10 23:50:53 UTC

Wikimedia Bugzilla is closed!

Wikimedia migrated from Bugzilla to Phabricator. Bug reports are handled in Wikimedia Phabricator.
This static website is read-only and for historical purposes. It is not possible to log in and except for displaying bug reports and their history, links might be broken. See T21593, the corresponding Phabricator task for complete and up-to-date bug report information.
Bug 19593 - $wgServer can't be set properly with --server attribute in command line tools
$wgServer can't be set properly with --server attribute in command line tools
Status: RESOLVED FIXED
Product: MediaWiki
Classification: Unclassified
Maintenance scripts (Other open bugs)
unspecified
All All
: Normal enhancement with 1 vote (vote)
: ---
Assigned To: Nobody - You can work on this!
:
Depends on: 8866
Blocks: 19077 19133
  Show dependency treegraph
 
Reported: 2009-07-08 14:55 UTC by Sergey Chernyshev
Modified: 2010-11-10 23:50 UTC (History)
2 users (show)

See Also:
Web browser: ---
Mobile Platform: ---
Assignee Huggle Beta Tester: ---


Attachments

Description Sergey Chernyshev 2009-07-08 14:55:48 UTC
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).
Comment 1 Sergey Chernyshev 2009-07-08 14:56:56 UTC
Sorry, mentioning of bug 18007 is incorrect - should be same bug 19077 instead...
Comment 2 Chad H. 2009-07-09 00:30:31 UTC
Could be worth tagging for cleanup in the maintenance-work branch.
Comment 3 Dan Jacobson 2009-07-10 19:41:35 UTC
>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.
Comment 4 Sergey Chernyshev 2009-07-11 18:29:28 UTC
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.
Comment 5 Chad H. 2009-07-11 18:37:04 UTC
Ew ew no. Nothing should use AdminSettings ever again.
Comment 6 Sergey Chernyshev 2009-07-11 18:39:31 UTC
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.
Comment 7 Dan Jacobson 2009-07-12 19:15:03 UTC
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.
Comment 8 Sergey Chernyshev 2009-07-13 01:13:39 UTC
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.

Comment 9 Dan Jacobson 2009-07-13 13:53:28 UTC
(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...
Comment 10 Chad H. 2009-07-13 13:57:37 UTC
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.
Comment 11 Sergey Chernyshev 2009-07-13 15:15:17 UTC
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)?


Comment 12 Chad H. 2009-07-13 15:20:16 UTC
(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.
Comment 13 Chad H. 2010-03-15 09:35:27 UTC
(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.
Comment 14 Dan Jacobson 2010-10-17 02:52:25 UTC
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.
Comment 15 Dan Jacobson 2010-10-17 03:19:33 UTC
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
Comment 16 Chad H. 2010-10-29 16:34:20 UTC
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.

Note You need to log in before you can comment on or make changes to this bug.


Navigation
Links