We now have 2 (or 3) of 5 integrations using mostly SmashPig calls (the iffy one is Amazon) rather than direct DonationInterface->processor API logic. Once we get AstroPay and PayPal rewritten we will be able to remove a whole lot of base gateway adapter code.

I was just able to see it again, but only in FF (with debug=true) and not in Chrome. Only difference in the generated DOM seems to be the height and width applied directly to the style attributes:

In case we do ever need the actually-maintained successor to the existing library, it's here: https://github.com/yanickrochon/jquery.uix.multiselect

Also worth considering what would break if we specifically included JQ Migrate just on the CN campaign admin page

For now, how about we just turn it off via the countries parameter and send the variant for when you want to turn it on?

OK, this has been deployed and tested with a new Adyen CC recurring and a couple old Adyen CC recurrings, as well as a bunch of Ingenico recurrings. The only missing piece are the Adyen iDEAL recurrings, and we should see those later tonight.

In T291199#7367131, @MBeat33 wrote:

976704 provided more info, including a screenshot from when they tried the TY link Peter suggested:

"I clicked on that link, and got the same, I've attached a screenshot to confirm how it looks. I use a Samsung Galaxy Note 8, Android version 9. I have the Wikipedia app installed."

Yay, we have unit tests now!

@EYener does this have any interest beyond just historical for you? If not, would you please close it as 'declined' or 'invalid'?

No longer using this separate job, have made most everything accept the command-line and config parameters

We're doing them sequentially now, and have them in a new orderspace

This is obsolete - SmashPig now handles Ingenico and Adyen recurring

This morning's change has broken the CentralNotice UI: T291410

@Pcoombe that looks like exactly the cause! Locally I can see the breakage with that setting false, but the multiselect works properly with wgIncludejQueryMigrate = true;

@Pcoombe that sounds like a great idea, asking them to open the link directly.

hmm, i think the problem is more the missing payment method than the country. Still, we should handle the error more gracefully.

This hides the top buttons and footer:

.navbar-nav, footer {
  display: none;
}

Some notes on implementation possibilities here:
https://etherpad.wikimedia.org/p/T276183

Here's the JS error:

Are you seeing any errors in the JS logs? What's the URL you're on or the menu path to get there?

@MBeat33 We've deployed a fix for the problem, but we haven't gone back and fixed the data in Civi yet.

So this looks like something we would do in the orphan rectifier. We currently delete pending rows (so the rectifier doesn't have to process them) when a payment is rejected. To make this work, we would stop deleting pending rows in that case and have the orphan rectifier take more info into account when deciding to capture.

@Ppena @EMartin - In order to get the donor's name and address from Apple Pay without them having to type it, I had to mark it as required. I'm guessing that the majority of Apple Pay users DO have a billing address configured, but those who don't will see the error @Cstone posts above.

OK, it looks like the NULLy rows aren't being created via the matching gifts extension - log lines with them generally have high-numbered log_contact_id values. I guess they're added when people are editing the rows. We're already filtering them out of the CSV export by specifying name_from_matching_gift_db IS NOT NULL, so we probably don't need to do any work here.

OK, this is working when it creates a new contact. When the email and name fields are an exact match for an existing contact, we're not adding the employer name to the matched contact.

@Eileenmcnaughton what do you think of adding the RML contacts to the silverpop exports so we can populate the contact_id and contact_hash columns on the silverpop side? Closing that loop would fix this issue and also our inability to count unique clicks from RML email campaigns (links need to have a contact ID for the uniques table).

Looks like Amazon uses AMZN.COM/BILL in their charge descriptor

@DStrine this would have been pretty helpful to rescue those subscr_start messages dropped by T289175 , and this would be a very quick change.

I think we can close this now, right @Eileenmcnaughton & @Dwisehaupt ?

OK, that fix is deployed and the recurring queue size is coming down. We should probably do a quick grep for the subscr_ids in the crashy messages, check how many of them are missing from the contribution_recur table, and reconstitute and requeue those subscr_signup messages so the associated payments can be imported.