Thu, Nov 26
Mon, Nov 23
Sat, Nov 21
Mon, Nov 16
Sat, Nov 14
Fri, Nov 13
@DannyS712 Sorry, I realize in my haste I wasn't fully clear: I meant a page protected only by virtue of being transcluded, not the page that is directly cascade protected. See, e.g., https://test.wikipedia.org/w/api.php?action=query&format=json&prop=info&titles=Page4242&intestactions=edit%7Cmove
Nov 2 2020
Duplicate of T265763, I believe
Oct 31 2020
Oct 28 2020
Oct 24 2020
Superficially, this looks related to T256466? AFAICT that looks to have been resolved sometime in the last week or so, so I can't confirm the message I received there, but the (fractional?) request url here would suggest a different pathway.
@Fomafix Can you still see this? I'm no longer able to replicate it, so I'm hoping this got fixed somewhere.
Oct 21 2020
It is: the AbuseLog entry won't be crossed out and italicized, but it should have a trailing (hidden because revision has been deleted), which is accurate. It will still show up as "visible" in the search filter since it was not explicitly hidden, but it remains tied to the revision. That is, if the revision is unhidden, the AbuseLog entry will be as wel.
Oct 18 2020
Oct 17 2020
There is no justification for preventing administrators viewing or restoring this.
Thanks for the bump @Umherirrender, I've been meaning to comment that yes, I haven't run into it at all and even after removing my safeguards, don't trigger it anymore so seems great on my end AFAICT.
Oct 16 2020
Oct 15 2020
Sep 22 2020
Sep 20 2020
FWIW, it looks apihelp-stabilize-param-watchlist needs adding to all the i18n pages. Presumably it can just copy the text used everywhere by apihelp-*-param-watchlist in core?
Sep 19 2020
Sep 18 2020
The difference, though, is that history-deleted is marking text that is used as a stand-in for the hidden user name in a history or diff, whereas this text is presented in addition in order to provide some information, as the username is not displayed on each li on Special:Contributions. This text is thus (potentially) the only marker on Special:Contributions that a revision has had just the username revdel'd. Removing it would be harmful: the main reason I opened this was so that scripts could detect hidden usernames on a contribs page, but even in normal usage, it's the best way to confirm that a user's revisions have been sufficiently hidden.
...history-deleted will gray and cross-out the message, which is not what would be wanted here.
Please explain why. I'd rather have the behavior be consistent (for things that are basically the same) than introduce new arbitrary class.
Sep 15 2020
Sep 8 2020
That's a good bet, AFAICT, but hundreds of times?! It's clicking the button that adds the term and reloads, so getting to hundreds or even dozens seems unlikely from manual use. There are currently only seven users importing it so if so it should be easy to nail down, especially given the tight timeframe today.
Aug 30 2020
I think script authors should do some existence check instead of blindly assuming relevant user is set always.
Aug 8 2020
Aug 7 2020
If it were up to me, I'd say it's better to have it defined; any script/etc. that's dependent on wgRelevantUserName (to, say, add links or lookup user info) wouldn't work otherwise. The target user is known, regardless of whether the viewer can manipulate the Special page in question. At the very least, there should be agreement.
- Be a non-sysop user, including logged-out
- Go to Special:Block/Jimbo (the actual account being "viewed" doesn't matter)
- mw.config.get('wgRelevantUserName') -> Jimbo
- Go to Special:DeletedContributions/Jimbo (the actual account being "viewed" doesn't matter)
- mw.config.get('wgRelevantUserName') -> null
I think you might be missing the "non-sysop" part? For a non-sysop, Special:Block defines the name, and links are provided in the sidebar for logged-in users (contributions, logs). For Special:DeletedContributions, this is not the case.
Jul 26 2020
Isn't this expected behavior? /w/index.php is the default entry point, but wmf rewrites article paths to look pretty. /w/index.php?diff= does just what I'd expect with an empty or missing parameter diff parameter: it takes you to the latest diff of the page, which, when unprovided, defaults to the main page.
Jul 24 2020
@Scott Is there a reason you removed DeletedContributions?
Jul 20 2020
Seems a reasonable to me
Jul 15 2020
(belated but) I think that's T213837
Jul 14 2020
Jul 10 2020
Jul 8 2020
Jul 6 2020
Looks great to me! Not sure about usability, etc., but then again it's modern not vector so might be fine.
Re: modern, see also T246931
Jun 28 2020
Jun 26 2020
Jun 25 2020
Is there a good reason for users to be notified and asked to change #searchGoButton to #searchGoButton, #searchButton before #searchButton is even available? I would think we should wait until the transition state is available. Won't the tech new notice and tagging here before #searchButton is usable mean more work for diligent users, who will have to someday remove #searchGoButton in a second edit? Somewhat similar to my comment at T254797#6234392.
Jun 22 2020
Isn't it already present in the "view logs for this page" link? Although I'm somewhat confused given the links you provided.
Jun 21 2020
So, the plan is to replace #searchGoButton with #searchButton, to match Vector? If that goes forward, can I suggest renaming the search button id as well? If not, that would mean monobook and modern would have #searchButton and #mw-searchButton, which is surely rather confusing.
Jun 20 2020
Jun 18 2020
This connects to multiple other tasks, but if I may add to MusikAnimal's excellent summary of the creation of a menu, one other thing is that AFAICT there wasn't a point where making one change would both account for this change and not leave deprecated classes. Specifically, wmf.36 didn't require the new stuff, but it did require that menu and vectorMenuCheckbox be present. It's not a big deal since it's not a common situation, but does require follow-up after wmf.37 if someone wants to be clean and remove the deprecated classes.
Jun 17 2020
Jun 15 2020
Jun 13 2020
Duplicate of T255018 ?
Jun 11 2020
Getting login errors at enWiki with perl's MediaWiki::API, seems related? I happened to be testing something, so I think I can pinpoint the issue to between 14:32 and 14:38 EDT.
Jun 9 2020
Jun 8 2020
FWIW, the inclusion of the . for the class selector means this will miss JS pages that reference the class directly. I imagine there are unlikely to be many, but Twinkle gadgets are one of them.
@Jdlrobson Presumably this will include .vectorMenuCheckbox -> .vector-menu-checkbox (added in T253329/https://gerrit.wikimedia.org/r/c/mediawiki/skins/Vector/+/59784) or is that to be done separately? I note that T254797 doesn't mention it in the search query.
May 21 2020
May 19 2020
Sorry, I missed the reversion and conversation thereof. Presumably inclusion of cactions would change the list of pages needing updating, whenever it goes through?
Two quick questions:
May 18 2020
May 16 2020
Isn't the issue with that that the partial block API accepts invalid pages? I think it matters but it'd be a different task.
May 14 2020
I think most gadgets will either prefer or fall-back to #content (on enWiki, only the gadget for T54810 will need tweaking, I think), but I'm not sure about user scripts and css. There's obviously not as healthy an ecosystem for modern-only gadgets, and a quick search suggests most js are old popup-clones, but I would imagine personal css will be messed up. A notice, at least, would be warranted.
May 12 2020
@Jdlrobson It's the [a-z][a-z][a-z]\s*\[role bit; select2 has option[role=group which matches ion[role. With that knowledge, it looks like there are a handful of other false positives.
Could you clarify "have to"? Beyond the thousands of links above, I specifically note the select2.min.css pages, which is an external library that shouldn't conflict, and AFAICT from grep doesn't actually contain div anywhere...
May 2 2020
May 1 2020
Apr 19 2020
Apr 4 2020
Mar 31 2020
Mar 28 2020
I'd go with Wikipedia:Administrators' noticeboard: it's the main place for sysop-related concerns and notices, and is tracked pretty heavily by everyone so it's a common place for such notices. There could be arguments for other places, but AN makes the most sense to introduce and take folks' temperature.
@Ammarpad Maybe I'm missing something, but this is for the length of the page (e.g. 42 bytes) where as T218802 is/was for the number of revisions (e.g. (42 revisions)). I suppose they'd both need to be stored but they are different tasks.
I vaguely recall there being a bit of a concern when enWiki's massblock userscript was first introduced (circa 2010), although I think it was more concerned with someone going rouge than a security risk (different times...). Our ability to handle such things has markedly improved since then (bureaucrat removal of sysop, steward corps, block user who blocked you, etc.) but even ignoring that, that script has been noted in the new admin's guide since at least 2015 so I don't think there's been much a concern there (although it's unclear how many folks, especially old hands, ever read/read it). Absence of evidence != evidence of absence and all that, but just to say that the userscript hasn't been cranked about lately.
Mar 27 2020
@Guywan: The OP brings up the fact that, since the only thing available to distinguish each individual item are the href and title, it can be difficult to style any one in particular, since those are localized. The set of links isn't the same, mind you; they vary according to the viewing user's usergroups. children, etc. isn't the same for everyone, everywhere (maybe 0 and -1 are?).