Jump to content

Wikipedia talk:WikiProject Articles for creation/Helper script/Rewrite

Page contents not supported in other languages.
From Wikipedia, the free encyclopedia
< Wikipedia talk:WikiProject Articles for creation | Helper script
This is an old revision of this page, as edited by Technical 13 (talk | contribs) at 15:20, 20 June 2014 (OneClickArchiver archived 1 discussion to Wikipedia talk:WikiProject Articles for creation/Helper script/Rewrite/Archive 2). The present address (URL) is a permanent link to this revision, which may differ significantly from the current revision.



Archives (Index)

This page is archived by ClueBot III.

This page is for feedback about the rewritten Articles for creation helper script. See the rewrite page for more information.
Does it look like a thread has disappeared? Check the archives →

Infoxbox, photo request

I accepted an article with the new script. It worked fine, but I just wanted to make sure that you have "infobox requested" and "image needed" on your to-do list. —Anne Delong (talk) 14:32, 24 March 2014 (UTC)[reply]

When cleaning what goes at the top of the page

I think this is a logical bug (and probably one that has other cases). When cleaning a AFC draft that has a MFD on it [1] the MFD got put under the AFC banner. Hasteur (talk) 14:49, 8 May 2014 (UTC)[reply]

@Hasteur: Hmm, this is interesting. Do you know if anyone has generated a list of process banners in the past that we could use? If not, any help in just making a list of the most common would be useful as well... Thanks! Theopolisme (talk) 22:19, 13 May 2014 (UTC)[reply]

