WIP progress patch that you can follow:
https://github.com/WikipediaLibrary/hashtags/pull/88

Upon getting stalled in T402055: wikilink: Replace deprecated Bullseye VM in Cloud VPS, we tried our hand at this task; we encountered numerous issues that we need to address to complete this migration; the first of which will be to port over some basic ops scripts from wikilink (eg. backup & restore) and do some local testing to validate functionality. We also need to request a quota increase for storage:
https://phabricator.wikimedia.org/project/profile/2880/

We need to request a quota increase to complete the migration
https://phabricator.wikimedia.org/project/profile/2880/

Not waiting on patch changes necessarily, rather some investigation/decision making

we now have correct data, but need to make a ui tweak:

Also, embedding is only supported on internal survey types, it should probably support external surveys as well.

In T393436#11102898, @Alien333 wrote:

@jsn.sherman : supported, yes, but not mandatory: there are still surveys that barge into page content.

Therefore the point of this task still stands: such surveys should not exist, because they break on-wiki content.

It looks like this is already supported via the "embedded" survey type;
https://www.mediawiki.org/wiki/Extension:QuickSurveys#Survey_layout

I created a PR for some additional type safety:
https://github.com/WikipediaLibrary/externallinks/pull/462

note that we should double check zhwiki since it has variants

verified on testwiki

Verified fixed on testwiki

okay, per followup conversations and requests from @Samwalton9-WMF:

Thank you for exploring some solutions to this problem. I agree that the resource loader is a promising approach. There's nothing actionable left for us on these proof of concept patches, but we should pick up this work and solve the issue using the findings. I'm moving this out of review and into our priority maintenance queue.

@sjvipin @Samwalton9-WMF can one of you verify that you have what you need in the sheet?

verified the experiment is up and running

I suggest we turn this into a spike/investigation to start with since dealing with wikidata-related issues can be complex.

In T399458#11058013, @jsn.sherman wrote:

After talking with design and product, it sounds like keeping category changes in Special:RecentChanges may be desirable over moving it out to a new page; we're talking through the idea of making category changes a mutually exclusive option; eg. selecting category changes deselects all other changes and queries the new table. Selecting changes besides category changes deselects category changes and queries the recentchanges table. The overall requirements for doing it this way would be very similar in terms of updating code for category change queries.

@OTichonova when you asked about relevant tasks for this, I somehow failed to mention T399458: Move category changes from RecentChanges/Watchlist to separate Special page:

Thanks for the report; we're getting this into the queue for future work

This would be much more likely to be considered by the moderator tools team if it were reframed into a problem statement, whereas this has some really specific solution requests in it. I'm not sure that watchlist makes sense as a home for this kind of information. If I understand correctly, the issue is the lack of visibility into expirations?

Note that I added counts for namespace and tag filter usage and limited the reporting period to 30 days to keep performance happy.

After talking with design and product, it sounds like keeping category changes in Special:RecentChanges may be desirable over moving it out to a new page; we're talking through the idea of making category changes a mutually exclusive option; eg. selecting category changes deselects all other changes and queries the new table. Selecting changes besides category changes deselects category changes and queries the recentchanges table. The overall requirements for doing it this way would be very similar in terms of updating code for category change queries.

Verified on enwiki test (thanks @Kgraessle!):
https://test.wikipedia.org/wiki/User_talk:Bad-editor-111#c-AutoModeratorTest-20250731173700-July_2025:_AutoModeratorTest_reverted_your_edit

Happily there is nothing to QA here since this exception was never raised in production :-)

I just checked the partners in production and they are working as expected. I have marked them as available and they are now visible in "my library"

Looks good on enwiki beta, using

mw.xLab.overrideExperimentGroup( 'fy24-25-we-1-7-rc-grouping-toggle', 'toggle-shown' );

to enable, and the url parameter to force back off:
/wiki/Special:RecentChanges?hidebots=1&hidecategorization=1&hideWikibase=1&limit=50&days=7&enhanced=1&urlversion=2&mpo=fy24-25-we-1-7-rc-grouping-toggle%3Acontrol

In T322916#11030575, @Samwalton9-WMF wrote:

Thanks for pointing this out @Uzume. I wonder if it would make sense at this point to remove the Newspapers.com config from our EZProxy configuration @jsn.sherman? I think that would solve the above issue of ending up in a poor experience via a link from another proxied resource?

I suggest we just set the default in extension.json

In T322916#11030575, @Samwalton9-WMF wrote:

Thanks for pointing this out @Uzume. I wonder if it would make sense at this point to remove the Newspapers.com config from our EZProxy configuration @jsn.sherman? I think that would solve the above issue of ending up in a poor experience via a link from another proxied resource?

In T393436#11030318, @Jdrewniak wrote:

Looking into this some more, it appears that it is possible to inject a quickSurvey onto a customizable element, via the embedElementId configuration option.

embedElementId - When this field is present, the survey can only be injected into a page with a DOM element matching the configured value by ID. For example, a survey with embedElementId: "survey-embed-point" will be displayed on a page with HTML <div id="survey-embed-point"></div>, immediately after that element.

@jsn.sherman I think we can look at injecting the survey into a different DOM element, using that config option, as a potential solution here. I'm not sure where exactly that would be though, It could vary per-project. We could potentially add an element like that at the skin level as well if necessary.

In T400367#11032568, @Dzahn wrote:

fwiw, the more standard way to do this would be to ask SRE to add this domain to our own DNS servers, certs and redirect configs.

And then just configure in MarkMonitor that this domain should point to our own infra.

You would have to coordinate with SRE/traffic team once but in return would not ever have to worry about such details like cert renewals, redirects and issues on the MarkMonitor side now or in the future.

Okay, I think this is worth looking at now. I just used the same "moderation monitoring" nomenclature that @Kgraessle used in her initial hackathon patch.