Thanks @Huji - this is really helpful to know.

@dom_walden This can be tested on thegoodplace (thanks to @dbarratt) - let me know if you have any questions.

@Niharika I've made a second subtask to remove the code for Special:InvestigateLog and change the links that point to it.

@Niharika @dbarratt The copy feature sanitizes the HTML before sending it to the parser, rather than re-parsing the wikitext output from the parser - so the cleanest way to do this is to make the user links external links.

Summarizing a team discussion - we may want to split this into separate subtasks:

This is a deployment blocker.

Thanks @Jcross, it looks like we've added the information to this task description. Do you need anything else from us before the review can go ahead?

Thanks for pointing out that patch. I'm inclined to think we should revert the hard deprecations, and re-apply them in 1.37.

@dbarratt For local reviewing/testing you'll need to do a few things:

• Get the GeoLite2 databases: https://dev.maxmind.com/geoip/geoip2/geolite2/
• Put the .mmdb files in the same directory (similar to T264838#6534393)
• Set $wgIPInfoGeoIP2Path to the database file paths, up to the last common part of the filenames (actually, might want to rethink that to just the path, but that's how the patch currently works...)

@dbarratt While I was working on T264905 I noticed that there are around 50 data fields. I'm wondering if it's worth copying them all out here?

@dbarratt For a better example of how DELETED_RESTRICTED works, here's what ApiQueryLogEvents does. TL;DR, as above, it suppresses whatever was deleted, rather than the full log entry. The full log entry is only hidden in some specific circumstances (example below).

Thanks for the thorough notes @dom_walden. I think proposal 3 looks the most correct - here's why...

Moving to Done since @dom_walden has tested: T265103#6531647

This is solved by the same patch as T264303. Nothing additional to review or test for this task.

Thanks @Krinkle, @Ladsgroup. Have documented that there are performance concerns in https://www.mediawiki.org/wiki/Extension:GuidedTour.

In T261646#6525523, @dbarratt wrote:

We could fix this problem by restoring the focus to the previous element that was focused before the click. Basically:

1. Capture the current focus on mousedown
2. Restore the existing focus on mouseup

Theoretically that should fix the problem.

Deprecation was done in https://gerrit.wikimedia.org/r/c/mediawiki/core/+/588104

In T261646#6425511, @dbarratt wrote:

I think this is because of the mousedown handler https://gerrit.wikimedia.org/r/c/mediawiki/extensions/CheckUser/+/620798/6/modules/ext.checkuser.investigate.tables.js#234

@Niharika I think it could be, if Platform Engineering are happy for us to do this

In T263409#6521873, @Tchanders wrote:

@Prtksxna How do you think the error looks, with the MessageWidget (type: error) styling?

Same thing, with inline: true:

Note that the error messages will be displayed in the content language (or fallback languages if that isn't available), rather than the user language, until T264777.

@Prtksxna How do you think the error looks, with the MessageWidget (type: error) styling?

In T189073#6520614, @dom_walden wrote:

In T189073#6515734, @gerritbot wrote:

Change 631992 had a related patch set uploaded (by Urbanecm; owner: Urbanecm):
[mediawiki/core@master] Hard deprecate SpecialBlock::validateTarget

https://gerrit.wikimedia.org/r/631992

@Tchanders Should this be in a separate ticket, or should we keep this ticket open?

@Ladsgroup Do you think it's worth documenting the performance issue with GuidedTour on the extension page: https://www.mediawiki.org/wiki/Extension:GuidedTour ? Could help teams in the future when weighing up whether to add a tour. Pinging also Growth-Team, who are listed as the maintainers (though they may no longer be!)

Thanks @Niharika - moved to QA since the fix has been merged, and I don't think a backport will be possible before it rolls out on the next train.

In T189073#6502159, @dom_walden wrote:

@Tchanders @Urbanecm I notice that in the log_params of the logging table we are now storing namespaces as integers. Previously they were strings.

For example, now: ... "namespaces";a:1:{i:0;i:3;} ....
Previously: ... "namespaces";a:1:{i:0;s:1:"3";} ....

I am not sure if this matters at all. The only difference I have noticed so far is in the logevents API they no longer have quotation marks (e.g. https://en.wikipedia.beta.wmflabs.org/w/api.php?action=query&list=logevents&lelimit=10&format=json&letype=block).