I can replicate on https://bn.m.wikivoyage.org/wiki/%E0%A6%89%E0%A6%87%E0%A6%95%E0%A6%BF%E0%A6%AD%E0%A7%8D%E0%A6%B0%E0%A6%AE%E0%A6%A3:%E0%A6%A8%E0%A6%BF%E0%A6%AC%E0%A6%A8%E0%A7%8D%E0%A6%A7_%E0%A6%AA%E0%A7%8D%E0%A6%B0%E0%A6%A4%E0%A6%BF%E0%A6%AF%E0%A7%8B%E0%A6%97%E0%A6%BF%E0%A6%A4%E0%A6%BE_%E0%A7%A8%E0%A7%A6%E0%A7%A8%E0%A7%AA/%E0%A6%A8%E0%A6%BF%E0%A6%AC%E0%A6%A8%E0%A7%8D%E0%A6%A7_%E0%A6%A4%E0%A6%BE%E0%A6%B2%E0%A6%BF%E0%A6%95%E0%A6%BE - I can look into the associated gadget later and suggest a fix.

This is still occurring at a significant rante - mostly on bn.m.wikivoyage.org and en.m.wikivoyage.org
so I assume a gadget there also needs to be updated.

We did it for PHPUnit tests as reflected on https://doc.wikimedia.org/cover-extensions/ .

Change #1081448 merged by jenkins-bot:

[mediawiki/core@master] Simplify code to avoid interpreting "$" characters in string replacement

https://gerrit.wikimedia.org/r/1081448

I took the opportunity to replace the other occurrence in mediawiki/core.

That's neat, I like it.

Change #1081448 had a related patch set uploaded (by Gerrit Patch Uploader; author: Anne Haunime):

[mediawiki/core@master] Simplify code to avoid interpreting "$" characters in string replacement

https://gerrit.wikimedia.org/r/1081448

Change #1080320 merged by jenkins-bot:

[mediawiki/core@master] live preview: Do not add edit/view-source link for special pages

https://gerrit.wikimedia.org/r/1080320

Change #1080323 merged by jenkins-bot:

[mediawiki/core@master] TemplatesOnThisPage: Do not show non-functional link for special pages

https://gerrit.wikimedia.org/r/1080323

I couldn't reproduce this at first – special page transclusion does not result in those links being shown. I eventually figured out that the links are produced by Scribunto's mw.title getContent() method. I think that's the real bug here, and I filed a task about it: T377530: Scribunto mw.title getContent() method can record templatelinks to special pages (but I still approved your patches here, as it seems reasonable to handle this case – maybe recording special page transclusions is made to work one day, or maybe no one ever fixes that Scribunto bug).

Thanks Od1n, very appreciated, I should do that for my local wiki also sometime. There are still some remaining extensions and I've got busy with some other things but overall this went well I think. Thanks

Change #1069544 merged by jenkins-bot:

[mediawiki/extensions/Kartographer@master] build: Updating npm dependencies

https://gerrit.wikimedia.org/r/1069544

I have removed all uses on frwiki (I handled the remaining cases I mentioned above) and on frwiktionary (there was only one occurrence).

Change #1080323 had a related patch set uploaded (by Ammarpad; author: Ammarpad):

[mediawiki/core@master] TemplatesOnThisPage: Do not show non-functional link for special pages

https://gerrit.wikimedia.org/r/1080323

I think we also need to duplicate this for the non-live preview version. There's no error in that case, but a non-functional 'view-soure' link is always shown.

Change #1080320 had a related patch set uploaded (by Ammarpad; author: Ammarpad):

[mediawiki/core@master] live preview: Do not add edit/view-source link for special pages

https://gerrit.wikimedia.org/r/1080320

Change #1071846 merged by jenkins-bot:

[mediawiki/extensions/MultimediaViewer@master] Use browser provided URL object instead of mw.Uri

https://gerrit.wikimedia.org/r/1071846

Change #1074726 merged by jenkins-bot:

[mediawiki/extensions/TocTree@master] Use ES6 features

https://gerrit.wikimedia.org/r/1074726

In T40932#10221678, @SD0001 wrote:

In https://gerrit.wikimedia.org/r/1078975, @Jdforrester-WMF wrote:

Note that this feature isn't Parsoid-DOM compatible (compare https://hu.wikipedia.org/wiki/Sablon:K%C3%B6nyvsorozat_infobox?useparsoid=0 and https://hu.wikipedia.org/wiki/Sablon:K%C3%B6nyvsorozat_infobox?useparsoid=1)

I see ext.pygments.view is not being loaded in Parsoid DOM, even though we are adding the module to ParserOutput via the parser hook. I guess something else needs to be done for Parsoid compatibility?

I have removed the majority of uses of "mw.Uri" on frwiki.

Change #1078975 merged by jenkins-bot:

[mediawiki/extensions/SyntaxHighlight_GeSHi@master] Fix styling for code blocks with copy buttons next to floated content

https://gerrit.wikimedia.org/r/1078975

In https://gerrit.wikimedia.org/r/1078975, @Jdforrester-WMF wrote:

Note that this feature isn't Parsoid-DOM compatible (compare https://hu.wikipedia.org/wiki/Sablon:K%C3%B6nyvsorozat_infobox?useparsoid=0 and https://hu.wikipedia.org/wiki/Sablon:K%C3%B6nyvsorozat_infobox?useparsoid=1)

Ok, thanks to getAll() it can be achieved, just a very tiny bit less conveniently:

In T374314#10129809, @matmarex wrote:

Also, worth noting that mw.Uri and URL treat duplicate query parameters when parsing differently.

uri = new mw.Uri('http://example.com/foo?a=1&a=2')
uri.query.a // => [ "1", "2" ]
uri = new mw.Uri('http://example.com/foo?a=1&a=2', {arrayParams: true})
uri.query.a // => "2"

url = new URL('http://example.com/foo?a=1&a=2')
url.searchParams.get('a') // => "1"
url.searchParams.getAll('a') // => [ "1", "2" ]

Change #1069544 had a related patch set uploaded (by Jforrester; author: Libraryupgrader):

[mediawiki/extensions/Kartographer@master] build: Updating npm dependencies

https://gerrit.wikimedia.org/r/1069544

Just slam _addItem into "allowedGlobals": [] in the jsdoc.json and it'll work fine.

Any new insights? If createEntityView in wikibase.ui.entityViewInit.js shall not be called from commonswiki, maybe we should simply return from this function if mw.config.get('wgWikiID') === 'commonswiki' && mw.config.get( 'wgCanonicalNamespace' ) === 'File'