Last modified: 2010-05-15 15:41:05 UTC
I have noticed as well. I do not have a good explanation, but this patch seems to fix it. [root@ncassr includes]# diff /root/mediawiki-1.7.1/includes/SpecialSpecialpages.php /var/www/mediawiki- 1.7.1/includes/SpecialSpecialpages.php 21c21 < wfSpecialSpecialpages_gen($pages[''],'spheading',$sk); --- > wfSpecialSpecialpages_gen($pages[NULL],'spheading',$sk); Fedora Core 5 MediaWiki 1.7.1 PHP 5.1.4 Zend 2.1.0 eAccelerator 0.9.5-beta2 - Mike ************************************** Michael Roach michael.roach at us.lawson.com Mon Jun 5 18:42:09 UTC 2006 Since upgrading to 1.6.6 I've noticed a problem with Special:Specialpages not rendering completely. Specifically, the page title and 'Restricted special pages' section are always present but I have to bang on the refresh button to get the 'Special pages for all users' section to show up. Note that this section is completely missing from the source. Also note that it doesn't make a difference under different accounts (except of course to determine if the Restricted special pages are shown). The problem happens the same under Firefox and IE. Except for my own templates, I have not made any code changes to the base install and the problem persists after disabling all parser addons. Has anyone else encountered this? Thanks, Michael
You could also try: $allPages = $pages['']; foreach ($pages as $key => $val) { if ($key == '' && count($val) > 0) { $allPages = $val; } } /** Pages available to all */ wfSpecialSpecialpages_gen($allPages,'spheading',$sk); I've been noticing this as an intermittent problem for a while now too. It's occurring on two machines each running two separate MediaWiki versions; the problem occurs under all configurations. Occasionally apache segfaults and the page does not display at all. Host1: PowerPC, PHP 5.1.4-pl4-gentoo and eAccelerator 0.9.5_beta2(?); MediaWiki 1.6.7 and 1.6.6. Host2: Intel P4, PHP 5.1.2-gentoo and eAccelerator 0.9.5_beta2; MediaWiki 1.6.5 and 1.5.6. Debug code shows that the $pages array returned by SpecialPage::getPages() when printed with var_export() occasionally has an extra key=>element prepended, which prints as e.g. ':ey' => array ( ), but that this key (most of the time) actually compares equal to ''. i.e. using a foreach() loop will show two '' keys - that of this extra empty element and that of the "real" non-empty array. This extra element is the one that's being picked for $pages[''] - it's not that the real '' key doesn't exist, it's just that the imposter occurs first. Sometimes though, this extra element shows up in neither a var_export() nor a foreach() iteration even when $pages[''] evaluates to an empty array. Other information: when I added debug code for type-comparison, the imposter's key compared type-equal - i.e. using an === comparison - with '' but NOT with null. Some key strings other than ':ey' that I've seen so far: 'ðame', 'mey', 'Ley', '!ey', ' ey', '/ey', 'Pey', 'rey'. For at least the '/ey' key string, the value of $pages[''] was its "normal" non-empty array although I can't confirm whether that key string compared equal to '' as I didn't have that debug code in place at that point. It seems likely that this is a problem of MediaWiki's only indirectly, and that it's more directly a PHP or possibly an eAccelerator problem.
I've been seeing the same problem, also with eAccelerator enabled. And thank you, replacing the literal empty string '' with NULL did avoid the problem. However, I believe the real bug may be this one in eAccelerator: http://eaccelerator.net/ticket/63 That bug is apparently fixed in 0.9.5-rc1. If you are stuck on an earlier version, one workaround proposed is to set the following in eaccelerator.ini: eaccelerator.shm_only = 1
Upstream bug fixed; closing.
