Question: Does the automatic update require JavaScript, or is it completely server-side?

Some counter-examples, showing that it sometimes works (also from svwiki):

In T384319#12063506, @neriah wrote:

When I'm reviewing a draft that a new user wrote in their user space, I might make 15 or 20 edits there. To avoid flooding the user with a large number of notifications, it would be worth creating a mechanism that prevents sending more than one notification per page within every x amount of time.
(Regarding the option to disable these notifications; new users, who commonly receive edits in their user space, are not aware of all the options in preferences, and it's not right to require that of them.)

How to handle projects that are already adding "default" to their descriptions?

Those projects would just have to remove their hardcoded text, either before or after deployment here, just like with any other on-wiki feature that MediaWiki adopts. I don't think the consequences of two "(default)" after each other are so big that any particular consideration needs to be taken here. We can use Tech News to reach out, but I don't think we need to do more than that.

In T420600#12005199, @Escargot_rouge wrote:

I've been monitoring this tag (and the CSS one) on frwiki but no edit has been made with this tag on frwiki since the creation of the tag.

I don't see this explicitly stated anywhere, but a comment above mentions 2 weeks, and there was a scap sync-world (whatever that means) on May 26. Does this mean these demotions will take effect on June 9? And is that simultaneously on all WMF projects, disregarding the normal staggered weekly deployment? (I'm not personally affected, but there was a post on the svwiki village pump about this, and I'd just like to make sure I understand the situation correctly)

This is indeed now resolved.

I don't know which component that is to blame for this, so leaving project tags for someone else to fix.

In T423193#11817052, @Catrope wrote:

• resubmit the edit

In T422312#11788001, @Novem_Linguae wrote:

Tiny wikis

@matmarex A few days ago I noticed the site logo is blurry. It's blurry on my computer, regardless of site and browser (it's blurry in Firefox, Chrome and Edge). However, it's not blurry on my phone, using Firefox or Chrome.

This is affecting the site logo. I would suggest prioritizing this higher.

Can confirm. This happens if you can't edit that filter.

As Dragoniez and codenamenoreste have already said, this either has to be amended or reverted. We can't be expected to work with filters like this.

Why can't we just:

1. Introduce proper array functions
2. Change !("confirmed" in user_groups) to !("autoconfirmed" in_array user_rights) in the filters

Thank you, @matmarex, for approving this! I was just about to ping Jdlrobson about this, but you were faster.

I suggest that this task is closed as declined or invalid the way it is currently written. There are filters that are not meant to match things often, precisely because what they aim to find happens very rarely. It is not necessarily a performance problem, or a problem at all, assuming that the filter works correctly. What we need is things like T93564 so that we can easily find filters that rarely match anything and can check if they work properly and are needed.

I agree with Johannnes89. This seems excessive. There are much broader and older data leaks in AbuseFilter (like T44734) and a lot of people don't think it's a big deal.

Hi. Just a question. Is this bug the reason why we at svwiki have to make updates like this every year, or is our problem solvable in some other way? Thanks!

In T412824#11484750, @Izno wrote:

In T412824#11466490, @Bawolff wrote:

Could we keep parsing and disable PST?

Although i dont know if people use {{subst: to "install" scripts.

They do, see https://en.wikipedia.org/wiki/Template:Install_user_script

Based on the discussion here, it seems like parsing is mostly wanted, but pre-save transform is mostly unwanted. Renaming the task to reflect this, as well as to include CSS pages.

In T412824#11466490, @Bawolff wrote:

Although i dont know if people use {{subst: to "install" scripts.

Only treating content inside comments as wikitext sounds awesome. Close as duplicate of T373834?

I agree that the fact that ~~~~ is transformed is unwanted. However, until T91169 is solved, any page needs to be able to be tagged for speedy deletion by editing the content, so templates and categories need to work until then.

@jsn.sherman Do you have any objections to the proposed patch, or can we move forward with this?

VE is also seemingly replacing Image with File. Should I open a new task for these issues?

I wonder if this is truly fixed. VE is till making changes like this. Is there perhaps a different task for that?

Confirmed in production.

Thank you so much for your work on this, @ihurbain ! I do believe backporting this was the right call.

@cscott , @ssastry , @Arlolra Thanks for whipping up code to fix this! Now, if I remember correctly, for Parsoid changes to take effect on Wikimedia wikis, Stashbot needs to be run? What I mean to say is: I don't think this can wait until Thursday evening.

Thank you! Here is a screenshot with the stack trace, if that helps:

Thank you! The change looks good to me!

Thank you, that sounds wonderful!

Thank you for tagging this task with good first task for Wikimedia newcomers!

Noting it here because it took some time for me to see it: toclevel is tocLevel in the new API.

In T373874#11350846, @Tgr wrote:

new mw.ForeignApi( 'https://www.wikidata.org/w/api.php', { userAgent: 'NameOfTool (ContactInformation)' } )

It's mentioned, if briefly, in the inline docs,

In T373874#11346908, @Tgr wrote:

mw.ForeignApi takes the same options as mw.Api, and Api-User-Agent is on the CORS allowlist, so it should work.

Does this work with mw.ForeignApi? In the only signature that I'm aware of, mw.ForeignApi accepts a string which is the foreign domain. I can't find any mention of userAgent in the source code for mw.ForeignApi.

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' )

In T233520#7523405, @Manuel wrote:

Hi everyone! Does T295219 mean that we didn't solve the problem after all?

There were 235 pages listed on https://sv.wikipedia.org/w/index.php?title=Special:UnconnectedPages&limit=250&offset=0&namespace=0

In T284921#7156564, @ssastry wrote:

span.tocnumber { display: none; } should do it right?

There are no links on MediaWiki:Gadgets-definition

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

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.

Oh, and the file is https://phabricator.wikimedia.org/source/mediawiki-config/browse/master/wmf-config/InitialiseSettings.php

Maybe I should also add that the filter has correctly ignored actions that are sparse enough for the filter's throttle.