If there are other extensions which have been converted to virtual domains but not to use addExtensionUpdateOnVirtualDomain(), probably better to handle them in dedicated tasks or in the relevant T348573: All Wikimedia extensions that store their data outside the main database should use a virtual database domain subtasks.

Already asked at Wikimedia but maybe it is more appropriate here, so self-quoting:

@Joe do you have any comments on the above? I think you were involved in requirements development for this task. I would like to get a more nuanced view of what kinds of namespaces should be excluded and why.

I'm not sure if it's actually possible to do in the regular interface. I went into manual edit mode to copy what Denny/Al had done. But in any case, that level of difficulty is worth it for this kind of rare but enabling need.

Change #1203281 had a related patch set uploaded (by Krinkle; author: Majavah):

[mediawiki/extensions/WikimediaMaintenance@wmf/1.46.0-wmf.1] Fix symbolic links

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

Change #1202872 had a related patch set uploaded (by Krinkle; author: Zabe):

[operations/puppet@production] mediawiki: Update location of startupregistrystats script

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

From the Logstash mw-cron dashboard, we can see the blameStartupRegistry.php maintenance script invocation has been failing since Tue Nov 4, as follows:

My bad, I missed it: T409212: MediaWiki periodic job startupregistrystats-testwiki failed

(btw, I've tagged Phabricator here as well due to the request for silent task batch-editing & a Herald rule change, but feel free to untag as appropriate!)

Revert "Fix backpressure management in ipoid imports"

stran opened https://gitlab.wikimedia.org/repos/mediawiki/services/ipoid/-/merge_requests/260

PR: https://github.com/zotero/translators/pull/3527

PR: https://github.com/zotero/translators/pull/3526

Change #1203280 merged by jenkins-bot:

[mediawiki/core@master] Actions: Move hook interfaces to MediaWiki\Actions\Hook\ namespace

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

Requested public project MediaWiki-extensions-WandaScribe has been created: https://phabricator.wikimedia.org/project/view/8313/

Please see and follow https://www.mediawiki.org/wiki/Writing_an_extension_for_deployment for extension deployment requirements.

Image of the minimal example from above:

Change #1203280 had a related patch set uploaded (by Umherirrender; author: Umherirrender):

[mediawiki/core@master] Actions: Move hook interfaces to MediaWiki\Actions\Hook\ namespace

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

There was a patch set to use the constant in a test - https://gerrit.wikimedia.org/r/c/mediawiki/core/+/1165604 - but to make the test useful it needs more PSR-4 moves. But after T398513 any test about that can be written without the constant.

In T398513#11354461, @Reedy wrote:

I believe... for MW core this is effectively done.

The root folders in includes/ are all done.

There's many tests probably still need updating...

It's a different issue, but maybe maintenance/includes/ should be moved to includes/Maintenance, which would remove another special case... But as we're not using AutoLoader::CORE_NAMESPACES for anything, that's less of an issue.

	public const CORE_NAMESPACES = [
		'MediaWiki\\' => __DIR__ . '/',
		'MediaWiki\\Maintenance\\' => __DIR__ . '/../maintenance/includes/',
		'Wikimedia\\' => __DIR__ . '/libs/',
	];

There's various heirachy and namespacing issues. Files still need namespacing, some definitely need moving around and re-namespacing...

But I think the main pain point for this task is done.

Boldly resolving per last comment.

hey @Nicolasmichel have reviewed your MR, please address the comment
Thanks

I see your point, but the problem with this approach is that it potentially blocks unrelated development, like in my case. I find the approach of Dependabot much better: it constantly updates dependencies, but in separate PRs (changes in Gerrit speak), so if a new dependency version breaks the code, CI fails only on that change, and not everywhere. Also, the CI failure is less mysterious, since it’s no longer tied to the timing, but to code changes.

In T409175#11353892, @Aklapper wrote:

I am unsure if the patch for this task in https://gitlab.wikimedia.org/repos/phabricator/phabricator/-/commit/da496b05a57173447ca4a414933b9fdca2a785d8 created T409519 as an unexpected side-effect.

@Rjwilmsi thank you!

Thanks @NNgu-WMF - I'm trying to think about what would feel more natural for the supporter -

My proposal here is to complete the entry with:

• Add a prerequisites section here.
  • With an intro of what a deployable wiki (has Parsoid basically) is, and the way of checking this:

./multiversion/bin/expanddblist 'parsoidrendered - wikifunctionsclient - closed'

@scarecroe See https://sourceforge.net/projects/autowikibrowser/files/autowikibrowser/Snapshots/ - AutoWikiBrowser6401-12997.zip includes fix on this ticket.

Is it possible to get a beta release of the next version with the fixed code? I tried using an old version of AWB, but I get an error saying that version isn't enabled.

Is it possible to get a beta release of the next version? I think this was fixed in another ticket, but the code hasn't been released yet. I tried using an old version of AWB, but I get an error saying that version isn't enabled.

Change #1166873 merged by jenkins-bot:

[mediawiki/core@master] Namespace 12 classes in includes/Collation, 2 in includes/DB, and 1 in includes/Debug

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

As there's been no objections/responses so far to my last comment, leaving advance notice that I plan to close this task in probably a few weeks if there are no objections. (Leaving this second comment rather than closing the task right now due to the length of time it's been open for so far.)

If you use the new TUX ui rather than editing the page through the wikitext editor, you get a better error message:

Sidenote: that error message is really unhelpful. Validators should explain why they are failing rather than all failing with the same unhelpful error message.

In T351289#10732361, @Aklapper wrote:

[...] I'm specifically curious about "Parent ID" mentioned before :)

Change #1203274 merged by jenkins-bot:

[mediawiki/core@master] Gallery: Namespace most classes

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

(For the record, if this is a request to change user-group configuration on all WMF wikis, should it be proposed on Meta-Wiki via a global RfC, rather than here on Phabricator?)

Change #1203260 merged by jenkins-bot:

[mediawiki/core@master] tests: Ensure capitalise folder for php files in tests folder

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

I agree with Pppery. We should let individual communities decide on this. Furthermore, the use case isn't too broad (currently only 9 projects out of over 800 have this flag enabled and 3 of them don't have any interface editors at the moment), and, if needed, a community can discuss it locally and easily request the flag here imho!

Change #1203273 had a related patch set uploaded (by Xqt; author: Xqt):

[pywikibot/core@master] IMPR: show friendly install message when mandatory packages are missing

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

Change #1203274 had a related patch set uploaded (by Ladsgroup; author: Amir Sarabadani):

[mediawiki/core@master] Gallery: Namespace most classes

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

Change #1203273 had a related patch set uploaded (by Xqt; author: Xqt):

[pywikibot/core@master] IMPR: show friendly install message when mandatory packages are missing

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

Change #1203273 had a related patch set uploaded (by Xqt; author: Xqt):

[pywikibot/core@master] IMPR: show friendly install message when mandatory packages are missing

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

Only 8.8% left: P85110