User talk:Wbm1058/Adding permalinks to block log entries

Adding permalinks to block log entries for 3RR

Thanks for your experiment with permalinks. See a proposed improvement at User talk:EdJohnston#Linking in edit summaries. EdJohnston (talk) 17:33, 16 December 2013 (UTC)

OK, I did the block, per the dummy case you created. See the permalink. Nice. How can you get those anchors to appear in front of all the 3RR complaints? :-) The permalink is going to the original complaint before the action was taken. The real case (after being closed) is at Wikipedia:Administrators' noticeboard/Edit warring#User:ThisIsaTest reported by User:Wbm1058 (Result: 24 hours). EdJohnston (talk) 19:40, 17 December 2013 (UTC)

To make this work right, the admin needs to (a) write the closure on the 3RR board with their summary, and save the page. Then (b) do the block. The permalink goes to the version of the page that existed when you hit 'Block.' EdJohnston (talk) 20:01, 17 December 2013 (UTC)

That's correct. I found one other issue I need to fix, then we can run another test. Wbm1058 (talk) 20:03, 17 December 2013 (UTC)

OK, I issued a block on the new test you just created. See the results at [1]. Then I removed the test report from the board (which actually simulates what will happen when a report is archived) and you still see the one that you want to see when you click on the permalink. Do you have a suggestion of what to do next? I'm not sure there would be general support for changing the commonly used userlinks. Maybe an admin could install a script that would enable some of this functionality, while leaving the board undisturbed for for other users. Thanks for your work, EdJohnston (talk) 05:02, 18 December 2013 (UTC)

Ed, I think we're ready to go live with this. Since I've added a parameter to {{userlinks}} I think it best to create a new application-specific fork of this template, which I've done: Wikipedia:Administrators' noticeboard/Edit warring/userlinks. This way other uses of {{userlinks}} and prior uses in this application will not be affected. We go live with the new permalinks feature simply by making the version of Wikipedia:Administrators' noticeboard/Edit warring/Example with edit summary "implement permalinks for user blocks" current. I don't see any potential controversy or downside to this. All the change does is pre-populate the other reason field in the user blocking form. As with technical move requests, if an administrator doesn't want to use the default permalink message in the reason field, they can simply replace it before clicking Block. I suspect that, as with technical move requests, most admins will just go with the default permalink message. If you agree, I'll flip the switch to make it live, and we can run a final in-production test to confirm everything is working right, and then post a notice at Wikipedia talk:Administrators' noticeboard and update the administrators' documentation. Wbm1058 (talk) 14:44, 18 December 2013 (UTC)

Why not let me try it out for a week in practice. I can call your new userlinks explicitly before saving each report. If no problems, let's propose the idea at WT:AN3 and see if there are any comments. EdJohnston (talk) 15:36, 18 December 2013 (UTC)

Sure, we can take a slower approach to full implementation. Just to be clear on the changes required to "flip the switch" on this, in this diff the left side shows the code needed to implement. One piece of this is a unique section anchor that is created (the number which is the current time stamp) when users "click here to create a new report", edit the form and save it. Those anchors are needed for the section linking to work. The anchors are invisible to readers and only seen in edit mode, and adding them should be harmless to the current system. The second part is the link admins click on to block editors. I created a beta version of my new Wikipedia:Administrators' noticeboard/Edit warring/userlinks which includes the normal "block user" link which is the current method, followed by a "beta" link which does the new permalinks. Would that be OK? Wbm1058 (talk) 16:49, 18 December 2013 (UTC)

It is often necessary to fix up incomplete or malformed headers on someone else's report. Unclear on how people will correctly fill in the 'Anchor' when they are trying a manual fix. EdJohnston (talk) 17:19, 18 December 2013 (UTC)

Good point. I added a comment to the preload file that loads when users click "Click here to create a new report" in the edit warring page header, warning them not to edit the anchor. Anyone bypassing the preload file to create their request won't have an anchor; I don't know how many editors would do that. Worst case, if there is no section anchor, then the permalink will just go to the top of the page. I realized that these section headers are edited, that's why I added the anchors as something more permanent to ensure that the section links would keep working after the section header text was changed. Wbm1058 (talk) 18:47, 18 December 2013 (UTC)

