So far:

Credit card-
      Visa - VI
      MasterCard - MC
      Diners Club - DC
      American Express - AE
      RuPay - RU - https://pay.dlocal.com/views/2.0/images/payments/UI.png

@notconfusing yep, you are correct. This CSP is only applied on a forced banner view, like those from preview links in the CentralNotice admin UI.

Note: the latest FK violation was on an insert to the 'gift data' fields, referencing a rolled-back contribution. Earlier work may have only included checking for rollbacks of contact when inserting the contribution, then of the contribution when inserting the wmf_contribution_extra row.

Hi @jgleeson, that query looks pretty good, but there are a few other fields that also can get someone on the unsubscribes list. We're doing that for people whose email is marked as on hold (civicrm_email.on_hold=1), people marked as 'do not email' (civicrm_contact.do_not_email=1), or who are marked as 'do not solicit' in the communications table (civicrm_value_1_communication_4.do_not_solicit=1). I can run those queries and tally up the total.

Possibly-related commit in the FundraiserLandingPage extension:
Remove temporary EventLogging code-duplication rEFUL9f0535ff0750ee605eede776facc83cf0f32bd44 (merged May 22)

@XenoRyet does grouping by email address reduce those numbers much? The Silverpop export does its own de-duping by email.

@Umherirrender, this isn't quite ready yet. There are still a lot of links in people's inboxes pointing to the old extension, and the new page need to be updated to handle all the unsubscribe cases. The new page currently just handles opt-in.

Update on FTP: a week ago I tried to get in via various means and was unable. On the cluster, only the user which runs the upload is allowed to make that connection. I tried FTP-ing from my laptop via VPN (after setting the VPN address as allowed in the Silverpop UI) but it still wasn't letting me get in.

Thanks @hashar, that sounds great! @Eileenmcnaughton is the local subject matter expert on CiviCRM and its build tools. Enjoy your holidays!

@Pcoombe, @spatton just a heads-up that this will be rolling out along with the 'employer' field variants (T219558), hopefully later today. After that, the 'emailExplain' variant should be unnecessary so you can test the employer variants in places you're currently using emailExplain.

Potentially related commit (deployed a couple weeks before first instance of this bug, touches the relevant code): rETRAb1b777818ba1b555d03527e5865e59aa2b427dd7

FR-tech, the approach to this would be to first check the numbers in Civi, looking at the civicrm_value_1_communication_4.opt_in field for donors with preferred_language=it.

So, we only keep on disk the last two files uploaded, and today's Unsubscribes file is bigger than yesterday's. Checking to see if the uploads from the 16th-18th are still available in Silverpop's FTP site

OK, this is on production! Now if you're on an Ingenico card entry field and tab past the 'cancel' button, you don't scroll all the fields out of sight. @MBeat, I'm hoping this will solve those errors where donors say the iframe was blank after putting in card info.

@MBeat33, @CCogdill_WMF Turns out the problem was names with spaces, not cyrillic characters. I found the template setting that was blocking those and have just pushed a change to production that fixes it. Looking good now as far as I can tell.

Good catch on the captions, @MBeat33 ! That's a bit mysterious, since the credits for all the pictures are in the source code. It looks like the Cyrillic ones are the ones that get dumped somewhere in the process of rendering the template. Trying to figure it out.

OK @CCogdill_WMF and @spatton , those changes are deployed. There's now some basic client-side validation on submit, and the error page has a retry link. If you want to test the error page, use an almost-valid email address like "test@domain.1". That will get past the front-end validation but the back-end's stricter checking will cause an error. Note that the error page is still not styled for the variant.

@Jksamra We will be using a core civicrm field, civicrm_contact.organization_name . We haven't yet deployed the form changes to collect the data.

New link: https://payments.wikimedia.org/index.php?title=Special:EmailPreferences/optin&variant=wle_001

OK, this is deployed. Link in description works now.

OK, this is all set!

Thanks @TSkaff! All the main email body translations look good, except for Catalan. That one needed [givenname] changed to [given name] near the bottom. I made the change, but it still needs to be published.

some other notes here: https://etherpad.wikimedia.org/p/adyen-smashpig-failmail

@TSkaff After looking into the logic of how we find the latest published version, I wouldn't be surprised if simply unpublishing and re-publishing did the trick. Please let us know when you've done that. Also, leaving the bracketed versions in all of the translations sound like a good way to go!

@TSkaff It would be easiest for us to have the subject line in its own page, like Fundraising/Translation/Thank_you_subject

OK, this new text is up, and I see the volunteer translators have already given us coverage in Arabic and a few other languages

OK, we're now using composer-merge-plugin to pull extension dependencies in to paymentswiki's vendor repo.

@jrobell: If you want to put them on-wiki alongside the TY email body, we're actually able to do that now. We did most of the work to enable that last year.

Awesome, glad to hear it! I'll keep looking at the payments-wiki code to see if there's some error in how we're marking redirects, but it's great to have this code to fix anything that slips through the cracks! I think we can resolve this ticket now.

Oh shoot, I didn't realize cross-origin framebusters are dead now!

ok, it looks like there's a problem with the translation of the 7th paragraph. The English source has been updated to include a few new sentences, including one with a tvar for the amount. But... looking at the translate interface for other languages, the source for that paragraph is the old single-sentence text, with no amount. Maybe it's a caching issue?

ca - [givenname] should be [given name]
pt-br - something funky with #recurringCancelinstru
da, de, es, es-419, fr, he, hu, it, lv, nb, nl, pl, pt, pt-br, ro, ru, sk, sv, uk: $amount rather than [amount]

@Pcoombe I think we saw more issues like this recently. We try to get the redirect / pop out correct on payments-wiki, but just in case we make a mistake there, would it be tough to have framebuster code on the TY page? Something simple like 'if (location.href !== top.location.href ) { top.location.href = location.href } ' ?