Module talk:Protection banner/Archive 1

Page contents not supported in other languages.
From Wikipedia, the free encyclopedia

Too enterprisey

@Mr. Stradivarius: This is just my opinion, but I'm worried that this module is ending up too enterprisey and becoming unnecessarily complicated. Do you agree with this, or is it just me? Jackmcbarn (talk) 15:34, 9 June 2014 (UTC)

I certainly wouldn't want to make it any more complicated, I agree. But what you see there now is the finished structure - the rest is just filling out the details. Can you put up with it as long as it doesn't get any more complicated? Also, if you have any elegent ways to simplify the code, then I'm all ears. :) — Mr. Stradivarius ♪ talk ♪ 16:01, 9 June 2014 (UTC)

Taking stock

@Jackmcbarn: So, the module is finally just about working, and we're now at the stage where we can start writing test cases by comparing the output with the current protection templates. Before that, though, is there anything you would like to change about the way I've structured things? It's simpler than it was when you wrote the comment at the top of the page, but that's not to say we can't do things better. And if we want to do things like swapping round which class is responsible for what, then it's better to do it now to save us from rewriting the test cases. Let me know what your thoughts are. — Mr. Stradivarius ♪ talk ♪ 06:16, 27 June 2014 (UTC)

@Mr. Stradivarius: A few thoughts:
  • The Config class should go away and be replaced with a table that's effectively a singleton instance of what it used to be.
  • The getBannerConfig function should become part of the Protection class.
  • All of the functions that look like "function Foo:getBar() return self:_bar" should go, and the members should be made "public". (This is getting back to the issue of not being overly enterprisey.)
  • Why not use the __tostring metamethod instead of the render method?
  • I don't think we need a Category class. I think a makeCategoryLink function would do just as well.
  • In line with the above entry, ProtectionCategory should go, and the work it does in :render() should instead be Protection:getCategory() or something.
  • The other subclasses of Category should also be changed to individual functions.
That's all I see for now. Let me know what you think of those ideas. Jackmcbarn (talk) 22:19, 27 June 2014 (UTC)
@Jackmcbarn: Thanks, those suggestions make a lot of sense. I was also wondering about turning the getter methods into public properties, so I'll start by converting those. I agree with moving ProtectioCategory:render to the Protection class - should the functions for ErrorCategory, ExpiryCategory and TemplateCategory be moved there too? They all need protection data and title data, so it seems like a good fit. Moving the getBannerConfig to the Protection class and simplifying the Config class is a good idea, but I think we should keep some kind of mechanism to allow specifying an arbitrary table in place of the data in Module:Protection banner/config. That way, we can write the test cases using customised config tables, and we won't have to worry about them breaking if someone updates the main module config. — Mr. Stradivarius ♪ talk ♪ 01:20, 28 June 2014 (UTC)
@Mr. Stradivarius: I changed Config so it just uses the raw table from mw.loadData everywhere. This will work for testing by just passing some table other than the loadData result in when the objects are first created. Jackmcbarn (talk) 01:49, 28 June 2014 (UTC)
@Mr. Stradivarius: Okay, I'm done editing now, so there shouldn't be any more ECs. Anyway, yes, I do think the other category classes should get moved into Protection. Jackmcbarn (talk) 02:06, 28 June 2014 (UTC)
@Jackmcbarn: Thanks. :) I'll start work on converting the other stuff, then. — Mr. Stradivarius ♪ talk ♪ 02:12, 28 June 2014 (UTC)
@Jackmcbarn: I've finished making all the changes you suggested above. Let me know if you think of anything else. — Mr. Stradivarius ♪ talk ♪ 14:23, 28 June 2014 (UTC)
@Mr. Stradivarius: I found a few more changes that I made myself. I have three concerns left, though:
  • It looks like whatever was supposed to call Padlock:setRight never got written, so the protection icons will overlap.
  • I don't really like the way the properties table is being used inside Protection:makeProtectionCategory.
  • Now that title and bannerConfig are part of Protection, can they be removed from Blurb?
Once those are all resolved, I think we're ready to move onto testing and deployment. Jackmcbarn (talk) 22:33, 28 June 2014 (UTC)

@Jackmcbarn: All done:

  • I've fixed the setRight issue by adding a new config table and setting Padlock._right from that in Padlock:initialize.
  • Protection:makeProtectionCategory is now simplified. That extra complexity was left over from when I thought users might need to set the order of the config table with much more freedom, but I no longer think that's necessary.
  • Done.

Let's get started on the test cases. At the moment I'm thinking of having two sets of test cases: one at Module:Protection banner/testcases for the core module functionality, and one at Module:Protection banner/config/testcases to test Module:Protection banner/config against the current template system. Does that sound like a good idea? — Mr. Stradivarius ♪ talk ♪ 12:02, 29 June 2014 (UTC)

@Mr. Stradivarius: If we make testcases for the config at all, then I agree that's where they should go, but I'm not sure if that's necessary at all. Also, something I just noticed looking at the code today is it seems like there's a lot of code that exists only to support {{pp-create}} et al., but those are unused and have been deprecated in favor of salting for a long time, so I don't think it's worth supporting them. Jackmcbarn (talk) 18:30, 29 June 2014 (UTC)
(I see that those are sometimes used in create-protection reasons, but since you recently changed MediaWiki:Titleprotected to not display them anyway, I don't think it's worth worrying about.) Jackmcbarn (talk) 18:43, 29 June 2014 (UTC)
@Jackmcbarn: Thinking about it, I agree that we shouldn't make too much effort for {{pp-create}} when it isn't actually being used here. And indeed, I've just altered it so that all it displays is a template link, and I've taken the check for it out ofMediaWiki:Titleprotected. That way, people will be able to see it in the protection message, and it won't insert a protection banner inside another protection banner. However, I don't think we should make "create" an invalid action altogether, as other wikis might want the functionality. We can allow other wikis to have creation banners by just enabling "create" as an action, and allowing them to add text for them in the banners and defaultBanners config tables, without making the code much more complex. — Mr. Stradivarius ♪ talk ♪ 07:13, 30 June 2014 (UTC)
Even if we did allow create as an action, it still wouldn't work right, since a page that exists cannot be create-protected, and Module:Effective protection level won't lie by saying it is, so the pages would just end up in Category:Wikipedia pages with incorrect protection templates anyway. Jackmcbarn (talk) 17:05, 30 June 2014 (UTC)
@Jackmcbarn: It would have to be used through MediaWiki:Titleprotected on that wiki. I had a search, and Simple English Wikipedia and Chinese Wikipedia are currently using {{pp-create}} in this manner. I suppose we could just recommend that they update their message syntax to match enwiki's, though. — Mr. Stradivarius ♪ talk ♪ 01:38, 1 July 2014 (UTC)
@Mr. Stradivarius: That brings up a debate that I don't think we've had yet. I'm not sure if we should be making our modules support things that are of no use to us just because they'd be of use to another wiki. (To me, that would be a step beyond things like separating config and localization from the code, which I'm perfectly happy with.) Jackmcbarn (talk) 01:45, 1 July 2014 (UTC)
@Jackmcbarn: Fair enough. I suppose if another wiki really wanted a pp-create equivalent, we could always go and implement it over at that wiki. So let's leave create-protection out here, and wait to see if anyone complains. :) The debate over how much we should support will probably be more relevant if/when we get a global module repository. — Mr. Stradivarius ♪ talk ♪ 02:09, 1 July 2014 (UTC)

Error messages

I don't think throwing script errors for invalid input (like the code error('Unsupported action ' .. args.action, 2) on line 86) is the best way of doing things. In my experience, only fairly technical users actually know to click on them and read the error message. Other users will just assume that there is a mistake in the module. At the moment all of the arguments are processed by Protection:initialize. How about calling Protection:new with pcall and then returning an error formatted for wikitext if there is a problem? If there are any unforseen errors in Protection:initialize then they would be returned as wikitext rather than a proper error, but other parts of the module would still produce proper errors. — Mr. Stradivarius ♪ talk ♪ 07:13, 30 June 2014 (UTC)

I guess that will work for now. My plan for later is to make script errors display the message right on the page, and only hide the stack trace behind a click. Jackmcbarn (talk) 17:05, 30 June 2014 (UTC)
I was also having similar thoughts. I originally thought of adding a third parameter to the Lua error function that turned the error into plain wikitext, but I like your idea much better. — Mr. Stradivarius ♪ talk ♪ 01:41, 1 July 2014 (UTC)
@Mr. Stradivarius: Now that Lua errors are displayed right on the page here, I've removed the pcall code. Jackmcbarn (talk) 03:22, 3 October 2014 (UTC)
Thanks for that. :) — Mr. Stradivarius ♪ talk ♪ 05:07, 3 October 2014 (UTC)