@Theopolisme: At this time the only ones I can come up with are MFD,CSD, and probably page protection templates (though this last one I'm iffy on). Hasteur (talk) 01:32, 14 May 2014 (UTC)[reply]

Blacklisted url

The text bellow is copied from https://github.com/WPAFC/afch-rewrite/issues/6 here by (t) Josve05a (c) 23:19, 9 May 2014 (UTC).[reply]

What to do if the url for a cv is blacklisted, then the script will not decline or CSD the article. -- josve05a

This will probably need to be fixed... The only thing I can think of that we can do is have the actual URL in a hidden comment with a note like: url=Blacklisted URL, see hidden comment<!--http://this.is.blacklisted.com/so-sorry--> -- Technical 13
@Technical-13:, is the blacklist too sophisticated for something simple like http://url<!-- blacklisted -->continues.com? I'm not sure, it will probably required experimentation. -- Theopolisme
Comments are stripped out before it's tested against by the parser, so yes. The only way I know of isn't worth it and it's easier to hide the url in a comment. -- Technical 13

Notifications before actions completed

The afch-rewrite (can I call it the script/gadget/tool?) should not send a message to the user saying that an article has been declined, if the article could not actually 'be declined'. it should wait until the declining of the submission been done first, otherwise a user might get a message saying that the article has been declined, when in reallity, it has not. -- Josve05a (t) Josve05a (c) 23:19, 9 May 2014 (UTC)[reply]

The reason not to do this, of course, is that waiting for each edit to finish before beginning subsequent ones will increase the length of time it takes for a review to complete. I'll look into this further. Theopolisme (talk) 21:08, 14 May 2014 (UTC)[reply]

[0.7] Feedback about logs

We all know of Twinkles CSD-log,could it be possible to make a "AfC-review-log? for three reasons:

  1. To help in backlog drives, it makes it easier to collect revies, without te need of the magnificent program that [I can't remember the users name] has made.
  2. I want a log to see the outcome of the articles later, if they were denied cop copyvio, then I can see if they have been recreated.
  3. It is fun! (t) Josve05a (c) 17:43, 12 May 2014 (UTC)[reply]
Hiya, thanks for the thoughts. I've added this to my "To Contemplate" list. Theopolisme (talk) 21:06, 14 May 2014 (UTC)[reply]

User Talk Page messages

Rightly, we offer a Teahouse notification. Even then the talk page messages are not 100% friendly. MIght we also offer a welcome where no welcome exists at present to add some additional warmth? I know Twinkle does this well, and I am not looking for script creep, just, perhaps, an option to invoke the TW Welcome module? Fiddle Faddle 07:52, 14 May 2014 (UTC)[reply]

  • I think the best way to go about this is to open the user's talk page in a new tab upon posting and letting the reviewer use Twinkle to expand as needed, like what Twinkle itself does when you revert something. — {{U|Technical 13}} (t • e • c) 13:59, 14 May 2014 (UTC)[reply]
  • Yes, sending a welcome message from an AfC submission may not work well, because it's not always evident from the submission who needs welcoming. (Just a couple of months ago I received and invitation to the Teahouse...) Maybe there's a way to have a link to the user's talk page appear after a submission is declined (perhaps in that twilight zone display where the page has been refreshed after being declined, and the giant menu bar is still being displayed, but with no options except a backlink to the actual options). The a reviewer who has just declined a submission would then have a convenient way to leave additional information, welcome messages, or whatever. —Anne Delong (talk) 17:18, 14 May 2014 (UTC)[reply]
Yes, I declined one just now and realized that this is already done. Sorry; I will try to pay closer attention. But in that case I'm not sure why the other suggestions above would be needed, since someone wanting to leave a welcoming message could just click on that link and use Twinkle or write a message or plop in their favourite welcome template. The only thing I can think of that would be possibly helpful might be to have a small message near the user's talk page link suggesting leaving a welcome message, and that seems like a low priority change if needed at all. —Anne Delong (talk) 22:20, 14 May 2014 (UTC)[reply]

[0.8] Placeholder text

I'm really not liking the placeholder text in the "input boxes" (terminology?) presented when declining a draft. I just declined one as "already exists" and the dialogue had "Chocolate chip cookies" in the space where the actual existing article title was to be entered. A "Comments" box was also pre-filled with a quite large paragraph of "blah blah" that I didn't bother to read. IMHO an "input box" should be empty when presented for filling - particularly when filling it is not mandatory. Reviewers are not newbies, I found the placeholder text to be quite patronizing. Roger (Dodger67) (talk) 11:04, 20 May 2014 (UTC)[reply]

Fair enough. I'm inclined to agree with you, and you're entirely correct in that reviewers are hardly newbies. The goal is to find a balance between "no information provided at all" and "enough information provided to explain how a given field should be filled out"... @Anne Delong, Technical 13, and Hasteur: thoughts on removing these placeholders? (And/or which should be possibly retained/slimmed down/whatever). Thanks Roger for bringing this up! Theopolisme (talk) 20:57, 20 May 2014 (UTC)[reply]
Hrm... Comment box I think could be blanked out, but I'm sondering if we want to pre-populate on some of these.... Hasteur (talk) 21:08, 20 May 2014 (UTC)[reply]
  • I actually prefer a fair amount of automated pre-selection/pre-filled text input fields. Quite often this is an extremely repetitious task and the more the script can do on its own, the better in my opinion. Roger, it's not meant to imply that reviewers are newbies or are incapable to put in the right things. Would a simple <button class="clearField" title="Clear the default text"><img src="/media/wikipedia/commons/2/2c/WikEd_clear_summary.png" alt="Clear field" /></button> that clears the default text work? — {{U|Technical 13}} (t • e • c) 21:12, 20 May 2014 (UTC)[reply]
T13, he's not talking about prefilled, he's talking about placeholder text that tells users *how* to fill out fields (and/or provide examples of syntax). I agree more automated prefilling would be nice, but that's not what this thread is about, unless I'm misunderstanding something... Theopolisme (talk) 21:15, 20 May 2014 (UTC)[reply]
  • In the case that I'm misunderstanding the topic (entirely likely), there is no reason for the placeholder= text to not be there and there is no reason for it to not be specific. Not having it is discouraging and more likely to turn new reviewers away or old reviewers with memory issues or simply people that don't review often enough to keep up with the constant stream of interface changes. These texts are a very light grey (at least on my browser) and technically do nothing except remind new reviewers what is expected. — {{U|Technical 13}} (t • e • c) 21:38, 20 May 2014 (UTC)[reply]
I think that the placeholder for the "comment" functionality should stay: Enter your comment about the submission using wikicode syntax. Your signature will be added automatically. This is useful information about *how* to comment, and should not be removed.
I think that when declining, we should change the placeholder to: Elaborate on your decline reason here using wikicode syntax. This is once again valuable information (wikicode syntax is okay), but I've removed the fluffy "clear supportive..." text.
Thoughts on these two? Theopolisme (talk) 21:15, 20 May 2014 (UTC)[reply]
  • I don't think that the comment boxes should be filled with any text that is intended to show up - if there is default text it is likely in the template itself. I've try to ignore the sample text, but it could be confusing to new reviewers - especially since the colour of the text is only slightly lighter than active text (at least on my screen). For the first while I kept trying to delete it. Maybe the comment box, if unused, could say <no comment entered> or something bland like that. When reviewing I have a word processor open with the most common comments that I like to write, and I copy, paste and modify to save typing. —Anne Delong (talk) 21:27, 20 May 2014 (UTC)[reply]
Right, that makes sense. My worry is that users wouldn't understand that they could enter wikicode in the comments, for example, or that they were signed automatically... Placeholder text in and of itself isn't something new (see the Search box in the upper righthand corner, for example :) ). Theopolisme (talk) 21:31, 20 May 2014 (UTC)[reply]
I've remove the fluff about being clear and supportive, since that's (to me) obviously unnecessary. We can continue to discuss other placeholders. Theopolisme (talk) 21:55, 20 May 2014 (UTC)[reply]

Feedback about the list of decline reasons

Dear Theo: As I've mentioned before, I have a 16:9 aspect ratio on my screen, and by the time the various toolbars and the large script bar are all displayed, only about 1/3 of the screen is left for content. When I open the list of decline reasons, it runs off the bottom of the screen, and I have to scroll up every time. On some of the similar lists displayed by other scripts, the list centres on the screen rather than popping down. I am not sure how difficult this would be to implement, and it's a low priority request, but it would save some people a step. —Anne Delong (talk) 21:36, 20 May 2014 (UTC)[reply]

Question re "Mark as reviewing"

Dear Theo: I know that when the blue "Under review" template is displayed, normally the script doesn't let another editor accept or decline. What about admins, though? Today I needed to override the title blacklist, which the accepting editor couldn't do. I just did a regular move, which worked, but if I had used the script "accept" function what would have happened? It would be nice if it would accept and credit the person who placed the hold, but would it at least accept? —Anne Delong (talk) 12:07, 21 May 2014 (UTC)[reply]

  • Anne, I find this as a good question. I've not looked at the code much, and I know that there is a fair amount of how to handle this type of situation and the situation when a page is SALTed. What is the status on both of those Theo? — {{U|Technical 13}} (t • e • c) 13:11, 21 May 2014 (UTC)[reply]
The salted situation is similar, yes, and also the case where there's a redirect at the target location. However, in either case, it wouldn't be good if the script just noticed that the person was an admin and accepted automatically. There's the situation in which the regular reviewer just happens to be an admin (or, I believe, a template editor in the case of the title blacklist), rather than having been called to help, so there should be some kind of very noticeable warning of the need to investigate the situation before accepting. —Anne Delong (talk) 14:21, 21 May 2014 (UTC)[reply]

Hi Anne! You say that when a page is under review, the script doesn't let another editor accept or decline – this shouldn't be the case, can you please verify? I just tested at Wikipedia talk:Articles for creation/Artelia (random page in the "under review" category) and the script still let me review it, as intended. I never wrote any code to prevent review of "under review" submissions, for precisely the reasons you specified. A warning notice is displayed, yes, but the user is not prevented from reviewing: if something different is happening, that's a bug. Theopolisme (talk) 20:48, 21 May 2014 (UTC)[reply]

AFAIK any reviewer can revert the "under review" template state to "waiting for review" - not only the one who put it under review. Roger (Dodger67) (talk) 21:03, 21 May 2014 (UTC)[reply]
I have just successfully done "Unmark as under review" on Wikipedia talk:Articles for creation/Artelia - it was "marked under review" weeks ago! Roger (Dodger67) (talk) 21:09, 21 May 2014 (UTC)[reply]
Sorry, this is my mistake, and I've wasted everybody's time (again). Of course until now I had no reason to want to review when the blue box was showing, and I thought from long ago, with the old script, that it was mechanically prevented. Now I can no longer see what things look like for a non-admin (weird, eh?). Maybe it was wishful thinking from that time when Arctic Kangaroo and Bonkers the Clown were grabbing all of the submissions within seconds of creation, and the rest of us could only review when they were asleep... —Anne Delong (talk) 22:06, 21 May 2014 (UTC)[reply]
  • It's a legitimate question Anne. Just because anyone could revert the change that added the under review template, doesn't mean that the script shouldn't have a mechanism built in that will allow someone to mark a draft as under review and then get a  Template editor or Admin to complete the request (tboverride or bluelock issues). — {{U|Technical 13}} (t • e • c) 22:19, 21 May 2014 (UTC)[reply]
Yeah, right now anyone can still review an under-review page. I've added "a mechanism for asking for TE/admin assistance" to my todo board... what do you guys think about another talk page that the script could automatically post to and that willing admins and template editors could add to their watchlist? The script would post details to that page (incl. type of protection, etc). (The script could even have some sort of "one-click" functionality built in, or rather a preloader...so in other words admins could click a single link and be brought into the accept interface of AFCH with data prefilled for easy accepting...) Thoughts? Theopolisme (talk) 22:41, 21 May 2014 (UTC)[reply]
Well, it's not as if there would be very many of these each day. A simple talk page would be fine, if a reviewer could click on something that would add a link to the page with a heads-up edit summary. Here's another possiblility: What if the click added a categgory or template to the page, and then a new line was added to the "Submissions" page, saying something like "Submissions needing admin attention". Then every time someone who was an admin started to do reviewing, they could see how many items were in the category and clear it out if not empty. It wouldn't depend on people checking their watchlist, and could be automatically removed when the article was accepted or declined. This would have the advantage of attracting only Afc reviewers, but have the disadvantage that frequent watchlist-checkers may be more likely to see the other kind of posting first. I'm not sure about the preload - the problem is that these need to be investigated: Why was the title blacklisted? Is the redirect empty, or does it already have multiple revisions in its history? Should another title be chosen? Which admin did the create-protecting, and are they willing to unprotect? etc. It may be quite a while before the page can be accepted. —Anne Delong (talk) 23:59, 21 May 2014 (UTC)[reply]
  • An advantage to the talk page idea is that users could add a comment (although I guess if a template were added to the page it could have a comment imbedded). Also, it could be used like a log if desired, with each item marked "done" or something, if that is considered necessary. Keeping it updated might be a extra work. —Anne Delong (talk) 00:10, 22 May 2014 (UTC)[reply]
I don't know if the feature is in this script, the old one would tag an existing redirect with "db-move" if it was blocking an accept. Perhaps unsalt and blacklist override requests could be handled in a simila or r way? Roger (Dodger67) (talk) 09:47, 22 May 2014 (UTC)[reply]
That makes sense, because we would be taking advantage of an existing process. It might be good to have this as an option - if there's a problem with a redirect, the script could display the reason, and provide a choice of adding db-move or not, since some reviewers may wish to do their own investigation and some may wish to just tag. Salted pages may be more problematic, since WP:SALT says to find an admin who was involved or do a deletion review. I suppose that an "admin help" template with an explanatory comment might throw the legwork of that onto a random admin that sees it and that might be okay. —Anne Delong (talk) 21:16, 24 May 2014 (UTC)[reply]

[0.8] Feedback about categories

In edit I accepted the article, but the script added the categories (category in this case) above the Persondata. (t) Josve05a (c) 13:25, 22 May 2014 (UTC)[reply]

Thanks for the report... trickier than it seems, so I'll be adding this to the todo list. Note to self: only occurs if there are already cats on page, based on logic in AFCH.Text.prototype.updateCategories... Theopolisme (talk) 22:25, 22 May 2014 (UTC)[reply]

Introducing... user preferences

Hey everyone,

Just a heads up that I had a burst of productivity and wrote a preference management system for the new script. Preferences can be accessed by clicking the "preferences" link next to "give feedback" on the main panel -- right now, there's not that much to customize (in fact, next to nothing) -- but now that the system is in place it will be very easy to add more.

@Technical 13, Anne Delong, and Hasteur: and many others, I'm open to any and all suggestions for features which should be made user configurable -- please feel free to brainstorm here! I've got a few listed here as well, scavenged from previous discussions. Thanks! Theopolisme (talk) 23:26, 23 May 2014 (UTC)[reply]

Ideas

  • A way to add (connect to) a Wikidata-item (e.g. Q30) when accepting articles. (This could be turned on in user preferences, since it is not "many" that will use it). (t) Josve05a (c) 23:30, 23 May 2014 (UTC)[reply]
    Bad idea... Unless you know the wikidata code prior to do the linking, You're grunteed at least one more edit to get the right linking. Furthermore adding the wikidata link is outside of enWP and is effectively automation on Wikidata, which I think we need to get some cast iron consensus on. Still Further, there's many specialized WikiData scripts for doing the linking so I almost wonder if this is duplicate? Hasteur (talk) 19:14, 24 May 2014 (UTC)[reply]
  • An option to make the "rewiev-window" hide/make the page "hard"-update after an action. (t) Josve05a (c) 23:31, 23 May 2014 (UTC)[reply]
  • I don't think I'll implement this; it's important for editors to be able to see the list of edits made by the script, since after all they are the people being held responsible for them. Theopolisme (talk) 14:48, 26 May 2014 (UTC)[reply]

Wikiproject banners

Dear Theo: There's a thread here: Wikipedia talk:WikiProject Articles for creation#Adding Wikiproject banners to drafts that may be of interest. I remember seeing a request for others to use the ability to easily add Wikiproject banners, without having to be AfC reviewers (NPP people, for example). I don't remember if the request was here, at the old script page, or somewhere else (sigh). Do you know if anything like that has happened? If not, would it be a problem to make that an independent module the could be called by other scripts or just used by itself? ....since you have nothing else to do.... —Anne Delong (talk) 23:40, 23 May 2014 (UTC)[reply]

I think that was requested at WP:VPT at some point. I've tracked the request and will look into it. Shouldn't be especially difficult, I just needed some prodding :) Theopolisme (talk) 23:52, 23 May 2014 (UTC)[reply]

