Technical notes: this could use the opt-in queue that we established for the re-provisioning emails. That queue's consumer assumes that we're just flipping a bit on an existing donor, so we would want to extend it to use the basic donor info from payments-wiki to create a donor record if it doesn't find one for the email address. Then I think we'd need to update the Silverpop export if we wanted to include contacts with no donations.

@NNichols, @Eileenmcnaughton found a fix for this, and it's now deployed. You should now be able to delete tags without bringing things crashing to a halt!

Looks like the Italian hasn't been changed since last June. Italian's also still using the 20171019 email. The 2018-10-01 TY email only exists in English, Catalan, Danish, and Japanese. @jrobell what's the process for getting more translations of the new version?

ping @CCogdill_WMF, @MeganHernandez_WMF, @spatton, @Pcoombe: any thoughts on sending the user back to PayPal to get a second authorization?

Looking good on https://meta.wikimedia.org/wiki/Special:Log?type=protect&user=&page=&wpdate=&tagfilter=

First and Last Name search works for me too.

These tags are now showing up on meta: https://meta.wikimedia.org/wiki/Special:RecentChanges?tagfilter=centralnotice&limit=50&days=7&urlversion=2

diagonal banner list on Special:CentralNoticeBanners in Firefox:

Oh boy, that's some unfortunate non-handling of errors right there. We've got a try/catch around it but I guess it's non-catchable.

Testing checklist here:
https://etherpad.wikimedia.org/p/PaymentsPhp7Test

It wan't translatable before (just a quick hack to get something for IE and GB) but it will be once we get that patch merged ^^^

For PayPal, it looks like we need to explicitly have the donor agree to recurring payments on PayPal's site. So we would have to bounce them back to PayPal for another authorization once they clicked 'yes'.

So we'll have to go through this one processor by processor to see which support a one-time payment with the option to set up recurring afterward without having to re-enter card details.

Looks like we're actually OK - the vast majority of today's txns at the console are from old-api recurring.
If I add up all the ones from today like 'ingenico%', 'recurring ingenico%', 'globalcollect%', and 'recurring globalcollect%', it's within two percent of the number of txns exported from today with status >=800.

See email Re: Changes in Platform for Wikimedia Ref : ref:_00D57ri6p._5001i1yk5m:ref

@Jgreen does GeoLite2 have separate databases for ipv4 and ipv6?

@krobinson sorry! I deployed something last night without testing it well. I've just pushed out a different version that should show actually the cancel button rather than breaking the whole tab

@MBeat33 we got a quick n dirty solution out there, but we haven't tested it on a real live subscription yet. Please let us know if it's working!

@Eileenmcnaughton That hack should get the button back, but I haven't tested whether the button works. A more correct alternative fix is detailed in the commit message.

@DStrine this should probably be done soonish. For users that come to paymentswiki without a country in the URL, we've been geocoding them with a local database of IP ranges that was updated weekly. Looks like the old version isn't going to get any more updates, so we run the risk of mis-locating people as IP addresses are bought and sold. I think the old DB never included IPv6, so we also are mis-locating more people as the IPv6 transition continues.

Ooh, nice! I think @Jdrewniak said that the portal was duplicating the same code to do some eventlogging outside of mediawiki. Wonder if the new stuff can help them?

OK, I'm seeing the loading errors in Chrome now. It's more images inlined into CSS by ResourceLoader as data: urls. This time, it's from core MediaWiki.

Did you intend to have a different field than uri_host in the OR clause looking for Special:BannerLoader? Lools like uri_host has to be exactly meta.wikimedia.org.

Yes @mepps, we did tidy this up in Civi - the patch to do that was attached to T210473

Looks like the php-memcache upgrades shouldn't matter. Our filters are using memcache via Mediawiki's BagOStuff interface, which has its own PHP class to talk directly to the daemon without using either of the PHP libs.

Looking at https://meta.wikimedia.org/wiki/Special:RecentChanges?namespace=8&limit=500&days=7&urlversion=2 I still see plenty of protection for formerly-unprotected translated messages, but I don't see any duplicates like we had before.

@Jgreen and @cwdent - the current thought is to keep the schema almost the same, just changing the contribution_tracking.id column from autoincrement to a writable int, and using a monotonically increasing sequence generator (probably supplied by Redis) to generate the IDs, starting with the max + 1 of the current autoincrement. Contribution tracking rows from the front end would be sent via a new queue.

This is now deployed to all wikis. Now let's keep an eye on the protection log to see if it stops getting multiple entries

Awesome, thanks @AndyRussG

Oops @Eileenmcnaughton , they DO have the same root cause! So, for this issue, we were charging people's recurring donations in USD but recording the contribution as though we had charged them in the original currency. I'll see what I can do to fix the contribution records (so they reflect the reality that we charged people in USD for a month or two).

Verified with payment 4000928094 - initiated in DKK, but the December payment was in USD. The January payment was (correctly) in DKK again.

@Eileenmcnaughton No, I think these are actually separate issues.

@mepps one patch to add logging is deployed, but we could add logging in a couple other places to catch other sorts of failures.

This is done for this year. Since they're only valid for a year, we might think about generating a new on in June or something, so we don't have to think about renewal anywhere near Big English.

On the Ingenico configuration site (https://account.ingenico.com/) we need to click 'API keys' on the left menu, then 'Request API key', then deploy the new keys (in localsettings/SmashPig/ingenico/main.yaml). We can immediately revoke the old one or just let it expire.

Oh darn, it looks like we're using the converted (USD) amount for recurring payments in the new Ingenico API. I'll switch that over ASAP to use the original currency.

• needs support across more processors
• we shouldn't drop PayPal annual subscriptions that the donors have found ways to create
• new SmashPig recurring processor needs more safeguards against double charges