Last modified: 2010-11-10 23:50:53 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).
Sorry, mentioning of bug 18007 is incorrect - should be same bug 19077 instead...
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.
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.
Ew ew no. Nothing should use AdminSettings ever again.
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.
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...
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.
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)?
(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.
(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
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.
