ಮಾಡ್ಯೂಲ್ ಚರ್ಚೆಪುಟ:Protection banner

Too enterprisey

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

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

Taking stock

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

@Mr. Stradivarius: A few thoughts:

• The Config class should go away and be replaced with a table that's effectively a singleton instance of what it used to be.
• The getBannerConfig function should become part of the Protection class.
• All of the functions that look like "function Foo:getBar() return self:_bar" should go, and the members should be made "public". (This is getting back to the issue of not being overly enterprisey.)
• Why not use the __tostring metamethod instead of the render method?
• I don't think we need a Category class. I think a makeCategoryLink function would do just as well.
• In line with the above entry, ProtectionCategory should go, and the work it does in :render() should instead be Protection:getCategory() or something.
• The other subclasses of Category should also be changed to individual functions.

That's all I see for now. Let me know what you think of those ideas. Jackmcbarn (talk) 22:19, 27 June 2014 (UTC)

@Jackmcbarn: Thanks, those suggestions make a lot of sense. I was also wondering about turning the getter methods into public properties, so I'll start by converting those. I agree with moving ProtectioCategory:render to the Protection class - should the functions for ErrorCategory, ExpiryCategory and TemplateCategory be moved there too? They all need protection data and title data, so it seems like a good fit. Moving the getBannerConfig to the Protection class and simplifying the Config class is a good idea, but I think we should keep some kind of mechanism to allow specifying an arbitrary table in place of the data in Module:Protection banner/config. That way, we can write the test cases using customised config tables, and we won't have to worry about them breaking if someone updates the main module config. — Mr. Stradivarius ^{♪ talk ♪} 01:20, 28 June 2014 (UTC)

@Mr. Stradivarius: I changed Config so it just uses the raw table from mw.loadData everywhere. This will work for testing by just passing some table other than the loadData result in when the objects are first created. Jackmcbarn (talk) 01:49, 28 June 2014 (UTC)

@Mr. Stradivarius: Okay, I'm done editing now, so there shouldn't be any more ECs. Anyway, yes, I do think the other category classes should get moved into Protection. Jackmcbarn (talk) 02:06, 28 June 2014 (UTC)

@Jackmcbarn: Thanks. :) I'll start work on converting the other stuff, then. — Mr. Stradivarius ^{♪ talk ♪} 02:12, 28 June 2014 (UTC)

@Jackmcbarn: I've finished making all the changes you suggested above. Let me know if you think of anything else. — Mr. Stradivarius ^{♪ talk ♪} 14:23, 28 June 2014 (UTC)

@Mr. Stradivarius: I found a few more changes that I made myself. I have three concerns left, though:

• It looks like whatever was supposed to call Padlock:setRight never got written, so the protection icons will overlap.
• I don't really like the way the properties table is being used inside Protection:makeProtectionCategory.
• Now that title and bannerConfig are part of Protection, can they be removed from Blurb?

Once those are all resolved, I think we're ready to move onto testing and deployment. Jackmcbarn (talk) 22:33, 28 June 2014 (UTC)

@Jackmcbarn: All done:

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

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

@Mr. Stradivarius: If we make testcases for the config at all, then I agree that's where they should go, but I'm not sure if that's necessary at all. Also, something I just noticed looking at the code today is it seems like there's a lot of code that exists only to support {{Pp-create}} et al., but those are unused and have been deprecated in favor of salting for a long time, so I don't think it's worth supporting them. Jackmcbarn (talk) 18:30, 29 June 2014 (UTC)

(I see that those are sometimes used in create-protection reasons, but since you recently changed MediaWiki:Titleprotected to not display them anyway, I don't think it's worth worrying about.) Jackmcbarn (talk) 18:43, 29 June 2014 (UTC)

