Check for unknown parameters

Suggested enhancement

Template:See also We are using this module on Module:WikiProject banner. We first check if Category:Pages using WikiProject PROJECT with unknown parameters exists and if not, then we use Category:WikiProject templates with unknown parameters instead. The problem is that this is causing thousands of links to non-existent categories to be recorded, which can be seen in Special:WantedPages. My suggestion is as follows. The module can accept an additional argument called fallback which is a category which will be used if the one specified in unknown does not exist. In this way we can check existence of that category only when unknown parameters are discovered, not in every single case. — Martin (MSGJ · talk) 14:19, 4 September 2024 (UTC)

What is it that I'm missing? If the problem is caused by something that happens in Module:WikiProject banner, that is where the fix should be applied. Adding miscellaneous one-off patches to this module is not a good idea. When you switch to the default category, you know that the preferred category does not exist so why link to it? Link to the preferred category only when it exists.

—Trappist the monk (talk) 15:35, 4 September 2024 (UTC)

I'll try and explain better. Or you can look at the code at around Module:WikiProject banner#L-831. We have to check existence before calling this module. Checking existence adds a link to the page. Therefore every transclusion of {{WikiProject Lepidoptera}} is generating a link to Category:Pages using WikiProject Lepidoptera with unknown parameters which is not so good. I would prefer to only check if the category exists if there are some unknown parameters. That check can only happen in this module. Or perhaps you have a better idea — Martin (MSGJ · talk) 21:02, 4 September 2024 (UTC)

I haven't taken any real time to study the code (it has taken me more time to write this than I spent looking at the code) but Module:Check for unknown parameters line 113 appears to return a concatenated string of unknown parameters (apparently without delimiters). If there are no unknowns then the <syntaxhighlight lang="lua" inline="1">table.concat(res)</syntaxhighlight> returns an empty string. So, it looks like <syntaxhighlight lang="lua" inline="1">p._check(args, pargs)</syntaxhighlight> returns:

nil when either of args and pargs is not a table

empty string when there are no unknown parameters

some sort of list of unknown parameters

If this is true then you should be checking the returned value from <syntaxhighlight lang="lua" inline="1">require('Module:Check for unknown parameters')._check(parameters, parent_args)</syntaxhighlight> before you fiddle about with categories.

—Trappist the monk (talk) 22:22, 4 September 2024 (UTC)

Great, thanks. I'll look into that — Martin (MSGJ · talk) 08:55, 5 September 2024 (UTC)

Yes that works. Unfortunately it means that I need to call the module twice: the second time after deciding which category to use. But this will only happen if there are any unknown parameters so will not affect performance unduly. — Martin (MSGJ · talk) 09:06, 5 September 2024 (UTC)

Add comments to your code. When you are crushed by a steamroller while jaywalking Main Street, whoever comes after you to maintain that module can then know why you did what you did.

—Trappist the monk (talk) 11:48, 5 September 2024 (UTC)

Bulk include all mapframe parameters

Rather than having to copy and paste all 20+ Module:Infobox mapframe parameters into the check at the bottom of the page, I’m wondering if we can add a hook of some kind? Something like |mapframe_params=on that will automatically include the hardcoded mapframe parameters? Alternatively could we create a {{Infobox mapframe/parameters}} that is just a list of parameters and then pass that in? IF the parameters for Module:Infobox mapframe were to change for some reason, that would involve updating a LOT of infoboxes. This would make that process easier. —Zackmann (^{Talk to me}/_{What I been doing}) 22:23, 30 September 2025 (UTC)

Sounds sensible — Martin (MSGJ · talk) 07:47, 1 October 2025 (UTC)

Template:Ping I know you put a lot of work into this module. Any thoughts?

Also a quick search reveals that at least 100 templates use Module:Infobox mapframe so it would definitely help. Zackmann (^{Talk to me}/_{What I been doing}) 09:28, 1 October 2025 (UTC)

Template:U this seems reasonable, so long as this is the only module that we are supporting. if there are going to be multiple modules that we want to support, we could provide a link to a data page. something like |params_data=Module:Infobox mapframe/parameters or |params_data1=Module:Infobox mapframe/parameters or whatever. back in the early days of this module, it was suggested that it would be more efficient if the list of parameters lived in module space and were loaded using mw.loadData but this would only really help if the template using this module were being called multiple times on each page, so not as big of an issue for infoboxes. Frietjes (talk) 14:54, 2 October 2025 (UTC)

I’m a fan of either solution. I guess the second solution provides support for future expansions better but that could always been performed as a refactor down the line if needed. Zackmann (^{Talk to me}/_{What I been doing}) 18:06, 2 October 2025 (UTC)

Template:Ping I have mocked up a solution in the sandbox. Not married to the parameter names of course but I did do some testing in my own sandbox and it seems to work just fine. All I did was {{#invoke:Check for unknown parameters/sandbox|check|mapframe_args=y}}.

Now there is a drawback I noticed... If you look, for example, at {{Infobox zoo}} you will see in the implementation the following:

The significance of this is that some of those parameters, |mapframe-marker=, |mapframe-width= and a few others are NOT valid parameters to be passed in to {{Infobox zoo}} as they are hardcoded in the Infobox code.

So we are left with a few options

1. Use |mapframe_args=y and just not care that there are a few extra params included (seems like a slippery slope to me but probably not a big deal)
2. Don't use the |mapframe_args=y and go back to the old school way of copying and pasting all the params in the check for unknown list
3. Add an additional |_exclude= which takes a CSV of mapframe_args to NOT pass to the check. (This idea takes from Module:Template wrapper.)

Let me know your thoughts. Happy to experiment with option 3 if there is interest. Also if this is implemented, I'll commit to updating the necessary documentation as well as taking on cleaning up the actual calls to the module so the new param is used. --Zackmann (^{Talk to me}/_{What I been doing}) 07:06, 6 October 2025 (UTC)

Template:Ping you may not be understanding the obscure way that Module:Infobox mapframe is parsing the arguments with getArgs in autoArgs(). the parentFirst=true flag is set, so that the parameter passed into {{Infobox zoo}} overrides the parameter provided in the template code itself. In other words, |mapframe-marker=zoo is simply the default. If |mapframe-marker= is set to something else, it will override zoo. This is true with any of the other parameters. Whomever wrote the template code didn't realize this. I'll fix the code to make it less obscure, but you don't have to do anything. — hike395 (talk) 12:18, 6 October 2025 (UTC)

Template:Ping thanks for the explanation! That dramatically simplifies things! I have struck my previous comments as they are no longer relevant. - Zackmann (^{Talk to me}/_{What I been doing}) 17:03, 6 October 2025 (UTC)