MediaWiki talk:Gadget-PatrollingEnhancements.js

I don't use the red deletion reason box and find it a bit intrusive. What JS disables it while retaining the other patrolling enhancements functionality? DCDuring TALK 03:39, 8 April 2012 (UTC)Reply

Can you clarify which part you want to disable, exactly? :

• Just the dropdown? (So the only way to enter a deletion reason is by typing it?)
• Just the freeform text input? (So the only way to enter a deletion reason is from the dropdown?)
• Both of these? (So you can't enter a deletion reason at all, and it will always supply a default?)
• The whole deletion mechanism? (So you still get the blue M buttons to mark edits as patrolled, but not the red D buttons to delete pages?)

Also, do you want it disabled everywhere (e.g., on Special:RecentChanges), or only on Special:Watchlist?

—Ruakh_TALK 19:48, 8 April 2012 (UTC)Reply

The box appeared at the bottom right corner of the browser window when I was viewing my watchlist. I will e-mail you a screenshot. This one thing is all that I hope to be rid of. Note that it takes up two lines. DCDuring TALK 22:40, 8 April 2012 (UTC)Reply

Thanks for the change. If anyone else wants it hidden, add

GPE.hideDeleteReasonDropdownOnWatchlist = true;

to your common.js, an optional user subpage. DCDuring TALK 15:12, 9 April 2012 (UTC)Reply

If the most recent change, to exclude "log entries", excludes changes to Liquid threads, great! If not, that's something else to consider, because LT diffs can't be patrolled, either (can they?). - -sche (discuss) 04:05, 21 July 2012 (UTC)Reply

Hi,

I've got a revised version at User:Krinkle/MediaWiki:Gadget-PatrollingEnhancements.js you should check out, and if it works for you, copy it :). Here's a summary of what I did:

• Don't use new Object()
  • Done, since I don't care either way, and you apparently do. —Ruakh
• Remove trailing comma's (invalid syntax, crashes IE
  • Done, thanks! —Ruakh
• Put curly brackets at end of line instead of new line (in some languages it doesn't matter, it does matter in JS)
  • I disagree. —Ruakh
• Remove redundant curly block brackets where there is no operator (e.g. no if, else, function etc.). There is no block scope in javascript, this isn't Java (Java and JavaScript are not related, the name is a joke).
  • I'm aware that there's no block scope in JavaScript, but thanks for your condescension. It makes me feel warm and fuzzy. —Ruakh
• Use jQuery(document).ready instead of the long-deprecated addOnloadHook
  • You have long claimed that addOnloadHook is deprecated, but you have refused to explain how or by whom. Do you just mean that you deprecate it? —Ruakh This reply was wrong; see below. —Ruakh
• The OR and AND operators in JavaScript don't return boolean, it functions like a DEFAULT operator. 0 || 5 returns 5, not true. Therefore I changed patterns like foo ? foo : bar to foo || bar which make sense in javascript.
  • I agree with this change, as you describe it; however, your use of the term "patterns" confuses me. I see only two instances of the ternary operator on this entire page, and only one of them is changeable in this way. Is there something I'm not seeing? (I'll change that one, anyway.) —Ruakh
• These operators can be used in if-statements as well, naturally so I changed the 5-level deep nested if-statement into an && operator. Also makes the indention a bit more sane.
  • I prefer the current version, obviously. (It's not as though I was somehow unaware of &&; I just think it's cleaner and more readable this way.) —Ruakh
• Using wgPageName is not a reliable way to detect special page. Firstly because their names have slightly changed over the years, secondly because they are translated on non-English wikis which makes the script very useless on other wikis. By using wgCanonicalSpecialPageName
  • Do I understand correctly that although the names of special pages can change over time, and are different on foreign-language wikis, you're saying that the canonical names will never change, and are the same everywhere? If so, then this is a good point — but I notice that even your improved version still depends on Special:Contributions and User:. I think I'll leave the current version in place for the moment, and give this a bit of thought, before deciding how to proceed. —Ruakh
• Using pageids is not a reliable way to identify pages. Firstly because when a page is deleted (to fallback to the default message for MediaWiki:Deletereason-dropdown) it will no longer have a page id, and when it is then edited again it gets a new id. And secondly, on other wikis it will obviously have a different ID all-together. Changed script to use titles=MediaWiki:Deletereason-dropdown instead in the API query.
  • Your specific advice doesn't help all the situations that you describe, but your point is a good one. There's a separate API request to retrieve a system-message; so, I'll just change this to retrieve the Deletereason-dropdown message, and then this will work whether or not the message has been customized. —Ruakh
• Change wiki-text like comments into javascript doc blocks. Wikitext is no longer parsed in previews for javascript pages (e.g. <pre> and == have no effect.
• Be a bit more liberal in whitespace, these gadgets are now delivered in minified form, so comments and spaces do not add up bandwidth. I've applied the whitespace linter from JSHint.com as that one appeared to most closely match the whitespace usage that this script had so far (I just made it a bit more consistent)
• Various other small best practices

See also:

• JavaScript Deprecations
• Change log and migration guide
• List of mw.config variables
• JavaScript Code Conventions
• JSHint

Krinkle (talk) 17:33, 21 September 2012 (UTC)Reply

Hi, thanks for the effort. Unfortunately, when I copy your new version into the edit-window and click "Show changes", the diff is unusable, because the lines don't match up at all. Since I'm certainly not going to take your version without reviewing all of the actual differences, this means that your effort is largely wasted. :-/
However, I'll go through your comment above, and implement some of the bullet-points.
Thanks again,
—Ruakh_TALK 17:43, 21 September 2012 (UTC)Reply

Put curly brackets at end of line instead of new line (in some languages it doesn't matter, it does matter in JS)

I disagree. —Ruakh

Well, I boldly said that it matters. It isn't really a matter of opinion. Putting them on the next line is syntactically different and will cause troubles when you least expect it. This isn't a style choice, it is the nature of the language. It is dangerous to mix (good) habits from one language with another.

The OR and AND operators in JavaScript don't return boolean, it functions like a DEFAULT operator. 0 || 5 returns 5, not true. Therefore I changed patterns like foo ? foo : bar to foo || bar which make sense in javascript.

I agree with this change, as you describe it; however, your use of the term "patterns" confuses me. I see only two instances of the ternary operator on this entire page, and only one of them is changeable in this way. Is there something I'm not seeing? (I'll change that one, anyway.) —Ruakh

It may have very well been only 1 or 2 instances. I explained it anyway as general advice for your self-education.

Use jQuery(document).ready instead of the long-deprecated addOnloadHook

You have long claimed that addOnloadHook is deprecated, but you have refused to explain how or by whom. Do you just mean that you deprecate it? —Ruakh

addOnloadHook, together with the rest of the globally exposed legacy functions in "wikibits.js" have been unmaintained since 2007 and deprecated since early 2011. This is documented on mw:ResourceLoader/JavaScript Deprecations and written in the release notes of MediaWiki 1.17. They will be removed in a future version, do not use them any more. There will be another announcement when that is going to happen, but please read mw:ResourceLoader/Migration guide (users) thoroughly and stay up to date, so that instead of keeping up with removals of years-old deprecated features, you can keep up with the latest new ones. That way if there are issues with something new, you can catch it early on, and not 2 years later when you finally migrate seconds before something is removed. This way you also prevent any last-minute stress or breakages if you miss an announcement. Scripts in a MediaWiki environment are very different and a fair bit more complicated than traditional programming because you don't control the environment, don't decide which versions or which dependencies are available etc. The community as a whole all runs on the same version, so it is your responsibility to keep up with announcements and upgrades in the software. The web is moving forward fast. We can only do so much whilst other scripts are left behind unmaintained. I hope you understand.

PS: If you prefer mailing lists, I'd recommend you subscribe to mail:wikitech-ambassadors.
Krinkle (talk) 13:17, 10 December 2012 (UTC)Reply

Re: Curly brackets on the next line: I was aware that "It isn't really a matter of opinion", but I thought it would be more polite to say that I disagree than to inform you that you were simply wrong. (I hoped it might inspire you to notice that the code currently works, despite the supposed syntactic difference.) Well, anyway, the cat's out of the bag now, so let me be clear: you are mistaken. There are only a few situations where JavaScript will infer a semicolon due to a line-break, and this is emphatically not one of them.

Re: Deprecations: Oops, I'm sorry, I owe you an apology. A few years back a WMF employee with the username Kaldari (talk • contribs) tried to convince us that we should eliminate our importScript function on the grounds that MediaWiki provides and deprecates another function with the same name and similar behavior; I confused you with him/her, and your advice with his/hers. I now realize that you are not the same person, and that you're referring to a function that is genuinely defined only by MediaWiki (in wikibits.js) and not by us. I apologize for my annoyed response above on this point; and, thank you for your links on the subject.

—Ruakh_TALK 18:02, 10 December 2012 (UTC)Reply

Following this edit, I can mark edits as patrolled like usual, but I can no longer delete pages using the patrolling gadget (the red "D" button); I get the error message "notoken: The token parameter must be set". That's using Firefox on Windows XP. If I can help you troubleshoot the issue, let me know. - -sche (discuss) 22:21, 1 January 2013 (UTC)Reply

Oh, oops, darn it, it looks like mediaWiki.user.tokens.get('...') only works for editToken, patrolToken, and watchToken. Sorry about that, I'll fix it. —Ruakh_TALK 02:19, 2 January 2013 (UTC)Reply

O.K., fixed, I think. (Please let me know.) And, thanks for pointing this out. —Ruakh_TALK 02:23, 2 January 2013 (UTC)Reply

Yep, deletion works again, and patrolling works as always. Thanks for fixing it. - -sche (discuss) 06:45, 2 January 2013 (UTC)Reply