@Jackmcbarn: Thinking about it, I agree that we shouldn't make too much effort for {{Pp-create}} when it isn't actually being used here. And indeed, I've just altered it so that all it displays is a template link, and I've taken the check for it out ofMediaWiki:Titleprotected. That way, people will be able to see it in the protection message, and it won't insert a protection banner inside another protection banner. However, I don't think we should make "create" an invalid action altogether, as other wikis might want the functionality. We can allow other wikis to have creation banners by just enabling "create" as an action, and allowing them to add text for them in the banners and defaultBanners config tables, without making the code much more complex. — Mr. Stradivarius ^{♪ talk ♪} 07:13, 30 June 2014 (UTC)

Even if we did allow create as an action, it still wouldn't work right, since a page that exists cannot be create-protected, and Module:Effective protection level won't lie by saying it is, so the pages would just end up in ವರ್ಗ:Wikipedia pages with incorrect protection templates anyway. Jackmcbarn (talk) 17:05, 30 June 2014 (UTC)

@Jackmcbarn: It would have to be used through MediaWiki:Titleprotected on that wiki. I had a search, and Simple English Wikipedia and Chinese Wikipedia are currently using {{Pp-create}} in this manner. I suppose we could just recommend that they update their message syntax to match enwiki's, though. — Mr. Stradivarius ^{♪ talk ♪} 01:38, 1 July 2014 (UTC)

@Mr. Stradivarius: That brings up a debate that I don't think we've had yet. I'm not sure if we should be making our modules support things that are of no use to us just because they'd be of use to another wiki. (To me, that would be a step beyond things like separating config and localization from the code, which I'm perfectly happy with.) Jackmcbarn (talk) 01:45, 1 July 2014 (UTC)

@Jackmcbarn: Fair enough. I suppose if another wiki really wanted a pp-create equivalent, we could always go and implement it over at that wiki. So let's leave create-protection out here, and wait to see if anyone complains. :) The debate over how much we should support will probably be more relevant if/when we get a global module repository. — Mr. Stradivarius ^{♪ talk ♪} 02:09, 1 July 2014 (UTC)

Error messages

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

I guess that will work for now. My plan for later is to make script errors display the message right on the page, and only hide the stack trace behind a click. Jackmcbarn (talk) 17:05, 30 June 2014 (UTC)

I was also having similar thoughts. I originally thought of adding a third parameter to the Lua error function that turned the error into plain wikitext, but I like your idea much better. — Mr. Stradivarius ^{♪ talk ♪} 01:41, 1 July 2014 (UTC)

@Mr. Stradivarius: Now that Lua errors are displayed right on the page here, I've removed the pcall code. Jackmcbarn (talk) 03:22, 3 October 2014 (UTC)

Thanks for that. :) — Mr. Stradivarius ^{♪ talk ♪} 05:07, 3 October 2014 (UTC)

Config for doc

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

And the same for the Documentation class. Jackmcbarn (talk) 02:59, 1 July 2014 (UTC)

Good idea. I'll move them to Module:Protection banner/documentation and Module:Protection banner/documentation/config. — Mr. Stradivarius ^{♪ talk ♪} 03:05, 1 July 2014 (UTC)

@Jackmcbarn: How about the new "description" fields in cfg.banner? Moving them to a submodule would be a little awkward. — Mr. Stradivarius ^{♪ talk ♪} 03:08, 1 July 2014 (UTC)

@Mr. Stradivarius: Good question. For now, I guess just move the class and leave the config alone, and I'll try to figure something out once it's done. Jackmcbarn (talk) 03:11, 1 July 2014 (UTC)

More templates

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

Now that you mention that, I notice that you currently hardcode most/all of the reasons (dispute, office, reset, vandal) into the main module. I think we should be able to completely specify these from the config module with no special code needed in the main module at all. Jackmcbarn (talk) 15:33, 1 July 2014 (UTC)

I did consider using the algorithm from Protection:getProtectionCategory to generate the banner config fields as well, but I was worried that it might make things overly complicated. Some banners would need four or five different text values to cover all the possibilities. But then again, there is probably a simpler way to do things. If you have any ideas for how the config tables should work, let me know. — Mr. Stradivarius ^{♪ talk ♪} 15:43, 1 July 2014 (UTC)