Config for doc

@Mr. Stradivarius: I think we should have a separate page for config that's only useful for generating documentation, so that changes to it don't invalidate every page that uses this module. Jackmcbarn (talk) 02:58, 1 July 2014 (UTC)

And the same for the Documentation class. Jackmcbarn (talk) 02:59, 1 July 2014 (UTC)
Good idea. I'll move them to Module:Protection banner/documentation and Module:Protection banner/documentation/config. — Mr. Stradivarius ♪ talk ♪ 03:05, 1 July 2014 (UTC)
@Jackmcbarn: How about the new "description" fields in cfg.banner? Moving them to a submodule would be a little awkward. — Mr. Stradivarius ♪ talk ♪ 03:08, 1 July 2014 (UTC)
@Mr. Stradivarius: Good question. For now, I guess just move the class and leave the config alone, and I'll try to figure something out once it's done. Jackmcbarn (talk) 03:11, 1 July 2014 (UTC)

More templates

I just found two more templates that use pp-meta: {{pp-main-page}} and {{pp-office-dmca}}. At the moment I'm thinking we should support pp-office-dmca (because I don't want to argue with the office), but not pp-main-page (it doesn't have any transclusions). I'm open to other suggestions though. — Mr. Stradivarius ♪ talk ♪ 07:43, 1 July 2014 (UTC)

Now that you mention that, I notice that you currently hardcode most/all of the reasons (dispute, office, reset, vandal) into the main module. I think we should be able to completely specify these from the config module with no special code needed in the main module at all. Jackmcbarn (talk) 15:33, 1 July 2014 (UTC)
I did consider using the algorithm from Protection:getProtectionCategory to generate the banner config fields as well, but I was worried that it might make things overly complicated. Some banners would need four or five different text values to cover all the possibilities. But then again, there is probably a simpler way to do things. If you have any ideas for how the config tables should work, let me know. — Mr. Stradivarius ♪ talk ♪ 15:43, 1 July 2014 (UTC)
Since this module generally won't be ran more than once per page (except for things like its own documentation and test cases), I don't see a reason to use mw.loadData() on the config. If we changed that to require(), we could move some of the business logic there. Jackmcbarn (talk) 16:04, 1 July 2014 (UTC)
@Jackmcbarn: Using require wouldn't be too onerous, I agree. Quite a few pages use two protection templates, e.g. {{pp-dispute}} and {{pp-move-indef}}, or {{pp-vandalism}} and {{pp-pc1}}, but it's rare to see three (and I think those get fixed by the bots). I've tried to imagine how moving the business logic to the config module would work, but I can't quite picture it. What did you have in mind? — Mr. Stradivarius ♪ talk ♪ 06:50, 2 July 2014 (UTC)
@Mr. Stradivarius: My idea: See if the things like cfg.banners.edit.dispute.text are strings or functions. If they're strings, treat them as you do now, but if they're functions, pass in the Protection object and args, and use the function call result as the output. Jackmcbarn (talk) 03:29, 3 July 2014 (UTC)

No wrapper?

@Mr. Stradivarius: I'm confused as to what the purpose of this change was. Can you elaborate? Jackmcbarn (talk) 03:11, 5 July 2014 (UTC)

@Jackmcbarn: It meant that Template:Pp-vandalism/sandbox didn't allow any parameters to be set, because the module was only checking the frame args and not the parent frame args. — Mr. Stradivarius ♪ talk ♪ 03:13, 5 July 2014 (UTC)
I see now. I see a possible shortcoming in Module:Arguments there, actually. I'll think some more about it. Jackmcbarn (talk) 03:18, 5 July 2014 (UTC)

MediaWiki namespace

@Jackmcbarn: The current protection templates don't display in the MediaWiki namespace, due to {{PROTECTIONLEVEL}}} not returning anything. However, we treat them as normal fully protected pages thanks to the logic in Module:Effective protection level. I don't think that this will matter in practice, but do you have any preference for what to do? I see that we also have a message 'explanation-blurb-full-nounprotect' which is used for the MediaWiki namespace, so we'd need to get rid of that if we went with the behaviour of the current protection templates. — Mr. Stradivarius ♪ talk ♪ 03:19, 10 July 2014 (UTC)

@Mr. Stradivarius: I've thought about this before too. The current system doesn't use that, cascading protection, the titleblacklist, or anything at all except the normal protection level. Maybe we shouldn't use Module:Effective protection level at all here, instead just using title:protectionLevels. Jackmcbarn (talk) 04:21, 10 July 2014 (UTC)
@Jackmcbarn: I'd say we need to detect at least cascading protection, as it will be useful for templates whose cascading protection level and normal protection level don't match. We also need {{PENDINGCHANGELEVEL}} for the pending changes banners. The rest might not be important for our purposes, but with three different things to detect I'd say we should probably stick with using Module:Effective protection level for ease of maintenance. — Mr. Stradivarius ♪ talk ♪ 04:37, 10 July 2014 (UTC)
@Mr. Stradivarius: In that case, I'd just not do anything special about it, since pages in the MediaWiki namespace generally don't contain protection templates anyway. Jackmcbarn (talk) 04:40, 10 July 2014 (UTC)

Deployment

@Jackmcbarn: I think we are just about ready to deploy this now. The test cases are written, and my spot checks for discrepancies between the module and the existing protection templates are looking good. I think what we should do now is invite other editors to test the sandbox templates to see if they work as expected, and then deploy if everything looks ok. Is there anything else you think needs doing before we advertise this? — Mr. Stradivarius ♪ talk ♪ 13:54, 22 July 2014 (UTC)

@Mr. Stradivarius: I think everything's ready to go, but I'm not sure how you want other users to test this. Jackmcbarn (talk) 18:11, 22 July 2014 (UTC)
Wow, you really don't like Module:Middleclass, do you? :) Still, it's not important. I'll invite others to look at this - watch this space. — Mr. Stradivarius on tour ♪ talk ♪ 22:50, 22 July 2014 (UTC)
@Mr. Stradivarius: It's not that I don't like it; it's that I don't think it's necessary in a lot of cases. I admit it's useful for things such as mixins, but here it isn't, since I was able to get rid of it adding virtually no new code. (My "ulterior" motive is the job queue.) Jackmcbarn (talk) 02:50, 23 July 2014 (UTC)

Proposal to convert all protection templates to use this module

Recently, User:Jackmcbarn and I have finished writing Module:Protection banner, which is intended to be a replacement for {{pp-meta}} and all of its daughter templates, such as {{pp-vandalism}}, {{pp-dispute}}, {{pp-template}}, etc. The module is a factory for producing protection templates; the actual templates themselves are defined in the configuration module at Module:Protection banner/config. The test cases are at Module:Protection banner/testcases (run). You can test the full functionality of the module out using the #invoke syntax outlined in the documentation, or by using the {{pp}} template. There are also replacements for all the existing protection templates in those templates' sandboxes:

Please test these out and see if you can find any problems with them. If there are no issues, I hope to switch the templates over to the Lua module in the next few days. — Mr. Stradivarius ♪ talk ♪ 23:32, 22 July 2014 (UTC)

Sounds, thanks for doing this! They look really good. Just one question, would it be possible to have them automatically query and display the expiry date (doing away for the need of the expiry parameter)? I'm not sure that there is a magic word which will give that but I thought it was worth asking as you guys know MediaWiki a lot better than I do. Callanecc (talk • contribs • logs) 00:48, 23 July 2014 (UTC)
No, not currently. It wouldn't be hard to add this to the module if this functionality becomes available in MediaWiki in the future, though. — Mr. Stradivarius ♪ talk ♪ 00:56, 23 July 2014 (UTC)
Thanks, Mr. Stradivarius it looks good to me. One other thing I think needs to be changed, whenever pp-template/sandbox is called and used with indef full protection, it should call the red lock rather than the gold one, which is what pp-template does now. See User:Callanecc/sandbox (for /sandbox version) and User:Callanecc/sandbox2 for current version. Callanecc (talk • contribs • logs) 01:12, 23 July 2014 (UTC)
@Callanecc: I've fixed this in the module now. — Mr. Stradivarius ♪ talk ♪ 02:55, 23 July 2014 (UTC)
@Callanecc: I do plan to add expiry detection to Scribunto in the near future. Jackmcbarn (talk) 02:51, 23 July 2014 (UTC)
Also, some pings for potentially interested parties: Cyberpower678, Σ, Tizio, Redrose64, MSGJ, Technical 13. — Mr. Stradivarius ♪ talk ♪ 01:00, 23 July 2014 (UTC)

I welcome this change. →Σσς. (Sigma) 01:04, 23 July 2014 (UTC)

  • I'm not sure what improvement this offers, but I don't oppose it. Callanecc}, hopefully I'll get a little free time next week to work on a userscript of mine that might interest you. It will display the protection icons (whether the page has the template or not) in the personal toolbar and mouseove will offer the expiration. Once it is done I'll leave you a note and you can try it out. Maybe if enough people think it is a good idea we can add it as a gadget and the pp templates would only be used for categorizations in the future if needed. Anyways, it's 1 am and I'm exhausted. — {{U|Technical 13}} (e • t • c) 05:14, 23 July 2014 (UTC)
    The Lua version detects protection levels automatically for all banners, and performs better than the old wikitext templates. Those are the two big advantages to enwiki. A third is that it's now easily customisable for other wikis and other languages. And a fourth is that no coding should be necessary to add new banners - all that will be needed is to update the configuration. — Mr. Stradivarius ♪ talk ♪ 05:34, 23 July 2014 (UTC)

