Location: Replacing the text "Please ensure draftifying is appropriate per WP:DRAFTIFY" with "Draftification may not be appropriate per WP:DRAFTIFY, since this article is less than 60 minutes old" OR "more than 90 days old".
Just the warning, but don't stop the user from draftifying, since there might be exceptional circumstances.
I don't think we need to clutter up the UI with more instructions. They should know this from the tutorial and it wasn't in Evad's version. Good thinking though. BTW, what did you think about my wireframes? There are two reasons for this idea: When creators complain, we can say "Two reviewers have checked your article", and it's a double safeguard and protects the first reviewer from making an unintentional error - saves unnecessary chit-chat at that chat site asking what to do. Kudpung กุดผึ้ง (talk) 12:15, 8 November 2022 (UTC)[reply]
@Kudpung, these are NOT instructions. It's a warning message that will not display unless the draft in question is outside the approved draftification window (1 hour - 90 days). This will catch move-to-drafts that do not follow this policy. Since it won't add any clutter in most cases unless the article probably shouldn't be moved, I think this is a good enhancement. I recall one very recent complaint at ANI about an NPPer Drafting an article that was just minutes old. MB14:23, 8 November 2022 (UTC)[reply]
I think 15 minutes is a better lower limit, since that is the lower limit given in WP:NPP. There is a danger that if we don't give the lowest limit possible, that folks will just ignore the warnings given by the user script. –Novem Linguae (talk) 21:56, 8 November 2022 (UTC)[reply]
I've added this feature to the script on the test wikipedia. Please test it out. If no one finds a problem with it, I'll copy it to the enwiki version as well.
The lower timelimit is 15 min as NL suggested. We can change that once the discussion on the NPP coordination talk page is closed. -MPGuy2824 (talk) 06:58, 9 November 2022 (UTC)[reply]
It already checks that there isn't already a Draft with the same title. Doesn't that catch this? I've received that warning many times. MB23:40, 8 November 2022 (UTC)[reply]
I didn't receive the warning when I tested Siwi Boora above. So either that one is an edge case, or the warning comes after clicking submit (I didn't click submit). Anyway, if most cases are covered already, don't worry about it :) –Novem Linguae (talk) 23:50, 8 November 2022 (UTC)[reply]
NL, yes the error is shown only after clicking 'Submit'.
MB, according to the API documentation there will be an API error while moving the page, if the destination page already exists, and it isn't a redirect to the source page. I think this only covers the situation where the contents of a draft are copied to mainspace. It doesn't cover all double draftifications though. e.g.
Article created in mainspace is moved to draftspace.
Creator moves it back to mainspace without much improvement.
If another editor tries to move it back to draft, the current script will allow it.
Let me see if it is easy to read the edit summaries of all the revisions of a page, and find the phrase that denotes previous draftification.
After showing an appropriate warning (say "This page has been moved to draft in the past.") should the script allow the user to continue or not? -MPGuy2824 (talk) 05:32, 11 November 2022 (UTC)[reply]
Perhaps a firmer warning, and then user (fully educated at this point) has the option to ignore. "This page has been moved to draft in the past. Per WP:DRAFTOBJECT, it is usually inappropriate to draftify again. Are you sure you want to continue?" –Novem Linguae (talk) 09:46, 11 November 2022 (UTC)[reply]
The only bug still in the UI that I designed is that the text window has still not been relabelled 'Preview', but I am not a js coder and I don't know how to do it myself. Kudpung กุดผึ้ง (talk) 07:16, 4 January 2023 (UTC)[reply]
Kudpung, I've figured out how to show an actual preview of the notification message. The new script is at the test wiki. Please test it out there. The only problem is that the draft link remains red since the page hasn't yet been moved. -MPGuy2824 (talk) 09:20, 4 January 2023 (UTC)[reply]
I had to import nearly 1,500 lines of code into my TestWiki js page. It doesn't work and I can't read computer code. All we really need to do is replace the words 'Notification message:' with 'Preview' The preview works perfectly, exactly as it is supposed to do. The link doesn't need to be in red because it's not clickable anyway. Kudpung กุดผึ้ง (talk) 09:38, 4 January 2023 (UTC)[reply]
Kudpung, there is no need to import the contents of the script to your common.js file (just the line saying importScript('User:MPGuy2824/nullEdit.js' );importScript('User:MPGuy2824/MoveToDraft.js'); should do). Anyway, i've added a screenshot of what it looks like. I've also changed the words "Notification message:" to "Notification preview:". -MPGuy2824 (talk) 09:56, 4 January 2023 (UTC)[reply]
My fault entirely. I should have said importScript('User:MPGuy2824/MoveToDraft.js'); Sorry about that. I copied the wrong line from my own common.js file. -MPGuy2824 (talk) 03:36, 5 January 2023 (UTC)[reply]
Steps to reproduce: 1) random article, 2) click "move to draft", bringing up the modal, 3) zoom browser in pretty far (mine is 150% which is what I use during normal browsing). What happens: when scrolling down, the modal moves up, and some items are floating on top of the modal such as the p-personal portlet, and the links created by the user script User:Bradv/Scripts/Superlinks. What should have happened instead: The open MoveToDraft script should have the topmost z-index, floating above all other elements on the page. –Novem Linguae (talk) 04:27, 8 January 2023 (UTC)[reply]
I have just updated it in my common.js and I must say I prefer this compared to the old one. A lot of more options especially reasons for moving to draft which sometimes takes me a while if I have to write it myself.
It was cleaned up some by RajEditor1999 who moved it to mainspace on Nov. 8
It was draftified by Onel5969 about three hours later, so the message went to the "wrong" person.
In this case, it probably didn't make any difference as the Draft was moved right back by Mahipal1234. It's tagged with UPE and these may all be the same person.
But in the more abstract case, maybe the script can look at the page history and notify the top 2 or 3 contributors and/or look for recent moves, or something else. MB15:08, 8 November 2022 (UTC)[reply]
I used the Evad script, and the editor to be notified is a field, which you can change to a different editor. I should have changed it to one of the other socks, probably Rajeditor. Onel5969TT me15:28, 8 November 2022 (UTC)[reply]
This script is the newer version, so you can do that too. But I suspect many people (myself included) don't bother to look at who should be notified and just let it default to the first editor. MB17:01, 8 November 2022 (UTC)[reply]
One option is to create a screen like the wikilove screen of PageTriage. Let the reviewer choose the contributors that need to be sent the draftification message. Then move on to the normal MoveToDraft screen with the various issue checkboxes. -MPGuy2824 (talk) 09:22, 12 November 2022 (UTC)[reply]
I've added this feature to the script on the test wiki. Please test it out there. With the new changes, you can't send a message to yourself, so besides your own creations, you'll need a few pages to test it out on. Try [1] and [2]. -MPGuy2824 (talk) 05:30, 20 December 2022 (UTC)[reply]
Hi, I ran into a bug today with the script. I was trying to move Draft:Kaili people and when I got to the contributors screen I got the following console error which caused the script to halt before rendering the next/cancel buttons:
at Sizzle.error (load.php?lang=en&modules=jquery%7Cjquery.ui&skin=vector&version=1lbgy:21:731)
at Sizzle.tokenize (load.php?lang=en&modules=jquery%7Cjquery.ui&skin=vector&version=1lbgy:31:651)
at Sizzle.select (load.php?lang=en&modules=jquery%7Cjquery.ui&skin=vector&version=1lbgy:38:145)
at Function.Sizzle [as find] (load.php?lang=en&modules=jquery%7Cjquery.ui&skin=vector&version=1lbgy:12:118)
at jQuery.fn.init.find (load.php?lang=en&modules=jquery%7Cjquery.ui&skin=vector&version=1lbgy:42:84)
at new jQuery.fn.init (load.php?lang=en&modules=jquery%7Cjquery.ui&skin=vector&version=1lbgy:43:384)
at jQuery (load.php?lang=en&modules=jquery%7Cjquery.ui&skin=vector&version=1lbgy:2:684)
at showContributorScreen (core.js?action=raw&ctype=text/javascript:1086:4)
Possibly related to the creator's username format breaking the script, but I'm not sure. I was able to overcome this by removing two lines from the companion script JS in my browser's memory:
I'd like to suggest perhaps adding a section to this page listing the differences between this script and the Evad37 script. I think we've made some good adjustments compared to the old script, including more customized messages, and additional alerts to the reviewer, but I can't remember the details and it would be nice to have it listed. –Novem Linguae (talk) 01:55, 11 June 2023 (UTC)[reply]
Greetings MPGuy2824. Upon reading the informative, well written parent of this talk page regarding the script you have developed, I did encounter one sentence which appears to be missing the present tense verb: "is", which would improve readability if it was present. Because it appears that you would prefer that others do not make changes in your user space when urgency is not a factor, I'll forgo being bold and suggest the possible change here instead.
Under the subheading: Disable logging within your userspace: A sentence reads as: "Logging is enabled if this omitted or set to false." I think that you meant to write: "Logging is enabled if this [is] omitted or set to false." I leave it to your discretion to implement this change, or not. Cheers. --John Cline (talk) 04:00, 11 June 2023 (UTC)[reply]
Currently when moving the page, the script writes something like Novem Linguae moved page John Smith to Draft:John Smith without leaving a redirect: Not ready for mainspace, incubate in draftspace. Would be nice if it mentioned the reason in this edit summary of the move. The reason is posted to the user talk page, I think, but would be nice to see it in watchlists and article history too without extra searching and clicks. Maybe something like Novem Linguae moved page John Smith to Draft:John Smith without leaving a redirect: Not ready for mainspace, incubate in draftspace. Main concern: no sources. And the main concern could be generated based on which reason check boxes are ticked in MoveToDraft. If they pick a custom reason only, we could continue to leave it blank. Thoughts? –Novem Linguae (talk) 04:13, 4 July 2023 (UTC)[reply]
Seems like a good idea. I'm thinking "no sources", "more sources needed", "language/grammar problems", "poor translation", "promotional/ad", "possible COI", "custom reason" for each of the given reasons shown in File:MoveToDraft - Options screen.png. I can add it to the move log, and the Draftify log, as well as its edit summary. -MPGuy2824 (talk) 04:28, 4 July 2023 (UTC)[reply]
Sounds perfect. Nice choice of shortwords. Throw the user's checkbox choices into an array, .map() it to your shortwords, .join() it with commas, and should work really nicely. –Novem Linguae (talk) 10:29, 4 July 2023 (UTC)[reply]
The instructions for automatic installation state, "Click the big blue "Install" button in the infobox on the right of this page." However, there's no button anymore. Significa liberdade (talk) 15:34, 26 July 2023 (UTC)[reply]
Works for me. Try going to special preferences gadgets and enabling "Install scripts without having to manually edit JavaScript files". Might be worth mentioning this step on the script page, too. –Novem Linguae (talk) 19:47, 26 July 2023 (UTC)[reply]
I tried to use the script to draftify an article, but it is not loading after "Get contributor data", "Get current wikitext", "Get redirects", and "Get Page Triage status" are completed. The "Abort uncompleted tasks" button doesn't do anything, but the "X" closes the window as intended. – dudhhrtalkcontribs (he/they) 06:10, 5 August 2023 (UTC)[reply]
@Dudhhr Thanks for reporting this. I see that other people are able to use the script properly, so it isn't a widespread problem. My guess would be that there is something about the article, (or its history) that is causing the script to hang at that stage. If you can still remember the name of the article that is causing the problem, it would help me to debug and hopefully solve the issue. -MPGuy2824 (talk) 04:57, 9 August 2023 (UTC)[reply]
I'm not seeing anything weird in the article histories of either of those pages. I've copied your common.js to mine, and have tested the MTD script for Wingo Panama, Narcoguerrilla and Saleh al-Mansouf. For all of them, the script took me to the contributor screen, and then the options screen. Please try out the script again for these three pages and tell me what issues you are facing. Thank you for your patience. -MPGuy2824 (talk) 05:14, 10 August 2023 (UTC)[reply]
@MPGuy2824 I tested your script again on those arcitles, it still doesn't work. It's probably a device issue as I'm using an iPad. Can you try using the script on an iOS device if you have one? – dudhhrtalkcontribs (he/they) 20:25, 10 August 2023 (UTC)[reply]
I don't have an iOS device, but a fellow editor tested the script for the two remaining articles that i linked above. It worked as documented. I can't think of what else might be causing the issue. -MPGuy2824 (talk) 04:26, 11 August 2023 (UTC)[reply]
For "Usage", Selecting "Move to draft" will bring up a list of contributors to whom notifications can be sent. Question: is there ability to "Opt Out" of those notifications? The only articles that I occasionally create are posted as full & able to pass Review successfully, for example "1967 in Romania". Other non-year articles I have not created. In the past 4 days I've received two of these Talk page notices, and while they are a slight bother, I do see their value. Just do not want them to deter me from my prime Wikipedia objective - De-orphan articles. Regards, JoeNMLC (talk) 21:03, 2 August 2023 (UTC)[reply]
Hi Joe, I think removal of the orphan tag is a small non-controversial edit, and you can definitely mark such edits as minor. My script ignores edits that marked as minor, while getting a possible list of contributors to the article. This would be a quick solution to your problem. Also, this way, if you make any substantial edits to an article, you could still be notified if that article is going to be draftified. Happy gnoming! -MPGuy2824 (talk) 06:15, 3 August 2023 (UTC)[reply]
I think it would be helpful to make two changes to the automatic message placed on talk pages:
Remove the passive voice in Unfortunately, it is not ready for publishing because [...]. Your article is now a draft where you can improve it undisturbed for a while. The article was moved to draft by a person and the statement it is not ready for publishing and what follows is that person's evaluation, not objective fact. I'd suggest something along the lines of Unfortunately, I do not think it is ready for publishing at this time because [...]. I have converted the article to a draft which [...]. Apart from active voice generally being considered a better and more personal style, I think this avoids the misleading implication that the reviewer's judgement is unchallengeable.
Add something like or move the page to the last sentence. AfC is not mandatory for the vast majority of editors, and we can help lessen the burden on reviewers there by highlighting to creators that they can just move a draft back to mainspace themselves (where it will in any case be re-reviewed by an NPPer).
I'll also repeat my request to make the messages templates or something else configurable on-wiki, so we can make changes like this using normal editing procedures :) – Joe (talk) 07:37, 6 October 2023 (UTC)[reply]
Doh, ignore me – the current text already does both those things. Apparently I was reading old messages. Nice work! – Joe (talk) 07:46, 6 October 2023 (UTC)[reply]
Joe, this is a recent example of the message placed on a contributor's talk page. It doesn't seem to have your suggested changes. I'll think about how to read the message from an on-wiki template, but I should be able to change the message as per your suggestions soon. -MPGuy2824 (talk) 08:03, 6 October 2023 (UTC)[reply]
I am thoroughly confused. That's the kind of message that prompted this suggestion, but when I open the script myself I see a completely different one:
The article you created at [...] didn't cite any/enough sources. Verifiability is one of Wikipedia's core policies and information that isn't supported by a reference to a reliable source can be removed at any time. The topic does appear promising, so I've moved the article to draft so you can work on it. When you've added sources, you can move it back to article space yourself (see Help:Moving) or use the template at the top of the page to submit it to articles for creation (AfC). – Joe (talk) 09:23, 6 October 2023 (UTC)
Aha, I've got it. I'd previously customised the message used by Evad's script in my common.js, and that seems to have carried through to yours. I'd thought from the thread above that it wasn't possible to customise the message – apparently not! – Joe (talk) 09:25, 6 October 2023 (UTC)[reply]
In the thread above, FormalDude wanted a way to edit the message in the options window directly. That isn't possible, but you can set a standard message template different from the one in the script, which you have done. -MPGuy2824 (talk) 10:04, 6 October 2023 (UTC)[reply]
Hi! I'm curious about a potential improvement to MoveToDraft, though I'm not sure of the logistics exactly. Sometimes, I will sometimes make a few edits to a page before draftifying. At present, this means I get the big warning THIS HAS BEEN EDITED RECENTLY. Is there a way to deactivate this warning if the nominator is the one who has done the editing? Significa liberdade (talk) 13:46, 11 October 2023 (UTC)[reply]
Fixed Thanks for reporting this. I thought that i had fixed this problem sometime back, but the code had a bug in it. It works properly for me now. Please test it again to see if the issue crops up for you. Good luck on the backlog drive. -MPGuy2824 (talk) 05:37, 12 October 2023 (UTC)[reply]
Interface-protected edit request on 11 November 2023
In the user notification, can we not blatantly encourage users to just move the page back into main space (the last line)? This is going to invite users to just move pages back without improvement (I've seen this happen), which in turn creates a recipe for move wars and also leaves duplicate content across different namespaces all over the place. Anything that gets moved to draft by NPP should not be moved back into main space until it has been reviewed. Taking Out The Trash (talk) 02:16, 11 November 2023 (UTC)[reply]
I'm marking the interface edit requested as answered since a discussion regarding would need to take place elsewhere before any changes occur. Now to your question: Per WP:DRAFTOBJECT, anyone (including the creator of the page) can object to a draftification, and they can move a draft back to mainspace. If you feel that this policy needs to be tweaked, then I think you should start a conversation at Wikipedia talk:Drafts, which I'm sure editors on both sides of the draftification debate have watchlisted. Also, I don't think the user talk page message encourages the creator to move the pages back without improvement. It states "When the article is ready for publication, please click ... OR move the page back.". Thanks for caring about this and happy editing! -MPGuy2824 (talk) 03:32, 11 November 2023 (UTC)[reply]
Hey, not to worry; the Move API does this check. So for users, without the suppressredirect right, it would create a redirect to a draft. My script then slaps a DB-r2 template on the redirect so that an admin can delete it later. I hope this clears the issue. -MPGuy2824 (talk) 02:31, 28 December 2023 (UTC)[reply]
I mean, I can move without leaving a redirect but the policy does not allow me to do that when draftifying. So I had to create a fork of this script to actually leave a redirect. 94rainTalk02:38, 28 December 2023 (UTC)[reply]
Ah, I get it now. There are a couple of ways that this can be done. 1) a config variable that anyone can set in their common.js that forces the creation of the redirect, OR 2) a check within the code to allow only sysops and extendedmovers to access this. I think option 1 would be slightly easier to code, but what do you think? -MPGuy2824 (talk) 02:53, 28 December 2023 (UTC)[reply]
Yes, I think adding a config would be a good idea. We also need to modify the tagging redirect part which is already doing permission check here User:MPGuy2824/MoveToDraft/core.js#L-556. How about just moving that part out? I think there's a way that we can both add a config and do a permission check while not making it too complicated. The pseudocode below may help clarify my ideas:
// user can set no_redirect in common.js
if var no_redirect is set:
follow var no_redirect
else if sysop and extendedmover:
no_redirect = true
else:
no_redirect = false
move_page(nodirect=no_redirect)
tagRedirect():
if no_redirect:
Skip
I think option 2 would be a better solution. Option 2 is automatic. Option 1 is manual. Might as well automate it. I think it could be done with very simple code too. Something like if ( ! mw.config.get('wgUserGroups').includes('sysop') && ! mw.config.get('wgUserGroups').includes('extendedmover') ) {, and then tweak the flags of the API call. Just to restate the problem in case there is some confusion somewhere, the problem is that global rollbackers, global sysops, and stewards have suppressredirect, but are not supposed to use it on enwiki if they don't have the permission locally, right?
By the way, is this actually enforced in practice? I know there's some editors that go around unpatrolling autopatrolled stuff by global rollbackers, global sysops, and stewards using a database report. But do folks do the same for page moves left without a redirect? If this isn't something that's ever come up before, may not need to code it up. –Novem Linguae (talk) 04:53, 28 December 2023 (UTC)[reply]
Incidentally, global sysops don't have any rights on the English Wikipedia at all. In practice, all global sysops are also global rollbackers, which do have rights here, so it doesn't matter. * Pppery *it has begun...05:57, 28 December 2023 (UTC)[reply]
But do folks do the same for page moves left without a redirect? Yeah, it is a somewhat benign thing. Instead of leaving a redirect with a db-r2 for an admin to delete, it just moves the page completely. Let's wait for 94rain to chime in. -MPGuy2824 (talk) 04:56, 28 December 2023 (UTC)[reply]
I'm quite sure that in reality trying to get someone's global rights removed for not leaving a redirect that people think shouldn't eventually exist that would do nothing but make me look like a fool. I.e m:Steward requests/Global permissions/2019-08#Renew global interface editors for Isarra which admittedly was not my finest hour. And I know it's not people's fault that they use buggy scripts, despite the warnings splattered everywhere that people are responsible for their own actions, so haven't been yelling at them even when I was more active in that area. And I think I'm the only person who has ever cared about this in recent times. But yes, this should still be done simply because it's still wrong for scripts to violate established policy even if we have let a culture of apathy develop. * Pppery *it has begun...05:57, 28 December 2023 (UTC)[reply]
That didn't work quite as expected (It actually did the move suppressing the redirect and then recreated the mainspace page with the db-r2 template). Could you try again on [6] ? -MPGuy2824 (talk) 03:36, 29 December 2023 (UTC)[reply]
Resolved
Resolved
Fixed You're right: it was because of the dot in the username. Thanks for reporting. -MPGuy2824 (talk) 02:32, 7 May 2023 (UTC)
Done Thanks for catching that. -MPGuy2824 (talk) 04:07, 11 June 2023 (UTC)
