As configured, this is not now placing all the retrieved fields in the right place in CiviCRM; village names are in getaddressIO field {locality} (which logically comes before Town/City in postal addresses, so the $querystring in line 100 should be reordered), but as Civi only has 4 address fields (including "City") + Postcode, getaddressIO address_bits [2], [3] and [4] need to be concatenated into one Civi field - $address['supplemental_address_2'], as shown below (note the use of ".=")
I'm not familiar with submitting commits, so please could someone deal with this.
Cheers, Tom Crawshaw
line 100
querystring = "api-key=
apiKey&all=true&template={line_1},{line_2},{line_3},{line_4},{locality},{town_or_city},{county}";
lines 245 - 256 if (!empty($address_bits[0])) { $address['street_address'] = $address_bits[0]; }
if (!empty($address_bits[1])) {
$address['supplemental_address_1'] = $address_bits[1];
}
if (!empty($address_bits[2])) {
$address['supplemental_address_2']=$address_bits[2];
}
if (!empty($address_bits[3])) {
$address['supplemental_address_2'].=$address_bits[3];
}
if (!empty($address_bits[4])) {
$address['supplemental_address_2'].=$address_bits[4];
}
if (!empty($address_bits[5])) {
$address['city'] = $address_bits[5];
@JonGold We are still getting problems with recurring memberships when using GoCardless Direct debit - the logged error message is "[info] completeRedirectFlowCiviCore: EXCEPTION before successfully setting up subscription at GoCardless: Failed to find interval details". No DD is created.
Your change (in 22825) included the line (1168):
$this->_params['frequency_interval'] = $this->_params['frequency_interval'] ?? $this->_values['fee'][$priceFieldId]['options'][$priceFieldValue]['membership_num_terms'];
It looks as if 'frequency_interval' is not set in $params, and in fact I think this line ought to read:
$this->_params['frequency_interval'] = $membershipTypeDetails['duration_interval'] ?? $this->...
so that the interval between recurring DD charges (12 months in our case) is set using the membership term (i.e. the "duration interval") retrieved from the Membership Type.
Does this make sense? (It appears to work!)
Background: Using BackdropCMS 1.23.1, Civi 5.56.0, GoCardless 1.12.1. Membership Types are set to "optional Auto-renew", but on the Direct Debit signup contribution page, auto-renew is set to "Required" (it's optional for credit card signups)
Hi Thanks for the suggestions, and good to hear that they seem to be working. The Firewall extension is now mandatory with latest Stripe ext, so I hope it works! I also enabled a Honeypot extension, so hopefully that will deter attacks. Stripe Radar is (and was) enabled by default, so not encouraging that it did nothing to stop these recent card tests being made, and getting through to the Stripe system. What screwed our site appeared to be the volume of webhooks coming back from Stripe - every second another SQL call.. Radar for Fraud Teams (chargeable option) might stop rogue webhooks - not sure.
We (Wey & Arun Canal Trust) have also just suffered a massive attack which Stripe say is card testing - brought the server to its knees for few hours, so we had to disable Stripe and its webhooks, and they had to (somehow) cancel the payment attempts, which had continued to run on their system. Like with Hugo, Stripe is saying we must implement mitigation, or they will suspend our account. I'm reluctant to enable Captcha, but may have to, unless there is a better solution. Meanwhile, I am looking at other options including Paypal. The final suggestion in the Stripe guidance is: For example, you might combine CAPTCHAS and rate limits so the first payment attempt from an IP address succeeds without restriction, but subsequent requests made by that same IP address for the next several hours require a captcha verification to succeed. which is more aattractive,if rate limiting can be implemented in this way. Thanks for any assistance, Tom Crawshaw
Hi, I'm getting a lot of these error messages, which I think arise from a hacking attempt this morning on a webform with a Stripe payment. It looks like these error messages arise every hour, with the Stripe cleanup job, and this is confirmed by there being around a hundred entries in civicrm_stripe_paymentintent table where the stripe_intent_id field is null. Can I simply delete the records with null fields in this table, or will that cause other issues?
How much is 1 hour?
Is a quick fix just to manually add the option 'civicrm_contribution' with the group_id for 'entity_batch_extends' to the option_value table? I've tried this on our demo system and all seems to work, but I wanted to check.
We're getting an error when creating a new GA batch ("'civicrm_contribution' is not a valid option for field entity_table") which I guess is to do with this issue, and the fix appears from the discussion to be to add 'civicrm_contribution' as an option in group 'entity_batch_extends', but I can't see how to do this - should there be a function in the extension to do this? Running CiviCRM 5.44.0 and GA extension 3.4.8
Fetchify is a cost-effective provider for small charities, offering special rates for organisations entitled to the PAF file without charge. These changes add Fetchify (aka CraftyClicks) as an option.
Fetchify usage is based on credits, with one credit being used for each search. This meant that partially entered postcodes were triggering a search, and most postcode lookups were therefore costing 2-3 credits (it is not possible to use the JQuery min-length criterion to limit this behaviour, due to the variable length of postcodes). The file ukpostcodelookup.js file is modified to add a regex which disables JQuery autocomplete searches until a valid postcode has been entered.
Fetchify is a cost-effective provider for small charities, offering special rates for organisations entitled to the PAF file without charge. These changes add Fetchify (aka CraftyClicks) as an option.
Fetchify usage is based on credits, with one credit being used for each search. This meant that partially entered postcodes were triggering a search, and most postcode lookups were therefore costing 2-3 credits (it is not possible to use the JQuery min-length criterion to limit this behaviour, due to the variable length of postcodes). The file ukpostcodelookup.js file is modified to add a regex which disables JQuery autocomplete searches until a valid postcode has been entered.
TomCrawshaw (7c66cb05) at 15 Apr 14:03
Add Fetchify/CraftyClicks as an option
TomCrawshaw (9c2b2431) at 15 Apr 13:58
Add postcode validation to avoid multiple searches being made on pa...
TomCrawshaw (74d7d204) at 15 Apr 13:46
Add Fetchify/CraftyClicks as an option
Fetchify (aka CraftyClicks) works on a credits basis, so each search for a postcode (or partial postcode) uses a credit. This change adds a regex to delay a search until a valid postcode has been entered, so that only one credit is used.
TomCrawshaw (22de722f) at 15 Apr 13:37
Add Fetchify/CraftyClicks as an option
TomCrawshaw (9d5da533) at 15 Apr 13:34
Add Fetchify/CraftyClicks as an option
TomCrawshaw (a47f03fd) at 15 Apr 13:26
Add new file
TomCrawshaw (9da0a841) at 15 Apr 13:24
Update ukpostcodelookup.js