In T399681#11013296, @akosiaris wrote:

In T399681#11013197, @A_smart_kitten wrote:

Hmm… what's interesting about this task & the other two most-recent MediaWiki-Special-pages cron-job-failure tasks (T396454, T396977) is that all three of these failures have been due to (what seem like) database connection errors.

In all these cases, quite cleary, due to maintenance.

Indeed.

...having said that, and having now looked at the code here a bit, it seems like this might be a bit more complicated to fix than it first appeared (especially to someone brand-new to the RC codebase like myself). The main problem seems to be that there's currently no defined way to pass any system-message parameters from the PHP code (which defines the filters) to the RecentChanges JavaScript (which renders the system messages); so, in order to pass any parameters through to the RC filter-description messages, that code pathway first needs to be developed.
I've uploaded a couple of hacky proofs of concept to prove that this can be done, but - given what I've said - I'm gonna un-assign myself from this task for now. I might come back to it in the future, but I don't want to stop anyone else from working on it in the meantime if they want to :)

Hmm… what's interesting about this task & the other two most-recent MediaWiki-Special-pages cron-job-failure tasks (T396454, T396977) is that all three of these failures have been due to (what seem like) database connection errors.

Hey serviceops, please could an SRE grab the stack trace for this failure if/when you have the time?

I believe this is now complete :)

(migrating tag from merged-in task)

(thanks @Cparle :))

Please could someone with more Watchlist knowledge than me check to see whether T41510 describes the same thing as this task; and if so, merge the tasks together (preferably by merging this one into T41510 IMO, as that task has a lot more historical discussion/context)? (They seem similar/the same to me, but I'm not confident enough to do any merging myself here...)

todo:

• finish undeploying the extension from operations/mediawiki-config
• modify make-release/settings.yaml to stop WMF-branching the extension & adding it to the tarball
• possibly remove the MW_HAS_SPECIAL_INTERWIKI constant from MW core - AFAICS it was only used to assist with Wikimedia undeployment; so when that's been completed, it seems like this may no longer be needed. codesearch doesn't seem to find any external uses of the constant
• update https://www.mediawiki.org/wiki/Bundled_extensions_and_skins to note the extension's removal from the tarball
• (anything else?)

I've merged this into T362553: time/bytes (when including sections) overlaps history rows as it looks like the same issue to me; please feel free to comment/reopen if you think it's different, though :)

In T370266#11001276, @Aklapper wrote:

(Do we still redirect to https://www.mediawiki.org/wiki/Phabricator/Maintenance for that time? I am clueless how "standardized" the steps are.)

(removing MediaWiki-Special-pages, as it doesn't seem like any changes to core MW special-page functionality will be needed here. please undo if this is incorrect, though!)

I'm not Chlod, but it seems like the patch is ready for review — to resolve the issue on production, it seems like the proposed normalizeNukeTags.php can just be ran as a maintenance script in itself.

Gently bumping this task, as I feel like it might be a major reason for more people not using the test instance. Personally speaking, it's what stopped me from using the test instance myself for so long -- I noticed it linked from the Phab homescreen, and I was curious about the way Phab worked with certain things; but the non-working email verification stopped me from being able to do anything on it, and (until this task was filed) I didn't know that an SRE manually activating my account was even a possibility. (And even then, TBH, filing a task to request account activation is a bit of a hurdle to get into the test instance [and requires SRE time, which I'm guessing might not be feasible if a large number of account-activation requests were made]; and I didn't get the internal drive to do so myself until a few months later)

See also T41510: Opening Special:EditWatchlist with a large watchlist hits server timeout (Create watchlist pager)

(tagging Moderator-Tools-Team as stewards of the RecentChanges component)

(assuming based on the above that this task is no longer NDAed)

Possibly a regression from https://gerrit.wikimedia.org/r/c/mediawiki/core/+/1132176? /cc @Umherirrender

Seems potentially similar to T386903: Duplicate entry on Table pagelinks error during update script?

Would this include creating a new 'compatibility policy' field for the extension.json schema (which would also mean that it could be documented/defined within the extension itself, rather than just on MW.org)?

In T294329#8085948, @thcipriani wrote:

[…]

2. Remove your extension from CommonSettings.php (example)
3. Remove your extension from InitialiseSettings.php example)
4. Remove your extension from extension-list to stop rebuilding l10n on deployment (example)

[…]

It seems like the cleanest solution would be to have different tarball presets based on the starting branch

Thanks for the work that's been done on this! :)
A few notes from some things I noticed with the new UI elements (let me know if you'd like me to file any/all of these as separate tasks!):

That specific message is customised by the English Wikipedia (at https://en.wikipedia.org/wiki/MediaWiki:Noarticletext / https://en.wikipedia.org/wiki/Template:No_article_text) - if the message on enwiki needs to be improved, it might be worth bringing it up at Template talk:No article text and/or Wikipedia:Village pump (technical); so that it can be fixed onwiki. (I'm sorry for passing you to another forum to report this in, though!)

In T398840#10995587, @mmartorana wrote:

Maybe do we want to also have a general project for post incident / mitigation work? Or do we prefer to track that with a specific tag?

Question that came to mind: What if a temporary account is pinged by another user in a discussion (e.g. by using @[[User:~2025-3105|~2025-3105]])? Should the temporary account username in the ping have a grey background?

In T359549#10993837, @Dzahn wrote:

Are there any vetoes / hard concerns about making it visible only to logged in users?

from the task's description; re extensions that have been merged to core:

Open question: should these be removed from the preset?
As these extension repos are currently stubs, they won't (or at least, shouldn't) have any substantive effect - other than being listed at Special:Version - on new Patch demo wikis that are (e.g.) built from the master branch. However, for wikis that start from release-branches that were made before these extensions were merged into core, these repos will still contain active code.
Removing these extensions from the preset seems like it'd be (in effect) removing functionality from wikis built from some older release-branches; but (IIUC) keeping them shouldn't have any user-facing effect (other than at Special:Version) on wikis built from a branch that does contain the extension's merge into core.

In T398108#10992895, @STran wrote:

I'm not incredibly familiar with namespaces, but it looks like this is happening because WikiBase declares the Property namespace whereas meta has no awareness of that namespace.

Thinking about it; IMO, the instructions on how to create/export the actual patch itself might be better located on the MW.org page than on the Wikitech page, given (for one thing) that not everyone developing a patch will be responsible for deploying it to WMF production; and also because the idea of reviewing patches in private tasks (prior to pushing them to Gerrit) is not limited to WMF-deployed extensions (i.e., where a security deploy to Wikimedia wikis would be needed) — IIRC from reading security tasks for non-WMF-deployed extensions, it seems common to have security patches proposed privately within the task at first.

To be honest, I don't really mind how the tasks are structured. I reopened this based on (what seemed like) precedent in T27482: Merge RenameUser into core for the Wikimedia undeployment steps to be handled within the same task as the merging itself; and because (to me) fully undeploying the merged extension from Wikimedia sites necessarily seemed like a part of merging the extension into core. (One of the steps in the Wikimedia undeployment has already been done, & was linked to this task - it just seems like the others may have been inadvertently missed :))
If someone wants to open a new parent task for that though, I have no objection - I guess it just seems slightly unnecessary imo, but no objection if anyone else thinks it's worth doing :)

It turns out that the mediawiki/extensions/Interwiki repo still needs to be removed from being a bundled extension, and from being branched for WMF production; xref https://gitlab.wikimedia.org/repos/releng/release/-/blob/e358bf04db00e434a0192d7ac147221e2b494300/make-release/settings.yaml. (Discovered while working through T399035: Update the Patch demo `tarball` preset to reflect updates to the list of bundled extensions/skins since October 2020)

(I'm assuming that the page created as a result of this task is https://www.mediawiki.org/wiki/Codex/Design/Diffs)

In T385156#10793534, @A_smart_kitten wrote:

The only thing that immediately occurs to me is whether/in case it should remain protected until the Catalyst wikis without the Apache fix applied to them (referred to in T385156#10792315) are deleted?