Last modified: 2010-05-15 15:41:05 UTC

Wikimedia Bugzilla is closed!

Wikimedia has migrated from Bugzilla to Phabricator. Bug reports should be created and updated in Wikimedia Phabricator instead. Please create an account in Phabricator and add your Bugzilla email address to it.
Wikimedia Bugzilla is read-only. If you try to edit or create any bug report in Bugzilla you will be shown an intentional error message.
In order to access the Phabricator task corresponding to a Bugzilla report, just remove "static-" from its URL.
You could still run searches in Bugzilla or access your list of votes but bug reports will obviously not be up-to-date in Bugzilla.
Bug 6772 - Undefined Index error in SpecialSpecialpages.php
Undefined Index error in SpecialSpecialpages.php
Status: RESOLVED INVALID
Product: MediaWiki
Classification: Unclassified
Special pages (Other open bugs)
1.7.x
PC Linux
: Normal normal (vote)
: ---
Assigned To: Nobody - You can work on this!
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2006-07-21 21:15 UTC by mfreemon
Modified: 2010-05-15 15:41 UTC (History)
2 users (show)

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


Attachments

Description mfreemon 2006-07-21 21:15:49 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
Comment 1 netocrat 2006-07-24 14:43:43 UTC
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.
Comment 2 DeWitt Clinton 2006-08-10 17:40:08 UTC
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

Comment 3 Rob Church 2006-12-21 19:06:59 UTC
Upstream bug fixed; closing.

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


Navigation
Links