Topic on Help talk:Extension:Translate

Special page Special:SupportedLanguages php error

9
Hutchy68 (talkcontribs)

Hi

I'm scratching my head on this php error being thrown on Special:SupportedLanguages. The page works fine on my local. Using the same extension configurations setup on production server. MW 1.21.5, latest same language bundle on local and production server.

Warning: array_merge() expects at least 1 parameter, 0 given in /home/server/public_html/extensions/Translate/specials/SpecialSupportedLanguages.php on line 96

Warning: array_keys() expects parameter 1 to be array, null given in /home/server/public_html/extensions/Translate/specials/SpecialSupportedLanguages.php on line 96

Warning: Invalid argument supplied for foreach() in /home/server/public_html/extensions/Translate/specials/SpecialSupportedLanguages.php on line 364

Notice: Undefined variable: keys in /home/server/public_html/extensions/Translate/specials/SpecialSupportedLanguages.php on line 368

Catchable fatal error: Argument 1 passed to SqlBagOStuff::getMulti() must be of the type array, null given, called in /home/server/public_html/extensions/Translate/specials/SpecialSupportedLanguages.php on line 368 and defined in /home/server/public_html/includes/objectcache/SqlBagOStuff.php on line 212

A hint at what to look at or for greatly appreciated. Obviously I have something different, but what? Running same exact extensions on both local and production server. Everything else is working great. Thanks!

Nikerabbit (talkcontribs)

There is condition just before line 96 in the code, so I don't know.

Hutchy68 (talkcontribs)

Yes, pulling in user information. RC's from looking at the code? User contribs? I wonder if I rebuild the RC table if that would fix it? I did do a rebuildall when I upgraded after I ran update.php. Thoughts? Thanks

Hutchy68 (talkcontribs)

Hi Nikerabbit, still no joy, the page still has a fatal error. I rebuilt RC's, checked the User table, still failing array_merge and array_keys. Debugging log turned on and it shows nothing for this Special Page. Do you have any suggestions on how to debug this? Thanks.

Nikerabbit (talkcontribs)

In these cases I start adding manual debugging statements in the code until I understand what is going on.

Hutchy68 (talkcontribs)

Thanks Nikerabbit, on a live site so I don't usually like "live debugging" but did it anyway. Seems as if this statement is the issue.

if ( !defined( 'NS_PORTAL' ) ) {
	$users = $this->fetchTranslatorsAuto();
	} else {
	$users = $this->fetchTranslatorsPortal( $natives );
}

We have NS_PORTAL defined. Funny thing is, I comment out the if statement and use either or to define $users.

	$users = $this->fetchTranslatorsAuto();

or

	$users = $this->fetchTranslatorsPortal( $natives );

The page works, but the heading of languages is doubled at the top.

dansk български español Bahasa Indonesia français English فارسی Nederlands

then

español Bahasa Indonesia فارسی dansk English български français Nederlands

Even though the languages are in a different order, any of them link to the page's anchors for the language headings.

Also, all users are wrapped in a <del> tag so they look like this, username. Not sure why they are doing that either.

Thanks for your help.

Nikerabbit (talkcontribs)

That makes sense. We were supposed to get rid of the NS_PORTAL strategy, which would fix the error for you as well. The double list of languages can be just a byproduct of the heavy caching of the page with your debugging output.

Hutchy68 (talkcontribs)

Which $users statement is better? I guess we have a Portal namespace, which we eventually use for the languages. Low on my list. Ideas why the <del> tags are showing up?

Hutchy68 (talkcontribs)

Ok, I have it 1/2 working. I like the page and concept. It is very cool, with great feedback for translation admins or anyone interested. The view is buggy though. Commented out the PORTAL_NS check, just wouldn't work on server. Strike through on the page, every single user under every heading. Call the action=purge and it works for awhile until the cache time expires. Then back to a strike through for every single user again. Buggy. Is this a known bug or should I file one?

Reply to "Special page Special:SupportedLanguages php error"