Template:Pp is permanently protected from editing because it is a heavily used or highly visible template. Substantial changes should first be proposed and discussed here on this page. If the proposal is uncontroversial or has been discussed and is supported by consensus, editors may use {{ edit template-protected}} to notify an administrator or template editor to make the requested edit. Usually, any contributor may edit the template's documentation to add usage notes or categories. Any contributor may edit the template's sandbox. Functionality of the template can be checked using test cases.

What does the "pp" stand for? _└ ^Jared_┘^┌ _talk^┐  00:29, 2 April 2007 (UTC) reply

protected page _{→ Aza Toth} 02:11, 2 April 2007 (UTC) reply

"This page is currently protected from editing because lorem ipsum dolor sit amet." What the hell?! What does "lorem ipsum dolor sit amet" mean?! -- Reaper X 03:31, 6 July 2007 (UTC) reply

I know it's a bit of a late reply, but... → Lorem ipsum. — madman bum and angel 16:51, 6 August 2007 (UTC) reply

The Wikipedia:Article message boxes project has now changed and standardised the styles for most of the message boxes that goes on article pages. We are now planning to change the protection templates to have a matching look when on article pages. But they will keep their old look when they appear anywhere else.

Here is an example of the new look. (Note: Exact colour for the left-side colour bar is not yet decided, and we will of course have the old full text in them, this is just a short example.)

Editing of this page by unregistered or newly registered users is currently disabled.

Any input is welcome, see discussion and more examples at Wikipedia talk:Article message boxes#Protection Templates and Wikipedia talk:Article message boxes#Next steps.

-- David Göthberg 02:18, 21 September 2007 (UTC) reply

I have created a /doc subpage for this template to separate the docs from the template code to make further editing easier. I have used the old method (that had consensus) described at Wikipedia:Template documentation before that page got heavily reworked yesterday.

I have chosen to start out with this protection template since it is not used on as many pages as the other protection templates. So if we screw up we don't cause so much damage. I have tested the changes I suggest here in my own sandbox in my own user space.

{{ editprotected}}

To make the /doc page work the following changes needs to be done to this template:

1. Remove the noinclude with the pp-template from the first line of code. It is added in the end instead, see below. Make the first line look like this:

{{#ifeq:{{{small|}}}{{{expiry|ʁ}}}|yesʁ

2. Remove the documentation from the template and make the lines from the end table tag to the end of the page look like this:

</table>
}}<includeonly>[[Category:Protected|{{PAGENAME}}]]{{
#ifexpr:
  {{#if:{{{expiry|}}}
    | {{#time:U|today}}>{{#time:U|{{{expiry}}}}} 
    | 0 
  }}
| [[Category:Protected pages with expiry expired|{{PAGENAME}}]]
}}</includeonly><noinclude>

{{pp-template|small=yes}}
{{template doc}}
<!-- Add categories and inter-wikis to the /doc subpage, not here! -->
</noinclude>

That's all.

-- David Göthberg 14:15, 27 September 2007 (UTC) reply

done. — Carl ( CBM ·  talk) 14:36, 27 September 2007 (UTC) reply

Currently points to Wikipedia: Protection policy, I would like to suggest Wikipedia:This page is protected. — Random832 18:02, 17 December 2007 (UTC) reply

How about changing the image for the new images for Accessibility. ~~Awsome EBE123 ^talk _Contribs 19:02, 17 March 2011 (UTC) reply

Edit request from Ebe123, 24 March 2011

{{ edit protected}} Changing the images to the current version for Wikipedia:Accessability

~~Awesome EBE123 ^talk _Contribs 20:19, 24 March 2011 (UTC) reply

You're going to have to explain what you mean, and then get a consensus for change. Regards — Martin ( MSGJ ·  talk) 08:25, 25 March 2011 (UTC) reply

{{editprotected}} Go to Wikipedia:Village pump (proposals)#WP:Accessability ~~ EBE123~~ ^talk _Contribs 22:53, 25 March 2011 (UTC) reply

 Not done Come back when you have consensus... — GFOLEY FOUR— 05:34, 26 March 2011 (UTC) reply

I saw a sample of the use of this template and it said "because" followed by the reason, while "because of" would be correct grammar in the sample used. Vchimpanzee · talk · contributions · 22:34, 21 February 2012 (UTC) reply

This edit request has been answered. Set the |answered= or |ans= parameter to no to reactivate your request.

Change:

|small={{{small|}}}
|demospace={{{demospace|}}}

To:

|small={{{small|}}}
|right={{{right|}}}
|demospace={{{demospace|}}}

This allows use of the new pp-meta parameter. Jackmcbarn ( talk) 19:40, 25 August 2013 (UTC) reply

Done -- Redrose64 ( talk) 21:42, 25 August 2013 (UTC) reply

This edit request to Template:Pp-protected has been answered. Set the |answered= or |ans= parameter to no to reactivate your request.

Malaysia Airlines Flight 370 - This page may be vandalised, which is not a good thing as it may be offensive. It will be good if it is semi-protected. Nahnah4 | Any thoughts? Pen 'em down here! | No Editcountitis! 09:16, 10 June 2014 (UTC) reply

Please ask at WP:RFPP. — Martin ( MSGJ ·  talk) 09:22, 10 June 2014 (UTC) reply

There is currently a proposal to convert this and other protection templates to Lua at Module talk:Protection banner#Proposal to convert all protection templates to use this module. Please join this discussion over there if you are interested. — Mr. Stradivarius ^{♪ talk ♪} 23:47, 22 July 2014 (UTC) reply

FYI: https://www.mediawiki.org/wiki/Help:Page_status_indicators ed g2s • talk 23:15, 7 November 2014 (UTC) reply

I know. They're not stable yet, but once they are, I'll work on converting to use them. Jackmcbarn ( talk) 23:22, 7 November 2014 (UTC) reply

Thanks. 2.27.191.227 ( talk) 10:59, 8 November 2014 (UTC) reply

I'm trying to produce a red padlock on a page such as Wikipedia:Content disclaimer (which seems to fit as "permanent full protection"). What parameters are needed to do this? Thanks — Martin ( MSGJ ·  talk) 10:31, 17 December 2015 (UTC) reply

This is the test:

                        (
			namespace == 10
			or namespace == 828
			or reason and obj._cfg.indefImageReasons[reason]
			)
			and action == 'edit'
			and level == 'sysop'
			and not protectionObj:isTemporary()

The first two check for templates and modules, which Wikipedia:Content disclaimer isn't, so it needs to satisfy the third, which is kinda obscure. I've decided that it's somehow set by Module:Protection banner/config, which only mentions indefImageReasons once, and it helps not at all. Anyway, is a red lock important? I managed to display a gold one. -- Redrose64 ( talk) 13:10, 17 December 2015 (UTC) reply

indefImageReasons is obviously about protection of images so probably not relevant to Wikipedia:Content disclaimer. I'm not sure of the exact difference between the gold lock and the red lock. Do we even need to distinguish between them? According to the protection policy, WP:REDLOCK is for pages that should not be modified for copyright or legal reasons which this page seems to fall under. — Martin ( MSGJ ·  talk) 17:15, 17 December 2015 (UTC) reply

I don't think that indefImageReasons is about protection of images; I think that it's to do with the padlock image to be displayed. If you look at the very bottom of Module:Protection banner/config, you'll see code that sets two image filenames, one of these is ['image-filename-indef'] = 'Padlock-red.svg', - if you search for image-filename-indef in the same page, there is code like this:

-- Pages with a reason specified in this table will show the special "indef"
-- padlock, defined in the 'image-filename-indef' message, if no expiry is set.
indefImageReasons = {
	template = true
},

so indefImageReasons has something to do with it. -- Redrose64 ( talk) 19:01, 17 December 2015 (UTC) reply

Mr. Stradivarius, Jackmcbarn: can we get some advice on this please? — Martin ( MSGJ ·  talk) 09:02, 18 December 2015 (UTC) reply

I think the red lock is kind of pointless and poorly specified as it exists now. Perhaps we should completely replace it with the gold one. Jackmcbarn ( talk) 17:07, 18 December 2015 (UTC) reply

That sounds like a reasonable idea. I'll open a thread at Wikipedia talk:Protection policy — Martin ( MSGJ ·  talk) 19:18, 20 December 2015 (UTC) reply

Keep the red for "permanently" protected pages and use gold for indef-but-not-permanently-protected pages. Now, what do we do about pages that are "indef-protected" but which are not "permanently" protected? My recommendation: If you see a an indef-protected page that isn't "forever" change the protection to expire "a long time from now (such as 2099-12-31)" and slap a gold lock on it. If you see an indef-protected page that IS "forever, at least as far as the eye can see" slap a red lock on it and put a note in the edit summary explaining why (or un- and re-protect the page and put the note in the protection log). davidwr/( talk)/( contribs) 21:54, 20 December 2015 (UTC) reply

But what exactly is the difference? At the moment, a "permanently protected" page seems to be defined as one that has full edit protection and is either a template or a module. There are also two somewhat-obscure rules, the lines reason and obj._cfg.indefImageReasons[reason] and not protectionObj:isTemporary() in the test above, which neither Mr. Stradivarius ( talk · contribs) nor Jackmcbarn ( talk · contribs) (they being the people who made all but four edits to Module:Protection banner) seem willing to explain properly. Those two rules aside, why is an indef-full-protected template described as "permanently" protected, whereas a page in another namespace, which should rarely (or never) be altered because of legal implications (such as Wikipedia:Content disclaimer, Wikipedia:Copyrights or Wikipedia:Text of Creative Commons Attribution-ShareAlike 3.0 Unported License) apparently is not permanently protected? -- Redrose64 ( talk) 23:34, 20 December 2015 (UTC) reply

The definition of permanent protection can be found at Wikipedia:Protection policy#Permanent protection. If the definition needs to be changed or the "vague" areas clarified (what exactly does "frequently" transcluded mean?), we can discuss it at its talk page. The padlock templates and their use should reflect what's on the policy page. davidwr/( talk)/( contribs) 23:46, 20 December 2015 (UTC) reply

@ Redrose64: Module:Protection banner only does red locks the way it does because that's what the previous non-module system did. It really wasn't our decision at all. Jackmcbarn ( talk) 23:59, 20 December 2015 (UTC) reply

But why won't you explain exactly what those two lines actually do? -- Redrose64 ( talk) 08:28, 21 December 2015 (UTC) reply

reason and obj._cfg.indefImageReasons[reason] specifies that there is a reason and that that reason is present in the indefImageReasons config table. That table only contains a key of "template", so the code effectively checks whether reason is equal to "template". (The reason and part is only necessary because if the reason variable does not have a value set, trying to look it up in the table will cause an error.) not protectionObj:isTemporary() negates the result of Protection:isTemporary(), which in turn checks whether protectionObj.expiry has a numerical value. The code that sets the expiry is fairly complex. Here is the code block:

	-- Set expiry
	local effectiveExpiry = effectiveProtectionExpiry(obj.action, obj.title)
	if effectiveExpiry == 'infinity' then
		obj.expiry = 'indef'
	elseif effectiveExpiry ~= 'unknown' then
		obj.expiry = validateDate(effectiveExpiry, 'expiry date')
	elseif args.expiry then
		if cfg.indefStringsargs.expiry then
			obj.expiry = 'indef'
		elseif type(args.expiry) == 'number' then
			obj.expiry = args.expiry
		else
			obj.expiry = validateDate(args.expiry, 'expiry date')
		end
	end

The reason for the complexity is that we use {{PROTECTIONEXPIRY}}, which has recently been enabled on this wiki, and to make it easier to use from Lua, Cenarium has created Module:Effective protection expiry. Effectively, if {{PROTECTIONEXPIRY}} returns "infinity", then protectionObj.expiry is set to "indef". If it's a date, then protectionObj.expiry is set to that date as a number in Unix time. If the expiry is unknown - which at the moment means that the page is unprotected or under pending changes protection - then |expiry= is checked, and if it's a value similar to "indef" then protectionObj.expiry is set to "indef", and if it's a date, then protectionObj.expiry is set to that date as a number in Unix time. If the expiry is unknown and there is no |expiry= parameter, then protectionObj.expiry will be nil. So essentially, not protectionObj:isTemporary() checks whether we were not able to find an expiry date, either from {{PROTECTIONEXPIRY}} or from |expiry=. — Mr. Stradivarius ^{♪ talk ♪} 11:03, 21 December 2015 (UTC) reply

The distinction between indef and permanent is too vague and will be lost on most people (myself included). I really see no advantage in distinguishing between the two. The fantastically weird hacks with the expiry dates suggested by davidwr will overcomplicate things for no benefit. — Martin ( MSGJ ·  talk) 09:09, 21 December 2015 (UTC) reply

You make some valid points, but any discussion to treat "permanently protected" pages differently than they are now (e.g. changing the padlock color from red to gold) needs to happen at Wikipedia talk:Protection policy. davidwr/( talk)/( contribs) 14:54, 21 December 2015 (UTC) reply

That's why I attempted to initiate a discussion on Wikipedia talk:Protection policy a few days ago but you turned up here instead ;) — Martin ( MSGJ ·  talk) 09:52, 22 December 2015 (UTC) reply

Just to follow up on this, the red padlock is now history. — Martin ( MSGJ ·  talk) 09:49, 15 January 2016 (UTC) reply

Is there any banner to indicate that a file has upload protection, e.g. |action=upload? — Martin ( MSGJ ·  talk) 09:50, 15 January 2016 (UTC) reply

Not at the moment, at least as far as banners that use Module:Protection banner. In theory it shouldn't be too hard to add support for action=upload to the module, but it would require a few coding changes. For example, at the moment, the Protection.supportedActions table in the module only contains "edit", "move", and "autoreview". I'm pretty sure all of the padlock templates around on Wikipedia use the module, although there might be other non-padlock templates that check for upload protection. — Mr. Stradivarius ^{♪ talk ♪} 10:25, 15 January 2016 (UTC) reply

I'm not aware of any templates for upload protection either. I've just checked and PROTECTIONLEVEL does recognise upload as an action, so it should be possible to detect automatically. — Martin ( MSGJ ·  talk) 10:51, 15 January 2016 (UTC) reply

Yes, it's available in Scribunto's title.protectionLevels as well, so that part wouldn't be a problem. Do you know if there are any other requests for this, by the way? It strikes me that we should probably find out whether people want it before working out how to implement it. — Mr. Stradivarius ^{♪ talk ♪} 12:25, 15 January 2016 (UTC) reply

I am not aware of any other requests for this functionality. I just came across an image with the wrong template, and I couldn't find any suitable to replace it with. It might be interesting to find out how many images are upload-protected but not edit-protected, to see if the distinction is likely to be useful or not. — Martin ( MSGJ ·  talk) 13:29, 15 January 2016 (UTC) reply

I've just had a look and the purple padlock only seems to be generated by one template: {{ protected generic image name}}, and this template has no automatic detection code. — Martin ( MSGJ ·  talk) 13:34, 15 January 2016 (UTC) reply

@ Mr. Stradivarius: How about this purple padlock option? I've just upload-protected File:Suffolk University.jpg and I would like to indicate this somehow on the file page. Cheers — Martin ( MSGJ ·  talk) 20:00, 2 March 2016 (UTC) reply

@ MSGJ: Any preferences for a template name? I'm thinking Template:Pp-upload would probably be a sensible choice. Also, should the template be small by default, or should it be a banner unless you add |small=yes? — Mr. Stradivarius ^{♪ talk ♪} 01:44, 3 March 2016 (UTC) reply

Ok, I've gone ahead and added the code to the module sandbox. You can test it by previewing {{ pp-upload}} on upload-protected files. Feel free to tweak the banner wording - you can find the bolded text at line 417 of the config sandbox, and the body at line 520. Also, I chose to call the category Category:Wikipedia upload-protected files, but we can use a different name if you would prefer. And it's not small by default, but that can be changed as well. — Mr. Stradivarius ^{♪ talk ♪} 06:33, 3 March 2016 (UTC) reply

Thank you. I have tested it on File:Suffolk University.jpg and it seems to be working well. I suggest keeping it large by default. — Martin ( MSGJ ·  talk) 09:14, 3 March 2016 (UTC) reply

I've now added upload support to the main module, and switched over {{ pp-upload}} to use it. — Mr. Stradivarius ^{♪ talk ♪} 13:23, 3 March 2016 (UTC) reply

Great, thank you. Can Template:Pp-generic-image be incorporated at all? — Martin ( MSGJ ·  talk) 13:56, 3 March 2016 (UTC) reply

Template:Keep local high-risk is another one. It would be good if these could be incorporated so they automatically detect the type of protection (upload or edit) — Martin ( MSGJ ·  talk) 09:44, 4 March 2016 (UTC) reply

@ Mr. Stradivarius: can you clarify whether these other templates can be incorporated into the module so that they can auto-detect protection level? — Martin ( MSGJ ·  talk) 09:22, 9 March 2016 (UTC) reply

@ MSGJ: Sorry for the late reply. Yes, they can be incorporated - it is "just" a matter of updating the config module. You need to add entries for the templates in the "wrappers" table, giving them a suitable first positional parameter (the protection reason). Then you need to add an entry for that reason to the "upload" subtable of the "banners" table. Then you need to create the template page with {{#invoke:protection banner|main}}. That should be all that's necessary. Actually, try it with the config sandbox first (so the template code would be {{#invoke:protection banner/sandbox|main}}). Then you'll be able to see how things work without worrying about messing up the live templates. I'll set up the main module sandbox to point to the config sandbox instead of the main config so that it will work. — Mr. Stradivarius ^{♪ talk ♪} 12:07, 9 March 2016 (UTC) reply

This template populates Category:Protected images. I'm just wondering if it should be called Category:Wikipedia protected files as I assume non-image files would also go into this category. Also the "Wikipedia" should probably be added for consistency — Martin ( MSGJ ·  talk) 09:45, 4 March 2016 (UTC) reply

Listed at CfD, please see Wikipedia:Categories for discussion/Log/2016 March 9 — Martin ( MSGJ ·  talk) 09:21, 9 March 2016 (UTC) reply

Could one of our Lua magicians add a padlock for the new WP:EXTENDEDCONFIRMED protection? We'll want to use the blue padlock as seen on the right.

Our other padlocks link to whichever section in WP:PROTECT, but this form of protection as I understand is only to be used on pages under discretionary sanctions? If so I think we should link to Wikipedia:Arbitration Committee/Discretionary sanctions ( WP:30/500 will do). We'll also want to add the categories Category:Wikipedia pages under discretionary sanctions and I guess Category:Wikipedia pages under 30-500 editing restriction. Pinging recent contributors @ MSGJ, Mr. Stradivarius, and Jackmcbarn — MusikAnimal ^talk 04:31, 6 April 2016 (UTC) reply

I guess this might require a little discussion. Just figured we could add something, since we already have a handful of pages under this protection, enforced by Special:AbuseFilter/698. The padlock used on those pages is {{ pp-30-500}}, which I suppose we'll want to rewrite to use this module, just as we do with {{ pp-blp}}, etc. — MusikAnimal ^talk 04:34, 6 April 2016 (UTC) reply

We'll need to add a reason to the module as well. And shouldn't the edit filter be disabled since we already have flags for that purpose. Also, should we add the template to the TW module? -- QEDK ( T ☕ C) 06:12, 6 April 2016 (UTC) reply

The reason should be along the lines of "discretionary sanctions", if that's what you mean. And yeah, I've got a lot of Twinkle work to do! The filter will be disabled once we get everything else ironed out. I'm not sure the new user group has even finished populating to all qualified users — MusikAnimal ^talk 14:56, 6 April 2016 (UTC) reply

This module contains calls to the protected edit request templates/modules, so we should probably get those updated before this. I'll start on that now. Jackmcbarn ( talk) 17:07, 6 April 2016 (UTC) reply

Okay, everywhere else should be done now. Jackmcbarn ( talk) 19:10, 6 April 2016 (UTC) reply

Is the Lua module not updated yet, or did no one change {{ Pp-30-500}} to have {{#invoke:Protection banner|main}}? Datbubblegumdoe ^{talk – contribs} 22:38, 15 April 2016 (UTC) reply

For the record, the 30-500 category was renamed to Category:Wikipedia extended-confirmed-protected pages. – Fayenatic London 19:42, 14 October 2019 (UTC) reply

In case of pages with 2 kinds of protection, why don't both show up? Also, why did the padlock change in this case. -- QEDK ( T ☕ C) 05:04, 1 May 2016 (UTC) reply

Moved to VPT. -- QEDK ( T ☕ C) 19:03, 3 May 2016 (UTC) reply

Hello, I have a new suggestion for a reason proposal. I have been loooking for a bit, and I figured that a disruptive editing reason should be added (because the two main causes of semi-protection is either vandalism or disruptive editing. It would be great for this to be added, as there are a high amount of articles being protected from disruptive editing (I'm not too sure if vandalism and disruptive editing mean the same thing, or if they both have the same point). If you could consider the option for disruptive editing as a reason for this heavy used template, that would be great. Thank you, and have a good day. -- Redolta (talk) 01:58, 8 June 2016 (UTC) reply

@ Redolta: See WP:DE and WP:VAND. Vandalism is a special case of disruptive editing: the difference is basically one of intent. But this is the wrong page to discuss extension of reasons for protection: the {{ pp}} template merely reflects the current protection of a page which was protected in accordance with WP:PROT, so, a far better place to discuss changing the policy would be WT:PROT or even WP:VPP. -- Redrose64 ( talk) 10:22, 8 June 2016 (UTC) reply

Ok, thank you for the explanation. I now understand. Redolta (talk) 13:47, 8 June 2016 (UTC) reply

I always find it strange that the default on these protection templates is to have a big banner. In fact literally 4541 out of the 4542 instances of transclusion of {{ pp}} had small = yes/y ( [1])The one instance where it was used, I boldly changed as I was quite sure that wasn't the intention of the protecting admin. Instead of having |small=yes, I'm proposing to have |banner=yes and the default to be a padlock. Galobtter ( pingó mió) 10:22, 16 March 2018 (UTC) reply

...or does the presence of this template still on an article *after* semi-protection has expired mean it can't be edited by an unregistered user? I had a look at Fabinho (footballer, born 1993) on my mobile phone, on which I never sign into my account, and noticed the edit icon on the top right still contained the padlock. After removing it (while logged in from my computer) as the protection expired hours ago, I'm now able to edit the article from my phone as an unregistered user. And, as if by magic, an unregistered user made an unsourced edit to the article minutes after I removed the icon. And no, it wasn't me! If anyone wants to test this on their phone, try 2018 FIA Formula 3 European Championship, which also has had its protection expire, has the template and won't allow mobile editing. Any help/clarification would be appreciated. Thanks, Mattythewhite ( talk) 03:19, 31 May 2018 (UTC) reply

Actually, it could be that my IP address has been caught up in a range block... Mattythewhite ( talk) 03:23, 31 May 2018 (UTC) reply

@ Mattythewhite: The protection notice/icon templates such as {{ pp}} are just that, notices and icons. Their presence or absence has no effect whatsoever on the actual protection level of a page. The only other purpose of these template is categorisation: when used on a protected page, that page might be categorised in Category:Wikipedia semi-protected pages (or similar); but when used on a non-protected page, it will be placed in Category:Wikipedia pages with incorrect protection templates. If a protection expires, but the icon is still displayed, the most likely cause is caching. There are one or two bots that look for pp templates that are used on unprotected pages, and remove them; these bots are not infallible, and pages that are missed are usually picked up by myself or MarnetteD ( talk · contribs) within a few days. -- Redrose64 🌹 ( talk) 22:59, 31 May 2018 (UTC) reply

@ Mattythewhite: the one thing I would add to Redrose64's post is that the removal of a padlock by a bot or either one of us can be delayed by quite some time. I have seen articles that didn't show up in Category:Wikipedia pages with incorrect protection templates until days, weeks or months after a protection had expired. I just noticed this thread Wikipedia:Village pump (technical)#Change coming to MonoBook skin for mobile users I don't know if it is related to what you experienced but I thought I would make you aware of it just in case. MarnetteD| Talk 14:17, 1 June 2018 (UTC) reply

I don't think it's the same issue, the icons mentioned at that VPT thread are the ones that replace tabs such as "Talk", "Edit", "History" and so on. I also don't think it's the same issue as Wikipedia:Village pump (technical)/Archive 162#MediaWiki bug - undoing a protection although there are similarities. I think that caching is the most likely. -- Redrose64 🌹 ( talk) 21:37, 1 June 2018 (UTC) reply

Thanks for the followup info Redrose64. Cheers. MarnetteD| Talk 22:53, 1 June 2018 (UTC) reply

This edit request has been answered. Set the |answered= or |ans= parameter to no to reactivate your request.

You may also request that this page be unprotected. ----> You may also request that this page to be unprotected. ___ CAPTAIN MEDUSA talk 22:16, 26 February 2019 (UTC) reply

 Not done: It's correct as it stands. Your proposal is bad grammar. -- Redrose64 🌹 ( talk) 22:20, 26 February 2019 (UTC) reply

( edit conflict) - what Redrose64 said - but with a pointer to the subjunctive. Cabayi ( talk) 22:25, 26 February 2019 (UTC) reply

It seems like something that should exist, but if it does, it may have stopped working; I noticed that Help:Introduction to policies and guidelines/2, which has been protected since 2018, is missing it. Pinging Redrose64, since you seem to be active with this sort of thing. Cheers, {{u| Sdkb}}  ^talk 21:53, 19 May 2020 (UTC) reply

Protection templates are optional, not mandatory. They are merely informative, and the prot is just as effective with or without the icon. -- Redrose64 🌹 ( talk) 23:06, 19 May 2020 (UTC) reply

@ Redrose64: Interesting; I didn't know it was optional. But since it's so unobtrusive, I'd think we'd ideally want it on all protected pages. I'll start a BOTREQ and see where the discussion goes. {{u| Sdkb}}  ^talk 09:36, 21 May 2020 (UTC) reply

Several protected talk pages have a subpage for users who can't edit due to the protection. See e.g. WT:About or User talk:Jimbo wales. In those instances, we should be able to use this template (as at e.g. WT:Contents, where there's no subpage). Could we add a parameter that'd allow specification of the subpage? {{u| Sdkb}}  ^talk 23:17, 23 September 2020 (UTC) reply

There seems to be a trailing space after the tag in this template, which inserts a space wherever this is included. Where the page is a partial markup template (for instance Template:F1R2020) this space can break the behaviour of the template. Is there a reason not to remove this space or bring it inside the noinclude tags? Otherwise you have to have a second set of noinclude tags around the template at point of inclusion where this is an issue. Bigbluefish ( talk) 14:44, 10 December 2020 (UTC) reply

{{ pp}} is being misused - it is redundant because {{ documentation}} handles any prot icon that may be appropriate. -- Redrose64 🌹 ( talk) 23:11, 10 December 2020 (UTC) reply

For semi-protected article talk pages, I propose changing If you cannot edit this page and you wish to make a change, you can request unprotection, log in, or create an account. to the following: If you cannot edit this page and you wish to make a change, you can log in, create an account, or request unprotection. I do not think that "request unprotection" should be the first thing suggested to new users, because if a talk page is semi protected, it is likely for a good reason. Example (look at all these reverts that triggered the page protection). Thoughts? – Novem Linguae ( talk) 06:06, 1 March 2022 (UTC) reply

If you need to create an account, you still can't edit a semi-prot talk page until you're confirmed. -- Redrose64 🌹 ( talk) 13:45, 1 March 2022 (UTC) reply

Hey! I've been clearing up a protection related category for a while now, and during that, I've noticed that quite a lot of uses of the {{ pp}} template (or similar) include a |reason= parameter (like here). However, based off of what I've seen at Special:ExpandTemplates and in the module code, this parameter has absolutely no effect on the output. Why is it being used? Protection reasons are provided by the protection log so I wouldn't think that is why, and even if it was, most editors would not notice the text. Aidan9382 _{( talk)} 12:36, 21 June 2022 (UTC) reply

Looking at the code, it appears to do two things. 1) If |small=yes is not specified, it adds a "due to vandalism" etc. to the displayed banner. 2) It places the page in a hidden category such as Category:Wikipedia pages semi-protected against vandalism instead of a more generic category. Please note that you can't just put any reason, you need to use the language codes specified in the documentation, e.g. Template:Pp#Reasons – Novem Linguae ( talk) 12:54, 21 June 2022 (UTC) reply

@ Novem Linguae: Thing is - I tried doing stuff like {{ pp|reason=blp}}, but it would just display the default message. Only something like {{ pp|blp}} or {{ pp-blp}} would work. Thats why I'm confused over the use of |reason= - It's not that its being used wrong, its that as, as far as my testing went, it has 0 functionallity in any use. Aidan9382 _{( talk)} 12:56, 21 June 2022 (UTC) reply

Ah, you're right. I assumed that reason= and 1= were the same, but looks like it only likes 1=. Anyway, can you provide some diffs of reason=? I am curious if an automated tool such as Twinkle is adding them, if so we can work on a patch so the tool stops using reason=. – Novem Linguae ( talk) 13:25, 21 June 2022 (UTC) reply

Sure, no problem. Give me some time, I'll go through my previous removals of it and see if theres a pattern. Aidan9382 _{( talk)} 13:32, 21 June 2022 (UTC) reply

@ Novem Linguae: Oh wow. After taking a look at all my edits related to protection, it seems the majority of the cases were |reason= was used were by Deepfriedokra, who I'll ping so they can take a read of this. (If you want to check yourself, just see any triple-digit diff on this contribution search). However, all of those edits were also marked with the Twinkle tag, and after looking further, I've seen a different admin doing the same thing with twinkle, so it may be worth looking into. I've literally never used twinkle so I have no clue how the process works through it, so whether the root cause of the issue is human error or the tool providing it as an option is completely beyond me. Aidan9382 _{( talk)} 13:44, 21 June 2022 (UTC) reply

The diff is tagged Twinkle, so not Deepfriedokra's fault. I opened a bug report over at Twinkle just now. I'll write a patch for it eventually, gonna work on some other patches first though. – Novem Linguae ( talk) 13:59, 21 June 2022 (UTC) reply

I just use the twinkle. I thought there was a bot that removed expired protection templates. Perhaps my adding a custom message is confusing the bot or the script. -- Deepfriedokra (talk) 15:39, 21 June 2022 (UTC) reply

What makes it "incorrect?" -- Deepfriedokra (talk) 15:40, 21 June 2022 (UTC) reply

@ Deepfriedokra: The |reason= parameter has no functionallity within neither the template nor module, and therefore doesn't need to be added alongside the protection template. That explenation should be in the protection log anyways. Aidan9382 _{( talk)} 17:01, 21 June 2022 (UTC) reply

So my custom add? -- Deepfriedokra (talk) 17:54, 21 June 2022 (UTC) reply

Sorry, what? Aidan9382 _{( talk)} 18:06, 21 June 2022 (UTC) reply

In this diff, Twinkle placed the code {{pp-protected|reason=Persistent [[WP:Disruptive editing|disruptive editing]]; requested at [[WP:RfPP]]|small=yes}}, but should have placed the code {{pp-protected|small=yes}}. The parameter $1 is allowed, but has to use one of the codes in the documentation, and "disruptive editing" is not one of them. The parameter $reason isn't read by the template at all. The bug seems 100% on Twinkle's side, and is pretty minor, so I wouldn't worry about it. Keep doin what you're doin and we will fix it in the background. – Novem Linguae ( talk) 18:47, 21 June 2022 (UTC) reply

Pp userspace bug?

(Side comment) About your use of the vandalism category as an example, when i used {{ pp|vandalism}} as a test on my user page, it used the baseplate user page category and not the specific vandalism one, but the blp category would be used over the user page one. I'll probably investigate whats going on there, since I've got no idea why theres a difference. Aidan9382 _{( talk)} 13:00, 21 June 2022 (UTC) reply

Unable to reproduce. Doesn't display at all for me. I think the banner doesn't display if it doesn't detect any page protection. – Novem Linguae ( talk) 13:26, 21 June 2022 (UTC) reply

Try doing {{pp}}, {{pp|blp}} and {{pp|vandalism}} at Special:ExpandTemplates. Set the context title to User:Aidan9382/SafeEnvironmentTesting (semi-protected for this very purpose) so that the banner actually works and see the output categories. Aidan9382 _{( talk)} 13:32, 21 June 2022 (UTC) reply

Was able to reproduce. Userspace {{pp|vandalism}} is not placing in Category:Wikipedia pages semi-protected against vandalism. Pretty minor, but if someone wants to fix it, go for it (assuming it's not intentional for some reason lost in history :) The bug is likely in a module somewhere, e.g. Module:Protection banner or Module:Protection banner/config. – Novem Linguae ( talk) 13:44, 21 June 2022 (UTC) reply

It's nothing to do with the namespace, the {{ pp}} template intentionally displays nothing on a page that's not protected. Instead, it puts the page into hidden Category:Wikipedia pages with incorrect protection templates. The reason for this is partly so that it doesn't get used by people who think that the template alone is enough to confer protection, and partly so that the banner or padlock indicator vanish when the prot expires. If you want, I can set up some subpages of Template:Pp/testcases having different prot levels so that the messages may be demoed. -- Redrose64 🌹 ( talk) 05:45, 22 June 2022 (UTC) reply

The test page we were using to reproduce the bug, User:Aidan9382/SafeEnvironmentTesting, is semi-protected. Placing {{pp|vandalism}} on User:Aidan9382/SafeEnvironmentTesting does not place in Category:Wikipedia pages semi-protected against vandalism, but a mainspace protected page such as Abraham Lincoln does. – Novem Linguae ( talk) 05:49, 22 June 2022 (UTC) reply

But it does categorise into hidden Category:Wikipedia semi-protected user and user talk pages, and also displays either a padlock icon or a banner, depending upon whether you used |small=yes or not. That banner or icon is the primary purpose of Module:Protection banner, which is the core of Template:Pp, any categorisation is a sideline. -- Redrose64 🌹 ( talk) 19:51, 22 June 2022 (UTC) reply

This is apparently intentional, see Module:Protection_banner/config line 755. This can be ignored, as its not a bug. Sorry for any confusion caused there. Aidan9382 _{( talk)} 20:05, 22 June 2022 (UTC) reply

Other codes such as blp in userspace place in the blp category though. But eh, sentiment seems to be that it's not worth fixing. All good. – Novem Linguae ( talk) 20:11, 22 June 2022 (UTC) reply

Yeah, its all about order. If its higher on that list it takes effect earlier (or at least its ordered that way). To "fix" it, the order would need to be changed, but I doubt its worth it, per this search (I just removed the only entry). Aidan9382 _{( talk)} 20:15, 22 June 2022 (UTC) reply

On pages that are move-protected (Move=Require administrator access) but not edit-protected, the {{ pp}} template is added, indicating that the page is move-protected. On pages that have both edit-protection and move-protection enabled with different levels (Edit=Require autoconfirmed or confirmed access; Move=Require administrator access), the {{ pp}} template is added only once, and shows only a padlock about semi-protection from editing, without a padlock about move protection. Shouldn't it be placed twice for pages that have both edit-protection and move-protection enabled with different levels, where the first one is for edit protection and the second one is for move protection? Vlad5250 ( talk) 17:58, 14 September 2022 (UTC) reply

@ Vlad5250: A 2020 discussion resulted in the removal of the green lock, so this template needs some updating if it still displays the lock. I think {{ pp}} should be paired with {{ pp-move}}. ~~ lol1 VNIO (I made a mistake? talk to me) 18:08, 29 March 2023 (UTC) reply

ꞏ

This edit request has been answered. Set the |answered= or |ans= parameter to no to reactivate your request.

Description of suggested change:

Diff:

31.143.175.133 ( talk) 18:23, 24 January 2024 (UTC) reply

I think, as indicated above, the user wants to remove the green padlock for move protection in Module:Protection banner per a 2020 discussion that resulted in the removal of the padlock in {{ pp-move}}. I myself don't know Lua and don't know where to look. ~~ lol1 VNIO (I made a mistake? talk to me) 19:24, 24 January 2024 (UTC) reply

I'm not sure any change needs to be made here. Looking at the config, {{ pp-move}} and similar templates automatically function as "category only" unless manually specified otherwise, meaning they normally won't display the green padlock.

AFAIK, the only way for a move protection padlock to show is for both the move protection to have a higher restriction level than the edit protection (the code at line 842 in the module mentions that it explicitly prioritises edit actions over other actions if the restriction is equal to or higher than the other action) and for someone to use either {{ pp-move}} with |catonly=no or {{ pp}} with |action=move explicitly specified. There should be no way regular usage of this template generates a move padlock.

If it turns out there is a page that is displaying this padlock despite not being the situation described above, let me know, as that's likely a bug. Aidan9382 _{( talk)} 20:04, 24 January 2024 (UTC) reply

@ Lol1VNIO and Aidan9382: I see no clear request here, nor indeed a vague request. This edit was simply a random drive-by non-request, they've seen the link "submit an edit request", and with that they are playing "what does this button do?". Per WP:TPO#empty edit requests, the edit should simply have been reverted and not responded to. -- Redrose64 🌹 ( talk) 22:24, 24 January 2024 (UTC) reply

This edit request has been answered. Set the |answered= or |ans= parameter to no to reactivate your request.

Base user pages are semi-protected by default through an edit filter, but the template does not recognized this and hides itself. Could you please fix this? Paradoctor ( talk) 22:44, 25 March 2024 (UTC) reply

Technically they're unprotected, the restriction is built into the MediaWiki software and is independent of the protections that an admin may set. Consider:

• {{PROTECTIONLEVEL:edit|User:23skidoo}} → autoconfirmed

because it's explicitly semi-protected, but

• {{PROTECTIONLEVEL:edit|User:Paradoctor}} →

because it isn't. For the same reason, CSS and JavaScript pages in MediaWiki space also test as unprotected. -- Redrose64 🌹 ( talk) 00:41, 26 March 2024 (UTC) reply

Ok, stop me if I say something false, but WP:SEMI is defined by who can edit, not by the technical means used to exclude this group from editing, right? The basic problem here is that two different means exist to achieve the same effect, and the template does currently not acknowledge one of them. Neither does {{ PROTECTIONLEVEL}}, at that. Paradoctor ( talk) 01:53, 26 March 2024 (UTC) reply

I agree that it's not about the means of protection. And consistent with that understanding, this template/module (via Module:Effective protection level) also checks for restriction via the titleblacklist, not just individual page protection. But unless you have some way of checking edit filters in a template/module (and I am not aware of any way to do that — see mw:Extension:Scribunto/Lua reference manual for available functions, including ones for protectionLevels and TitleBlacklist but seemingly not edit filters), this is not ready for an edit request. Edit requests should be used when you have specific changes that you would make if not for the edit restrictions. SilverLocust 💬 07:11, 26 March 2024 (UTC) reply

Ok, so you can't check edit filters. But that would be overkill anyway. I'm not aware of any other protection-relevant edit filter, so all that is required is to add an exception to the hiding functionality when a) we're on a user base page, and b) {{ unlocked userpage}} is not present. Surely that is doable?

not ready for an edit request Ok, then where do I go with this bug report? I could be wrong, but I don't think Phabricator handles en.Wikipedia templates. Paradoctor ( talk) 07:37, 26 March 2024 (UTC) reply

The prot level checking that I mentioned above, i.e. {{PROTECTIONLEVEL:edit|User:Paradoctor}}, isn't a template but a parser function. Template:Pp doesn't do any prot level checking itself, in fact it does hardly anything except fire up Module:Protection banner. This also doesn't do any prot level checking itself, it uses the functions of Module:Effective protection level to do that. Whilst that module will certainly need to be amended, the question is whether it is able to retrieve the required information from the MediaWiki software? If not, that is when a Phabricator ticket is required. Once ot's been closed as resolved, it's then up to us to amend Module:Effective protection level. -- Redrose64 🌹 ( talk) 09:38, 26 March 2024 (UTC) reply

Namespace checks can be done in Module:Effective protection level, but checking for {{unlocked userpage}} would add complexity by requiring a transclusion of the user page via getContent().

The current behavior is only a "bug" worth the effort to change if there is some reason to add {{ pp}} to a user page that only has the default restriction for a user page. I don't see why those pages should have a protection icon/banner anyway. SilverLocust 💬 10:06, 26 March 2024 (UTC) reply

I would suggest instead an edit notice in the user namespace via Template:Editnotices/Namespace/User to the effect of:

{{#ifeq:{{ROOTPAGENAME}}|{{PAGENAME}}|<!-- Show only if not a subpage. -->{{#ifeq:{{PAGENAME}}|{{REVISIONUSER}}|<!-- Nothing if editing one's own user page. -->|{{#if:{{PROTECTIONLEVEL:|{{FULLPAGENAME}}}}|<!-- Nothing if the page has its own protection. -->|{{if in page|page={{FULLPAGENAME}}|1=%{%{unlocked userpage%}%}|2=<!-- Nothing if "{{unlocked userpage}}" is in page. -->|3={{If autoconfirmed|<!-- Nothing if autoconfirmed. -->|{{Edit notice|header=This user page is currently protected from editing|image=Semi-protection-shackle.svg|text=This is a [[Wikipedia:User pages|user page]] other than the one associated with your account. Please note that [[Wikipedia:User pages#Protection of user pages|unregistered and newly registered editors cannot modify other editors' user pages]]. If you would like to contact this editor, please do so at [[User talk:{{ROOTPAGENAME}}|the editor's talk page]]. If this is your user page, you can [[Special:Login|log in]] to edit it.}}}}}}}}}}}}

(This is not a final draft, but I'll be unavailable to check/edit it further for the next ~24 hours.) SilverLocust 💬 12:52, 26 March 2024 (UTC) reply