Problems with "done" text never appearing

Moved from User talk:Theopolisme
So, I've just started reviewing with the new baby and noticed some of the submissions get stuck after "saving ***author's*** page". I have to manually reload them. Is it a problem on my side? E.g. Wikipedia talk:Articles for creation/Jhanvieh and Draft:Aaron Morris (comedian) to list just 2. FoCuSandLeArN (talk) 17:26, 20 May 2014 (UTC)[reply]
@FoCuSandLeArN: Hmm, I'm not able to replicate this on my end. For debugging's sake, could you tell me what your user agent is? ([3] is a website which easily provides this information). Thanks, Theopolisme (talk) 20:50, 20 May 2014 (UTC)[reply]
"Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/34.0.1847.137 Safari/537.36". FoCuSandLeArN (talk) 01:58, 21 May 2014 (UTC)[reply]
Thanks, that is useful. I will investigate further. Theopolisme (talk) 11:01, 21 May 2014 (UTC)[reply]
I'm having that problem with most submissions now. I include an example of one that doesn't pose that issue. Thanks for your help. FoCuSandLeArN (talk) 12:28, 21 May 2014 (UTC)[reply]

The puzzling thing is that I cannot replicate this behavior at all on my end. This problem has been reported before by others, though... Technical 13 (who has experienced the issue), do you have anything you can add to this bug report? I'd really like to figure out what's going on here before publicizing the script, since it's quite an annoying problem for all who experience it. My apologies, and thanks, Theopolisme (talk) 20:56, 21 May 2014 (UTC)[reply]

  • I've had similar issues with other non-related scripts as well and think it has something to do with parsoid, api editing, or some other thing out of our immediate control. I've not had the time to figure out what the exact cause is, nor have I had time to experiment and see if it only happens on specific browsers. I'll do some independent browser testing next week if I have a moment. It's the start of the summer semester and I'm trying to find out what I need to get done in all my classes so I can get ahead of the assignments a little before I spend too much time on wiki. — {{U|Technical 13}} (t • e • c) 22:22, 21 May 2014 (UTC)[reply]