Thanks Mr. Stradivarius! All looks good to me, good work guys. :) Sounds interesting Technical 13, I'd definitely take an interest in that. Regards, Callanecc (talk • contribs • logs) 06:27, 23 July 2014 (UTC)

  • I oppose not supporting this proposal and support anyone that opposees this to receive a trout. :p—cyberpower ChatLimited Access 06:27, 23 July 2014 (UTC)

I've just switched all the templates over to use this module. Please leave a note here if you notice anything strange. — Mr. Stradivarius ♪ talk ♪ 17:53, 5 August 2014 (UTC)

@Mr. Stradivarius: {{Pp-semi-indef}} shows the whole banner on pages instead of just the lock if the small parameter isn't set, but this wasn't needed before conversion. This needs to either fixed, or someshould add this parameter to many-many pages. Armbrust The Homunculus 19:33, 5 August 2014 (UTC)
@Armbrust: Well-spotted - this edit should have fixed it. — Mr. Stradivarius ♪ talk ♪ 19:37, 5 August 2014 (UTC)
@Mr. Stradivarius: One aspect of the recent edit has messed up the "expiry" parameter. Whether you type August 15, 2014 or 15 August 2014, it always displays at "15 August, 2014". You can see an example at Teenage Mutant Ninja Turtles (2014 film). Sock (tock talk) 11:59, 8 August 2014 (UTC)
@Sock: Actually, the old templates didn't vary the output like that either - you got the same date formatting whether you typed "August 15, 2014" or "15 August 2014". What they did do was have consistent MDY formatting, whereas the module was set to use DMY formatting. I've switched it to MDY formatting in line with the old template system. — Mr. Stradivarius ♪ talk ♪ 13:39, 8 August 2014 (UTC)
@Mr. Stradivarius: I actually didn't know that, my bad. Thank you for fixing the formatting! Sock (tock talk) 13:54, 8 August 2014 (UTC)
@Mr. Stradivarius: For the templates that you added small=true as a wrapper option to, it's now impossible to display the large version of them, since wrappers currently overrides the passed parameters. I've written a (currently failing) test case for this. Jackmcbarn (talk) 02:20, 10 August 2014 (UTC)
@Jackmcbarn: Ah yes, I see {{pp-template}} used to allow large banners, but the default was small. The question is, do we want to allow overwriting of all parameters or just some of them? If we allowed overwriting all the parameters then editors could use a template for something completely different than its original purpose, e.g. {{pp-move-vandalism|dispute|action=edit}}. On the other hand, I doubt that many templates would get misused in that way, so it might not be worth worrying about. What are your thoughts? — Mr. Stradivarius ♪ talk ♪ 12:54, 10 August 2014 (UTC)
@Mr. Stradivarius: I think we should just let all parameters be overridden for simplicity. I don't think it's worth the trouble to stop edge cases that will probably never happen. Jackmcbarn (talk) 15:59, 10 August 2014 (UTC)
@Jackmcbarn: Ok, I've updated the sandbox to let all parameters be overridden. (I made a tweak to the test cases as well.) Does that look ok to you? — Mr. Stradivarius ♪ talk ♪ 16:45, 10 August 2014 (UTC)
@Mr. Stradivarius: Looks good to me. Jackmcbarn (talk) 17:06, 10 August 2014 (UTC)
I've updated the module. — Mr. Stradivarius ♪ talk ♪ 17:26, 10 August 2014 (UTC)

Misleading icons and text

 – Redrose64 (talk) 10:24, 5 September 2014 (UTC)

Sometimes WP:PC icons and text are visible at the top right, even though the article is semi-protected, which is misleading. From what I can tell, the problem is that, if an article is tagged with both, semi-protection overrides pending changes but the flaggedrevs icon and /light/ silver padlock of pending changes are still being shown. In other words, it says "This is the latest accepted revision, accepted on <date>." and the mouseover of the /light/ silver padlock says "All edits by unregistered and new users are subject to review", but anonymous users /cannot/ edit, and the "Edit" tab is "View source". As of 4:03 UTC 5 Sep., August 2014 celebrity photo leaks is an example where this problem occurs. --82.136.210.153 (talk) 04:03, 5 September 2014 (UTC)