Since this module generally won't be ran more than once per page (except for things like its own documentation and test cases), I don't see a reason to use mw.loadData() on the config. If we changed that to require(), we could move some of the business logic there. Jackmcbarn (talk) 16:04, 1 July 2014 (UTC)

@Jackmcbarn: Using require wouldn't be too onerous, I agree. Quite a few pages use two protection templates, e.g. {{Pp-dispute}} and {{Pp-move-indef}}, or {{Pp-vandalism}} and {{Pp-pc1}}, but it's rare to see three (and I think those get fixed by the bots). I've tried to imagine how moving the business logic to the config module would work, but I can't quite picture it. What did you have in mind? — Mr. Stradivarius ^{♪ talk ♪} 06:50, 2 July 2014 (UTC)

@Mr. Stradivarius: My idea: See if the things like cfg.banners.edit.dispute.text are strings or functions. If they're strings, treat them as you do now, but if they're functions, pass in the Protection object and args, and use the function call result as the output. Jackmcbarn (talk) 03:29, 3 July 2014 (UTC)

No wrapper?

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

@Jackmcbarn: It meant that Template:Pp-vandalism/sandbox didn't allow any parameters to be set, because the module was only checking the frame args and not the parent frame args. — Mr. Stradivarius ^{♪ talk ♪} 03:13, 5 July 2014 (UTC)

I see now. I see a possible shortcoming in Module:Arguments there, actually. I'll think some more about it. Jackmcbarn (talk) 03:18, 5 July 2014 (UTC)

MediaWiki namespace

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

@Mr. Stradivarius: I've thought about this before too. The current system doesn't use that, cascading protection, the titleblacklist, or anything at all except the normal protection level. Maybe we shouldn't use Module:Effective protection level at all here, instead just using title:protectionLevels. Jackmcbarn (talk) 04:21, 10 July 2014 (UTC)

@Jackmcbarn: I'd say we need to detect at least cascading protection, as it will be useful for templates whose cascading protection level and normal protection level don't match. We also need {{PENDINGCHANGELEVEL}} for the pending changes banners. The rest might not be important for our purposes, but with three different things to detect I'd say we should probably stick with using Module:Effective protection level for ease of maintenance. — Mr. Stradivarius ^{♪ talk ♪} 04:37, 10 July 2014 (UTC)

@Mr. Stradivarius: In that case, I'd just not do anything special about it, since pages in the MediaWiki namespace generally don't contain protection templates anyway. Jackmcbarn (talk) 04:40, 10 July 2014 (UTC)

Deployment

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

@Mr. Stradivarius: I think everything's ready to go, but I'm not sure how you want other users to test this. Jackmcbarn (talk) 18:11, 22 July 2014 (UTC)

Wow, you really don't like Module:Middleclass, do you? :) Still, it's not important. I'll invite others to look at this - watch this space. — Mr. Stradivarius on tour ^{♪ talk ♪} 22:50, 22 July 2014 (UTC)

@Mr. Stradivarius: It's not that I don't like it; it's that I don't think it's necessary in a lot of cases. I admit it's useful for things such as mixins, but here it isn't, since I was able to get rid of it adding virtually no new code. (My "ulterior" motive is the job queue.) Jackmcbarn (talk) 02:50, 23 July 2014 (UTC)

Proposal to convert all protection templates to use this module

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

2

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

Sounds, thanks for doing this! They look really good. Just one question, would it be possible to have them automatically query and display the expiry date (doing away for the need of the expiry parameter)? I'm not sure that there is a magic word which will give that but I thought it was worth asking as you guys know MediaWiki a lot better than I do. Callanecc (talk • contribs • logs) 00:48, 23 July 2014 (UTC)

No, not currently. It wouldn't be hard to add this to the module if this functionality becomes available in MediaWiki in the future, though. — Mr. Stradivarius ^{♪ talk ♪} 00:56, 23 July 2014 (UTC)

