User Details
- User Since
- Feb 18 2015, 1:31 AM (506 w, 6 d)
- Availability
- Available
- LDAP User
- Unknown
- MediaWiki User
- Nirmos [ Global Accounts ]
Aug 1 2024
Apr 12 2023
Apr 4 2023
Apr 1 2023
Mar 30 2023
Feb 17 2023
Jun 29 2022
Apr 18 2022
Jan 6 2022
If I understand the intention of the task and the logic in https://gerrit.wikimedia.org/r/c/mediawiki/core/+/749580/5/includes/skins/Skin.php#153 correctly, it is missing && !$this->getRequest()->getRawVal( 'oldid' )
Dec 20 2021
Nov 23 2021
Oct 21 2021
Oct 18 2021
There were 235 pages listed on https://sv.wikipedia.org/w/index.php?title=Special:UnconnectedPages&limit=250&offset=0&namespace=0
Sep 18 2021
Aug 9 2021
Aug 5 2021
Jul 27 2021
Jun 21 2021
Jun 14 2021
Jun 2 2021
May 12 2021
Apr 30 2021
Apr 19 2021
There are no links on MediaWiki:Gadgets-definition
Apr 14 2021
This was resolved in T266298.
Sounds like this can be done with a throttle set to page. See https://www.mediawiki.org/wiki/Extension:AbuseFilter/Actions#Throttling
Apr 10 2021
Hey, @Zabe! Thank you so much for taking a look at this, and so quickly too! I'm unsure if this should be added to wgSemiprotectedRestrictionLevels too. I'm not sure what that does, but the other projects that have extendedconfirmed also have that listed in wgSemiprotectedRestrictionLevels. I'll defer to @Urbanecm on this one.
Mar 30 2021
Mar 24 2021
Maybe I should also add that the filter has correctly ignored actions that are sparse enough for the filter's throttle.
Mar 18 2021
Mar 17 2021
async function is part of ECMAScript 2017 ("ES8").
Mar 12 2021
Is there a list of all patches merged in 1.36.0-wmf.34?
Going through Flow patches in 1.36.0-wmf.34 we find https://gerrit.wikimedia.org/r/c/mediawiki/extensions/Flow/+/668777/ but that looks unrelated to me, which makes me believe that the error is in some other extension or core.
When I reported this, the bug did not manifest on svwiki like https://sv.wikipedia.org/w/index.php?title=Wikipediadiskussion:Flow&action=history but now it's on svwiki too, which means the fault is in 1.36.0-wmf.34
...but this is still strange. From https://phabricator.wikimedia.org/source/mediawiki/browse/master/includes/actions/HistoryAction.php
omg, I figured it out: So, Flow does not load mediawiki.interface.helpers.styles at all. VisualEditor does. From https://phabricator.wikimedia.org/diffusion/EVED/browse/master/extension.json
"dependencies": [ "ext.visualEditor.core", "ext.visualEditor.mediawiki", "ext.visualEditor.diffing", "mediawiki.Title", "mediawiki.interface.helpers.styles", "mediawiki.user", "mediawiki.util", "mediawiki.jqueryMsg", "mediawiki.storage", "mediawiki.pulsatingdot", "mediawiki.skinning.content.parsoid", "mediawiki.widgets", "ext.visualEditor.switching", "ext.visualEditor.welcome", "oojs-ui.styles.icons-editing-advanced" ]
If the user unchecks "Enable the visual editor and the new wikitext mode in Structured Discussions" in https://www.mediawiki.org/wiki/Special:Preferences#mw-prefsection-editing and then goes to https://www.mediawiki.org/w/index.php?title=Talk:Compatibility&action=history the parens aren't there.
I've tried my best to investigate this, without any luck. Part of that might be because I'm not familiar with less. What I've found is:
- .comment--without-parentheses is defined in https://phabricator.wikimedia.org/source/mediawiki/browse/master/resources/src/mediawiki.interface.helpers.styles.less
I'm assuming that the problem and solution is the same as T137383 / https://gerrit.wikimedia.org/r/294701
Mar 11 2021
Mar 10 2021
Mar 9 2021
That's amazing, Catrope!
Mar 8 2021
On second thought: Forget about wgServer and wgServerName. Just give us location.host which differentiates between desktop and mobile.
If I am to investigate a technical problem I need:
- Wiki (wgServerName)
- Browser (navigator.userAgent)
- skin
- wgAction
- wgNamespaceNumber
- Any JavaScript error
- Any special page (wgCanonicalSpecialPageName)
Feb 22 2021
Feb 18 2021
I do believe this was declined in T152731.
Feb 3 2021
Jan 29 2021
Does this task also cover the fact that there are two radio inputs in a row on intermediate revisions, or should I open a new task about that?
Jan 27 2021
This is not necessarily something I personally recommend, but some projects load scripts from the user namespace in the MediaWiki namespace. An okay-ish example would be this search on enwiki and then searching on the page (ctrl-F) for User:. This finds for example https://en.wikipedia.org/wiki/MediaWiki:Gadget-wikEdDiff.js that imports https://en.wikipedia.org/wiki/User:Cacycle/wikEdDiff.js
Jan 25 2021
Jan 18 2021
Or just remove ⟨red-link-title⟩
Jan 13 2021
I think the only possibly legitimate reason to do this would be to get the title without " (page does not exist)" for redlinks. See for example https://sv.wikipedia.org/wiki/MediaWiki:Gadget-MarkDeletedPages.js and https://sv.wikipedia.org/wiki/MediaWiki:Gadget-NormaliseraSignatur.js that have to remove " [inte skriven än]". The fact that some user scripts may modify the title attribute is not a good enough reason to do this, in my humble opinion, as the same script could just as easily modify the data attribute as well.
Jan 11 2021
Dec 13 2020
Nov 30 2020
Same as T178356?
Nov 24 2020
Nov 22 2020
Nov 9 2020
What system message would be different in Indian English compared to British English?
Nov 4 2020
Oct 17 2020
Sep 27 2020
The category https://en.wikipedia.org/wiki/Category:Pages_with_non-numeric_formatnum_arguments is being populated but it is not listed on https://en.wikipedia.org/wiki/Special:TrackingCategories. How is this possible?
Sep 21 2020
I think someone or something turned 8 to 80 in namespaces in the URL to global-search.toolforge.org above. Let's see if this works instead: https://global-search.toolforge.org/?q=\%24.%2B\%3C(div|span|form|p|a|label|table|tr|th|td|th|thead|tfoot|tbody|small|strong|em|i|b)[^%3E\n]*%2F\s*%3E[^\n]*\%3C®ex=1&namespaces=8
Sep 6 2020
Aug 11 2020
Why do some of the test urls go to mediawikiwiki if this task is about cawiki? For example the first one with blockOptions. If I enter
mw.loader.load( 'https://meta.wikimedia.org/w/index.php?title=User:Mike.lifeguard/blockOptions.js&action=raw&ctype=text/javascript' );
in the console on https://www.mediawiki.org/wiki/Topic:Vlxq3or3tf4p1ozv I get "Uncaught ReferenceError: wgCanonicalSpecialPageName is not defined", just as the task says, but that is because mediawikiwiki has turned off global JavaScript variables (T72470). That does not happen on cawiki.
They aren't used anywhere in the cawiki User namespace either:
blockOptions
addTools
TwinkleGlobal
After a quick investigation, none of the following seem to be used anywhere in the cawiki MediaWiki namespace:
blockOptions
addTools
TwinkleGlobal
Jul 28 2020
@daniel , @BPirkle is this because of MCR / T212428 / 9bd04f784566?
Jun 16 2020
svwiki used to be in report-only. It no longer is. It has broken recently (this year). None of the patches I link to indicate that this is intentional.
https://deployment.wikimedia.beta.wmflabs.org/wiki/Main_Page has a content-security-policy header, but no content-security-policy-report-only header.
Maybe I should add that this worked in January. There are two CSP-related patches to CommonSettings since then. First https://phabricator.wikimedia.org/rOMWCa31cfb5a177a2cebbf786f74bdde604458a9867c on February 25 and then https://phabricator.wikimedia.org/rOMWC203f468dcdf3f07aa6f2c25bd7486861f8a95af4 on March 16. Neither patch makes any mention of removing the existing report-only for production wikis in their commit messages.