After a few hours of debugging, I think I may have found a possible fix... Will post more details shortly. Theopolisme (talk) 23:33, 21 May 2014 (UTC)[reply]

@FoCuSandLeArN and Techncial 13: I've done some blind experimentation and hypothesizing...if you have a moment, please try the script again and let me know if anything has changed. I'm kind of shooting in the dark, but I have to start somewhere... :) Theopolisme (talk) 11:21, 22 May 2014 (UTC)[reply]

Now that the other issue has been dealt with, I'll have some time to return to this one. :) @FoCuSandLeArN: Could you please provide me with a page that you've recently reviewed which has had this error (as well as, if possible, the exact actions you performed)? Thank you, Theopolisme (talk) 16:57, 27 May 2014 (UTC)[reply]

Sweet. Draft:Frank Broomell Jr., just opened the page, clicked review with the new script, decline, inserted some comments into the box, decline, then stuck at "saved User talk:Jbeich8" "declining submission...". I noticed doing that adds a "#" to the URL, which I assume means that the article has been reviewed. It persists after I refresh the page, however if you go directly to Draft:Frank Broomell Jr., it no longer shows; I also assume this is somehow part of using the script, because it always appears. Hope this helps! FoCuSandLeArN (talk) 17:18, 27 May 2014 (UTC)[reply]
@FoCuSandLeArN: Could you possibly take a screenshot of what your window looks like when this happens (on the panel where the "saved <pagename>" stuff is shown)? (You can then upload it to somewhere like imgur.) Thanks for your help with this -- I'm just trying to ensure I can exactly replicate your scenario. Theopolisme (talk) 18:26, 27 May 2014 (UTC)[reply]
  • If you can manage to open up your developer console as well before you review a draft, there may be a key piece of information Theo or I will see there that can help figure out the problem... — {{U|Technical 13}} (e • t • c) 18:31, 27 May 2014 (UTC)[reply]
  • I hope this satisfies both requests. I didn't know what tab to click on the console, so I took screenshots of the "Console" and "Elements" (which was the default one) tabs. Let me know if this is not enough. FoCuSandLeArN (talk) 00:13, 28 May 2014 (UTC)[reply]
  • Ahh. yes, I believe that will be kind of helpful... It is saying that there is an undefined function and "pages" can not be found in this function which makes me think it is an api call of some kind. Theo, what do you think? User:Technical 13

Problem with frequently-used declines

Moved from User talk:Theopolisme
  • It would also be nice if the helper knew which our most-used criteria were, and list them as a top-10 before the other ones. I think that's what you intended with the current layout, but its based on general AfC statistics, right? Because my top 5 aren't the ones appearing there. I know nothing about coding, so I might be way off here... FoCuSandLeArN (talk) 00:21, 23 May 2014 (UTC)[reply]
  • Actually, what you suggest is pretty much what I originally implemented in the script! The "frequently used" list at the top of the decline menu builds itself as you decline submissions, based on your personal decline habits, by storing a list of the number of times you use each decline rationale. If this doesn't appear to be working, let me know, though, and I can check out if there's some sort of logging error and it's not picking up your declines... It only works with declines made using the rewrite, so it will take a while for you to make enough declines to create a useful dataset. Theopolisme (talk) 00:32, 23 May 2014 (UTC)[reply]
  • Yeah, it doesn't seem to be logging them correctly as far as I can tell. It should have a decent sample size by now. I also wanted to point out that the previous problem also happens for comments. Regards, FoCuSandLeArN (talk) 19:20, 23 May 2014 (UTC)[reply]
  • @FoCuSandLeArN: Okay, that's weird. What do you see in the "Frequently-used declines" list? Also, while we're at it, can you do me a favor and let me know the output of this debugging statement?
  • In Chrome, load the Wikipedia Main Page.
  • Open the JavaScript console by pressing Ctrl-Shift-J ([4] has more instructions)
  • In the text prompt next to the blue right arrow, type mw.user.options.get( 'userjs-afch-decline-counts' ); and press enter
  • Please copy and send me the text that it outputs in response.