Thanks, Mr. Stradivarius it looks good to me. One other thing I think needs to be changed, whenever pp-template/sandbox is called and used with indef full protection, it should call the red lock rather than the gold one, which is what pp-template does now. See User:Callanecc/sandbox (for /sandbox version) and User:Callanecc/sandbox2 for current version. Callanecc (talk • contribs • logs) 01:12, 23 July 2014 (UTC)

@Callanecc: I've fixed this in the module now. — Mr. Stradivarius ^{♪ talk ♪} 02:55, 23 July 2014 (UTC)

@Callanecc: I do plan to add expiry detection to Scribunto in the near future. Jackmcbarn (talk) 02:51, 23 July 2014 (UTC)

Also, some pings for potentially interested parties: Cyberpower678, Σ, Tizio, Redrose64, MSGJ, Technical 13. — Mr. Stradivarius ^{♪ talk ♪} 01:00, 23 July 2014 (UTC)

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

• I'm not sure what improvement this offers, but I don't oppose it. Callanecc}, hopefully I'll get a little free time next week to work on a userscript of mine that might interest you. It will display the protection icons (whether the page has the template or not) in the personal toolbar and mouseove will offer the expiration. Once it is done I'll leave you a note and you can try it out. Maybe if enough people think it is a good idea we can add it as a gadget and the pp templates would only be used for categorizations in the future if needed. Anyways, it's 1 am and I'm exhausted. — {{U|Technical 13}} ^{(e • t • c)} 05:14, 23 July 2014 (UTC)

  The Lua version detects protection levels automatically for all banners, and performs better than the old wikitext templates. Those are the two big advantages to enwiki. A third is that it's now easily customisable for other wikis and other languages. And a fourth is that no coding should be necessary to add new banners - all that will be needed is to update the configuration. — Mr. Stradivarius ^{♪ talk ♪} 05:34, 23 July 2014 (UTC)

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

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

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

@Mr. Stradivarius: {{Pp-semi-indef}} shows the whole banner on pages instead of just the lock if the small parameter isn't set, but this wasn't needed before conversion. This needs to either fixed, or someshould add this parameter to many-many pages. Armbrust ^{The Homunculus} 19:33, 5 August 2014 (UTC)

@Armbrust: Well-spotted - this edit should have fixed it. — Mr. Stradivarius ^{♪ talk ♪} 19:37, 5 August 2014 (UTC)

@Mr. Stradivarius: One aspect of the recent edit has messed up the "expiry" parameter. Whether you type August 15, 2014 or 15 August 2014, it always displays at "15 August, 2014". You can see an example at Teenage Mutant Ninja Turtles (2014 film). Sock (tock talk) 11:59, 8 August 2014 (UTC)

@Sock: Actually, the old templates didn't vary the output like that either - you got the same date formatting whether you typed "August 15, 2014" or "15 August 2014". What they did do was have consistent MDY formatting, whereas the module was set to use DMY formatting. I've switched it to MDY formatting in line with the old template system. — Mr. Stradivarius ^{♪ talk ♪} 13:39, 8 August 2014 (UTC)

@Mr. Stradivarius: I actually didn't know that, my bad. Thank you for fixing the formatting! Sock (tock talk) 13:54, 8 August 2014 (UTC)

@Mr. Stradivarius: For the templates that you added small=true as a wrapper option to, it's now impossible to display the large version of them, since wrappers currently overrides the passed parameters. I've written a (currently failing) test case for this. Jackmcbarn (talk) 02:20, 10 August 2014 (UTC)

@Jackmcbarn: Ah yes, I see {{Pp-template}} used to allow large banners, but the default was small. The question is, do we want to allow overwriting of all parameters or just some of them? If we allowed overwriting all the parameters then editors could use a template for something completely different than its original purpose, e.g. {{pp-move-vandalism|dispute|action=edit}}. On the other hand, I doubt that many templates would get misused in that way, so it might not be worth worrying about. What are your thoughts? — Mr. Stradivarius ^{♪ talk ♪} 12:54, 10 August 2014 (UTC)

