So if I understand it correctly, when sandbox'ing is applied, it always gets a transient origin, which means that upon each request the origin effectively changes and thus there is no caching right ? And the only way around it is using a separate domain without sandboxing ?

I think the message should be modified. This is not a very friendly message. Especially with that "localhost" which might freak out a dev 😉 (my initial thought: why is Wikipedia trying to connect to my localhost). Jokes aside, the message does suggest there is problem on my side but – as I understand – this is mostly a backend problem. So maybe log some details to JS console or a tooltip or something...

I also found this in whatwg spec:

<iframe sandbox src="https://usercontent.example.net/getusercontent.cgi?id=12193"></iframe>
[Warning!] It is important to use a separate domain so that if the attacker convinces the user to visit that page directly, the page doesn't run in the context of the site's origin, which would make the user vulnerable to any attack found in the page.

Use a separate but unsandboxed domain (en.wikipedia.wikimedia-usercontent.org or something like that) that internally resolves to the same wiki (with similar effects to the "sandbox mode" mentioned above, except it wouldn't do sandboxing, just relying on the origin / registrable domain being different). This would of course vastly increase the effort required (buying the domain, setting up DNS rules, certificates, a bunch of changes to site configuration...).

Clam and others supported by 95.8% of browsers globally:

The quick fix for this particular case is to update the URL in Toolhub to the un-encoded value of https://commons.wikimedia.org/wiki/File:Logo_Dzień_Nowego_Artykułu_Orem_version.svg. I have done this at https://toolhub.wikimedia.org/tools/dna/history/revision/46196/diff/48064 and the desired icon is now rendering.

Thanks for the fix. That seems like a less invasive way then I wanted to do it.

Ci/cd configuration can be separated. For example I have a Jenkins installation of which configuration is not accessible to anyone. Jenkins pools GitHub and runs Wikiploy. That Wikiploy script can be in a separate repo if I need to. There is no problem in that.

So I kind of actually implemented this myself 🙂

Does that mean you cannot reach non-mobile https://pl.wikipedia.org/wiki/Specjalna:Różnica_mobilna/71469982 anymore? Because I can.

I assume modules and templates using the classes are also affected, right?
https://pl.wikipedia.org/w/index.php?search=insource%3A%2Fmw-ui%2F&title=Specjalna:Szukaj&profile=advanced&fulltext=1&ns8=1&ns10=1&ns828=1

Petscan also depends on this. Or to be more exact it assumes calback parameter is available to avoid CORS issues.

Hi. @Aklapper this shows that Wikipedia:Portal wikipedystów also triggers the switch of skin from monobook (prefered by Cuku New) to default (V'22).

If supporting negation perhaps it should be thought about more broadly and apply to all options (see also T342532)

Hm... I guess the parser part can be more universal. But I think having gadgets not in main namespace would help with budgets etc more. I assume most people, most of the time, probably visit only the main namespace.

For the performance sake could you support namespace!=0 syntax?

@Jdlrobson done. Didn't help, but I guess maybe cache? (purge didn't help though)

For Polish Wikipedia all disambiguation pages have {{Ujednoznacznienie}} on top and the page preview fails for them.

Seems like tags with explicit display:none are removed. So the problem was not the span with class (like I assumed). I've modified our template and it should work now.

I think .noexcerpt should be added explicitly to templates (rather then implicit, default class for Phonos).

Did you ever thought of using NodeJS?

@AlexisJazz Seems I found a way, if that helps. They have some rules for addresses/page title as seems.

	wgPageContentModel:"sanitized-css"
	wgRelevantPageName:"Template:Legend/Style.css"

@Izno Actually NavFrame is used on all year pages for collapsing navigation in a nice and more accessible way (both for sighted users and for users using screen readers and for mobile UX). But if you think you can do it with the default then we can discuss that. We can discuss that on WP:BAR:TE or on the template's page. In general default collapsing is visibly slower to load though.

A table with all this data would be great too. I mean something like:

{|
|-
! gadget !! size [KiB] !! zipped [KiB]
|-
...
|}

login.toolforge.org is not working too (even after flushing local dns). So no way to ssh into TS.

In T111565#9149907, @AlexisJazz wrote:

In T111565#9141090, @Msz2001 wrote:

In T111565#9141088, @matmarex wrote:

In T111565#9139046, @Msz2001 wrote:

It's worth noting that mobile MediaWiki already supports collapsible class, which is almost the same as mw-collapsible in appearance.

That doesn't work for me. I don't think it's a MediaWiki feature, but it's a fairly common on-wiki customization (older than mw-collapsible).

Ah, appears that you're right. I must have missed the on-wiki code that supports it.

On English Wikipedia it's part of https://en.wikipedia.org/wiki/MediaWiki:Common.js but Common.js doesn't load on mobile.

Curiously, plwiki (which appears to be your home wiki?) has https://pl.wikipedia.org/wiki/MediaWiki:Mobile.js to enable collapsible elements on mobile. While shorter, it's less efficient than the gadget proposed on enwiki and won't work when the page content is refreshed e.g. after editing a page.

[edit]
Oh, you created that page! I'd actually suggest you install https://en.wikipedia.org/wiki/Wikipedia:MakeMobileCollapsible#Installation_on_other_projects as it's more efficient than loading the module unconditionally on every page load.

This code is used on wikisource:

var mwskin = mw.config.get('skin');
var parentId = mwskin === "vector-2022" ? 'p-associated-pages' : 'p-namespaces';
var item = mw.util.addPortletLink( parentId, '#', "Lorem ipsum");
if (item && mwskin === "vector-2022") {
	item.classList.add('vector-tab-noicon');	// v22
}

I think you're looking for https://toolhub.wikimedia.org/tools/patchdemo ?

Isn't this what the Beta-Cluster is for?

The example book looks terrible on my monitor in Vector '22:
https://fr.wikisource.org/wiki/Criton_(trad._Cousin)?match=en

I believe that code is more likely to have a valid maintainer name. The same applies to documentation within code, as you might have noticed. This has been my experience at least. Documentation in comments tends to be more up-to-date in general, not just in the context of Wikipedia scripts.

The goal of this task was really to encourage someone who had never edited before to try editing for the very first time. We tried to design the task in a way that was extremely simple and really limited user options / limited decision fatigue. The good news is it really does help more new account holders try editing for the first time: Add a link Experiment analysis. And the good news is that although the task is fairly limited, newcomers do seem to progress on and try new types of editing: Newcomer task edit type analysis.

Two more things missing (worse then Quarry):

Is there any tutorial on how to use the Superset? I tried to run a simple query on plwiki but initially failed to find a database. It would be helpful to have a welcome page that explains how to find databases or add the same links Quarry has in the menu.

Changed hideSidebar upstream. You can update uk.wiki.
https://pl.wikipedia.org/wiki/Wikipedysta:Nux/hideSidebar.js

This could be extended for all types of edit tasks I think. Like when you want to add a picture, but maybe not as just image in the body, but in the infobox. Or I want to add an image and add an alt text and some links.

Sorry, I wasn't able to test it before the review. I will need to install the latest MW, but not sure when will I have enough time to do so as I am on and off from home...

I just noticed that 8301136545 works, but weirdly, the ISBN which you get back in the citation (9788301136543) does not work! Is it just that the isbn 13 isn't in their search database (despite that obviously they know about it because they're returning it) do you think?

