In T325201#8544686, @thiemowmde wrote:

Isn't the process that rules that are new or more strict than before (which is something we regularly do, not only because of eval) get disabled by the update bot via an exclude in .phpcs.xml? This can then be improved (e.g. replaced with individual exclusions per line) any time later. If a release is "breaking" or not shouldn't be that relevant because of this.

In T238285#7981540, @Xover wrote:

@BBlack The last status update on this bug was ~18 months ago, and indicated the issue was an upstream bug and you were following up there, with a fallback to a WMF-specific patch if upstream got stuck. I see no indication there is any question this behaviour is a bug (cf. eg. Krinkle's comment above). It's also a problem that makes certain pages inaccessible on all projects, breaks contribution histories and other core features for certain users, and necessitates manually prohibiting a character in page and user names that is intended to be permitted.

IOW: an update would be appreciated.

In T252980#8515577, @TTO wrote:

Patch was merged, @DannyS712 any further action required on this task?

In T166010#8352145, @Ladsgroup wrote:

I have been creating a lot of patches here which can be spammy for everyone subscribed to this ticket. I'm moving them to T321882: Reduce number of files directly under includes/

@Bawolff is this still an issue with the latest version of codesniffer (40.0.1)?

In T222042#8476252, @Tgr wrote:

Is there anything left here, other than making the sniff default?

@pwangai do you have any updates? This makes it a bit hard to review patches relating to test coverage

Cross link T266890: Establish a regular release process for codesniffer

In T324914#8459055, @Novem_Linguae wrote:

I think that sounds great. Let's move forward with that. cc @kostajh in case they have any input.

I can do this if we want. I have some experience with there being a vue version of the javascript separate from the non-vue version, and allowing switching between the two, but perhaps it would be easier if for now we don't change Special:NewPagesFeed at all and instead create the new version at, eg, Special:VueNewPagesFeed and then when the time comes simply rename it?

Okay, thanks for explaining

In T324619#8454463, @Krinkle wrote:

Set is ES6 whereas we require ES5 at the low level of mw.loader. The feature test in startup has a list of browsers versions that pass the current feature test, many of which do not support ES6.

The compatibility page describes what we are willing to fund support for. This is different from what passes the feature test at a technical level. The cut off for caring about the outcome is Grade C not Grade A.

In T324618#8449291, @Krinkle wrote:

Sounds good to me. Can do the same with console.error in mediawiki.base/log.js.

Happy to tackle this myself just wanted to make sure I wasn't missing anything with removing the fallback, if its okay with the performance team I'll send a patch.

Happy to tackle this myself just wanted to make sure I wasn't missing anything with removing the check, if its okay with the performance team I'll send a patch.

If it wasn't clear, from what I recall my Vue version has all of the JavaScript logic for the feed, not just a mockup - it actually works

In T265559#8440348, @HouseBlaster wrote:

Can this be closed as invalid?

I'm not around enough to tackle this myself, but a while ago I wrote a Special:NewPagesFeed implementation in vue at https://en.wikipedia.org/wiki/User:DannyS712/VueNPP.js that uses WVUI but should be easy to switch to Codex - as far as I recall it results in as close to the same look and feel as the current jQuery version, feel free to try it out by navigating to Special:BlankPage/VueNPP

I already created the infrastructure for this in my patch for T314236: docs: Add configurable Card demo which adds support for a "thumbnail" property type, once that patch is merged I'll add a configurable Thumbnail demo

T309899: Document how to build documentation within fresh node would also help make it easier to contribute

In T311099#8131864, @Jdlrobson wrote:

"I don't think allowing any developer to generate any arbitrary icon pack is a good idea" why not?

Each icon pack would be a ResourceLoader module and T225842 has not been implemented so each icon pack would bloat the registry overhead in the startup module and impact performance for everyone.

In T311099#8130427, @Jdlrobson wrote:

A script developer could request/use one of those icon packs managed in the definitions file. If any script can arbitrarily load icons, I'd be concerned that this might result in shipping several versions of the same icons when multiple scripts are installed.

I don't think allowing any developer to generate any arbitrary icon pack is a good idea so I think some kind of collaboration on what icon packs make sense would be the best outcome here. We do a similar thing for gadgets that share the same files. Perhaps we could provide some default modules to ease the burden here (perhaps on meta wiki?).

In T308488#8125620, @AnneT wrote:

@Volker_E Good point, and it's not very discoverable, either—you have to hover over the language tag to even see it. It'd be nice not to duplicate the copy code functionality, so I'll look into disabling the built-in one.

Just came across this while creating a configurable demo for the Card component. I suggest for changing once the image is loaded that the default be to show a placeholder, but that this can be overridden with a prop to still show the old icon. Also, perhaps the placeholder shown while reloading should be different from the placeholder before the first load, like cdxIconReload?

Can this be made public now?

For a further optimization using string concatenation instead of an array, I ran a modified version of the code above, posting here for reference

var now = performance.now.bind( performance );

In T311099#8107270, @Jdlrobson wrote:

I imagine the most feasible thing here would be to update the gadget extension to support community managed icon packs that gadgets and scripts can use. Editors with the appropriate user right could edit MediaWiki:Gadget-icon-definitions to define a icon module name and list icons.

In T232179#8098870, @Novem_Linguae wrote:

This is already fully implemented. Not sure why gerritbot didn't mention the patch in this ticket. Should be all done here, closing.

https://gerrit.wikimedia.org/r/c/mediawiki/extensions/PageTriage/+/525877

Please consider prioritizing T309899: Document how to build documentation within fresh node - we should not encourage new developers to be installing and running NPM scripts directly, https://timotijhof.net/posts/2019/protect-yourself-from-npm/

Fixed with an onwiki edit in my capacity as a global sysop (grants interface admin rights as well), https://ace.wikipedia.org/wiki/Special:Diff/137538

As far as I can tell Database::select() is not used in GlobalWatchlist, see codesearch https://codesearch.wmcloud.org/deployed/?q=select%5C(&i=nope&files=&excludeFiles=&repos=mediawiki/extensions/GlobalWatchlist - is there something I'm missing?