Was paging of this view ever supported? Can we support it or should we just hide the navbar?

LinkTarget::isSameLinkAs( LinkTarget $other ) is required by the interface since 1.36.

I think this is very similar to T22892 and needs T68961 to be done as well. Or maybe we could use another table if logging isn't a way.

Note that these snippets only work on pages with TOC. Pages with few headings don't have TOC.

Sorry, I meant T236996: When sitewide blocked, cannot edit tags on own User_talk, even if allowed to edit own User_talk.

Is it T288409: Blocked user can't write on his talk page (excluded from block) because of using a tool that adds tags to replies?

Tested on fresh news, works for me.

I think Regression reports should be handled by new tasks.

Per Stable interface policy § Removal:

Obsolete behavior MAY be removed after it has been hard deprecated for three months in the development version (the master branch) as well as in one major release

The patch is ready. As foreseen, this feature will unfortunately result in T44734 whenever a delete action triggers a filter.

Your custom code is exactly the "workaround". Still, the explanation is principally correct, it simply says that if you return {{…}} from a module, it won't be expanded. But when you call frame:expandTemplate, you expand it yourself and don't return any {{…}} anymore. (There is an even easier and more evil way, using frame:preprocess.)

In T289564#7304719, @lucamauri wrote:

(and I believe it's on purpose).

Even if it's on purpose, IMHO it doesn't make completely sense because is treating similar wikicode in different ways.
In any case, even if it is decided that this is the correct behavior, it is necessary to properly document it.

This is not an "inconsistency" of mw.wikibase.getDescription, but of Scribunto itself (and I believe it's on purpose). Try the following:

Created an alternative to @Esanders' patch. Dirty, but worked for me locally.

There are two close workarounds, each with a drawback:

Seems that things have changed overnight, so it's good that you pasted the stuff here.
I think that the notice above contributions is a consequence of implementation of DatabaseBlock::chooseMostSpecificBlock:

I don't think something like new PageArchive( $title, /* ... */ ) can simply become a service (i.e. it's instantiated with a title object).

In T288332#7267307, @DannyS712 wrote:

In T288332#7266500, @matej_suchanek wrote:

I'm failing to identify a single bit of global state in the class...

The direct constructor of Message objects should be replaced with an injected MessageFormatterFactory

I'm failing to identify a single bit of global state in the class...

Removed in 7a1fcc4cf5badb0d0de5f4d77b12a2ab5946f603.

Deleted my previous comment to avoid confusion. There is actually no need to delete the autoblock.
The patch is now ready for review (there is one more consistency fix).

In T287798#7250469, @Zabe wrote:

https://gerrit.wikimedia.org/r/c/mediawiki/core/+/703719 is a candidate.

I started poking this. But I realize it could worsen situation about info leaks...

I'm fine with this. I guess strict 3.6+ support will be a greater challenge.

So I guess "the associated rev id for the log entries" was the broken stuff...

looks like it was something in 1.37/wmf.4.

Indeed.

SELECT log_id, log_timestamp, log_namespace, log_title, log_page, ct_rev_id, ct_tag_id, ctd_name
FROM logging
JOIN change_tag ON ct_log_id = log_id
JOIN change_tag_def ON ctd_id = ct_tag_id
WHERE log_type = 'protect' AND log_action = 'protect'
AND ct_rev_id IS NOT NULL
AND ct_tag_id NOT IN (590, 606, 607) -- mw-reverted, mw-add-media, mw-remove-media (how did they get there?)
ORDER BY log_timestamp
LIMIT 10;

This is a regular pattern, e.g.:

• Group-confirmed: Confirmed users
• Group-confirmed-member: {{GENDER:$1|confirmed user}}

Not reproducible from the link anymore.

With the visual editor more available and used on mobiles, this is becoming more common (we had four occurrences of this on cswiki in the last week, there are over 250 results on enwiki, some of them very recent).

My suggestion would be to do it in a job so the user pages are moved so the rows it picks up would be much smaller.

Some recent renames with recent blocks on enwiki:

LapeerCityRecord
Factchecker_for_ksw
Office_Swissmetal
Toddlinacrossamerica
TulkoffFoods
CaymanIslandsMonetaryAuthority
UCI_School_of_Physical_Sciences
Thewoodspublishing
Dailycalarts
BillboardMagazine
MadMeadyRevenge
4321_team
Previewbot11

Sorry if I wasn't clear enough. I was mostly concerned about the WHERE part (regardless of SELECT vs. UPDATE, though if there is difference, please teach me). There is currently no exact index on recentchanges which the engine could choose, so the first question is whether such a WHERE (with only "partial" match) would be acceptable at all. If yes, there is the index choice question.

This is the update query to be run (asynchronously) on every wiki whenever a user is renamed:

This was probably fixed within efforts in T263592.

Usually 1=0 is used in MediaWiki code base.

So obviously this happened due to some server problem and non-JSON response where JSON is expected (except ValueError in Request._json_loads). Why this happened is a mystery for me, but it isn't really important. Further down:

Note that neither the local database actually references NS_SPECIAL. The link is transformed by Wikibase here. In other words, this would currently require at least having Wikibase on MetaWiki.

Works for me. Jason Kidd has just been protected on enwiki and the tag ("Twinkle") is visible in its history. Perhaps it was fixed meanwhile. Or do I misunderstand?