I'm still not 100% sure of what could cause this and would appreciate seeing it, but the fix above should do.

which uses e.target (which can be NULL if custom events are being used)

(Apologies for the edit conflict, moving back to CR as I had some drafts from an unfinished review, and a couple things I found later, that I turned into a follow-up change)

One thing that the AC do not clarify: should "articles edited" include articles that were created as part of the event (and are therefore already included in "articles created")?

CentralAuth and dependent extensions got fixed by https://gerrit.wikimedia.org/r/c/mediawiki/extensions/CentralAuth/+/1193021, as confirmed in r1193442. But the thing I ask myself is:

(Note: disable-if does not support arrays with in_array-style checks, so we may need to build a list of A === X OR A === Y ... manually.)

In T405920#11233747, @daniel wrote:

@Daimona can you shed some light on why you filed this ticket? What's the problem? Did the fact that the helper class is not wiki-aware cause a problem somewhere?

Random thoughts:

• I think this could be resolved by letting organizers export a CSV/TSV file. I thought we already had a task for it, but apparently we don't.
• Not sure if we can make this work synchronously, as opposed to delayed processing where the organizer comes back later to download the file. Perhaps, start by restricting this to event with less than X participants, where we can probably just do it synchronously.

@ifried @JFernandez-WMF question that came up in code review: for the "wiki" column, what are we showing? Options are:

• URL: es.wikipedia.org
• ID: eswiki
• Localised: Spanish Wikipedia

In T351366#11187929, @matmarex wrote:

I think the real fix to make the "caused by" information comprehensible would be to make the plugin emit a graph that shows how the tainted data flows through the relevant lines of code, instead of just a flat list of these lines.

In T401748#11187930, @matmarex wrote:

I wrote that workaround patch, because something in https://gerrit.wikimedia.org/r/c/mediawiki/core/+/1188321/comments/15ff156e_e6ed0623 caused this failure in UpdateQueryBuilder::execute to disappear, and I didn't want us to be randomly adding and removing the suppression every couple of patches.

In T405924#11225460, @Lucas_Werkmeister_WMDE wrote:

Fine, it need not belong to this page, but how is that useful if the response then contains garbage?

I don’t think it’s garbage? The main page contains no revisions between the timestamp of revision 1167335840 and the timestamp of revision 1167335840, so there are no revisions in the response.

In T400953#11225686, @JFernandez-WMF wrote:

@Daimona hey! i believe that full-width behavior is possible within the codex dialog: https://doc.wikimedia.org/codex/latest/components/demos/dialog.html#with-form-inputs

I'm realizing now that we use the same pattern in 4 more places (BlockRestrictionStoreFactory, DatabaseBlockStoreFactory, ActorStoreFactory, UserFactory). I'm not sure what to do then. It'd be great if this confusion between domain ID and wiki ID could be clarified.

Filed T405922: UserGroupManagerFactory::getUserGroupManager doesn't work correctly when wiki ID contains a hyphen to address the core bug, so this task can be resolved independently of that.

Ah, now that I read the doc comment more carefully:

In fact, when used with LinkTarget it also fails with interwiki prefixes.

Per above

FWIW, I came across the same issue as part of T400722.

In T404118#11216045, @thcipriani wrote:

Sooooo our database names with a hyphen in Catalyst are confusing, I guess.

@JFernandez-WMF Hi! The selector in the task description appears to be full width in desktop, but that is not the default behaviour I got from Codex's select component. Am I missing something? Or, is it fine to leave it at its predefined width? Thanks!

Not directly testable, may want to wait for the contributions tab and the association dialog to be merged so you can test all at once.

In T392123#11103334, @Daimona wrote:

(Note: this dialog might be dropped entirely: T358872#11099077)

Since this is affecting multiple repos, I have created a revert of the core change, so that we can unblock CI for everyone affected while working on a proper fix. I'm going to let it sit for ~half an hour (and complete CI) in case someone is close to pushing a better fix, in which case please let me know.

In T405226#11201570, @Jdforrester-WMF wrote:

Consider creating a package that brings in all the needed dependencies, as well as extensible config files with sensible defaults (what we do for code checkers like PHPCS, eslint, phan, stylelint)

Maybe. We don't do this for PHPUnit or QUnit

Blocking patches in other repos, e.g. https://gerrit.wikimedia.org/r/c/mediawiki/extensions/CampaignEvents/+/1181146

@DLynch Thanks for the explanation, it makes sense. Indeed, setting $wgMainStash = CACHE_NONE; is sufficient. That also explains why switching is forbidden - of course it didn't matter for my simple test of just adding a couple letters, but for anything more complex, it would matter. So, I guess the only remaining thing for this task is the JS warning.

Thanks for the quick fix!

In T280156#11197423, @Tgr wrote:

jobs with unknown / wrong types will just sit there in the queue, completely unreachable.

In T280156#11195360, @Tgr wrote:

Running jobs on the other hand relies on $wgJobClasses; job types not included in it are never scheduled to run.

I don't recall what this was based on, but jobs are created by JobFactory::newJob() which does throw if the job type is unknown.

In T402353#11195911, @vaughnwalters wrote:

@Daimona I believe the API docs still need to be updated to have the a flag to toggle collaborative contributions for enable, edit, get.

And the API endpoints (enable/edit/get registration) should have equivalent functionality and be documented in https://www.mediawiki.org/wiki/Extension:CampaignEvents/Api

FYI that this happened. A quick test would suffice. Open Special:EnableEventRegistration on a wiki that does not use wgConf and confirm that you can still select that wiki in the event wikis field.

In T404118#11195674, @Daimona wrote:

I seem to recall that DB domain ID and wiki ID are not guaranteed to be the same under certain specific conditions, but I may be misremembering, or at the very least I don't know where I saw this.

On the face on it, it's a not-so-uncommon example of confusion between the special value WikiAwareEntity::LOCAL and the full, string form of the wiki ID for the current wiki. From the relevant code:

This issue was previously faced for the participant search in Special:EventDetails. See tasks T308574 and T312645, proposed schema + mention of things to watch our for re renames, and workaround (unfiltered query followed by filtering in PHP code; yuck). That work was eventually declined, but judgind from the above alone it's not clear if there were other reasons. I'm also not sure how complex it might really be dealing with renames. Maybe it was just a case of "non super-simple, the workaround is good enough, let's not bother".

I just had a similar occurrence and spent a good 20 minutes staring at the code in anger before noticing the mismatch :old-man-yells-at-jobqueue:. If this isn't easy to validate at runtime, could we at least have a structure test to verify that the keys in JobClasses match the job's actual command or something like that? At least for extensions and best-effort. As well noted in the task description, the current failure mode is extremely irritating and hard to debug.