So with the last of this chain of patches now merged, here's how it went for me:

I wasn't able to install MySQL Workbench on my Debian Bullseye laptop. However, LibreOffice Base worked fine. (BTW I did have to install an extra package, libreoffice-sdbc-mysql.)

In T275156#6850254, @CDenes_WMF wrote:

Hi Andy! Thanks for this valuable feedback.
I don't believe we can change the text on DLocal's form (i.e. "tasas" "cuotas" etc)-- I believe they own that and those respective translations. Although David or Evelyn please do correct me if I am wrong.

As for the Jimmy text & footer text on Payments Wiki, I am happy to have that translation improved, thanks for linking the Google Doc with notes.

Kind regards,
Camille

In T275156#6850027, @EMartin wrote:

Hi Andy,

Thanks for testing this. So you were able to get a transaction through
then? Did it complete? I'll be happy to refund it if you give me your
email address. Many thanks for the feedback.

Evelyn

Hi! I can try making a donation... just looking for a link for test card numbers to use with dlocal...

In T274943#6847538, @Eileenmcnaughton wrote:

@AndyRussG - yes most of the fixes are to reduce the number of failures you get when it is not a brand new install - by improving cleanup

Wow thanks for all this @Eileenmcnaughton! Even with a bunch of the patches not yet merged, on the master branch HEAD at this writing (898a31439725e), with a clean install using the most recent civibuild patches (b5a85eb0ddc), all tests are passing!

This now worked for me, with the latest version of buildkit in our repo. Thanks!!!

Just to note, as per IRC, for now I'm proceeding with the approach outlined in the task description. Thanks!!

Hey again... so just specifically on the security, git and CI points. So, I hadn't thought of the points you raised, and, agreed, it does seem there would be at least some additional work there... still, I would just add a few thoughts/questions...

Hi! So, thinking about this some more... tl;dr: You're right about the attack surface not being all that different, and about the need for some additional CI and branch maintenance, but I would still suggest this should be done in a new extension, especially for software design reasons, and I'm not convinced that overall maintenance cost wouldn't be less, rather than more, if we go that route. :)

This looks fixed! There are still a few events like this in the wild, probably due to incorrectly cached JS, but the number has dropped dramatically. Thanks again @awight!!

Gonna close this now, too, with all the changes merged! Thanks much @Ejegg!

Just some first quick improvements in the attached patch. Didn't look at the payment form links yet.

The attached change uses volumes instead of bind mounts for database and queue data. Performance on Mac does seem better. Not sure if it's quite where we need it to be, though--maybe? Civi install is still pretty slow, but composer and npm installs seem fine. We're still using bind mounts for source code, config and logs.

Closing as this is basically done. :)

Hi! Thanks so much, all, for the detailed info here!

In T272953#6790271, @Marostegui wrote:

Change applied to metawiki

Some more notes about whether or not to make this a new extension (from discussions in Standup and IRC):

• Another option could be to re-purpose FundraisingEmailUnsubscribe? Some of the code there seems potentially reusable? Though it might still have to be refactored, which might be just as much work as writing new code in a new extension.
• Should code to talk to CiviProxy maybe go in SmashPig? Or maybe not, since SmashPig is first and foremost a payments library?
• Is it worth the effort to create an entirely new extension for this?

In T271168#6787654, @Pcoombe wrote:

For regular banner testing we're still using the pgehres data which comes in via a different method. So I don't think this would affect us at the moment.

In T271168#6784971, @Ottomata wrote:

I don't know what that timeline is, but as far know I this CentralNotice code is the only custom code that works around the lack of support for sendBeacon. According to https://analytics.wikimedia.org/dashboards/browsers/#all-sites-by-browser, IE 11 is < 1% of our traffic. @Milimetric told me that dropping support in MW for old browsers is more about regional percentages of traffic rather than global (e.g. we don't want to drop a browser that most of some country still uses). But, perhaps the decision to drop support from MW is different than just dropping support for instrumentation of MW in old browsers?

I would like to suggest maybe that instead of using DonationInterface for this, we create a new, separate MediaWiki extension?

Hi @Ottomata! Thanks so much for your help here!!

In T272953#6777633, @Marostegui wrote:

testwiki is done:

Regarding making this a part of DonationInterface, I found this in the doc about implementation: "reuse some form rendering and querystring checking code that’s in the DonationInterface extension" .

This is now ready to go once the schema change for Campaign Filtering (T272953) is deployed. Thanks much!!

Thanks @Base!

Here is what I found so far:

• On staging, there is a group called Wikimedia in Review Recipients and it does take at least 5 minutes to show contacts. There are 13943 contacts in all.
• The criteria for that group is based in part on membership in another smart group called Wikimedia in Review Newsletter, and showing contacts for this second group is fast. There are only 1924 contacts in that group.
• It looks like membership in the second (base) group is just determined by the presence of the tag "Wikimedia in Review quarterly newsletter".
• Strangely, it seems membership in the first (derived) group is determined by membership in the base group, plus exclusions for "Do not e-mail" or "No bulk e-mails". So I would expect the derived group to include less contacts than the base group, not more.
• I tried to parse the form_values column in the corresponding rows of civicrm_saved_search, to double-check the details of the smart group definitions. However, I'm having trouble understanding how to interpret the string with the settings there.
• Next steps could include checking what actual queries are being run, and maybe seeing what contacts we get in a new group based on the "Wikimedia in Review quarterly newsletter" tag with the added exclusions, and checking if that's more performant.

Hey @awight! Many, many apologies for the long delay in replying here, and thanks so much for sharing WMDE docker dev work, that looks amazing! I really like the modular setup and also how clean the bash code is.

In T268646#6758836, @Jseddon wrote:

On the 12th January, I left the following comment on irc:

02:53 <Seddon>mepps: Can we keep it greyed out for now. Could we also add in the following text to the preferences tab:
02:53 <Seddon> https://www.irccloud.com/pastebin/j4VW4me2/



CentralNotice is the Mediawiki extension that delivers announcements of interest to Wikimedia communities and users in the form of a banner.

Below are a series of options that allow you to manage which types of announcements you see. Certain platform notices, such as those relating to site maintenance and special notices considered necessary to all users, will still be displayed. For further information, please read the documentation provided.

02:54 <Seddon> "documentation provided" should then link to https://www.mediawiki.org/wiki/Extension:CentralNotice

This is currently blocked due to Campaign Filtering having merged to master. We don't yet have confirmation that it should be deployed in its current state. However, it seems needlessly messy (though I guess not impossible) to merge only the patches previous to Campaign Filtering into the wmf_deploy branch to deploy only those.

Omnipay is a library that provides a general framework for creating gateway integrations. Also, there are Omnipay implementations for numerous popular gateways, some by the authors of Omipay and some by third parties. However, the state of these implementations is uneven. Some appear to be up-to-date and have many contributors, while others haven't been updated recently and have only one contributor. Also, recurring is officially outside the scope of the Omnipay library, though it does seem to be implemented for some gateways.