The example page has since been 'fixed', but obviously the problem I described remains. --82.136.210.153 (talk) 19:37, 6 September 2014 (UTC)
The problem isn't in these templates. It happens because even though semi-protection makes PC1 redundant, it doesn't automatically cause PC1 to be removed. If we want to, though, we could hack around this by bailing out of the autoreview=autoconfirmed case if edit=autoconfirmed. (And we might as well also bail out of autoreview=reviewer if edit=sysop if we do that.) Jackmcbarn (talk) 19:49, 6 September 2014 (UTC)
I've just implemented a change that does that, so this should be fixed now. (If you see any pages where it's not fixed, purge them.) Jackmcbarn (talk) 21:14, 6 September 2014 (UTC)
Thanks Jackmcbarn. --82.136.210.153 (talk) 21:28, 6 September 2014 (UTC)

Use of pp-template in template sandboxes

It's common practice for a template's sandbox to match the live template, except for those areas that are under test. This means that if the last few lines of the live template are something like this 

}}<noinclude>
{{documentation}}
</noinclude>

the last few lines of the /sandbox will be exactly the same. Sometimes a template has no doc page, but is protected, so we might find that it ends with 

}}<noinclude>
{{pp-template|small=yes}}
</noinclude>

The last few lines of the /sandbox should be exactly the same, but if you do this, the sandbox ends up in Category:Wikipedia pages with incorrect protection templates. One fix is to do this; but if I make exactly the same change to the live template, it attracts complaints as "unnecessary".

I go through that category every few months, because although there are bots that clean it up, they always miss some pages, mainly {{pp-move-indef}} being used on a page which isn't move protected, but plenty of others are also passed over by the bots. Accordingly, I work through the cat, check the current prot level, and remove templates or amend their params as necessary. In the past I've never come across so many template sandboxes in the category - I've only got as far as "D" but I must have come across something like twelve cases of template sandboxes in the cat: most were using {{pp-template}}; and few of them had been edited recently; all were unprotected; none of them had had their prot level changed recently (most had never been protected). Therefore, the {{pp-template}} was present on these sandboxes at the time that I last went through the cat in April/May; and the sandboxes were also unprot at the time, yet the sandboxes weren't in the cat.

I find that in the meantime, {{pp-template}} it was Lua-ised on 5 August 2014, so something happened during Lua-isation to cause a change in behaviour. I've found that beforehand, it had code to detect usage on a sandbox, and if so, it would not categorise; it seems that this feature has been lost. Is there any chance that it could be restored? --Redrose64 (talk) 13:41, 18 September 2014 (UTC)

