Module talk:Protection banner

Miscategorisation at Wikipedia fully protected templates

Extended-confirmed templates are currently erroneously being categorised into Category:Wikipedia fully protected templates. That category has a note "For technical reasons, this category also erroneously contains extended confirmed protected templates.", but neither that comment or its edit summary indicates what this "technical explanation" is. I presume this module is responsible for populating that category? Can this reason be explained? (ping @Mr. Stradivarius, in case you know) ProcrastinatingReader (talk) 16:52, 28 August 2020 (UTC)

@ProcrastinatingReader: It sounds like the module needs to be fixed, but I'm not sure of the exact fix needed yet. Do you have an example of a page that is wrongly categorised? — Mr. Stradivarius ^{♪ talk ♪} 00:56, 29 August 2020 (UTC)

And yes, the module is responsible for populating the category. In particular, the category list is in Module:Protection banner/config, about two-thirds of the way down. — Mr. Stradivarius ^{♪ talk ♪} 00:57, 29 August 2020 (UTC)

Mr. Stradivarius, examples: Template:Justice League characters, Template:Palestinian militancy attacks in the 1960s, Template:Gs/topics ProcrastinatingReader (talk) 01:29, 29 August 2020 (UTC)

Very quick glance at 30 secs of reading the comments in the config, but perhaps the issue is just that we don't have a Category:Wikipedia extended-confirmed protected templates and thus it's resolving up the ladder to the fully protected ones? A complete and utter guess, though, probably wrong... ProcrastinatingReader (talk) 01:32, 29 August 2020 (UTC)

