Page MenuHomePhabricator

SF_RunQuery.php: Argument 3 passed to Parser::parse() must be an instance of ParserOptions, null given
Closed, ResolvedPublic

Description

We found a small glitch with the current revision 10778 of
SF_RunQuery.php which generates an error on

Catchable fatal error: Argument 3 passed to Parser::parse() must be an
instance of ParserOptions, null given, called in
D:\xampp\htdocs\aris\extensions\SemanticForms\specials\SF_RunQuery.php
on line 105 and defined in
D:\xampp\htdocs\aris\includes\parser\Parser.php on line 313

We switched to MW 1.18 together with SMW 1.7 any of our 30 RunQuery
forms run into the same problem either called via Special:RunQuery or
as url based service with wpRunQuery=true.

It seems that in MW 1.18, $wgParser->mOptions expects an array instead
of a string which causes the fatal error.


Version: unspecified
Severity: normal

Details

Reference
bz33606

Event Timeline

bzimport raised the priority of this task from to Needs Triage.Nov 22 2014, 12:03 AM
bzimport set Reference to bz33606.

Created attachment 9826
Patch by James Hong Kong

JHK: Since I needed it to work, with current SVN trunk I did a quick fix,
which works fine as far I can see but you are the experts. It is just
one line (see patch).

Attached:

/confused

You assigned this to yourself? :)

Small remark: why not just pass in the PO object as argument instead of messing with wgParser?

(In reply to comment #2)

You assigned this to yourself? :)

Small remark: why not just pass in the PO object as argument instead of messing
with wgParser?

Yes, assigned it to myself. The bug is the result of an email exchange between James, Yaron and me. I put it in here to not forget about it.

I did not look at it yet, so can not say anything about it. If you want to fix it, go ahead.

That parameter will actually set $wgParser->mOptions, but it's hard to find the right way to deal with the parser. Not pretty, but would work ok.

However, I fail to see how you may be arriving to that line with a null $wgParser->mOptions, since it is set in line 85 with the same condition (why is that split in two ifs??), and ParserOptions::newFromUser can't return null.

Did you have any customization to that file?

PS: I hope you missed a digit, r10778 is from 2005 (the patch is from r108114, which is much saner :) ).

Can this bug report be closed? It seems to no longer be valid...

Unknown Object (User) added a comment.Jun 6 2012, 10:59 PM

We haven't seen anything related to that issue in SF 2.4.2 therefore I close this one.