Last modified: 2007-11-14 11:12:27 UTC
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.
Created attachment 3548 [details] Patch to check $wgArticle is defined. Patch, as described above.
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.
