Page MenuHomePhabricator

Allow Scribunto code to add a category without changing output
Open, LowPublic


Sometimes Lua module is used with some obsolete parameters, and wants to create a category for all pages that use it in obsolete way. Other times Lua might simply want to add a category to the page. Regardless, adding "[[category:xxx]]" to the output is not ideal because there are many cases when it breaks final wiki markup (e.g. in the middle of the html atribute text.

I think there should be a frame::addCategory()

Event Timeline

To solve this question in central modules, I collect all categories in a table.
Then, just before return the wikitext, I place them after this wikitext.

To solve this question in central modules,

Which is entirely irrelevant to this task.

To delay categories at the end of the wikitext is a simple way.
If this way answer the question, is this task needed?

How frame::addCategory() can solve the question if it is in the same place in the html page?

That way is not the answer to the question. The method would probably be mw.addCategory() rather than being on the frame object, and would call $parserOutput->addCategory() rather than doing anything to the wikitext.

Collecting categories in a table as you go, and spitting the table out at the end of your output, is a workaround, and probably one of the most elegant workarounds, absent any other tools. Having some tool specifically for the job is probably preferable though (especially since it means editors don't have to be aware of the problem and its potential workarounds).

Change 585684 had a related patch set uploaded (by Agabi10; owner: Agabi10):
[mediawiki/extensions/Scribunto@master] Create mw.addCategory function in Lua

Could anyone think of any issues, to have categories but without their code in the final wikitext?

On a related note, this makes me think we could have a similar method in parser functions, i.e. {{#addcategory:<category name>|<optional sort key>}}.

Could anyone think of any issues, to have categories but without their code in the final wikitext?

Yes, it causes problems like T88797. Furthermore, Template:suppress categories exists and (obviously) cannot suppress categories added via a side channel.

That's correct. The template wouldn't be able to suppress those categories, but it's totally different of T88797, because the generated categories are controlled by the module author in this case and the categorization could be easily suppressed in the code with a parameter. Anyway using this function is completely optional, while the error category isn't.

@Agabi10 Did you give up on this patch? It looks really useful to me, and from the review comments it didn't look like there were any insurmountable problems (just maybe some documentable limitations due to the architecture context).