Development issueshttps://lab.civicrm.org/groups/dev/-/issues2023-10-30T02:57:00Zhttps://lab.civicrm.org/dev/core/-/issues/4724Contribution fails mid-donation with geocoding, "on behalf of", and no state/...2023-10-30T02:57:00ZJonGoldContribution fails mid-donation with geocoding, "on behalf of", and no state/provinceOverview
----------------------------------------
The "On Behalf of Organization" code causes a bug in geocoding when a state is not submitted, but other address info is present.
Reproduction steps
-------------------------------------...Overview
----------------------------------------
The "On Behalf of Organization" code causes a bug in geocoding when a state is not submitted, but other address info is present.
Reproduction steps
----------------------------------------
1. Create a contribution page that allows giving "on behalf of an organization". The Organization profile should include state/province and at least one other address field. The state/province must not be required.
2. Submit the form with an organization. Provide at least one part of the address but leave the state blank.
Current behaviour
----------------------------------------
Crashes in geocoding.
Expected behaviour
----------------------------------------
Submits successfully.
Comments
----------------------------------------
This wouldn't be such a big deal but for https://lab.civicrm.org/dev/core/-/issues/2929.
A partial backtrace is below, though there are other ways to reach this code path (e.g. if confirm pages are present/absent).
```
#0 /var/www/connect.mysite.org/vendor/civicrm/civicrm-core/CRM/Core/DAO.php(1419): strtolower()
#1 /var/www/connect.mysite.org/vendor/civicrm/civicrm-core/CRM/Utils/Geocode/Google.php(76): CRM_Core_DAO::getFieldValue()
#2 /var/www/connect.mysite.org/vendor/civicrm/civicrm-core/CRM/Core/BAO/Address.php(1287): CRM_Utils_Geocode_Google::format()
#3 /var/www/connect.mysite.org/vendor/civicrm/civicrm-core/CRM/Core/BAO/Address.php(276): CRM_Core_BAO_Address::addGeocoderData()
#4 /var/www/connect.mysite.org/vendor/civicrm/civicrm-core/CRM/Core/BAO/Address.php(1365): CRM_Core_BAO_Address::fixAddress()
#5 /var/www/connect.mysite.org/vendor/civicrm/civicrm-core/CRM/Core/BAO/Location.php(52): CRM_Core_BAO_Address::legacyCreate()
#6 /var/www/connect.mysite.org/vendor/civicrm/civicrm-core/CRM/Contact/BAO/Contact.php(327): CRM_Core_BAO_Location::create()
#7 /var/www/connect.mysite.org/vendor/civicrm/civicrm-core/CRM/Contact/BAO/Contact.php(1921): CRM_Contact_BAO_Contact::create()
#8 /var/www/connect.mysite.org/vendor/civicrm/civicrm-core/CRM/Contribute/Form/Contribution/Confirm.php(1296): CRM_Contact_BAO_Contact::createProfileContact()
#9 /var/www/connect.mysite.org/vendor/civicrm/civicrm-core/CRM/Contribute/Form/Contribution/Confirm.php(2312): CRM_Contribute_Form_Contribution_Confirm::processOnBehalfOrganization()
#10 /var/www/connect.mysite.org/vendor/civicrm/civicrm-core/CRM/Contribute/Form/Contribution/Confirm.php(836): CRM_Contribute_Form_Contribution_Confirm->processFormSubmission()
#11 /var/www/connect.mysite.org/vendor/civicrm/civicrm-core/CRM/Core/Form.php(617): CRM_Contribute_Form_Contribution_Confirm->postProcess()
#12 /var/www/connect.mysite.org/vendor/civicrm/civicrm-core/CRM/Contribute/Form/Contribution/Main.php(1318): CRM_Core_Form->mainProcess()
#13 /var/www/connect.mysite.org/vendor/civicrm/civicrm-core/CRM/Contribute/Form/Contribution/Main.php(1076): CRM_Contribute_Form_Contribution_Main->skipToThankYouPage()
```5.68.0JonGoldJonGoldhttps://lab.civicrm.org/dev/core/-/issues/654Contribution Field Map not saving Soft Credit Type2022-11-30T19:39:36ZphilmorbruContribution Field Map not saving Soft Credit TypeWhen importing Contributions with Soft Credits and saving a field mapping, the Soft Credit fields do not save the type of soft credit in the mapping. When reusing the saved mapping, the user must change the "Matching CiviCRM Field" to a ...When importing Contributions with Soft Credits and saving a field mapping, the Soft Credit fields do not save the type of soft credit in the mapping. When reusing the saved mapping, the user must change the "Matching CiviCRM Field" to a field other than Soft Credit, and then change it back to Soft Credit to select the proper choice. Compare attached files of incorrect and expected/correct behavior.
![wrong](/uploads/ef41cb0ec6cf2b02a40a0a3cbbdfa6ed/wrong.jpeg)
![right](/uploads/185289c1c32fde58999381d14aefee65/right.jpeg)
Replicated on clean install of 5.7.0 on Joomla 3.9.https://lab.civicrm.org/dev/joomla/-/issues/7Contribution Field Map not saving Soft Credit Type2019-01-09T17:16:43ZphilmorbruContribution Field Map not saving Soft Credit TypeWhen importing Contributions with Soft Credits and saving a field mapping, the Soft Credit fields do not save the type of soft credit in the mapping. When reusing the saved mapping, the user must change the "Matching CiviCRM Field" to a ...When importing Contributions with Soft Credits and saving a field mapping, the Soft Credit fields do not save the type of soft credit in the mapping. When reusing the saved mapping, the user must change the "Matching CiviCRM Field" to a field other than Soft Credit, and then change it back to Soft Credit to select the proper choice. Compare attached files of incorrect and expected/correct behavior.![wrong](/uploads/d4ebc3db40919ac2542c95449f817086/wrong.jpeg)![right](/uploads/a1914fa45e5d1b85af0c0de6c4ec6011/right.jpeg)
Replicated on clean install of 5.7.0 on Joomla 3.9.https://lab.civicrm.org/dev/core/-/issues/3892Contribution for event registration with multiple participants lists them mul...2022-10-11T11:57:34Zthoni56Contribution for event registration with multiple participants lists them multiple times in "associated participants"Overview
----------------------------------------
If an event registration is made for multiple participants the corresponding contribution view lists participants multiple times.
Reproduction steps
-------------------------------------...Overview
----------------------------------------
If an event registration is made for multiple participants the corresponding contribution view lists participants multiple times.
Reproduction steps
----------------------------------------
1. Do a single registration with multiple participants to a paid event
2. Go to the resulting contribution and view it
Current behaviour
----------------------------------------
In the section "Associated participants" each participant is listed multiple times, even for the same registration option.
E.g. for this registration for 8 participants (from the "Contribution Amount" section of the same view):
![Skärmbild_2022-10-04_205306](/uploads/93ad061f56970aca8b854c2c41d9f78b/Skärmbild_2022-10-04_205306.png)
we get this "Associated Participants" listing:
![Skärmbild_2022-10-04_205401](/uploads/404d53d7cec254a9aae24962324badef/Skärmbild_2022-10-04_205401.png)
Expected behaviour
----------------------------------------
I'm expecting to see each participant listed only once.
Environment information
----------------------------------------
The event has price sets with multiple options.
![Skärmbild_2022-10-04_223722](/uploads/db466e84bf3a11a04db31181259eed4a/Skärmbild_2022-10-04_223722.png)
![Skärmbild_2022-10-04_223744](/uploads/82129e1b4bd6f32152b53e57df44f815/Skärmbild_2022-10-04_223744.png)
Comments
----------------------------------------
I encountered this since I was trying to get a nice list to include in our invoices. (We cannot use the CiviCRM invoices, partly because of dev/core#3881)5.56.0https://lab.civicrm.org/dev/core/-/issues/886Contribution gets saved with wrong financial type2019-04-25T07:00:42Zrita_compucorpContribution gets saved with wrong financial typeHi all!
There is a small issue when you have a membership type with 'financial type A' and having a membership price set with 'financial type B', and the contribution page is using the price set.
Steps:
1. I have a membership called ‘...Hi all!
There is a small issue when you have a membership type with 'financial type A' and having a membership price set with 'financial type B', and the contribution page is using the price set.
Steps:
1. I have a membership called ‘General’
2. I have 2 membership financial types: ‘member dues’ and ‘member dues 20% discount’
3. The ‘General’ membership type is using ‘member dues’ financial type
4. I create a membership price set, adding the ‘General’ membership type with the other financial type (‘member dues 20% discount’) and save it
5. Then I set up a contribution page using financial type ‘member dues 20% discount’
- enable the member processing on the contribution page
- and select the previously created member price set
6. Then I sign up to this membership
- --> and the created contribution is using the ‘member dues’ financial type - **Incorrect** https://nimb.ws/nf8wlZ
- --> the contribution’s line item is using the ‘member dues 20% discount’ financial type - **Correct**
- --> the contribution's transaction item is using the ‘member dues 20% discount’ financial type - **Correct**
I would have expected for the main contribution to use the ‘member dues 20% discount’ too, but apparently its using the Membership Type’s financial type. I have checked on the latest civicrm demo (5.14) site as well and the behaviour is the same.
One of our clients reported this.
Thanks,
Ritahttps://lab.civicrm.org/dev/core/-/issues/1430Contribution ID token not working with 'contribution type' scheduled reminders2021-09-13T05:23:27Zellen_compucorpContribution ID token not working with 'contribution type' scheduled remindersThe Contribution ID token does not appear to be working when used with with 'contribution type' scheduled reminders, however it does seem to still work when used in sending an email from 'find contributions'.
----------------------------...The Contribution ID token does not appear to be working when used with with 'contribution type' scheduled reminders, however it does seem to still work when used in sending an email from 'find contributions'.
----------------------------------------
Reproduction steps
----------------------------------------
1. Go to /civicrm/admin/scheduleReminders?reset=1
1. Create a new scheduled reminder with type 'contribution type', a financial type selected, and the contribution status 'completed'
1. Set scheduled reminder to be sent 0 hours after received date
1. Give the email a subject, and in the email body, insert the token 'contribution ID'
1. Save the scheduled reminder
1. Create a new contribution on any contact record (using the same financial type used previously, and with status 'completed).
1. Execute the 'send scheduled reminders' scheduled job
Current behaviour
----------------------------------------
Scheduled reminder email is sent, but contribution ID has not been generated
Expected behaviour
----------------------------------------
Contribution ID should have been generated and should be include in the received email
Environment information
----------------------------------------
* __CiviCRM:__ 5.19.2
* __PHP:__ _7.2
* __CMS:__ Drupal
Comments
----------------------------------------
As mentioned above, the token does seem to work correctly when used in an email sent via the 'search contributions' action menu5.43.0https://lab.civicrm.org/dev/core/-/issues/3918Contribution in Australia returns yellow error banner with "setBillingCountry...2022-11-22T22:57:09ZjhungerfordContribution in Australia returns yellow error banner with "setBillingCountry expects ISO 3166-1 alpha-2 country code"Overview
----------------------------------------
After upgrading to CiviCRM 5.54.0, test donations result in a yellow error banner with the message ```setBillingCountry expects ISO 3166-1 alpha-2 country code```. I haven't tried a real ...Overview
----------------------------------------
After upgrading to CiviCRM 5.54.0, test donations result in a yellow error banner with the message ```setBillingCountry expects ISO 3166-1 alpha-2 country code```. I haven't tried a real donation. We are located in Australia, and we use Stripe as the payment processor.
I asked a question about this issue here: https://chat.civicrm.org/civicrm/pl/atwjzr4ozf8fbdkokzegze9iiw
Reproduction steps
----------------------------------------
1. Upgrade a CiviCRM site to 5.54.0
2. Navigate to a Test-drive contribution page
3. Attempt to make a test contribution
Current behaviour
----------------------------------------
A yellow error banner appears with the message ```setBillingCountry expects ISO 3166-1 alpha-2 country code```.
Expected behaviour
----------------------------------------
The test contribution should be processed, and the donor should be redirected to the thank-you page.
Environment information
----------------------------------------
* __Browser:__ Chromium 105.0.5195.125 (Official Build) Arch Linux (64-bit)
* __CiviCRM:__ 5.54.0 (upgraded from 5.53.0)
* __PHP:__ 7.4.30
* __CMS:__ Drupal 7.92, also tested on Drupal 9.4.7
* __Database:__ 10.3.36-MariaDB, for debian-linux-gnu (x86_64) using readline 5.2
* __Web Server:__ Apache 2.4
* __civicrm-Stripe version:__ 6.7.11, also tested on 6.7.10
* __Payment Shared version:__ 1.2.9, also tested on 1.2.8
Comments
----------------------------------------
I'll post an example of a failing test contribution page in the chat linked above.
Reverting to CiviCRM 5.53.0 results in a working contribution page.5.55.1https://lab.civicrm.org/dev/core/-/issues/1617Contribution Invoice template improvements2022-06-24T03:29:06Zmagnolia61Contribution Invoice template improvementsThe Contribution Invoice workflow template needed some quick fixes:
* style wise clean up
* some layout fixes
* make CiviCRM logo comply with Display "empowered by CiviCRM" setting
**BEFORE** (bit of a messy layout)
![Screenshot_from_2...The Contribution Invoice workflow template needed some quick fixes:
* style wise clean up
* some layout fixes
* make CiviCRM logo comply with Display "empowered by CiviCRM" setting
**BEFORE** (bit of a messy layout)
![Screenshot_from_2020-02-17_22-41-59](/uploads/291c8d5752d6aa26de2c96b9fd11961f/Screenshot_from_2020-02-17_22-41-59.png)
**AFTER** (clean professional layout)
![Screenshot_from_2020-02-17_22-52-02](/uploads/231174cee285853c5bf2d86b2e23622c/Screenshot_from_2020-02-17_22-52-02.png)https://lab.civicrm.org/dev/core/-/issues/552Contribution net amount not re-calculated when fee amount is changed2018-12-05T20:27:27Zaydunsaidan.saunders@squiffle.ukContribution net amount not re-calculated when fee amount is changedWhen a contribution is edited and the fee amount changed, the net amount is not being recalculated.
Scenario 1:
Go to a contact summary
Contributions > Record Contribution
Choose a financial type
Enter amount as 100
Expand Add...When a contribution is edited and the fee amount changed, the net amount is not being recalculated.
Scenario 1:
Go to a contact summary
Contributions > Record Contribution
Choose a financial type
Enter amount as 100
Expand Additional Details section
(Incidentally note stray help text "Net value of the contribution (Total Amount minus Fee)")
Enter Fee Amount as 1.23
Save
View the Contribution just created and note Total amount = $100, Fee amount $1.23, Net amount $98.77 -> Correct
Scenario 2:
Go to a contact summary
Contributions > Record Contribution
Choose a financial type
Enter amount as 100
Save
View the Contribution just created and note Total amount = $100, Fee amount $0, Net amount $100 -> Correct
Now edit the contribution
Expand Additional Details section
Enter Fee Amount as 1.23
Save
View the Contribution just created a note Total amount = $100, Fee amount $1.23, **Net amount $100** -> Total and Fee amounts are correct, but the **Net amount is not recalculated**.
May be related to https://github.com/civicrm/civicrm-core/pull/126625.8https://lab.civicrm.org/dev/core/-/issues/1504Contribution note removed when edited contribution2023-01-29T05:03:15ZtapashContribution note removed when edited contributionOverview
----------------------------------------
Contribution note does not retrieve when editing a contribution, therefore it gets deleted when saved the contribution.
Reproduction steps
----------------------------------------
1. Cli...Overview
----------------------------------------
Contribution note does not retrieve when editing a contribution, therefore it gets deleted when saved the contribution.
Reproduction steps
----------------------------------------
1. Click on **Edit contribution of any individual**.
1. clicked **Save**.
1. Got a message "Deleted - Selected Note has been deleted successfully."
Current behaviour
----------------------------------------
notes field blank althogh there was a message save in previous edit.
![Screenshot_2020-01-01_at_23.17.57](/uploads/9f9555b85ded80e5f41af0bc7ffcf180/Screenshot_2020-01-01_at_23.17.57.png)
Expected behaviour
----------------------------------------
message should show when editing
Environment information
----------------------------------------
* __CiviCRM:_5.20.3https://lab.civicrm.org/dev/core/-/issues/2449Contribution page creates a wrong amount and probably payment processor use t...2021-03-15T18:40:07ZjaapjansmaContribution page creates a wrong amount and probably payment processor use this wrong amount**Steps to reproduce**
1. Set localization settings **decimal separator**: `,` and **thousand separator**: `.`
2. Create a contribution page with a amount `897.654.321,987654321`
3. Make a contribution with this contribution page in liv...**Steps to reproduce**
1. Set localization settings **decimal separator**: `,` and **thousand separator**: `.`
2. Create a contribution page with a amount `897.654.321,987654321`
3. Make a contribution with this contribution page in live mode. (We used a dummy payment processor)
**Whats is wrong?**
The amount is changed from `897.654.321,99` to `89.765.432.198.765,00` this is shown on the thank you page as in CiviCRM contribution. So it looks like the wrong amount is charged on the dummy payment processor.
**Screenshots**
![Screenshot_20210309_120737](/uploads/b26eded4cc5e5312a44daa90b1971db9/Screenshot_20210309_120737.png)
![Screenshot_20210309_120742](/uploads/dfcf28497afd690f702ca5399fe89672/Screenshot_20210309_120742.png)
![Screenshot_20210309_120643](/uploads/4fe5b4cfcb0d28d5ca5177d83b4c30fd/Screenshot_20210309_120643.png)
![Screenshot_20210309_120834](/uploads/dfb07362bc3421f7fdc4e4c9fd40b5d4/Screenshot_20210309_120834.png)
**Environment**
Drupal 7
CiviCRM 5.37.aplha1 (dmaster)5.37.0https://lab.civicrm.org/dev/core/-/issues/4012Contribution Page credit card expiry months are incorrectly offset when the t...2022-12-17T23:11:48ZbgmContribution Page credit card expiry months are incorrectly offset when the timezone is WhitehorseFound an interesting bug that only happens with users who have chose the America/Whitehorse timezone (-0700). It does not happen if we chose another similar timezone (America/Vancouver, America/Yellowknife, etc).
To reproduce on dmaster...Found an interesting bug that only happens with users who have chose the America/Whitehorse timezone (-0700). It does not happen if we chose another similar timezone (America/Vancouver, America/Yellowknife, etc).
To reproduce on dmaster / drupal7:
- login as the demo user
- change the user's timezone to America/Whitehorse
Then go to a contribution page:
https://dmaster.demo.civicrm.org/civicrm/contribute/transact?reset=1&id=2
![image](/uploads/ea61f948003f258501391a3c90e2a6e3/image.png)5.58.0https://lab.civicrm.org/dev/core/-/issues/961Contribution page including 2 email fields does not respect dedupe rule.2019-08-02T01:27:13ZjitendraContribution page including 2 email fields does not respect dedupe rule.Unsupervised rule fails if we have 2 email fields to match on with latter set as empty. To replicate -
- Add a profile with first name, last name, billing email and work email.
- Create a contact with first name = "Test", Last name = "D...Unsupervised rule fails if we have 2 email fields to match on with latter set as empty. To replicate -
- Add a profile with first name, last name, billing email and work email.
- Create a contact with first name = "Test", Last name = "Dedupe" and email = "test@example.com"
- Add the profile to a contribution page.
- Submit the contribution page anonymously and enter First name = Test, Last name = "Dedupe" and billing email = "test@example.com". Keep work email as empty.
- Complete the payment.
![image](/uploads/43e2533c1a6f37dc9251b380755ca0f9/image.png)
- The payment should be recorded against the existing contact based on dedupe matching.
- As we do not have any value filled for second email field, dedupe fails and a new contact is created with same details.5.17.0jitendrajitendrahttps://lab.civicrm.org/dev/core/-/issues/2860Contribution Page Premium "No Thank You" is always disabled2023-10-01T05:03:26ZredgarContribution Page Premium "No Thank You" is always disabledOverview
----------------------------------------
Contribution pages that have the option of Premiums enabled always have the "No Thank You" checkbox disabled. This is true even if you select a donation greater than the amount for the mi...Overview
----------------------------------------
Contribution pages that have the option of Premiums enabled always have the "No Thank You" checkbox disabled. This is true even if you select a donation greater than the amount for the minimum premium. The checkbox still works - but the input field has disabled="disabled" and the checkbox is always grayed out.
I'm using civicrm 5.41.1 on Joomla.
Proposed behavior
----------------------------------------
Code could be written to enable the checkbox once a donation amount greater than the minimum is selected - but it would be easier, and maybe even preferable to never disable the checkbox.
[screenshots](/uploads/81546b7525d3093b8483b6ffc37f7e35/screenshots.png)
Comments
----------------------------------------
The code that sets it to disabled in in templates/CRM/Contribute/Form/Contribution/PremiumBlock.tpl
Line numbers 44, 47, 96, and 99 hardcode the checkbox to disabled.https://lab.civicrm.org/dev/core/-/issues/2229Contribution page start/end dates don't affect widget's total contributions sum2023-06-04T05:03:24ZedgimarContribution page start/end dates don't affect widget's total contributions sumWhen using a contribution widget associated with a particular contribution-page, it would be nice to be able to modify the start/end dates of the contribution page, and have them affect which contributions are included when computing the...When using a contribution widget associated with a particular contribution-page, it would be nice to be able to modify the start/end dates of the contribution page, and have them affect which contributions are included when computing the sum that is displayed by the widget. Currently this date-range has no effect on the computed widget sum.
The use-case is this: a contribution page is set up, and the user wants to continue to be able to use the same contribution page and widget, but to adjust the date-range (e.g. to match a new year or matching-grant period) on occasion.
On a tangentially related topic, it would probably be better to still allow people to access a contribution page even if the current date is outside the start/end date range. Otherwise potential donors are greeted with an "invalid page" message instead of a form by which they can donate.https://lab.civicrm.org/dev/core/-/issues/322Contribution page, completing this form on behalf of someone else: JavaScript...2018-08-19T22:47:31ZdavejContribution page, completing this form on behalf of someone else: JavaScript error for checkbox fieldOn a contribution page, when "completing this form on behalf of someone else", a JavaScript syntax error occurs when the page includes a profile with a checkbox field and the contact has this field checked.
Steps to replicate:
1. Creat...On a contribution page, when "completing this form on behalf of someone else", a JavaScript syntax error occurs when the page includes a profile with a checkbox field and the contact has this field checked.
Steps to replicate:
1. Create a custom field, Test Checkbox: Alphanumeric, CheckBox with 1 option:
label "I agree", value 1.
2. Create a profile including this field.
3. Include this profile on a contribution page.
4. Edit Contact A and check the "I agree" checkbox.
5. On the contribution page, click "Not demo test, or want to do this for a different person?"
6. Choose Contact A.
Expected result:
Form populates with Contact A's data.
Actual result:
JavaScript error: "Syntax error, unrecognized expression: [name=custom_13[1]]".
Form does not populate with Contact A's data.
I have a fix for this, will create a PR & link to this issue.5.6https://lab.civicrm.org/dev/core/-/issues/1999Contribution pages - When email addresses are defined for the Receipt, CC Rec...2020-09-05T00:05:31Zjustinfreeman (Agileware)Contribution pages - When email addresses are defined for the Receipt, CC Receipt To / BCC Receipt To fields and emails to those recipients bounce then that bounce is counted against the Contribution Contact and not the actual bounced recipientIf you set the Receipt email addresses on a Contribution page and ANY of those email addresses bounce then that bounce is recorded against the CiviCRM Contact that the receipt was sent too. So if you have 3 or more CC/BCC email addresses...If you set the Receipt email addresses on a Contribution page and ANY of those email addresses bounce then that bounce is recorded against the CiviCRM Contact that the receipt was sent too. So if you have 3 or more CC/BCC email addresses defined and they ALL bounce. Then that CiviCRM Contact's email is immediately put ON HOLD.
This is because the receipt email has the bounce return path of the CiviCRM contact and a single email is sent with the CC/BCC defined.
A possible workaround would be to send individual emails for each of the email addresses defined in the CC Receipt To / BCC Receipt To fields.
A symptom of this problem occurring is that new members, event participants and donors have their email addresses immediately marked as on hold after contributing or registering for an event.https://lab.civicrm.org/dev/core/-/issues/2322Contribution Pages pager should have page bottom controls2021-04-15T21:57:09ZlarsssandergreenContribution Pages pager should have page bottom controlsIf you have more than 50 contribution pages, they are split onto more than one screen. There is a pager control to go to the next page, see how many pages there are, etc. on the top of the screen, but not on the bottom of the page. If yo...If you have more than 50 contribution pages, they are split onto more than one screen. There is a pager control to go to the next page, see how many pages there are, etc. on the top of the screen, but not on the bottom of the page. If you scroll down to the bottom of the page, you may think there are no more contribution pages. Other lists (groups, mailings, search results, campaigns) have pager controls on the bottom of the page, so this is inconsistent.
Design of the different pagers is inconsistent, so I'm not sure what would be the best design. Simplest would be simply to copy the top of the page controls to the bottom of the page, but I'm open to ideas about how this should be done.https://lab.civicrm.org/dev/core/-/issues/4487Contribution pages with extra URL parameters lead to incorrect AJAX URL const...2023-08-10T14:20:50ZsebalisContribution pages with extra URL parameters lead to incorrect AJAX URL constructed in buildPaymentBlock – users cannot proceed to payHi,
I encountered an error while building an Engish version of a contribution page on a system that mostly operates in German. While entering translated texts for all elements, I was told that some elements (button captions, the “total”...Hi,
I encountered an error while building an Engish version of a contribution page on a system that mostly operates in German. While entering translated texts for all elements, I was told that some elements (button captions, the “total” text) cannot be configured in the contribution page or the profiles and price sets it includes (for all of which I built translated copies). Instead, they are supplied by core itself so we need to signal to core that they should be produced in English, too.
By default, the language for these elements seems to be determined by the browser language, but I was interested in overriding this and was advised (by @Detlev) that I could add a (Drupal-specific) GET parameter `language=en` to the URL for that purpose. This does work – up to the point where users want to choose their payment options.
My contribution page (on a Drupal 9 system) has a choice between the PayPal and SEPA processors. When users click the respective radio button, an AJAX request is issued to a URL like
`<host>/civicrm/payment/form?formName=Main&is_back_office=&id=14&pre_profile_id=78&processor_id=&language=en3&payment_instrument_id=undefined¤cy=EUR&snippet=json`
Notice that the value for `language` has been extended from `en` to `en3` and the URL parameter for processor_id is empty. This leads to a popup with a complaint about a network error, and users cannot proceed. Inspecting the communication reveals that the AJAX request returns a 500 status, and the Civi log contains information about the empty value for `processor_id` being the problem.
It turns out that the page has some inline JavaScript code that tries to build the processor ID into the AJAX URL in the `buildPaymentBlock` function. It does this by concatenating the parameter `type` to a partial URL that itself is produced using the crmURL smarty tag. On my payment page, the offending line was this:
```
var dataUrl = "/civicrm/payment/form?formName=Main&is_back_office=&id=14&pre_profile_id=78&processor_id=&language=en" + type;
```
This is rendered by the following line in `templates/CRM/common/paymentBlock.tpl`:
```
var dataUrl = "{crmURL p='civicrm/payment/form' h=0 q="formName=`$form.formName``$urlPathVar``$isBackOfficePathVar``$profilePathVar``$contributionPageID``$preProfileID`processor_id="}" + type;
```
It is obviously assumed that the string produced by crmURL ends with `processor_id=`. However, if extra parameters such as `language=en` are present, these end up at the end of the string produced by crmURL, although the parameters in the call to the Smarty tag do not indicate this. Some further lines in the code add other parameters, leading to the full list of parameters given above. But this line is where the problem is created. The line was executed with `type` set to 3 (the ID of the SEPA processor in my setup) and this is how the `language` value became `en3` and `processor_id` remained empty.
I am going to submit a pull request with a solution with this issue. Since we apparently cannot know where `type` should be inserted, the solution had to involve some kind of templating instead of string concatenation. I would have preferred some templating function provided by one of the JavaScript libraries that are already included on the page. The only candidate library I found was Lodash which provides `CRM._.template`. The syntax to use would have been `<%= type %>`, but that gets URL-escaped by the Smarty tag. Correcting this would become messy, so I resorted to a hand-crafted call to String.replace using `__type__` as the placeholder, in the hope that there is no real risk of this string appearing somewhere else in `dataURL` by accident. Edit: I have made the replacement more specific in a second commit, so the risk of it applying in the wrong place should now be vanishingly small.
I hope that this is an acceptable solution. The problem seems generic enough to affect other people too. I encountered and patched this on an old system (5.58.1, there are issues that prevent us from immediately updating), but the line in `templates/CRM/common/paymentBlock.tpl` is unchanged in the current master branch and I assume that the way the crmURL Smarty tag works hasn’t changed either.https://lab.civicrm.org/dev/core/-/issues/1935Contribution Pages with On Behalf of Organization profile enabled stop workin...2020-08-08T16:09:03ZKarinGContribution Pages with On Behalf of Organization profile enabled stop working in ESR 5.27.4 [Regression]Upgrading from 5.21.3 (previous ESR) to 5.27.4 (current ESR).
**To reproduce:**
Enable the checkbox "Allow individuals to contribute and / or signup for membership on behalf of an organization" in the Contribution Page settings:
![image...Upgrading from 5.21.3 (previous ESR) to 5.27.4 (current ESR).
**To reproduce:**
Enable the checkbox "Allow individuals to contribute and / or signup for membership on behalf of an organization" in the Contribution Page settings:
![image](/uploads/6583b87856bc1ea6f1d22446686b7fb6/image.png)
**Problem:**
Visit Contribution Page + do NOT select to make an On Behalf of Contribution - pick your amounts, fill in card details and then click Review Contribution button at the bottom of the form:
Nothing happens; no error message. Just a non-responsive button.
**Digging in:** opening up the On Behalf of Contribution (after clicking Review Contribution button and nothng happening):
![image](/uploads/56551687401cae077e82ec64fdf837d6/image.png)
**Conclusion** -> Province/State is required even if this On Behalf of section is hidden.
**Quick Workaround:** in Localization -> set a default Province.
Solution @seamuslee -> see https://chat.civicrm.org/civicrm/pl/ehfq919d4jb6mk4yfmmy13mtgr
This fix was not backported to 5.27.x yet