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.

In T258895#6925835, @Legoktm wrote:

This is waiting on response from the WCQS maintainers on whether the above criteria are met (now documented at https://wikitech.wikimedia.org/wiki/W.wiki)

async function is part of ECMAScript 2017 ("ES8").

Is there a list of all patches merged in 1.36.0-wmf.34?

@Krinkle This feels a lot like T173411

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

T259019 and T259028 were also closed as duplicates of T258277.

T259099 was closed as a duplicate of T258277, so I'm assuming this is intentional.