I would say yes.

Proposal: implement add_warning_params and instead of

added_lines irlike '<(div|s|center|td|small|font|span)/>'

do

matches := get_matches('<(div|s|center|td|small|font|span)/>', added_lines);
matches !== false & add_warning_params(matches[1])

My T204331 is probably a duplicate.

Random ideas:

1. we must avoid circular dependencies
2. we should cache whether a filter was triggered
3. we can enable filters that don't log hits and only execute on demand from other filters

Depends on when it gets review but there is https://gerrit.wikimedia.org/r/#/q/Ida5f2fee548215cc190c401c2677c943f7bfe87b which conflicts and certainly is higher priority.

Other manually updated lists are also available on cswiki.

It seems to work for properties and some items now.

@Sahajsk Hello! If so, please thoroughly read and follow https://www.mediawiki.org/wiki/How_to_become_a_MediaWiki_hacker and https://www.mediawiki.org/wiki/Gerrit/Tutorial.

Certainly no. First, mark getSQL as @deprecated and note it in RELEASE-NOTES-1.35. Then, where getSQL() is overriden, getQueryInfo() must be overriden instead. Also getSQL() shouldn't be called anywhere. This applies to all extensions but does not to file includes/specialpage/QueryPage.php. You can use code search to locate files to be updated. They will probably be in separate repositories, not in mediawiki/core.

Perhaps DiscussionTools have something for us?

In T244138#5861790, @Poojayadav12 wrote:

getQueryInfo() is returning null in the code and getSQL() is returning string in the code. I am not able to understand how can be getQueryInfo() overrided?

Not Lua specific, #property and #statements have the same problem, eg. {{#property:P527|from=Q5836034}}. Reproduced on Wikidata and Commons but not enwiki.

It seems to work for properties and some items now. It might work for all when T219123 is done.

I'm sure I saw this on some other Wikimedia wikis. We should probably look around for such overrides and have them deleted...

From what I can see in the code, there must be an entry in your recentchanges with empty rc_title. Not sure what could cause this...

https://translatewiki.net/w/i.php?title=MediaWiki:Growthexperiments-homepage-suggestededits-difficulty-filter-label/qqq&diff=9110393&oldid=9092118

We can probably show "Global filter #123" instead or always query with afl_global = 0 when T220791 is done.

You have to filter them out. There is another user preference and also a filter on the watchlist for this.

Done with T194950: Include Wikibase dispatch lag in API "maxlag" enforcing.

This could be T202916: Stop changing my "Group results by page" prefs based on a URL that I've clicked on.
Scenario: there is a public convenience link which contains enhanced=1.

It hasn't been translated yet. Check with uselang=qqx or uselang=de.

I think Wikidata parser functions should avoid this kind of categorization by colon-protecting the output like [[:Category:XXX|Category:XXX]]. Or allow both but there's no way to choose. Same with files. The class EntityIdSiteLinkFormatter handles this.

T169834: Change EchoEvent->create to return Status or throw exceptions, never false seems duplicate and even has a pending patch.

Note that this is what wikis have by default:

The problem in the task description has been fixed. Is there anything else to do?

Thanks for the review!

In T27909#5772594, @Quiddity wrote:

"[[Special:NewPages]] has a new drop-down menu interface for selecting the Tag filter. You do not need to type the tag from memory anymore."

Revived and rebased patch, tagging Core Platform Team for review

What makes you think that the problem is solved?

actually that's not "edit history"

Actually, the link can be quite useful. It leads to a page with deletion logs. So perhaps re-label and make blue?

Is this T167912: Create an Echo notification to inform user of the outcome of his rename request?