Hmm, looks like Mdaniels was working on something similar a few months ago. I've made a slight adjustment to the config sandbox, perhaps this will work? Not quite sure how to test, though. I tried changing the version at Template:Palestinian militancy attacks in the 1960s to the sandbox v, but it isn't overriding (I'm guessing the template namespace does some kind of autodetect to insert the lock, hence overrides my manual one). And on that note, just wondering, why does {{Pp-extended}} exist rather than just using {{Pp}} (which is used for all other protections & at least in source appears to do the same thing as the former?) ProcrastinatingReader (talk) 01:47, 29 August 2020 (UTC)

@ProcrastinatingReader: It looks like your edit did the trick, and you are right, it is just a matter of editing that table so that extended-confirmed-protected templates don't fall through to the default case. The best way to test would be to add some new tests to Module:Protection banner/config/testcases. Unfortunately, previous editors have edited the config without updating the test cases, so we will need to fix the existing test cases as well. For live testing, I recommend User:Jackmcbarn/advancedtemplatesandbox.js, which you can use to test the sandbox out on live pages without updating the main module. — Mr. Stradivarius ^{♪ talk ♪} 01:57, 29 August 2020 (UTC)

That script is handy, I think C&C recommended it to me a little while ago actually but I forgot about it. Synced the update and it seems to be populating the category (awfully slowly, not too sure how the software decides when to update the categorisation). Also fixed most of the testcases. Very, very well documented modules by the way. Most paid code I come across has far worse documentation. I'm actually somewhat surprised you're not professionally a developer. ProcrastinatingReader (talk) 17:16, 29 August 2020 (UTC)

@ProcrastinatingReader: Thank you for updating the module, and for fixing the test cases! It is much appreciated. I think you do need the second hyphen in the category name, though: "Wikipedia extended-confirmed protected templates" with one hyphen translates to "protected templates that are extended-confirmed" (whatever that may mean); "Wikipedia extended-confirmed-protected templates" with two hyphens translates to "templates which have extended-confirmed protection", which I think is the one we want here. — Mr. Stradivarius ^{♪ talk ♪} 14:08, 30 August 2020 (UTC)

Mr. Stradivarius, that change is fine with me. By the way, I was looking to find a fully protected page and came across Category:Wikipedia fully protected pages. Every article directly in this category isn't fully protected, which confused me a bit. Then I realised they're redirects. We tend to put the redirects into Category:Fully protected redirects, which has 1,375 members. Any idea why some are also/instead being categorised into the former category, which only has 553 members? I think it may be because they're also move protected (the few examples I checked are also in Category:Wikipedia indefinitely move-protected pages), but if that's the case I guess we need an extra config case to catch these so they're not falling into the generic category. If my guess is correct, do we want to just change the config case to |all (rather than |edit), or do we want to create a separate category for fully-protected moves?

My side question is, why is the module adding them to multiple categories? I know that's good behaviour, but what's the code logic behind it? Is it looking for a category for each type of protection separately (as in: edit/move are put through the hierarchy for a category separately)? ProcrastinatingReader (talk) 14:18, 30 August 2020 (UTC)

After some further digging, this looks like a mess (but not on the part of this module). Looks like this module isn't responsible for the fully protected redirects category, that's done manually and the category added by redirect templates like {{R fully protected}}. So we have some redirects which aren't tagged with a lock and only in the latter cat, and other articles which are only tagged with the lock, and thus only in the fully-protected category. The ones tagged with both the template and the lock being placed in both. This kinda makes the tracking categories an inconsistent mess and a bit useless as a result, really. Not sure what the best way to clean this up is? I know we can check for redirect using Lua, so we can always add that in, but not sure what the performance impact would be? We'd probably need a bot to fix pages like the one I linked, too? ProcrastinatingReader (talk) 14:30, 30 August 2020 (UTC)

@ProcrastinatingReader: I've made the change to add the extra hyphen, so the pages should start to slowly filter over to the new category. To answer your earlier question, the updating is done by the job queue, which can be very slow for category changes caused by a template edit. I've seen it take months before. As for the multiple protection categories, this module only adds one protection category per #invoke, but there can be multiple protection templates on a page, and as you found, there are other templates which add protection categories as well. To fix this in an elegant way, we would probably need to make a separate module for generating protection categories which can be called from all of the different templates involved. — Mr. Stradivarius ^{♪ talk ♪} 15:04, 30 August 2020 (UTC)

Mr. Stradivarius, hmm, in the case of this what's adding the lock (in read mode)? And why is that thing not adding the lock here? These look quite similar to me? ProcrastinatingReader (talk) 15:07, 30 August 2020 (UTC)

@ProcrastinatingReader: That's Template:Rcat shell, which is calling Template:pp-protected based on the edit protection level. — Mr. Stradivarius ^{♪ talk ♪} 15:14, 30 August 2020 (UTC)

Mr. Stradivarius, I see. Isn't the easiest way to clean this up just to remove {{pp-protected|small=yes}} from {{Rcat shell}}? Then it would only call {{R fully protected}}, which adds the proper category. The only issue would be the lack of lock, then, but we can fix that by adding, to {{R fully protected}}, something like: {{pp|small=yes|category=no}}. ProcrastinatingReader (talk) 15:35, 30 August 2020 (UTC)

No, don't remove it. That would undo the work carried out by myself and others (such as Paine Ellsworth) over the last few years to try and eliminate the use of dedicated templates that only apply to a specific prot level. So when a page has {{rcat shell}} it should not also have any other protection template, not even {{r protected}} or similar. The thing about {{pp-protected}} is that it autodetects the prot level and doesn't need adjusting when a page is raised from semi-prot to full-prot, etc. If you find a page (redirect or otherwise) in the "wrong" protection category, first apply a WP:NULLEDIT and see if that resolves it. --Redrose64 🌹 (talk) 09:28, 31 August 2020 (UTC)

Redrose64, these are in the wrong categories due to an inherent bug in the templating. Null edits won't resolve the issue (also, I can't null edit a fully protected page). Please see discussion above. The change I suggested shouldn't defy your efforts. {{r protected}} accounts for other protection levels as well, and so moving {{pp}} into there for this case wouldn't cause any negative effects as far as I can see. If you're seeing something I'm not, please elaborate. To be clear, I'm only proposing moving it for the fully protected case (which necessarily calls {{r protected}}, so this doesn't cause any omissions). There's absolutely no scenarios I can see where this goes wrong? See sandboxes for example. ProcrastinatingReader (talk) 20:17, 31 August 2020 (UTC)