Thanks very much for your help with this, and sorry it wasn't working as desired. Theopolisme (talk) 20:40, 23 May 2014 (UTC)[reply]
  • "{"music":3,"joke":1,"cv":1,"corp":2,"lang":1,"exists":1,"adv":1}" is what appears. Exist and adv do not come up on the actual list I see when I load it. If I were to give an estimate of what I think those should honestly be, I would say nn, bio and corp are my most used by a big margin. I am bemused as to why lang, cv or joke are there; I seldom use those. No worries, this is how we make things better! Thanks for your dedication, FoCuSandLeArN (talk) 19:34, 25 May 2014 (UTC)[reply]
This is interesting, mainly because I can't replicate it, which makes it all the more difficult. :/ @Technical 13: can you also look at AFCH.userData.get( 'decline-counts' ) just in case that's returning different results?
Also... if you'd like to be really helpful, could you set AFCH.consts.mockItUp = true; in your console before using the script, then simulate a single decline (just do it normally -- it won't actually decline the page, though, because you've enabled mocking), and compare the value of decline-counts (via userData) before and after and seeing if it changes based on what you did?
Thanks again guys. This is a very weird bug -- I just did exactly what I described above and everything worked flawlessly. Theopolisme (talk) 23:46, 25 May 2014 (UTC)[reply]
  • I'm not sure about that...
mw.user.options.get( 'userjs-afch-decline-counts' );
"{"music":1,"context":1,"adv":1}"
AFCH.userData.get( 'decline-counts' );
ReferenceError: AFCH is not defined
AFCH.consts.mockItUp = true;
ReferenceError: AFCH is not defined
is what I got back (haven't attempted a decline yet). — {{U|Technical 13}} (t • e • c) 23:57, 25 May 2014 (UTC)[reply]
@Technical 13: Uh...that means AFCH was never loaded...you are on an AfC-applicable page, right? :P Theopolisme (talk) 00:01, 26 May 2014 (UTC)[reply]
  • Theo, of course... (ZzzzZZZZzz)
Long image of technical crud no-one really understands no matter how much they say they do...

File:Test results (test set 1).png

— {{U|Technical 13}} (t • e • c) 00:11, 26 May 2014 (UTC)[reply]
@Technical 13: Cool. So it looks like there it *is* recording an update, which is a start. When you reload or go to another page, does that `nn: 1` persist? Theopolisme (talk) 00:18, 26 May 2014 (UTC)[reply]
By the way, to clarify why mw.user.options and AFCH.userData have different results: mw.user.options is only populated once on pageload by MediaWiki. I implemented some frontend caching in userData so that results are reflected immediately (mw.user.options is set via api request). Theopolisme (talk) 00:21, 26 May 2014 (UTC)[reply]
Long image of technical crud no-one really understands no matter how much they say they do...

File:Test results (test set 2).png

— {{U|Technical 13}} (t • e • c) 00:34, 26 May 2014 (UTC)[reply]
  • Okay, so I ran a couple tests, and when I selected the decline reason from the list of "frequently used" up top, it registered the decline on AFCH.userData.get( 'decline-counts' ); but forgot about it when I reloaded the page. When I selected the decline reason from the static list below, it registered and remembered. — {{U|Technical 13}} (t • e • c) 00:47, 26 May 2014 (UTC)[reply]
  • @Technical 13: Hmm, I can't replicate that, and I don't see where in the code it would be possible for that situation to occur, given how we treat the "frequently used" as identical to normal declines (same <option value='x'>...in fact, they are literally clones of the other elements). Could you try again and ensure that wasn't just a random occurrence?
Feel free to take a look at the code, too -- maybe I'm just missing something obvious because I've been working with it for so long. displaying the reasons in the list, incrementing the counters, AFCH.userData implementation. Theopolisme (talk) 01:02, 26 May 2014 (UTC)[reply]
	if ( declineCounts[declineReason] ) {
		declineCounts[declineReason] += 1;//Why not just// declineCounts[declineReason]++;
	} else {
		declineCounts[declineReason] = 1;//This triggers an internal red flag for some reason
	}

Theo:

Long image of technical crud no-one really understands no matter how much they say they do...

File:Test results (test set 3).png

I will do some more testing in the sandbox tomorrow when I'm awake as to not be disruptive and not using mock up mode. Good night good sir. — {{U|Technical 13}} (t • e • c) 01:52, 26 May 2014 (UTC)[reply]

Screenshot of what to do in FireFox

Anne Delong report

  • Just out of curiosity, what does mw.user.options.get( 'userjs-afch-decline-counts' ); return for you per the instructions above? If you are using Firefox instead of Chrome, it is ctrl+⇧ Shift+k to access the console where you type in the code. — {{U|Technical 13}} (t • e • c) 22:25, 25 May 2014 (UTC)[reply]
Yes, I am using FireFox - trying not to contribute to megacompanies taking over the world - and using your keyboard shortcut I was able to access the console. I haven't done this before, so I didn't see an obvious place to paste in the code. Sorry, the only web programming I've done besides HTML, CSS and Wikicode is server side stuff. —Anne Delong (talk) 23:02, 25 May 2014 (UTC)[reply]
(oh, yeah, and Java, but that had to be compiled) —Anne Delong (talk) 23:15, 25 May 2014 (UTC)[reply]
@Technical 13: You need to re-license that file as CC-BY-SA 3.0, because it has Wikipedia-text (this disussion) on it. (t) Josve05a (c) 00:26, 26 May 2014 (UTC)[reply]
  • Okay, silly mistake - the text input box was hiding behind my task bar. I moved it to the top and voilà! Here are the results:
mw.user.options.get( 'userjs-afch-decline-counts' );
"{"lang":1,"corp":2,"cv":2,"test":2,"not":1,"blank":1}"
mw.user.options.get( 'userjs-afch-decline-counts' );
"{"lang":1,"corp":2,"cv":2,"test":2,"not":1,"blank":1}"
mw.user.options.get( 'userjs-afch-decline-counts' );
"{"lang":1,"corp":2,"cv":2,"test":2,"not":1,"blank":1}"
—Anne Delong (talk) 00:12, 26 May 2014 (UTC)[reply]

I wonder if data is being erased at some point in time... since it looks like new data is added correctly, and then disappears... just thinking aloud. Theopolisme (talk) 00:34, 26 May 2014 (UTC)[reply]

  • That's likely right. According to my contributions, in the past week I have accepted nine submissions, declined eight, and postponed 15. I've also been using the script for making comments and cleaning submissions. Some of my Afc work has bypassed the script: changing old submissions into redirects, moving sandboxes to Draft, fixing format problems, adding reflists, deleting G13s, etc. Off-wiki musical events, WP:IEG committee work, learning to do history merges and undeletions, etc., have also been keeping me away from the queue. —Anne Delong (talk) 01:56, 26 May 2014 (UTC)[reply]

Analysis

@Technical 13: I'm not even going to pretend I can look at the console logs without my eyes glazing over. Could you summarize your findings, perhaps? Thanks so much for all your help. Theopolisme (talk) 14:49, 26 May 2014 (UTC)[reply]

  • Theopolisme, my eyes were glazing over too... What I found is that section of the script works flawlessly in mockup mode, but not in live mode. I will need to do some more testing to isolate the steps to reproduce every time, and I'm too brain blah to do it today... — {{U|Technical 13}} (e • t • c) 18:16, 26 May 2014 (UTC)[reply]
  • Depends on how techy and JS knowledgeable you are. You are welcome to go to the AFC sandbox, open up your console and try all kinds of different things to see if you can isolate when the script counts the decline and when it doesn't. Will need to test each reason (standard and frequent list versions both), and test with mockup on and off... Many, many tests to see which reasons (in which section) fail in which modes... — {{U|Technical 13}} (e • t • c) 19:14, 26 May 2014 (UTC)[reply]

Okay, cool! Thank you T13 :) I'm able to replicate the "not working in real mode" issue with a decline as "adv" and will look into it further tonight. Being able to replicate the bug is most of the battle -- I'll try to knock this out. :) Theopolisme (talk) 23:15, 26 May 2014 (UTC)[reply]

