Last modified: 2013-12-19 22:28:28 UTC
Observed in translatewiki.net production. Use case and impact currently unknown. PHP Warning: Parameter 1 to Language::findVariantLink() expected to be a reference, value given in includes/StubObject.php on line 79
Some background info: Has been observed once on given site. Last code update to master for core and extensions was about 15 minutes before the issue was logged (17-Apr-2013 20:27:45 UTC). The updated code was about 2 days worth.
Simple repro: $ php maintenance/eval.php > $l=new StubUserLang; > $n='1'; > $t=Title::newFromText($n); > $l->findVariantLink($n,$t); PHP Warning: Parameter 1 to Language::findVariantLink() expected to be a reference, value given in ./includes/StubObject.php on line 79 PHP Stack trace: PHP 1. {main}() ./maintenance/eval.php:0 PHP 2. eval() ./maintenance/eval.php:72 PHP 3. StubUserLang->findVariantLink() ./maintenance/eval.php(72) : eval()'d code:1 PHP 4. StubUserLang->__call() ./maintenance/eval.php(72) : eval()'d code:1 PHP 5. StubObject->_call() ./includes/StubObject.php:177 PHP 6. call_user_func_array() ./includes/StubObject.php:79 Warning: Parameter 1 to Language::findVariantLink() expected to be a reference, value given in ./includes/StubObject.php on line 79 Call Stack: 0.0003 236024 1. {main}() ./maintenance/eval.php:0 18.7853 8924472 2. eval('$l->findVariantLink($n,$t);;') ./maintenance/eval.php:72 18.7853 8924672 3. StubUserLang->findVariantLink() ./maintenance/eval.php(72) : eval()'d code:1 18.7853 8925112 4. StubUserLang->__call() ./maintenance/eval.php(72) : eval()'d code:1 18.7853 8925144 5. StubObject->_call() ./includes/StubObject.php:177 18.9612 10705640 6. call_user_func_array() ./includes/StubObject.php:79 >
A direct cause is that stub objects can't handle calls with references. However: 1) $wgContLang is never initialized as a stub object 2) findVariantLink() is always expected to run on $wgContLang Looks as if something is calling findVariantLink() on $wgLang or similar stuff incorrectly? A backtrace would be useful...
*** Bug 44583 has been marked as a duplicate of this bug. ***
Closing this as fixed. Not observed in a long time. The scenario from comment 2 can still be reproduced.