Another test: See last entry in my log. Though your change isn't 'live' yet I'm able to exercise it with two additional steps:

1. Insert '/' in front of userlinks, like {{/userlinks|Sample_user}}
2. Manually add {{anchor|28}} in front of the noticeboard header, where the '28' is the number from the TOC.

For clarity, I'd normally want to include the article name in the block reason. Will try to remember to do that next time. Also saw that the permalink can be cut-and-pasted onto the user's talk page for extra documentation, following the block notice. EdJohnston (talk) 20:44, 18 December 2013 (UTC)

Another example: [2]. EdJohnston (talk) 21:02, 19 December 2013 (UTC)

Proposal at User talk:Bbb23#Making 3RR actions more informative. EdJohnston (talk) 19:43, 22 December 2013 (UTC)

I've read the discussion at Ed's page and now the discussion here (well, skimmed the discussions is more accurate). I know much less about templates and coding than Ed. With that in mind, a few things stuck out for me. First, I don't block users from the userlinks template. My practice is to block the user in the normal way and then update the AN3 report with the result. Second, I'm a little unclear as to how dependent all of this is with an admin doing things in a particular way. What way does this have to be done to get the permalink? Is there more than one way? Does it matter if a report is generated with Twinkle? Finally, I don't have a clue as to what Ed means by the anchor and "tolerating its presence". In any response to me, please assume I'm clueless.--Bbb23 (talk) 16:38, 23 December 2013 (UTC)

My new template just "prepopulates" the normal block administrator-interface with the "other reason" field having a permanent link to the section of the noticeboard where the block was proposed. If you don't click on that template link then you won't get the permalink and you can continue to block editors as you always have. Instructions can be updated to explain this new (optional) feature. It's best to update the AN3 report first, and then do the block. That way the version with the updated AN3 report is seen when the permalink is clicked. You can block first, but then the permalink will show the older version of the AN3 report. {{anchor}} is a template added in the new system that just aids in directly linking to the applicable section on the noticeboard. Using anchors is also optional, but without them the permanent links will just go to the top of the AN3 report page. What Ed means by "tolerating its presence" is that these cryptic anchors would be part of the section titles and editors should just ignore them and not attempt to edit them. I put an edit comment around them to help ensure that happens. I was hoping to find a "magic word" that would let me link to the section immediately above the template, which would avoid the need to create these anchors, but I couldn't find anything. The pros to using permalinks are that it makes it easier to find historical block records, to research an editor's block history. The cons are that it makes it easier to find historical block records, if blocks are at some point to be "forgiven and forgotten" some time after a user corrects their bad behavior. I can also keep it optional to use the permalinks in the other reason field, by having separate block and block w/ permalink in the template to click on. Wbm1058 (talk) 17:22, 23 December 2013 (UTC)

Occasionally it may be necessary to research an editor's history. Quarrelsome people often clear out their talk page. Seeing an edit warring block in the log (from months ago) is not always informative, especially if the person was working on a variety of articles at the time. At a minimum, I think the name of the article in dispute should be in the log. It looks as though Bbb23 is one of the admins who always does that for AN3 reports. It would be even better to provide the link to a discussion if there was a simple mechanism to do that. If I'm the only admin who would use this system it's probably not worth any change in the noticeboard that others would notice. EdJohnston (talk) 03:35, 24 December 2013 (UTC)

@Wbm, thanks for the lucid explanation. I believe I understood it. Just as Ed has noticed that I put a wikilink to the article when I block someone for edit warring, I also noticed that Ed puts in a link to the AN3 section. I've never followed Ed's lead on that because I knew that once the section got archived, the link in the block log would be less useful (not useless, though). The proposal here would resolve that problem, and the only cost, as I understand it, other than a small learning curve, is the anchor in the section header. If this is implemented, I will use it, so that makes at least two administrators who would do so, and with a little of publicity and coaxing, others might do so.--Bbb23 (talk) 13:56, 24 December 2013 (UTC)

