@egardner If we used a transparent background, wouldn't that just be transparent in dark mode as well? What additional design for that are you looking for or what do you think would need to change?

Test wiki on Patch demo by CMelo (WMF) using patch(es) linked to this task was deleted:

Change #1285447 merged by jenkins-bot:

[mediawiki/extensions/MultimediaViewer@master] mmv.bootstrap: Force dark mode for cdx-progress-bar

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

Change #1084804 abandoned by Mhorsey:

[mediawiki/extensions/CampaignEvents@master] [DNM] POC adding sidebar links for CampaignEvents

Reason:

POC not implemented

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

Change #1285447 had a related patch set uploaded (by Eric Gardner; author: Eric Gardner):

[mediawiki/extensions/MultimediaViewer@master] mmv.bootstrap: Force dark mode for cdx-progress-bar

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

RE: MediaViewer, I think shipping an opaque background color in ProgressBar would be fine as long as we had a corresponding dark mode style for this component (which I assume we would anyway). @DTorsani-WMF or @JFernandez-WMF, can you show a dark mode example of the new design?

sorry for the delay and thanks for flagging!
the example that we thought of to inform the decision on whether we wanted a white background or no background was if, for example, the progress bar appears in an article or above written content, e.g.:

@JFernandez-WMF Can you help shine some light on the example where the progress bar appears over the page content, and your thoughts around changing the background color of the progress bar to transparent?

In T407638#11863890, @DTorsani-WMF wrote:

Can you help me understand why the page is dark, assuming this is in light mode?

Otherwise the content would have shown through in this instance. I'm unsure why the transparent background before didn't have this issue.

Thanks @Krinkle for bringing this to our awareness! The border-radius update is intentional, so I won't go into detail there. As for the background color, we made it white (in light mode) for pages where it appears on an overlay over the content of the page. Otherwise the content would have shown through in this instance. I'm unsure why the transparent background before didn't have this issue. Possibly a local override. @JFernandez-WMF any ideas here?

FYI: This change applies to MediaViewer and currently causes a white flash (live on the Beta Cluster, riding the train this week).

Change #1275555 merged by jenkins-bot:

[mediawiki/core@master] Update Codex from v2.4.0 to v2.5.1

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

In T411829#11715177, @ifried wrote:

Thank you for testing this, @ldelench_wmf! I will close this task as done, since all the work we could do is complete.

And hello @seanleong-WMDE, thanks for the response! Maybe we can briefly chat about this in the next few weeks? If yes, I could set up a meeting. Let me know! I will be out of the office for the remainder of the week, but I'll be back on Monday March 23. Thanks!

Change #1275555 had a related patch set uploaded (by Catrope; author: Catrope):

[mediawiki/core@master] Update Codex from v2.4.0 to v2.5.0

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

In T423388#11826205, @Daimona wrote:

@cmelo The checklist you copied in the task description is for creating new tables, not the one for schema changes. You can see examples of that one in T408460 and T402816 and then update this task. For the time being, I have reviewed the schema patch and I think it's ready for DBA review.

In T422545#11827436, @ifried wrote:

Thank you so much for this investigation, @cmelo! This is fantastic and very exciting :)

One note is that, for the post-publication dialog link, I think we would actually want people to go to the event page and not to Special:RegisterForEvent. This is because someone is unlikely to know that they want to register for an event without first reviewing the event page to learn more about the event vision, goals, organizers, who else is participating, etc. So, with that in mind, what can we measure when they land on the event page? Is it possible to track their clicks on Register for Event from the event page, or no?

Thank you so much for this investigation, @cmelo! This is fantastic and very exciting :)

This is now working as expected.

This is now working as expected.

Thank you so much @phuedx!!!

@cmelo The checklist you copied in the task description is for creating new tables, not the one for schema changes. You can see examples of that one in T408460 and T402816 and then update this task. For the time being, I have reviewed the schema patch and I think it's ready for DBA review.

Thanks for looking into this. No questions for me, I think this gave me a good overview, and I'll familiarize myself more when we actually start using TestKitchen.

Not directly testable, will be tested as part of T422156.

Not directly testable, will be tested as part of T422156.

In T421749#11804013, @jhsoby wrote:

As long as the Event namespace isn't added to $wgTestWikiNamespaces (which doesn't have special configuration in Wikimedia, so the default is used), it will work like on all other wikis – that is, no prefix required. I would like to keep it like that, because adding the namespace there would require all events to be specific to a certain test wiki, but I can imagine far more events where participations from users of several wikis is encauraged (not that having them prefixed would stop others from joining, but still). So we can just keep it as simple as possible.

Change #1269481 merged by jenkins-bot:

[mediawiki/extensions/CampaignEvents@master] Fix aggregate pagination in EventContributionsEditorsPager

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