Well PR, seems you're coming in on an old problem we've been noticing and trying to fix for several years now. On this talk page alone it goes back at least to 2016 and when {{Redirect category shell}} was the {{This is a redirect}} template. This challenge applies not just to Extended-confirmed-protected but also to others like the {{-r}} redirect, which is template-protected. There appear to be so many layers of this issue that some seriously good admins and template editors, as well as Lua experts have tried to fix it and then apparently put it off to tackle more serious challenges that come up. It's a really tough nut to crack, so I wouldn't get my hopes up for a solution any time soon. However, I myself do hope that it will eventually be well-resolved. P.I. Ellsworth  ed. ^put'r there 12:01, 1 September 2020 (UTC)

Paine Ellsworth, do you see any flaws with my proposed solution? Obviously it would only affect the niche case of fully-protected redirects using one of the two templates (not the other ones, which would remain as broken as they are now), but since I cannot see it causing any issues for that case I think my solution it's better than nothing, and at least it would make the fully-protected category less useless for other purposes. Noting that the shell necessarily calls {{r protected}} makes this an easy case to solve, I think. ProcrastinatingReader (talk) 12:08, 1 September 2020 (UTC)

You appear to be looking to remove the {{pp-protected}} template from the shell, thus changing:

{{#switch: {{PROTECTIONLEVEL:edit}}
   |sysop={{pp-protected|small=yes}}{{R protected|embed=yes}}
   |templateeditor={{pp-protected|small=yes}}{{R template protected|embed=yes}}
   |extendedconfirmed={{pp-protected|small=yes}}{{R extended-protected|embed=yes}}
   |autoconfirmed={{pp-protected|small=yes}}{{R semi-protected|embed=yes}}

to:

{{#switch: {{PROTECTIONLEVEL:edit}}
   |sysop={{R protected|embed=yes}}
   |templateeditor={{pp-protected|small=yes}}{{R template protected|embed=yes}}
   |extendedconfirmed={{pp-protected|small=yes}}{{R extended-protected|embed=yes}}
   |autoconfirmed={{pp-protected|small=yes}}{{R semi-protected|embed=yes}}

is that correct? And then further, to get back the lock icon that would be lost, you propose to insert the {{pp-protected}} template into the {{R fully protected}} rcat template? Where exactly would you insert it? P.I. Ellsworth  ed. ^put'r there 12:38, 1 September 2020 (UTC)

Paine Ellsworth that's correct. For your question, see Template:R fully protected/sandbox. Both sandboxes are updated with the change I'm proposing.

(the second option is to keep both templates as-is, but just add a |category=no to the shell. This works the same to fix our categorisation issue, but since currently half the fully-protected redirects don't use the shell, they don't have the lock. I think the above approach is better so we have the lock in all cases, as well as fixing categorisation). ProcrastinatingReader (talk) 19:43, 1 September 2020 (UTC)

Like you, PR, I'm unable to test your changes on fully-protected redirects; however, I can test the changes on template-protected redirects and found that they are removed from Category:Wikipedia template-protected templates when the {{Redirect category/sandbox}} is used. This leads me to think that your changes will accomplish what you want them to do. One problem is that your changes did not remove the template-protected redirect from Category:Wikipedia fully protected pages, and that is one of our main issues. So your solution might very well be a good partial fix (that would need testing by an admin to confirm); however, it does not address other important issues I have with incorrect and improper categorization as I've raised elsewhere on this talk page. P.I. Ellsworth  ed. ^put'r there 10:18, 2 September 2020 (UTC)

Thanks for testing, Paine Ellsworth. That problem you note unfortunately won't be fixed by these changes, as this modification in the same way applied to TE redirects won't work in the same way. That would require a new rule in the module and some modifications to the templates, I believe, but I haven't looked into the case of TE redirects closely, thus only propose a change for the full-protected redirect case. May look into the other cases later on. The issues in others should also become more apparent once the fully-protected cat isn't polluted with nonsense.

I've tested my changes on Alissa (a fully-protected redirect) using the templatesandbox script suggested above, and it does correctly categorise this redirect. If any admins wish to test further, on the live redirect by changing it to the sandbox, that'd be great. Otherwise, I think there's sufficient evidence to make this relatively straight-forward change in the coming days, if no objections to the technical details are made. ProcrastinatingReader (talk) 11:38, 2 September 2020 (UTC)

You're welcome, ProcrastinatingReader! Yes, it would be very helpful if the admins who've been working on this would test the FP redirects with the sandboxed code. Another question I have would be what do you think would happen if, instead of placing {{pp|small=yes|category=no}} in the {{R fully protected}} rcat, what would be the difference if we just added the |category=no parameter to the existing {{pp-protected}} template (which of course redirects to template {{pp}}) in the {{Rcat shell}}? Would that accomplish the same thing? or do you think there would be different results? P.I. Ellsworth  ed. ^put'r there 12:14, 2 September 2020 (UTC)

Paine Ellsworth, in terms of categorisation, it would be exactly the same result. However, a lot of fully-protected redirects do not use the shell, and instead only use {{R fully protected}}. As a result, they don't have the lock icon in the top right. I think the approach suggested would also correct this 'error' (if you like) by adding the lock in those cases too, and I think the lock should be there, so my initial thoughts were that this instead is a better approach. As you (and others) have dealt with this issue over a longer period of time than I, I'd be interested to hear your thoughts on this matter. ProcrastinatingReader (talk) 12:33, 2 September 2020 (UTC)

I would support adding the pp template to the fully-protected rcat as an interim solution, and I would also support adding the |category=no parameter to the shell for all the protection templates in the shell. May as well add the pp template to {{R template-protected}}, {{R extended-protected}} and {{R semi-protected}} as well, because when those are used without the shell, they too do not add a lock to the top of the redirect page.

A better solution in the long run might be for a bot to find all of the protected redirects and replace the protection rcats with the rcat shell; however, some editors might complain if other appropriate rcats are not also added to justify the use of the shell. And that could not be facilitated by a bot. That would have to be done manually, which would take an army of Wikignomes to accomplish. < sigh > P.I. Ellsworth  ed. ^put'r there 13:29, 2 September 2020 (UTC)

I will look into those templates too, when I have a chance, to confirm there would also be no adverse affects of doing so. I agree we need a better solution to really address all components of this issue. I raised the idea of a bot above. Issue is that neither of us could operate the bot (it would have to be adminbot to edit fully-protected redirects). Not sure of many active admins who have experience & interest in this area, so unless you would like to put in an RfA and operate it I think the bot point is moot. WikiGnomes (even if logistically possible) wouldn't help for same reason, fully-protected edit requests take forever to process (and I've only seen 1 or 2 admins who actively attend to them). Unlikely 1000 of them would be done. Even if they could be, it's double the amount of time taken per redirect (time of proposer + time of admin reviewer). ProcrastinatingReader (talk) 15:01, 2 September 2020 (UTC)

Move-protected

Mr. Stradivarius, thoughts on what to do about move-protected pages to a non-sysop level? Currently, they just default up the chain to Category:Wikipedia fully protected pages. I saw a testcase for this that was failing, so I made Special:Diff/976938143, but really this seems wrong. Doesn't exactly make sense to categorise TE move-protected into TE. We do have categories for sysop move protection, eg ['all|template|all|sysop|move'] = 'Wikipedia move-protected templates', but none really for lesser move protection, and it kinda seems somewhat silly to have "Wikipedia template-editor move-protected templates"? Hence, not sure what solution would be best here. ProcrastinatingReader (talk) 19:11, 6 September 2020 (UTC)

Why not introduce a separate category tree for move-protection? From Wikipedia:Move protection it is unclear, how many different levels of move protection there is except fully move-protected pages. Other relevant bits:

• Fully edit-protected pages are also implicitly move-protected.
• All files are implicitly move-protected; only file movers and administrators can move files.

—⁠andrybak (talk) 21:38, 6 September 2020 (UTC)

• I think in theory you can move protect to all levels, but for the most part non-sysop move-protection not matching edit protection is quite a rare scenario. It happens on some mainspace pages (usually to ECP move), there's a couple templates that have this (edit=semi, move=TE). I think many of them are IAR actions, rather than codified in guidelines, but reasonable protections nevertheless. A move category tree is one idea, yeah, and not awfully difficult to implement, at least in the module. There's a bunch of scattered templates that would need to be double-checked, as well. It would be worth noting that if we did that, stuff like Category:Wikipedia move-protected templates should probably be a cat containing child cats only, so we'd have to make sure no bots are going to be troubled by that. ProcrastinatingReader (talk) 22:02, 6 September 2020 (UTC)

(edit conflict) To ProcrastinatingReader: I'd also like to hear thoughts from Redrose64, Martin, Anomie⚔, wbm1058, xaosflux and Jackmcbarn that would be helpful on this issue. As a "tough nut to crack", we need all the help we can get. P.I. Ellsworth  ed. ^put'r there 21:48, 6 September 2020 (UTC)

@Andrybak: Move protection has exactly the same five levels as edit-, upload- and create-protection, i.e. none, semi, EC, template and full. However, since IPs and unconfirmed editors cannot move pages, a page with no move protection is effectively semi-protected for moves. It is rare to have a page that is explicitly semi-prot for moves but has no edit protection; these are usually mistakes and, when discovered, are often reduced to having no move protection for the sake of tidiness. --Redrose64 🌹 (talk) 11:10, 7 September 2020 (UTC)

Userspace scripts

We've got a lot of cat pollution where someone adds a userspace script and chucks a // {{pp-template}} or something into their css/js files, causing a gold lock and sysop-protected categorisation (eg User:GoldenRing/common.js, User:BeywheelzLetItRip/common.css, User:AHollender (WMF)/sandbox/2019–20 coronavirus pandemic data/2019–20 coronavirus pandemic data/styles.css, etc). Rather than have IAdmins constantly removing this stuff, perhaps it's a good idea for this module should just not show lock or categorise (basically just skip) any .js/.css files in userspace (which are all IAdmin protected, globally)? ProcrastinatingReader (talk) 22:15, 6 September 2020 (UTC)

Done in sandbox if anyone wants to take a look. ProcrastinatingReader (talk) 22:38, 6 September 2020 (UTC)

I took a look at the code. It looks basically good - thanks for contributing it. :) There are a couple of things I would change:

• Instead of having the code in Protected:isProtected(), I would put it directly in Protection:makeCategoryLinks(), or maybe better, put it in a dedicated Protection:shouldBeCategorized() method and call that from makeCategoryLinks. Saying user .js or .css pages aren't protected when they effectively are protected is a bit confusing, and I think that moving the code would make the intention more explicit, and maybe avoid future bugs.
• It could do with some test cases at Module:Protection banner/testcases.

Best — Mr. Stradivarius ^{♪ talk ♪} 15:32, 7 September 2020 (UTC)

Mr. Stradivarius, thanks for reviewing! Re bullet 1: I popped it into :isProtected() to also stop it showing the lock, as well as stopping the categorisation, since my thought was that showing a gold sysop lock on these types of files seems slightly misleading & undesirable. Also seemed like a good idea to pop them into the "wrong categories" cat to have their // {{pp-template}} removed seemed like a good idea. Easiest way to achieve all points was to edit :isProtected(). Of course, open to thoughts on if any of these fixes are themselves undesirable. ProcrastinatingReader (talk) 16:11, 7 September 2020 (UTC)

@ProcrastinatingReader: I see - if we need to suppress the padlock icons as well, then I agree that :isProtected() is a very convenient place to add the code. I think the problem is just one of naming, then, which I had a go at tackling in the sandbox. I couldn't think of a good name for a method that means "the template should output a protection category, and a banner/padlock icon", though, so I cheated by making an alias. There's probably a better way of doing it. Also, I fixed the test cases, which appeared to have been broken for quite some time. — Mr. Stradivarius ^{♪ talk ♪} 14:24, 8 September 2020 (UTC)

Mr. Stradivarius, looks good to me! ProcrastinatingReader (talk) 19:27, 9 September 2020 (UTC)

Mr. Stradivarius, is this good to merge into live? ProcrastinatingReader (talk) 19:08, 15 September 2020 (UTC)

@ProcrastinatingReader: Not yet - there are some test cases missing, and I noticed an edge case that the user JS/CSS code needs to cover (i.e. user pages only have the JS/CSS content type if they are a subpage; User:Foo.css would be a wikitext page). — Mr. Stradivarius ^{♪ talk ♪} 00:20, 16 September 2020 (UTC)

Interesting. Technically those pages could be CSS too, if manually changed. The best way to check all would be to use contentModel I guess, but it’s a “maybe expensive function”; a check on the page title will probably handle 99.9% of cases. ProcrastinatingReader (talk) 09:54, 16 September 2020 (UTC)

Using the content model shouldn't be a problem, as we would only be making one expensive function call. And I'm guessing the result would be cached per page, so there would probably still be only one expensive function call even if we have multiple #invokes on a page. — Mr. Stradivarius ^{♪ talk ♪} 04:19, 19 September 2020 (UTC)

Also, checking the docs, it looks like fetching the content model for the current page doesn't count towards the expensive function count, so it shouldn't actually have any effect. — Mr. Stradivarius ^{♪ talk ♪} 07:18, 19 September 2020 (UTC)

I've just put the code up live - let me know if you notice any issues. — Mr. Stradivarius ^{♪ talk ♪} 13:07, 19 September 2020 (UTC)

Mr. Stradivarius, looks good right now. Am curious about one thing. I know categories don't update with contents immediately, but I thought a purge with forcerecursivelinkupdate on the page immediately updated that? Tried on a couple but they don't disappear from Category:Wikipedia fully protected pages for some reason - any idea? ProcrastinatingReader (talk) 18:33, 19 September 2020 (UTC)

It's not worked for months, if not longer: see Wikipedia:Village pump (technical)/Archive 181#Sending a POST to the API to purge. --Redrose64 🌹 (talk) 21:45, 19 September 2020 (UTC)

Redirect sub-categorisation

Category:Fully protected redirects is a little useless for maintenance purposes, because it has 1,500 members with no subcategories. Ideally this should be split up, e.g. redirects of alternate name of a BLP, redirects protected due to vandalism, project redirects pre-emptively protected, etc. Discussed briefly above in Module_talk:Protection_banner#Categorization_of_protected_redirects, Mr. Stradivarius gave 3 options which I also think are the best few. I think it can easily be done with this module. We could create a bunch of wrappers and get around the named caveat by adding a title check for isRedirect if the wrapper is for a redirect (probably easiest option). These would use the reason key. It would also keep per-namespace options open, but we wouldn't be able to use normal banner data (could get around this by having a -redirect suffix in reason for cat, but fetching data from parent for lock). There's also option 3 of making a redirect key in the algorithm, but that's maybe a bit of work (Mr. S or Jack might know best). ProcrastinatingReader (talk) 14:53, 7 September 2020 (UTC)

Update

Making a bit of a laundry list of protection category 'issues', feel free to add/change. I guess we can figure out solutions from there. Paine Ellsworth may be interested? Re. redirects, I know Mr. Stradivarius suggested above the ideas of Add redirect detection as a full-blown key to the protection category algorithm, or a new module to deal with redirects. I also had an idea of suffixing -redirect to the reason. I think the adding to algorithm approach is best, the issue overlaps into non-redirects and I think it's easier than having a near-duplicate module. However, I think it may also just be better to cut our losses, focus on fixing & having categorisations based mainly on protection level and duration (indef/temp), and suggesting Petscan if one wishes to get useful stuff out of them. For example, to figure out extended confirmed protections NOT DS one can use the "has none templates", on talk page, of "ArbCom Arab-Israeli enforcement" + [...]. ProcrastinatingReader (talk) 17:20, 26 September 2020 (UTC)

In both cases, here's some issues:

• Category:Wikipedia move-protected pages needs to be able to handle non-admin move protections (currently they just go into the fully-prot cat). But since each run of the module only categorises once, it would require completely changing the category tree structure I think (like the standard protections) to make this work smoothly? Or, we can just mash everything up into one move-protected category per protection level (ditch the namespace stuff) and suggest Petscan for namespace categorisation (likely the easiest option?)
• Category:Wikipedia protected biographies of living people is ineffective, and hence it (and its subcategories) nearly empty. Admins rarely use {{pp-blp}}, Twinkle just adds {{pp-30-500}}, e.g. Sushant Singh Rajput, with a protection reason usually including "Violations of the biographies of living persons policy" (but not always). A few things a bot can do here, but I note that Petscan can also be used for the same purpose, so do we just want to scrap {{pp-blp}} and only categorise by protection level instead? It seems to at least be used for semi-protections, but I wonder how many semis are just mashed up in other cats, like Category:Wikipedia semi-protected pages (a lot, at a glance). Similar issue with Category:Wikipedia extended-confirmed-protected pages.

To ProcrastinatingReader: yes, I'm very interested and watching all this closely. Much of it seems above my pay grade and ken, but I read and watch anyway hoping this will be resolved by those who know more than I do about these things. P.I. Ellsworth  ed. ^put'r there 15:57, 27 September 2020 (UTC)

Catonly

@Mr. Stradivarius: I made a change to sandbox that adds a parameter called "catonly". If it's "yes", then the banner/padlock will be hidden and only the category will be provided. Added 2 testcases which pass. This would implement this TfD. Is that good to go? ProcrastinatingReader (talk) 19:47, 15 July 2021 (UTC)

@ProcrastinatingReader: Thank you for implementing this! I really appreciate it when someone takes the time to write test cases. :) Looks like you forgot to sync the latest changes from the main module (see the diff), so you should resync and check that your changes still pass the unit tests. We could probably do with another test case to show that a padlock icon is shown when |catonly=no. And maybe a similar one for categories if you want to be thorough. Also, I see that you're duplicating the UNIQ...QINU pattern to detect strip markers - that should probably be made its own variable, in case it needs to be changed in the future. The sandbox code looks fine, although as that if/then condition gets more complex, I would be tempted to split it out into its own function for readability. Let me know if you want me to clarify anything, and once you've fixed the above issues feel free to deploy the code if all the unit tests pass. Best — Mr. Stradivarius ^{♪ talk ♪} 11:45, 16 July 2021 (UTC)

Thanks for reviewing! Added those tests and added a test for banners as well. Also split that pattern into a variable. All tests pass, so I've deployed the code. ProcrastinatingReader (talk) 12:01, 16 July 2021 (UTC)

Template-protected edit request on 3 February 2022

Please add the following to Module:Protection banner/config near line 772:

	['all|module|all|extendedconfirmed|edit']      = 'Wikipedia extended-confirmed-protected modules',

ECP modules currently categorize into Category:Wikipedia fully-protected modules, this would move them to Category:Wikipedia extended-confirmed-protected modules. AntiCompositeNumber (talk) 23:27, 3 February 2022 (UTC)

 Done: Special:Diff/1069763876. —⁠andrybak (talk) 23:50, 3 February 2022 (UTC)

@Andrybak Thanks! AntiCompositeNumber (talk) 00:02, 4 February 2022 (UTC)