@Mr. Stradivarius: I think we should just let all parameters be overridden for simplicity. I don't think it's worth the trouble to stop edge cases that will probably never happen. Jackmcbarn (talk) 15:59, 10 August 2014 (UTC)

@Jackmcbarn: Ok, I've updated the sandbox to let all parameters be overridden. (I made a tweak to the test cases as well.) Does that look ok to you? — Mr. Stradivarius ^{♪ talk ♪} 16:45, 10 August 2014 (UTC)

@Mr. Stradivarius: Looks good to me. Jackmcbarn (talk) 17:06, 10 August 2014 (UTC)

I've updated the module. — Mr. Stradivarius ^{♪ talk ♪} 17:26, 10 August 2014 (UTC)

Misleading icons and text

Moved from Wikipedia:Village pump (idea lab)/Archive 14#Misleading icons and text: Redrose64 (talk) 10:24, 5 September 2014 (UTC)

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

The example page has since been 'fixed', but obviously the problem I described remains. --82.136.210.153 (talk) 19:37, 6 September 2014 (UTC)

The problem isn't in these templates. It happens because even though semi-protection makes PC1 redundant, it doesn't automatically cause PC1 to be removed. If we want to, though, we could hack around this by bailing out of the autoreview=autoconfirmed case if edit=autoconfirmed. (And we might as well also bail out of autoreview=reviewer if edit=sysop if we do that.) Jackmcbarn (talk) 19:49, 6 September 2014 (UTC)

I've just implemented a change that does that, so this should be fixed now. (If you see any pages where it's not fixed, purge them.) Jackmcbarn (talk) 21:14, 6 September 2014 (UTC)

Thanks Jackmcbarn. --82.136.210.153 (talk) 21:28, 6 September 2014 (UTC)

Use of pp-template in template sandboxes

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

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

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

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

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

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

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

IMO, the best way to fix this would be to replace {{Pp-move-indef}} with {{Documentation}}, even if the template has no doc page. Jackmcbarn (talk) 14:21, 18 September 2014 (UTC)

It's not {{pp-move-indef}}; it's {{pp-template}}. --Redrose64 (talk) 15:26, 18 September 2014 (UTC)

@Redrose64: Oops. My solution is the same though. Jackmcbarn (talk) 15:28, 18 September 2014 (UTC)

It seems a bit strange to use that method to fix Template:Documentation/core/sandbox, Template:Documentation/core2/sandbox, Template:Documentation/end box2/sandbox, and Template:Documentation/start box/sandbox. --Redrose64 (talk) 16:58, 18 September 2014 (UTC)

Template talk:Permanently protected is in Category:Wikipedia pages with incorrect protection templates; it shouldn't be, because the single use of {{pp-template}} has |demolevel=semi which prior to the Lua-isation, prevented the page from being categorised inappropriately. --Redrose64 (talk) 20:40, 3 October 2014 (UTC)

I've fixed that by using |category=no for the moment. Is this enough of a problem that the demolevel parameter needs to be re-added? For the test cases, it's enough to use internal Lua functions to simulate protection levels rather than doing it from a parameter that would have to be checked every time. — Mr. Stradivarius ^{♪ talk ♪} 15:52, 4 October 2014 (UTC)

I agree that what you did is a good fix. We shouldn't re-add demolevel. Jackmcbarn (talk) 02:21, 5 October 2014 (UTC)

Wikipedia:Template messages/Maintenance is also in Category:Wikipedia pages with incorrect protection templates because of these eight lines:

{{Tlrow|pp-dispute|demolevel=sysop}}
{{Tlrow|pp-vandalism|demolevel=autoconfirmed}}
{{Tlrow|pp-vandalism|demolevel=sysop}}
{{Tlrow|pp-protected|demolevel=autoconfirmed}}
{{Tlrow|pp-protected|demolevel=sysop}}
{{Tlrow|pp-sock|demolevel=autoconfirmed}}
{{Tlrow|pp-move|demolevel=sysop}}
{{Tlrow|pp-office|demolevel=sysop}}

