View source for Module talk:Params

== New function <code>self</code> ==
I have added a new function to the module, &#123;&#123;[[Module:params|#invoke:params]]|[[Module:params#self|self]]&#125;&#125;, however I am not sure whether the most idiomatic name for it is <code>self</code> or <code>title</code> (especially considering that <code>self</code> has a special meaning in Lua). --[[User:Grufo|Grufo]] ([[User talk:Grufo|talk]]) 00:36, 27 September 2023 (UTC)

:@[[User:Grufo|Grufo]]: I would prefer a different naming. Based upon magic words like {{tlm|PAGENAME}} and friends, things along the lines of <code>PARENTNAME</code>, <code>TEMPLATENAME</code> (sadly we already have a {{tl|TEMPLATENAME}} with a slightly different meaning), <code>INVOKERNAME</code> or similar come to mind, along with the possibilites of things like <code>CHILDNAME</code>, <code>MODULENAME</code>, <code>INVOKEENAME</code> or similar; potentially with modifiers for other encodings ''a la'' {{tlm|PAGENAMEE}} and [[mw:Manual:PAGENAMEE encoding#Encodings compared|comparison of page title encodings]], etc. (e.g., by returning [[mw:Extension:Scribunto/Lua reference manual#Title objects|mw.title:partialUrl()]] or similar), not to mention other options in line with things like {{tlm|FULLPAGENAME}}, {{tlm|FULLPAGENAMEE}}, etc. That said, perhaps those names are not really the best either and it would be better to stick to naming closer to Scribunto naming along the lines of <code>parentPageTitle</code>/<code>modulePageTitle</code> and stick to modifiers provided by <code>mw.title</code> object and/or <code>mw.url</code> API like <code>partialUrl</code>, <code>queryEncode</code>, <code>pathEncode</code>, <code>wikiEncode</code>, <code>anchorEncode</code>. Incidentally, I have often considered developing a Scribunto replacement for base (or even all the extensions in the default and/or WMF MediWiki packaging) magic words and then potentially extending it from there. This begs the need for these types of things more generally but I digress. —[[User:Uzume|Uzume]] ([[User talk:Uzume|talk]]) 19:51, 6 March 2024 (UTC)
:: @[[User:Uzume|Uzume]] Sorry for my very late reply. Your suggestions would be <syntaxhighlight lang="wikitext" inline>{{#invoke:params|INVOKERNAME}}</syntaxhighlight>, or <syntaxhighlight lang="wikitext" inline>{{#invoke:params|CHILDNAME}}</syntaxhighlight>, or <syntaxhighlight lang="wikitext" inline>{{#invoke:params|MODULENAME}}</syntaxhighlight>, or <syntaxhighlight lang="wikitext" inline>{{#invoke:params|INVOKEENAME}}</syntaxhighlight>. These would break the convention used for function names in this module, and also would not be so immediate to understand (i.e. if template <syntaxhighlight lang="wikitext" inline>{{foobar}}</syntaxhighlight> ''invokes'' this module I would expect “INVOKENAME” and the other names you propose to return <code>Module:Params</code> instead of <code>foobar</code>). There is a convention used by many programming languages according to which the parameter zero is the name of the routine executing the code (e.g. in [[Bash]] <code>$<nowiki />1</code>, <code>$<nowiki />2</code>, <code>$<nowiki />3</code>, … are the parameters, whereas <code>$<nowiki />0</code> is the name of the script or the name of the subroutine, much like our <syntaxhighlight lang="wikitext" inline>{{#invoke:params|self}}</syntaxhighlight>). However in these languages parameters can only be non-zero positive numbers, whereas in template syntax <code>0</code> can also be a parameter name (e.g. <syntaxhighlight lang="wikitext" inline>{{foobar|0=hello|1=world}}</syntaxhighlight>), so another solution needs to be found. There used to be an <code>arguments.callee</code> property in JavaScript with a similar meaning, but [https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Functions/arguments/callee today is deprecated], and if we named our function <syntaxhighlight lang="wikitext" inline>{{#invoke:params|CALLEENAME}}</syntaxhighlight> I believe it would create confusion in redirected templates. The name “self” is what for me comes the closest to “parameter zero” in those languages that use the latter for the same purpose. And so “self” inside <syntaxhighlight lang="wikitext" inline>{{foobar}}</syntaxhighlight> is <code>foobar</code>. --[[User:Grufo|Grufo]] ([[User talk:Grufo|talk]]) 19:20, 22 May 2024 (UTC)
:::@[[User:Grufo|Grufo]]: To me <code>self</code> tends to lend its meaning from Lua in much the same way as as <code>this</code> does in C++, namely an [[object (computer science)|object]] reference (although in C++ these are always [[class-based programming|class-based]] and in Lua they do not have to be as they could be [[prototype-based programming|prototype-based]], etc.). It is true that in MW "title" has several meanings but its most common meaning is a textual name of a {{em|page}}, that said I would try to avoid it based on things like [[mw:Manual:Modeling pages|Manual:Modeling pages]]. That said page "title" and <code>PAGENAME</code> tend to be the name of a page without a namespace, as opposed to <syntaxhighlight lang=lua inline>frame:getTitle()</syntaxhighlight> and <code>FULLPAGENAME</code>, etc. You asked how people felt about the naming of the current <code>self</code> invocation target and though I am not a fan of "self", I do think it is better than anything with "title" in its name. —[[User:Uzume|Uzume]] ([[User talk:Uzume|talk]]) 10:16, 23 May 2024 (UTC)
:::: It's true I asked, but my concern was not about how understandable the term is, but about the fact that “self” has a peculiar meaning in Lua. And although this still holds true, it is also true that this module is not meant to be called by other modules (i.e. it is not meant to be used in Lua), but it is meant to be called by templates, where “self” has no special meaning whatsoever (plus, template writers are required to know nothing at all about Lua, and maybe one day modules will be written in more languages other than Lua). And ''even if'' a template writer knows about Lua, <code>self</code> would still make sense (i.e.  the “Lua-style ''self'' from the point of view of a template is the template itself”). If you mention words that are already in use, they would carry the reference they currently have (e.g. “title” would refer to the transcluding page, not the transcluded template), so we do need to invent new words that carry no references, since no magic word or template currently offers the same functionality. For me the only possible contender would be <code>callee</code> (but see what I wrote earlier about the case of redirected templates). --[[User:Grufo|Grufo]] ([[User talk:Grufo|talk]]) 10:42, 23 May 2024 (UTC)
:::::Be verbose to avoid any confusion, it costs you nothing. How about calling_template_name? [[Special:Contributions/68.199.122.141|68.199.122.141]] ([[User talk:68.199.122.141|talk]]) 11:20, 23 May 2024 (UTC)
:::::: But that would be very confusing! This function is meant to be used in transcluded templates (otherwise one uses<syntaxhighlight lang="wikitext" inline>{{FULLPAGENAME}}</syntaxhighlight>); and if template <syntaxhighlight lang="wikitext" inline>{{foo}}</syntaxhighlight> calls <syntaxhighlight lang="wikitext" inline>{{bar}}</syntaxhighlight>, and the latter contains <syntaxhighlight lang="wikitext" inline>{{#invoke:params|self}}</syntaxhighlight>, we get <code>bar</code>, which is the ''called'' template, not the ''calling'' template (which instead would be <code>foo</code> – of course, technically the called template is also ''invoking'' a module, but users need to know nothing about Lua and modules for using <syntaxhighlight lang="wikitext" inline>{{#invoke:params}}</syntaxhighlight>). It is not a coincidence that in JavaScript the same functionality was called <code>arguments.'''callee'''</code> (and not <code>arguments.'''caller'''</code> – but again, “callee”/“called” create confusion in redirected templates). --[[User:Grufo|Grufo]] ([[User talk:Grufo|talk]]) 13:08, 23 May 2024 (UTC)
:::::::In your example, template {{tl|bar}} is calling {{mlx|params|self}}, so {{tl|bar}} is the calling template (of your function), and its name is calling_template_name. It could be this_template_name as well. The word 'self' is usually used for the very object (with methods and stuff), not only its name. [[Special:Contributions/68.199.122.141|68.199.122.141]] ([[User talk:68.199.122.141|talk]]) 13:39, 23 May 2024 (UTC)
:::::::: <code>this_template_name</code> would also be possible. Let's see if others prefer it to <code>self</code>. Contra: although the funcion is meant to be used in templates, nothing forbids to use it in non-transcluded pages, wehere there is no such thing as “this template”; or imagine the page <code>Template:Foobar/doc</code> using <code>this_template_name</code> for referring to itself instead of the actual template it is documenting (i.e. <code>Template:Foobar</code> – that would also create confusion with {{tl|TEMPLATENAME}}). --[[User:Grufo|Grufo]] ([[User talk:Grufo|talk]]) 21:09, 23 May 2024 (UTC)
:::::::::this_function_caller, I don't think it can be more precise; self, though, is a bit confusing when a page transcludes a template invoking a template invoking the function, or any such mumbo jumbo. [[Special:Contributions/68.199.122.141|68.199.122.141]] ([[User talk:68.199.122.141|talk]]) 22:50, 23 May 2024 (UTC)
:::::::::I cannot say I like {{code|this_template_name}}. Without doing strange manipulations like {{code|frame:newChild}}, etc. the parent frame should always be the frame that calls {{code|#invoke}}. Even when {{code|frame:callParserFunction('#invoke', ...)}} is called this is normally true as it will either refer to the calling module or if specifically called off the parent frame, the invoker's invoker frame (i.e., a grandparent but the actual invoker frame is hidden then). This is why from the Lua standpoint something like {{code|parent_fullpagename}} probably makes the most sense, however, as you said this is designed to be understood from the template or parent's point of view (the users of which should not need to understand Lua, etc.) and as such there are {{em|way}} too many confusing page names to begin with. To that end, I still like {{code|invoker_fullpagename}}. {{code|full}} should probably be included as {{code|FULLPAGENAME}} includes a prefixed {{code|NAMESPACE}} as this function also returns. If you really like the {{code|caller}} nomenclature then how about {{code|module_caller_fullpagename}} and if you really like the {{code|this}}, how about {{code|this_module_caller_fullpagename}}. —[[User:Uzume|Uzume]] ([[User talk:Uzume|talk]]) 15:06, 11 July 2025 (UTC)
:::::::::FYI: {{ml|TEMPLATENAME|main}} now does this same thing too but I am not a fan of its naming either. I personally believe names like {{code|template_name}} or {{code|module_name}} should be considered in situations where they are made to be used with {{code|msg:}} or {{code|#invoke:}}, i.e, the namespace is not prefixed for template or modules but it is otherwise, including for the empty main namespace (for example when you want to transclude a main space page and need syntax like <code><nowiki>{{:mainspacepage}}</nowiki></code> or <code><nowiki>{{msg::mainspacepage}}</nowiki></code> but you don't need such for {{code|{{ns:10}}}} and in a similar fashion you don't need {{code|{{ns:828}}}} for {{code|#invoke:}}. This is exactly what things like {{tlx|TEMPLATENAME}} do because they are designed for constructions like <code><nowiki>{{{{TEMPLATENAME}}|...}}</nowiki></code> (in this case typically from a {{code|/doc}} subpage but one wants it to also render properly from the main template and/or its {{code|/sandbox}} subpage, etc., i.e., everywhere {{code|/doc}} is transcluded from). —[[User:Uzume|Uzume]] ([[User talk:Uzume|talk]]) 15:06, 11 July 2025 (UTC)

== Wrapper template with pass-thru params ==

I'm a template writer and have newly discovered this Module, and am still getting on board with it, but have not used it yet. I think it probably will handle some use cases I have, but I'm not quite sure. One case that is typical for me, is a wrapper template with "pass-thru params", that is, the case of a wrapper template A, that calls template B passing thru all or almost all of A's params to B without alteration, and one or two more params with hard-coded  values. For a concrete example, consider template {{tl|sfnlink}}. I want to create new wrapper template {{tl|sfnlinknb}}, that will have the identical params that sfnlink has, less param {{para|nb}}; the job of the wrapper, is to pass through all of its params to {{tl|sfnlink}}, and add {{para|nb|yes}} as well. The "pass-thru" part of this seems like the kind of thing I ought to be able to do with Module:Params, but I'm not quite sure. Maybe using <code>for_each</code>? Thanks, [[User:Mathglot|Mathglot]] ([[User talk:Mathglot|talk]]) 00:09, 3 December 2023 (UTC)

:It looks like you have a working implementation using double transclusion and <code>for_each</code> in {{tl|sfnlinknb}} already, but if it's useful as an alternative approach, I just used <code>concat_and_call</code> to do the same thing in {{tl|autnum plain}}: [[Special:Diff/1188117126]]. [[User:DefaultFree|DefaultFree]] ([[User talk:DefaultFree|talk]]) 13:26, 3 December 2023 (UTC)
:: [[User:DefaultFree|DefaultFree]], thank you '''so''' much for this. Your solution is infinitely better, and I've rewritten my wrapper using your idea. I had made multiple attempts—you can see the numerous failures at the history of [[User:Mathglot/sandbox/Templates/params_for_each]] and at [[Template:Sfnlinknb]]. At one point, I thought I had it because it worked perfectly at [[Special:ExpandTemplates]], but then I found it didn't work anywhere else—it spit out the correct code (as if it were nowiki'ed), but didn't invoke it, except at ExpandTemplates, for some reason. Then I went off on a tangent, trying to add {{tl|Eval}} in front of the whole thing to get it to execute, and as you saw, I got tangled up in double transclusion, and, oh, what a mess! Yours is so much better, and would make a great addition to the documentation of this Module, either as an example, or as a "Pro tip" note.  (You might be interested to see what I did with the (on-page) /doc, the {{no redirect|Template:Sfnlinknb/sandbox|/sandbox}}, and the [[Template:Sfnlinknb/testcases|/testcases]] pages for {{tl|Sfnlinknb}}.)  Thanks again, and I owe you one! [[User:Mathglot|Mathglot]] ([[User talk:Mathglot|talk]]) 22:29, 3 December 2023 (UTC)

== 15th January 2024: New changes ==
The [[Module:Params/ChangeLog]] subpage now keeps the record of the most important changes in the module's code. Furthermore four new modifiers – <code>[[Module:Params#mapping_values_by_calling|mapping_values_by_calling]]</code>, <code>[[Module:Params#mapping_values_by_invoking|mapping_values_by_invoking]]</code>, <code>[[Module:Params#mapping_values_blindly_by_calling|mapping_values_blindly_by_calling]]</code> and <code>[[Module:Params#mapping_values_blindly_by_invoking|mapping_values_blindly_by_invoking]]</code> – were recently added to the module. These allow to pass each argument one by one to a custom template or a custom module in order to be preprocessed before further actions. --[[User:Grufo|Grufo]] ([[User talk:Grufo|talk]]) 04:07, 15 January 2024 (UTC)

== growth and sandboxes ==

Hi {{ping|Grufo}} - following on from your request over at [[WP:PERM]]. Got a few questions:
#Do you know what has recently caused the large growth in calls to this module? Is such a large use necessary?
#This module doesn't appear to have a /sandbox; now that it is so heavily used where are changes being validated prior to deployment?
Thanks, — [[User:Xaosflux|<span style="color:#FF9933; font-weight:bold; font-family:monotype;">xaosflux</span>]] <sup>[[User talk:Xaosflux|<span style="color:#009933;">Talk</span>]]</sup> 13:34, 22 April 2024 (UTC)
:{{u|xaosflux}}, the drastic usage increase looks to be due to [[Special:Diff/1214727698]]. [[User:Primefac|Primefac]] ([[User talk:Primefac|talk]]) 13:42, 22 April 2024 (UTC)
::Numbers should start falling, I've undone the above. [[User:Primefac|Primefac]] ([[User talk:Primefac|talk]]) 13:50, 22 April 2024 (UTC)
:::FYI to {{ping|Uzume}} — [[User:Xaosflux|<span style="color:#FF9933; font-weight:bold; font-family:monotype;">xaosflux</span>]] <sup>[[User talk:Xaosflux|<span style="color:#009933;">Talk</span>]]</sup> 14:19, 22 April 2024 (UTC)
::::@[[User:Xaosflux|Xaosflux]]: Thanks for the heads-up. I just fixed a minor documentation bug. Using something like this module insulated it from potential moves (or someone copying it for as a template, etc.) but there are obviously other ways to fix that issue and I certainly did not mean for it to have such ramifications (I would not want to prevent the author from development; the sandbox still allows such if somewhat more cumbersome). —[[User:Uzume|Uzume]] ([[User talk:Uzume|talk]]) 14:31, 22 April 2024 (UTC)
: Hi [[User:Xaosflux|Xaosflux]]. I have no idea. I tried to find out, but I believe that whoever is responsible for the growth did not follow the suggestion of adding {{Tl|Lua}} to the documentation of the templates that start using this module. So finding out where all the calls come from is hard (btw, someone has to improve the “What links here” special page and allow to list direct transclusions only…). I had planned some important improvements for this module, but I have been very busy in the last months. And as soon as I had a bit of time for the module I found out that I can no longer edit it. Concerning the sandbox: it's not hard to create one, is it? So far every time I posted an update I tested it locally on my machine, but I agree that it would be good to have a sandbox here too. '''EDIT.''' [[User:Primefac|Primefac]] gave the answer while I was writing mine (@[[User:Primefac|Primefac]]: Thank you). --[[User:Grufo|Grufo]] ([[User talk:Grufo|talk]]) 13:48, 22 April 2024 (UTC)
::Always happy to help. For the record, I used an insource search to find where it was being invoked, specifically <code>insource:/invoke:params/</code>, as seen [https://en.wikipedia.org/w/index.php?title=Special:Search&limit=500&offset=0&ns0=1&ns1=1&ns2=1&ns3=1&ns4=1&ns5=1&ns6=1&ns7=1&ns8=1&ns9=1&ns10=1&ns11=1&ns12=1&ns13=1&ns14=1&ns15=1&ns100=1&ns101=1&ns118=1&ns119=1&ns710=1&ns711=1&ns828=1&ns829=1&search=insource%3A%2Finvoke%3Aparams%2F here]. [[User:Primefac|Primefac]] ([[User talk:Primefac|talk]]) 14:19, 22 April 2024 (UTC)
::I've lowered the protection level on this, you should be able to edit again. Suggest you build up a sandbox and incorporate it to the testcases. — [[User:Xaosflux|<span style="color:#FF9933; font-weight:bold; font-family:monotype;">xaosflux</span>]] <sup>[[User talk:Xaosflux|<span style="color:#009933;">Talk</span>]]</sup> 14:21, 22 April 2024 (UTC)
::: Thank you both @[[User:Primefac|Primefac]] and @[[User:Xaosflux|Xaosflux]]! The next changes in the code will pass through a sandbox. --[[User:Grufo|Grufo]] ([[User talk:Grufo|talk]]) 14:30, 22 April 2024 (UTC)

== Ready for general use ==
Improvements are always possible, but I believe [[Special:Diff/1224926156/1225161147|time has come]] to mark this module as [[:Category:Modules for general use|ready for general use]]. --[[User:Grufo|Grufo]] ([[User talk:Grufo|talk]]) 18:52, 22 May 2024 (UTC)

== Inverting parameters ==

At {{tlf|[[WP:RSPUSES]]}}, I needed not <code>|1=key|2=value</code> but <code>|1=value|2=key</code>. I achieved this with <code><nowiki>{{#invoke:params|sequential|mapping_by_calling|duses|values_and_names|setting|i|<br>|list_values}}</nowiki></code> when <code>call_for_each</code> didn't work. Are there plans to add a shortcut like <code>call_for_each_value_and_key</code>? [[Special:Contributions/174.92.25.207|174.92.25.207]] ([[User talk:174.92.25.207|talk]]) 21:56, 4 July 2024 (UTC)
: You followed exactly the right way. There are no plans to create a <code>call_for_each_value_and_key</code> function, because that will mean that we will have to create also an <code>invoke_for_each_value_and_key</code> function, a <code>magic_for_each_value_and_key</code> function, a <code>call_for_each_key</code> function, and so on. This module is already quite rich in functions; if new functions will be added in the future it will probably be to add new functionalities, not just syntax sugar. --[[User:Grufo|Grufo]] ([[User talk:Grufo|talk]]) 00:56, 6 July 2024 (UTC)

== Code link on mobile ==

{{re|Grufo}} Are you aware that the mobile view looks like this? <pre>
----------------------------------------
|               Function               |
| |----------------------------------| |
| |              count               | |
| |----------------------------------| |
|                  (                   |
|                code                  |
|                  )                   |
| Num. of arguments 0                  |
</pre> instead of the proper desktop view like this?
<pre>
              |-----|
     Function |count| (code)
              |-----|
--------------------------------
| Num. of    0                 |
| arguments                    |
</pre> Ideally the entire header should be on the same line like on desktop. But the parentheses in the code link are currently a monstrosity on mobile. [[Special:Contributions/174.92.25.207|174.92.25.207]] ([[User talk:174.92.25.207|talk]]) 06:03, 8 July 2024 (UTC)

: @[[User:174.92.25.207|174.92.25.207]]: Thank you. I think the quirk is too infobox-specific to be integrated in the {{[[Module:Params/doc/link to the code|./doc/link to the code]]}} template. However  [[Special:Diff/1233239047/1233369914|this]] should fix it. --[[User:Grufo|Grufo]] ([[User talk:Grufo|talk]]) 18:45, 8 July 2024 (UTC)

== Minor limitation currently affecting some functions ==
There is currently a design limitation in the [[:mw:Extension:Scribunto/Lua reference manual#frame:newChild|child frame]] object that affects <code>[[Module:Params#invoke_for_each|invoke_for_each]]</code>, <code>[[Module:Params#invoke_for_each_value|invoke_for_each_value]]</code>, <code>[[Module:Params#mapping_by_invoking|mapping_by_invoking]]</code> and <code>[[Module:Params#renaming_by_invoking|renaming_by_invoking]]</code>. The limitation affects these functions only when used on a large number of parameters (> 99). For more information see:
* {{Section link|Wikipedia talk:Lua/Archive 12|Editing the args metatable of a child frame}}
* [[:mw:Topic:Y61qv62t0k0w2b7f|Topic on Extension talk:Scribunto/Flow § Design problem in the frame object]]
--[[User:Grufo|Grufo]] ([[User talk:Grufo|talk]]) 20:03, 14 April 2025 (UTC)

:@[[User:Grufo|Grufo]]: It seems like the best solution would be to avoid your current {{code|:newChild}} hacks and instead do actual {{code|#invoke:}} parser function calls via {{code|:callParserFunction}}. That also solves a number of problems with the current solution (besides the 99 frames limit), e.g., the current "invocation" method does not always work correctly for modules that attempt to detect such things (e.g., ones that test their inbound {{code|...}} to see how the module is being loaded, either as a {{code|#invoke:}} "main" or as a {{code|require}} sub-library module, {{code|mw.loadData}}, etc.). It also allows you to jettison some error code as true {{code|#invoke:}} already throws errors when the function cannot be found, etc. Don't try and reinvent the wheel (I ran into a similar situation with [[Special:Diff/954154594/prev|954154594]]). It also allows you the ability to potentially consolidate your code as your template {{code|call}} interfaces could be moved from {{code|:expandTemplate}} to {{code|:callParserFunction}} with {{code|msg:}} and both {{code|#invoke:}} and {{code|msg:}} could be implemented with your {{code|magic}} functions which already use {{code|:callParserFunction}}. The {{code|invoke}} function of <code>[[Module:Lua call]]</code> is a good example. Most uses of {{code|:newChild}} are typically poorly designed. One probably legitimate use would be to create an artificial parent frame for calling {{code|:callParserFunction}} off of (for modules that look at their parent frame, etc.). —[[User:Uzume|Uzume]] ([[User talk:Uzume|talk]]) 19:05, 9 July 2025 (UTC)
:: Thank you, [[User:Uzume|Uzume]]. You make a strong point when you talk about modules that detect whether they have been called via <code>require()</code> or <code>#invoke</code>. I did not even know that was possible (how does one do that?). I have been thinking for a while about replacing <code>:newChild()</code> with <code>:callParserFunction()</code> + <code>#invoke</code> in the functions listed above. I have not done it so far because I was hoping to trigger a rethinking upstream on how <code>:newChild()</code> is currently designed. However no discussions have emerged so far as far as I know (and so maybe now it is the time to get rid of <code>:newChild()</code>). At the moment, when facing the bug described here, it is already possible to use <code>{{mfl|params|mapping_by_magic|#invoke|...}}</code> instead of <code>{{mfl|params|mapping_by_invoking|...}}</code> (which is why this did not seem to be an urgent fix). For instance, if we wanted to use {{mfl|string|replace}} to replace spaces with hyphens in values (and forgetting for a moment that we already have <code>{{mfl|params|mapping_by_replacing|...}}</code>), we could already do
::: <code>...&#124;[[Module:Params#mapping_by_invoking|mapping_by_invoking]]&#124;[[Module:String|string]]&#124;[[Module:String#replace|replace]]&#124;4&#124;%s+&#124;-&#124;&#124;false&#124;...</code>
:: or, equivalently,
::: <code>...&#124;[[Module:Params#mapping_by_magic|mapping_by_magic]]&#124;#invoke&#124;values_only_as&#124;3&#124;let&#124;1&#124;[[Module:String|string]]&#124;let&#124;2&#124;[[Module:String#replace|replace]]&#124;4&#124;%s+&#124;-&#124;&#124;false&#124;...</code>
:: Interestingly, while <code>#invoke</code> is recognized as a parser function, the same seem not to apply to <code>msg</code>, and so it seems not possible to use the latter in combination with <code>:callParserFunction()</code>. In any case, <code>:expandTemplate()</code> seems to work just fine. --[[User:Grufo|Grufo]] ([[User talk:Grufo|talk]]) 11:19, 10 July 2025 (UTC)
:::@[[User:Grufo|Grufo]]: I am not sure why {{code|msg}} would not work as a parser function. I wonder if that is also true for {{code|msgnw}} (which is sort of similar to Scribunto {{code|mw.title:getContent()}} because it does {{em|not}} process page source through the main wikitext parser). I wonder if there is an issue with the way you are building your argument list or calling the parser function that is limiting things. —[[User:Uzume|Uzume]] ([[User talk:Uzume|talk]]) 21:29, 10 July 2025 (UTC)
:::Anyway, I am not sure about all the ways for Lua modules to detect how they are called but one of the primary ones would be to check {{code|...}} during the execution of the module initialization block (which executes during {{code|#invoke}} before the function call to the its first argument and why it is possible to catch {{em|any}} argument as the function name using a metatable with {{code|__index}} like in <code>[[Module:Ustring]]</code>; oddly enough that also means one can process the frame args {{em|before}} the function name is provided to the module but of course nothing can be returned until later). {{code|require()}} passes in the module's name while Scribunto {{code|#invoke}} does not (imitating command line {{code|lua}} but the frame args are {{em|not}} put into {{code|...}} or global {{code|arg}} so they are always empty/{{code|nil}}; probably because frame args have non-sequential parameter keys). Checking {{code|...}} can be a good way to have the module return a different {{em|package}} table (often denoted as just {{code|p}}) based upon whether it is loaded via {{code|#invoke}} or not. In fact, that style of coding allows one to do away with the awkward leading underscore API functions and even allows the module to {{code|require}} itself during {{code|#invoke}} thereby using its own API while also providing {{em|frame}} wrapper function(s) for {{code|#invoke}} calls from wikitext. The name of the module used during {{code|#invoke}} is of course provided via {{code|frame:getTitle()}} which can be accessed from anywhere, including the module initialization block, via {{code|mw.getCurrentFrame()}}. —[[User:Uzume|Uzume]] ([[User talk:Uzume|talk]]) 21:29, 10 July 2025 (UTC)
:::I created an example module for demonstrating how a module can detect how it is loaded at <code>[[Module:Sandbox/Grufo]]</code>. Feel free to do with it as you see fit. Notice how your {{code|require()}} plus {{code|frame:newChild()}} implementation likely would not work with that construction but a {{code|frame:callParserFunction('#invoke', ...)}} construction would. You should consider which frame to call that off-of though. Frequently it makes more sense to call that off of the parent so that the new invocation has the same parent as where you call it from (i.e., they are effectively "sibling" invocations) as arguments to your module might not be particularly interesting to the module you are invoking (if they are, you should probably pass them to the module directly via its own arguments) but arguments to the parent template would otherwise be lost (due to frame depth; a module can only access its frame and one parent—no grandparents, etc.). I am not sure if it matters which parent frame is available for other parser functions/magic words but I encourage you to consider using {{code|frame:callParserFunction()}} from the parent frame. —[[User:Uzume|Uzume]] ([[User talk:Uzume|talk]]) 21:29, 10 July 2025 (UTC)
:::FYI: another little known fact is that Scribunto has translations of {{code|#invoke}} so such can actually be accessed via alias keywords on for example a Korean or Russian Mediawiki, etc.; that makes it pain to search for all such invocations of a module but luckily few people know and use aliases. —[[User:Uzume|Uzume]] ([[User talk:Uzume|talk]]) 21:29, 10 July 2025 (UTC)
:::: Hi [[User:Uzume|Uzume]]. Thank you for the sandbox module. I think I understand now. As for <code>msg</code>, you can check yourself:
::::* <syntaxhighlight lang="wikitext" inline>{{if|eq|a|a|x|y}}</syntaxhighlight>
::::*: ↳ {{if|eq|a|a|x|y}}
::::* <syntaxhighlight lang="wikitext" inline>{{#invoke:params|new|concat_and_call|if|eq|a|a|x|y}}</syntaxhighlight>
::::*: ↳ {{#invoke:params|new|concat_and_call|if|eq|a|a|x|y}}
::::* <syntaxhighlight lang="wikitext" inline>{{#invoke:params|new|concat_and_magic|msg|if|eq|a|a|x|y}}</syntaxhighlight>
::::*: ↳ {{#invoke:params|new|concat_and_magic|msg|if|eq|a|a|x|y}}
::::* <syntaxhighlight lang="wikitext" inline>{{#invoke:params|new|concat_and_magic|#ifeq|a|a|x|y}}</syntaxhighlight>
::::*: ↳ {{#invoke:params|new|concat_and_magic|#ifeq|a|a|x|y}}
:::: You can also experiment with a new module and <code>:callParserFunction()</code> to see if there is a problem in [[Module:Params]]. But there are no reasons to replace <code>:expandTemplate()</code>. As for replacing <code>:newChild()</code> with <code>:callParserFunction()</code> + <code>#invoke</code>, we need to see if in these language in which they use a local translation of <code>#invoke</code> the English <code>#invoke</code> still works (I think it should). Otherwise this module will become a nightmare to maintain. If the English <code>#invoke</code> does not work we should leave the module as it is and simply warn that in case of > 99 parameters or in case of modules that check how they have been invoked, people should use the local version of <code>{{mfl|params|mapping_by_magic|#invoke|...}}</code> instead of <code>{{mfl|params|mapping_by_invoking|...}}</code>. I wonder what the performance difference is between using <code>:callParserFunction()</code> + <code>#invoke</code> and <code>:newChild()</code>. I will run some tests. --[[User:Grufo|Grufo]] ([[User talk:Grufo|talk]]) 15:34, 11 July 2025 (UTC)
:::::@[[User:Grufo|Grufo]]: I think {{code|msg}} not being recognized as a parser function is likely a bug. The question is where the bug is: your module, the Scribunto extension, MediaWiki proper or some other weird place (i.e., unforeseen interaction somewhere). As shown below, the first argument can cause this error in some cases:
:::::* <syntaxhighlight lang="wikitext" inline>{{#invoke:params|new|concat_and_magic|canonicalurl|:ja}}</syntaxhighlight>
:::::*: ↳ {{#invoke:params|new|concat_and_magic|canonicalurl|:ja}}
:::::* <syntaxhighlight lang="wikitext" inline>{{#invoke:params|new|concat_and_magic|canonicalurl|::ja}}</syntaxhighlight>
:::::*: ↳ {{#invoke:params|new|concat_and_magic|canonicalurl|::ja}}
:::::This definitely needs more investigation. I might have to look into that. —[[User:Uzume|Uzume]] ([[User talk:Uzume|talk]]) 16:52, 11 July 2025 (UTC)
:::::Yes, Scribunto ensures {{code|#invoke}} always works even when there are localized alias names. This is in a fashion similar to MediaWiki base namespace names, e.g., Chinese Wikipedia might have another name for <code>{{ns:10}}</code> but that name always works everywhere (even here we have a different base name for the {{code|Project}} namespace but {{code|Project}} still works; i.e. <syntaxhighlight lang="wikitext" inline>{{ns:Project}}</syntaxhighlight> yields <code>{{ns:Project}}</code> and <syntaxhighlight lang="wikitext" inline>{{ns:Image}}</syntaxhighlight> yields <code>{{ns:Image}}</code>, etc.) they just act like a redirect alias to the localized name.  —[[User:Uzume|Uzume]] ([[User talk:Uzume|talk]]) 16:52, 11 July 2025 (UTC)
:::::FYI: Another little known fact is that {{em|all}} Scribunto module pages are in content language English (I am not sure that is really the right choice but I am not planning to fight it anytime soon) even on Mediawiki instances where English is really used nowhere else. As an example, try going to [[zh:Special:EditPage/Module:Var#mw-scribunto-console]] and type into the debug console: <syntaxhighlight lang="lua" inline>mw.log(mw.title.getCurrentTitle().pageLang.code)</syntaxhighlight>. You will get: {{code|en}}. —[[User:Uzume|Uzume]] ([[User talk:Uzume|talk]]) 16:52, 11 July 2025 (UTC)
:::::: {{Re|Uzume}} Now I don't have the time to create a test module and check <code>:callParserFunction()</code> with <code>msg</code>. However writing <code>::ja</code> as argument seems to make the <code>canonicalurl</code> parser function invisible even when called directly (see third example):
::::::# <syntaxhighlight lang="wikitext" inline>{{#invoke:params|new|concat_and_magic|canonicalurl|ja}}</syntaxhighlight> corresponds to <syntaxhighlight lang="wikitext" inline>{{canonicalurl:ja}}</syntaxhighlight>; the latter yields
::::::#: ↳ {{canonicalurl:ja}}
::::::# <syntaxhighlight lang="wikitext" inline>{{#invoke:params|new|concat_and_magic|canonicalurl|:ja}}</syntaxhighlight> corresponds to <syntaxhighlight lang="wikitext" inline>{{canonicalurl::ja}}</syntaxhighlight>; the latter yields
::::::#: ↳ {{canonicalurl::ja}}
::::::# <syntaxhighlight lang="wikitext" inline>{{#invoke:params|new|concat_and_magic|canonicalurl|::ja}}</syntaxhighlight> corresponds to <syntaxhighlight lang="wikitext" inline>{{canonicalurl:::ja}}</syntaxhighlight>; the latter yields
::::::#: ↳ [[:Template:Canonicalurl:::ja]]
:::::: As for moving from <code>:newChild()</code> to <code>:callParserFunction()</code> + <code>#invoke</code>, as soon as I have a moment I will update [[Module:Params/sandbox]] and run a few tests. --[[User:Grufo|Grufo]] ([[User talk:Grufo|talk]]) 18:13, 11 July 2025 (UTC)
:::::::@[[User:Grufo|Grufo]]: Yes,  that is interesting how the parser decides that syntax could not be a parser function call (because the argument is not a legal pagename?) and then falls back to parsing it as a template invocation of that pagename. The error from {{code|frame:callParserFunction()}} is definitely coming from [https://github.com/wikimedia/mediawiki-extensions-Scribunto/blob/e93d49ff0570930922a25ca515068c89397ae5ae/includes/Engines/LuaCommon/LuaEngine.php#L807-L810 the Scribunto PHP code] but the point you bring up may in fact be related (see below). As memory serves, when the parser is parsing normal wikitext, it handles parser function calls by parsing out the name and the chunk of wikitext to the end of the call (i.e., <code>{{))}}</code>) only separating them out by <code>{{!}}</code> and then calling the parser function code itself giving it a chance to "claim" the provided wikitext arguments (which are {{em|not}} yet fully parsed) and the parser function then decides how to parse such (some use the frame parser but many do not, e.g., {{code|#switch}} depends on the order/positioning of its arguments so it cannot use the frame parser and this is also why Scribunto {{code|#invoke}} can never perfectly emulate it) but I believe the parser function can also return to the parser stating it does not claim the provided wikitext arguments and in such a case the parser must march on assuming that it was not in fact a call to that parser function. I believe that is what is happening in your example above. Maybe something similar is happening in the {{code|frame:callParserFunction()}} path. It would kind of make sense there would be no way to actually call the parser function with entirely pre-parsed arguments so that path perhaps reconstructs the pseudo-unparsed wikitext arguments from the provided arguments and passes it to the parser function just as it would during normal wikitext processing. Then if the parser function rejects it, the parser assumes it was not a parser function call and eventually Scribunto yields the error: {{error|function "{{var|function}}" was not found.}} since there is probably no way to differentiate this from someone trying to call a nonexistent parser function, meaning the "not found" in the error is deceptive and should probably say something more like {{error|failed to execute function "{{var|function}}".}} Maybe this is an issue with the way the pseudo-unparsed wikitext arguments are reconstructed that causes {{code|msg}}, {{code|msgnw}} and {{code|raw}} to always reject the call. There may also be something special about {{code|msg}} and friends as in the history of wikitext parsing it was the {{em|first}}—even before normal template syntax existed and template syntax was implemented as a simplification. I wonder if {{strong|parsoid}} has the same issue. —[[User:Uzume|Uzume]] ([[User talk:Uzume|talk]]) 20:17, 11 July 2025 (UTC)
:::::::: @[[User:Uzume|Uzume]]: I agree that the error is deceptive. Let me know if you find out more. In the meanwhile I have updated [[Module:Params/sandbox]] with a new version that replaces <code>:newChild()</code> with <code>:callParserFunction()</code> + <code>#invoke</code>. It will still require extensive testing. --[[User:Grufo|Grufo]] ([[User talk:Grufo|talk]]) 05:17, 12 July 2025 (UTC)
:::::::::@[[User:Grufo|Grufo]]: Okay, yes, I have determined parser functions themselves {{em|can}} and apparently sometimes {{em|do}} return the PHP value <syntaxhighlight lang=php inline>[ 'found' => false ]</syntaxhighlight> which will ultimately lead to that error, however, I think the issue with {{code|msg}}, {{code|msgnw}} and {{code|raw}} is different. I notice they do not show up on [[Special:Version#mw-version-parser-function-hooks]]. They are clearly magic words that take parameters but it looks like they might be handled special by the parser and technically are not parser functions or something which would explain why they cannot be reached by [https://github.com/wikimedia/mediawiki/blob/a5b5777ae4ec274a4ee347c5716d9a4b8180b1fb/includes/parser/Parser.php#L3460 <syntaxhighlight lang=php inline>MediaWiki\Parser\Parser()->callParserFunction()</syntaxhighlight>] (and it {{em|does}} rebuild the arguments for parser function calls in a sort of pseudo-unparsed fashion and the first argument has some special handling) which is used by [https://github.com/wikimedia/mediawiki-extensions-Scribunto/blob/e93d49ff0570930922a25ca515068c89397ae5ae/includes/Engines/LuaCommon/LuaEngine.php#L775 <syntaxhighlight lang=php inline>MediaWiki\Extension\Scribunto\Engines\LuaCommon\LuaEngine()->callParserFunction()</syntaxhighlight>] and ultimately via its Lua library interface. —[[User:Uzume|Uzume]] ([[User talk:Uzume|talk]]) 09:13, 12 July 2025 (UTC)
::::::::::@[[User:Grufo|Grufo]]: Okay, I read through the main parser again and in {{code|braceSubstitution()}} it clearly shows that {{code|msg}}, {{code|msgnw}} and {{code|raw}} are {{strong|NOT}} parser functions. It looks for and handles these in this order:
::::::::::#{{code|subst}} and {{code|safesubst}} prefixes
::::::::::#variables (which are sort of like argument-less parser functions)
::::::::::#{{code|msg}}, {{code|msgnw}} and {{code|raw}} prefixes
::::::::::#parser functions by actually calling the same interface Scribunto calls: {{code|callParserFunction}}
::::::::::#page transclusions, i.e, template syntax
::::::::::#special transclusions from "special pages"
::::::::::Then that function finishes up with some other processing like loop checking and HTML DOM updates, etc.
::::::::::The {{code|msg}}, {{code|msgnw}} and {{code|raw}} prefixes "work" because they are mostly just deleted and do nothing but the code continues on and eventually finds the template transclusion so it appears to do that. {{code|msgnw}} and {{code|raw}} do set some flags but the same flags can sometimes also be set by some of the parser functions which can be seen in the handling at the return of the parser function call. This means some weird syntax is allowed, e.g., <syntaxhighlight lang=wikitext inline>{{msg:canonicalurl:ja}}</syntaxhighlight> and <syntaxhighlight lang=wikitext inline>{{canonicalurl:ja}}</syntaxhighlight> both yield {{msg:canonicalurl:ja}} but one can also do <syntaxhighlight lang=wikitext inline>{{msgnw:canonicalurl:ja}}</syntaxhighlight> which yields {{msgnw:canonicalurl:ja}} (notice no link; this is because "nw" means nowiki but not as in the strip-marker generating tag but as in HTML entity escaping). It also means that this type of functionality is {{em|not}} directly available from Scribunto Lua (at least not without {{code|frame:preprocess()}}). —[[User:Uzume|Uzume]] ([[User talk:Uzume|talk]]) 11:03, 12 July 2025 (UTC)
:::::::::Here are some more examples of core parser functions (I do not plan to go searching through every extension) that themselves return the deceptive "not found":
:::::::::* <syntaxhighlight lang="wikitext" inline>{{#invoke:params|new|concat_and_magic|int|help}}</syntaxhighlight>
:::::::::*: ↳ {{#invoke:params|new|concat_and_magic|int|help}}
:::::::::* <syntaxhighlight lang="wikitext" inline>{{#invoke:params|new|concat_and_magic|int|}}</syntaxhighlight>
:::::::::*: ↳ {{#invoke:params|new|concat_and_magic|int|}}
:::::::::* <syntaxhighlight lang="wikitext" inline>{{#invoke:params|new|concat_and_magic|#interwikilink|d}}</syntaxhighlight>
:::::::::*: ↳ {{#invoke:params|new|concat_and_magic|#interwikilink|d}}
:::::::::* <syntaxhighlight lang="wikitext" inline>{{#invoke:params|new|concat_and_magic|#interwikilink|x}}</syntaxhighlight>
:::::::::*: ↳ {{#invoke:params|new|concat_and_magic|#interwikilink|x}}
:::::::::* <syntaxhighlight lang="wikitext" inline>{{#invoke:params|new|concat_and_magic|ns|project}}</syntaxhighlight>
:::::::::*: ↳ {{#invoke:params|new|concat_and_magic|ns|project}}
:::::::::* <syntaxhighlight lang="wikitext" inline>{{#invoke:params|new|concat_and_magic|ns|xyzzy}}</syntaxhighlight>
:::::::::*: ↳ {{#invoke:params|new|concat_and_magic|ns|xyzzy}}
:::::::::* <syntaxhighlight lang="wikitext" inline>{{#invoke:params|new|concat_and_magic|ns|829xyzzy}}</syntaxhighlight>
:::::::::*: ↳ {{#invoke:params|new|concat_and_magic|ns|829xyzzy}}
:::::::::Oddly this one never returns the error so long as it is passed a value that starts with an integer value other than {{code|0}} (and it also takes exactly {{code|0}} too) even when such an integer value corresponds to no such namespace, e.g., <syntaxhighlight lang="wikitext" inline>{{ns:-500xyzzy}}</syntaxhighlight> parses as a valid parser function call. —[[User:Uzume|Uzume]] ([[User talk:Uzume|talk]]) 09:13, 12 July 2025 (UTC)
:::::::::One thing about parser functions "failing" that bothers me is that there does not seem to be anything that specifies to the parser this type of dependency. One of the key tenants of parsoid is to be able to (re)parse parts of a page potentially out of order doing the right thing based upon a dependency chain (sort of like a software build tool like [[make (software)|make]]). A key example is the new {{code|#interwikilink}} which fails when it is provided an invalid interwiki prefix but that is dependent on MediaWiki configuration. This means that I could place some wikitext somewhere that calls {{code|#interwikilink}} and fails but at some future point it might suddenly succeed. Suppose I lobby for some new interwiki prefix at [[m:Talk:Interwiki map]] and it succeeds and soon afterwards is deployed. Does this mean all MediaWiki wikis at WMF (and whatever else uses those maps) needs to reparse {{em|all}} pages everywhere (Commons literally has millions) because they {{em|might}} contain wikitext that will now suddenly render differently (properly)? If this dependency was somehow stored then the parser would know which pages (and/or page parts) to reparse (and whatever depends on them in turn, etc.). But nowhere is it documented, let alone specified, when and how a parser function will choose to parse something (or lack thereof; i.e., fail and not parse something). So the main parser cannot know when such parser functions change their mind. Maybe I am overthinking things because there are clearly timestamp type of magic words that obviously change their minds on a regular basis and things are just kept "fresh" at a regular cadence. —[[User:Uzume|Uzume]] ([[User talk:Uzume|talk]]) 09:13, 12 July 2025 (UTC)
:::::::::: @[[User:Uzume|Uzume]]: I think you should bring the part of this discussion that concerns parser functions to [[:mw:Extension talk:ParserFunctions]]. Going back to the original point, here is the bad news about my latest experiments. If I write the following wikitext (which uses <code>:newChild()</code>) 12 times in a page and display the preview, I get an average “Lua time usage” of &lt; 0.1 seconds:
:::::::::: <syntaxhighlight lang="wikitext">{{#invoke:params|new|
	imposing|99||
	filling_the_gaps|
	mapping_by_replacing||true|1|strict|
	mapping_by_invoking|string|replace|4|^.*$|Hello!|1|false|
	for_each|[$#::$@]}}</syntaxhighlight>
:::::::::: On the other hand, if I write the following wikitext (which uses <code>:callParserFunction()</code> + <code>#invoke</code>) 12 times in a page and display the preview, I get an average “Lua time usage” of 0.7 seconds:
:::::::::: <syntaxhighlight lang="wikitext">{{#invoke:params/sandbox|new|
	imposing|99||
	filling_the_gaps|
	mapping_by_replacing||true|1|strict|
	mapping_by_invoking|string|replace|4|^.*$|Hello!|1|false|
	for_each|[$#::$@]}}</syntaxhighlight>
:::::::::: Therefore now I am no longer so sure we should drop <code>:newChild()</code>… --[[User:Grufo|Grufo]] ([[User talk:Grufo|talk]]) 10:34, 12 July 2025 (UTC)
:::::::::::@[[User:Grufo|Grufo]]: I do not think [[mw:Extension talk:ParserFunctions]] is appropriate at all. That would be for discussion just about that extension including the parser functions from that extension, e.g., {{code|#expr}}, {{code|#if}}, {{code|#ifeq}}, {{code|#titleparts}}, etc. but not about parser functions in general nor about core parser functions. —[[User:Uzume|Uzume]] ([[User talk:Uzume|talk]]) 11:39, 12 July 2025 (UTC)
:::::::::::As for your performance data, that is very interesting but remember, though {{#invoke}} does have nontrivial overhead (and there are some Phabricator issue tickets about such things) it also means your client code can run loops more than 99 times so long as they do not run out of resources {{em|and}} that they will run properly even with modules that detect how they are loaded and provide a different package interface when loaded via {{code|require}} than with {{code|#invoke}} (it is also trivial to detect {{code|mw.loadData}} but that is sort of a moot point from your perspective as it can only return static data that cannot be executed). So yes, your {{code|newChild}} hack is somewhat faster but it is also buggy and your clients will half to take that into account. I am assuming ([[Module:Params]] is long with lots of indirection; I did not read through all of it) you are calling both {{code|newChild}} and {{code|callParserFunction}} off the parent frame to keep that in tact for the target module. —[[User:Uzume|Uzume]] ([[User talk:Uzume|talk]]) 11:39, 12 July 2025 (UTC)
:::::::::::[[Module:Params]] claims it is not designed to be used from other modules via {{code|require}}. To that end it could detect how it is loaded and provided a different interface when loaded via {{code|require}} keeping people from accessing it in such a manner (or fixing it so it does provide useful functionality under such conditions). —[[User:Uzume|Uzume]] ([[User talk:Uzume|talk]]) 11:39, 12 July 2025 (UTC)
{{outdent|:::::::::::}} @[[User:Uzume|Uzume]]: Uh right. With this module being invoked via wikitext, the information that the second module (e.g. [[Module:String]] in my examples) has not been called via <code>require()</code> should be propagated and inherited, right (even if we actually call that via <code>require()</code>)? As for <code>:newChild()</code>, I was wondering if a solution like <code>frameTools.makePseudoFrame()</code> found [https://dev.fandom.com/wiki/Global_Lua_Modules/FrameTools here] could solve everything. The 99 parameter limit comes from a limitation in the number of child frames that can be created, however we don't really need so many child frames, since they are all identical except for one or two parameters. The ideal solution would be that they make the <code>frame.args</code> metatable editable upstream, so that we stick to one. Lacking that, I was wondering if we could use the “pseudo frame” object mentioned in that wiki. --[[User:Grufo|Grufo]] ([[User talk:Grufo|talk]]) 10:32, 13 July 2025 (UTC)

:@[[User:Grufo|Grufo]]: You mean will the [[Fandom (website)|Fandom]] {{code|makePseudoFrame}} from [[CentralWikia:dev:Module:FrameTools|Module:FrameTools]] (with the documentation you mentioned at [[CentralWikia:dev:Global Lua Modules/FrameTools|Global Lua Modules/FrameTools]]) solve your problems? Yes...no and maybe. I am not exactly sure without testing but I think the concept is mostly sound. That said, it {{em|definitely}} introduces more caveats.
:There is no guaranteed your target module will even use the {{code|frame}} argument it is provided in the call as it can always fetch the real frame from {{code|mw.getCurrentFrame()}} and you are almost guaranteed that it will use such during package initialization if it wants access to the frame at all, because there is no other method for access (at that point the {{code|frame}} argument is not available as it is before the target function has even been indexed much less called because it is the initialization block that returns the package table the target function is indexed from). One common idiom I have seen here is a package function that uses a construction like {{code|lang=lua|1=if frame == mw.getCurrentFrame() then}} allowing the package function to potentially work under {{code|#invoke}} {{em|or}} {{code|require}} (I do not consider this practice as good as the example module I gave you but it does something {{em|somewhat}} similar in attempting to handle both situtations). Currently, a search of all EN Wikipedia Scribunto module code for {{code|getCurrentFrame}} {{sl|all: contentmodel:Scribunto insource:/getCurrentFrame/|yields 620 hits}}. Of those, I found this programing idiom at:{{div col|content={{ulist
|[[Module:Archive list alpha#L-329--L-337]]
|[[Module:Archive list#L-313--L-321]]
|[[Module:Armenian#L-10--L-18]]
|[[Module:BaseConvert#L-89--L-93]]
|[[Module:BellezzasoloUserPageModule#L-139--L-143]]
|[[Module:British regnal year#L-12--L-20]]
|[[Module:Csdcheck#L-24--L-36]]
|[[Module:Fixme#L-71--L-79]]
|[[Module:Japanese calendar#L-214--L-222]]
|[[Module:PageLinks#L-274--L-282]]
|[[Module:QuidAppearances#L-65--L-69]]
|[[Module:Random#L-298--L-304]]
|[[Module:Roman#L-98--L-106]]
|[[Module:Sandbox/Ahecht/interwiki#L-80--L-88]]
|[[Module:Sandbox/AlphaZeta/test4#L-25--L-29]]
|[[Module:Sandbox/Frostly#L-237--L-245]]
|[[Module:Sandbox/Hawkeye7#L-177--L-185]]
|[[Module:Sandbox/Mlkj#L-313--L-321]]
|[[Module:Sandbox/Retro#L-26]]
|[[Module:Sandbox/Szqecs/Adjacent_stations#L-164--L-168]]
|[[Module:Sandbox/Toohool#L-22--L-34]]
|[[Module:Track gauge#L-11--L-19]]
}}}}
:These all use {{code|getCurrentFrame}} and soon compare it to something with {{code|1===}} (oh, and be glad I did not spam you with all the {{code|/sandbox}} copies too). All of these will {{em|already}} fail with your {{code|newChild}} hack (unless you call {{code|callParserFunction('#invoke', ...)}} off the {{code|newChild}} frame but that sort of defeats your purpose for using it to begin with) because in Lua comparing two tables always fails unless they are the same table reference (i.e., {{code|1===}} does not do a "deep compare" to compare the table contents so it is only true if they are in fact the exact same table not a copy). And there maybe other modules that do such as well but hold the {{code|getCurrentFrame}} value and compare it in some other fashion or compare it at some later time, etc. I only looked briefly at the 620 search hit results. I did not look directly at the module code from all 620 hits. Incidentally, I also looked for comparison via {{code|1=~=}} but I could not find a single such usage which I find a bit odd as I would probably prefer that myself but apparently that is not popular. I almost never depend on the provided frame argument as it is not really reliable and {{code|getCurrentFrame}} is (although I suppose someone {{em|could}} attempt to [[monkey patch]] the {{code|getCurrentFrame}} field of the {{code|mw}} package table/global).
:Scribunto {{code|newChild}} actually calls into the PHP code to create a new [[mw:Manual:PPFrame.php|PPFrame]] object (notice its own PHP {{code|newChild}} method) that the MediaWiki parser and extensions, etc. can all use. Fandom {{code|makePseudoFrame}} does not appear to do this but just creates a fake one in Lua by copying fields from another Lua frame table. To that end, it is worse than {{code|newChild}} but from your perspective, I would say it is perhaps considerably better. Consider this: {{code|makePseudoFrame}} is probably no worse than {{code|newChild}} with regard to using it and {{code|require}} to fake a {{code|#invoke}}. Both have same caveat of not being the frame of an actual {{code|#invoke}}. However {{code|makePseudoFrame}} has the additional caveat of introducing potential issues for the target module if it uses the provided pseudo-frame to call back into MediaWiki (e.g., where do you think the parser will get arguments for parameter references like {{param|1}} in a {{code|preprocess}} call?). If you use {{code|newChild}} you are trapping those in the new PPFrame (which PHP does not let you change and this is why Lua does not let you change them either; this is also the source of the frame count limitation) so those references work (even if the target module {{code|could}} detect is is not actually being be called via {{code|#invoke}}). This is why I say {{code|makePseudoFrame}} introduces more potential caveats. On the other hand, it will likely be considerably faster as it does not call into PHP and it will not have the PHP frame count limitation (and you probably can write into its arguments although since it is a purely Lua table and its overhead is small you can probably just ensure it gets deleted and recreate it cheaply). My take on it is that if you are considering keeping your {{code|require}} based {{code|#invoke}} emulation, you would likely be better to switch from {{code|newChild}} to {{code|makePseudoFrame}}, however, I would encourage you to pursue a proper {{code|#invoke}} solution over the {{code|require}} based emulation. And at the very least you should rename and very clearly document that those functions in {{mlx|Params}} are {{code|#invoke}} emulations that have lower overhead but only work sometimes when the target module does not do much discrimination on how it is actually loaded (e.g., initialization block {{code|...}}), its provided frame arguments (e.g., comparing it to {{code|getCurrentFrame}}) or calling back into PHP in certain ways (e.g., {{code|preprocess}} with {{code|makePseudoFrame}}). —[[User:Uzume|Uzume]] ([[User talk:Uzume|talk]]) 16:12, 13 July 2025 (UTC)
:: Thank you for your incredibly detailed answer, [[User:Uzume|Uzume]]. What I don't understand is this: how is possible that if I want to call a module via <code>require()</code> + <code>:newChild()</code> I hit the &lt; 100 parameters limitation, whereas <code>#invoke</code> is able to bypass it? How does it do it? Shouldn't it suffer from the same PHP limitation too? I was thinking that maybe the best solution at the moment is to leave everything as it is and write about it in the documentation. I think so because this is the solution that gives the maximum freedom of choice. Currently if one wants to favour performance can use, for instance <code>...&#124;[[Module:Params#mapping_by_invoking|mapping_by_invoking]]&#124;...</code>, whereas if one wants to have the possibility of having 1000 parameters (at the cost of a slower solution) can use  <code>...&#124;[[Module:Params#mapping_by_invoking|mapping_by_magic]]&#124;#invoke&#124;...</code> --[[User:Grufo|Grufo]] ([[User talk:Grufo|talk]]) 17:35, 13 July 2025 (UTC)
:::@[[User:Grufo|Grufo]]: I took a brief look at your module's usage of {{code|newChild}} as well as {{code|makePseudoFrame}} (which can be directly compared with Scribunto's own </code>[https://github.com/wikimedia/mediawiki-extensions-Scribunto/blob/e93d49ff0570930922a25ca515068c89397ae5ae/includes/Engines/LuaCommon/lualib/mw.lua#L153-L456 newFrame]</code>). First, you should really consolidate your {{code|#invoke}} code whether it is an emulation or not (and while you're at it also encapsulate {{code|expandTemplate}} and {{code|callParserFunction}}; FYI: I do not like your usage of the word "magic" as it only supports parser functions not all types of magic words so you should really consider renaming those too). There is no reason to have five copies scattered around needing different maintenance.
:::How about a single invoker that takes an emulation parameter and either does a real invoke or emulates one? Then the caller can choose, and if you really get daring, the parameter can be more than a boolean specifying the emulation type, i.e., to what lengths should the emulation employ. There are some things I am not too thrilled with about {{code|makePseudoFrame}} (and I think I found a minor bug in it too). If you are serious about trying to maintain a {{code|#invoke}} emulator, I have some ideas on how to build a better mousetrap.
:::I am not sure if there is a good way to fake the environment for the module initialization block (e.g., {{code|...}}, etc.) as hacking that would probably have security implications and as such is likely locked down well but remember that it runs at a very different time to the execution of the package functions which get executed later either by Scribunto directly (i.e, via {{code|#invoke}}) or by Lua calls from module code, typically needing a {{code|require}} to get access to the package. If you look at {{code|newFrame}}, Scribunto's own frame object generation code, you might notice that they are generic tables without a metatable. Sure, the {{code|args}} field is another subtable and it is {{em|definitely}} metatabled but the main frame objects do not seem to be (of course someone might go and change things at some later date but at the moment that is true). To that end, it gave me an idea to help you with your emulation and potentiality alleviate your 99 frame limit whoas. Why not use real {{code|newChild}} but do it later only upon demand? Your code seems to proactively create a {{code|newChild}} at every emulated {{code|#invoke}}. If you instead, created a dummy table with a metatable and pass that in, you could wait until the target code actually tries to reference fields from the dummy frame and only {{em|then}} create the {{code|newChild}} upon demand and return values from there. This way if the target module never uses the dummy frame object, {{code|newChild}} is never actually called. You could also try and monkey patch the {{code|mw.getCurrentFrame}} to return the same dummy frame object fixing those situations I mentioned above. Of course if the target module does try to use its frame object, then you will be forced to call {{code|newChild}} and provide one so the number of iterations would be limited then. Since most modules at least attempt to use the frame {{code|args}}, you will likely want to handle that yourself avoiding the {{code|newChild}} call. You will likely want to handle {{code|getTitle}} and {{code|getParent}} (for its own {{code|args}}) too but in other cases you could punt to {{code|newChild}} upon demand. The code would likely be pretty tricky but it should work fairly well (except for possible initialization block issues referenced earlier). Just some ideas. —[[User:Uzume|Uzume]] ([[User talk:Uzume|talk]]) 18:30, 13 July 2025 (UTC)
:::: Thank you again, [[User:Uzume|Uzume]]. As for the nomenclature, I might agree that “magic” is a bit creative, but it has the advantage of being short. Any other solution was lengthier. But I am definitely open to suggestions, as long as they are coherent with the rest of the names. As for “consolidate my <code>#invoke</code> code” and “encapsulate <code>expandTemplate</code> and <code>callParserFunction</code>”, I am not totally sure I understood what you mean. As for creating a metatable and passing that, there is no way that the target module does not access its <code>frame.args</code> metatable in functions like <code>[[Module:Params#mapping_by_invoking|mapping_by_invoking]]</code>, so at least that will have to be a “fake” parameter table. I was thinking that I could create a single <code>:newChild()</code>, create a metatable, redirect all its fields except <code>frame.args</code> to that single child frame, and use a normal (always changing) table for <code>frame.args</code>. How does this sound? You might have just given me an idea to experiment with. --[[User:Grufo|Grufo]] ([[User talk:Grufo|talk]]) 18:58, 13 July 2025 (UTC)
:::::@[[User:Grufo|Grufo]]: By encapsulate I mean make a function or something so there is only one copy of the code to maintain and have everything that needs to accomplish that feat use that function (or class object, etc.). Your idea sounds like an interesting starting point but I do think you are going to run into many weird corner cases and you need to be {{em|very}} meticulous and methodical with your design and implementation. And I question the need for {{code|newChild}} if you are not planning to capture the args in an actual parser frame (because you keep changing them without a {{code|newChild}} for every change). What you are suggesting is very much like the Fandom {{code|makePseudoFrame}} (which does not bother with {{code|newChild}} {{em|because}} it does not capture the args in an actual parser frame). Of course doing that presents issues if the target module tries to call back into parser as the parser will then not know about those uncaptured args. Instead of "magic" why not just "pf" or "parserfunc" or some such. —[[User:Uzume|Uzume]] ([[User talk:Uzume|talk]]) 19:12, 13 July 2025 (UTC)
:::::: @[[User:Uzume|Uzume]]: <code>:newChild()</code> would be needed because the callback module might want to access other fields of the frame object (e.g. <code>:callParserFunction()</code>, or <code>:getParent()</code>, and in this way it will have the entire suite of fields ready. These remain constant for the entire duration of this module's invocation, so it makes sense that they always refer to a single child frame. The only thing that the callback modules can see changing is their <code>frame.args</code> field. --[[User:Grufo|Grufo]] ([[User talk:Grufo|talk]]) 19:20, 13 July 2025 (UTC)
:::::::@[[User:Grufo|Grufo]]: Even if they remain constant, why bother with {{code|newChild}} if you can get them from your own frame? Well the only thing they will see is the changing {{code|frame.arg}} {{strong|if and only if}} that is all they look at. You mentioned the target module might want other fields. What if it wanted say {{code|preprocess}}? The parser does not know about your changed uncaptured args so the {{code|preprocess}} has the possibility of rending incorrectly (e.g., parsing {{param|1}}, etc.) The point is, either capture the args with a real {{code|#invoke}} or {{code|newChild}} {{em|or}} don't and then there is no real need for {{code|newChild}}. Besides the functions themselves, a frame is really only a page name and a set of args. Sure you might be able to capture the title but if you are tweaking the args all the time, it would be very little work to handle the title yourself too. If you handle both, I do not see the point. What does even a single {{code|newChild}} buy you. I say very little under those circumstances. Of course it it is only one call so feel free to explore, but I really do not see the need. —[[User:Uzume|Uzume]] ([[User talk:Uzume|talk]]) 19:46, 13 July 2025 (UTC)
:::::::: @[[User:Uzume|Uzume]]: There are many little reasons why <code>:newChild()</code> is necessary. For instance in the callback module <code>frame.args</code> should return the parameters passed to the callback module itself, whereas <code>frame:getParent().args</code> should always return the calling template's parameters (I mean the parameters passed to the template that invoked [[Module:Params]]); or <code>frame:getTitle()</code> should return, for instance <code>Module:String</code>, whereas <code>frame:getParent():getTitle()</code> should always return the calling template's name, and so on. As for <code>frame:preprocess()</code>, you are possibly making a valid point (I should test it). --[[User:Grufo|Grufo]] ([[User talk:Grufo|talk]]) 23:54, 13 July 2025 (UTC)
:::::::::@[[User:Grufo|Grufo]]: But you can just pass back your module's parent frame for {{code|getParent}} and you already know the target module's full pagename as you need that to call {{code|require}} so you can easily implement {{code|getTitle}}. Anyway, I have not tested this at all however, I made a first try at creating an {{code|invoke}} function in [[Module:Sandbox/Grufo]]. I am not sure how robust it is but it should spoof {{code|args}}, {{code|getParent}} and {{code|getTitle}} while also monkey patching {{code|getCurrentFrame}} and never creating any frames until the target module attempts to access one of the other fields. Then it calls {{code|newChild}} and updates all the fields to stop spoofing things but just passing calls to the on demand created child frame. This will still have a 100 frame limitation if the target module uses those fields, but if it sticks to just those three that I have spoofed, it should never hit any such limit. It might be possible to spoof some of the other fields but they do not seem to be in much demand besides the ones that probably require calling back into the parser anyway. It also can do nothing about load detection in the target modules initialization block. It certainly has some key caveats but I think this should work for the vast majority of cases and be a little lighter on resources than doing many actual {{code|#invoke}} calls. Let me know what you think and if you try it out, etc. —[[User:Uzume|Uzume]] ([[User talk:Uzume|talk]]) 01:17, 14 July 2025 (UTC)
:::::::::: Thank you for your code, [[User:Uzume|Uzume]]. I have not tested it yet, but it seems to me that on demand (i.e. delayed) it creates a child frame for each callback, am I wrong?. This means that with functions like <code>[[Module:Params#mapping_by_invoking|mapping_by_invoking]]</code> it will hit the &lt; 100 limitation for sure, because these callbacks can never ignore the <code>frame.args</code> metatable. P.S. I started playing around with my solution, but so far I did not find a way to make the methods of the pseudo frame object work (none of them). Only the fields work. This happens because of [https://github.com/wikimedia/mediawiki-extensions-Scribunto/blob/a091b46d65cdccbdbae6c52ec79c4df12859c3e2/includes/Engines/LuaCommon/lualib/mw.lua#L164-L171 this restriction]. So I will have to find a way somehow to bypass it. --[[User:Grufo|Grufo]] ([[User talk:Grufo|talk]]) 04:04, 14 July 2025 (UTC)
:::::::::::@[[User:Grufo|Grufo]]: No, that is not how it designed to work. It creates the {{code|frameSpoof}} and passes that instead. It is filled with fields that are punting stub functions that will call {{code|newChild}} and then rewrite the stub functions to other stub functions that will use the created {{code|newChild}}. This way if the target module does access one of the unspoofed fields, {{code|newChild}} will be called from inside the target module by one of the punting stub functions but only once. But before I am done creating the {{code|frameSpoof}}, I overwrite the fields I want to spoof including {{code|args}}, {{code|getParent}} and {{code|getTitle}}. So target modules that only use those three fields will use those spoofed values and {{strong|never}} have {{code|newChild}} called. In fact, technically the target module is calling {{code|newChild}} when it calls one of the punting stub fields that are not spoofed. This is why the {{code|newChild}} is delayed. It is also why target modules that do not touch those other punting fields will never actually call {{code|newChild}}. We cannot control what the target module will do but we {{em|can}} respond to what it does do. So I wrote it inside-out which makes the code a little weird and maybe hard to follow. Once {{code|frameSpoof}} is completely constructed with its one-time punting stubs and three spoofed fields, I monkey patch {{code|getCurrentFrame}} to return my {{code|frameSpoof}} and then call the target module function and then immediately unpatch it before returning the value from the call to the target module function. Remember, you are not just spoofing the target module function. You are spoofing that and {{strong|everything}} it calls including other modules it loads and calls via {{code|require}}, etc. Your module's main use cases make it lean towards being used with other modules that have functions with fairly simple functionality (otherwise why call them repeatedly?). If those target module functions are simple enough to not trigger one of the {{code|newChild}} stubs in {{code|frameSpoof}} (i.e, one of the punt stubs vs. the spoof fields), they never need do any punting to {{code|newChild}} at all. —[[User:Uzume|Uzume]] ([[User talk:Uzume|talk]]) 06:46, 14 July 2025 (UTC)
:::::::::::: @[[User:Uzume|Uzume]]: I am amazed. But I have to admit that you lost me there. I will probably have to just study your code. But just as a quick understanding, if I were to implement <code>[[Module:Params#mapping_by_invoking|mapping_by_invoking]]</code> using your solution, and then I were to launch the following code (which calls {{mfl|string|replace}} 101 times),
:::::::::::: <syntaxhighlight lang="wikitext">{{#invoke:params|new|
	imposing|101||
	filling_the_gaps|
	mapping_by_replacing||true|1|strict|
	mapping_by_invoking|string|replace|4|^.*$|Hello!|1|false|
	for_each|[$#::$@]}}</syntaxhighlight>
:::::::::::: would I hit the &lt; 100 parameters limitation? --[[User:Grufo|Grufo]] ([[User talk:Grufo|talk]]) 13:48, 14 July 2025 (UTC)
:::::::::::::@[[User:Grufo|Grufo]]: Based upon my understanding and having studied [[Module:String]] (so I know it hardly touches its frame for anything other than {{code|args}}), I believe you should not hit such a limit (although you might hit others I am not sure). But of course such things need testing. I did some basic testing to make sure it appears to work in general. But I certainly did not test it to that extent. Also it {{em|really}} needs more input validation, etc. For example, right now, I could pass in some nasty things to {{code|modargs}} that are not strings, etc. But assuming one does not do anything crazy, I believe it should handle your situations fairly well. —[[User:Uzume|Uzume]] ([[User talk:Uzume|talk]]) 16:04, 14 July 2025 (UTC)
:::::::::::::: @[[User:Uzume|Uzume]]: Thank you. Some personal commitments got in the way, and I won't be free until the beginning of August (so I will just do ordinary admin tasks on Latin Wikipedia for the next days). But I want to get to the bottom of this. In the meanwhile, if you find a solution that never hits the &lt; 100 limitation, please make a whistle. The ideal would be that we found a way to create a <code>:newChild</code> only once. But unfortunately, due to [https://github.com/wikimedia/mediawiki-extensions-Scribunto/blob/a091b46d65cdccbdbae6c52ec79c4df12859c3e2/includes/Engines/LuaCommon/lualib/mw.lua#L164-L171 this restriction] using a custom metatable instead of the original frame won't work. And honestly at the moment I am in lack of frash new ideas. --[[User:Grufo|Grufo]] ([[User talk:Grufo|talk]]) 10:55, 16 July 2025 (UTC)
:::::::::::::::@[[User:Grufo|Grufo]]: Yes, I too noticed how the Lua frame object methods created by {{code|newFrame}} use their private {{code|checkSelf}} function to validate the passed in frame table {{code|self}}arguments preventing anyone from calling those functions without with passing in the exact table they were created for. This is probably why {{code|makePseudoFrame}} creates a bunch of stub functions like [[CentralWikia:dev:Module:FrameTools#L-76--L-84|this]] that punt/redirect calls to a passed in real frame object. It is also in part why I do something similar with regard to creating punting stub functions as well as replicate the {{code|checkSelf}} style code to propagate errors. That said, even without the {{code|checkSelf}} restrictions, passing in different frame objects probably would not work anyway due to the way they {{code|newFrame}} creates a [[closure (computer programming)|lexical closure]] for each frame method and each depend on their upvalues. —[[User:Uzume|Uzume]] ([[User talk:Uzume|talk]]) 07:32, 17 July 2025 (UTC)
:::::::::::::::@[[User:Grufo|Grufo]] You recently mentioned Postel's [[robustness principle]], in an entirely different context, but to that end I thought I would mention some things. I have improved my {{code|invoke}} emulation code at [[Module:Sandbox/Grufo]] including better monkey patching of {{code|mw.getCurrentFrame}} to allow it to be seen by the target module initialization block (i.e., {{code|require}}), completely saving and restoring {{code|package.loaded}} so it appears {{code|require}} was never called, and perhaps most importantly sanitizing the given {{code|modargs}}. Remember {{code|#invoke}} and {{code|newChild}} will provide a target module with {{code|frame.args}} that have stringent requirements. The passed in {{code|modargs}} are spoofed to the target module without going through such things so they need to emulate them closely or the target might get weird things it is not expecting, e.g., the target module might check {{code|args[1]}} but the given {{code|modargs}} might have a value like {{code|args['1']}} which would not be seen as the same (conversely {{code|modargs}} might have {{code|args[1.2]}}). BTW, I tried creating a proof of concept at [[Module:Params/sandbox]] by loading my {{code|invoke}} via {{code|require[[Module:Sandbox/Grufo]]}} and I ran into some major problems. [[Module:Params]] has {{strong|serious}} bugs. I wrote [[Module:Sandbox/Grufo]] to use [[mw:LUAREF#strict|strict]] to avoid inadvertent global reference bugs but it exposes them in [[Module:Params]]. You should really at least test with {{code|strict}} as you never know what your target modules may or may not call. If they are buggy and do not use it, you will break them if you use it, however, if they use it and your code is buggy they will break your code. So even if you chose to not use it in [[Module:Params]] itself, you should really consider testing with it turned on early to expose as many of your bugs as possible so that you won't have such things and the target module cannot break you by exposing such with {{code|strict}}, etc. —[[User:Uzume|Uzume]] ([[User talk:Uzume|talk]]) 04:57, 21 July 2025 (UTC)
:::::::::::::::: @[[User:Uzume|Uzume]]: Thank you a lot for helping with this and other modules. You will have to wait a few more days for me to have a look at [[Module:Params/sandbox]]. In the meanwhile I added the <code>strict</code> directive to [[Module:Params]], but [[Special:Diff/1297865432/1302040393|these]] were all the bugs I could find. Please let me know if you see any other bug! --[[User:Grufo|Grufo]] ([[User talk:Grufo|talk]]) 01:16, 23 July 2025 (UTC)
:::::::::::::::::@[[User:Grufo|Grufo]]: That is great. Thank you for fixing your issues related to [[mw:LUAREF#strict|strict]]. I was having problems trying to figure out what were the right fixes for those issues. I did find one more bug: [[Module:Params#L-1910]] {{code|fname}} should be {{code|mname}}. But this is related to your {{code|#invoke}} emulation paths so necessarily it will get fixed when converting to my own {{code|#invoke}} emulation code. To that end, I ported my sandbox proof of concept changes using my {{code|invoke}} emulation to the new active code (i.e., with your {{code|strict}} fixes) so now the proof of concept works and you can "look at" it when you get time. For example, this works: {{show|1=<syntaxhighlight lang="wikitext" inline>{{#invoke:params/sandbox|new|imposing|1025||filling_the_gaps|mapping_by_replacing||true|1|strict|mapping_by_invoking|string|replace|4|^.*$|Hello!|1|false|for_each|[$#::$@]}}</syntaxhighlight>|2={{#invoke:params/sandbox|new|imposing|1025||filling_the_gaps|mapping_by_replacing||true|1|strict|mapping_by_invoking|string|replace|4|^.*$|Hello!|1|false|for_each|[$#::$@]}}}} Cheers, —[[User:Uzume|Uzume]] ([[User talk:Uzume|talk]]) 13:38, 23 July 2025 (UTC)
:::::::::::::::::: @[[User:Uzume|Uzume]]: Good catch again! [[Special:Diff/1302041492/1302137674|Fixed]]! :-) --[[User:Grufo|Grufo]] ([[User talk:Grufo|talk]]) 16:11, 23 July 2025 (UTC)
:::@[[User:Grufo|Grufo]]: That is an easy answer. MediaWiki owns the parser and the parser {{em|knows}} about the entire parse tree (well eventually it does anyway otherwise it cannot yield a completely parsed page and that is really the parser's main job). So even though you can use {{code|newChild}} to {{em|create}} a parser frame object, you do not really know when it is safe to {{em|destroy}} it and so Scribunto does not provide access to a frame destructor for frames. The parser {{em|does}} know so it merrily goes along creating and destroying them. If you call {{code|#invoke}} 200 times, so long as there is no dependency requiring the frames to continue to exist, MediaWiki destroys them (if you created a tree of recursions where each frame created more frames there would be dependencies and the frames would have to live longer). In this way, so long as nothing hits imposed resource limitations all is good. Since the main parser is unlikely to need {{strong|many}} frames at any single point in time, there is a limit imposed on them and you found it: 100. Since you cannot pass back unparsed text from Scribunto, I imagine the parser will quite quickly destroy all the frames you created with {{code|newChild}} upon exit of the {{code|#invoke}} to your module. This means you can batch such things, e.g., you could assume you can create 50 {{code|newChild}} frames without issue, then you could have some code that processes no more than 50 iterations and have your main code {{#invoke}} back into your own module where that entry point just does the 50 limit max and returns. Then your main code could get control again and keep doing this until the request is complete no more than 50 at a time. In fact the {{code|callParserFunction('#invoke', ...)}} route could be views as a "do only one iteration at a time" batch processor. —[[User:Uzume|Uzume]] ([[User talk:Uzume|talk]]) 19:00, 13 July 2025 (UTC)
:::: Now it is all clear. Thank you! --[[User:Grufo|Grufo]] ([[User talk:Grufo|talk]]) 19:04, 13 July 2025 (UTC)