-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
simetrical@svn.wikimedia.org wrote:
if( $nt->equals( $wgTitle ) ) {
wfRunHooks( 'EditSectionLink', array( &$this, $nt, $section, $attribs, $url, &$result ) );
} else {
This comparison fails during API-based parsing, and perhaps at other times when $wgTitle isn't available. (Bug 14965.)
I've reverted the change for now, so parsing works again.
Fun note on PHP debugging -- I had a heck of a time tracking this problem down until I saw the bug report.
The original problem spewed errors like this to our error log:
PHP Fatal error: Call to a member function getInterwiki() on a non-object in /usr/local/apache/common-local/php-1.5/includes/Title.php on line 3005
that tells us that something is calling Title::equals() with a null parameter, but not what.
I tried slipping in a check for null and throwing an exception, which should be logged with more details.... but the exception didn't get logged!
Once I found the bug report with the same error in it I was able to reproduce it locally with a copy of the parsed page, and could track it down...
So two fun lessions:
1) I found that I could get useful error messages by adding a type hint to Title::equals():
PHP Catchable fatal error: Argument 1 passed to Title::equals() must be an instance of Title, null given, called in /usr/local/apache/common-local/php-1.5/includes/Linker.php on line 1323 and defined in /usr/local/apache/common-local/php-1.5/includes/Title.php on line 3003
This error now tells me *who called* the function with the bad parameter, which is much more useful!
2) The separate exception handling paths in the API and the general UI can cause trouble, as here where exceptions aren't being logged via wfDebugLog().
Should be an easy fix, but it's the kind of thing we should avoid -- separate code paths for the same thing tend to lead to divergent behavior.
- -- brion