Template talk:Pp-meta

From Wikipedia, the free encyclopedia
Jump to: navigation, search

The small padlock[edit]

Since I have received questions about the small padlock in the top right corner, here's some explanation:

1. The small grey padlock in the top right corner is one of the examples of what this meta template can create. The code that causes the small padlock is placed among the examples in the /doc page.

2. I did choose the grey padlock for now since currently this template is not protected. Thus the grey padlock is the least untrue. When this template becomes fully protected the example should of course be changed to the golden padlock. But this template should not be protected yet since it is still under testing and discussion and not used yet.

3. The position of the small padlock is where most protection templates now place the small padlock. That is, a bit more to the left than before. The reason is that if placed in the old spot it collides with and even covers other objects we place in the top right corner, like the featured article star and the spoken Wikipedia sound icon etc.

--David Göthberg 12:02, 27 September 2007 (UTC)

It seems not all templates place the icon at the same place, which interferes with other icons and MediaWiki:Gadget-edittop.js. I'll check them all to ensure they all occupy the same spot (right: 55px). EdokterTalk 19:41, 29 March 2008 (UTC)
Thanks for setting the "right:55px" on those protection templates that were not using {{pp-meta}}. It was annoying to see the padlock cover the edit button for section 0 when on template pages. (I use such a javascript too, but from another source.)
I noticed you lowered the padlock in {{pp-meta}} from "top:9px" to "top:10px". The reason I set it to 9px back when I created {{pp-meta}} was that I thought it lined up better with the other icons. Such as the featured article star and the spoken Wikipedia sound icon. At least in the three web browsers I tested it in. But one pixel up or down doesn't matter much.
By the way, I have updated the javascript I use to also show a "purge" button there, very nifty when doing work on template documentation since changes to the documentation do not always show up if one doesn't purge the template. I guess I should suggest the purge button at the official versions of those javascripts.
--David Göthberg (talk) 06:33, 30 March 2008 (UTC)

How the category setup works[edit]

Since I've made some changes to the category setup which are reasonably complex in nature, I'll clarify exactly how it works.

  1. pp-meta itself contains the following category code:
    • This code first evaluates if categories is equal to "no". If so, it cancels the display of a pp-template's article categories at each level. If not, it displays the values if and only if present.
    • This code is offset with includeonly tags to only be made effective at the transcluded level, that is, wherever the template is placed.
  2. Any template calling pp-meta should use the following code for categories:
    • Where **** is, the categories that one wants the calling template to display should be placed. These can also use ParserFunctions to be disabled where desired (i.e. expiry-enabled categories that appear once the article is unprotected again).
    • Since any template calling pp-meta should use the form <includeonly>{{pp-meta}}</includeonly> (where pp-meta includes parameters), categories placed as the calling template's default for categories will be transcluded only to the article page.
  3. Therefore:
    • pp-meta's categories parameter evaluates the category's value to see whether categories should be suppressed. If not, it displays the value given to the calling template.
    • The calling template sets the default categories value in the parameter, but allows it to be customized, for example to values like "no" to suppress category display. "no" should be the only non-categorical value passed, or the template will display the resulting code beneath its lower bound. This bug is only solvable with a complex solution if Wikipedia ever has Extension:StringFunctions enabled, which it does not as of Nihiltres(t.l) 15:37, 28 September 2007 (UTC).

I hope this explains the general idea of how it works. I'm currently too tired to figure out how to explain it in a REALLY simple way , but if someone can explain it simply enough (or decide that it can't be explained any simpler), please add it to the documentation somewhere as its own section. Nihiltres(t.l) 03:04, 28 September 2007 (UTC)

Now that I'm not as tired, I feel confident that I can reasonably add this to the "technical details" section of the documentation, so I'll go do that now. Nihiltres(t.l) 15:37, 28 September 2007 (UTC)

New namespace detection code[edit]


The old namespace detection code in this meta-template is not complete, so it needs fixing. (My fault, I coded that.)

The new code is available for cut and paste at {{pp-meta/sandbox}}. The sandbox is the complete code, so delete all old lines in {{pp-meta}} and paste in the new lines from the sandbox.

I used the new improved namespace detection function that we use in {{main talk other}}. I also changed one thing back to as it was from the beginning: I removed the {{pp-template}} since that one does not use this meta-template, thus it prevents us from showing the small padlock from this meta-template as an example on the template page. (Or we get two padlocks there at the same time, at two different positions.)

--David Göthberg (talk) 03:52, 21 March 2008 (UTC)

 Done Took me a while to get my head around what you'd done there, but that's very elegant and clean. Nice code! Happymelon 22:59, 22 March 2008 (UTC)
Thanks and thanks. Yeah, that code took some learning and testing to get right. The old code here at {{pp-meta}} was my first try, and then Nihilitres improved it. Since then I coded namespace detection some more times and studied how others did it. So I ended up making the {{main talk other}} and then copying and pasting that code to this template.
--David Göthberg (talk) 00:32, 23 March 2008 (UTC)

Too abstract?[edit]

Although as I said above, this template handles the namespace-dependent formatting in a very elegant fashion, it strikes me that it is (as currently written) a bit too abstract for its purpose. There are still many features which have to be manually specified in each of the pp-series of templates. For instance, each one of the instance templates has its own code for the small padlock which appears in the top-right of the screen. There is absolutley no reason why this can't be moved into pp-meta. Similarly, there's no reason why, given that the only difference between the padlocks used in each template is the colour, the size, formatting and caption can't be moved to pp-meta. Most of the text itself appears to be boilerplate, so a fair amount of that could perhaps also be incorporated, although I'm less keen on that as I can see the potential need for flexibility there. But it seems a shame to have such a great metatemplate given such limited functionality.

I have modified the code substantially in a sandbox, and have come up with a new version here. Instance templates are now generated using code similar to the examples found here. I will be the first to state that the new code for pp-meta is neither as clean nor as elegant as the current code. In particular, the imagemap implementation is very inelegant (necessitated by the non-expansion of template parameters inside the imagemap XML tags). However, and much more importantly, the code to generate instance templates is much cleaner, which is what metatemplates are all about. By shifting as much of the coding as possible onto the metatemplate, it makes the instance templates much less cluttered and easier to modify.

I'm interested to hear comments and suggestions about this new code. Happymelon 22:16, 23 March 2008 (UTC)

Just wanted to give a quick response since I guess you are eager to get one: Yes, this meta template could probably handle more of the functionality. Back when we coded it summer 2007 MediaWiki could not handle template parameters inside imagemaps and that was one of the reasons why it was designed the way it was. But now I heard rumours that MediaWiki can handle template parameters inside imagemaps so we should test that. And yes, most of the handling of the big padlocks can probably be moved into {{pp-meta}}.
1: By the way, over at Wikipedia talk:Article message boxes#Protection type boxes we are currently discussing to create a {{ambox protected}} that can be called from {{pp-meta}}. Since the current "ambox" code in {{pp-meta}} does not include the extra tricks that make amboxes flow nicely left of infoboxes and images. So we want to separate out the "ambox logic" from {{pp-meta}} and have {{pp-meta}} instead only handle the rest of the logic such as page type detection.
2: When we deploy the new version I suggest we don't modify the old one, but instead make a new one named say {{pp-meta2}}, at least during deployment. Then we can switch over the different pp templates one by one without getting weird behaviour of the non-modified ones meanwhile.
Now I am going to eat breakfast and then I will take a look at your code.
--David Göthberg (talk) 22:47, 23 March 2008 (UTC)
Happy‑melon: I have looked at your code, but have not tested it (yet). Here is my preliminary analysis of the new templates in your sandbox:
3: I found a bug close to the end of your code. This line:
| talk = | other | #default =
Should probably be changed to:
| talk | other | #default =
4: I noticed that you choose the red padlock for permanent protection. That is a new use for me. So far I have only seen the red padlock used in {{Permprot}} that goes on talk pages to inform about a permprotected page. I think the red padlock is to intense to show in articles, the golden padlock is less chocking. But with the brown message box background in talk pages then the red padlock is okay.
5: Your new main/other detection code is elegant, probably more readable than my old "x" solution. I mean this code:
I tested it and it seems to do what it should do. I might change {{main talk other}} to use it. Although I am also thinking of another way to make that detection code easy to understand:
I have to think about which one is the least confusing.
6: I have not checked yet if your generic texts for the small padlocks match what is currently used, but the texts sound fine to me.
So my preliminary conclusion is that your code seems all right. But I think it needs some clearer indention and some comments and a lot more testing. I'll be looking more into this during the next few hours and days.
--David Göthberg (talk) 01:59, 24 March 2008 (UTC)
7: Happy‑melon: I ran some tests in my own userspace, it seems that at least the currently installed version of MediaWiki still does not handle template variables inside imagemaps. (I guess you already tested that?) So your solution with "generic" imagemaps for each type seems to be the best.
--David Göthberg (talk) 02:26, 24 March 2008 (UTC)
8: I think your switch:type statement for the imagemaps should have a default case with an error message. Since if someone sets small=yes and then not sets type or misspells type then nothing at all will render, which will be confusing. I suggest an error message something like this: "{{pp-meta2}}: Missing or wrong type parameter." It is not as necessary to have an error message for the image:switch:type since that generates a visible image string.
--David Göthberg (talk) 12:41, 24 March 2008 (UTC)
OK, thanks for your quick response. Thanks for numbering your statements, it makes them a lot easier to respond to:
  1. Interesting, thanks. I've now got involved.
  2. I've just come from a complete overhaul of the CSD templates (the db- series), where we used {{db-meta/new}} and {{db-g1/new}} etc. I was planning on doing the same here.
  3. Well spotted. I've copied the code over to {{pp-meta/sandbox}}, so we can work on it there.
  4. It's currently only used in {{permprot}}, but it's the colour seen at WP:PPOL#Permanent protection, so I thought it would be appropriate. It would be used only on templates (where it would always be small), or (if we chose to put it there) on things like WP:GFDL or WP:LEGAL.
  5. I'll have a check myself and make sure they are similar.
  6. I think that the {{ns:0}} syntax is much easier to understand, but that's just my preference. It avoids the "where did the namespace go" thought process :D.
  7. Yes I was very annoyed to realise that the parameters weren't expanded.
  8. Yes it should - I'll add one.
