Re: [Wikitech-l] Fatal exception when calling replaceVariables() from parser hook, after upgrade to MW 1.34

[Bryan Davis]

On Mon, Jan 18, 2021 at 7:46 AM Mark Clements (HappyDog)
 wrote:
>
> Thanks, Máté,  That's helpful.
>
> What is the most appropriate way to reach-out to the Parsing Team?  I had
> assumed it would be via this list, but no-one else has responded to my
> question, so I guess not.
>
> The method that I am using is based on what I was told to do for the
> previous parser implementation.  It would be useful if there were some
> migration documentation to help extension developers migrate to the new
> implementation.  Is that on the roadmap, somewhere?

See  and
. There is
also a bit of explanation about the changes at
<
along with a link to a tech talk that Subbu gave on the topic.

Bryan
-- 
Bryan Davis  Technical Engagement  Wikimedia Foundation
Principal Software Engineer   Boise, ID USA
[[m:User:BDavis_(WMF)]]  irc: bd808

___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Fatal exception when calling replaceVariables() from parser hook, after upgrade to MW 1.34

[Mark Clements (HappyDog)]

Thanks, Máté,  That's helpful.

What is the most appropriate way to reach-out to the Parsing Team?  I had 
assumed it would be via this list, but no-one else has responded to my 
question, so I guess not.

The method that I am using is based on what I was told to do for the 
previous parser implementation.  It would be useful if there were some 
migration documentation to help extension developers migrate to the new 
implementation.  Is that on the roadmap, somewhere?

Kind regards,

- Mark Clements (HappyDog)


"Máté Szabó"  wrote in message 
news:80e88bac-ae9b-42ae-a0ba-834a39a7a...@wikia-inc.com...
> Hi,
>
> The DOM-based wikitext preprocessor (Preprocessor_DOM class and friends) 
> was deprecated in MediaWiki 1.34 and removed in MediaWiki 1.35 as part of 
> the Wikimedia Parsing Team's work around Parsoid-PHP.[1]
> In the short/medium term, the easiest fix to keep your code working would 
> be to use the other preprocessor implementation (class Preprocessor_Hash 
> and friends) instead.
> Since your code already has access to a PPFrame instance, you can also try 
> invoking its newChild() method to construct a new child frame with your 
> arguments, instead of creating the instance directly.
>
> In the long term, the legacy wikitext preprocessor will be removed, so you 
> may want to reach out to the Parsing Team[2] to find out how you can make 
> your code ready for Parsoid-PHP.
>
> Hope this helps.
>
> -
> [1] https://phabricator.wikimedia.org/T204945
> [2] https://www.mediawiki.org/wiki/Parsing
>
> Best,
> Máté Szabó
> Sr. Software Engineer
> he - him - his
>
> Fandom Poland sp. z o.o. z siedziba w Poznaniu, ul. Abp. A. Baraniaka 6
> Sad Rejonowy Poznan - Nowe Miasto i Wilda w Poznaniu, VIII Wydzial 
> Gospodarczy Krajowego Rejestru Sadowego, KRS 254365
> NIP: 5252358778
> Kapital zakladowy: 50.000,00 zlotych
>
>> On 29 Dec 2020, at 12:48, Mark Clements (HappyDog)  
>> wrote:
>>
>> Hi there,
>>
>> I am investigating a breakage in my extension that has occurred in MW 
>> 1.34
>> but which didn't seem to be a problem on MW 1.29.  (I have not tested
>> interim versions to see where the issue first arises.)
>>
>> One of the parser hooks in the extension needs to perform variable
>> expansion.  What is happening is a lot more complicated than this 
>> example,
>> but effectively
>>
>>   {{{Foo}}}
>>
>> should end up generating the following output, using variable expansion:
>>
>>What the foo!
>>
>> The semantics of variable handling need to follow the MW semantics,
>> including default values (possibly nested), parser functions, etc. 
>> therefore
>> it needs to use the MW parser to perform the expansion.
>>
>> Assuming the arguments that MW passes into the parser hook are named 
>> $Text,
>> $Vars, $Parser and $Frame, the relevant code looks something like this
>> (again, a bit more complicated in practice):
>>
>>$NewFrame = new PPTemplateFrame_DOM($Frame->preprocessor, $Frame,
>>array(), $Vars, $Frame->title);
>>return $Parser->replaceVariables($Text, $NewFrame);
>>
>>
>> (I have included a more detailed listing of the code that I am using for
>> doing the parse at the end of this message.)
>>
>> My code was working fine on MW 1.29 and earlier, but when I upgrade to 
>> 1.34
>> I am finding that I get a fatal exception thrown when my tag is 
>> encountered:
>>
>>/index.php?title=Main_Page MWException
>>from line 373 of ~\includes\parser\PPFrame_DOM.php:
>>PPFrame_DOM::expand: Invalid parameter type
>>
>> I have generated a backtrace and the top of the stack is as follows:
>>
>> #0 ~\includes\parser\Parser.php(3330): 
>> PPFrame_DOM->expand(PPNode_Hash_Tree,
>> integer)
>> #1 MyExtension.php (434): Parser->replaceVariables(string,
>> PPTemplateFrame_DOM)
>> #2 ~\includes\parser\Parser.php(4293): MyExtensionParserHook(string, 
>> array,
>> Parser, PPTemplateFrame_Hash)
>>
>> (The subsequent call stack entries are the parent functions you would 
>> expect
>> to see in that situation.)
>>
>> Can anyone see why the above code would no longer work as it did on 
>> previous
>> versions?  What is the current recommended method for manually expanding
>> template variables from within a parser hook?
>>
>> Kind regards,
>>
>> - Mark Clements (HappyDog)
>>
>> --
>> Full example (with extension-specific code omitted):
>> --
>>
>>function MyExtensionParserHook($Text, $Vars, $Parser, $Frame) {
>>
>>// 1) Manipulate $Text and $Vars
>>
>>// (omitted)
>>
>>// 2) Expand variables in the resulting text.
>>
>>// Set up a new frame which mirrors the existing one but which also 
>> has
>> the
>>// field values as arguments.
>>// If we are already in a template frame, merge the field arguments 
>> with
>> the
>>// existing template arguments first.
>>if ($Frame instanceof PPTemplateFrame_DOM) {
>>$NumberedArgs = $Frame->numberedArgs;
>>