Page MenuHomePhabricator

Call to a non-object when error_page used in parser hook.
Closed, InvalidPublic

Description

I have written a parser hook that adds a new tag to the markup, which in certain
situations redirects to the error page, using $wgOut->errorpage().

When this happens, I get the following error (which did not occur in 1.5.8, but
occurs in 1.9.3 and HEAD):

Fatal error: Call to a member function isCurrent() on a non-object in
includes\Skin.php on line 1259

The offending line is:

if( $this->mRevisionId && ! $wgArticle->isCurrent() ) {

and this causes an error because $wgArticle is not defined at this stage (it
contains NULL).

It can be fixed by adding a check that $wgArticle is defined, which returns the
code to its original behaviour.

This bug was introduced in r11890.


Version: 1.10.x
Severity: normal

Details

Reference
bz9739

Event Timeline

bzimport raised the priority of this task from to Medium.Nov 21 2014, 9:36 PM
bzimport set Reference to bz9739.
bzimport added a subscriber: Unknown Object (MLST).

Created attachment 3548
Patch to check $wgArticle is defined.

Patch, as described above.

Attached:

robchur wrote:

Parser hook extensions should not be touching globals such as $wgOut, $wgTitle
or $wgArticle, because parse operations can be called in situations where these
are not defined, e.g. job queue.

Then how should a parser-hook redirect to an error page?

It must not do so.

(You _might_ be able to get away with adding a header field in the parser output
object in 1.10, however I would recommend against such a thing. The concept
appears to be fundamentally flawed, and you should consider a different way of
displaying your error message -- for instance returning error text into the
page, which will not disrupt the entire wiki when you have a localized problem.)

The hook works like this: <protect>bob,john</protect> will prevent the page from
being viewable by anyone except bob and john. I am aware of the issues
regarding MW security, and how easy this is to bypass, but for my trusted
user-base a simple 'keep out' notice such as this is sufficient.

Previously it called the error page to generate a 'protected page' error
message. This works fine in 1.5.8 (and maybe higher) but is now broken. It
would be fixed by a simple check that $wgArticle is actually a valid object...

If you can suggest an alternative way to replace the entire page output (not
just the content within the tags) then that would be sufficient, however I was
under the impression that you could only modify the tag text itself. Feel free
to take this to private e-mail if this is an inappropriate place to continue the
discussion.

Pages may be rendered in batch processing or at many other times. Parsing/HTML rendering is not a UI operation, and must not attempt to manipulate the UI which may be completely unrelated.

To change page permissions, you should be hooking into the permissions system; see hooks in the Title and User classes.

Understood. I have written a new version using the userCan hook and it seems to be working well.

Thanks for taking the time to elaborate.