IMO, the best way to fix this would be to replace {{pp-move-indef}} with {{documentation}}, even if the template has no doc page. Jackmcbarn (talk) 14:21, 18 September 2014 (UTC)
It's not {{pp-move-indef}}; it's {{pp-template}}. --Redrose64 (talk) 15:26, 18 September 2014 (UTC)
@Redrose64: Oops. My solution is the same though. Jackmcbarn (talk) 15:28, 18 September 2014 (UTC)
It seems a bit strange to use that method to fix Template:Documentation/core/sandbox, Template:Documentation/core2/sandbox, Template:Documentation/end box2/sandbox, and Template:Documentation/start box/sandbox. --Redrose64 (talk) 16:58, 18 September 2014 (UTC)
Template talk:Permanently protected is in Category:Wikipedia pages with incorrect protection templates; it shouldn't be, because the single use of {{pp-template}} has |demolevel=semi which prior to the Lua-isation, prevented the page from being categorised inappropriately. --Redrose64 (talk) 20:40, 3 October 2014 (UTC)
I've fixed that by using |category=no for the moment. Is this enough of a problem that the demolevel parameter needs to be re-added? For the test cases, it's enough to use internal Lua functions to simulate protection levels rather than doing it from a parameter that would have to be checked every time. — Mr. Stradivarius ♪ talk ♪ 15:52, 4 October 2014 (UTC)
I agree that what you did is a good fix. We shouldn't re-add demolevel. Jackmcbarn (talk) 02:21, 5 October 2014 (UTC)
Wikipedia:Template messages/Maintenance is also in Category:Wikipedia pages with incorrect protection templates because of these eight lines: 
{{Tlrow|pp-dispute|demolevel=sysop}}
{{Tlrow|pp-vandalism|demolevel=autoconfirmed}}
{{Tlrow|pp-vandalism|demolevel=sysop}}
{{Tlrow|pp-protected|demolevel=autoconfirmed}}
{{Tlrow|pp-protected|demolevel=sysop}}
{{Tlrow|pp-sock|demolevel=autoconfirmed}}
{{Tlrow|pp-move|demolevel=sysop}}
{{Tlrow|pp-office|demolevel=sysop}}
- we need to demonstrate the templates without improper categorisation. --Redrose64 (talk) 23:00, 13 October 2014 (UTC)
I hadn't thought of that use. @Mr. Stradivarius: I guess we do need to re-add demolevel to get those to display right. Jackmcbarn (talk) 03:10, 14 October 2014 (UTC)
Fair enough, let's add it back in. That should be an easy fix. — Mr. Stradivarius ♪ talk ♪ 03:27, 14 October 2014 (UTC)
Ok, I think this should be all that's needed. I've changed all of the protection template sandboxes to point to the module sandbox, so you can try out the new code with {{pp-vandalism/sandbox}}, etc. It seems to be working ok on Wikipedia:Template messages/Maintenance - Jackmcbarn, does this look ok to you? — Mr. Stradivarius ♪ talk ♪ 03:44, 14 October 2014 (UTC)
@Mr. Stradivarius: Looks like that will work to me, and I added one other fix related to it. One thing I'm wondering is whether or not setting demolevel should cause any special behavior of categories. (Did it before?) Jackmcbarn (talk) 04:06, 14 October 2014 (UTC)
@Jackmcbarn: I see that pp-meta did with the code you added back in February, but I looked in the old versions of pp-template, pp-dispute and pp-vandalism and they just treat it like a normal protection level. (I haven't checked all of the others yet.) I think makes the most sense to have demolevel produce the same categories as a real protection would - otherwise you couldn't consider it a true demonstration. Unwanted categories can always be suppressed with |category=no. — Mr. Stradivarius ♪ talk ♪ 06:52, 14 October 2014 (UTC)
@Mr. Stradivarius: I guess that will work then. Jackmcbarn (talk) 15:38, 14 October 2014 (UTC)
Ok, I've updated the module. — Mr. Stradivarius ♪ talk ♪ 21:49, 14 October 2014 (UTC)
and Wikipedia:Template messages/Maintenance is no longer in Category:Wikipedia pages with incorrect protection templates, which is good. But it is in seven other cats: Category:Wikipedia pages protected due to dispute; Category:Wikipedia protected pages without expiry; Category:Semi-protected project pages; Category:Protected project pages; Category:Wikipedia pages semi-protected from banned users; Category:Wikipedia move-protected project pages; Category:Wikipedia Office-protected pages. Not sure if that's good or bad. --Redrose64 (talk) 23:59, 14 October 2014 (UTC)
@Redrose64: We already support category=no to fix that, but it's not getting used there for some reason. Jackmcbarn (talk) 00:00, 15 October 2014 (UTC)
I've added |category=no to those templates. If there are any other demonstration templates out there, they can be fixed in the same way. — Mr. Stradivarius ♪ talk ♪ 06:05, 15 October 2014 (UTC)

pp-template and move protection

Would it be possible for {{pp-template}} to categorise the template into Category:Wikipedia move-protected templates if the page is full or template editor move protected? Also so that the template can be used when there is no edit protection such as edit=none move=template editor. Thanks, Callanecc (talk • contribs • logs) 07:40, 29 September 2014 (UTC)

@Callanecc: It will be soon, but we're waiting for a software change before we can easily do it. Jackmcbarn (talk) 14:16, 29 September 2014 (UTC)
I have some additional suggestions, but of an exquisitely low priority. The icon should probably say when the template is both semi-protected and move-protected (currently, the move-protection icon takes priority). A color intermediary between those of each icon may also be helpful to differentiate easily. And the same could be done for modules (for them it's the semi-protected icon that takes priority), along with a new Category:Wikipedia move-protected modules (there are at least dozens already). Cenarium (talk) 01:25, 12 November 2014 (UTC)
@Cenarium: Move protection and edit protection often go hand in hand. When a page has no prot of any kind, an admin who intends to protect the page against editing selects the new prot level from a menu, and selects (or types in) an expiry. As they do this, the move protection is automatically set to the same level and duration: the admin needs to make a conscious decision to not set the move prot. For many people, knowing that a page is edit protected (also why and for how long) is much more important than knowing that it is move prot. Additionally, it's not worth showing a move-protection icon for any page that is semi-protected for moves - these are essentially unprotected for moves, since non-confirmed users can't move pages. --Redrose64 (talk) 15:39, 12 November 2014 (UTC)
I know how it works, I'm an admin. I thought it was obvious we were talking about templates/modules with template or full move protection and no or semi edit protection. Example template, example module. Cenarium (talk) 18:26, 12 November 2014 (UTC)
Available icons sufficiently different from existing ones are File:Padlock-turquoise.svg, File:Padlock-lightblue.svg and File:Padlock-green.svg. See also Choose a padlock. Cenarium (talk) 21:06, 12 November 2014 (UTC)
Turquoise looks too much like the one we use for SALTing, and green is the one we use for move-protection. Jackmcbarn (talk) 21:46, 12 November 2014 (UTC)
The later is File:Padlock-olive.svg but it's similar yeah. Cenarium (talk) 22:12, 12 November 2014 (UTC)

pp-semi-indef

Can {{pp-semi-indef}} be changed so that it will only work if there is an indef semi on the page, otherwise it displays in Category:Wikipedia pages with incorrect protection templates? Callanecc (talk • contribs • logs) 05:18, 12 October 2014 (UTC)

@Callanecc: Not yet, as we currently can't detect protection expiry dates from Lua. However, Jackmcbarn has added the patch for this to Gerrit, so we might have this functionality soon. — Mr. Stradivarius ♪ talk ♪ 10:04, 12 October 2014 (UTC)
Thanks Mr. Stradivarius, can it not show and trigger the category if the page is full protected? Callanecc (talk • contribs • logs) 11:16, 12 October 2014 (UTC)
@Callanecc: Not at the moment - that would require a rewrite of the protection code and the config. That's something that we will need to put on the list of fixes for when this gets rewritten. — Mr. Stradivarius ♪ talk ♪ 12:13, 12 October 2014 (UTC)

Category for semi-protected and template/fully protected modules

Currently, semi-protected modules end up in the general Category:Wikipedia semi-protected pages category, and template/fully protected modules end up in Category:Wikipedia protected pages. Could we have specific categories for them so they aren't in the main categories ? I don't know Lua at all so I won't try. The category names would be : Category:Wikipedia semi-protected modules and Category:Wikipedia protected modules. There's also Category:Modules subject to page protection but not all modules use {{module rating}}, so this can't be used in general. Cenarium (talk) 01:04, 12 November 2014 (UTC)

@Cenarium: These edits should do the trick. You can test it out with {{pp/sandbox}}. If everything looks ok we can create the categories and update the main module config. One thought - might any bots be using Category:Wikipedia protected pages and Category:Wikipedia semi-protected pages to track Lua modules? If so, they would need to be updated after this change was made. — Mr. Stradivarius ♪ talk ♪ 02:13, 12 November 2014 (UTC)
I've tested it and it works as intended. The template is added by the module documentation, so by Module:Documentation through MediaWiki:Scribunto-doc-page-show. So it's automatic and there should be no need for bots to get involved. I've created the categories and I think the changes can now be made. Cenarium (talk) 02:59, 12 November 2014 (UTC)
 Done I've performed the edit. Cenarium (talk) 19:08, 12 November 2014 (UTC)

Conversion to <indicator>

I am in the process of turning {{top icon}} and the likes to use <indicator>. This module however builds its top icon (using a div) itself. I'd like to test the indicator tags in the sandbox, but how do I call a parser tag? -- [[User:Edokter]] {{talk}} 10:48, 22 March 2015 (UTC)

@Edokter: You need to preprocess it using one of the frame object methods, probably frame:extensionTag. — Mr. Stradivarius ♪ talk ♪ 08:23, 23 March 2015 (UTC)
I may need some help with that. Basically, the only thing needing change is function Padlock:__tostring(), so that it generates the indicator tag instead of a div. The tag only needs a name parameter and the image as its content. -- [[User:Edokter]] {{talk}} 08:47, 23 March 2015 (UTC)
Fair enough - it isn't the easiest module in the world to understand, I admit. I've written the necessary code and switched the module over to use indicator tags. If you need to tweak the names attributes, you can specify a different name for each protection action in the "padlockIndicatorNames" table in Module:Protection banner/config. — Mr. Stradivarius ♪ talk ♪ 13:59, 23 March 2015 (UTC)
And undone again - the code looks fine, but the padlocks clash with topicons that haven't been converted yet. I see that we'll need to roll out all the templates at the same time. — Mr. Stradivarius ♪ talk ♪ 14:06, 23 March 2015 (UTC)
Indeed... I wanted to test it first anyway, but you were to quick. We need to pick a time to switch both. I have {{top icon/sandbox}} ready to deploy. If you think your code is ready, feel free to deploy both. -- [[User:Edokter]] {{talk}} 19:48, 23 March 2015 (UTC)

Error when viewing page while not logged in

Hi all - This was reported to OTRS just now, and I verified that is happening. When I load Anita Sarkeesian I see this error at the top. Apparently it's something specific to that page, because I tried Louis Zamperini and the error does not show up. I know little about modules so I figured I'd report it here. §FreeRangeFrogcroak 22:16, 26 March 2015 (UTC)

Ping @Edokter: who seems to have made the latest edits. §FreeRangeFrogcroak 22:17, 26 March 2015 (UTC)
See above. Should be fixed now. -- [[User:Edokter]] {{talk}} 08:22, 27 March 2015 (UTC)

pp-upload

Could an option for a purple lock (WP:UPLOAD-P) be incorporated into the lua module? Callanecc (talk • contribs • logs) 05:34, 20 April 2015 (UTC)

Support. Though it does require incorporating the upload protection level into all the tables in /config, as it is completely absent. -- [[User:Edokter]] {{talk}} 07:49, 20 April 2015 (UTC)

Custom reason

Is it possible to add a parameter so that a custom reason can be used in the banner version of the template? Thanks, Callanecc (talk • contribs • logs) 08:30, 23 April 2015 (UTC)

@Mr. Stradivarius: this one and the one above. Callanecc (talk • contribs • logs) 06:43, 17 May 2015 (UTC)

Splitting the tracking categories

I've suggested splitting the protected template and module tracking categories, which would presumably necessitate a change to this module, here. Alakzi (talk) 11:19, 25 August 2015 (UTC)

Protected edit request on 6 September 2015

Per Wikipedia:Categories for discussion/Log/2015 August 25#Category:Wikipedia protected templates, merge Module:Protection banner/config/sandbox to split the categories. Alakzi (talk) 08:09, 6 September 2015 (UTC)

Done — Mr. Stradivarius ♪ talk ♪ 08:46, 6 September 2015 (UTC)

Magic word for protection expiry

A magic word for the protection expiry has been added in recently merged gerrit:255717, which should be deployed in a couple of days. There's also a commit for the same with pending changes, gerrit:255719 but it hasn't yet been merged. Cenarium (talk) 15:28, 7 December 2015 (UTC)

@Mr. Stradivarius, Edokter, and Jackmcbarn: The magic word is now available! I've created Module:Effective protection expiry and put it to use in the sandbox of protection banner. Do you any suggestions on the implementation ? Cenarium (talk) 22:04, 10 December 2015 (UTC)
I made a minor tweak and set the config page to the main config instead of the sandbox. Otherwise, it is all looking good. Thanks for your work on this. — Mr. Stradivarius ♪ talk ♪ 23:43, 10 December 2015 (UTC)
A click on an ISBN number like ISBN 9780300144246 leads to a page like Special:BookSources/9780300144246 which currently displays this at top:
Lua error: invalid expiry date ("--"). Lua error: invalid expiry date ("--").
Special:BookSources uses Wikipedia:Booksources which transcludes {{pp-move}} and {{pp-vandalism}} at the top. I guess the new code doesn't like a protection template on a special page. It was reported at Wikipedia:Village pump (technical)/Archive 142#Lua error message on ISBN book search page. PrimeHunter (talk) 19:12, 13 December 2015 (UTC)
Indeed, the magic word returns nothing on special pages. I've made Module:Effective protection expiry return 'unknown' instead of empty string, which fixed this issue. Thanks for pointing this out, Cenarium (talk) 20:57, 13 December 2015 (UTC)

Categorization of protected redirects

Paine Ellsworth enhanced Template:This is a redirect to automatically sense protection levels and categorize them: 

<!--
  Automatically detect protected redirects:
--><includeonly>{{#switch: {{PROTECTIONLEVEL:move}}
   |sysop|templateeditor={{pp-move|small=yes}}
 }}{{#switch: {{PROTECTIONLEVEL:edit}}
   |sysop={{pp-protected|small=yes}}{{R protected|embed=yes}}
   |templateeditor={{pp-protected|small=yes}}{{R template protected|embed=yes}}
   |autoconfirmed={{pp-protected|small=yes}}{{R semi-protected|embed=yes}}
   | <!--Not protected, or only semi-move-protected-->
 }}</includeonly>

This relies on {{pp-move}} and {{pp-protected}} to categorize these redirects. I believe this is done via Module:Protection banner's configuration page: Module:Protection banner/config.

I don't see anything in the module that is detecting redirects for special categorization. Template:This is a redirect transcludes {{R protected}}, which populates Category:Protected redirects.

I believe that this module is putting protected redirects in Category:Wikipedia protected pages. That is marked with {{Category diffuse}} indicating that "pages in this category should be moved to subcategories where applicable." The appropriate subcategory is indeed Category:Protected redirects, as This is a redirect / R fully protected have correctly populated. However, as the module itself doesn't have diffusion logic, then the best it can do is populate the next higher level category, which in this case is redundant.

This came to my attention when I was looking at the redirect Colour (which was long-ago protected to prevent WP:ENGVAR-related wars). You may check my recent edits to that.

I don't know how important this is, or what the best solution is, but thought I'd just mention it, and leave it for Paine, Mr. Stradivarius and whoever else might be interested to sort out as you want. Thanks, Wbm1058 (talk) 23:29, 9 January 2016 (UTC)

The module uses quite an interesting algorithm to decide what category to use on a given page - search for "protection categories" in Module:Protection banner/config for the details on how it works. It doesn't have explicit detection for redirects, though, as redirect pages never had padlock icons when it was written. There are three ways I can think of to deal with this:
  1. Create a new protection template with a "redirect" reason, probably called {{pp-redirect}}. This would be intuitive for people adding protection templates to redirect pages, but would also allow non-redirect pages to be given a "redirect" protection reason.
  2. Treat redirects as a kind of namespace. Here we would give redirects a namespace of "redirect", regardless of what namespace they are actually in. This would mean that only redirects could be categorised as redirects, but it would mean that we couldn't make more fine-grained categories based on namespace.
  3. Add redirect detection as a full-blown key to the protection category algorithm. This would prevent non-redirect pages as being categorised as redirects, and it would also allow us to have different categories for redirects in different namespaces, but it would double the number of potential table lookups the algorithm would have to make each time the module is run. I was worried that this might impact performance, but it turns out to only cost about 20 microseconds for each run. (However, if we wanted to add more such keys in the future, this time would increase exponentially.)
If we are only going to use Category:Protected redirects for redirect pages, then I think #2 would be the way to go. However, if in the future we want to have several categories for protected redirects in different namespaces, then #3 would be the way to go. What do others think would be the best way forward? — Mr. Stradivarius ♪ talk ♪ 01:02, 10 January 2016 (UTC)

Suggesting a pp-unsourced template

I was thinking of a template similar to the format of pp-sock or pp-blp (both semi-protection templates) called "pp-unsourced". My idea is to put in "This article has been semi-protected until DATE to promote compliance with Wikipedia's policy on verifiability". I recently asked Callanecc about this and thought it was a good idea but lacks the knowledge about the Module stuff. I would appreciate it if you like my idea of a pp-unsourced template. Qwertyxp2000 (talk | contribs) 19:48, 30 January 2016 (UTC)

As I said on my talk page, it sounds like a good idea to me. Callanecc (talk • contribs • logs) 23:41, 30 January 2016 (UTC)
What do other users think about this idea? I would like some more users to collaborate with this consensus. Qwertyxp2000 (talk | contribs) 23:48, 30 January 2016 (UTC)

walkHierarchy relying on undefined behaviour?

@Jackmcbarn: I've just been looking at the walkHierarchy function again, and I've realised that it makes multiple calls of next(toWalk) while simultaneously adding values to toWalk. This obviously seems to work, as it has been running without problems for quite a while now, but looking at the reference manual entry for the "next" function it says that "Behavior is undefined if, when using next for traversal, any non-existing key is assigned a value." That seems to be what we are doing here - should we change the function to something else? I'm thinking that using an array might work. — Mr. Stradivarius ♪ talk ♪ 03:04, 3 March 2016 (UTC)

@Mr. Stradivarius: Not quite. Note that it's always calling next with only one argument, so it's always getting the "first" element. There's no undefined behavior here; it's just unspecified what order we'll get them in. The undefined behavior is only if you call next with multiple arguments and add things. What we're doing is equivalent to repeatedly stopping and restarting the iteration from the beginning. Jackmcbarn (talk) 03:12, 3 March 2016 (UTC)
Aha, that makes sense. I'll leave it as it is then. Thanks. :) — Mr. Stradivarius ♪ talk ♪ 03:23, 3 March 2016 (UTC)

Protected edit request on 17 June 2016

In Module:Protection banner/config, each of the description arguments is a sentence fragment and thus should have their periods removed per MOS:TABLE. Thanks! – voidxor 20:10, 17 June 2016 (UTC)

You need to be more specific and possibly provide text (or diff from the sandbox) that can be pasted when using the edit protected template. -- [[User:Edokter]] {{talk}} 20:35, 17 June 2016 (UTC)
Roger. Sorry. My suggested changes are now in the sandbox. I am additionally recommending that we wikilink Digital Millennium Copyright Act. – voidxor 22:09, 17 June 2016 (UTC)
Done — Martin (MSGJ · talk) 14:41, 20 June 2016 (UTC)

Protected edit request on 11 July 2016

Change the title of the page from 'Colonial Dames of America' to 'The Colonial Dames of America'--CDA Brendan (talk) 18:12, 11 July 2016 (UTC)

CDA Brendan (talk) 18:12, 11 July 2016 (UTC)

If you're referring to the page Colonial Dames of America, not done per WP:THE. Also, this page was not the page to request a page move. Consider requesting moves at WP:RMT. This request itself was misplaced. — Andy W. (talk · ctb) 18:20, 11 July 2016 (UTC)

Protected edit request on 03 August 2016

Please sync to the module sandbox (minus the config sandbox call around line 14) please. This brings some queued changes by Jackmcbarn to live, as well as recognition of the extendedconfirmed prot level for the edit request initiation part of this module.

This does not include syncing Module:Protection banner/config / sandbox (needs to wait for the ECP RfC to finish first) — Andy W. (talk · ctb) 23:32, 3 August 2016 (UTC)

Done Jackmcbarn (talk) 01:56, 4 August 2016 (UTC)

Protected edit request on 21 August 2016

Please sync the config submodule to Module:Protection banner/config/sandbox. This will allow {{pp|ecp}} to display a message for extended confirmed protection. (Discussed this with Mr. Stradivarius on his talk, and just need a sync at this point.)

I will sync {{Pp-30-500}} separately after this request. Thanks — Andy W. (talk · ctb) 22:21, 21 August 2016 (UTC)

Done — Mr. Stradivarius ♪ talk ♪ 06:47, 23 August 2016 (UTC)

Expiry parameter can be deprecated

Since Module:Effective protection expiry now also supports 'autoreview', there is no need to provide an expiry parameter. Cenarium (talk) 10:47, 23 September 2016 (UTC)

Protected edit request on 3 February 2017

If the protection banner is placed on a page that is extended protected, it says "Please discuss any changes on the talk page; you may submit an edit request to ask for unconversial changes supported by consensus". But it says that on talk pages too and a non-extended confirmed user wouldn't be able to discuss changes. Can that sentence be changed to "If you cannot edit this page and you wish to make a change, you can request unprotection, log in, or create an account.", like it is with the protection banner on semi-protected pages? —MRD2014 (talk • contribs) 03:49, 3 February 2017 (UTC)

Not done for now: Please sandbox your proposed changes — Martin (MSGJ · talk) 09:27, 3 February 2017 (UTC)

"This article is extended-protected under extended confirmed editing restrictions"

When I hover over the blue padlock at Donald Trump I get the above verbose and opaque words. Where do they come from? How can we change them? I think this is because Module:Protection_banner/config says 

		ecp = {
			description = 'For articles in topic areas authorized by'
				.. ' ArbCom or'
				.. ' meets the criteria for community use',
			tooltip = 'This ${PAGETYPE} is ${PROTECTIONLEVEL}'
				.. ' under extended confirmed editing restrictions',
			alt = 'Extended-protected ${PAGETYPE}',

Could we change the tool tip bit to something like 

			tooltip = 'This ${PAGETYPE} is extended-confirmed protected',

(no need to go on to a second line) (also, I don't know why there is less indentation in the second code snippet, I used the same number of tabs.)

I don't have a strong opinion on what it should be changed to, so long as it is shorter and clearer.

Yaris678 (talk) 10:32, 21 March 2017 (UTC)

OK. I have made the change and it doesn't seem to have had an effect, despite me purging the cache. Am I missing something? Yaris678 (talk) 17:07, 22 March 2017 (UTC)
You have to purge pages using a template or module and not purge the template/module itself. It works for me at Vanniyar after purging that article. PrimeHunter (talk) 17:41, 22 March 2017 (UTC)
OK. I didn't purge enough. It works for me too, now I have. Thanks for your help. Yaris678 (talk) 08:59, 23 March 2017 (UTC)

Protected edit request on 22 March 2017

"South Korean rapper, producer and song-writer, and boyfriend kim seokjin" I think this sentence boyfriend Kim seokjin need to be change into more reliable content with "leader of BTS". Thank you Lulutae (talk) 11:44, 22 March 2017 (UTC)

Not done: You seem to be on the wrong page. Please suggest your change on the talk page of the article concerned. — Martin (MSGJ · talk) 12:01, 22 March 2017 (UTC)

Protected edit request on 26 March 2017

Please change "All edits by unregistered and new users are subject to review" to "Edits to this page from new or unregistered users are subject to review prior to publication" per Wikipedia:Village pump (proposals)#More descriptive pending changes edit notice. — Train2104 (t • c) 15:36, 26 March 2017 (UTC)

Done. Jo-Jo Eumerus (talk, contributions) 16:11, 26 March 2017 (UTC)

Date but no time is misleading

See this. The banner clearly says that the protection expires today, but it won't actually expire until nearly 16 of the 24 hours of "today" have completed. Could the expiry time be added? Apologies if this is an FAQ? --Dweller (talk) Become old fashioned! 09:54, 9 October 2018 (UTC)

Mr._Stradivarius, you're about the only editor of this template that still seems to be active. What do you think? --Dweller (talk) Become old fashioned! 14:05, 10 October 2018 (UTC)
I've changed "['expiry-date-format'] = 'F j, Y'," to "['expiry-date-format'] = 'F j, Y "at" g:i a e'," in the sandbox which makes it always show something like "October 13, 2018 at 6:56 am UTC" instead of "October 13, 2018".
Showing the precise time if one is on that date seems interesting enough. Doable, though because of issues of pages not being updated instantly it may not always show up.. Galobtter (pingó mió) 14:26, 10 October 2018 (UTC)
Thanks. I think (I'm not very technical) that's exactly what I was looking for. Is that change live now, or just in sandbox for testing? --Dweller (talk) Become old fashioned! 15:24, 10 October 2018 (UTC)

Anyone? --Dweller (talk) Become old fashioned! 15:35, 15 October 2018 (UTC)

Well, this talk page isn't really watched much. Maybe try one of the pumps - at-least I'd like a bit more discussion before changing the module Galobtter (pingó mió) 15:59, 15 October 2018 (UTC)
@Dweller and Galobtter: I've gone ahead and made this change — it seems reasonable enough. As far as I can tell, most everything parses the log itself, so unless I've missed something relying on this hopefully nothing will break. It seems Mr. Stradivarius chose the format to match what {{pp-meta}} used, which is what he was deprecating in creating this. ~ Amory (u • t • c) 16:06, 31 October 2018 (UTC)
That's terrific, thank you. --Dweller (talk) Become old fashioned! 16:08, 31 October 2018 (UTC)

Template protected edit request 12/11

Hello,

Per this RfC, please change the following:

Current Change
Padlock.svg Full-protection-shackle.svg
Padlock-pink.svg Template-protection-shackle.svg
Padlock-silver.svg Semi-protection-shackle.svg
Padlock-skyblue.svg Create-protection-shackle.svg
Padlock-olive.svg Move-protection-shackle.svg
Padlock-purple.svg Upload-protection-shackle.svg
Padlock-silver-light.svg Pending-protection-shackle.svg
Padlock-blue.svg Extended-protection-shackle.svg
Padlock-black.svg Office-protection-shackle.svg
Padlock-turquoise.svg Cascade-protection-shackle.svg

Many thanks, ProgrammingGeek talktome 01:49, 13 November 2018 (UTC)

 Done I'm updating it now ∰Bellezzasolo✡ Discuss 02:08, 13 November 2018 (UTC)

Time format

Regarding ['expiry-date-format'] = 'F j, Y "at" g:i e', this ends up producing an output that isn't really valid such as "December 13, 2018 at 6:28 am UTC" , where UTC is not supposed to have AM/PM designation. Brought up at Special:PermaLink/873423420#Currently_disabled:_two_issues at WP:VPT. Didn't want to just change it - does anyone have the background on this? — xaosflux Talk 03:40, 13 December 2018 (UTC)

This was changed just above after a request for finer detail. Totally on me — I missed the am/pm. I'll just go ahead and make the change to F j, Y "at" G:i e to produce April 26, 2024 at 10:38 UTC ~ Amory (u • t • c) 11:56, 13 December 2018 (UTC)

Template-protected edit request on 30 October 2019

Please apply this diff on Module:Protection banner/config. The template pp-30-500 was recently moved to Template:Pp-extended and the "small" parameter is no longer going through, meaning that all articles have a huge banner: Fatah, Kuttichathan. – Thjarkur (talk) 13:12, 30 October 2019 (UTC)

 Done --Trialpears (talk) 13:35, 30 October 2019 (UTC)

Miscategorization

Bringing to the attention of concerned editors something that is, for me, a very gnarly challenge that appears to have something to do with this module and likely Module:Protection banner/config. It has to do with the {{Redirect category shell}} (Rcat shell) and its ability to sense protection levels. The original code is found in a previous 2016 discussion above on this page and is reproduced here because there have been some changes: 

<!--
  Automatically detect protected redirects:
--><includeonly>{{#switch: {{PROTECTIONLEVEL:move}}
   |sysop|templateeditor|extendedconfirmed={{pp-move|small=yes}}
 }}{{#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}}
   | <!--Not protected, or only semi-move-protected-->
 }}</includeonly>

Problemo

The challenge arises when a page 1) transcludes the Rcat shell template, 2) is template-protected, and 3) is not fully move-protected. Such pages, usually template redirects, are miscategorized to Category:Wikipedia fully protected pages.

Examples

First, here is a redirect that is both template- and fully move-protected. It is correctly categorized.

Here is a redirect that is template-protected, but not fully move-protected. Here is another. Many examples can be found in the Wikipedia fully protected pages category.

Also found there are at least two non-redirect pages, {{NASTRO comment}} and {{Redirect template}}, that are miscategorized the same way. They both have the Rcat shell either in their code or their documentation.

To summarize, both {{Pp-protected}}, which redirects to {{Pp}}, and {{Pp-move}} use this module. I'm almost bald I've been pulling my hair out so much over this. Pinging Martin, Redrose64 and Anomie⚔ from this conversation. Also pinging wbm1058 and Mr. Stradivarius from the above 2016 discussion. Hopefully, one or more of you will be able to help me with this bit of a wee challenge? P. I. Ellsworth, ed. put'r there 03:15, 5 November 2019 (UTC)

@Paine Ellsworth: I checked your examples, and while they are wrongly categorized your description seems wrong. Those pages are both template-protected for 'edit' and template-protected for 'move', not unprotected for move. — xaosflux Talk 03:28, 5 November 2019 (UTC)
To xaosflux: sorry, you're correct. Meant to say they are not "fully move-protected". When there is full move protection, categorization works correctly. When the page is not fully move-protected, that is when the miscategorization happens. P. I. Ellsworth, ed. put'r there 03:35, 5 November 2019 (UTC)
I've clarified my text above. P. I. Ellsworth, ed. put'r there 03:55, 5 November 2019 (UTC)

From the lack of response to this challenge, I would guess that this is either a low priority? or not possible to fix? both? neither? PI Ellsworth  ed. put'r there 17:59, 16 December 2019 (UTC)

Categorisation error?

 – per Redrose64 the underlying code of {{pp-move}} that is wrong, which is Module:Protection banner so I've moved the discussion here. —⁠andrybak (talk) 21:51, 27 February 2020 (UTC)

The redirect Template:Doc is in Category:Wikipedia fully protected pages but it is only template-protected. Is this a known issue? — Martin (MSGJ · talk) 13:07, 27 February 2020 (UTC)

To be exact, it's in Category:Wikipedia fully protected pages, Category:Wikipedia template-protected templates, Category:Template-protected redirects, and Category:Redirects from template shortcuts. The first three are emitted by {{pp-move|small=yes}}{{pp-protected|small=yes}}{{R template protected|embed=yes}} respectively, these being in the code for Template:Redirect category shell. If anything, it's the underlying code of {{pp-move}} that is wrong. --Redrose64 🌹 (talk) 19:39, 27 February 2020 (UTC)
@Redrose64 and MSGJ: I've fixed up the testcases for /config subpage. And added a test, which I hope covers the issue we're facing here. I'm very much a Lua beginner and I don't have enough bandwidth to dig deeper. The only thing that I've come up with is that protectionLevels table does not cover the templateeditor-move protection. —⁠andrybak (talk) 21:57, 27 February 2020 (UTC)
I've just realized, that Paine Ellsworth has already reported the issue two months ago just two sections above. @Mr. Stradivarius, Jackmcbarn, and Cenarium: pinging the three authors of this module. —⁠andrybak (talk) 22:37, 27 February 2020 (UTC)
Thank you, ⁠andrybak! This looks like an issue that's not going away until it's fixed. PI Ellsworth  ed. put'r there 23:28, 27 February 2020 (UTC)

I'm going to have time to sort this today but the fault seems to be in the Protection categories table (lines 643 onwards). On line 779 there is defined Category:Wikipedia move-protected templates but it doesn't catch it because the page is not fully-move-protected. The catch all category ('all|all|all|all|all') is used if there is no match to any other case, and that is set to use Category:Wikipedia fully protected pages. I think it would be better if the "fully" was taken out of that. — Martin (MSGJ · talk) 08:47, 28 February 2020 (UTC)

I think the question is: do we want a specific category for template-move-protected templates? If not, then what category do we want these templates in? — Martin (MSGJ · talk) 08:49, 28 February 2020 (UTC)
MSGJ, I would suggest Category:Wikipedia move-protected templates. —⁠andrybak (talk) 09:33, 28 February 2020 (UTC)
Okay, so that would contain templates if they are fully-move-protected and also template-move-protected. What about extended-move-protected templates? (I think a few of these exist.) Also this would not solve the problem of pages in other namespaces (e.g. see User:MSGJ/Sandbox/1) being wrongly categorised. — Martin (MSGJ · talk) 11:23, 28 February 2020 (UTC)
MSGJ, do we want to create a separate category tree of "Wikipedia {fully,templateeditor,extended-confirmed} move protected pages"? Side note: would we want to add the word "edit" to the existing category tree where needed? At the moment, in Category:Wikipedia protected pages, there are separate single categories for move, pending changes, and file upload protections. Having a Category:Wikipedia edit protected pages might help just to keep things more organized. —⁠andrybak (talk) 15:24, 28 February 2020 (UTC)
@MSGJ: That agrees with my analysis from Template talk:Citation needed/Archive 14#Fully protected edit request on 13 May 2019. There are a few different ways things could be fixed. I personally have no opinion on which method is chosen, which is why I didn't change anything back then. Anomie⚔ 12:41, 28 February 2020 (UTC)

Template-protected edit request on 9 February 2020

If you place the template {{pp-blp}}, the mouseover text will show "[...] biographies of living people" instead of "[...] biographies of living persons", simply because the policy is called "WP:Biographies of living persons", and not "WP:Biographies of living people". Keyacom (💬 | 🖊) 07:54, 9 February 2020 (UTC)

 Done DannyS712 (talk) 10:06, 9 February 2020 (UTC)
Retrieved from "https://en.wikipedia.org/w/index.php?title=Module_talk:Protection_banner/Archive_1&oldid=1087656681"