Maybe it would be more useful to spit back interpretation of what was entered. You know like now when enable ES6 it says that on the special page ("This gadget is only supported on ES6-compliant browsers") and other thing like that. So like that, but show even a dump of options on a preview of changes or something. I guess an editor would solve that too (like for TemplateData).

Something you can use for things like popups:

// popups
// only on devices that can hover (not on touch-only)
if (!window.matchMedia("(hover: none)").matches) {
	importStylesheet('MediaWiki:Gadget-navpop.css');
	mw.loader.using( "mediawiki.api,mediawiki.user,mediawiki.util,user.options,mediawiki.jqueryMsg".split(',') , function() {
		importScript('MediaWiki:Gadget-popups.js');
	});
}

The thing with en.wiki is probably that they get most of the stuff done by WMF. For example, many enhancements were made in the new Vector specifically after the mutiny on en.wiki. This is not a reproach; it just partly explains why they have fewer default gadgets. This also might explain why Wikisource usually has more gadgets than Wikipedia. WS has weaker support in general, and more features need to be added by the community.

Does that mean gadgets will still be available for all skins by default? So this would be a default gadget for all skins and targets?

wikiflex [ResourceLoader | hidden | default] | wikiflex.css

In T328610#8974807, @Jdlrobson wrote:

I do think on the long term we should replace targets in gadgets for a more sophisticated system. I like the idea from @Tgr for using skip functions - that seems more in line with what we actually want here. These skip functions could potentially be predefined so you might have a gadget that requires support for touch devices (ReferenceTooltips might benefit from that for example) that could mark itself up like so:

gadget.name[ResourceLoader|default|skipIf=TOUCH_DEVICE]

So to be clear this will cause a bug:

hideSidebar [ResourceLoader | skins=vector,monobook | targets=desktop ] | hideSidebar.js
MobileMaps[ResourceLoader|targets=mobile]|mobilemaps.js

This will be fine:

hide-rollback [ResourceLoader | rights=rollback | targets=desktop,mobile ] | hide-rollback.css | hide-rollback.js

On that note, there is a new color-mix function in CSS:
https://developer.mozilla.org/en-US/docs/Web/CSS/color_value/color-mix

So this is called multiple times uw.ui.Upload.prototype.load = function (uploads).

There are too many files-added events.

Reproduction with images.

More detailed steps to reproduce:

The scripts are not re-downloaded every time you view a page, and there is no need to add any bcache, maxage or smaxage parameters to MediaWiki urls, these do not improve performance anymore. Performance is our default, as much as possible.

Note that on Village pump someone mentioned that the i18n menu doesn't work in Opera GX so that is kind of weird. I don't have that one but I tested with IE on Windows 10 (via Edge).

There is a green light from Zotero devs and the Polish National Library is now available:
https://github.com/zotero/translators/pull/3036

As I understand below would work, but AFAIK was not merged:

@Esanders That is helpful for other stuff... but none of that works for discussion tools.

@KFrancis I sent you an email. Please let me know if it didn't arrive or something else would be needed.

I've confirmed the steps above break refs.

This is still a regular thing. I think this might be happening for all named refs when the first ref doesn't have cite-body.

Sent an e-mail signed with my PGP, fingerprint: 86C84A9B865FDD51FCFB12D2EE3F8013A0DD3792.

analytics-privatedata-users is the wrong group and SRE-Access-Requests is the wrong workflow here. What you want for (especially client) log access is Logstash access which can be received via the nda LDAP group which is required via LDAP-Access-Requests.

In T336297#8859823, @Mvolz wrote:

In T336297#8846443, @Nux wrote:

Did you consider using LoC or some other national library?

Most if not all big libraries should support OAI-PMH. OAI can be used as a dump (kind of) to get all book descriptions and keep them on some Wikimedia server.

Most big libraries have some API which you could use directly to search for ISBN. Many probably use Z39.50 which is not very friendly, but doable for ISBN searches. Polish national library (BN) also has a custom API that support JSON, XML and MARC (but it is a custom API, so probably better for a local tool or gadget then a global search service).

Thanks for your suggestion! For the time being we have have enabled Zotero's ISBN endpoint internally which primarily uses Library of Congress (T336727)

With Zotero it would be possible to support other national libraries in addition by contributing a translator for them here: https://github.com/zotero/translators

In T336952#8863202, @Nux wrote:

[...]
I also narrowed down the problem.

• This is a minified Lua that is problematic: https://pl.wikipedia.org/wiki/Modu%C5%82:Kontrola_autorytatywna/temp
• This is a test page: https://pl.wikipedia.org/wiki/Wikipedysta:Nux/test_WD-KA_fail_-_mini

Please note that you will not be able to edit or view the test page until you disable the Lua module (e.g. change the name of the main function).

You may have seen my tests. I've re-enabled the KA template (the Lua call) for a while and it's a very popular template. I've disable the Lua call for now, but please note that it doesn't solve the problem.