Last modified: 2010-05-15 16:03:28 UTC

Wikimedia Bugzilla is closed!

Wikimedia migrated from Bugzilla to Phabricator. Bug reports are handled in Wikimedia Phabricator.
This static website is read-only and for historical purposes. It is not possible to log in and except for displaying bug reports and their history, links might be broken. See T17618, the corresponding Phabricator task for complete and up-to-date bug report information.
Bug 15618 - parser returns without generating output
parser returns without generating output
Status: RESOLVED FIXED
Product: MediaWiki
Classification: Unclassified
Parser (Other open bugs)
1.13.x
PC Linux
: Normal major (vote)
: ---
Assigned To: Nobody - You can work on this!
: parser
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2008-09-16 03:53 UTC by Ken Yap
Modified: 2010-05-15 16:03 UTC (History)
1 user (show)

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


Attachments

Description Ken Yap 2008-09-16 03:53:47 UTC
I'm using the parser standalone to parse Wiki text to be stored into a string and then sent via AJAX to an iframe. The code is running in the context of a Mediawiki as an extension. I have found that the parser returns prematurely without generating any output when I call $wgOut->parse().

I have traced it to these lines in formatHeaders in Parser.php. When I comment these lines out, the parser works without returning prematurely.

if( !$this->mTitle->quickUserCan( 'edit' ) ) {
 $showEditLink = 0;
} else {
 $showEditLink = $this->mOptions->getEditSection();
}

Is there a problem with quickUserCan? Is mTitle not initialised properly when I use the parser standalone?

This did not happen in 1.12 so I think it is something new in 1.13.
Comment 1 Niklas Laxström 2008-09-18 17:18:15 UTC
Are you sure it doesn't throw any errors or warnings? Also, Bugzilla is not a good place to get development help.
Comment 2 Ken Yap 2008-09-18 17:37:32 UTC
No, it exits the program at that point, as any echo statements placed after that point do not execute and generate output. Apache error_log shows nothing amiss. access_log shows a transfer of 0 bytes. I ought to turn on more debugging options in PHP.

I don't need development help, I've worked around the problem by commenting those lines out which don't appear to do anything useful for me. I'm just very surprised that a PHP program can exit just like that without any error messages in the log or a 500 error to the client, but perhaps mediawiki is trapping those errors, or I don't know PHP well enough.
Comment 3 Niklas Laxström 2008-09-18 17:40:47 UTC
Well, try to get php log enabled or otherwise enable error reporting. I'm guessing it just dies with a fatal php error, possibly because of the reason you guessed.
Comment 4 Ken Yap 2008-09-18 17:55:09 UTC
Ok, will do that next week when I encounter this system again.
Comment 5 Ken Yap 2008-09-29 03:07:28 UTC
Ok, this appears to be a PHP problem. I upgraded to PHP5.2 and it works fine now.

The reason I was at PHP5.1 is because I have to use RHEL5 and the version of PHP supplied is PHP5.1. It took a while for me to locate some suitable PHP5.2 packages to install.

You might want to document somewhere that Mediawiki 1.13.1 requires PHP5.2 now.

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


Navigation
Links