Module talk:Protected edit request: Difference between revisions

Broken links

The {{edit protected}} and {{edit semi-protected}} templates used to set an anchor {{anchor|editprotected}} immediately before the box; this was useful because the lists at User:AnomieBOT/PERTable and User:AnomieBOT/SPERTable contain links to that anchor - see this edit, where the link [[Template talk:Infobox requested#editprotected|request]] is in the second added line. These links are now broken. I would fix it myself, but I can't find my way through the Lua code: there is something that looks like it's supposed to add an anchor, in the form of function box:exportAnchors, but I can't work out why that's not happening. --Redrose64 (talk) 14:07, 24 November 2013 (UTC)

The anchors are working for me from User:AnomieBOT/PERTable and User:AnomieBOT/TPERTable. I changed the template on Template talk:Infobox requested from {{edit protected}} to the new {{edit template-protected}}, which will have caused links in the history of User:AnomieBOT/PERTable to stop working. If you use [[Template talk:Infobox requested#edittemplateprotected|request]] it should work. (Here's the link: request.) Are any of the anchors from the live PERTable lists not working, or is it just ones in the history? — Mr. Stradivarius ^{♪ talk ♪} 14:31, 24 November 2013 (UTC)

Yes, they appear to be working now. --Redrose64 (talk) 16:37, 24 November 2013 (UTC)

Protection detection

The module also attempts to detect the protection level of the pages used, and if any pages have a different protection level from the function specified it adds the page to Category:Wikipedia edit requests possibly using incorrect templates.

Instead of populating an error category, why not just choose the appropriate function based on the protection level? — Martin (MSGJ · talk) 19:17, 27 November 2013 (UTC)

Because we can't do it accurately. The module can't detect when something is on the title blacklist, and it can't detect when a page is cascade-protected. It would put such pages into the category for whatever protection level is returned by {{PROTECTIONLEVEL}}, even though actually only admins can edit them (or template editors for the title blacklist). If this becomes possible to detect on the MediaWiki side then we should probably do as you suggest, and indeed this is how I wrote the code originally, so it would be trivial to switch it back and add the new protection detection. Having some pages categorised wrongly probably outweighs the benefits of being able to get the protection level for most pages, however. — Mr. Stradivarius ^{♪ talk ♪} 21:49, 27 November 2013 (UTC)

The bot can accurately detect the protection level, so perhaps the best solution is to remerge the categories and leave the bot to update the two tables. Then editors will be able to use {{editprotected}} on both types, without having to worry about using the correct template. — Martin (MSGJ · talk) 10:51, 28 November 2013 (UTC)

It's three tables now. Besides the long-established User:AnomieBOT/PERTable and User:AnomieBOT/SPERTable, User:AnomieBOT/TPERTable was set up a few days ago. --Redrose64 (talk) 11:37, 28 November 2013 (UTC)

Yes, it was actually the PER and TPER tables that I was referring to (although it could apply to SPER as well.) I'm not seeing any advantages in having separate templates and separate categories for full- and template-protected pages. And in fact there are disadvantages because editors now have to choose between more templates and reviewers have to monitor more categories. So my proposal is to let the bot maintain the three tables but use a common template. — Martin (MSGJ · talk) 12:52, 28 November 2013 (UTC)

Your suggestion would definitely be easier for most editors to understand, and I have already seen a fair few mistakes with the new protection templates. We would have to rethink the way we layout the categories to make them easy to access for patrollers at all permissions levels, but that's not such a bad thing in my opinion. Anomie, what do you think? — Mr. Stradivarius ^{♪ talk ♪} 04:20, 29 November 2013 (UTC)

How is one template going to result in pages being in two different categories, so the bot can divide them into different tables? Anomie⚔ 16:06, 29 November 2013 (UTC)

I think Martin is suggesting that you reprogram the bot so that it chooses which table to put a page in depending on the protection level it detects. So all the pages would be in the same category, and the bot would do the work of sorting them into tables by protection level. It's completely up to you whether you want to go through with it, of course. — Mr. Stradivarius ^{♪ talk ♪} 17:31, 29 November 2013 (UTC)

Then where would the two tables be displayed? It would make more sense to me in that case to have one PER table but to color the template-protected rows differently (suggestions as to the coloring welcome). Anomie⚔ 20:29, 29 November 2013 (UTC)

Yep, color coding would work as well. Having two separate tables and transcluding them both to the category might be slightly more flexible, because template editors might choose to tranclude it to their userpage or whatnot. I don't really mind, both would be an improvement on the current situation. — Martin (MSGJ · talk) 12:34, 2 December 2013 (UTC)

Poke, Anomie. Any more thoughts on this? — Martin (MSGJ · talk) 12:51, 12 December 2013 (UTC)

No new thoughts. Do we have a consensus on how exactly it should be changed? Anomie⚔ 14:19, 12 December 2013 (UTC)

I don't we think we have consensus for any method yet. (Wish this could have been discussed before implementing though.) When I get some time I'll advertise this in a couple more places and see what others think. — Martin (MSGJ · talk) 20:23, 15 December 2013 (UTC)

Handle full URLs passed as pages to be edited

At [1], a full URL was given as a page to edit instead of just a page name. Would it be simple to make this change the URL back into a page name, or otherwise handle it? Currently, it leads to things like [2] happening, which isn't very pretty or accurate. @Mr. Stradivarius: ping. Jackmcbarn (talk) 22:57, 4 December 2013 (UTC)

It's very rare, and we can't guard against every mistake - somebody will always do something unexpected. Just fix it when it happens, which I see was done (but there's still a whole slew of empty <ref></ref> causing a sea of red). --Redrose64 (talk) 23:18, 4 December 2013 (UTC)

In addition to being a rare error, it's also possible for a URL to be a valid page title (e.g. [3]). That kind of title is rare enough that it probably wouldn't matter (and would probably be moved then deleted under G6), but I think we should probably support all titles allowed by MediaWiki. That kind of page title breaks the double-square-bracket syntax though (see [[4]]). This means we'd have to update the bot to support them properly, but I'm not sure that it matters enough to fix. — Mr. Stradivarius ^{♪ talk ♪} 00:07, 5 December 2013 (UTC)

Meh, I should fix the bot anyway. It is already applying the colon trick to File- and Category-namespace pages, but I forgot there are other cases. Anomie⚔ 02:03, 5 December 2013 (UTC)

last revision links

I tried to add a link for the last revision of the page and the last revision of the sandbox if it exists, but it doesn't seem to have worked... Can someone more familiar with Lua fix it and tell me what I missed so I can learn? @Theopolisme and Mr. Stradivarius: maybe? Technical 13 (talk) 20:51, 3 January 2014 (UTC)

Your code's working fine - see [5]. Perhaps this was what you forgot? — Mr. Stradivarius ^{♪ talk ♪} 21:30, 3 January 2014 (UTC)

Fully detecting all forms of protection

A magic word to detect cascading protection is already merged and will be usable here soon. My next project is going to be to set up a magic word to detect titleblacklist protection. Once we have this, this module will be able to detect the protection level of all pages with 100% accuracy. At that point, will we be able to remove Category:Wikipedia edit requests possibly using incorrect templates and have it just automatically use the correct version of itself? Jackmcbarn (talk) 17:02, 7 January 2014 (UTC)

That would be awesome. That's the conclusion that we came to above, and the module code will be able to handle it with minimal tweaking. The only reason the module isn't doing that right now is because it isn't currently technically possible. So, the answer to your question is a big "yes". :) — Mr. Stradivarius ^{♪ talk ♪} 17:09, 7 January 2014 (UTC)

Okay, it's written and waiting for approval. gerrit:105979 Jackmcbarn (talk) 18:11, 7 January 2014 (UTC)

Jack, can you expand your magic words to have a JavaScript wgVar attached for cascading and titleblacklist (and antispoof I suppose wouldn't hurt for those trying to create user pages of users that can't exist)? This would be useful in assisting any script that would check for protection levels and display some text or do something differently (I had an example case use last night I wanted it for, but have forgotten it now)... Thanks if this is possible. Technical 13 (talk) 17:51, 9 January 2014 (UTC)

I think that would be too expensive to check for every page. Jackmcbarn (talk) 17:54, 9 January 2014 (UTC)

Jack, I'm just asking for an addition to the ,"wgIsProbablyEditable":true,"wgRestrictionEdit":[],"wgRestrictionMove":[], section of mw.config.set section that is on every page. I would say if it is cascade protected, titleblacklisted, or antispoof, then wgIsProbablyEditable should be changed to false if it isn't already. Also, would be good to add "cascade", "titleblacklist", "antispoof" to ,"wgRestrictionEdit":[], if those restrictions apply (I wouldn't expect them to prevent a move, so no need to put them there I wouldn't think). Is that doable? Technical 13 (talk) 19:03, 9 January 2014 (UTC)

I mean actually checking to see whether a page is cascade-protected or on the titleblacklist is expensive. That's why you see "Edit" links instead of "View source" links for them, because MediaWiki doesn't check until you actually try to edit it. Jackmcbarn (talk) 19:04, 9 January 2014 (UTC)

Jack, isn't that check now already being made with the availability of {{CASCADINGSOURCES:Foo}}? So, does it really add any load to change the existing variables to include this information? Technical 13 (talk) 19:53, 9 January 2014 (UTC)

{{CASCADINGSOURCES}} isn't really a variable. Think of it more as a function. On pages that don't use it, it isn't calculated at all. It might be feasible to check it all the time, but you'd have to ask the server guys about that (and right now they only know it as the thing that causes all the fatal errors [long story]). Jackmcbarn (talk) 19:58, 9 January 2014 (UTC)

Implementation

@Mr. Stradivarius and Technical 13: The titleblacklist detection functionality got accepted and will be live here on the 6th. While we're waiting for that, how do we want to implement the autodetection? Obviously, if someone uses {{edit protected}} when they first create a request on a semi-protected page, we'd want to just display the semi-protected request banner instead. What about the trickier situations, though?

1. What if someone submits an edit request while the page is fully protected, but the protection level later drops or expires? Should we downgrade the template, or leave it as-is so someone can stick {{subst:EP|nlp}} on it (if appropriate)?
2. What if someone submits an edit request for a page that's not protected at all? Should we pretend like they used {{request edit}}?
3. What should we do with answered edit requests? We clearly don't want them changing. Should I try implementing my polymorphic solution here?

There's probably other questions that need answered too. Thoughts? Jackmcbarn (talk) 22:24, 30 January 2014 (UTC)

My two yen:

1. It would be best to keep the template at the protection level it was originally detected as, so that requests still make sense if the protection level changes. I'm not sure if this is technically possible without making users subst the template though.
2. I'd say put them in an error category rather than put them in the {{request edit}} category. COI edit requests tend to stick around for a long time without being answered, and most often the editor just forgot to fill in the page name in the template. For example, if someone makes a protected edit request for {{cite web}}, they are redirected to Help talk:Citation Style 1, and Help:Citation Style 1 isn't protected. We want this kind of mistake to be flagged for fixing rather than buried in the wrong queue. Also, we might see similar kinds of mistakes where the redirect's subject page is protected, which could prove problematic. It won't be so bad if the original page is semi-protected and the target's subject page is template-protected or fully protected, as those queues tend to be dealt with fairly quickly. But if the request is for a fully protected or template-protected page and is detected as a request for a semi-protected page, the error might not be noticed for a while. Not sure if there's anything we can do about that, short of updating the preload text code in MediaWiki to take a "page" parameter.
3. I'd prefer keeping things simple here. How about just using the same code for all answered edit requests? We could maybe make a special "answered edit request" icon, and think of some text that would work with all protection levels. We should probably also structure the code so that answered requests don't detect the protection level, as that will make the template calls relatively cheap. Some pages have a lot of answered edit requests - see Talk:List of social networking websites/Archive 7, for example.

That's it for now, but I'll let you know if I think of anything else. — Mr. Stradivarius ^{♪ talk ♪} 23:48, 30 January 2014 (UTC)