I spoke too soon. It worked flawlessly the second time I tried a decline as adv in real mode. This is so strange. Theopolisme (talk) 23:41, 26 May 2014 (UTC)[reply]

@Technical 13: Can you try this behavior out and see if you can replicate what I get:

  • Decline a page using a decline reason for the first time (i.e. one that isn't listed in decline-counts)
  • Examine AFCH.userData (it should include the updated item)
  • Now reload the page once, and examine AFCH.userData (the item should appear to disappear from the list)
    If you decline the page *now*, the item will be lost and overwritten *for real*, so DON'T DO THAT, instead...
  • Reload the page *again*! The old items might appear now in the list... if so, stop, otherwise:
  • Use the script to perform another action on the page (say, comment or submit).
  • Then reload *again*. The previously missing items should reappear now.

Any luck with this? Rather convoluted, I know, but something I encountered pretty consistently... is MediaWiki caching the values of mw.user.options and not pushing out an updated version until the page is purged (or edited), perhaps? Theopolisme (talk) 23:55, 26 May 2014 (UTC)[reply]

Debugging console

Update: I've modified the script to print out the values of userData and mw.user.options whenever the main panel is loaded (so initial load and whenever you hit "back to options"). Hopefully this will make debugging a bit easier.
I've been replicating this on testwiki (not consistently, though). Just looking for a pattern... :) Theopolisme (talk) 02:23, 27 May 2014 (UTC)[reply]
  • On this note, it would be cool if there was an independent debugging console that returned all kinds of information that could be useful for submitting bug reports. I'm also wondering if all this stuff we are saving in the browser's local storage shouldn't be saved on an actual page, ya know, for if people use multiple browsers or computers, or review only at the library/cafe/etc? This way the script will work consistently for them no matter where they are. I understand that mw.user.options should be saving it to their logged in user account, but that may not always be the case or they may use two accounts (a secure one and one for insecure locations). This presents its own new feature option: being able to specify a location for the configuration settings. Otherwise it may appear that the feature (and the saving of user preferences) doesn't work at all to some non-tech people. — {{U|Technical 13}} (e • t • c) 17:29, 27 May 2014 (UTC)[reply]
  • I don't know, I feel like that might be over-complexifying things. mw.user.options does work for the overwhelming number of cases, and with our net of fallbacks I find data loss quite unlikely. I'd rather avoid editing wikipages if possible, plus the value for multiple accounts just doesn't seem to be worth the development effort at this point in time. Theopolisme (talk) 18:17, 27 May 2014 (UTC)[reply]

I think I may have an answer

@Technical 13: Further simplified process for replicating the bug:

  1. Decline the submission once using the script.
  2. Now reload the page. If the decline appears not to be counted, continue reloading the page repeatedly. Eventually the decline will show up in the counts list.

And... that's it. In short, ResourceLoader occasionally serves cached versions of mw.user.options. This is almost certainly a bug, but not with AFCH. Rather, it's with MediaWiki itself and its ResourceLoader caching infrastructure. This explains why the issue has been so difficult to replicate -- if the user reloads/browses to other pages enough times before their next decline, the old cache will expire and update itself, and the problem won't occur.

I hope this makes some sense -- T13, let me know if you think I've missed something, since I may just be very tired and desperate to latch onto a solution (any solution!), but I have tested this quite a bit and it's always been the case that enough reloads update the cache. Thoughts? Next steps? (Bugzilla?) Theopolisme (talk) 02:54, 27 May 2014 (UTC)[reply]

Resolution: this bug should now be resolved -- or rather, at least worked around. I've added *another* layer of AFCH caching (via localStorage). Here's the explanation I added to the source code, if you're interested: 

The reason for this redundancy is because of an obnoxious
little thing called caching. Ideally the script would simply
use mw.user.options, but *apparently* MediaWiki doesn't always provide
the most updated mw.user.options on page load -- in some instances, it
will provide an stale, cached version instead. This is most certainly a
MediaWiki bug, but in the meantime, we circumvent it by adding numerous
layers of redundancy to the whole getup. In this manner, hopefully by
the time we have to rely on mw.user.options, the cache will have been
invalidated and the world won't explode. *sighs repeatedly*

And here's the commit in which the issue should be resolved. Basically it just relies on the user visiting pages that *aren't* already cached in order to force an update to mw.user.options. This should probably be a bug, though. :P Aaccttualllyy... Legoktm, could you possibly help redirect this to wherever it needs to go? I don't really know who deals with caches and varnishes and ResourceLoader and whatnot, but the tl;dr is that mw.user.options isn't always updated when the page is reloaded.

Thanks to T13, Anne, and FoCuSandLeArN for your help in hunting down this issue! Theopolisme (talk) 04:16, 27 May 2014 (UTC)[reply]

  • I've only read the post I was pinged in but that makes sense as to why I got two different results for my first batch of reviews (v then music). Certainly implies a caching issues. — {{U|Technical 13}} (e • t • c) 12:10, 27 May 2014 (UTC)[reply]

Feature request: add maintenance tags to beginning of article

Moved from User talk:Theopolisme

Reviewers will also appreciate a box to append maintenance templates at the beggining of articles, which at the moment seems only possible for categories. FoCuSandLeArN (talk) 21:39, 25 May 2014 (UTC)[reply]

Thanks -- on the top of the todo list! Theopolisme (talk) 14:45, 20 June 2014 (UTC)[reply]

Feedback about the AFCH script

Dear Theo: I used the script many times today and ABSOLUTELY NOTHING WENT WRONG. What's up with that? —Anne Delong (talk) 22:21, 25 May 2014 (UTC)[reply]

<discussion about a technical problem merged into the applicable thread @ 14:54, 26 May 2014 (UTC)>

I really just started this thread to cheer Theo up because this page has so many postings about problems that he must get tired sometimes. —Anne Delong (talk) 01:56, 26 May 2014 (UTC)[reply]

@Anne Delong: Thanks, I definitely appreciate the sentiment. :) 1.0, here we come -- albeit slowly. Then again, I checked a week or so ago and it looked like over 4,000 edits had been made with the new script, certainly something to smile about. We're getting there! Theopolisme (talk) 04:35, 26 May 2014 (UTC)[reply]