This is a new section header to permalink to

...so that I can explain how permanent links work by demonstrating a permalink to this section and use of the {{REVISIONID}} magic-word.

Cheers, Wbm1058 (talk) 18:35, 18 January 2014 (UTC)

Adding permalinks to block entries -- part 2

Hey Wbm1058. Can you take a quick look at my log and see what I'm doing wrong regarding permalinks? This is just a hacky thing I tried to do, where I compute the permalink myself and then try to type the right URL into the field of the blocking form. As you see the results do not look nice. The raw URL gets displayed in the block entry I create, instead of being concealed. When you do it (with your system) you get the word 'permalink' as a nice blue link. Thanks for any advice you can provide, EdJohnston (talk) 06:41, 18 January 2014 (UTC)

Hey Ed, I've been meaning to get back to you about #Adding permalinks to block log entries for 3RR, been juggling a lot of different projects lately. So you want to use the magic word {{REVISIONID}} to create custom edit summaries with permalinks? If you want to permalink to a revision that already exists, then you can just copy-paste it, for example, most editors know that

• [https://wiki.riteme.site/w/index.php?title=User_talk:Wbm1058&oldid=587393071#Adding_permalinks_to_block_log_entries_for_3RR old version]

gives this:

• old version

but there's another way to do it that involves just getting the REVISIONID number from the link:

• [https://wiki.riteme.site/w/index.php?title=User_talk:Wbm1058&oldid=587393071#Adding_permalinks_to_block_log_entries_for_3RR old version]

so this:

• [[Special:Permalink/587393071#Adding_permalinks_to_block_log_entries_for_3RR|old version]]

gives this:

• old version

which is the same link—the only difference is that the first one is done as an "external" link, while the permalink is an internal link. With the internal links you don't need to use the underscores instead of spaces, so this:

• [[Special:Permalink/587393071#Adding permalinks to block log entries for 3RR|old version]]

works too:

• old version

Now, what if I want to permalink the version I'm composing right now. I can't cut-paste the REVISIONID number as above, because it doesn't exist yet, and I can't compute or guess what it will be. Several editors are saving edits all over Wikipedia every minute, and each of their edits is assigned a new unique revision ID number by the MediaWiki software. That's where the "magic word" comes in.

Just for kicks, I'll create a new section just above this one with this edit, and permalink to that new section.

OK, here goes the test:

• This is an edit summary pointing to the [[Special:Permalink/{{REVISIONID}}#This is a new section header to permalink to|permalink]] on my talk page for this edit.

I'm just going to copy what's in boldface above from my preview screen and paste it to the end of my edit summary.

Remember that {{REVISIONID}} doesn't work in preview, so in this case, what I see in preview is not what I'm going to get!

This is what I see in my preview edit summary:

Preview of edit summary: (→‎Adding permalinks to block entries -- part 2: some copied from Eo ipso. This is an edit summary pointing to the [[Special:Permalink/{{REVISIONID}}#This is a new section header to permalink to|permalink]] on my talk page for this edit.)

I'll just take it on faith that it will work. Then I'll come back to see if it really worked.

And finish giving you and Bbb23 an easier way to do this at WP:AN3.

Hope this helps.

Cheers, Wbm1058 (talk) 18:35, 18 January 2014 (UTC)

Oh, yuk. That didn't work. Back to the drawing board. Wbm1058 (talk) 18:38, 18 January 2014 (UTC)

testing Wbm1058 (talk) 18:43, 18 January 2014 (UTC)

We can try out these options and then propose a change in Mediawiki to support what we need! :-) More likely to be accepted when we can submit a patch. EdJohnston (talk) 19:10, 18 January 2014 (UTC)

The problem with some of these obscure Mediawiki features is that is is so difficult to find good documentation. For one thing, the documentation is spread out over so many different projects. You have Help: and Wikipedia: on this project, but there's also Meta-Wiki, Media-Wiki and who knows what else. I still have trouble understanding the purpose of all these diffuse sources of info. Now I recall making this edit, and that was because this doc didn't say something that I found somewhere else in an almost redundant doc elsewhere (except that it added this useful tidbit). Now, I can't remember where I found that and can't find it anymore. Sigh. Now this is vaguely coming back to me, I think I figured it out in testing, never found this documented anywhere, but another restriction with {{REVISIONID}}, besides not subst:-able and not preview-able is that it doesn't work in bare wikitext, i.e., [[Special:Permalink/{{REVISIONID}}]] doesn't work either. No, it has to be encased in url-encoded {{fullurl:}}. See bug 5270 and m:Help:Parser function#URLENCODE. Looking at both the technical move requests and the block-user stuff I set up, I did it that way in both cases. So, let's try it again:

• This is an edit summary pointing to the [{{fullurl:{{Urlencode:[[Special:Permalink/{{REVISIONID}}#This is a new section header to permalink to|permalink]]}}}}] on my talk page for this edit.

No, now I'm thinking that this can't be done in a normal edit summary. You can't put external links in an edit summary, just wikilinks. The only places where I've seen this successfully used are at Special:MovePage and Special:Block. Both of those have special editor interfaces that do support (require) constructing fullurls. So I give up on doing this on normal talk pages. Wbm1058 (talk) 23:52, 18 January 2014 (UTC)

FWIW, I finally found the page m:Help:Variable that had that info.

{{REVISIONID}} showing the current unique revision number of a saved page as used for diffs in the page history is in essence useless, it can't be substituted and also doesn't work in preview.

"is in essence useless" LOL, at least we found a use for it at WP:RMTR! Wbm1058 (talk) 01:02, 19 January 2014 (UTC)

I guess I'll "spill some beans". I'm not entirely the guru who figured out how to make this REVISIONID/permalink stuff work. This 31 October 2009 edit by The Evil IP address was the big innovation of what had been a simple template. I just built on that and made it work on the sub-page. Hmmm, search their edit history to see whether they were making any other interesting edits around that time... B

• From an "editprotected" template:
  • You may click [{{fullurl:{{SUBJECTPAGENAME}}|action=edit&summary={{urlencode:Editing semi-protected {{pagetype|{{{1|}}}}} [[Template:Editsemiprotected|as requested]] by {{REVISIONUSER}}}}}} here] to perform the edit with an edit summary mentioning the edit request. Wbm1058 (talk) 02:15, 19 January 2014 (UTC)

You may click here to perform the edit with an edit summary mentioning the edit request.

That is most interesting. Maybe I'm on the trail now. Wbm1058 (talk) 02:15, 19 January 2014 (UTC)

UPDATE: That example did not last long before it was reverted. Nonetheless interesting from a technical standpoint. Maybe this didn't work on normal talk pages because, per mw:API:Edit#Token, I did not supply an edit token. – Wbm1058 (talk) 13:01, 18 May 2014 (UTC)

The fact that REVISIONID can't be substituted and doesn't work in preview sounds like understandable behavior. A preview page is not saved in the database yet, so it doesn't even have a REVISIONID (one assumes). EdJohnston (talk) 04:11, 19 January 2014 (UTC)

Hey! This seems to work. The wikilink I typed in the block reason field was this: [[Special:PermaLink/591416466#User:Jytdog.E2.80.8E_reported_by_User:FelixRosch_.28Result:_no_vio.29|Permalink]]. This creates a blue item called 'Permalink' in the block log and hides the raw URL. Now all I need is a script (or something) to be able to produce those wikilinks efficiently. Maybe an additional clickable word in your special userlinks template? Only catch is that the admin would have to close and save the 3RR report, and *then* click the special word and issue the block. EdJohnston (talk) 16:58, 19 January 2014 (UTC)

I'm glad you guys understand each other. I'm just gonna wait until you're all done and tell me how to do it and what its lilmitations are.--Bbb23 (talk) 17:14, 19 January 2014 (UTC)

Hey Bbb23. Just look at the block log of User:ThisisaTest. The last block entry (at 16:51) shows what I'm hoping to do. The entry says 'Edit warring: Permalink'. Try clicking 'Permalink' there. EdJohnston (talk) 17:23, 19 January 2014 (UTC)

testing

• click [{{fullurl:{{TALKPAGENAME}}|action=edit&summary={{urlencode:This is an edit summary pointing to the [[Special:Permalink/{{REVISIONID}}#This is a new section header to permalink to|permalink]] on my talk page for this edit.}}}} here] to perform the edit with an edit summary
• click here to perform the edit with an edit summary

bump. this is a test. Wbm1058 (talk) 18:19, 19 January 2014 (UTC)

OK, Ed, the test just above basically worked. First I saved the "click here" link and then I came back and clicked on it; that put the permalink to the previous edit into my edit summary. I found the documentation for the MediaWiki application programming interface at MW:API, specifically MW:API:Edit which lists the parameters you can feed into the "edit" command. This stuff is mostly useful for bot programmers, but also has some limited use in templates like {{RMassist}} and the block-user template I've been working on. So, here's a status update:

• To include the edit adding Blocked to the page in the permalink, that edit must be done before actually blocking the user. That's not really any different than the behavior at WP:RMTR; it's just that with the move requests, rather than go back and add a  Done message, the request is just removed from the page.
• I already have a solution ready, that works the same as the technical move requests to permalink the desired version of the whole Wikipedia:Administrators' noticeboard/Edit warring page. I didn't feel that it was necessary to section-link the move requests because that list rarely grows to a size where section-linking would be really helpful for finding the specific request.
• The issue is that we've been looking for a more elegant way to section-link the block-user requests. You had reservations about putting {{anchor}}s in the section headings. One option might be to just cut-paste the section title into the permalink, after the template has done the hard part, which is inserting the REVISIONID. Note that the API does have a parameter:
  • section: Section number. 0 for the top section, 'new' for a new section. Omit to act on the entire page
• which allows me to specify the number of the section that I want to edit. But there is no {{SECTION}} variable that I can find, which would tell me what the number of the section is that I'm currently editing. So the problem is that while I call provide the permalink with a section number, I don't know how to determine what the correct number to feed to the permalink is. That's why I came up with creating an anchor for this purpose; when I create the anchor then I have created an alternative hidden section title, which should never be changed.
• How about if I pull the anchor out of the section title and move it to the line immediately above the section header? That way the header itself stays the same. Like this. And instead of call it a beta test, just add a new link "permalink" like this: Wikipedia:Administrators' noticeboard/Edit warring/userlinks. So everything is the same except "block user with permalink" is a new item on the menu.
• I have to take a break for a while, but if you're agreeable, how about later today when we're both online, I make this live long enough so that we can run a quick "live" test using that test-user that we love to block. If any issues after the quick test, I can quickly revert to the current version. Wbm1058 (talk) 15:47, 20 January 2014 (UTC)

Testing in User:EdJohnston/Sandbox

• I tried out your new preload, and it works. See the results in User:EdJohnston/Sandbox, where I have created a miniature 3RR noticeboard of my own, with just one entry. The only modifications were:

1. I had to cut and paste the special version of the preload file, called Example which you created, and
2. I had to manually edit the 'userlinks' template in my Sandbox to replace it with 'Wikipedia:Administrators' noticeboard/Edit warring/userlinks'.

You can observe the successful creation of a permalink in the block log of the long-suffering user ThisIsaTest. Now that this can be tried out in a user sandbox, maybe we can persuade an enthusiastic volunteer (such as User:Bbb23) to try it out on his own and see if it works for him. There is a benefit to not having to modify the 3RR noticeboard for these tests. That way you don't have to look foolish in public. EdJohnston (talk) 01:39, 21 January 2014 (UTC)

Yes, but even those sandboxes are public if someone wants to look at them, just less public.

To do a really robust test using sandboxes, you would need to create sandboxes for the whole environment. Your sandbox test didn't subst: the anchor. But we already tested that in December (when the anchor was part of the title, not on top of it), and I believe it worked. Wbm1058 (talk) 02:31, 21 January 2014 (UTC)

For the anchor to be properly created the editor must enter the report from Wikipedia:Administrators' noticeboard/Edit warring by using "Click here to create a report". If the report is created manually or some other means, perhaps using Twinkle, then the anchor for section linking likely won't work. But that's not a really big problem; just that the permalink will only go to the top of the page rather than a specific section. So to more fully sandbox test you would need a sandbox version of Wikipedia:Administrators' noticeboard/Edit warring also. Wbm1058 (talk) 02:42, 21 January 2014 (UTC)

Your preload has CURRENTTIMESTAMP twice. Is there any way to get rid of one of them, for example put it inside the userlinks template? EdJohnston (talk) 02:44, 21 January 2014 (UTC)

The first CURRENTTIMESTAMP, when substituted, creates the actual anchor. The second CURRENTTIMESTAMP is a new second parameter being fed into the userlinks template to tell it what section to link to, i.e., that anchor which is the substituted CURRENTTIMESTAMP. Wbm1058 (talk) 02:55, 21 January 2014 (UTC)

This is probably the best I can do. If I knew the {{SECTION}} somehow, I could just pass that as parameter 2 to my custom userlinks, and then I would not need to create the anchor. Wbm1058 (talk) 03:08, 21 January 2014 (UTC)

From December, here is the test that showed how the anchor worked.

== {{anchor|20131217192533}} [[User:ThisIsaTest]] reported by [[User:Wbm1058]] (Result: 24 hours) ==

'''Page:''' {{pagelinks|This is a test}} <br />
'''User being reported:''' {{userlinks/sandbox|ThisIsaTest|20131217192533}}

<!-- In the section below, link to a version from before all the reverting took place, and which proves the diffs are reverts by showing material the same or similar to what is being reverted to. -->

"20131217192533" is the anchor, which is just the date/time when the request was entered. The anchor is only visible in edit mode and the custom userlinks template is transcluded so you don't see the date/time there either, except in edit mode. Wbm1058 (talk) 03:50, 21 January 2014 (UTC)

From reading Wbm1058's comments subsequent to Ed's ping of me, it looks like you're not ready for me. If I'm wrong, please ping me again, and I'll try to help.--Bbb23 (talk) 08:26, 21 January 2014 (UTC)

Yeah, we're getting close. The template code to automatically generate a permalink has been solved by Wbm1058. The remaining question (IMHO) is whether the preload file is getting too ugly and will confuse ordinary civilians who are trying to follow the directions. It's already about 8 out of 10 on confusing and the question is if it is getting more so. Probably I am too much worried about this, and if we just went ahead and changed the preload file it would go through harmlessly. It occurs to me that WP:Article Wizard is a nice example of how to support new people trying to go through the steps of a confusing procedure. This would allow us to step the new submitters of 3RRs through a process and give them advice along the way. But that might take us too far afield. In the interim, a process that lets the hipper admins use permalinks if they want to would certainly be worthwhile. Wbm1058 has been pointing out that my sandbox test is not quite kosher, but I might fix that with two more hours' work. EdJohnston (talk) 17:45, 21 January 2014 (UTC)

I just took a quick look at Wikipedia:Article wizard and that system with a lot of Q&A that guides users on a path through sub-pages looks interesting. I haven't really looked at a lot of the beginning-editor oriented help pages much, and some good ideas for enhancing other areas I support like requested moves and merges might be found there. I'm spreading myself thin here (editors are pleading for action at Wikipedia talk:Merging#Merge the MERGE!) so I don't really want to spend too much more time on this now. Maybe later. We could just implement the permalinks without any section linking, or we could try upping the confusion level from 8 to 9 and if that causes too much of a mess in practice, then back off to the simpler version. Probably won't know if there will be too-much-confusion-to-be-practical until we just try it for a while. Your call, Ed. Wbm1058 (talk) 18:13, 21 January 2014 (UTC)

In a previous reply you suggested a more complete sandbox test. I've done so at User:EdJohnston/Sandbox, which now shows a modified version of the 3RR noticeboard header. It also has a link called 'Click here to add a new report'. Unfortunately, clicking on that opens an edit buffer with nothing preloaded:

https://wiki.riteme.site/w/index.php?title=User:EdJohnston/Sandbox&action=edit&section=new&preload=User:Edjohnston/Sandbox/Example&editintro=Wikipedia:Administrators%27_noticeboard/Edit_warring/Editintro

Maybe preloading doesn't work in user space. EdJohnston (talk) 19:50, 21 January 2014 (UTC)

I found the problem. It was just a typo. Those can be easy to overlook. Wbm1058 (talk) 22:36, 21 January 2014 (UTC)

Adding permalinks to block entries -- part 3

Thanks for finding the problem! It all seems to work now. If I wrote it up, I could explain to User:Bbb23 how to do the test. Till then, it is of interest to notice that you already use anchors in the WP:RMTR system:

*{{anchor|movereq-Egyptian Constitution of 2014}} '''[[:Egyptian Constitution of 2014]] → {{no redirect|Constitution of Egypt}} {{#ifeq:{{FULLPAGENAME}}|Wikipedia:Requested moves/Technical requests|([{{fullurl:Special:MovePage|wpOldTitle={{Urlencode:Egyptian Constitution of 2014}}&wpNewTitle={{Urlencode:Constitution of Egypt}}&wpReason={{Urlencode:Requested at [[WP:RM]] as uncontroversial ([[Special:Permalink/{{REVISIONID}}|permalink]])}}&wpMovetalk=1}} move])|([{{fullurl:Wikipedia:Requested moves/Technical requests#{{anchorencode:movereq-Egyptian Constitution of 2014}}}} move (@subpage)])}}''' – Only historical constitutions should have "of YEAR#". The current constitution should be located at "Constitution of COUNTRYNAME" without a qualifier. [[User:Article editor|Article editor]] ([[User talk:Article editor|talk]]) 22:23, 19 January 2014 (UTC)

Of course, the anchors cause no confusion here because the user doesn't have to edit the wikitext while filing their report. EdJohnston (talk) 01:31, 22 January 2014 (UTC)

Oh, yes, right. I think those anchors were put there by someone else. At one time that list got pretty long because requests weren't immediately removed after processing. I didn't permalink the anchors there to minimize the risk that the edit summary would overflow its maximum allowed length. Wbm1058 (talk) 02:21, 22 January 2014 (UTC)

See User:EdJohnston/Sandbox#What this page is for. This explains how admins can exercise the sandbox and (if they wish) issue a trial block of the dummy account User:ThisIsaTest. Unfortunately non-admins won't be able to see if the test succeeded or not because Mediawiki won't even show them a block form. I left a note for User:Bbb23 so he can try it out if he wants. EdJohnston (talk) 03:29, 22 January 2014 (UTC)

Bbb23 has tried out the system. His reaction is at User talk:Bbb23#Testing of 3RR board changes is now open in my Sandbox. EdJohnston (talk) 19:33, 23 January 2014 (UTC)

A small glitch is visible when you edit the 3RR report just above one that was created with an anchor tag. (Though reports are added to the board from the top down they may be edited or closed in any order). Try going to WP:AN3#User:STATicVapor reported by User:Rushton2010 (Result: Protected) and hit the small edit button to the right of the section header. You'll see the anchor tag for the report below sitting at the bottom of the edit window. Maybe people can ignore this? EdJohnston (talk) 01:31, 28 January 2014 (UTC)

Actually it doesn't matter if an anchor tag gets accidentally deleted or archived apart from its 'parent' report. The anchor is only used one time, if is used for making a block log entry. After that it doesn't matter. EdJohnston (talk) 01:33, 28 January 2014 (UTC)

Oh, I see. You manually added that anchor. Keep in mind that I put a comment message on that line advising editors to just ignore the anchor and leave it alone. Right, if it's just above the section header, then logically it becomes the last line of the previous section. Or, I can embed it into the section header itself, which was my original way of doing the anchors. It can be done either way. And correct, after the section is permanent-linked, then it doesn't matter what happens to the anchor as at that point it has served its purpose. Wbm1058 (talk) 02:12, 28 January 2014 (UTC)

2017 Followup

See User talk:Wbm1058/Archive 5 (first section) —Preceding undated comment added 05:17, 23 April 2017 (UTC)