Happymelon 13:31, 24 March 2008 (UTC)
  1. This looks interesting - we'll want to keep this in mind while designing any update, and I think we should implement it if possible.
  2. There's a strategy I've used before, which is to create a new template, test individual instances, and then move the new template over the old template and undelete the old template. This allows dynamic testing while letting the final copy include the development history. With Happy-melon and I both administrators, this shouldn't be a big deal to carry out.
  3. OK, just keeping numbering of issues constant; good to have development central.
  4. It's good to include all the colours in use: flexible templates are generally a good thing.
  5. Simple: migrate "confusing" code into {{main talk other}} and use that. Elegant code can be complex; the solution is to use subroutines (or, in the case of templates, meta-templates).
  6. {{ns:0}} is preferable, since it remains viable even if the name for the main namespace is changed to be non-null.
  7. To allow ImageMap to accept parameters, replace the <imagemap> and </imagemap> tags with {{#tag:imagemap| and }} preserving line breaks. I recently wrote a tutorial on the subject.
  8. Error messages are ugly, and won't work with the #iferror parser function. Let's simply set defaults to create graceful failure.
All in all, however, the new code looks good; the worries I have are structural rather than bugs. Nihiltres{t.l} 16:52, 24 March 2008 (UTC)
Ok, enough with those numbers :D - perhaps we should restart the numbering since most of them are resolved. I have completely rewritten the code in {{pp-meta/sandbox}} to be a much more closely-defined metatemplate. It looks a bit of a mess in the edit box, but in notepad or something without word-wrap it's actually fairly clean (not nearly as clean as the old code, of course, but that's inevitable). I have created some instances at {{pp-meta/test1}}, {{pp-meta/test2}} and {{pp-meta/test3}}, and some testcases at {{pp-meta/testcases}}. What do you think? The metatemplate is much messier, but the instance templates are very clean indeed, which is the general idea. Comments? Happymelon 19:10, 24 March 2008 (UTC)
I find the coding-in of the template text somewhat problematic; meta-templates shouldn't define the wording of a part of a template unless it's present across every protection template. In re-coding the meta-template, we should be providing a framework on which to hang the custom text, not rigidly defining the instances except for local reason changes. The code should define which, say, images to use and perhaps some simple (or default) tooltip text, and then leave everything else to be filled in at an individual template. For one thing, the different templates might want different phrasings for clarity. For example, some of the semi-protection templates start "Editing of this page by unregistered or newly registered users is currently disabled […]" rather than "This page is protected […]", wordings which have been used to make the messages more clear to newbies. Nihiltres{t.l} 20:51, 24 March 2008 (UTC)
It's certainly true that coding wording makes the potential instances less flexible, and the semi-protect difference certainly gave me pause for thought. But I don't agree that the meta-template shouldn't have anything other than the images - that's barely an improvement on what we've currently got. My mantra with metatemplates, and I've worked on a few now (see {{WPBannerMeta}} to understand why I'm not overly concerned with code readability!) is that anything which is in all of the instance templates, should be in none of the instance templates, and be coded in at meta. The primary purpose of a metatemplate is to provide consistency between the various instances. All the instances should have a link to WP:PPOL and to the deletion log - there is no reason why that shouldn't be hardcoded at pp-meta. All the dispute-based templates should have a note that protection is not endorsement, and that note should be consistent across all the instances - again, no reason why that shouldn't be hardcoded. I agree that we shouldn't compromise on wording just to get more things hardcoded, so I've played around with the code a bit - allowing us to still use the "editing of this page by..." - this did not actually require returning any more code to the instance templates. The fact that some of the semi-protection templates use this wording, but not all, reinforces my desire to keep wording like this at source. We're not trying to create a fantastically versatile framework like {{ambox}} here, which can be customised for everything from {{unreferenced}} to {{db-i6}}; we're trying to create a metatemplate that can be used easily and effectively to create protection templates. As such, I stand by my belief that the more code and text we can shift into {{pp-meta}} and out of {{pp-semi-spambot}} and the like, the better. Happymelon 21:20, 24 March 2008 (UTC)

Text use (arbitrary subheading, long section)[edit]

Fair enough; I understand why we should shift text into the meta-template. But let's at least try to keep the texts as close as possible, if not identical, to the current implementations. If this involves allowing overrides of default text, that would work too; in fact, I think that we should allow every text element to be overridden (individually) for instances if possible. Nihiltres{t.l} 23:24, 24 March 2008 (UTC)

I agree, default texts at least for the small padlocks can be a good thing, as long as there is a parameter that lets you override it (feed a new text instead).
And I am happy to see that we have an expert on imagemaps on-board!
I probably won't be around much since I have severely neglected my real life the last few weeks so things are starting to pile up here. I have spent way too much time editing Wikipedia lately. But it seems this meta-template is in good hands with you Nihiltres and Happy-melon.
--David Göthberg (talk) 00:02, 25 March 2008 (UTC)

I think I've gotten the text setup up to scratch; please review. :) Nihiltres{t.l} 16:54, 26 March 2008 (UTC)

I've made a few tweaks, but it generally looks good. Happymelon 17:37, 26 March 2008 (UTC)
I saw how you used {{main talk other}} here in the sandbox. So I have made some new code for {{main talk other}} that will make it so that you don't need those pesky #ifeq statements here. I would like that you guys take a look at my code suggestion at Template talk:Main talk other and add that code to {{main talk other}}.
--David Göthberg (talk) 17:57, 26 March 2008 (UTC)
The #ifeq stuff with {{main talk other}} has been fixed; I think we're ready for a test rollout on one of the less-used protection templates. Nihiltres{t.l} 19:11, 30 March 2008 (UTC)
Well, Happy-melon is on vacation for a week (literally in the real world) and I will be busy this week too in the real world. I have not checked that code properly and not ran any tests on it, but from what I have seen it looks good. So it is in your hands Nihiltres. And yes, testing it on one of the less used protection templates (like last time when you found one that wasn't used at all) should be a good thing. Then you can run tests on a real template. Sorry that I won't be available.
--David Göthberg (talk) 22:42, 30 March 2008 (UTC)
I'm going to work out a few bugs first. Nihiltres{t.l} 19:21, 5 April 2008 (UTC)

Talkspace small version?[edit]

I was just thinking, do we want to use, for small=yes on talkspace pages, the "small-talk" class and have the mini padlock version be activated with small=alt or something? I could imagine that it would be easy to change the initial "yes" in the code to {{#ifeq:{{NAMESPACE}}|{{TALKSPACE}}|alt|yes}} to effect such a change, and set the line | 2 = class="messagebox standard-talk metadata plainlinks" to | 2 = class="messagebox {{#ifeq:{{{small|no}}}|yes|standard|small}}-talk metadata plainlinks". Think this is a good idea to implement? I'm working through potential bugs and working my head around how to work the default-text setup right, but this occurred to me when I recently fixed a few CSS ids to "protected-icon" from "administrator" and saw such a possibility in the setup of {{Temprot}}, which is one of the protection templates not yet using the current pp-meta. Nihiltres{t.l} 19:21, 5 April 2008 (UTC)

The problem is that this would require a change on a significant number of the several thousand pages which currently transclude a pp- series template, since a majority of them use the small padlock rather than the full banner. So while it's easy to implement it in the code, making it work with the template calls that are already out there is much less easy. Happymelon 19:28, 5 April 2008 (UTC)
I've converted {{pp-semi-spambot}} to use {{pp-meta/sandbox}} for some live testing, and it seems to be OK. I'll probably convert a couple of other pp templates that aren't too widely used. Ultimately, we want to convert all the pp templates, then synchronise {{pp-meta}} and {{pp-meta/sandbox}}, and then change the calls in the instance templates back to {{pp-meta}}. Happymelon 19:28, 5 April 2008 (UTC)

Permanently protected pages[edit]

I'm just checking this edit here, because I'd rather someone who fully understands what's going on in this page makes the change... Currently, the permanent protection link does not go to the right place on Wikipedia:Protection policy. I think the section that currently reads

{{{icon-link|Wikipedia:Protection policy#{{#switch:{{lc:{{{type}}}}}

should read

{{{icon-link|Wikipedia:Protection policy#{{#switch:{{lc:{{{type}}}}}

Could someone confirm/implement this?


Sam Korn (smoddy) 18:09, 27 May 2008 (UTC)

I changed the section title back to its original (and much clearer, IMO) "Permanent protection" - no idea why it was ever changed from that. Happymelon 18:38, 27 May 2008 (UTC)
I noticed that the policy page has invisible span markers with ids like "full", "semi", "create", and so forth. It might be simpler to avoid the problem of changing section titles by using those span markers instead, which would allow us simplify the code to
{{{icon-link|Wikipedia:Protection policy#{{lc:{{{type}}}}}}}}
as all of the markers correspond perfectly to our type names. If no one objects, I'll make this change later today. Nihiltres{t.l} 14:07, 30 May 2008 (UTC)
As long as those span ids stay put, that's a beautiful solution. Happymelon 20:42, 30 May 2008 (UTC)
Done. (A little later than I planned, admittedly - real life is catching up :p ) Nihiltres{t.l} 15:51, 31 May 2008 (UTC)

White space in icon-reason[edit]

You currently have to insert "<nowiki> </nowiki>" at the beginning of the icon-reason attribute to have the text displayed correctly. I wonder if this can be fixed? Cheers, Face 22:09, 4 September 2008 (UTC)


How ironic that I'm now the one asking for an edit... :D Please replace the code with the below, to fix the problem above. (also)Happymelon 22:19, 4 September 2008 (UTC)

<div class="metadata plainlinks" id="protected-icon" style="position:absolute; z-index:100; right:55px; top:10px;">
 |full=Fully protected
 |move=Move protected
 |indef=Permanently protected
 |create=Protected from creation
 |office=Protected by the Wikimedia Office
default [[{{{icon-link|Wikipedia:Protection policy#{{lc:{{{type}}}}}}}}|{{{icon-text|This {{#ifeq:{{NAMESPACE}}|{{ns:0}}|article|page}} is {{#switch:{{lc:{{{type}}}}}
 |office=<!--null, but should this have a special tag?-->
}}protected{{#ifeq:{{lc:{{{type}}}}}|indef||{{#if:{{{expiry|}}}| until {{#time:F j, Y|{{{expiry}}}}}}}}} {{{icon-reason|}}}.}}}]]
desc none
| demospace = {{{demospace|}}}
| type = protection
| image = [[Image:{{{image|{{#switch:{{lc:{{{type}}}}}
}}}}}|40px|{{{icon-text|This page is {{#switch:{{lc:{{{type}}}}}
 |office=<!--null, but should this have a special tag?-->
| text = '''{{{reason-text|{{#switch:{{lc:{{{type}}}}}
 |full=This page is currently [[Wikipedia:This page is protected|protected]] from editing
 |semi=Editing of this {{#ifeq:{{NAMESPACE}}|{{ns:0}}|article|page}} by [[Wikipedia:User access levels#Autoconfirmed_users|new]] or [[Wikipedia:User access levels#Anonymous_users|unregistered]] users is currently [[Wikipedia:Protection policy|disabled]]
 |move=This {{#ifeq:{{NAMESPACE}}|{{ns:0}}|article|page}} is currently [[Wikipedia:This page is protected|protected]] from [[Help:Moving a page|page moves]]
 |indef=This page is [[Wikipedia:This page is protected|protected]] from editing ''indefinitely''
 |office=This {{#ifeq:{{NAMESPACE}}|{{ns:0}}|article|page}} is currently [[Wikipedia:This page is protected|protected]] from editing
 |create=[[Help:Starting a new page|Recreation]] of this {{#ifeq:{{NAMESPACE}}|{{ns:0}}|article|page}} [[Wikipedia:This page is protected|has been disabled]]
}}{{#ifeq:{{lc:{{{type}}}}}|indef||{{#if:{{{expiry|}}}| until {{#time:[[F j]], [[Y]]|{{{expiry}}}}}}}}}{{{reason<includeonly>|</includeonly>}}}.}}}'''<br /> {{{explanation-text|{{#ifeq:{{lc:{{{dispute}}}}}|yes|This protection is '''not''' an endorsement of the {{#ifeq:{{{type}}}|move|[{{fullurl:Special:Log|type=move&page={{FULLPAGENAMEE}}}} current title]|[{{fullurl:{{FULLPAGENAMEE}}|action=history}} current version]}}.}} See the [[Wikipedia:Protection policy|protection policy]] and [{{fullurl:Special:Log|type=protect&page={{FULLPAGENAMEE}}}} protection log] for more details. {{#switch:{{lc:{{{type}}}}}
 |full|indef=Please discuss any changes on the [[{{TALKPAGENAME}}|talk page]]; you may use the {{tlx|editprotected}} template to ask an [[Wikipedia:Administrator|administrator]] to make the edit if it is supported by [[Wikipedia:Consensus|consensus]]. {{#ifeq:{{NAMESPACE}}|{{ns:8}}<!--MediaWiki-->||You may also [[Wikipedia:Requests for page protection|request]] that this page be unprotected.}}
 |semi=If you cannot edit this {{#switch:{{NAMESPACE}}|{{ns:0}}=article|{{ns:6}}=image|#default=page}} and you wish to make a change, you can {{#ifeq:{{NAMESPACE}}|{{TALKSPACE}}||[[{{TALKPAGENAME}}|discuss changes on the talk page]],}} [[Wikipedia:Requests for page protection#Current requests for unprotection|request unprotection]], [[Special:Userlogin|log in]], or <span class="plainlinks">[http://en.wikipedia.org/w/index.php?title=Special:Userlogin&type=signup <span style="color:#002bb8;" title="Sign in / create account">create an account</span>].
 |move=The page may still be edited but cannot be moved until unprotected. Please discuss any suggested moves on the [[{{TALKPAGENAME}}|talk page]] or at [[Wikipedia:Requested moves]].  You can also [[Wikipedia:Requests for page protection|request]] that the page be unprotected.  
 |office=If you are able to edit this page, please discuss all changes and additions on the [[{{TALKPAGENAME}}|talk page]] first. '''Do not remove protection from this article unless you are authorized by the Wikimedia Foundation to do so.'''
 |create=Please see the {{#if:{{{xfd|}}}|'''[[{{{xfd}}}|deletion discussion]]''' or the}} [{{fullurl:Special:Log|type=delete&page={{FULLPAGENAMEE}}}} deletion log] for details of why this page was deleted. If you would like to create a page at this title, you must first [[Wikipedia:Requests for page protection|request]] for it to be unprotected, or for the deleted material to be restored via [[Wikipedia:Deletion review|deletion review]].
}}<!--End if small--><includeonly>{{#ifeq:{{lc:{{{categories|no}}}}}|no||{{{categories|}}}}}</includeonly><noinclude>
<!-- Add categories and interwikis to the /doc subpage, not here! -->
This won't look good because it will create an unwanted space before the period if there is no icon-reason parameter. Is there anything wrong with using something like {{#if:{{{icon-reason|}}}|&#32;{{{icon-reason}}}}}? --- RockMFR 22:43, 4 September 2008 (UTC)
No I was just being lazy; seems I didn't analyse the code carefully enough. (also)Happymelon 23:06, 4 September 2008 (UTC)

topicon class[edit]

{{edit protected}}
It would be handy if pp-meta would use the topicon class for the small padlock, so that we don't need to special case this icon into the javascripts anymore. The 2nd line of the source would become:

<div class="metadata plainlinks topicon" id="protected-icon" style=

--TheDJ (talkcontribs) 14:54, 25 November 2008 (UTC)

Yes check.svg Done — {{Nihiltres|talk|log}} 16:37, 25 November 2008 (UTC)
I have made some more changes to the topicon. Tested in the sandbox and all CSS related, so can't go much wrong, but please revert of course if problems arrise. --TheDJ (talkcontribs) 22:29, 28 April 2009 (UTC)

Category reworking coming up?[edit]

There's a discussion at Wikipedia talk:Categorization#New_protection_category_layout about changing the categorization scheme used for protected pages. As this would presumably be implemented in Pp-meta and the other lower-level protection templates, it is worthwhile mentioning here. {{Nihiltres|talk|log}} 03:00, 15 December 2008 (UTC)

What's up with small=maybe?[edit]

Perhaps I missed something with being away for a while, but what's up with the recent addition of a small=maybe case that outputs nothing visible? This seems to defeat the purpose of the template—to show users that a page is protected. As far as I can tell, this is used only on {{pp-move-indef}}, but it strikes me that it shouldn't be used at all—it's quite opaque to most users that the page is in fact protected. Would anyone be bothered were I to set {{pp-move-indef}} to small=yes and remove the code causing this behaviour? {{Nihiltres|talk|log}} 03:32, 6 January 2009 (UTC)

I'd guess that the 'maybe' code was intended to go to the small version in some cases, but it seems to have been improperly executed, so is now broken as you say. I would quite like to see a setting that reverses the default for some types ({{pp-template}}, for instance, is always made small) but this is not the way to do it. Happymelon 10:49, 6 January 2009 (UTC)
Setting a default can be done in the individual templates: setting {{{small|yes}}} allows small=no to override a default small version. Do you mean that we should reverse the default based on the value of the type parameter? That would require another type #switch, but probably wouldn't be hard to implement—I merely don't see the point in getting that elaborate when there are few enough protection templates to let the current small parameter handle things. {{Nihiltres|talk|log}} 16:40, 6 January 2009 (UTC)
It has already been discussed that using the move-protection icon for a mass of pages with no reason to be moved is detrimental because it confuses users and is largely unneeded, see for example Wikipedia:Bots/Requests for approval/ProtectionTaggingBot. pp-move-indef categorizes only, it doesn't require pp-meta, but an option blank=yes could make it. Cenarium (Talk) 19:18, 8 January 2009 (UTC)

Protection templates in Category:Wikipedia protected pages[edit]

Looks like Template:Pp-meta, Template:Pp-meta/doc, Template:Pp-meta/sandbox and Template:Pp-protected are in Category:Wikipedia protected pages, can someone find out why ? Cenarium (talk) 18:56, 5 March 2009 (UTC)

Found out why, [1]. Cenarium (talk) 20:37, 4 September 2009 (UTC)

Fix link[edit]


Please change:

Code Before

This protection is '''not''' an endorsement of the {{#ifeq:{{{type}}}|move|[{{fullurl:Special:Log|type=move&page={{FULLPAGENAMEE}}}} current title]|[{{fullurl:{{FULLPAGENAMEE}}|action=history}} current version]}}.

Code After

This protection is '''not''' an endorsement of the {{#ifeq:{{{type}}}|move|[{{fullurl:Special:Log|type=move&page={{FULLPAGENAMEE}}}} current title]|[{{fullurl:{{FULLPAGENAMEE}}|diff=cur}} current version]}}.

because the "current version" should display the current diff, not the history. MC10 | Sign here! 23:24, 3 May 2009 (UTC)

But is that really any better ? I mean in most cases, aren't you already looking at that specific version of the page ? In that case the history seems more useful to me (although I agree incorrectly worked into the text). —TheDJ (talkcontribs) 00:10, 4 May 2009 (UTC)
In many, if not most, cases, the last diff will be an admin adding the protection template, which is completely useless to the reader. Since both TheDJ and I disagree with the proposed change, I've disabled the editprotected request for now. {{Nihiltres|talk|log}} 05:40, 4 May 2009 (UTC)

subjectspace=yes means this template cannot be used for talk pages[edit]

When talk pages are protected and this template is used, it erroneously reports about the "article" when we're actually trying to tell them the talk page is protected. –xenotalk 13:17, 14 April 2010 (UTC)

Finally tracked this down as well, it isn't going to be quite so simple {{pagetype}} always does this, with or without subjectspace. Really {{NAMESPACE}} and a switch should be used. I might just ignore this problem. Prodego talk 23:08, 12 January 2011 (UTC)
Fixed with Template:pp-meta/pagetype. Prodego talk 23:55, 12 January 2011 (UTC)

Confusing alt text for pending changes[edit]

The alt text generated by this template for pending changes is confusing: "This article is pending changes protected." Someone who isn't familiar with the pending changes feature would have no idea what this means or even how to parse the grammar of the sentence. Something like "Changes must me reviewed before being displayed on this page" would be better. This will require slightly rewriting some of the alt-text logic, however. Kaldari (talk) 00:20, 16 June 2010 (UTC)

I've made some changes that should fix the problem. When I* built {{pp-meta}}, I (evidently wisely!) included code to override specific parts of the text in particular uses of the meta-template: the icon-text parameter overrides the default tooltip text, and I've implemented this option in the {{pp-pending}} and {{pp-pending2}} templates. (*among other people, of course)
In the longer run, the logic in {{pp-meta}} could probably be improved, but I'm not sure how much ought to be given per-case. For example, the "This article is " prefix and "protected" suffix aren't very helpful for the pending changes scenario, but if we include that part as part of each individual case, the benefits from keeping the code as default become minimal from the redundancy that would be required. I'm inclined to merge only the "protected" suffix into each case (minimal redundancy added for much flexibility added) and use a slightly awkward wording for the default pending changes tooltip that can be easily overridden in most real cases using the icon-text parameter. Does that seem like a reasonable plan?
I also ought to request that the developers implement support for Pending Changes in the protectionlevel magic word—or some similar feature—as that would allow a more elegant implementation of support in {{pp-meta}} for Pending Changes messages; I'm not quite happy with (more of) the code as it stands. {{Nihiltres|talk|edits|}} 20:34, 16 June 2010 (UTC)

Invalid HTML[edit]

This template causes id="protected-icon" to be generated twice, thus every protected template renders invalid HTML. See W3C markup validation for Template:Pp-meta. Note: "id" invalid: "." is caused by a header in the documentation and the <ul>...</ul> problem is a MediaWiki bug that has been resolved but not implemented. ---— Gadget850 (Ed) talk 22:20, 26 July 2010 (UTC)

Once from the template code, once the protection lock automatically added by the documentation page. I guess we could includeonly the lock. —TheDJ (talkcontribs) 22:37, 26 July 2010 (UTC)
Ah— I was trying to figure out if the second one was caused by the doc page, but hadn't quite got there yet. ---— Gadget850 (Ed) talk 22:47, 26 July 2010 (UTC)

More accessible protection icons[edit]

  • Fully protected
Fully protected
Fully protected
  • Semi-protected
  • Pending changes protected (level 1)
Pending changes protected (level 1)
Pending changes protected (level 1)
  • Pending changes protected (level 2)
Pending changes protected (level 2)
Pending changes protected (level 2)
  • Create protected
Create protected
Create protected
  • Move protected
Move protected
Move protected
  • Upload protected
Upload protected
Upload protected
  • Permanently protected
Permanently protected
Permanently protected

Our padlock icons are becoming increasingly diverse in color yet static in shape, and it occurred to me that this might cause some confusion for colorblind people. As a result, I took the liberty to create combo icons so that they have their original color but also a logical and unique symbol in order to increase accessibility. I used symbols that somewhatly made sense to me and were easy to implement, so obviously feel free to give feedback/propose others/make your own. Cheers =) --slakrtalk / 06:04, 18 November 2010 (UTC)

I take it from the crickets that there are no initial objections, so I'll start the swap. Feel free to revert. --slakrtalk / 07:35, 7 December 2010 (UTC)
Sorry for that. I looked, and think they look good. My only concern is that, at the small size, the thinner symbols (the diagonal bar, the horizontal bar) aren't very clear. Might they be emboldened a bit more? --Bsherr (talk) 16:11, 7 December 2010 (UTC)
And, similarly, perhaps the arrows could have solid arrowheads? --Bsherr (talk) 16:12, 7 December 2010 (UTC)
Also, the horizontal bar should go from end to end, like the diagonal bar. --Bsherr (talk) 18:27, 7 December 2010 (UTC)
Yeah, they don't seem to show up too well with the smaller size. Perhaps consider having the symbols next to the lock icon for upper corner of a page? The bigger size is fine though. --Dorsal Axe 20:02, 7 December 2010 (UTC)
Rather a big change. I think you should discuss this on one of the Village pumps. —TheDJ (talkcontribs) 22:23, 7 December 2010 (UTC)
Posts were made here and on the protection policy talk page. TheDJ, if you'd like to post on the Village Pump as referral to here, that would be fine. --Bsherr (talk) 22:01, 8 December 2010 (UTC)
The icons to the right of the title are sensitively positioned. It's probably not possible to make them wider. --Bsherr (talk) 21:59, 8 December 2010 (UTC)
(deindent) Good ideas. I really just wanted to get the ball rolling on it. I do share the concerns about the small icon size and like the idea of solidifying the arrows (among other things). Obviously {{sofixit}} applies here to anyone who thinks they've got a good idea, but I'll work on some alternates when I get a sec if nobody else steps up to the plate. =) In response to TheDJ, however, I can only echo what others have said—I've canvassed this in several relevant places (even on IRC) and nobody cared enough to even comment; granted, I didn't think of VPT since this didn't really seem like a technical issue, but if you think it'll help, by all means, please post. --slakrtalk / 14:06, 9 December 2010 (UTC)
They're kind of ugly, imo. @theM0N0 05:08, 12 December 2010 (UTC)
I agree. Is there a way I can use custom css to see the old icons again, or do I have to live with it? Accessibility is good, and I don't want to raise a huge fuss over a minor detail. /ƒETCHCOMMS/ 00:39, 13 December 2010 (UTC)
The remedy is for a graphically skilled Wikipedian to edit the images to make them asthetically pleasing. I'm sure we'd all welcome that help. --Bsherr (talk) 04:55, 13 December 2010 (UTC)

User:Slakrs icons are currently cc-by-sa, which I've come to understand is not valid for interface elements (please correct me if I'm wrong). Also, imo, his changes are not originally enough for him to claim own copyright. AzaToth 23:56, 16 January 2011 (UTC)

This may be easy enough to fix. Slakr, can you relicense the files as PD-user? --Bsherr (talk) 00:27, 17 January 2011 (UTC)
Just fyi, the editbox text is still, "You irrevocably agree to release your contributions under the CC-BY-SA 3.0 License and the GFDL," so if a major copyright standard for wikipedia has changed, please be sure to update the appropriate interface message, as well. On a related note, if you'd like to put in time and effort to make something different and license it under whatever you want the "CC-BY-SA 3.0 License and the GFDL" (or presumably a compatible license), then by all means do so. --slakrtalk / 23:57, 17 January 2011 (UTC)
Images in interface elements often don't lead towards their image description page (These lead towards info pages on page protection), and thus their licensing information is unreachable. It has been agreed that we should only use PD images when we remove their default click target from them. —TheDJ (talkcontribs) 11:45, 18 January 2011 (UTC)
Slakr, everything's still correct. What appears at the bottom of the edit page refers to textual contributions. As you know, you can't upload an image by editing a page, thus the statement on the edit page can only refer to textual contributions. Images are uploaded using Special:Upload, which includes correct instructions regarding licensing, and allows the user to choose from among several licenses. Can you relicense the images, please? --Bsherr (talk) 16:52, 18 January 2011 (UTC)
No. --slakrtalk / 10:34, 19 January 2011 (UTC)
...And I should also note that this is not the way to encourage content creation from people like me. At this rate, I, personally, would rather never upload another image to Wikipedia again than be badgered, both here and on irc, into pulling my name off the things I make in my spare time and completely for free. All I ask is for someone making use of that to say who made it, and if that's somehow impossible for you to deal with—that trivially minor request—then it would seem that the problem's not originating on my end. Therefore, my suggestion to all of you would be to do what I did: take some time to fire up a vector graphics editor, play around with it, and then make something even better. Doing so grants you the power to quell your discontent instead of wasting time and bandwidth furthering this discussion. Case in point, I could have spent this time responding to the points raised above regarding the thumbnail versions of the icons and come up with some better alternatives, but since you've forced my hand, I've had to spend this free time typing this paragraph instead. --slakrtalk / 11:01, 19 January 2011 (UTC)
I'm not trying to badger you, Slakr. I asked you one, and you gave a reply that included some inaccuracies, so I asked again for clarification. I'm only asking because I thought it would be the simplest way to resolve a potential issue. But if you don't want to, I understand and I won't pursue it with you further. --Bsherr (talk) 18:00, 19 January 2011 (UTC)
Heh, no worries, that particular part was more directed toward AzaToth. --slakrtalk / 20:27, 19 January 2011 (UTC)
Given Slakr's decision not to relicense the files, is there any evidence there's a problem with our policies? It seems to me these files are more similar to files used in templates than parts of the interface, no? --Bsherr (talk) 18:00, 19 January 2011 (UTC)
Ok, removed then if people think there is a problem with this. Prodego talk 18:10, 29 January 2011 (UTC)
I think that's premature. Can anyone offer anything more specific about whether there actually is a problem concerning the licensing? --Bsherr (talk) 23:54, 30 January 2011 (UTC)
I agree it's premature. Since nobody offered anything specific, please revert to the accessible versions. If there are concrete concerns, please also revert the big icons, e.g. at WP:PP, because at the moment they are inconsistent. Thanks. (talk) 15:32, 12 February 2011 (UTC)
I don't see another solution. Their licensing is incompatible with our conventions for images we use where clicking on the image does not lead towords the imagedescription pages. The author has stated that he does not want to relicense them, and if we are really honest, any of those protection locks in the top right corner are too little to properly show these icons anyways. That's a lot of issues.... —TheDJ (talkcontribs) 15:42, 12 February 2011 (UTC)
Whatever is decided, can someone please make WP:PP and other pages consistent? (talk) 16:05, 12 February 2011 (UTC)
Wow. Someone reverted it? Really?! Wow. Just... wow. So now we're back to "fuck the colorblind?" I'm done. You can {{sofixit}} yourselves. Oh wait... apparently nobody will! Sad. --slakrtalk / 03:55, 15 February 2011 (UTC)
Also, just fyi, there are plenty of other non-public-domain-licensed images that are part of the site interface, including File:Cscr-featured.svg (lgpl), File:Wikipedia-logo-v2-en.svg (all rights reserved), File:Commons-logo.svg (all rights reserved), and the skin images used in mediawiki (gpl). Since they're part of the interface and aren't linked to the actual image page, you might want to go remove them from the interface and hunt those people down, too, so you can get them to make it all public domain. --slakrtalk / 06:13, 15 February 2011 (UTC)

Doc Page[edit]

Problem. Apparently someone replaced it with an advertisement with a link to a porn site, and this shouldn't be on Wikipedia. Being only a large contributor on other wikis, and not having an account for this version of MediaWiki, I don't feel that there's anything I really should do about it... So I'm bringing it to your attention. Thanks! (talk) 18:27, 30 June 2011 (UTC)

Hubdar Alighari[edit]

Janat me Janat k haqdar jayenge, Kasam ALI ki ALIk hubdar jayenge, Dar-e-Jana t pe khari Zehra A.S kehti hen, Janat me mereLaaL k Azadar jayenge — Preceding unsigned comment added by Hubdar alighari (talkcontribs) 16:18, 3 July 2011 (UTC)

Edit request 06:17, 4 December 2011 (UTC)[edit]

Please change <span class="plainlinks">[http://en.wikipedia.org/w/index.php?title=Special:Userlogin&type=signup <span style="color:#002bb8;" title="Sign in / create account">create an account</span>] to [[Special:UserLogin/signup|create an account]] because this link works, and the code looks cleaner. →Στc. 06:17, 4 December 2011 (UTC)

Seems uncontroversial.  Done — Martin (MSGJ · talk) 11:11, 4 December 2011 (UTC)

Templates on other wikis[edit]

Looking after another Wiki - there are several 'Templates' on the Wanted pages list, Pp-meta being the first on the list. The topic being 'very technical' is the simplest solution to have a mention linking to the relevant WP article? Jackiespeel (talk) 17:51, 7 March 2012 (UTC)

Dispute param[edit]

It seems that the dispute parameter is not listed in the usage, even though it's in the code...? - Penwhale | dance in the air and follow his steps 07:20, 20 July 2012 (UTC)

Translation issue[edit]


I am currently working on translating this template into the Malay Wikipedia here: ms:Templat:Pp-meta, but it seems that the text in this template won't work there, even if I directly copied and pasted the entire text into the editor and previewed - the preview will just be blank, other than the documentation, even after saving. Am I missing something that I have to do first? A prompt reply would be much appreciated. Thanks. Pizza1016 (talk | contribs | uploads | logs) 09:16, 26 December 2012 (UTC)

 Resolved: No furthur action is required. Pizza1016 (talk | contribs | uploads | logs) 15:58, 29 December 2012 (UTC)

Pending changes padlocks[edit]

Hi. Can we include the padlocks {{pp-pc1}} and {{pp-pc2}} to this template? For example, at "type" it should be added |pc1=Padlock-silver-light.svg and |pc2=Padlock-orange.svg. Both templates have errors because they are not using pp-meta as its main template, they are just padlock icons, and they cannot be diplayed like this. I don't know how templates work, if somebody could help this would be appreciated. Tbhotch. Grammatically incorrect? Correct it! See terms and conditions. 02:07, 9 January 2013 (UTC)

See comment on my talk, I'll (try to) start working on this when I get back in a week. Anyone is welcome to start working on it before then, if so, let me know and I'll see if I can help. Callanecc (talkcontribslogs) 09:07, 11 January 2013 (UTC)

Edit request January 2013[edit]

When users with Popups enabled mouse over a protection template, they are given a preview of the relevant section of the protection policy, and thus don't see any standard tooltips that could be useful to know about - for instance, a user with Popups has no immediate way of discerning if a silver lock is a generic {{pp-protected}}, a {{pp-vandalism}}, a {{pp-semi-sock}} or a {{pp-semi-blp}}. I believe that the solution is to simply change <div class="metadata topicon" id="protected-icon" style="display:none; right:55px;"> to <div class="metadata topicon nopopups" id="protected-icon" style="display:none; right:55px;">. I got this idea from {{top icon}}, where popups have been disabled for over 3 years. Anyone who's really curious about the protection policy can just click on the lock, so there's no real downside, and having the popups both deprives editors of pertinent information, and is also just pretty damn annoying to have all those previews jump up . — Francophonie&Androphilie(Je vous invite à me parler) 14:37, 12 January 2013 (UTC)

 Done -- WOSlinker (talk) 15:54, 12 January 2013 (UTC)

Follow-up request[edit]

After WOSlinker implemented the change I requested above, I wandered around the project a bit to make sure all the topicons were running as expected. I was surprised to find that {{pp-pc1}} and {{pp-pc2}} were still displaying popups. Now, I could just request that pp-pc1 be updated to reflect this change, but I assume that the reason pp-meta was created was so general protection template attributes could be changed with a single edit. So, I suggest that we integrate pp-pc1 into pp-meta. (Pp-pc2 is currently only used on one article [per an ad hoc decision at AN/I], so there's no reason to integrate it, especially as it's only semi-protected, so I was able to just revise it myself.) Amazingly, it took me so long to write this request that the number was up to four by the time I finished, but let's consider that a fluke.

I believe that this would be accomplished by making the following additions:

Whitelist to make topicon display
Topicon image
Topicon text
Topicon alt text

To my knowledge, no mbox has been created for pp-pc1, but I can draw one up and figure out how to integrate, if the admin who looks at this would like... I'm not really sure why exactly we have the mboxes, though, as I don't think I've ever seen one used (except for in the "creation protected" interface message, and on Damon Dash.)

So, if this change is implemented, the reviewing admin should then first (before editing pp-pc1) add a "pc1" anchor to WP:PP (the actual pending changes anchors are located at the end of WP:PP#Upload, to avoid an overly long section header). I've used "pc1" as the parameter name, instead of "pending", to avoid making things any more complicated than they already are if PC2 is ever adopted. While I can file another edit request at pp-pc1 after this, if this change is implemented and the said admin has an extra minute or two, I'd appreciate if they could also change {{pp-pc1}} to


|demospace={{{demospace|}}} |icon-reason={{{icon-reason|}}}
|categories={{{Categories|{{#switch: {{NAMESPACE}}
 | {{ns:0}}
 | {{ns:4}} = [[Category:Wikipedia pending changes protected pages (level 1)]]{{#if:{{{expiry|}}}|{{#ifexpr:{{#time:U|today}}>{{#time:U|{{{expiry}}}}}|[[Category:Wikipedia pages with incorrect protection templates|{{PAGENAME}}]]}}|[[Category:Wikipedia protected pages without expiry|{{PAGENAME}}]]}}
 | #default = [[Category:Wikipedia pages with incorrect protection templates|{{PAGENAME}}]]


  • As best I can tell, there is no Pending Changes equivalent of {{PROTECTIONLEVEL}}, making it impossible to set a disallowlevel parameter; however, as you can see, I have set it up so that if applied anywhere but the mainspace or projectspace, it will not display (see first change to pp-meta), and will be listed in Category:Wikipedia pages with incorrect protection templates, which is at least preferable to the status quo.
  • Also, Category:Wikipedia pending changes protected pages (level 1) is currently at CFD for renaming, but it's already been mentioned that pp-pc1 would need to be revised.
  • Oh, also, if all of this sounds like too much work, someone could just downgrade pp-pc1's own protection level to semi-protection, since it's only transcluded to like 200 pages at the moment.

I know this is rather detailed for an edit request, but this page has less than 30 watchers, and I don't think I'm suggesting anything particularly controversial - this is just to streamline any future changes to the protection templates, and to open up pp-pc1 to the full range of pp-meta parameters. (If it is felt to be too substantive to handle by edit request, I can raise the issue at VPT, but note that while this request is 11,923 chacters long, the actual changes in question are only 533... I had to use A LOT of <nowiki> and stuff to make all of this display property.) — Francophonie&Androphilie(Je vous invite à me parler) 16:08, 13 January 2013 (UTC) Minor improvement to pp-pc1 @ 18:46, 13 January 2013 (UTC)

Preview available at Template:pp-meta/sandbox. Preview of {{pp-pc1}} at Template:pp-meta/test4. (I've simplified the preview from the one suggested above to make it display and not miscategorize, but I've tried out the full version as well; see [2].) All Template:pp-meta/testcases appear non-borken. — Francophonie&Androphilie(Je vous invite à me parler) 16:23, 13 January 2013 (UTC)
  • Hey, &... I'd be happy to implement the changes but while I feel it's nothing groundbreaking or likely to be controversial, I'd still like a bit more discussion before diving in to enact the request. :) Salvidrim!  19:04, 21 January 2013 (UTC)
There is a magic word available for mw:Extension:FlaggedRevs, see [3]. ⁓ Hello71 15:33, 9 February 2013 (UTC)
  • Done I've implemented your changes, but using the {{PENDINGCHANGELEVEL}} magic word, and coding in support for pc2 and the mbox as well. I've also updated {{pp-pc1}} and {{pp-pc2}}. Sorry for the inordinately long amount of time this request has been sitting here for. — Mr. Stradivarius ♪ talk ♪ 16:49, 26 February 2013 (UTC)

Request for a check on the changes on Wiki-cy[edit]

An IP has changed this page on the Welsh Wiki. We usually don't allow IPs to edit Templates. Can someone check the changes and respond on my talk page as to whether this was Vandalism or a bona fide edit. Many thanks. Llywelyn2000 (talk) 17:52, 10 February 2013 (UTC)

Note on possible future functionality with expiry[edit]

I'm noting this here for the benefit of future functionality: if the request for a magic word returning protection expiry, at bug 17354http://bugzilla.wikimedia.org/show_bug.cgi?id=17354, is completed, we'll be able to compare the actual expiry set and the expiry that the template alleges. So we'll be able to create a category of pages with protection templates with incorrect expiry, e.g. template says protection expires on 16 December while the protection is in fact indefinite. Cenarium (talk) 16:26, 1 June 2013 (UTC)

Edit request on 25 August 2013[edit]

Make these changes. Note: Template talk:Pp-pc1#Edit request on 25 August 2013 should be done first to prevent overlapping of the icons in the interim period. Jackmcbarn (talk) 19:10, 25 August 2013 (UTC)

Done --Redrose64 (talk) 22:01, 25 August 2013 (UTC)

Update for template-protection[edit]

Request: Copy over the new code from the sandbox.

I've made changes in the sandbox so that template-protected pages can be distinguished from indef-protected pages (diff). Seems to work in the Template-protected sandbox and not break anything in the testcases page. After pp-meta is updated, {{pp-template}} can be updated to auto-detect the protection level and pass through the relevant information (code currently in its sandbox). Then template-protected pages will show the pink lock, instead of incorrectly showing the red lock.

Note that the pink padlock is used in the code, but this may need to be changed if consensus changes (straw poll had closed in favour of pink[4], but the close was reverted as premature. However, pink is currently used on WP:TPE and WP:TEMP-P) - Evad37 (talk) 04:20, 18 October 2013 (UTC)

I've made some bold changes to the sandbox, switching from "This is template-protected" to "This is a protected template" (or module), since I feel like "xyz-protected" is more for specific methods of protection, and while this is technically a new protection level, the goal is to switch all (or almost all) fully protected templates to it, so this doesn't seem quite the same. I had to fiddle with some of the parsers since this has a different sentence structure from the rest, and I also threw in some namespace parsing (including options for non-templates/modules, as test pages or whatever). Template-protected sandbox and testcases still working fine, and the namepsace parsing works according to a preview I did of Template:WikiProject Biography (through its doc page). Oh, {{pp-meta/pagetype}} needs updating to including modules; I'd just ask for the protection to be downgraded, and do it myself, but I believe it's cascaded as well. :/ — PinkAmpers&(Je vous invite à me parler) 11:56, 18 October 2013 (UTC)
I changed the default messages a wee bit. I made them identical for all namespaces, to say "This is an indefinitely protected {{pp-meta/pagetype}}, as it is high-risk". Protected-template will always be indefinite and always be for reasons of high-risk, regardless of namespace, so I figure this makes sense. See Template:Pp-meta/testcases, where I added a template protect test. I also changed the topicon text to match. equazcion 15:50, 18 Oct 2013 (UTC)
PS. I had closed the straw poll for padlock color (before it was reopened) once it became clear that pink was the favorite. I had only started that poll on padlock color to get some quick outside opinions, since the two or three of us as the discussion previously couldn't decide. It seems like WP:BIKE silliness at this point and was never meant to be an RFC-length debate. I think we can safely code in the pink now (as it is in the sandbox already), and if we really need to change it again later that can be still be done -- but I doubt it will be necessary. The consensus seems rather clear. equazcion 15:59, 18 Oct 2013 (UTC)
I've switched it from "indefinitely" to "permanently," since, at least the way we use those words on Wikipedia, I feel like the former generally means "no end date decided—maybe just for a bit, maybe forever, we'll see," whereas the latter means "not expected to ever end." Of course, "permanently protected" templates occasionally get deprecated and thus unprotected, but as long as the status quo is maintained, there's essentially 0% chance that the protection will be reversed... Unlike, say, indefinite semi-protection, which is often lifted after a few years to "test the waters."

Oh, and, yeah, and I agree that the color's unimportant. Unlike the rest of this stuff, it's very simple to change the image if there's a consensus to do so. — PinkAmpers&(Je vous invite à me parler) 16:41, 18 October 2013 (UTC)

All looking good there. I think this is ready to go now. Template:Pp-meta/testcases shows the result (the fourth box down). I created a sandbox of /pagetype as well to provide the addition of modules. So just for clarity, here's what needs to be done:
If anyone considering making these changes isn't clear on what they do, or on what needs to be done, please let us know. Thanks :) equazcion 21:02, 18 Oct 2013 (UTC)
Done. Thanks for all your efforts, and let me know if more tweaks need to be made. — Mr. Stradivarius ♪ talk ♪ 03:38, 19 October 2013 (UTC)

Tiny tweak[edit]

Thanks for making those edits, Mr. Stradivarius. Just one thing, it looks like we had an extra dot in the topicon rollover text, so now two dots are showing up after the message. I removed the redundant dot in Template:Pp-meta/sandbox, and changed Template:Pp-meta/testcases to show the sandbox's template-protect topicon. This is a pretty innocuous fix and I think it's safe to go for it (just removal of a character within a message, no real code changes). Thanks once again. equazcion 12:38, 19 Oct 2013 (UTC)

Done --Redrose64 (talk) 18:26, 19 October 2013 (UTC)

Protection level of pp-meta[edit]

Just noticed that pp-meta is actually template-protected, not full/indef protected. However, it is still cascade protected from Wikipedia:Cascade-protected_items. I will still leave the above discussion here so that wording/coding can be discussed, but perhaps Mark Arsten or another admin can also remove the cascading protection. - Evad37 (talk) 04:44, 18 October 2013 (UTC)
I've never done anything with cascading protection before, so I'll have to defer to a more experienced admin. Mark Arsten (talk) 04:49, 18 October 2013 (UTC)
Not done for now: I am very tempted to just do this myself, but it should probably wait until the discussion at Wikipedia talk:Cascade-protected items#Proposal that this page be unprotected has come to a conclusion. Or at least we should propose this template's unprotection at that page before actually going through with it. Or we can always do this the old-fashioned way by copying things across from the sandbox. :) — Mr. Stradivarius ♪ talk ♪ 04:59, 18 October 2013 (UTC)

Categories of incorrectly tagged pages[edit]

Currently, pages with incorrect protection templates are still placed into the categories passed into this template. I've added [5] to the sandbox to disable this. Can I add this to the real template, or will that break something I'm not thinking about? Jackmcbarn (talk) 01:58, 12 November 2013 (UTC)

Limited protection templates[edit]

I was thinking about the protection templates which can only be used for certain protection levels:

Given the pages are semi-protected during content disputes for that reason and that pages are fully protected from socks and for BLP vios. It's strange (to me anyway) that I can't use the protection template. I envisage doing something similar to Template:pp-vandalism. For those who know about how pp-meta works, is that possible? Callanecc (talkcontribslogs) 07:29, 7 January 2014 (UTC)

Actually, these templates are the "normal" ones. Templates that can detect multiple protection levels do so in spite of the coding in {{pp-meta}}, which only allows for detection of one protection level. I think this would all be handled much better if we had a much simpler system of protection templates, perhaps even just one, that could be set with |reason=dispute, |reason=blp, etc. We could also make it detect the protection level and set the correct image and category automatically. Rather than trying to force this into {{pp-meta}}, though, I think writing a new Lua module would be both simpler and give us better performance. We would need to make sure such a module works well with Twinkle, though, and with the bots that use protection templates. What do others think about this? — Mr. Stradivarius ♪ talk ♪ 13:11, 7 January 2014 (UTC)
I just tried pp-dispute on a semi protected page and it didn't work and the other two (including without "-semi") on a fully protected pages. I meant can we change them (or create a new ones, which seems the long way around) so they detect and work on different protection levels. I think having a template for protection due to disputes, vandalism, BLP vios, sockpuppetry plus a generic one which can have a reason set (for both template and icon) is an easier way to go about it. My personal opinion is that having a template with an easy name is easier to use than fiddling with parameters. Though I agree having one template would be easier to manage, and we can always call the parameters on pages with appropriate names (which will need to be done to grandfather in the current names anyway). Callanecc (talkcontribslogs) 13:29, 7 January 2014 (UTC)
I agree with Mr. Stradivarius. I think we should have a Template:Pp that calls a Module:Protection banner, which would be used as {{pp|vandalism|expiry=7 January 2014|small=yes}}. Jackmcbarn (talk) 16:57, 7 January 2014 (UTC)

Changes suggested at Template talk:Pp-dispute[edit]

There is currently a discussion at Template talk:Pp-dispute#Expanding template for semi protection (edit request) in which changes have been suggested to this template. Callanecc (talkcontribslogs) 04:43, 27 January 2014 (UTC)

Overlapping icons[edit]

I just noticed on pages that have multiple protections set, eg. semi edit protection and full move protection, only the last pp-template on the page shows in the top corner. This should be adjusted so that one of the following things happen:

  • Use Lua to detect multiple pp templates and off-set them automatically
  • Hard code a different offset for each level of template so they never overlap (will cause spaces or gaps)
  • Offer an |offset= parameter similar to |icon-nr= in {{Top icon}} so that an allowed user can shift the templates over

I'd like to hear some opinions before I start implementing any of these possibilities and see which one others like best or if there is something I hadn't thought of. Thanks! — {{U|Technical 13}} (tec) 16:19, 14 February 2014 (UTC)

@Technical 13: Doesn't the right= parameter do what you're asking for? (See the pending change templates, which use it by default). Jackmcbarn (talk) 19:22, 14 February 2014 (UTC)
  • That parameter is completely undocumented, and based on my tests it is only a boolean switch that puts that particular icon in one far corner of the screen or the other. Not what I had in mind at all. It can be set as |right=0 to achieve an effect similar to what I was looking for, but there is a noticeable gap between the icons, which is ... ick. — {{U|Technical 13}} (tec) 20:27, 14 February 2014 (UTC)
Though it is completely undocumented (my fault), it takes a pixel value. The default is 55px and the PC templates use 25px (the px suffix is required). Jackmcbarn (talk) 21:18, 14 February 2014 (UTC)
@Technical 13: Documented now. Jackmcbarn (talk) 21:20, 14 February 2014 (UTC)
@Jackmcbarn and Technical 13: Having an offset other than the default isn't a good idea, because different offsets are used for different icons such as the featured article star, etc. There is already a bug in this template where the pending changes icons overlap the speaker icon for articles with audio, which I'm planning to fix when the template gets converted to Lua. (See this VPT thread for more info about the bug.) It looks like the correct solution is to detect what the highest protection level is, and only display a padlock icon for that level, in the padlock's designated place among the different top icons. Pp-meta is the next template on my hit list, and work can begin on it now that the PENDINGCHANGELEVEL parser function accepts other pages as input (thanks Jack!), so hopefully this can be fixed soon. I'll make a rough draft of the data structure and post back here when I'm done. — Mr. Stradivarius ♪ talk ♪ 01:08, 25 February 2014 (UTC)
We do need multiple offsets sometimes. What if a page is both semi-protected and PC2 protected? Neither one of those is "stronger" than the other, and they both have an effect. Jackmcbarn (talk) 01:12, 25 February 2014 (UTC)
I agree with Jack, especially in cases where there is semi-edit protect and full move protection. These are different types of protections and as such neither can be "stronger" than the other. — {{U|Technical 13}} (tec) 02:07, 25 February 2014 (UTC)
(edit conflict) That's a good question. Ideally we would display both icons, but we don't have a lot of choice there if we want to avoid breaking the other top icons. I can think of three options:
  1. Just using the semi-protected padlock (easiest, but not ideal)
  2. Creating a new padlock icon (would require discussion, but easy technically)
  3. Creating a hack in {{top icon}} or related templates to allow two protection icons (would require a significant rethink of the top icon system, and there may not be space for all the icons on some articles anyway)
I'm leaning towards number one or number two, but if you can think of a good way to do number three I'd be interested to hear it. Also worth bearing in mind is the fact that when PC was activated on enwiki for good at the end of 2012, there was disagreement over whether we needed to have a PC icon at all due to the presence of the drop-down "accepted revision" menu. The {{pp-pc1}} template went to TfD over that, and the discussion was closed as "no consensus". Not that that should necessarily dictate what we do here, but I do think it suggests that the community attitude is that the protection icons are more important than the PC icons. — Mr. Stradivarius ♪ talk ♪ 02:18, 25 February 2014 (UTC)
  • Apparently Jack's {{{right}}} in {{pp-meta}} is the same as {{{extra_offset}}} in {{top icon}}. Using that it shouldn't be hard to set up the {{{icon-nr}}} in {{pp-meta}} and simply setting it to {{#expr:{{{icon-nr|1}}}*22}} which is the number of the offset times the width of the protection icon with 1px on each side for a margin. This means that the existing {{{right}}} parameter will be replaced with {{{right|{{#expr:{{{icon-nr|1}}}*22}}}}}{{U|Technical 13}} (tec) 02:39, 25 February 2014 (UTC)
(edit conflict) @Mr. Stradivarius and Technical 13: Changing div.flaggedrevs_short's right parameter from 80px to 100px in MediaWiki:Vector.css and from 55px to 75px in MediaWiki:Monobook.css will create enough room to allow "extra" protection icons to be placed to the left of the normal one, rather than to the right, allowing this problem to be solved. Jackmcbarn (talk) 02:43, 25 February 2014 (UTC)

──────────────────────────────────────────────────────────────────────────────────────────────────── That's a good way of fixing it. :) This is the kind of fix that will require discussion with a wider section of the community, though, perhaps at WP:VPR. It strikes me that the outcome of Wikipedia:Pending changes/Request for Comment 2014 could have a big impact on such a discussion - any news of when it might be closed? — Mr. Stradivarius ♪ talk ♪ 06:01, 25 February 2014 (UTC)

I just had a look to see which pages were affected by the overlapping icons bug. I came up with three: Humpback whale, Black and 0.999.... There are also two that have the spoken icon and are PC protected, but have had the protection template removed and are blocking Cyberbot II - Troye Sivan and Scott Mills. The problem isn't all that common, but I think you'll agree it looks really ugly when it happens. — Mr. Stradivarius ♪ talk ♪ 06:32, 25 February 2014 (UTC)
WP:VPR#Move Pending Changes dropdown in header 20 pixels to the left Jackmcbarn (talk) 19:51, 25 February 2014 (UTC)
The stylesheets were updated, and I moved the PC templates over to 85px from the right side of the screen. They no longer conflict with anything. Jackmcbarn (talk) 02:43, 4 March 2014 (UTC)

Lua protection category system[edit]

@Jackmcbarn: I've been doing some work on converting pp-meta to Lua, and I think I have a category-matching system that is both able to be adapted to the needs of other wikis, and also mimic how the daughter templates of pp-meta currently assign categories. It's at Module:User:Mr. Stradivarius/pp, and the test cases are at Module:User:Mr. Stradivarius/pp/testcases (run). This can probably be improved, so let me know if you can see any ways to improve it. Also, there are a couple of categories that I cheated on - see the bottom of the test cases page to see which ones don't work the same as the current templates. (Or at least, the ones that I know don't work the same.) — Mr. Stradivarius ♪ talk ♪ 14:53, 10 March 2014 (UTC)

The one thing that I see is commented out right now that I'd really miss is Category:Wikipedia pages with incorrect protection templates. Also, what's the logic behind the attempt order you picked? Is it just what was necessary to make it work like the old system, or is there more to it? Jackmcbarn (talk) 16:23, 10 March 2014 (UTC)
I was planning on checking for errors in a different function, so don't worry, that will be added later. As for the attempt order logic, there is more to it than just matching the existing templates, although I do admit that my code was a little hacky, and I skipped out some possible key combinations that I didn't think were likely on enwiki. I've changed the module to generate the order algorithmically, so the logic behind it should now be clearer. As a bonus, the function no longer creates any duplicate keys for properties that weren't specified, which should compensate for the increase in unlikely key combinations. Judging from the test cases, there are now an average of 3.8 category table lookups before a match is found. Take a look and see what you think. — Mr. Stradivarius ♪ talk ♪ 15:28, 11 March 2014 (UTC)
Looks good. Jackmcbarn (talk) 01:00, 12 March 2014 (UTC)

Move protection, but not admin-only[edit]

There are four levels of edit protection (none, semi, template, full), and our pp- templates seem to handle these OK. Similarly, there are four levels of move protection; however, the available templates seem to cater only for two levels of move protection - none, and full move prot. What is the correct template to use on an article which is indef move protected, but for non-autoconfirmed users only? If I use {{pp-move-indef}}, it puts the page in Category:Wikipedia pages with incorrect protection templates with no other action; if I use {{pp-move}}, it goes through {{pp-meta}} and is put in three cats: Category:Wikipedia pages with incorrect protection templates Category:Wikipedia move-protected pages Category:Wikipedia protected pages without expiry --Redrose64 (talk) 20:57, 23 May 2014 (UTC)

@Redrose64: Semi-protection for moves doesn't make sense, since you have to be autoconfirmed to move anything anyway. Template-protection for moves does appear to be a gap in the current system. @Mr. Stradivarius: Are you still working on overhauling these protection templates? If so, does your new system cover this case? Jackmcbarn (talk) 21:21, 23 May 2014 (UTC)
I haven't updated Module:User:Mr. Stradivarius/pp in a while, but I'm planning to get back to it. The idea is that it will be able to handle situations like this by adjusting the module settings, but the code isn't yet at the point where this actually works. — Mr. Stradivarius ♪ talk ♪ 00:08, 24 May 2014 (UTC)

Proposal to convert all protection templates to Lua[edit]

There is currently a proposal at Module talk:Protection banner to convert all of the protection templates to Lua. This would effectively make {{pp-meta}} obsolete. Please join this discussion over there if you are interested. — Mr. Stradivarius ♪ talk ♪ 00:53, 23 July 2014 (UTC)

I see this template is no longer in use. How about we clean up the remaining incoming links and delete this? -- [[User:Edokter]] {{talk}} 16:21, 11 December 2014 (UTC)
@Edokter: I fixed most of them. The vast majority of the remaining ones are from Template:Soft redirect protection. Jackmcbarn (talk) 17:42, 11 December 2014 (UTC)

Indicator tags[edit]

Jeeze -- you guys don't joke around. But wasn't the Top icon approach ultimately deemed "more trouble than its worth" and, as a result, was scrapped for indicator tags instead? -- George Orwell III (talk) 01:09, 14 December 2014 (UTC)

@George Orwell III: We do plan to switch to indicator tags. However, I don't really like the way indicator tags work right now, so I'd like to get some software changes through before we switch to them. Also, note that this template is obsolete, so you should make your changes to Module:Protection banner/sandbox instead of Template:Pp-meta/sandbox. Jackmcbarn (talk) 17:29, 15 December 2014 (UTC)
@Jackmcbarn: I'm almost afraid to know but... I have to ask; what is it that's not to your satisfaction? Not that we had anywhere near the usage en.WP does but I've already phased any use of the top-icon class or scripted approaches on Wikisource and am left wondering if that was a good idea or not now. TIA. -- George Orwell III (talk) 03:13, 16 December 2014 (UTC)
@George Orwell III: Nothing major, just things like phabricator:T76234 that are really annoying. Jackmcbarn (talk) 03:17, 16 December 2014 (UTC)
@Jackmcbarn: Forget 'nothing major' -- that's not even a valid issue. Please revisit phabricator:T76234. -- George Orwell III (talk) 05:12, 16 December 2014 (UTC)
I agree, that's a non-issue, especially since we use a templates (like {{top icon}}). And in the module it is even less of an issue, you can add/remove any linebreak you want. -- [[User:Edokter]] {{talk}} 08:43, 16 December 2014 (UTC)
Okay, I guess I can live with it. If you get it to work in the module sandbox, I'll have no problem with switching to it. Jackmcbarn (talk) 21:26, 16 December 2014 (UTC)
  • Question, would there be any support for moving away from using templates for this and towards an on-by-default gadget like User:Technical 13/Scripts/Gadget-pageProtectionLevels.js, which I started adapting from a fully working version I developed on DDOwiki.com which has fewer protection modes? — {{U|Technical 13}} (etc) 12:16, 16 December 2014 (UTC)
    • Personally, I don't like protection notices being dependant of JavaScript. -- [[User:Edokter]] {{talk}} 12:30, 16 December 2014 (UTC)
      I've been considering writing a MediaWiki extension to do this. Then it would work everywhere without the need for tagging, and it wouldn't be dependent on JavaScript. Jackmcbarn (talk) 21:26, 16 December 2014 (UTC)
        • That would be great and I would support that. — {{U|Technical 13}} (etc) 21:47, 16 December 2014 (UTC)