Automatically open the review panel on AfC submissions (again)

I don't want it to automaticly open while in "Editing-mode", only when viewing the actual draft. (t) Josve05a (c) 09:05, 28 May 2014 (UTC)[reply]

Hi, thanks for the report. Given that (at least when I was doing research 6 months or so ago) a fair number of editors reviewed using edit mode, I'm not sure if autoopen should be restricted to view mode. If it's an important concern for you, we can certainly solicit feedback from other reviewers as well. Theopolisme (talk) 13:56, 28 May 2014 (UTC)[reply]
Another way could be "checkboxes" in he prference-menu, so that every user can personally decide if they want it to open automaticly n different places:
Automatically open the review panel on AfC submissions
  • When viewing the submition
  • While viewing the history
  • While checking diffs
  • While editing the submition
That way, we can make sure that everybody is happy (except you who has to code it...)
(t) Josve05a (c) 14:11, 28 May 2014 (UTC)[reply]

(edit conflict) I don't follow. What does Josve mean exactly? FoCuSandLeArN (talk) 14:13, 28 May 2014 (UTC)[reply]

  • He means that he wants to be able to select what views the script automatically loads in (it's a user preference). Josve, I feel that is option bloat and should be avoided. That being said, I agree there should be "some" compromise. Perhaps a dropdown with "never autoload", "only when &action=view", "always autoload"? — {{U|Technical 13}} (e • t • c) 14:55, 28 May 2014 (UTC)[reply]

Heads up

Sorry to spring this on everyone, but User_talk:Theopolisme#Heads_up:_no_internet_access_until_June_19th. Thanks! Theopolisme (talk) 14:57, 28 May 2014 (UTC)[reply]

Enjoy your vacation, Theo! —Anne Delong (talk) 15:33, 28 May 2014 (UTC)[reply]

And I'm back! I've got a few things waiting for me first, and then I'll be able to get back to work on the reports here. Thanks, everyone! Theopolisme (talk) 14:21, 20 June 2014 (UTC)[reply]

Blank custom decline

Hello. I used AFCHRW to do a "custom" decline, but the field returned blank: [5]. Cheers (Google Chrome Version 35.0.1916.114 m, Windows 7, Vector Skin). --LukeSurl t c 20:41, 4 June 2014 (UTC)[reply]

LukeSurl, thanks for the report. I couldn't replicate this when I tried it; could you try again (use WT:AFC/sand if you'd like) and let me know if the problem still exists (along with details for reproducing it)? Thanks, and sorry about that, Theopolisme (talk) 14:44, 20 June 2014 (UTC)[reply]

[0.8] Feedback about the arrow <

I know I have said this before... The arrow ('<') Next to the "comment"-button is out of place for me on Firefox. It is inside the yellow button and not in the "white space".

User-Agent: Mozilla/5.0 (Windows NT 6.2; WOW64; rv:32.0) Gecko/20100101 Firefox/32.0 (t) Josve05a (c) 00:57, 5 June 2014 (UTC)[reply]

[0.8] Feedback about cleaning the submission

