@Jackmcbarn: I just used the tool here, and it put my reply at the top of the level 2 section, as there was a level 3 section heading directly below it. However, the logical place to put it would be right at the end of the level 2 section. Is this easily fixable? — Mr. Stradivarius♪ talk ♪16:37, 2 April 2014 (UTC)[reply]
That's a good point - the current behaviour does make more sense in your second example. I'm not sure which case is more common, though, as in my experience they are both pretty rare. I'd say keep it like it is unless we get some data showing that cases like your first example are more common. — Mr. Stradivarius♪ talk ♪02:01, 3 April 2014 (UTC)[reply]
Hi Jackmcbarn, thanks for the script it's an awesome idea! Might have a possible bug for you. In this edit using the "Respond" button I answered the request with a not done. However the script didn't mark the edit request as done, maybe because the level 2 section header had a comma before the == which prevented it being detected as a section header. Callanecc (talk • contribs • logs) 04:39, 11 April 2014 (UTC)[reply]
@Callanecc: I'm unable to reproduce this issue. Are you sure you checked the "Answered" box? (You need to do that when using the Respond button but not for the quick response buttons) Jackmcbarn (talk) 12:10, 11 April 2014 (UTC)[reply]
Suggestion for EPH improvement on technical pages[edit]
I was just thinking about this, and on module/template related pages, the "rs" quick-click button should be replaced with a "sand" quick click as that is much more likely than the template needing reliable sources. Also, "consensus" should be added to quick response as that is a very common one (that I use at least). I'll put in separate pull request on GitHub for each piece of these pies if I get a moment and you don't beat me to it. :P — {{U|Technical 13}}(t • e • c)22:35, 24 April 2014 (UTC)[reply]
@Technical 13: Better idea. You can set a variable called ephQuickResponses in your common.js to specify what buttons you want. The format is a two-dimensional array. Each button is an element in the outside array, and the 3 elements in the inside array are the template code, additional text to add, and the button label (just like on line 41 of the script). Jackmcbarn (talk) 22:45, 24 April 2014 (UTC)[reply]
I've installed it, bypassed the cache, but the options for responding to requests aren't showing up. I'm running Safari Version 7.0.3, on Mac OS X, 10.9.3. What's wrong? Acalycine(talk/contribs)06:04, 20 May 2014 (UTC)[reply]
I'd say pull the template out of the header and place it directly below it, leaving any text behind or if there is none then the default "edit protected request on {#time:j F Y}" or whatever datestamp is most common. — {{U|Technical 13}}(e • t • c)17:54, 15 June 2014 (UTC)[reply]
I encountered another more complicated issue today as well, but am unsure how to deal with it. That issue was that the request content was placed inside the |1= parameter. (request && my fix) It was quite a long request, I'm not sure if the script could pull that out and place it outside the template if, for example, the length of the contents of that parameter were greater than the maximum pagename length or something? Just some ideas... — {{U|Technical 13}}(e • t • c)16:39, 15 June 2014 (UTC)[reply]
I'm probably not going to fix this. It's not practical to handle every possible way that somebody could screw up using the templates. Jackmcbarn (talk) 17:45, 15 June 2014 (UTC)[reply]
Did you ever get around to adding a parameter that would allow people (more likely those that answer template requests) to have it reload to the diff of the edit to be able to fix the Parsoid bug issue more quickly (so we don't have to get nasty messages when we miss one...)? Thanks. — {{U|Technical 13}}(e • t • c)16:39, 15 June 2014 (UTC)[reply]
More details: the console shows that the script loads, but the buttons do not appear on the edit request banner. I'm not seeing any console errors. I'll try disabling some of my other scripts and see if that changes things. — Mr. Stradivarius♪ talk ♪04:46, 26 June 2014 (UTC)[reply]
Mr. Stradivarius, example page? The script is very picky about what it recognizes as an edit protected template. For example, it doesn't recognize some that use "-"s in the template name like {{Edit template-protected}} but IIRC, only spaces like {{Edit template protected}}. This has annoyed me in a few cases as well. I've got access to IE 7, 9 & 11 actually on my various machines. — {{U|Technical 13}} (e • t • c)10:43, 26 June 2014 (UTC)[reply]
Very interesting indeed, the script didn't load the buttons on a request on Talk:Terence McKennauntil I preformed this edit. I then answered the request, and it put the hyphen back in. I had given it plenty of time to load, reloaded the page with the console open, saw no errors. My conclusion was that unanswered requests with a page name defined in the implicit {{{1}}} parameter caused it to not see the template with the hyphen. It's not the first time I've had hyphen issues, and it almost seems improbable that my hypothesis is what is really happening. — {{U|Technical 13}} (e • t • c)19:28, 27 June 2014 (UTC)[reply]
For example, suppose after I modified the tree, I was left with this:<root><template><title>echo</title><part><name index="1"/><value>foo|bar</value></part></template></root>. Using your XSL transform to convert that back to wikitext would yield {{echo|foo|bar}}, which would be wrong. Jackmcbarn (talk) 17:22, 10 July 2014 (UTC)[reply]
You should have put {{!}} there in the first place. Though I probably should have written that the reverse transformation guarantees round-trip equality only, and not necessarily that it will "do what I mean". To properly escape markup as an argument value, you have to parse it, escape top-level occurrences of |as{{!}} (which is the only universal method), serialise it back, and use the result of that as the argument value. With some special handling of wikilinks if you want to keep it pretty in the 99% case. But hey, you at least avoid Parsoid bugs. — Keφr17:39, 10 July 2014 (UTC)[reply]
And breaks other stuff in return? Cross-domain requests are less reliable (and IE's lack of support for them is probably the reason for the issue in the section above). I looked at your code. Parsoid outputs lots of stuff you do not actually end up using. The script discards most of it and uses brute hacks around it (pseudo strip markers) to process markup according to its needs. And best of all: you never actually use free-form user-supplied markup inside a template in your script, which means that the issue you mentioned is not a problem for you anyway. You are just being lazy. — Keφr07:20, 11 July 2014 (UTC)[reply]
Another, and I think a more important one, is understanding the items in your toolbox and knowing when not to use them. I am sorry it has no catchy name, but I think for the better. — Keφr18:14, 23 July 2014 (UTC)[reply]
Problem with different "editprotected" template[edit]
Hello Jackmcbarn, seems like I ran into a small problem with EPH here: [[1]]. The tool changed the original {{editprotected}} template into the {{edit template-protected|answered=yes}} template, and also completely removed the initial request message "There are whitespace ...". If I remember correctly, I used the respond button, entered a small notice and checked the "answered" box, then saved. I'll try to double-check my changes next time :), but could you check, what happened, please? GermanJoe (talk) 14:00, 17 November 2014 (UTC)[reply]
@GermanJoe: Changing {{editprotected}} template into the {{edit template-protected|answered=yes}} was correct. The only issue there was that the request disappeared. I'll look into that part of it. Jackmcbarn (talk) 02:30, 18 November 2014 (UTC)[reply]
See these edits: [2]; [3]byCyberpower678 (talk·contribs) and these: [4]; [5]byTechnical 13 (talk·contribs). Two different users, both editing the same section - both causing exactly the same damage (replacement of a colon with a newline) to an unrelated section, twice each. There must be a common factor; and since the edit summaries all say "(EPH)", I've come here: how is this happening, and please can it be stopped. --Redrose64 (talk) 16:38, 27 January 2015 (UTC)[reply]
Now that we have the reload to diff addition, that usually works although loads index.php?diff=undefined&oldid=undefined presumably because it's not getting the data back from the api call (and should probably return index.php?title=wgPageName&diff=curr&oldid=prev in those cases as that is more likely to be useful), I've been really good at undoing my own damage in those cases [6][7]. I do wish that the parsoid bug could be figured out and fixed though. — {{U|Technical 13}} (e • t • c)16:59, 27 January 2015 (UTC)[reply]
Jackmcbarn, I've tried to isolate a pattern. I've even reverted a couple times and redid my steps exactly and been unable to reproduce myself. The only think I can think of, and I've never had my console open to confirm this, is that it is posting the request and never receiving or receiving a corrupted response from the API. I'd suggest changing editProtectedHelper.jsonGitHub with:
Unless you can fix the API timing out on returning a result, it's not a fixable issue and having the last diff is better than no diff (of the Home_page). — {{U|Technical 13}} (e • t • c)02:31, 28 January 2015 (UTC)[reply]
@Technical 13: I just deployed a change so that if that problem happens, you'll get an error message about it and the page won't reload, so you'll be able to check the console to see what's going on. Jackmcbarn (talk) 04:22, 1 February 2015 (UTC)[reply]
I will note that there is a TypeError: 'log' called on an object that does not implement interface Console. error in the console at the moment on successful reloads. Haven't gotten a failure yet. — {{U|Technical 13}} (e • t • c)20:05, 4 February 2015 (UTC)[reply]
It most certainly should not be doing that. I've never seen that before. Either it is a new thing Jack added or it is a new thing that Parsoid is doing. If it is the first, then I beg of Jack to remove it because it makes the tool unusable as it violates half a dozen policies that say not to edit other peoples comments on talk pages without a really good reason. If it is a parsoid thing, I'd ask Jack to politely figure out where it came from and fix it. Either way, there is no consensus for that to happen, so it should be removed. — {{U|Technical 13}} (e • t • c)14:31, 3 April 2015 (UTC)[reply]
That was indeed my first thought. Well, second, but since it is the only script that ElHef has loaded as a custom script, it couldn't be my first thought that one of their other scripts were conflicting causing the issue. It is still a possibility I suppose that it is conflicting with a gadget or a locally run script (in greasemonkey or an addon of some kind they might not be aware of), but I find that unlikely unless they have a virus. — {{U|Technical 13}} (e • t • c)15:44, 3 April 2015 (UTC)[reply]
@Technical 13: Definitely no greasemonkey, and I doubt there was much in the way of addons. It was a friend's work computer running some flavor of IE, and I don't have access to change any settings at all on it. I suppose virus is possible, but it was at H&R Block and I would hope they'd have a pretty tight grip on stuff like that. I've got various gadgets running, but I just came back from a pretty long hiatus and haven't changed anything at all since returning. --ElHef (Meep?) 17:05, 3 April 2015 (UTC)[reply]
This is indeed an IE bug. I added a check to the script that detects this bug, warns the user, and (by default) disables the script from making any edits. Jackmcbarn (talk) 18:30, 18 June 2015 (UTC)[reply]
Wait you're saying I can no longer use the script now? And that there will be no fix for internet explorer? There's got to be a fix for this. I find it hard to believe that this isn't fixable.—cyberpowerChat:Online19:10, 18 June 2015 (UTC)[reply]
The template now tells you To override this, add "ephAllowDataCorruptionBug = true;" immediately above the line where you load this script. I'm guessing it would be okay to do that as long as you revert any page damage. Or you could just get Firefox or Chrome. But yeah, how come this can't be fixed? Eman235/talk19:17, 18 June 2015 (UTC)[reply]
@Cyberpower678: There will (hopefully) be a fix, but it has to come from Microsoft rather than me or the Parsoid team. There's really no way to work around it, other than either letting it corrupt the data and then fixing it after, or just using another browser. Jackmcbarn (talk) 19:33, 18 June 2015 (UTC)[reply]
@Sam Sailor: It's because years ago, Chopstickkitty (talk·contribs) made a complete mess out of the page's HTML by not closing any of his tags correctly. Apparently, Tidy covered up his errors, so they've gone unfixed up to now. Parsoid doesn't fix them the same way as Tidy, so since this is Parsoid-based, it broke them really obviously. Jackmcbarn (talk) 23:25, 26 November 2015 (UTC)[reply]
May I suggest that {{reflist-talk}} be automatically added when a reference is present in the section? I've noticed that they frequently are and I find myself adding the template often. Ping me if you reply please. Thank you for this wonderful script! EvergreenFir(talk) Please {{re}} 03:03, 3 February 2016 (UTC)[reply]
HiJackmcbarn - I was wondering, is it possible to modify the tool so that for Not Done responses, the {{not done}} template is added instead of the current one, as the current one has a question mark instead of a red "X". I find the red "X" to be better as it shows that the edit will not be performed. Many thanks. Class455 (talk|stand clear of the doors!) 22:44, 16 April 2017 (UTC)[reply]
A "Doing" function that inserts e.g. *{{doing}}~~~~ and removes it upon responding would be a nice little feature and prevent occasional edit conflicts. Thanks again for the script to both Jack and those who maintain it. SamSailor10:31, 17 July 2018 (UTC)[reply]
So I noticed you do a Parsoid API call to retrieve the current HTML of the page. As a userscript, doesn't the code already know the current HTML of the page, using standard DOM functions? Enterprisey (talk!) 04:26, 25 July 2018 (UTC)[reply]
For posterity, the HTML of the page does not have all of the annotations that Parsoid puts on it. This still isn't optimal, so I'll look into figuring out how to move away from this system. Enterprisey (talk!) 05:26, 7 October 2018 (UTC)[reply]
Fully-protected edit request on 22 September 2018 - add option[edit]
Please add an option, window.editProtectedHelperReloadAfter, that causes the page to reload instead of navigating to the diff page. I don't really want to look at the diff page afterwards, because I'm quite certain that the script works almost all of the time. I performed this change on my own sandbox, resulting in this revision. You can just copy over the JS from my sandbox. Enterprisey (talk!) 03:37, 23 September 2018 (UTC)[reply]
Hello, I'm a WMF Employee and a maintainer of the REST API /api/rest_v1. I've noticed your api-user-agent in some logs and want to suggest some very simple changes that will greatly help us improve the API without breaking your script.
1. Parsoid HTML version 1.2.1 is no longer supported, please update to 2.0.0. This will not require any real changes since the backwards incompatibility is only in video/audio tags. All you'd need to do is to replace 1.2.1 with 2.0.0 in the Accept header you're sending.
2. When using the transform endpoint, you do not provide the if-match` header, although according to the documentation it's required. You just need to pass back the value in the Tag header of the original HTML content. Right now your code is relying on a fallback I'm going to remove soon. — Preceding unsigned comment added by Pchelolo (talk • contribs) 20:31, 2 October 2018 (UTC)[reply]
There are 2 entries above from 4 years ago describing this problem, but in each instance Jackmcbarn applied a different response so it's difficult to troubleshoot from my end. Does anyone have a clearer idea of why these response selections appear in certain article requests but not in others? Spintendo 13:50, 5 October 2018 (UTC)[reply]
This fixes both issues identified in #Suggested updates: the 2.0.0 version and the ETags/If-Exist business. The change can be seen in this diff in my sandbox (version after fix); all you need to do is copy the revision over into Jackmcbarn's page.
Technical clarification, to Pchelolo: I'm guessing that we must pass precisely the full content of the etags header into the If-Exist header on the transform request; please let me know if this is correct. To the responding intadmin: this doesn't affect the functioning of the script for now, so we can copy the whole revision in and do another patch later if it turns out I got this wrong. Enterprisey (talk!) 03:04, 7 October 2018 (UTC)[reply]
This IPER is intended to fix the issue stated on the documentation page which states * Decline reasons run off the end of the screen
See this diff from my sandbox to see my intended changes. It just splits the selection from one selection to multiple selections so you can see the not done reasons you never could at 100% page zoom. It's not the best fix, but it works.
@Can I Log In: what is the stray "]" at the end? In this case (user is inactive for about 3 years) I'm mostly supportive of forcing a change to their script for cosmetic changes - though will continue to echo that this is an overall bad idea and perhaps this script should be moved Mediawiki and become a "community script" or become a gadget if it is popular enough. — xaosfluxTalk13:59, 20 April 2020 (UTC)[reply]
Umm, that is to be ignored since this doesn't have anything to do with my intentions, and it doens't have an effect on the code. Probably just some accidental thing. The main thing is to fix the Decline reasons run off the end of the screen, which is what this IPER is. It's not the best fix, but it works for now. There are better ways than this, but this is all I know.
Yeah, someone needs to take over this thing because it's owned by someone inactive for 2.5 years. Making it a gadget would be cool, but according it WP:MOSTIMPORTED, only 299 users are using this with only 164 of them active, and we don't know the definition of active, but ~55% of those who are active are using this. {{replyto}} Can I Log In's(talk) page16:46, 20 April 2020 (UTC); edited 01:04, 21 April 2020 (UTC)[reply]
Tone it down. I take a liberal approach in review of Iadmin requests since I can trivially request the permission (I just wouldn't meet the activity requirements probably to retain it). Relying on a bug for the review of a change (yes, it's a known bug that only i-admins can review deleted history of JS/CSS) also doesn't strike me as all that great. --Izno (talk) 15:43, 25 April 2020 (UTC)[reply]
Not done I'm discomforted by the idea of only having the text reviewable if I approve it; there's certainly no need for it to stay deleted. Regardless, though, I think this is a decidedly worse experience. Having options split without any indication that they're the same just leads to confusion; I knew exactly what to expect and it still took me ages to figure it out. ~ Amory(u • t • c)17:14, 25 April 2020 (UTC)[reply]
@Can I Log In: I'm active again. Anyway, your diff link appears to be deleted and I haven't asked for my admin bit back yet, so I can't currently see it. Can you repost exactly what change you wanted? Jackmcbarn (talk) 20:20, 26 July 2020 (UTC)[reply]
Doing so would violate Can I Log In's editing restriction from activities that are not related to content creation (which was imposed after this edit request was made) * Pppery *it has begun...23:17, 26 July 2020 (UTC)[reply]
Pppery I consider pings to be Responding to people on your user talk is obviously fine since a notification is sent like the you have new messages [on your talk page]; it's similar to Discord DMs and @mentions. Anyways, Jackmcbarn, welcome back all the sudden, and I see you've got the diff. Can I Log In (talk) 13:30, 27 July 2020 (UTC)[reply]
@Can I Log In: Thanks for the suggestion. It's clever, though also kind of a hack. (For the record, the specific suggestion is to replace the long entries with consecutive short ones, such that selecting any one of the lines corresponding to a given reason will result in using that reason.) My biggest issue with it is that since it's hard wrapping, it won't work right on differently-sized screens than the text was wrapped for. I think I'm going to pass on that specific change, though I will consider other alternatives, such as an HTML list to emulate a <select> element that can do real wrapping. Jackmcbarn (talk) 20:48, 27 July 2020 (UTC)[reply]
EPH is a great tool, thanks so much for developing it! I've just seen a weird bug, thought it best to bring it up here. Take a look at this diff - this was generated by clicking "Unclear" and then "OK" on EPH. No other changes, everything else was just what EPH generated automatically.
I came across a blank SPER on Talk:XXXX. I press remove request like normal per the guidelines for Empty edit requests (though not all do this), which pops up up that we should not do that. This script hasn't been updated since Oct 26, 2018. do this. On that same talkpage in that blank SPER, I then come across this from Jan 2019, so there was actually consensus despite the fact that it's already guideline, so it means there was consensus.
So it's logical to make the following change.
From
Are you sure you want to completely remove this edit request from the page? In general, this should not be done to good-faith requests, even if they are blank, unless they are duplicates of other requests by the same user, etc.
To
Are you sure you want to completely remove this edit request from the page? In general, this should not be done to good-faith requests unless they are blank or duplicates of other requests by the same user, etc.
I'd like if this script worked with COI edit requests. I did the stupid thing to make the selectors work with that template (Template:Request edit/request), but still no pretty buttons.
@Izno: It will not run because the variable "selectedlevel" is invalid since it isn't a protected edit request box... Although there are others caused by similar issues since it isn't a protected edit request box. Terasail[✉]15:35, 9 February 2021 (UTC)[reply]
@Jackmcbarn: Being on mobile, I normally edit the page to copy & paste the importScript, but this page is Trmplate protected, and I can't copy & paste from the source, so can somebody please copy the text here. Thanks ―Qwerfjkl|✉20:19, 4 May 2021 (UTC)[reply]
@MSGJ, Thanks. It looks good now. I will try to clarify my request, to clear your confusion.
Prior to this addition, the only way to install this WP:EP script was to copy the code to the commons.js page. When you include the infobox, then at the bottom of the infobox a button to install/uninstall appears for folks who have enabled User:Enterprisey/script-installer. Anyone can enable it from Preference, Gadget,
"Install scripts without having to manually edit JavaScript files (documentation)". And then you no longer need to copy paste the install code. Venkat TL (talk) 11:14, 29 October 2021 (UTC)[reply]
@MSGJ, Ok. Its upto you but I highly recommend that script. Looks like I made a small typo in copying username of author. Can you please correct the "Author = Jackmcbar" and add a 'n' at the end to make it "Author = Jackmcbarn". Thanks Venkat TL (talk) 11:21, 29 October 2021 (UTC)[reply]
It would be nice to have the associated article protection level displayed on the request template. This will remove the need to go to: article> Page information to check the level if you're considering actioning it as "decrease" or "increase" and the Admin who set the current level, can be linked in the closing rational. Example: Not done: requests for decreases to the page protection level should be directed to the protecting admin
(Xaosflux) or to Wikipedia:Requests for page protection if the protecting admin is not active or has declined the request. Sorry for the ping Xaosflux - FlightTime (open channel)23:45, 2 November 2021 (UTC)[reply]
Can we add to the increase/decrease responses, the protecting Admin into the response? Something like: "Not done: requests for decreases to the page protection level should be directed to the protecting admin (Admin) or to Wikipedia:Requests for page protection"... It seems unlikely for most requested edits, the user (probably newbie), doesn't know how to lookup the protecting Admin. - FlightTime (open channel)18:18, 14 December 2021 (UTC)[reply]
Hey there! I'm currently facing an issue with the tool not being able to recognize edit request templates. This error is being printed in the console: No data-mw attribute was found on edit request banner 14. This is probably because some template above it on the page opened an HTML tag but didn't close it. I think it's a WP:THURSDAY issue, as there are edit requests still functional before, but not after some point in time. SWinxy (talk) 01:22, 12 July 2022 (UTC)[reply]
Shouldn't affect it, but that's about the point the script disappears into Parsoid so I couldn't tell you what's happening. Izno (talk) 18:50, 12 July 2022 (UTC)[reply]
Tossing it into an HTML validator in some hopes something will be found, it looks like Module:Class is dropping its templatestyles tag in the WikiProject banner inside <tr> instead of inside <td>. I don't think that's it given the age of the related change, but I'm throwing it out there. @Nihiltres:. Izno (talk) 19:01, 12 July 2022 (UTC)[reply]
I don't think so. I first noticed problem started maybe on Saturday or Sunday, definitely before the change to Mbox. SWinxy (talk) 19:19, 12 July 2022 (UTC)[reply]
No, it was the change to mbox, I've got confirmation from a WMF engineer who knows how Parsoid works. The script currently looks for data-mw being on the tmbox, but that element shows up on the first transcluded HTML. That is now the TemplateStyles link/style element, not the tmbox. Izno (talk) 19:49, 12 July 2022 (UTC)[reply]
So, SSastry (WMF) worked on this today a bit and got a version that is mostly functional again at User:SSastry (WMF)/editProtectedHelper.js. One thing it does not fully do right now is remove the section header when the only edit request template is removed. I can merge this if desired. Izno (talk) 23:19, 12 July 2022 (UTC)[reply]
Yeah, that wasn't a "make everyone switch", that was a "I can merge a partial fix if that's what we want, probably with some added caveat on the 'Remove' button" since at the time I hadn't thought simply to adjust the text to indicate its broken-ness. Let me play around with the adjustments Sastry made today. Izno (talk) 17:39, 13 July 2022 (UTC)[reply]
I've merged Subbu's live. It should be functional enough at this point (his fix did fix the remove issue), even if I'm not sure it handles everything in User talk:Jackmcbarn/sandbox2 that it's supposed to (since I don't know what parts of that page are requirements and which were aspirations). Izno (talk) 17:54, 13 July 2022 (UTC)[reply]
<subbu> The HTML for mboxes now look like this --> <link ... about="#mwt5" typeof="mw:Extension/templatestyles mw:Transclusion" data-mw='{..}' .../><table class="... editrequest" about="#mwt5" ... >
<subbu> so, the script is looking for $(.editrequest) and looking for data-mw on that node.
<subbu> but, with the addition of templatestyles, the templatestyle element now holds the data-mw since it is the first element of the transclusion conent
<subbu> so, the code needs to be made a bit more robust.
<Izno> what would the check for data-mw been a double check for?
<subbu> i didn't check why he is looking for that.
<Izno> the console error was about likely unclosed elements up the page
<subbu> oh, looks like data-mw info is used to infer the type of form to generate. see line 270 onwards in https://en.wikipedia.org/wiki/User:Jackmcbarn/editProtectedHelper.js#L-270
<subbu> so, without data-mw, the script won't work.
I can verify that parsoid output has changed from 2020-12-21 to now. I've got the saved output of /api/rest_v1/page/html/onSpecial:Permalink/995545527, which I was using in a unit test. When I get the parsed output now, it's different. Sadly, the standard unix command-line diff does a poor job of showing what the difference is, but I've got the data here that I can share with somebody who might be able to make more sense out of it. -- RoySmith(talk)20:48, 13 July 2022 (UTC)[reply]
Roysmith, I am happy to work with you to figure out what is broken with your script. If you are on IRC, we can find a time to be online and chat there, or we can find a talk page to work through this. SSastry (WMF) (talk) 22:21, 13 July 2022 (UTC)[reply]
No, because it's not obvious to me that it's a Parsoid issue. I know that your output would have changed because I changed Module:Message box. If your stuff was working up until basically today, and it was showing the exact-same symptom as evident here (it would work on one page and not the next until the one page updated because of the job queue/MediaWiki cache being updated and now neither page worked), then I'd say the root cause isn't Parsoid in so much as the scripts' assumptions about the output of templates as-parsed by Parsoid. The above quotation is from IRC if it's not obvious, where I approached subbu thinking that this script also suffered certain assumptions. Izno (talk) 21:39, 13 July 2022 (UTC)[reply]
How so? "Each comment should be indented one more level than the comment it replies to" which is exactly what I was trying to suggest — Martin (MSGJ · talk) 15:11, 10 February 2023 (UTC)[reply]
Done, Not done, etc. are in response to the request, so it should be indented one more level than the request, not the last comment, unless the last comment is the first one that laid out what's being "done" or "not done". Nardog (talk) 15:27, 10 February 2023 (UTC)[reply]
Ah, I see your point! Well quite often the later comments are clarifying the request, so I wanted to reply to them. But I guess it depends on the context — Martin (MSGJ · talk) 17:04, 10 February 2023 (UTC)[reply]
Unfortunately it seems that Jackmcbarn has left the project, but in any case I'll log this issue in case he returns or someone else picks up the maintenance of this script.
Inthis edit, the script only removed the edit request template and the stuff that followed, leaving behind an empty section that had to be removed manually. This was probably caused by the "1" typed right before the template, as the comment at line 214 in the code say that it will only remove the header if it immediately precedes the request template. This is different from the behaviour of User:Terasail/Edit Request Tool, which removes the whole section that the template is situated in.
I can understand that this may be intended behaviour, as in some cases edit requests may be opened halfway through an existing discussion, in which case it wouldn't be ideal to simply remove the whole section, but in my experience the majority of cases in which "remove request" is used is when someone creates a new empty or vandalism-like request in their own section, in which case simply removing the whole section would be okay and would save the need for additional cleanup or convoluted checks in the code. Liu1126 (talk) 21:06, 30 April 2024 (UTC)[reply]