View source for Module talk:Protection banner

{{Permanently protected}}
{{talk header}}

== 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 {{ping|Mr. Stradivarius|p=}}, in case you know) [[User:ProcrastinatingReader|ProcrastinatingReader]] ([[User talk:ProcrastinatingReader|talk]]) 16:52, 28 August 2020 (UTC)
:{{ping|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? — '''''[[User:Mr. Stradivarius|<span style="color: #194D00; font-family: Palatino, Times, serif">Mr.&nbsp;Stradivarius</span>]]''''' <sup>[[User talk:Mr. Stradivarius|♪&nbsp;talk&nbsp;♪]]</sup> 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. — '''''[[User:Mr. Stradivarius|<span style="color: #194D00; font-family: Palatino, Times, serif">Mr.&nbsp;Stradivarius</span>]]''''' <sup>[[User talk:Mr. Stradivarius|♪&nbsp;talk&nbsp;♪]]</sup> 00:57, 29 August 2020 (UTC)
::{{u|Mr. Stradivarius}}, examples: [[Template:Justice League characters]], [[Template:Palestinian militancy attacks in the 1960s]], [[Template:Gs/topics]] [[User:ProcrastinatingReader|ProcrastinatingReader]] ([[User talk: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... [[User:ProcrastinatingReader|ProcrastinatingReader]] ([[User talk: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 {{t|Pp-extended}} exist rather than just using {{t|Pp}} (which is used for all other protections & at least in source appears to do the same thing as the former?) [[User:ProcrastinatingReader|ProcrastinatingReader]] ([[User talk:ProcrastinatingReader|talk]]) 01:47, 29 August 2020 (UTC)
::::{{ping|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. — '''''[[User:Mr. Stradivarius|<span style="color: #194D00; font-family: Palatino, Times, serif">Mr.&nbsp;Stradivarius</span>]]''''' <sup>[[User talk:Mr. Stradivarius|♪&nbsp;talk&nbsp;♪]]</sup> 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. [[User:ProcrastinatingReader|ProcrastinatingReader]] ([[User talk:ProcrastinatingReader|talk]]) 17:16, 29 August 2020 (UTC)
::::::{{ping|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. — '''''[[User:Mr. Stradivarius|<span style="color: #194D00; font-family: Palatino, Times, serif">Mr.&nbsp;Stradivarius</span>]]''''' <sup>[[User talk:Mr. Stradivarius|♪&nbsp;talk&nbsp;♪]]</sup> 14:08, 30 August 2020 (UTC)
:::::::{{u|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 [https://en.wikipedia.org/w/index.php?title=Alissa&redirect=no 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?{{pb}}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)? [[User:ProcrastinatingReader|ProcrastinatingReader]] ([[User talk: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 {{t|R fully protected}}. So we have [https://en.wikipedia.org/w/index.php?title=Armando_(Blogger)&action=edit 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? [[User:ProcrastinatingReader|ProcrastinatingReader]] ([[User talk:ProcrastinatingReader|talk]]) 14:30, 30 August 2020 (UTC)
::::::::{{ping|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 [[WP:JQ|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. — '''''[[User:Mr. Stradivarius|<span style="color: #194D00; font-family: Palatino, Times, serif">Mr.&nbsp;Stradivarius</span>]]''''' <sup>[[User talk:Mr. Stradivarius|♪&nbsp;talk&nbsp;♪]]</sup> 15:04, 30 August 2020 (UTC)
:::::::::{{u|Mr. Stradivarius}}, hmm, in the case of [https://en.wikipedia.org/w/index.php?title=Alissa&redirect=no this] what's adding the lock (in read mode)? And why is that thing not adding the lock [https://en.wikipedia.org/w/index.php?title=Armando_(Blogger)&action=edit here]? These look quite similar to me? [[User:ProcrastinatingReader|ProcrastinatingReader]] ([[User talk:ProcrastinatingReader|talk]]) 15:07, 30 August 2020 (UTC)
::::::::::{{ping|ProcrastinatingReader}} That's [[Template:Rcat shell]], which is calling [[Template:pp-protected]] based on the edit protection level. — '''''[[User:Mr. Stradivarius|<span style="color: #194D00; font-family: Palatino, Times, serif">Mr.&nbsp;Stradivarius</span>]]''''' <sup>[[User talk:Mr. Stradivarius|♪&nbsp;talk&nbsp;♪]]</sup> 15:14, 30 August 2020 (UTC)
:::::::::::{{u|Mr. Stradivarius}}, I see. Isn't the easiest way to clean this up just to remove {{tlx|pp-protected|small{{=}}yes}} from {{t|Rcat shell}}? Then it would only call {{t|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 {{t|R fully protected}}, something like: {{tlx|pp|small{{=}}yes|category{{=}}no}}. [[User:ProcrastinatingReader|ProcrastinatingReader]] ([[User talk: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 {{u|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 {{tlx|rcat shell}} it should not also have any other protection template, not even {{tlx|r protected}} or similar. The thing about {{tlx|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. --[[User:Redrose64|<span style="color:#a80000; background:#ffeeee; text-decoration:inherit">Red</span>rose64]] &#x1f339; ([[User talk:Redrose64|talk]]) 09:28, 31 August 2020 (UTC)
:::::::::::::{{u|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. {{t|r protected}} accounts for other protection levels as well, and so moving {{t|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 {{t|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. [[User:ProcrastinatingReader|ProcrastinatingReader]] ([[User talk:ProcrastinatingReader|talk]]) 20:17, 31 August 2020 (UTC)
::::::::::::::Well {{u|ProcrastinatingReader|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 {{tl|Redirect category shell}} was the {{tl|This is a redirect}} template. This challenge applies not just to Extended-confirmed-protected but also to others like the {{tl|-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. '''''[[User:Paine Ellsworth|<span style="font-size:92%;color:darkblue;font-family:Segoe Script">P.I.&nbsp;Ellsworth</span>]]'''''&nbsp;&nbsp;[[Editor|<span style="color:black">ed.</span>]]&nbsp;[[User talk:Paine Ellsworth|<sup>put'r&nbsp;there</sup>]]&nbsp;<small>12:01, 1 September 2020 (UTC)</small>
{{od|::::::::::::::}}
{{u|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 {{t|r protected}} makes this an easy case to solve, I think. [[User:ProcrastinatingReader|ProcrastinatingReader]] ([[User talk:ProcrastinatingReader|talk]]) 12:08, 1 September 2020 (UTC)
:You appear to be looking to remove the {{tl|pp-protected}} template from the shell, thus changing:
<pre>
{{#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}}
</pre>
:to:
<pre>
{{#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}}
</pre>
:is that correct? And then further, to get back the lock icon that would be lost, you propose to insert the {{tl|pp-protected}} template into the {{tl|R fully protected}} rcat template? Where exactly would you insert it? '''''[[User:Paine Ellsworth|<span style="font-size:92%;color:darkblue;font-family:Segoe Script">P.I.&nbsp;Ellsworth</span>]]'''''&nbsp;&nbsp;[[Editor|<span style="color:black">ed.</span>]]&nbsp;[[User talk:Paine Ellsworth|<sup>put'r&nbsp;there</sup>]]&nbsp;<small>12:38, 1 September 2020 (UTC)</small>
::{{u|Paine Ellsworth}} that's correct. For your question, see [[Template:R fully protected/sandbox]]. Both sandboxes are updated with the change I'm proposing.{{pb}}(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). [[User:ProcrastinatingReader|ProcrastinatingReader]] ([[User talk:ProcrastinatingReader|talk]]) 19:43, 1 September 2020 (UTC)
:::Like you, {{u|ProcrastinatingReader|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 {{cat|Wikipedia template-protected templates}} when the {{tl|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 {{cat|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. '''''[[User:Paine Ellsworth|<span style="font-size:92%;color:darkblue;font-family:Segoe Script">P.I.&nbsp;Ellsworth</span>]]'''''&nbsp;&nbsp;[[Editor|<span style="color:black">ed.</span>]]&nbsp;[[User talk:Paine Ellsworth|<sup>put'r&nbsp;there</sup>]]&nbsp;<small>10:18, 2 September 2020 (UTC)</small>
::::Thanks for testing, {{u|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.{{pb}}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. [[User:ProcrastinatingReader|ProcrastinatingReader]] ([[User talk:ProcrastinatingReader|talk]]) 11:38, 2 September 2020 (UTC)
:::::You're welcome, {{u|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 <code><nowiki>{{pp|small=yes|category=no}}</nowiki></code> in the {{tl|R fully protected}} rcat, what would be the difference if we just added the {{para|category|no}} parameter to the existing {{tl|pp-protected}} template (which of course redirects to template {{tl|pp}}) in the {{tl|Rcat shell}}? Would that accomplish the same thing? or do you think there would be different results? '''''[[User:Paine Ellsworth|<span style="font-size:92%;color:darkblue;font-family:Segoe Script">P.I.&nbsp;Ellsworth</span>]]'''''&nbsp;&nbsp;[[Editor|<span style="color:black">ed.</span>]]&nbsp;[[User talk:Paine Ellsworth|<sup>put'r&nbsp;there</sup>]]&nbsp;<small>12:14, 2 September 2020 (UTC)</small>
::::::{{u|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 {{t|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. [[User:ProcrastinatingReader|ProcrastinatingReader]] ([[User talk: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 {{para|category|no}} parameter to the shell for all the protection templates in the shell. May as well add the pp template to {{tl|R template-protected}}, {{tl|R extended-protected}} and {{tl|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 > '''''[[User:Paine Ellsworth|<span style="font-size:92%;color:darkblue;font-family:Segoe Script">P.I.&nbsp;Ellsworth</span>]]'''''&nbsp;&nbsp;[[Editor|<span style="color:black">ed.</span>]]&nbsp;[[User talk:Paine Ellsworth|<sup>put'r&nbsp;there</sup>]]&nbsp;<small>13:29, 2 September 2020 (UTC)</small>
::::::::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). [[User:ProcrastinatingReader|ProcrastinatingReader]] ([[User talk:ProcrastinatingReader|talk]]) 15:01, 2 September 2020 (UTC)

====Move-protected====
{{u|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 <code>['all|template|all|sysop|move'] = 'Wikipedia move-protected templates'</code>, 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. [[User:ProcrastinatingReader|ProcrastinatingReader]] ([[User talk: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 {{tq|fully move-protected pages}}. Other relevant bits:
:* {{tq|Fully edit-protected pages are also implicitly move-protected.}}
:* {{tq|All files are implicitly move-protected; only file movers and administrators can move files.}}
: —⁠[[User:Andrybak|andrybak]] ([[User talk: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. [[User:ProcrastinatingReader|ProcrastinatingReader]] ([[User talk:ProcrastinatingReader|talk]]) 22:02, 6 September 2020 (UTC)
:{{ec}} {{to|ProcrastinatingReader}} I'd also like to hear thoughts from [[User:Redrose64|<span style="color:#a80000; background:#ffeeee; text-decoration:inherit">Red</span>rose64]], [[User:MSGJ|Martin]], [[User:Anomie|Anomie⚔]], [[User:Wbm1058|wbm1058]], [[User:Xaosflux|<span style="color:#FF9933; font-weight:bold; font-family:monotype;">xaosflux</span>]] and [[User:Jackmcbarn|Jackmcbarn]] that would be helpful on this issue. As a "tough nut to crack", we need all the help we can get. '''''[[User:Paine Ellsworth|<span style="font-size:92%;color:darkblue;font-family:Segoe Script">P.I.&nbsp;Ellsworth</span>]]'''''&nbsp;&nbsp;[[Editor|<span style="color:black">ed.</span>]]&nbsp;[[User talk:Paine Ellsworth|<sup>put'r&nbsp;there</sup>]]&nbsp;<small>21:48, 6 September 2020 (UTC)</small>
::{{replyto|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. --[[User:Redrose64|<span style="color:#a80000; background:#ffeeee; text-decoration:inherit">Red</span>rose64]] &#x1f339; ([[User talk: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 <code><nowiki>// {{pp-template}}</nowiki></code> 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)? [[User:ProcrastinatingReader|ProcrastinatingReader]] ([[User talk:ProcrastinatingReader|talk]]) 22:15, 6 September 2020 (UTC)
:Done [[Module:Protection banner/sandbox|in sandbox]] if anyone wants to take a look. [[User:ProcrastinatingReader|ProcrastinatingReader]] ([[User talk: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 <code>Protected:isProtected()</code>, I would put it directly in <code>Protection:makeCategoryLinks()</code>, or maybe better, put it in a dedicated <code>Protection:shouldBeCategorized()</code> 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 — '''''[[User:Mr. Stradivarius|<span style="color: #194D00; font-family: Palatino, Times, serif">Mr.&nbsp;Stradivarius</span>]]''''' <sup>[[User talk:Mr. Stradivarius|♪&nbsp;talk&nbsp;♪]]</sup> 15:32, 7 September 2020 (UTC)
:::{{u|Mr. Stradivarius}}, thanks for reviewing! Re bullet 1: I popped it into <code>:isProtected()</code> 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 // {{tlf|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. [[User:ProcrastinatingReader|ProcrastinatingReader]] ([[User talk:ProcrastinatingReader|talk]]) 16:11, 7 September 2020 (UTC)
::::{{ping|ProcrastinatingReader}} I see - if we need to suppress the padlock icons as well, then I agree that <code>:isProtected()</code> is a very convenient place to add the code. I think the problem is just one of naming, then, which I [[Special:Diff/977374710|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. — '''''[[User:Mr. Stradivarius|<span style="color: #194D00; font-family: Palatino, Times, serif">Mr.&nbsp;Stradivarius</span>]]''''' <sup>[[User talk:Mr. Stradivarius|♪&nbsp;talk&nbsp;♪]]</sup> 14:24, 8 September 2020 (UTC)
:::::{{u|Mr. Stradivarius}}, looks good to me! [[User:ProcrastinatingReader|ProcrastinatingReader]] ([[User talk:ProcrastinatingReader|talk]]) 19:27, 9 September 2020 (UTC)
:::::{{u|Mr. Stradivarius}}, is this good to merge into live? [[User:ProcrastinatingReader|ProcrastinatingReader]] ([[User talk:ProcrastinatingReader|talk]]) 19:08, 15 September 2020 (UTC)
::::::{{ping|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; <code>User:Foo.css</code> would be a wikitext page). — '''''[[User:Mr. Stradivarius|<span style="color: #194D00; font-family: Palatino, Times, serif">Mr.&nbsp;Stradivarius</span>]]''''' <sup>[[User talk:Mr. Stradivarius|♪&nbsp;talk&nbsp;♪]]</sup> 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. [[User:ProcrastinatingReader|ProcrastinatingReader]] ([[User talk: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. — '''''[[User:Mr. Stradivarius|<span style="color: #194D00; font-family: Palatino, Times, serif">Mr.&nbsp;Stradivarius</span>]]''''' <sup>[[User talk:Mr. Stradivarius|♪&nbsp;talk&nbsp;♪]]</sup> 04:19, 19 September 2020 (UTC)
::::::::Also, checking the [[mw:Extension:Scribunto/Lua reference manual#Expensive properties|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. — '''''[[User:Mr. Stradivarius|<span style="color: #194D00; font-family: Palatino, Times, serif">Mr.&nbsp;Stradivarius</span>]]''''' <sup>[[User talk:Mr. Stradivarius|♪&nbsp;talk&nbsp;♪]]</sup> 07:18, 19 September 2020 (UTC)
:::::::::I've just put the code up live - let me know if you notice any issues. — '''''[[User:Mr. Stradivarius|<span style="color: #194D00; font-family: Palatino, Times, serif">Mr.&nbsp;Stradivarius</span>]]''''' <sup>[[User talk:Mr. Stradivarius|♪&nbsp;talk&nbsp;♪]]</sup> 13:07, 19 September 2020 (UTC)
::::::::::{{u|Mr. Stradivarius}}, looks good right now. Am curious about one thing. I know categories don't update with contents immediately, but I thought a [[Wikipedia:Purge#forcerecursivelinkupdate|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? [[User:ProcrastinatingReader|ProcrastinatingReader]] ([[User talk: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]]. --[[User:Redrose64|<span style="color:#a80000; background:#ffeeee; text-decoration:inherit">Red</span>rose64]] &#x1f339; ([[User talk: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]], {{u|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). [[User:ProcrastinatingReader|ProcrastinatingReader]] ([[User talk: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. {{u|Paine Ellsworth}} may be interested? Re. redirects, I know {{u|Mr. Stradivarius}} suggested [[Module_talk:Protection_banner#Categorization_of_protected_redirects|above]] the ideas of {{tq|Add redirect detection as a full-blown key to the protection category algorithm}}, or a new module to deal with redirects. I also had [[Special:Diff/977097115/977183814|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" + [...]. [[User:ProcrastinatingReader|ProcrastinatingReader]] ([[User talk: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 {{t|pp-blp}}, Twinkle just adds {{t|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 {{t|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. '''''[[User:Paine Ellsworth|<span style="font-size:92%;color:darkblue;font-family:Segoe Script">P.I.&nbsp;Ellsworth</span>]]'''''&nbsp;&nbsp;[[Editor|<span style="color:black">ed.</span>]]&nbsp;[[User talk:Paine Ellsworth|<sup>put'r&nbsp;there</sup>]]&nbsp;<small>15:57, 27 September 2020 (UTC)</small>

== Catonly ==

{{re|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 [https://en.wikipedia.org/wiki/Wikipedia:Templates_for_discussion/Log/2020_October_25#Template:Pp-move this TfD]. Is that good to go? [[User:ProcrastinatingReader|ProcrastinatingReader]] ([[User talk:ProcrastinatingReader|talk]]) 19:47, 15 July 2021 (UTC)
:{{ping|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 [https://en.wikipedia.org/wiki/Special:ComparePages?page1=Module%3AProtection+banner&rev1=1013845490&page2=Module%3AProtection+banner%2Fsandbox&rev2=1033774702&action=&diffonly=&unhide= 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 {{para|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 — '''''[[User:Mr. Stradivarius|<span style="color: #194D00; font-family: Palatino, Times, serif">Mr.&nbsp;Stradivarius</span>]]''''' <sup>[[User talk:Mr. Stradivarius|♪&nbsp;talk&nbsp;♪]]</sup> 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. [[User:ProcrastinatingReader|ProcrastinatingReader]] ([[User talk:ProcrastinatingReader|talk]]) 12:01, 16 July 2021 (UTC)

== Template-protected edit request on 3 February 2022 ==

{{edit template-protected|Module:Protection banner/config|answered=yes}}
Please add the following to [[Module:Protection banner/config]] near line 772:
<pre>
	['all|module|all|extendedconfirmed|edit']      = 'Wikipedia extended-confirmed-protected modules',
</pre>
[https://en.wikipedia.org/wiki/Special:ProtectedPages?namespace=828&type=edit&level=extendedconfirmed&size-mode=min&size= ECP modules] currently categorize into [[:Category:Wikipedia fully-protected modules]], this would move them to [[:Category:Wikipedia extended-confirmed-protected modules]]. [[User:AntiCompositeNumber|AntiCompositeNumber]] ([[User talk:AntiCompositeNumber|talk]]) 23:27, 3 February 2022 (UTC)
: {{Done}}: [[Special:Diff/1069763876]]. —⁠[[User:Andrybak|andrybak]] ([[User talk:Andrybak|talk]]) 23:50, 3 February 2022 (UTC)
::@[[User:Andrybak|Andrybak]] Thanks! [[User:AntiCompositeNumber|AntiCompositeNumber]] ([[User talk:AntiCompositeNumber|talk]]) 00:02, 4 February 2022 (UTC)

== Issues with pending changes alongside generic protection ==

At [[Chimpanzee]], the page is both pending changes and semi-protected. {{tl|pp-pc}} does not render, only {{tl|pp-vandalism}} does. Is this expected? <span class="nowrap">&#8212;'''[[User:CX Zoom|CX Zoom]]'''[he/him]</span> <sup class="nowrap">([[User talk:CX Zoom|let's talk]] • {[[Special:Contributions/CX Zoom|C]]•[[User:CX Zoom/X|X]]})</sup> 09:51, 5 August 2022 (UTC)
:{{replyto|CX Zoom}} Yes, only one kind of protection is reported - the "stronger" one. In this case, the {{tlx|pp-vandalism}} picks up the [[WP:SEMI|semi-protection]] for editing which prevents all edits by unconfirmed users; whilst the {{tlx|pp-pc}} picks up the [[WP:PC1|pending changes]] prot, also for editing, which ''allows'' edits by unconfirmed users but doesn't make them visible unless accepted. So in this case the semi-prot is the stronger one. --[[User:Redrose64|<span style="color:#a80000; background:#ffeeee; text-decoration:inherit">Red</span>rose64]] &#x1f339; ([[User talk:Redrose64|talk]]) 20:46, 5 August 2022 (UTC)

== Using plain English for protection levels ==

The recent high-profile case of readers not understanding protection icons at [[Recession]] led me to review the tooltip text, and it seems that it leaves something to be desired. The messages are currently in forms like {{tq|This article is semi-protected until April 7, 2022 at 1:47 UTC.}} Readers don't know what "semi-protected" or "extended-protected" means, and very few will click through to the [[WP:protection|protection policy page]] to find out. I suggest that we change the wording to plain English to help make it easier to understand. For semi-protection, I'd suggest {{tq|New users cannot edit this article until April 7, 2022, at 1:47 UTC}} (note also two grammar fixes: the added comma and removed period). For EC, {{tq|Only experienced users can edit this article until...}} Thoughts? <span style="color:#AAA"><small>&#123;{u&#124;</small><span style="border-radius:9em;padding:0 5px;background:#088">[[User:Sdkb|<span style="color:#FFF">'''Sdkb'''</span>]]</span><small>}&#125;</small></span> <sup>[[User talk:Sdkb|'''talk''']]</sup> 18:21, 28 August 2022 (UTC)
: The idea seems reasonable in theory, but the wordings you proposed don't work as the language used for semi-protection and for extended-confirmed-protection read like synonyms of each other. [[User:Pppery|* Pppery *]] [[User talk:Pppery|<sub style="color:#800000">it has begun...</sub>]] 15:10, 29 August 2022 (UTC)
::What high-profile case? There doesn't seem to be anything on its talk page. --[[User:Redrose64|<span style="color:#a80000; background:#ffeeee; text-decoration:inherit">Red</span>rose64]] &#x1f339; ([[User talk:Redrose64|talk]]) 09:15, 30 August 2022 (UTC)
:::@[[User:Pppery|Pppery]], do you have a suggested alternative? Users won't be seeing both notices at the same time, and I can't think of an intuitive word for those in the 10-500 edit range, so I'm not sure we can do any better. Perhaps for EC, {{tq|New and intermediately experienced editors cannot edit...}}, but that's a little wordier.
:::@[[User:Redrose64|Redrose64]], https://slate.com/technology/2022/08/wikipedia-recession-article.html. <span style="color:#AAA"><small>&#123;{u&#124;</small><span style="border-radius:9em;padding:0 5px;background:#088">[[User:Sdkb|<span style="color:#FFF">'''Sdkb'''</span>]]</span><small>}&#125;</small></span> <sup>[[User talk:Sdkb|'''talk''']]</sup> 14:29, 30 August 2022 (UTC)
::::Having mulled this over for a while, I can't come up with any wording clearer than my original proposal. I don't think the synonym concern is a blocker, since the tooltips won't be appearing alongside each other and it's fairly intuitive that there's an intermediate level in between "new user" and "experienced user".
::::The config page [[Module:Protection_banner/config#L-922|currently relies on PROTECTIONLEVEL]], so improving it will require some coding; would anyone with Lua skills be interested in taking that on? <span style="color:#AAA"><small>&#123;{u&#124;</small><span style="border-radius:9em;padding:0 5px;background:#088">[[User:Sdkb|<span style="color:#FFF">'''Sdkb'''</span>]]</span><small>}&#125;</small></span> <sup>[[User talk:Sdkb|'''talk''']]</sup> 18:06, 5 October 2022 (UTC)
:::::{{ping|Sdkb}} I've decided to give this a quick go. Note that I've entirely focused on the padlocks here - the regular big banner text is unaffected, since it's seen less often and I'm not sure you wanted anything there to be changed. I've tried to make the changes as light as possible (since the multiple class structures in the main module with objects being created all over the place is, at best, hard to learn on the spot), and I've come up with a basic config approach (See [[Module:Protection banner/config/sandbox#L-559|here]]) (Note that the move and upload sub-tables could be excessive, since I've never seen their padlocks appear normally, but I've implemented some wording anyways). I've also removed the tooltip from the template and ecp options in the banners table, since this would break messaging (see the thread just below), and also applied the comma you suggested above into the time formatting, though I'm not sure about removing the period (it's possible, but not elegant, likely being a "does the final message end with 'UTC' " check).
:::::Since showing tests for this module can be quite hard, here are the 4 main protection levels with the messages as of the current sandbox version: [[File:Full-protection-shackle.svg|20px|link=Wikipedia:Protection policy#full|alt=Page protected|Only admins can edit this page until January 1, 2022, at 00:00 UTC.]] [[File:Template-protection-shackle.svg|20px|link=Wikipedia:Protection policy#template|alt=Page template-protected|Only experienced template editors and admins can edit this page until January 1, 2022, at 00:00 UTC.]] [[File:Extended-protection-shackle.svg|20px|link=Wikipedia:Protection policy#extended|alt=Page extended-protected|Only experienced users can edit this page until January 1, 2022, at 00:00 UTC.]] [[File:Semi-protection-shackle.svg|20px|link=Wikipedia:Protection policy#semi|alt=Page semi-protected|New users cannot edit this page until January 1, 2022, at 00:00 UTC.]]
:::::Hope this fits roughly what you were thinking. Any comments or requests, just ask. [[User:Aidan9382|Aidan9382]] <sub>([[User talk:Aidan9382|talk]])</sub> 12:31, 9 December 2022 (UTC)
::::::@[[User:Aidan9382|Aidan9382]], sorry for the delayed reply. That looks excellent! I'd support implementing. <span style="color:#AAA"><small>&#123;{u&#124;</small><span style="border-radius:9em;padding:0 5px;background:#088">[[User:Sdkb|<span style="color:#FFF">'''Sdkb'''</span>]]</span><small>}&#125;</small></span> <sup>[[User talk:Sdkb|'''talk''']]</sup> 06:02, 1 March 2023 (UTC)
:::::::@[[User:Aidan9382|Aidan9382]], just wanted to circle back, where are we at with this? Cheers, <span style="border:3px outset;border-radius:8pt 0;padding:1px 5px;background:linear-gradient(6rad,#86c,#2b9)">[[User:Sdkb|<span style="color:#FFF;text-decoration:inherit;font:1em Lucida Sans">Sdkb</span>]]</span> <sup>[[User talk:Sdkb|'''talk''']]</sup> 01:34, 6 March 2024 (UTC)
::::::::{{ping|Sdkb}} (This was over a year ago? God, swear this wasn't that long ago) I haven't made any changes since the last sandbox edit related to this, but that version should be working since its what I used to generate the padlocks in my 9 december message. I've re-synced the config changes back into the current config sandbox version, and the module changes are already still in the sandbox. Changes for the protection messages are welcome since I'm not the best at writing that kind of stuff. You can see an example padlock message in action at [[User:Aidan9382/SafeEnvironmentTesting]] (you can adjust the demolevel as needed to test each padlock - you can't test multiple at once due to the indicators all being named the same). [[User:Aidan9382|Aidan9382]] <sub>([[User talk:Aidan9382|talk]])</sub> 07:44, 6 March 2024 (UTC)

== Tooltip/title does not match the actual protection level ==

While the symbol displayed by templates like {{tl|pp-extended}}, and the link placed behind the symbol, automatically match the actual protection level, the tooltip/title doesn't.
Specifically, the article [[Russia]] is currently full-protected and displays a golden "F" lock, with a link pointing towards the "#full" section of the protection policy. Its title attribute, however, is "This article is extended-confirmed protected".

This has been noticed by [[User:Jishiboka1|Jishiboka1]] at [[Talk:Russia]] and should probably be fixed in the module. [[User:ToBeFree|~ ToBeFree]] ([[User talk:ToBeFree|talk]]) 11:44, 1 October 2022 (UTC)

:Note: After some tampering with the module and some test runs, I've found out what the issue is. The module seems to be relying entirely on the template itself for the banner text it uses which is fetched from [[Module:Protection banner/config]]. You can see an example of this if you try to use {{tl|pp-template}} on a semi-protected page - it'll display the template banner's text from the config, but with the protection level at semi. This works ''most'' of the time, as the tooltip messages use <code>${PROTECTIONLEVEL}</code>, which means the message adapts to the protection level of the page. However, the tooltip for ecp is hard-coded to read <code>This ${PAGETYPE} is extended-confirmed protected</code>, which is where the issue is coming from. A solution to this could be just changing the tooltip message to <code>This ${PAGETYPE} is ${PROTECTIONLEVEL}</code>, so it matches the other options' format. [[User:Aidan9382|Aidan9382]] <sub>([[User talk:Aidan9382|talk]])</sub> 13:09, 1 October 2022 (UTC)

{{edit template-protected|Module:Protection banner/config|answered=yes}}
Apparently forgot to do this. Based off of the discussion above, could the <code>This ${PAGETYPE} is extended-confirmed protected</code> message on line 224 be changed to <code>This ${PAGETYPE} is ${PROTECTIONLEVEL}</code> to avoid the module displaying the wrong message when {{tl|pp-extended}} (or similar) is used? Thanks. [[User:Aidan9382|Aidan9382]] <sub>([[User talk:Aidan9382|talk]])</sub> 18:38, 5 October 2022 (UTC)
:{{edited2}}. '''''[[User:Paine Ellsworth|<span style="font-size:92%;color:darkblue;font-family:Segoe Script">P.I.&nbsp;Ellsworth</span>]]'''''&thinsp;,&nbsp;[[Editor|<span style="color:black">ed.</span>]]&nbsp;[[User talk:Paine Ellsworth|<sup>put'r&nbsp;there</sup>]]&nbsp;<small>04:19, 6 October 2022 (UTC)</small>

== Template configuration feedback ==

Some of the strings in [[Module:Protection_banner/config]] could be more consistent with how page protection works on Wikipedia.

1. The non-iconified page protection template does not link [[Wikipedia:Request for edit]] when a page and its talk page are both protected as specified in the [[Protection_policy#Semi-protection|semi-protection policy]]. It would be better if that could happen automatically, maybe just add that always on talk pages when they are protected? If that's not possible, it would be good if there was an option to the template to add that link.

2. Several strings in the configuration state "or [[Special:UserLogin/signup|create an account]]" in reference to making edits to semi-protected pages. That seems misleading when a new account cannot edit semi-protected pages until it is old enough to be autoconfirmed.

3. Would it be possible to change the default settings so that '''small=yes''' would be set by default on articles that are edit protected (not move protection or any kind of protection on talk pages, though). It seems like that's the preferred practice so why not make it the default?

[[User:Daniel Quinlan|Daniel Quinlan]] ([[User talk:Daniel Quinlan|talk]]) 21:53, 10 July 2023 (UTC)

== Template-editor move-protected? ==

(Regarding [[Module:Protection banner/config#L-758]].)

It doesn't seem helpful to categorize a template into [[:Category:Wikipedia template-protected templates]] when it's only protected for ''moves'' and not for ''edits''. For example, [[Template:Bill Clinton]] is in that category but can be edited (but not moved) freely.

I suggest either (A) <s>removing that line</s> <ins>[edit: not adding any category]</ins>, similar to how currently there is no category for a page that is extended-confirmed move-protected but not edit-protected or (B) creating new categories [[:Category:Wikipedia template-editor move-protected templates]] and [[:Category:Wikipedia extended-confirmed move-protected pages]] (or similar). [[User:SilverLocust|<small style="color:#667;background:#fff;border:2px solid;border-radius:.4em;padding:0 .3em">SilverLocust</small>]] <small class="plainlinks sysop-show extendedmover-show">[//w.wiki/8xwX &#x1f0cf;]</small> [[User talk:SilverLocust|💬]] 02:26, 27 January 2024 (UTC)
:{{reply to|SilverLocust}} That line was added by [[special:diff/976938143|this 00:07, 6 September 2020 edit]] per the discussion at [[#Move-protected]] above. – [[User:Wbm1058|wbm1058]] ([[User talk:Wbm1058|talk]]) 03:30, 8 February 2024 (UTC)
::To be more precise, that change wasn't added ''per'' the discussion at [[#Move-protected]], it was added ''followed by'' the discussion at [[#Move-protected]] that the change wasn't quite correct and should have some better solution. Nobody there claimed that the category now provided is correct, just that it's there so that it doesn't default to "fully protected pages". 
::But that just suggests that rather than removing the line entirely, option (A) would be to move that line up to the [[Module:Protection banner/config#L-735|2nd line]] within protectionCategories (so that it has lower priority than all of the categories below it) and to replace it with <syntaxhighlight lang="Lua">['all|template|all|templateeditor|move']    = '' -- there is currently no category for template-editor move-protected pages</syntaxhighlight> 
::And I suppose there could be an option (C) — combining TE move-protected pages into [[:Category:Wikipedia move-protected templates]]. [[User:SilverLocust|<small style="color:#667;background:#fff;border:2px solid;border-radius:.4em;padding:0 .3em">SilverLocust</small>]] [[User talk:SilverLocust|💬]] 13:46, 27 February 2024 (UTC)
:::[[Module:Protection banner/config#L-734|The first line]] of  protectionCategories (which is the default) should also be changed to <syntaxhighlight lang="Lua">['all|all|all|all|all'] = 'Wikipedia miscellaneous protected pages',</syntaxhighlight> as a new tracking category, rather than defaulting to 'Wikipedia fully protected pages' when none of the below options match. And that would allow incorrect categories to just be removed rather than shoehorned into some not-quite-correct category. [[User:SilverLocust|<small style="color:#667;background:#fff;border:2px solid;border-radius:.4em;padding:0 .3em">SilverLocust</small>]] [[User talk:SilverLocust|💬]] 20:11, 27 February 2024 (UTC)

== Edit request 28 February 2024 ==

{{Edit template-protected|Module:Protection banner/config|answered=yes}}
<syntaxhighlight lang="Lua>	['all|all|all|templateeditor|move']         = 'Wikipedia template-protected pages other than templates and modules',
	['all|template|all|extendedconfirmed|move'] = 'Wikipedia extended-confirmed-protected templates',</syntaxhighlight>
Please [[Special:Diff/1210714229|add these two new lines (sandbox diff)]] to the protectionCategories object in the /config so that 
# pages like the redirect {{no redirect|Template talk:Db-a1}} will not be miscategorized into [[:Category:Wikipedia fully protected pages]] (via {{tl|pp-move}}, which is called by {{tl|Redirect category shell}}) and
# extended-confirmed templates like [[Template:Israel–Hamas war]] will not be categorized into both [[:Category:Wikipedia extended-confirmed-protected pages]] (via {{tl|pp-move}}) and the subcategory [[:Category:Wikipedia extended-confirmed-protected templates]] (via {{tl|pp}}) rather than just the subcategory. 
[[User:SilverLocust|<small style="color:#667;background:#fff;border:2px solid;border-radius:.4em;padding:0 .3em">SilverLocust</small>]] [[User talk:SilverLocust|💬]] 02:02, 28 February 2024 (UTC)

:I can make this edit now, so I shall do my own request. (This is separate from the suggestions in the previous section.) [[User:SilverLocust|<small style="color:#667;background:#fff;border:2px solid;border-radius:.4em;padding:0 .3em">SilverLocust</small>]] [[User talk:SilverLocust|💬]] 12:39, 1 March 2024 (UTC)

== Small bug ==

I noticed that a semi-protected article that has the extended-protection template applied to it displays the semi-protection icon, but with a tooltip that says "This article is semi-protected#semi". Not the biggest deal, but if anyone wants to get rid of the "#semi" at the end, that would be nice. <span style="border:3px outset;border-radius:8pt 0;padding:1px 5px;background:linear-gradient(6rad,#86c,#2b9)">[[User:Sdkb|<span style="color:#FFF;text-decoration:inherit;font:1em Lucida Sans">Sdkb</span>]]</span> <sup>[[User talk:Sdkb|'''talk''']]</sup> 21:09, 27 August 2024 (UTC)

:Which article? The anchor shouldn't be appearing since it should be part of the lock's link, and some quick testing myself doesn't seem to cause this case. [[User:Aidan9382|Aidan9382]] <sub>([[User talk:Aidan9382|talk]])</sub> 21:39, 27 August 2024 (UTC)
::I found it on [[Tim Walz]], which had EC protection that expired (and I then replaced with semi-protection). <span style="border:3px outset;border-radius:8pt 0;padding:1px 5px;background:linear-gradient(6rad,#86c,#2b9)">[[User:Sdkb|<span style="color:#FFF;text-decoration:inherit;font:1em Lucida Sans">Sdkb</span>]]</span> <sup>[[User talk:Sdkb|'''talk''']]</sup> 21:57, 27 August 2024 (UTC)
:::Seems fine to me, the tooltip is just "This article is semi-protected". [[User:Aidan9382|Aidan9382]] <sub>([[User talk:Aidan9382|talk]])</sub> 08:35, 28 August 2024 (UTC)

== Icon redirect ==

Anyone watching? The BLACKLOCK icon at [[Asian News International vs. Wikimedia Foundation]] redirects to [[Wikipedia:Protection_policy#full]], but [[Wikipedia:Protection_policy#Office_actions]] would be more on point. [[User:Gråbergs Gråa Sång|Gråbergs Gråa Sång]] ([[User talk:Gråbergs Gråa Sång|talk]]) 18:41, 21 October 2024 (UTC)

:This'll require a change to the module code, since the config responsible for determining the link that the padlock uses is determined [[Module:Protection banner/config#L-596|here]], and an office action is, in technical terms, just a normal full (admin) protection. The only way the difference is determined for the image is by explicitly using {{tl|pp-office}} instead of {{tl|pp}}, so something similar would need to be done for the image link handling too. [[User:Aidan9382|Aidan9382]] <sub>([[User talk:Aidan9382|talk]])</sub> 18:50, 21 October 2024 (UTC)
::While office action protections are implemented as full protections, the purpose of the redirect is to provide additional context and information to readers. I agree that it makes sense for the icon to redirect to the most relevant section of the policy, {{slink|Wikipedia:Protection policy#Office actions}}. Just to be clear, I'm only commenting on the desired outcome, not on the technical implementation. [[User:Daniel Quinlan|Daniel Quinlan]] ([[User talk:Daniel Quinlan|talk]]) 18:58, 21 October 2024 (UTC)
:::{{replyto|Gråbergs Gråa Sång}} It's easy to find out what the protection level is, and when it will expire. There are two [[WP:PF|parser functions]] that do this:
:::*<code><nowiki>{{PROTECTIONLEVEL:edit|Asian News International vs. Wikimedia Foundation}}</nowiki></code> → {{PROTECTIONLEVEL:edit|Asian News International vs. Wikimedia Foundation}}
:::*<code><nowiki>{{PROTECTIONEXPIRY:edit|Asian News International vs. Wikimedia Foundation}}</nowiki></code> → {{PROTECTIONEXPIRY:edit|Asian News International vs. Wikimedia Foundation}}
:::*<code><nowiki>{{PROTECTIONLEVEL:move|Asian News International vs. Wikimedia Foundation}}</nowiki></code> → {{PROTECTIONLEVEL:move|Asian News International vs. Wikimedia Foundation}}
:::*<code><nowiki>{{PROTECTIONEXPIRY:move|Asian News International vs. Wikimedia Foundation}}</nowiki></code> → {{PROTECTIONEXPIRY:move|Asian News International vs. Wikimedia Foundation}}
:::The value "sysop" denotes full protection, for any reason. These values are read directly from a table, and whereas this module obtains the values using another module (specifically [[Module:Effective protection level]]) and not the parser functions, the underlying routines in the MediaWiki software are the same, and so the values are read from the same table. But the ''reason'' for protection is not held in a table, it's only recorded as a log entry. The module would need to scan back through that log, since the imposition of protection might not be the most recent entry in the protection log (although in this case, [//en.wikipedia.org/wiki/Special:Log?type=protect&page=Asian_News_International_vs._Wikimedia_Foundation it is]). The module would also need to do that every time the page is retrieved, and that would take time. I don't think that this is a good idea. Stick with using {{tlx|pp-office}} or {{tlx|pp-vand}} etc., whichever is most appropriate, as these describe the situation explicitly. --[[User:Redrose64|<span style="color:#a80000; background:#ffeeee; text-decoration:inherit">Red</span>rose64]] &#x1f339; ([[User talk:Redrose64|talk]]) 07:37, 22 October 2024 (UTC)
::::If it can't be done, it can't be done. It would be a minor but obvious improvement for the reader, and my guess was that changing the "redirect" to [[WP:BLACKLOCK]] would be fairly trivial, though of course restricted by [[WP:PINKLOCK]] etc. To make a [[WP:OTHERCONTENT]] comparison, the [[WP:PINKLOCK]] icon (top right) at [[Module:Protection banner]] redirects to [[WP:PINKLOCK]], not [[WP:GOLDLOCK]]. [[User:Gråbergs Gråa Sång|Gråbergs Gråa Sång]] ([[User talk:Gråbergs Gråa Sång|talk]]) 07:48, 22 October 2024 (UTC)
:::::After a quick skim of the module code, it turns out it is already possible to override the link of the padlock in the config based on the template used, it's just none of the existing cases used said feature. I've tried my best to workshop the change in the sandbox config on phone [[Special:Diff/1252648173|here]]. [[User:Aidan9382|Aidan9382]] <sub>([[User talk:Aidan9382|talk]])</sub> 09:52, 22 October 2024 (UTC)
::::::Nice find. That seems like a promising solution, and it uses a descriptive link. [[User:Daniel Quinlan|Daniel Quinlan]] ([[User talk:Daniel Quinlan|talk]]) 11:45, 22 October 2024 (UTC)
:::::It would be better to avoid using the color shortcuts which are often unclear to people in meaning and less frequently used, and instead use the more descriptive shortcuts like [[WP:ECP]] or, even better, direct and descriptive links. [[User:Daniel Quinlan|Daniel Quinlan]] ([[User talk:Daniel Quinlan|talk]]) 11:33, 22 October 2024 (UTC)

If no one has any extra comments or suggestions regarding this, I'll move [[Special:Diff/1252648173|this change]] from the sandbox to main, since this seems pretty uncontroversial. [[User:Aidan9382|Aidan9382]] <sub>([[User talk:Aidan9382|talk]])</sub> 16:41, 22 October 2024 (UTC)

:I've implemented the config change, office padlocks will now start linking to the office section in the protection policy. [[User:Aidan9382|Aidan9382]] <sub>([[User talk:Aidan9382|talk]])</sub> 18:54, 23 October 2024 (UTC)
::Thanks! [[User:Gråbergs Gråa Sång|Gråbergs Gråa Sång]] ([[User talk:Gråbergs Gråa Sång|talk]]) 19:09, 23 October 2024 (UTC)
::Looks good. Office padlocks have the correct destination and full protection padlocks are unchanged. Thanks. [[User:Daniel Quinlan|Daniel Quinlan]] ([[User talk:Daniel Quinlan|talk]]) 19:19, 23 October 2024 (UTC)

== Mobile places infobox incorrectly for [[WP:PIA]] notice ==

Mobile moves infoboxes down after the opening paragraph per [[:mw:Reading/Web/Projects/Lead Paragraph Move]]. On [[Detention of Mahmoud Khalil]] {{tlx|1=pp-extended|2=small=yes}} includes <code><nowiki><p class='PIA-flag' style='display:none; visibility:hidden;'>This page is subject to the extended confirmed restriction related to the Arab-Israeli conflict.</p></nowiki></code>. The text is hidden but mobile still interprets it as an opening paragraph and displays the infobox right after it instead of moving it further down after the first displayed paragraph. Is there a better fix than moving {{tlx|1=pp-extended|2=small=yes}} down in the wikitext? [[MOS:ORDER]] says it should be at the top. [[User:PrimeHunter|PrimeHunter]] ([[User talk:PrimeHunter|talk]]) 09:36, 17 March 2025 (UTC)

:According to the [https://gerrit.wikimedia.org/g/mediawiki/extensions/MobileFrontend/+/a7183b11e63dc28e6baabfc1eb9e62e02baab130/includes/Transforms/MoveLeadParagraphTransform.php#250 code] moving the notice inside a span might be enough. [[User:Sjoerddebruin|<span style="color:var(--color-progressive,#36c); font-weight:var(--font-weight-semi-bold,600); letter-spacing:0.05em;">Sjoerd de Bruin</span>]]&nbsp;[[Overleg gebruiker:Sjoerddebruin|<small style="color:var(--color-progressive,#36c); letter-spacing:0.05em;">({{int:Talkpagelinktext}})</small>]]  09:52, 17 March 2025 (UTC)
::That only targets <code><nowiki><span id="coordinates">...</span></nowiki></code>. We could use it but adding a coordinates id would be hacky. There may be tools looking for that id and getting confused. [[User:PrimeHunter|PrimeHunter]] ([[User talk:PrimeHunter|talk]]) 10:45, 17 March 2025 (UTC)
:::It works in a mobile preview to use a div. [[User:PrimeHunter|PrimeHunter]] ([[User talk:PrimeHunter|talk]]) 18:35, 17 March 2025 (UTC)
:This also means that this text, which exists only for the purpose of the abuse filter, is now present in multiple search engines where those articles are showing up: [https://duckduckgo.com/?t=ffab&q=detention+of+mahmoud+khalil&ia=web Duckduckgo example]. While I get why @[[User:SilverLocust|SilverLocust]] made that edit, they should’ve done it in a way that does not create this slew of issues. One way this could be mitigated is by testing whether adding that as a hidden {{tag|indicator|o}} instead would still work for those purposes, since those do not affect the page output in this way. [[user:stjn|stjn]] 17:31, 19 March 2025 (UTC)
::I've made a [[Special:Diff/1281325360|fix]] (at least temporarily, someone else may have a better suggestion) for the mobile issue and I believe the search issue. Got to go, but I'll subscribe to this section. Email me if there's anything needing a quick response. - Jenson[[User:SilverLocust|SL]]&nbsp;([[User talk:SilverLocust|SilverLocust]]) 18:06, 19 March 2025 (UTC)