I tried twice to clean Draft:Leighton Pierce, but the script just said "Working..." for a long time. I eventually reloaded the page, but it was not cleaned. —Anne Delong (talk) 14:31, 9 June 2014 (UTC)[reply]

I have a hunch this has to do with our other problem with declines above. FoCuSandLeArN (talk) 14:51, 9 June 2014 (UTC)[reply]
  • It certainly does, and if you can check your error console and report back any error messages for JavaScript or Security that you see (screenshots are awesome, feel free to email them to me at my wiki username at yahoo or post them on commons or something). — {{U|Technical 13}} (e • t • c) 14:59, 9 June 2014 (UTC)[reply]

[0.8] Feedback about "next draft" options

I see the rewrite doesn't offer any link for the "next" draft or to "review another" I'm thinking about this, and it would be nice to offer a small selection of possible "next" drafts. I'm thinking; "Next oldest", "Next smallest", "Next largest", and possibly (if there are any) "Next misplaced". — {{U|Technical 13}} (e • t • c) 22:31, 10 June 2014 (UTC)[reply]

[0.8] Feedback about cleaning (ref befor/after dot)

In this edit it changed [1]. to .[1]. (t) Josve05a (c) 00:07, 12 June 2014 (UTC)[reply]

Thanks, I've tracked this and will be investigating soon. Theopolisme (talk) 14:42, 20 June 2014 (UTC)[reply]

[0.8] Feedback about create-protection

Good start with the warning the page is SALTed. But... Where the "accept" button should be, there needs to be a "recheck" button, and it wouldn't hurt if there was a button or link to allow the user to request unprotection directly from the form. I'll expand a little later on my ideas of how this would all come together, need more coffee... — {{U|Technical 13}} (e • t • c) 16:13, 15 June 2014 (UTC)[reply]

@Technical 13: Yeah, we have talked before about a button that auto-posts a message to WT:AFC -- or at least, it's in trello :) If you can firm out a spec for how it should work (i.e., create a template it should amend to the page), I'll be happy to implement this -- seems like a very useful feature. Cheers, Theopolisme (talk) 14:35, 20 June 2014 (UTC)[reply]
  • Wouldn't it make more sense to submit the request directly to WP:RFPP like Twinkle does to request the page be unprotected or the move be made? When I have a little free time, I can pull the code for this out of MediaWiki:Gadget-twinkleprotect.js and reflow it a little for our use. The major part of this request is to have it be a clickable "recheck" button so that the reviewer can get everything ready and keep rechecking to see if the page is protected (once they make their request for unprotection) and submit their accept once the protection is removed. — {{U|Technical 13}} (e • t • c) 15:10, 20 June 2014 (UTC)[reply]

Notification of a change to the preload template comment that AFCH(RW) removes

Moved from user talk:Theopolisme. Theopolisme (talk) 14:25, 20 June 2014 (UTC)[reply]

Hey Theo, I know you won't be back for a couple more weeks, and it "shouldn't" be too big an issue, but I'm notifying you per the editnotice nonetheless that I have edited Template:AFC_submission/Substdraft to wrap the comment in a {{subst:Void}} so that the comment should disappear on its own when they click save and I changed the case of a couple key words like "new template will appear on the BOTTOM of the page" and "the draft template will still be on the top but IT IS OKAY TO IGNORE IT" (not exactly the words, but conveys the jist of the changes) so that we won't get so many "I'm confused by the two templates contradicting each other" type reports. Anyways, hope to see you back soon and figure you should know of the changes (which I expect the RW removes the comment /i anyways). — {{U|Technical 13}} (e • t • c) 14:09, 6 June 2014 (UTC)[reply]

Ordering adjustments

Moved from WT:AFCH. Theopolisme (talk) 14:25, 20 June 2014 (UTC)[reply]

I noticed two small ordering "problems". First, added categories seem to be placed before the default sort instead of after it (where living person and DOB are placed): [6] Second, biography should always be the first WikiProject tag (ahead of the AfC tag) on talk so that the BLP message appears on the top of the page instead of in the middle of other tags: [7].

Thanks, ThaddeusB (talk) 19:08, 8 June 2014 (UTC)[reply]

Thanks for the report! I've tracked both of these issues and will be getting to them soon. Theopolisme (talk) 14:41, 20 June 2014 (UTC)[reply]

stubs and tags

Moved from WT:AFCH. Theopolisme (talk) 14:25, 20 June 2014 (UTC)[reply]

I've accepted a couple stubs today, and I'm noticing there is no longer a tagging feature built into AFCHRW that allows me to add stuff to the top of the page (yes, it's a pain to remember them all and properly format them sometimes, but it was nice to have the option). I'm also noticing that when I select "Stub-class", it's not applying a general or wikiproject specific stub template to the bottom of the article like I would expect it to. I know Theo is gone for another 10-11 days, and maybe I'll have a moment to try and add some of these abilities myself (but don't hold your breath :p). — {{U|Technical 13}} (e • t • c) 19:55, 8 June 2014 (UTC)[reply]

I second re-adding these features if it can be done reasonably easily. --ThaddeusB (talk) 00:00, 9 June 2014 (UTC)[reply]

I have tracked the append/prepend text option in trello and will be getting to it soon -- it's at the top of the todo list. I think that we should think some more about a "stub tagging" workflow. It would be a hugely useful feature: I envision an input similar to the add categories one, except (of course) for stubs. @Technical 13: Are you at all familiar with current stub tagging scripts (which we/I could study for ideas on how exactly this would work)? Theopolisme (talk) 14:40, 20 June 2014 (UTC)[reply]

  • I'm not aware of any, but I'm sure we could find one or two. I'm guessing we could use morebits to post to the top of the page like Twinkle does when tagging. This would reduce the number of wheels that need reinvention I would think. — {{U|Technical 13}} (e • t • c) 15:01, 20 June 2014 (UTC)[reply]
Retrieved from "https://en.wikipedia.org/w/index.php?title=Wikipedia_talk:WikiProject_Articles_for_creation/Helper_script/Rewrite&oldid=613698537"