Last modified: 2012-06-06 22:59:27 UTC
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.
Created attachment 9826 [details] 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).
/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...
We haven't seen anything related to that issue in SF 2.4.2 therefore I close this one.
