personally I don't see the point of Richard's template. I would suggest that automating the merge procedure would be a much better bang for the buck than further perfecting the automated RM procedure, particularly as the algorithms for mulit-move requests and proposed merges are similar and proposed merges are such a mess -- some of them have been around for may years. -- PBS (talk) 00:11, 13 January 2013 (UTC)[reply]
His template could be used to eliminate some redundancy and in my opinion is more elegant than harej's solution for archiving closed RMs. Eventually I would like any similar solutions for merges to be implemented consistently with the RM solutions. But, yes, further teaking here need not hold up some temporary solutions for merges, since that's such a mess... Wbm1058 (talk) 15:52, 14 January 2013 (UTC)[reply]
I am missing knowledge of what harej's solution is, and why it is thought necessary. Surly to close a RM one just uses {{poll top}}. Why is anything else needed? -- PBS (talk) 18:02, 15 January 2013 (UTC)[reply]
Actually you should use the more specific {{subst:RM top}}. The old and new page names are included as parameters in {{requested move/dated}}. Closing instructions call for removal of {{requested move/dated}}. It needs to be removed so the bot doesn't pick it up, as the bot looks for transclusions of that template. So, to keep a record of the old and new page names in the archived section on the talk page, harej created {{subst:Requested move}}, which creates the {{requested move/dated}} template, and redundantly writes a list of old and new pages outside of the /dated template, so the list will still be there after /dated is removed. Now, if instead of removing it, we simply change its name to {{requested move old}}—or {{requested move/old}}—voila, now we don't need to write the redundant list outside the template. The redundancy can cause issues, when an editor corrects their typo or changes their mind about what the new name should be, they need to make the change in two places. – Wbm1058 (talk) 21:52, 15 January 2013 (UTC)[reply]
It looks like the bot was confused after this edit. There is a second, redundant place where corrections of this sort need to be made, and I covered it here. I'm aware of this issue and eventually may simplify the templates to remove this redundancy. Wbm1058 (talk) 23:32, 17 February 2013 (UTC)[reply]
This seems to be some one-off glitch—I've not seen this bug before. It may be a side-effect of some other issue, and could be hard to track down. Wbm1058 (talk) 13:43, 19 March 2013 (UTC)[reply]
Whatever the bug is, it is causing a wholesale overwrite of the entire talk page, from what I can see, it deletes the entire talk page, and replaces it with the new notice. -- 65.92.180.137 (talk) 06:18, 20 March 2013 (UTC)[reply]
Excellent observation! It could be something more like this type of problem. I'll put it on my list to check the code to see if any edit checks can be made to prevent it. Wbm1058 (talk) 15:14, 20 March 2013 (UTC)[reply]
I think I finally realize the cause of this (an API function's failure to retrieve the page content when asked), and will get right to implementing the solution, which is to not update the page at all rather than break it. Wbm1058 (talk) 20:15, 13 December 2014 (UTC)[reply]
Not fixed yet. The bot needs to be able to tell the difference between a page that has no content because it doesn't exist (normal), and a page which appears to have no content (but probably really does) because the server was down or bits got lost on the Internet. Wbm1058 (talk) 14:44, 15 December 2014 (UTC)[reply]
I think the move template – not the discussion, or the decision – should be removed when discussion is closed. The same thing happened with an RM I posted some weeks ago. Remind the closing editor. HandsomeFella (talk) 18:42, 1 April 2014 (UTC)[reply]
Closure of talk page entries for a multi-move request?
When a multi-move request is approved, should a bot be closing the entries that were placed on all of the talk pages? Cf. Omega1 Aquarii. Just curious; it seems odd to leave inquiry messages dangling out there. Regards, RJH (talk) 22:21, 11 August 2012 (UTC)[reply]
A note to optionally do this (leave a terse note) could be added to Wikipedia:Requested moves/Closing instructions, along with the notes to update or add {{Oldmoves}}, {{Old RM multi}} or {{Oldmove}}. There is no transcluded template or category flagging these messages, so once the RM is closed it would be hard for a bot to find them. The closing instructions are getting pretty complicated, so a possibility would be to see if a new program could be created to assist this closing process. – Wbm1058 (talk) 16:30, 27 September 2012 (UTC)[reply]
Notifying talk pages that are named in multi-move requests
It's nice that the bot can be used to notify talk pages that are named in multi-move requests. What is needed is a follow-up notification to those talk pages that reports on the result of the request. 67.100.127.30 (talk) 19:45, 15 November 2014 (UTC)[reply]
An editor, presumably unintentionally, removed the template, effectively "closing" the discussion as far as the bot was concerned. I've reverted that template removal, so the notice should be re-posted in a few minutes. wbm1058 (talk) 17:41, 29 August 2017 (UTC)[reply]
Someone recently inserted an RfC into an open RM. While version 7.52 (19 August 2021) now allows insertion of a single line between the section heading and {{Requested move/dated}} (e.g. {{notavote}}), in this case there are two lines after Legobot adds a "User:DoNotArchiveUntil", and RMCD bot still flags multiple inserted lines as a malformed request. Figuring out how to make the regex that supports two or more inserted lines is harder than you might think, at least for this guy who doesn't use regex often enough to become super proficient with it. Since the RfC was reverted anyway, I'm just keeping this on my back burner as a low-priority item. – wbm1058 (talk) 21:39, 21 March 2022 (UTC)[reply]
If you are uncertain about what the new page names should be, then you should use the "?" form of request, as demonstrated in the last example in Wikipedia:Template messages/Moving/Requested. The bot reads the template parameters and uses those only to generate the listings at WP:RM. You can do whatever you want with the list of moves which is shown outside the template, as the bot doesn't care about or look at those. wbm1058 (talk) 00:09, 25 February 2017 (UTC)[reply]
No, the {{requested move/dated}} transclusion on that page was properly formatted showing only one target, and the bot failed to properly skip over the list shown outside the request. As you can see here, the bot included by proposed alternate title as if it were part of the reason. Pppery01:08, 25 February 2017 (UTC)[reply]
OK, the bot was trying to skip over all that and jump to the reason, but a couple of curve-balls tricked it. (1) the bot is looking for an en-dash as the separator indicating where the reason starts. Now, it knows enough to ignore false-positive en-dashes when they are included inside the standard-formatted request. Since your "or this–alternatives" were outside of the expected standard formatting, the first one found was interpreted as the beginning of the reason. Then you get a mangled reason because inside the reason are what appear to be more standard-formatted requests that the bot strips out of the reason. This is all tricky regex to implement and I don't know regex like the back of my hand. I'm not going to attempt to support this, because it is theoretically impossible to create an RM in this format. The idea behind using {{subst:requested move}} is to prevent unsupported syntax in requests, but of course I can't stop editors from hacking up perfectly well-formatted requests after their initial creation. Suggest you use {{subst:requested move}} to create a "name to be determined via discussion" request, and then put your list of alternatives in a separate section below your brief rationale for the move request and your signature. Thus, the discussion of alternatives will only be seen on the talk page hosting the discussion and not get copied to the WP:RM page. wbm1058 (talk) 02:41, 25 February 2017 (UTC)[reply]
Which would take up a lot of unnecessary space, considering the request involves over 100 articles. Would it make sense for the bot to ignore en-dashes in links? Pppery02:45, 25 February 2017 (UTC)[reply]
I'm not keen on huge proposals like this. Maybe you could start a more general discussion about the naming conventions on the talk page for the relevant naming conventions or WikiProject? If you can get a consensus on naming conventions, then perhaps these become technical requests. wbm1058 (talk) 03:07, 25 February 2017 (UTC)[reply]
At 14:20, 25 December 2017, rather than revert Nardog, I made bot version 6.55 accommodate the removal of the dash from multiple move requests in Module:Requested move (thanks for calling me in to work on the holiday!)
At 22:08, 19 January 2018 Ppperyreverted Nardog's change: "seems to break bot parsing for users who have a dash in their signature"
@Wbm1058: I noticed something is still wrong with the patch. Namely, Talk:CMY (disambiguation) was not actually created with the WikiProject on it. Please try to identify the error with the code that causes this, and fix it. Also, if page A is being requested to be moved to B, page B currently redirects to a disambiguation page C other than page A, and page C does not already have a talk page, then the bot should place {{WikiProject Disambiguation}} as well while creating the talk page for page C. This did not happen with Talk:Tremont Avenue (disambiguation), for example. GeoffreyT2000 (talk) 04:37, 24 August 2019 (UTC)[reply]
Done in v 6.92 – it's always easier to make a fix while an RM is open, as that provides a use-case for testing. I verified the patch with Talk:Tremont Avenue (disambiguation). However the Talk:CMY (disambiguation) wasn't easy to reproduce. I found that with most move requests of this nature the bot doesn't post a notice (i.e. it doesn't create a new page) as there is no point in creating a notice for a page with no content. So I dug a little deeper to see what was happening here. This request was created by an editor who seemed unware of disambiguation policies and conventions, and who failed to follow the instructions for starting an RM via {{subst:Requested move}}. The bot didn't pick up the request until another editor added a section header for it. At the time the "content" that made the bot decide that a notice was needed was a fork of CMY, which was later changed to the {{r to disambiguation page}} that should have been there all along (and would not have had a talk page notice created for it). So, given the cause of the issue was user error, and the user error didn't break anything significantly, I'm not going to try to accommodate this now; very low-priority issue. If there's anything for the bot to do here, I think it should be able to recognize the existence of a disambiguation fork, and report that as an error, while refraining from creating the Talk:CMY (disambiguation) page that the user error triggered. – wbm1058 (talk) 21:08, 26 August 2019 (UTC)[reply]
To be clear, the discussion was there (and open) in the archive, although it was showing up as a malformed request on the RMC page. When I reverted the bot, I also deleted the empty archive as G6, routine cleanup. Dekimasuよ!05:29, 13 March 2018 (UTC)[reply]
Thanks, I stand corrected. I just followed the link to an archive page, knew it was wrong, and looked for why, but by the time I found out very much more you'd fixed it. Andrewa (talk) 05:51, 13 March 2018 (UTC)[reply]
Now I've seen everything. I suppose my bot should patrol for stupid archiving configurations. This page was set up to archive threads after 5 days (120 hours) with no new comments. Yeah, that's a problem when requested moves are scheduled to run for seven days and nobody comments on the RM after the second day that it was open! wbm1058 (talk) 10:57, 13 March 2018 (UTC)[reply]
Thanks. Nothing is foolproof, because fools are so ingenious! I certainly wouldn't modify the bot on one occurrence. If it became a regular thing, it may be better to modify the archive bot... say, have a template adding a banner and category to the talk page, to indicate that the page is temporarily not to be archived, which might stop some stupid manual archiving too (I said might... hmmm, but that needs a mod to your bot too, to add and remove the template). But even if I'd figured out what the problem was, it was something I think you needed to see. Andrewa (talk) 16:44, 13 March 2018 (UTC)[reply]
OK, and if the RM is relisted then the two weeks automatically restarts for that section, because relisting is itself an edit even if there's no other activity... that sounds logical to me, interested in other views. Andrewa (talk) 17:38, 13 March 2018 (UTC)[reply]
There will be no talk page threads most of the time with that setting. Two weeks is an extremely short period for all but the most active articles; I'm not sure why there would be a preference for the talk page to be empty. Actually, given that there is so little action on the page, manual archiving is probably a better option. Also, the RMCD bot isn't updating the moves page now, I think. Is it down or being reworked? Dekimasuよ!17:41, 13 March 2018 (UTC)[reply]
I have collated the 4 existing archives into one archive that's still only 15K and turned off the auto-archiving. There's no need for archives that look like this, because they don't help us search for relevant previous discussions. On a normal talk page, it would be just fine to have all the talk topics since the creation of the article over ten years ago still on the main talk page, but I haven't taken the step of dearchiving everything. Dekimasuよ!17:48, 13 March 2018 (UTC)[reply]
Good points all. But this is on archiving rather than on the RM bot. Dekimasu and QEDK, I'd be very interested in continuing this discussion, but I think we should find a better place for it, and leave the bot and its owner in (exonerated) peace. Andrewa (talk) 17:57, 13 March 2018 (UTC)[reply]
I agree. However, the real reason I came by again was to get confirmation that Wbm knows the bot is down, and he does, so I feel reassured as well. Dekimasuよ!18:07, 13 March 2018 (UTC)[reply]
Or, maybe have a flag on a section that says not to be archived and is respected by archive bots? And add that flag to every properly raised RM (needs a mod to one template)? And remove (or override with another flag, that sounds simpler but is a bit ugly) the no-archive-section flag when the bot sees it as closed (and maybe make it available for immediate archive... that could use the archive-section-anyway override flag and makes it a lot less ugly).
I agree with Dekimasu re archiving. I'm trying to update to a newer version of PHP, and running into problems. I'm about to give up and revert to the version that works. Then I can futz with trying to upgrade on my other system. I wasn't expecting updating to be so difficult. wbm1058 (talk) 17:54, 13 March 2018 (UTC)[reply]
Better option may be a bot to patrol all talk pages transcluding User:ClueBot III/ArchiveThis and check their archiving configurations, and report all pages with overly aggressive archiving setups, including setups changed by _cough_ *vandals*. – wbm1058 (talk) 19:42, 5 July 2018 (UTC)[reply]
This rhymes with similar "edit-conflict" issues I previously fixed; see User talk:RMCD bot/Archive 1#RMCD bot alert. Unfortunately the bot's console log overwrites itself each time the bot runs, so the internal diagnostic report is lost already. I'll probably need to intentionally reproduce this scenario to follow the processing and confirm a fix, though I may be able to figure it out with a code-walkthrough. Thanks for the report. – wbm1058 (talk) 22:43, 25 September 2018 (UTC)[reply]
All good. It's a brilliant system overall. "Unfortunately, Andy, the closer we get to true artificial intelligence, the closer we also get to artificial stupidity." - My favourite AI expert who may not want to be named. Andrewa (talk) 06:36, 26 September 2018 (UTC)[reply]
Danski454, thanks for reporting this. Ideally I would have been notified about this sooner, while the RM was still open. The bot endeavors to comply with MOS:ORDER, so I suspect it got confused by this template:
{{cite journal |author=Ushiki T |title=Collagen fibers, reticular fibers and elastic fibers. A comprehensive understanding from a morphological viewpoint |journal=Arch Histol Cytol |volume=65 |issue=2 |pages=109–26 |year=2002 |pmid=12164335 |doi=10.1679/aohc.65.109 |url=https://www.healthyki.com/2019/01/amazing-facts-about-acne-all-will-shock.html }} |date=December 2017 |bot=InternetArchiveBot |fix-attempted=yes }}
thinking that template belonged with the hatnotes placed "before the lead section" and thus the notice was placed after that template. It's not immediately apparent to me why. This involves regex (regular expressions) which aren't easy to code to perfection at times. As this seems to be a one-off that I've never seen before, I'm giving it a mid-priority, meaning that the next time something like this happens while an RM is open, I expect I would likely bump up the priority then and try to fix it before the RM closed. – wbm1058 (talk) 15:16, 17 June 2019 (UTC)[reply]
Please note at this point that the nom has withdrawn and moved the template back to its previous name. Still doesn't mean I'm not confused, tho. :>) In case you didn't see it, the entry on the WP:RM page was Template:Infobox medical condition (new) → Template:Infobox medical condition (new). Weird. Paine Ellsworth, ed.put'r there00:06, 4 July 2019 (UTC)[reply]
Nonetheless I see that Template:Requested move seems to be missing an edit check to flag requests to move a page to its current location as an {{error}}, and I suppose the bot should also check for edits to previously-submitted RMs to do that. – wbm1058 (talk) 21:46, 9 October 2019 (UTC)[reply]
Bot not detecting some transclusions of {{Reflist-talk}}
RMCD bot isn't putting some redirects to {{Reflist-talk}} on a new line, causing rendering issues as seen in two entries of the current backlog. In case it's useful, there is a full list of all redirects to {{Reflist-talk}} below.
Fixed in version 6.87 – when I made the formatting fix to support this template in January 2015, there was only one alias for this template, which the bot supported. But then, starting in May 2015, the floodgates started opening. Three different editors added a single new alias in May, June, and July 2015. Then an editor covered most of the bases by adding 8 aliases in September 2015. Two more editors added two new aliases in January and October 2016, bringing the total number of names for the template to 15. The bot is now up to date as-of October 2016 with support for these 15. Right, since then seven different editors have added seven more aliases (total 22), between November 2016–May 2019. These are of dubious value and are thinly used. Maybe I'll update support for these later. Redirects aren't that cheap, when they waste programmer time. – wbm1058 (talk) 18:32, 10 August 2019 (UTC)[reply]
That notice first went up after MSGJ closed the RM without removing the template. From the bot's perspective, the RM isn't closed until the template is removed. The bot kept posting the misplaced notice until the template was removed. This could be an unintended side effect of my code refactoring in order to solve this issue (or not). In any event, it's now another item on my bug list. – wbm1058 (talk) 17:32, 25 May 2020 (UTC)[reply]
This problem has been popping up frequently recently. I'm not sure why but likely a side effect of more recent code refactoring. Adding a second pass to catch redundant requests made on different pages has lengthened the delay from when the transcluded requests are captured to the time they are processed. Also, as I mentioned here, very large multimove requests such as this one can cause significant delays. Longer delays means larger windows for edit conflicts to happen. Edit conflicts have always happened but this previously infrequent problem has now become a common occurrance. I've caught one in action and am posting my findings here for the record as I walk through the processing sequence.
At 02:02 or 02:03, the bot reads this version of New Corella, Davao del Norte and should find that it is a self-redirect as the result of a page-mover's page swap but doesn't check for that –
it just notes that it's a redirect that does not redirect to the requested name (New Corella)
But the RM is still otherwise listed normally, as if it hasn't been moved or closed yet (its status during the first pass)
Except that in this diff{{no redirect|New Corella}} changed to [[New Corella]]
Right, that's just because of this recent code change to stop exceeding the expensive parser function limit. Since after the page-mover swap it's not a redirect anymore so {{no redirect|New Corella}}, an expensive function, isn't needed
The second-pass console report:
__________
82 Processing Talk:New Corella, Davao del Norte (:New Corella, Davao del Norte) contents...
Description: No other place, person or event that carry the same name. Refer to [[Talk:Talaingod, Davao del Norte|Talaingod]], [[Talk:Cagdianao|Cagdianao]] and [[Talk:Capas|Capas]] for similar discussion. --[[User:Exec8|Exec8]] ([[User talk:Exec8|talk]]) 01:17, 6 June 2020 (UTC)
Timestamp: 1591406220 - 01:17, 6 June 2020 (UTC); Original timestamp: 1591406220 - 01:17, 6 June 2020 (UTC) Delay passed?: true
Section> Requested move 6 June 2020
Current name: 0: :New Corella, Davao del Norte
GET: https://en.wikipedia.org/w/api.php?action=query&format=json&prop=revisions&rvslots=main&titles=%3ANew+Corella%2C+Davao+del+Norte&rvlimit=1&rvprop=content|timestamp (0.11700701713562 s) (432 b)
*** PAGE :New Corella, Davao del Norte IS A REDIRECT!! ***
#REDIRECT [[New Corella, Davao del Norte]]
Target: New Corella, Davao del Norte
GET: https://en.wikipedia.org/w/api.php?action=query&format=json&prop=revisions&rvslots=main&titles=Talk%3ANew+Corella&rvlimit=1&rvprop=content|timestamp (0.091005086898804 s) (2126 b)
New name: 0: New Corella (Talk:New Corella has non-redirecting content) GET: https://en.wikipedia.org/w/api.php?action=query&format=json&prop=revisions&rvslots=main&titles=New+Corella&rvlimit=1&rvprop=content|timestamp (0.092005014419556 s) (11258 b)
Target-page New Corella has non-redirecting content
New Corella is not requested for move
*** Post crosspost notice to Talk:New Corella ***
GET: https://en.wikipedia.org/w/api.php?action=query&meta=tokens&format=json (0.083004951477051 s) (99 b)
POST: https://en.wikipedia.org/w/api.php?action=edit&format=json (1.0500600337982 s) (180 b)
__________
v 7.36 went live yesterday; that should fix this but I didn't test it. Watch for a live-test which should add a line to Wikipedia:Requested moves/Current discussions for the malformed request: "[pagename] self-redirects. May be in process of moving or closing." While monitoring for a confirming use case, I just found two different scenarios which I added as separate sections below. Oh my. – wbm1058 (talk) 16:40, 14 June 2020 (UTC)[reply]
8′46″
This represents a different variant of the issue. In this case the talk page was temporarily out of sync with the article. Unfortunately I didn't capture the console report before it was overwritten.
At 15:44, Fuzheado moved page 8 minutes and 46 seconds to 8′46″: improper SNOW CLOSE, no consensus, and early close - undoing move until proper procedure followed
This is a timing issue that I'm not sure I reproduced in testing, but I think other patches I've put in place including v 7.37 should catch it depending on the timing. So I'm taking this off my to-do list until another instance of the problem is noticed, at least. – wbm1058 (talk) 01:40, 4 July 2020 (UTC)[reply]
{{User:RMCD bot/multimove|1=John Brown (disambiguation)|2=Talk:John Brown (abolitionist)#Requested move 13 June 2020 }}
because originally it wasn't a multi-move. Upon conversion to multi-move the template should just be added to the original notice. Working – wbm1058 (talk) 15:38, 14 June 2020 (UTC)[reply]
v 7.38 addresses this... now when this happens notifications are skipped and this won't be reported as a "possibly incomplete" request. Really, notifications should be skipped any time the bot sees what it thinks is a malformed request. "Redirects to requested name" is still reported as a "soft error": "May be in process of closing." This is not a problem needing attention if it's an edit conflict, but if hours pass after the page moved and the RM still hasn't been closed then it is a problem needing attention. – wbm1058 (talk) 15:50, 16 June 2020 (UTC)[reply]
Edit conflict with bot's processing. The bot would have reverted itself on the next run as it automatically removes these templates after an RM is closed. In this case, the RM was still open when the bot passed by the page. This issue should be addressed by my next bot coding task. – wbm1058 (talk) 00:51, 25 October 2021 (UTC)[reply]
mw:API:Edit has parameters that are used to detect edit conflicts. My bot framework has a rudimentary option to use these but I think my algorithm is too complicated to use that as designed. Anyhow that may be an option for solving this particular issue, versus trawling through edit histories. Just also noting that I named that template User:RMCD bot/subject notice as an attempt to communicate to editors, "this template is property of the bot, which will take responsibility for its proper usage, including removal when appropriate." The issue is the bot doesn't work in real time, and thus there can be a lag of up to 15–20 minutes or more from when the RM is closed to when the bot removes that template. – wbm1058 (talk) 23:29, 8 November 2021 (UTC)[reply]
OK, so detecting edit conflicts or reversions of bot edits requires still unimplemented changes in my bot's framework. In lieu of that, I have Fixed this specific issue with version 7.67 which won't post notifications more than one week after the RM was listed. That addresses the issues linked above. There is still a chance for this issue to repeat if an RM is speedily closed, but that should happen about as often as it snows in mid-summer. – wbm1058 (talk) 01:09, 16 November 2021 (UTC)[reply]
Indication of move protection settings
Is it possible to add an indication of page move protection settings of the pages involved in move discussion? Basically, there have been some cases where I go to a RM & realise it's template protected (could even be sysop protected). Maybe, we should add an indication of this in the elapsed/backlog requests list, so that everyone knows what rights are required for closing the move. Sysops would know that this particular RM requires their intervention, etc. An underline on page name, like it is under Discuss seems appropriate. A section noting the significance/meaning of these underlines at WP:RM would help everyone know what they stand for. Thanks! ---CX Zoom(he/him)(let's talk|contribs)12:50, 2 March 2022 (UTC)[reply]
The technology exists: {{PROTECTIONLEVEL:move|Elton John}} → sysop; {{PROTECTIONLEVEL:move|Template:Pp-template}} → templateeditor. --Redrose64 🌹 (talk) 21:47, 2 March 2022 (UTC)[reply]
Yes, the bot would obtain it via mw:API:Info. But this idea raised another idea in my mind, which is to flag requested move targets that have page histories that prevent page-movers from moving directly over the redirect. I find unnecessary round-robin moves to be annoying as they add confusion to the page-move histories. I envision preemptive deletions of page-move-blocking edits, while the RM is open, to enable RM-closing page movers to move directly over the redirect. – wbm1058 (talk) 17:18, 12 March 2022 (UTC)[reply]
Interesting take on the round-robin technique. Your suggestion to make it possible for page movers to be able to move over multiple-edit redirects is admirable and I hope it comes to pass. I remember reading that when a redirect's page history is substantial, then even admins should use the round-robin to preserve the page history. I have been using a different technique when the page history is not substantial, which is simply to move the redirect to a new, plausible title without leaving a redirect behind. So the old redirect is deleted much the same way an admin would do it, except that there is a new redirect created. One tricky part for page movers would be weighing how substantial the redirect's page history is. Novice page movers might want to avoid this procedure until they are experienced enough to measure what is and isn't a substantial page history. P.I. Ellsworth - ed.put'r there09:09, 22 April 2022 (UTC)[reply]
Hi there! I'd like to request that when the bot has insufficient perms to edit certain pages to add the banner, it adds an an edit request to the talk page. An example of this happening is here. Thanks! 🐶 EpicPupper(he/him | talk)21:42, 4 April 2022 (UTC)[reply]
This is lower priority because it's not a frequently-occurring problem. My bot tells me (in its console report, when I check in on that) when it hasn't posted a notice somewhere. I don't see that very often. – wbm1058 (talk) 23:10, 9 March 2024 (UTC)[reply]
I suppose I could enhance the bot to look at the edit history of Wikipedia:Requested moves/Current discussions, and make it post a notice on the talk page of any editor who happened to be the last editor to edit that subpage, basically telling that editor the same thing that UtherSRG did. On 15 December 2023, I added a new functionrecent_page_edits to botclasses.php – this function hasn't been tested in production code yet, though. I should write another, related function that gets the user ID of the most recent editor of a specified page, for this purpose. – wbm1058 (talk) 16:05, 19 January 2024 (UTC)[reply]
That archived discussion points out that not all edits to the bot's page are misuse.
Here an editor who is not a template editor jumped in a minute after the bot's last edit to correct their requested move target. They just wanted to get a jump on the bot, which would have made the same change, albeit about 15 minutes later.
Indeed, the page should rarely (if ever) be edited by non-bots. The only edit I have made to the page eight and a half years ago, for example, was immediately reverted by the bot in the next edit. This change replaced the #ifeq with noinclude and includeonly, and I did not ask the bot to do this until about a year later (archived at User talk:RMCD bot/Archive 1#Noinclude and includeonly tags).
Below are possible solutions with the pros and cons:
@Saisønisse: hopefully I've fixed it to your satisfaction. You should always use {{subst:requested move}}, following the instructions given in that template's documentation or at WP:RM#CM, to request potentially controversial moves; the purpose of that template is to pre-process requests so that you don't encounter the sort of issues you did, which often require me to intervene to fix. My time is over-subscribed. – wbm1058 (talk) 20:20, 3 April 2024 (UTC)[reply]
Thanks for reporting. Fixed to not edit war by bot v 8.51
The underlying problem was a commented-out template. I had to make ONE, TWO edits to resolve the underlying problem. I've not attempted to make the bot's regex smart enough to ignore commented-out templates or partial-template syntax, so this issue could recur in the future, albeit without the internal edit warring. The problem will be reported in my bot's console, and if I notice that, I can fix it in a similar manner. – wbm1058 (talk) 17:45, 3 April 2024 (UTC)[reply]
The request was closed, at which point the bot correctly removed the banner, but then the RM was reopened. I have restored the banner. SilverLocust💬10:50, 6 April 2024 (UTC)[reply]
Understandable, but ... it can be confusing to readers since, in most cases, the nomination statement will be about a primary topic claim and why the proposed article should move to the base name, but then the move listed before their nomination statement is either moving the current primary topic away from the title or moving the respective disambiguation page. Move discussion closers can figure out the correct order of moves themselves when closing the discussion, since ... honestly, they should anyways if they are moving pages. Steel1943 (talk) 16:10, 4 June 2024 (UTC)[reply]
I am updating the the current discussion pages in a semi-autonomous manner using the bot's script. It should suffice for now until Wbm1058 returns in a couple of days (hopefully). – robertsky (talk) 00:40, 17 July 2024 (UTC)[reply]
No problem. Let me know when you are ready take over. Additionally, I have just figured out the settings for Toolforge to have it scheduled. If you want, I can guide/help you to set it up. – robertsky (talk) 11:52, 20 July 2024 (UTC)[reply]
Thanks again for filling in. I wanted to let the bots run in parallel for a little while to see whether any issues with edit conflicts cropped up. I do have some of my bots set up to run on the Toolforge. Unfortuanately both of my permalink bots (on my desktop and on the Toolforge) stopped working while I was away. – wbm1058 (talk) 03:00, 29 July 2024 (UTC)[reply]
After I took over the tasks, I realised that there was the potential for repeated messages, so I modified a couple of lines in your code to ensure that there's no repeat of messages from my bot if yours had posted first on the talk page. There shouldn't be edit conflicts on the article pages and the notice pages given that the content should be roughly the same. – robertsky (talk) 04:02, 29 July 2024 (UTC)[reply]
@Spworld2 I think you got confused. The discussion is not about a 'removal' of I don't know what you are thinking of. The discussion should not be unceremoniously removed as you had done. You can leave a comment on it though. – robertsky (talk) 06:31, 23 August 2024 (UTC)[reply]
Moved from User talk:wbm1058