- we need to demonstrate the templates without improper categorisation. --Redrose64 (talk) 23:00, 13 October 2014 (UTC)

I hadn't thought of that use. @Mr. Stradivarius: I guess we do need to re-add demolevel to get those to display right. Jackmcbarn (talk) 03:10, 14 October 2014 (UTC)

Fair enough, let's add it back in. That should be an easy fix. — Mr. Stradivarius ^{♪ talk ♪} 03:27, 14 October 2014 (UTC)

Ok, I think this should be all that's needed. I've changed all of the protection template sandboxes to point to the module sandbox, so you can try out the new code with {{Pp-vandalism/sandbox}}, etc. It seems to be working ok on Wikipedia:Template messages/Maintenance - Jackmcbarn, does this look ok to you? — Mr. Stradivarius ^{♪ talk ♪} 03:44, 14 October 2014 (UTC)

@Mr. Stradivarius: Looks like that will work to me, and I added one other fix related to it. One thing I'm wondering is whether or not setting demolevel should cause any special behavior of categories. (Did it before?) Jackmcbarn (talk) 04:06, 14 October 2014 (UTC)

@Jackmcbarn: I see that pp-meta did with the code you added back in February, but I looked in the old versions of pp-template, pp-dispute and pp-vandalism and they just treat it like a normal protection level. (I haven't checked all of the others yet.) I think makes the most sense to have demolevel produce the same categories as a real protection would - otherwise you couldn't consider it a true demonstration. Unwanted categories can always be suppressed with |category=no. — Mr. Stradivarius ^{♪ talk ♪} 06:52, 14 October 2014 (UTC)

@Mr. Stradivarius: I guess that will work then. Jackmcbarn (talk) 15:38, 14 October 2014 (UTC)

Ok, I've updated the module. — Mr. Stradivarius ^{♪ talk ♪} 21:49, 14 October 2014 (UTC)

and Wikipedia:Template messages/Maintenance is no longer in Category:Wikipedia pages with incorrect protection templates, which is good. But it is in seven other cats: Category:Wikipedia pages protected due to dispute; Category:Wikipedia protected pages without expiry; Category:Semi-protected project pages; Category:Protected project pages; Category:Wikipedia pages semi-protected from banned users; Category:Wikipedia move-protected project pages; Category:Wikipedia Office-protected pages. Not sure if that's good or bad. --Redrose64 (talk) 23:59, 14 October 2014 (UTC)

@Redrose64: We already support category=no to fix that, but it's not getting used there for some reason. Jackmcbarn (talk) 00:00, 15 October 2014 (UTC)

I've added |category=no to those templates. If there are any other demonstration templates out there, they can be fixed in the same way. — Mr. Stradivarius ^{♪ talk ♪} 06:05, 15 October 2014 (UTC)

pp-template and move protection

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

@Callanecc: It will be soon, but we're waiting for a software change before we can easily do it. Jackmcbarn (talk) 14:16, 29 September 2014 (UTC)

pp-semi-indef

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

@Callanecc: Not yet, as we currently can't detect protection expiry dates from Lua. However, Jackmcbarn has added the patch for this to Gerrit, so we might have this functionality soon. — Mr. Stradivarius ^{♪ talk ♪} 10:04, 12 October 2014 (UTC)

Thanks Mr. Stradivarius, can it not show and trigger the category if the page is full protected? Callanecc (talk • contribs • logs) 11:16, 12 October 2014 (UTC)

@Callanecc: Not at the moment - that would require a rewrite of the protection code and the config. That's something that we will need to put on the list of fixes for when this gets rewritten. — Mr. Stradivarius ^{♪ talk ♪} 12:13, 12 October 2014 (UTC)