CiviCRM Core issueshttps://lab.civicrm.org/dev/core/-/issues2019-07-19T20:27:43Zhttps://lab.civicrm.org/dev/core/-/issues/1133Payment method name is displayed instead of label in payment block for Manual...2019-07-19T20:27:43ZDon WijesooriyaPayment method name is displayed instead of label in payment block for Manual payment`getPaymentTypeLabel()` method in `CRM_Core_Payment_Manual` class returns payment method name instead of label.
````php
/**
* Get the name of the payment type.
*
* @return string
*/
public function getPaymentTypeLabel() ...`getPaymentTypeLabel()` method in `CRM_Core_Payment_Manual` class returns payment method name instead of label.
````php
/**
* Get the name of the payment type.
*
* @return string
*/
public function getPaymentTypeLabel() {
return CRM_Core_PseudoConstant::getName('CRM_Contribute_BAO_Contribution', 'payment_instrument_id', $this->getPaymentInstrumentID());
}
````
## Fix
````php
/**
* Get the name of the payment type.
*
* @return string
*/
public function getPaymentTypeLabel() {
return CRM_Core_PseudoConstant::getLabel('CRM_Contribute_BAO_Contribution', 'payment_instrument_id', $this->getPaymentInstrumentID());
}
````5.17.0https://lab.civicrm.org/dev/core/-/issues/1120Export help info does not match code2019-07-16T20:03:55ZeileenExport help info does not match codeIn the export screen we see that the postal greeting or addressee greeting can change if more than 2 contacts are merged
![Screen_Shot_2019-07-16_at_9.32.04_AM](/uploads/871c946c283258e8e4c6e68bae72e1d7/Screen_Shot_2019-07-16_at_9.32.04...In the export screen we see that the postal greeting or addressee greeting can change if more than 2 contacts are merged
![Screen_Shot_2019-07-16_at_9.32.04_AM](/uploads/871c946c283258e8e4c6e68bae72e1d7/Screen_Shot_2019-07-16_at_9.32.04_AM.png)
In the code the rules are that 2 or more contacts being merged use the rules (ie if contacts are merged then use the rules). (There is some mickey mouse separate handling where it seems the code attempts to only use the 'other' logic for 2 or more
I can't see why you wouldn't use the merge string for any merges - which would simplify the code a lot too
@lcdweb @colemanw thoughts - can we tweak the above to '(when merging contacts to one row)' & clean up the code to just do that (without extra code that with more or less success attempts to do ? something ? when there are only 2 & use the merge string where there is more than 2
I *think* the intent might have been that you could choose different behaviour for many vs just 2 but in practice you can't actually select that in the UI5.17.0https://lab.civicrm.org/dev/core/-/issues/1118Case summary report filters incorrectly for case type2019-07-21T23:07:54ZDeepak SrivastavaCase summary report filters incorrectly for case typeCase summary report uses REGEXP filtering for case type:
`WHERE case_civireport.case_type_id REGEXP '[[:cntrl:]]*5[[:cntrl:]]*' `
Which results in records where case type id consists of 5 (for this example).
![image](/uploads/485a42f6d...Case summary report uses REGEXP filtering for case type:
`WHERE case_civireport.case_type_id REGEXP '[[:cntrl:]]*5[[:cntrl:]]*' `
Which results in records where case type id consists of 5 (for this example).
![image](/uploads/485a42f6d595079ce990816695e1b4a6/image.png)
The clause looks old and appears to be based on assumption that case could be based on multiple case types. Case type however is an integer column and could use where() clause of CRM/Report/Form.php.
The problem also been raised on stack exchange - https://civicrm.stackexchange.com/questions/30573/case-type-filter-bug-in-case-summary-report-multiple-case-types-reported.
A PR would follow.5.17.0https://lab.civicrm.org/dev/core/-/issues/1109Contact Reference fields are not updated when merging contacts2019-08-08T03:27:12ZPatrick Figelpfigel@greenpeace.orgContact Reference fields are not updated when merging contactsWhen contacts are merged, any Contact Reference custom fields pointing to the contact that was deleted will not be updated to point to the remaining contact.
This is not a recent regression. It used to work in 4.6, but was broken at som...When contacts are merged, any Contact Reference custom fields pointing to the contact that was deleted will not be updated to point to the remaining contact.
This is not a recent regression. It used to work in 4.6, but was broken at some point after that. (Confirmed as broken in 5.7, 5.13 and master.)5.17.0https://lab.civicrm.org/dev/core/-/issues/1104Make admin panels hookable2019-08-01T04:07:14ZyashodhaMake admin panels hookableMake it easy to show/hide items on administer screen.Make it easy to show/hide items on administer screen.5.17.0yashodhayashodhahttps://lab.civicrm.org/dev/core/-/issues/1073Performance : Expose some important smarty configuration variables outside th...2021-03-29T14:14:27ZVangelisPPerformance : Expose some important smarty configuration variables outside the smarty classWhile working with multiple "complex" civicrm sites on dedicated server instances, I've noticed that even though the database was highly optimized, all sites were having some sort of overhead of nearly 1.5-2 seconds before rendering the...While working with multiple "complex" civicrm sites on dedicated server instances, I've noticed that even though the database was highly optimized, all sites were having some sort of overhead of nearly 1.5-2 seconds before rendering the results. That is on the contact display page, on search, advanced search and so on.
Added Redis caching to CiviCRM, helped with a bit of small improvement but again, the delay was there.
Digging deeper with XHProf, I've found out that for every page that was loading, Smarty was checking if the templates needed recompiling.
Long story short, inside the /packages/Smarty/Smarty.class.php there's a variable that is `true` by default:
`var $compile_check = true;`
Description is the following:
> This tells Smarty whether to check for recompiling or not. Recompiling does not need to happen unless a template or config file is changed. Typically you enable this during development, and disable for production.
Disabling this in production, i did see a big improvement in terms of speed, as Smarty is now being instructed not scan every time if it needs to recompile the templates.
My suggestion would be to expose that variable (along with `$caching`) as a constant so that for example we can add it to `settings.php` as 'false' in production environments.
I could provide a patch (if needed) that does that.
PS. "complex" = a CiviCRM instance with many extensions and many tpl injections through custom extensions.5.17.0https://lab.civicrm.org/dev/core/-/issues/1061Bad popup on update recurring screen2019-08-21T16:48:10ZeileenBad popup on update recurring screenWe are seeing a popup when checksum users attempt to update a recurring contribution.
![Screenshot_2019-06-12_at_18.50.39](/uploads/85512b40438dcd0e198fddc51dd64c00/Screenshot_2019-06-12_at_18.50.39.png)
This appears to date back to M...We are seeing a popup when checksum users attempt to update a recurring contribution.
![Screenshot_2019-06-12_at_18.50.39](/uploads/85512b40438dcd0e198fddc51dd64c00/Screenshot_2019-06-12_at_18.50.39.png)
This appears to date back to March 2018 when custom data was added to this form (by @mattwire ) - which means we don't need to target the rc & I'm inclined to focus on 'the right fix' on master.
Fundamentally we have a backoffice form that is being exposed for front end users. I have personally proposed doing similar to the 'Add Payment' form recently so it probably bares a little thought. In this case the custom data is not accessible to checksum accessors of the page & superficially the problem is not that it is not available but that it is noisily not available.
I feel like at a conceptual level we probably want to either
1) say front end forms are front end forms and back end forms are back end forms and never the twain shall meet or
2) set the front end form flag whenever a both-use-form is accessed with a checksum
In terms of the custom data I feel the safest option is just to say 'don't expose custom data on both-use forms to users without Access CiviCRM'. If people want to this might not be the right form approach for them - they can actually probably intervene by hook but the risk of exposing inappropriate custom data fields seems real.
This probably also impacts on theming & provides an obvious way not to present un-themed versions of these pages (@seamuslee @totten )5.17.0https://lab.civicrm.org/dev/core/-/issues/987Issue with alterReportVars hook invoke2019-08-01T04:07:14ZsushantpIssue with alterReportVars hook invokeCurrently alterReportVars hook is invoked after grand total and section total calculations.
When alterReportVars used for altering any values in report rows , calculations does not take that into
consideration.
alterReportVars hook ...Currently alterReportVars hook is invoked after grand total and section total calculations.
When alterReportVars used for altering any values in report rows , calculations does not take that into
consideration.
alterReportVars hook should invoked before grand total and section total calculations.5.17.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/949Export table field size is inadequate for State/Province data values2019-08-06T20:35:08ZorigamiusaExport table field size is inadequate for State/Province data valuesExporting a custom data field of type State/Province crashes with a db error "Data too long for column" if the State/Province has a long name (example: no crash with "Massachusetts", but crash with "District of Columbia"). The temporary ...Exporting a custom data field of type State/Province crashes with a db error "Data too long for column" if the State/Province has a long name (example: no crash with "Massachusetts", but crash with "District of Columbia"). The temporary table is created with a column size of varchar(16), presumably because the State/Province key is stored as a LONG; but the exported quantity is the value, which could be of arbitrary length (and certainly includes examples longer than 16 characters in normal usage).
This appears to be a similar issue to https://lab.civicrm.org/dev/core/issues/181 and https://lab.civicrm.org/dev/core/issues/877.5.17.0https://lab.civicrm.org/dev/core/-/issues/578Fatal db error in Activity Summary report for some Sorting fields (with ONLY_...2019-07-09T20:07:12ZdavejFatal db error in Activity Summary report for some Sorting fields (with ONLY_FULL_GROUP_BY)A fatal db error occurs in Activity Summary report for some Sorting fields. This occurs only with ONLY_FULL_GROUP_BY set in sql_mode.
Steps to replicate:
1. From the standard pre-defined Contact Reports, go to Activity Summary.
2. Le...A fatal db error occurs in Activity Summary report for some Sorting fields. This occurs only with ONLY_FULL_GROUP_BY set in sql_mode.
Steps to replicate:
1. From the standard pre-defined Contact Reports, go to Activity Summary.
2. Leave Columns as default, with Contact Name not checked.
3. Leave Grouping as default (Activity Type + Activity Status).
4. In Sorting, select Contact Name.
5. Click "Refresh results".
Expected result:
Report runs.
Actual result:
```
DB Error: unknown error
Database Error Code: Expression #1 of ORDER BY clause is not in GROUP BY clause and contains nonaggregated column 'dmasterciv_t1nir.contact_civireport.sort_name' which is not functionally dependent on columns in GROUP BY clause; this is incompatible with sql_mode=only_full_group_by, 1055
[debug_info] => INSERT INTO civicrm_activity_temp_a10856f163bac9e54ba4f5f5538d1cbf (civicrm_activity_duration_total)
SELECT SUM(activity_civireport.duration) as civicrm_activity_duration_total
FROM civicrm_activity activity_civireport
LEFT JOIN civicrm_activity_contact target_activity
ON activity_civireport.id = target_activity.activity_id AND
target_activity.record_type_id = 3
LEFT JOIN civicrm_contact contact_civireport
ON target_activity.contact_id = contact_civireport.id
WHERE
activity_civireport.is_test = 0 AND
activity_civireport.is_deleted = 0 AND
activity_civireport.is_current_revision = 1 GROUP BY activity_civireport.activity_type_id, activity_civireport.status_id ORDER BY contact_civireport.sort_name ASC LIMIT 0, 50 [nativecode=1055 ** Expression #1 of ORDER BY clause is not in GROUP BY clause and contains nonaggregated column 'dmasterciv_t1nir.contact_civireport.sort_name' which is not functionally dependent on columns in GROUP BY clause; this is incompatible with sql_mode=only_full_group_by]
```
The error also happens for various other combinations of Columns, Grouping & Sorting.
Occurs in current dmaster with MySQL 5.7.23, when ONLY_FULL_GROUP_BY set in sql_mode.5.17.0https://lab.civicrm.org/dev/core/-/issues/577Fatal db error in Activity Summary report when Sorting uses Section Header (w...2019-07-07T05:16:06ZdavejFatal db error in Activity Summary report when Sorting uses Section Header (without ONLY_FULL_GROUP_BY)A fatal db error occurs in Activity Summary report when sorting by a field that has not been selected in Columns, if Section Header is checked. This occurs with or without ONLY_FULL_GROUP_BY.
Steps to replicate:
1. From the standard p...A fatal db error occurs in Activity Summary report when sorting by a field that has not been selected in Columns, if Section Header is checked. This occurs with or without ONLY_FULL_GROUP_BY.
Steps to replicate:
1. From the standard pre-defined Contact Reports, go to Activity Summary.
2. Leave Columns as default, with Contact Name not checked.
3. Leave Grouping as default (Activity Type + Activity Status).
4. In Sorting, select Contact Name and check "Section Header / Group By".
5. Click "Refresh results".
Expected result:
Report runs.
Actual result:
```
DB Error: value count on row
Database Error Code: Column count doesn't match value count at row 1, 1136
[debug_info] => INSERT INTO civicrm_activity_temp_319632dc20cdeda8063b99ed6caaec62 ( civicrm_contact_id,civicrm_activity_activity_type_id,civicrm_activity_status_id,civicrm_activity_duration,civicrm_activity_id_count )
SELECT contact_civireport.id as civicrm_contact_id, activity_civireport.activity_type_id as civicrm_activity_activity_type_id, activity_civireport.status_id as civicrm_activity_status_id, activity_civireport.duration as civicrm_activity_duration, COUNT(DISTINCT(activity_civireport.id)) as civicrm_activity_id_count , contact_civireport.sort_name as civicrm_contact_sort_name
FROM civicrm_activity activity_civireport
LEFT JOIN civicrm_activity_contact target_activity
ON activity_civireport.id = target_activity.activity_id AND
target_activity.record_type_id = 3
LEFT JOIN civicrm_activity_contact assignment_activity
ON activity_civireport.id = assignment_activity.activity_id AND
assignment_activity.record_type_id = 1
LEFT JOIN civicrm_activity_contact source_activity
ON activity_civireport.id = source_activity.activity_id AND
source_activity.record_type_id = 2
LEFT JOIN civicrm_contact contact_civireport
ON target_activity.contact_id = contact_civireport.id
LEFT JOIN civicrm_contact civicrm_contact_assignee
ON assignment_activity.contact_id = civicrm_contact_assignee.id
LEFT JOIN civicrm_contact civicrm_contact_source
ON source_activity.contact_id = civicrm_contact_source.id
LEFT JOIN civicrm_option_value
ON ( activity_civireport.activity_type_id = civicrm_option_value.value )
LEFT JOIN civicrm_option_group
ON civicrm_option_group.id = civicrm_option_value.option_group_id
LEFT JOIN civicrm_case_activity
ON civicrm_case_activity.activity_id = activity_civireport.id
LEFT JOIN civicrm_case
ON civicrm_case_activity.case_id = civicrm_case.id
LEFT JOIN civicrm_case_contact
ON civicrm_case_contact.case_id = civicrm_case.id WHERE civicrm_option_group.name = "activity_type" AND
activity_civireport.is_test = 0 AND
activity_civireport.is_deleted = 0 AND
activity_civireport.is_current_revision = 1 GROUP BY activity_civireport.activity_type_id, activity_civireport.status_id ORDER BY contact_civireport.sort_name ASC LIMIT 0, 50 [nativecode=1136 ** Column count doesn't match value count at row 1]
```
Occurs in Civi 5.5.1 with MariaDB 10.1.34 or 10.1.37; also in current dmaster with MySQL 5.7.23 .
Note that dev/core/issues/428 reported an error in similar circumstances for the Activity Detail report but the error details are different and the error occurs at a different stage: here in INSERT INTO civicrm_activity_temp_XXX, there in a SELECT query.5.17.0https://lab.civicrm.org/dev/core/-/issues/439Contact Reference Field Cutoff on Export2019-08-04T18:55:16ZhershelContact Reference Field Cutoff on ExportOn a brand new Drupal 7 / CiviCRM 5.6.0 install I created a custom field group for Grants and added one Contact Reference field and then created 2 grants. When I search for grants and export and try to export that Contact Reference field...On a brand new Drupal 7 / CiviCRM 5.6.0 install I created a custom field group for Grants and added one Contact Reference field and then created 2 grants. When I search for grants and export and try to export that Contact Reference field, the name of the Contact is limited to 16 characters.
Further testing indicates that the name of a Contact Reference field on a Contact record also is limited to 16 characters when exported.
First reported here: https://civicrm.stackexchange.com/questions/26835/grant-export-custom-field-cutoff5.17.0https://lab.civicrm.org/dev/core/-/issues/285Scheduled Reminders for Membership not being sent2019-07-12T03:35:58ZMickCScheduled Reminders for Membership not being sentMembership reminders are not being sent - 2 probable causes found:
1. civicrm_action_log records for the same reminder 1 year ago
2. Status Override is checked
When either of the above conditions exist, the reminder is not sent.
Whe...Membership reminders are not being sent - 2 probable causes found:
1. civicrm_action_log records for the same reminder 1 year ago
2. Status Override is checked
When either of the above conditions exist, the reminder is not sent.
When neither of the above conditions exist, the reminder is sent.
When corrective action is taken to remove past civicrm_action_log records and remove any override, the reminder is sent.
Environment:
* CiviCRM 4.7.29
* Extension 'Transactional Email' is installed5.17.0https://lab.civicrm.org/dev/core/-/issues/5112Blank custom fields accordion appears on Find XXX search forms2024-03-28T04:43:32ZDaveDBlank custom fields accordion appears on Find XXX search formse.g. Find Activities, Find Cases. An accordion appears, but there's nothing in it. I don't think it ever used to appear. Started maybe in 5.72?e.g. Find Activities, Find Cases. An accordion appears, but there's nothing in it. I don't think it ever used to appear. Started maybe in 5.72?5.72.0https://lab.civicrm.org/dev/core/-/issues/5100Payment appears as 123 units of $1 rather than one unit of $123 if using othe...2024-03-22T14:38:36ZwmortadaPayment appears as 123 units of $1 rather than one unit of $123 if using other amount fieldOverview
----------------------------------------
This appears to be a regression in CiviCRM 5.69 upwards. If you create a contribution pages that allows other amounts the amount in that field is recorded in the quantity field of the li...Overview
----------------------------------------
This appears to be a regression in CiviCRM 5.69 upwards. If you create a contribution pages that allows other amounts the amount in that field is recorded in the quantity field of the line item rather than the unit price.
It looks like the quantity and the unit price have been swapped.
Reproduction steps
----------------------------------------
1. Create a contribution page with the other amounts section enabled
2. Visit the contribution page and type an amount in 'Other amount' field
3. View the contact record - note that the quantity is the amount and the unit price is 1.00
![image](/uploads/c16ed4be20e97bb2f86d63d5842d481e/image.png)
![image](/uploads/2e27e1f53dfca423a63ef4d98a5f0042/image.png)
![image](/uploads/85840162f1fc088ddcd6de5c7565ea5d/image.png)
Current behaviour
----------------------------------------
The amount is recorded in the quantity field. The unit price is $1.00.
Expected behaviour
----------------------------------------
The quantity is 1. The amount is recorded in the unit price field.
Environment information
----------------------------------------
Tested in CiviCRM 5.69, 5.70 and 5.73alpha1 (current dmaster). It is an issue in all three versions.
I'm not sure when this stopped working, but think it is quite recent.5.71.2https://lab.civicrm.org/dev/core/-/issues/5090Display of autocomplete multi-select custom fields for events is broken2024-03-18T23:14:49ZDetlev SieberDisplay of autocomplete multi-select custom fields for events is broken## Overview
For events, the display of autocomplete multi-select fields does not work anymore.
## Reproduction steps
1. Create a custom field for events:
1. Data Type Alphanumeric
2. Field Input Type: autocomplete
3. Multi-Se...## Overview
For events, the display of autocomplete multi-select fields does not work anymore.
## Reproduction steps
1. Create a custom field for events:
1. Data Type Alphanumeric
2. Field Input Type: autocomplete
3. Multi-Select: check
4. Add two options (e.g. "value1", "value2")
2. Edit an event, select "value1", Save.
3. Open the event again: the selected value(s) are not displayed (however, they are stored in the database).
## Current behaviour
Stored values of autocomplete multi-select fields for events are not displayed.
(This might create problems, because when you save, then the existing values are overwritten/nulled)
## Expected behaviour
Stored values of autocomplete multi-select fields for events should be displayed.
## Environment information
* This worked well with CiviCRM 5.64.4, but since some time it is broken.
* Tested here with 5.71.1
## Workaround
* Field input type can be changed to "checkbox(es)" - which however might be ugly and un-usable if there are many option.5.71.2https://lab.civicrm.org/dev/core/-/issues/5088message template "Events - Registration Confirmation and Receipt (on-line)" -...2024-03-14T18:53:32ZDetlev Siebermessage template "Events - Registration Confirmation and Receipt (on-line)" - transaction no. not displayed## Overview
In this message template, the transaction id is not displayed anymore.
Probably, this is due to a recent code refactoring: https://github.com/civicrm/civicrm-core/commit/0242bc9a3f44e9c4a800ba03f3a4e8887d5eceda
## Reproduc...## Overview
In this message template, the transaction id is not displayed anymore.
Probably, this is due to a recent code refactoring: https://github.com/civicrm/civicrm-core/commit/0242bc9a3f44e9c4a800ba03f3a4e8887d5eceda
## Reproduction steps
1. Register for an online event, using a payment processor
2. Look at the registration confirmation mail
## Current behaviour
Instead of the transaction id, "1" is displayed:
![grafik.png](/uploads/b660a14bf7f314fff73ef8600a4db5b3/grafik.png)
## Expected behaviour
![grafik.png](/uploads/08786dc3201bbe926c94dd5439ad2172/grafik.png)
## Environment information
## Comments
A fix is under way.5.71.2Detlev SieberDetlev Sieberhttps://lab.civicrm.org/dev/core/-/issues/5079(regression) Submission of non-numeric value on contribution form causes crash2024-03-28T03:51:54ZJonGold(regression) Submission of non-numeric value on contribution form causes crashOverview
----------------------------------------
Putting anything other than a strict numeric value in the "Other Amount" field of a price set results in a crash.
Reproduction steps
----------------------------------------
1. Use a pag...Overview
----------------------------------------
Putting anything other than a strict numeric value in the "Other Amount" field of a price set results in a crash.
Reproduction steps
----------------------------------------
1. Use a page with an "Other Amount" field (Quick Config or not, doesn't matter). This also affects all "Text / Numeric Quantity" price fields.
2. Enter a value that isn't strictly numeric. Like `$5` or `5 dollars`.
3. Submit the page.
Current behaviour
----------------------------------------
Division by zero error, crash.
Expected behaviour
----------------------------------------
Should fail validation with the message "Other Amount must be a number (with or without decimals).".
Comments
----------------------------------------
This is new in 5.70. I traced it to [PR #29275](https://github.com/civicrm/civicrm-core/pull/29275). Our first validation is now `$self->resetOrder($fields);`. The docblock there says we assume the input has been sanitized, but in the backtrace below, it must be happening pre-sanitization.
Backtrace:
```
#0 /var/www/mysite/vendor/civicrm/civicrm-core/CRM/Financial/BAO/Order.php(832): CRM_Financial_BAO_Order->calculateLineItems()
#1 /var/www/mysite/vendor/civicrm/civicrm-core/CRM/Contribute/Form/Contribution/Main.php(1983): CRM_Financial_BAO_Order->recalculateLineItems()
#2 /var/www/mysite/vendor/civicrm/civicrm-core/CRM/Contribute/Form/Contribution/Main.php(819): CRM_Contribute_Form_Contribution_Main->resetOrder(Array)
#3 /var/www/mysite/vendor/civicrm/civicrm-packages/HTML/QuickForm.php(1600): CRM_Contribute_Form_Contribution_Main::formRule(Array, Array, Object(CRM_Contribute_Form_Contribution_Main))
#4 /var/www/mysite/vendor/civicrm/civicrm-core/CRM/Core/Form.php(703): HTML_QuickForm->validate()
#5 /var/www/mysite/vendor/civicrm/civicrm-core/CRM/Core/QuickForm/Action/Upload.php(137): CRM_Core_Form->validate()
#6 /var/www/mysite/vendor/civicrm/civicrm-core/CRM/Core/QuickForm/Action/Upload.php(120): CRM_Core_QuickForm_Action_Upload->realPerform(Object(CRM_Contribute_Form_Contribution_Main), 'upload')
#7 /var/www/mysite/vendor/civicrm/civicrm-packages/HTML/QuickForm/Controller.php(203): CRM_Core_QuickForm_Action_Upload->perform(Object(CRM_Contribute_Form_Contribution_Main), 'upload')
#8 /var/www/mysite/vendor/civicrm/civicrm-packages/HTML/QuickForm/Page.php(103): HTML_QuickForm_Controller->handle(Object(CRM_Contribute_Form_Contribution_Main), 'upload')
#9 /var/www/mysite/vendor/civicrm/civicrm-core/CRM/Core/Controller.php(355): HTML_QuickForm_Page->handle('upload')
#10 /var/www/mysite/vendor/civicrm/civicrm-core/CRM/Core/Invoke.php(322): CRM_Core_Controller->run(Array, NULL)
#11 /var/www/mysite/vendor/civicrm/civicrm-core/CRM/Core/Invoke.php(69): CRM_Core_Invoke::runItem(Array)
#12 /var/www/mysite/vendor/civicrm/civicrm-core/CRM/Core/Invoke.php(36): CRM_Core_Invoke::_invoke(Array)
#13 /var/www/mysite/web/modules/contrib/civicrm/src/Civicrm.php(88): CRM_Core_Invoke::invoke(Array)
#14 /var/www/mysite/web/modules/contrib/civicrm/src/Controller/CivicrmController.php(83): Drupal\civicrm\Civicrm->invoke(Array)
#15 [internal function]: Drupal\civicrm\Controller\CivicrmController->main(Array, '')
#16 /var/www/mysite/web/core/lib/Drupal/Core/EventSubscriber/EarlyRenderingControllerWrapperSubscriber.php(123): call_user_func_array(Array, Array)
#17 /var/www/mysite/web/core/lib/Drupal/Core/Render/Renderer.php(627): Drupal\Core\EventSubscriber\EarlyRenderingControllerWrapperSubscriber->Drupal\Core\EventSubscriber\{closure}()
#18 /var/www/mysite/web/core/lib/Drupal/Core/EventSubscriber/EarlyRenderingControllerWrapperSubscriber.php(124): Drupal\Core\Render\Renderer->executeInRenderContext(Object(Drupal\Core\Render\RenderContext), Object(Closure))
#19 /var/www/mysite/web/core/lib/Drupal/Core/EventSubscriber/EarlyRenderingControllerWrapperSubscriber.php(97): Drupal\Core\EventSubscriber\EarlyRenderingControllerWrapperSubscriber->wrapControllerExecutionInRenderContext(Array, Array)
#20 /var/www/mysite/vendor/symfony/http-kernel/HttpKernel.php(181): Drupal\Core\EventSubscriber\EarlyRenderingControllerWrapperSubscriber->Drupal\Core\EventSubscriber\{closure}()
#21 /var/www/mysite/vendor/symfony/http-kernel/HttpKernel.php(76): Symfony\Component\HttpKernel\HttpKernel->handleRaw(Object(Symfony\Component\HttpFoundation\Request), 1)
#22 /var/www/mysite/web/core/lib/Drupal/Core/StackMiddleware/Session.php(58): Symfony\Component\HttpKernel\HttpKernel->handle(Object(Symfony\Component\HttpFoundation\Request), 1, true)
#23 /var/www/mysite/web/core/lib/Drupal/Core/StackMiddleware/KernelPreHandle.php(48): Drupal\Core\StackMiddleware\Session->handle(Object(Symfony\Component\HttpFoundation\Request), 1, true)
#24 /var/www/mysite/web/core/lib/Drupal/Core/StackMiddleware/ContentLength.php(28): Drupal\Core\StackMiddleware\KernelPreHandle->handle(Object(Symfony\Component\HttpFoundation\Request), 1, true)
#25 /var/www/mysite/web/core/modules/page_cache/src/StackMiddleware/PageCache.php(106): Drupal\Core\StackMiddleware\ContentLength->handle(Object(Symfony\Component\HttpFoundation\Request), 1, true)
#26 /var/www/mysite/web/core/modules/page_cache/src/StackMiddleware/PageCache.php(85): Drupal\page_cache\StackMiddleware\PageCache->pass(Object(Symfony\Component\HttpFoundation\Request), 1, true)
#27 /var/www/mysite/web/core/lib/Drupal/Core/StackMiddleware/ReverseProxyMiddleware.php(48): Drupal\page_cache\StackMiddleware\PageCache->handle(Object(Symfony\Component\HttpFoundation\Request), 1, true)
#28 /var/www/mysite/web/core/lib/Drupal/Core/StackMiddleware/NegotiationMiddleware.php(51): Drupal\Core\StackMiddleware\ReverseProxyMiddleware->handle(Object(Symfony\Component\HttpFoundation\Request), 1, true)
#29 /var/www/mysite/web/core/lib/Drupal/Core/StackMiddleware/AjaxPageState.php(36): Drupal\Core\StackMiddleware\NegotiationMiddleware->handle(Object(Symfony\Component\HttpFoundation\Request), 1, true)
#30 /var/www/mysite/web/core/lib/Drupal/Core/StackMiddleware/StackedHttpKernel.php(51): Drupal\Core\StackMiddleware\AjaxPageState->handle(Object(Symfony\Component\HttpFoundation\Request), 1, true)
#31 /var/www/mysite/web/core/lib/Drupal/Core/DrupalKernel.php(704): Drupal\Core\StackMiddleware\StackedHttpKernel->handle(Object(Symfony\Component\HttpFoundation\Request), 1, true)
#32 /var/www/mysite/web/index.php(19): Drupal\Core\DrupalKernel->handle(Object(Symfony\Component\HttpFoundation\Request))
#33 {main}
```5.71.2https://lab.civicrm.org/dev/core/-/issues/5071TypeError when trying to use checkboxes with default non-membership options i...2024-03-08T04:07:50ZFrancis (Agileware)TypeError when trying to use checkboxes with default non-membership options in the Membership section of Contribution PagesOverview
----------------------------------------
If you have a PriceSet with a checkboxes field, that has default options set that **don't** have a membership type associated with them, trying to use it on a Contribution Page causes th...Overview
----------------------------------------
If you have a PriceSet with a checkboxes field, that has default options set that **don't** have a membership type associated with them, trying to use it on a Contribution Page causes that page to crash.
Observed on PHP 8.0, may not be an issue on 7.4 -
Reproduction steps
----------------------------------------
1. Create a membership price set
2. Include in this price set a Checkboxes fields with a default option that does not select a membership type, e.g.
Membership Type
[ ] General - $100
[ ] Student - $50
Be awesome
[ X ] Donate $150 to save the Northern White Rhino
3. Use this price set in the membership context of a Contribution page
4. View the contribution page on the front-end
Current behaviour
----------------------------------------
Contribution page does not load, crashes with TypeError:
```
PHP Fatal error: Uncaught TypeError: strtolower(): Argument #1 ($string) must be of type string, array given in /.../public_html/ontarget/wp-content/plugins/civicrm/civicrm/CRM/Core/DAO.php:1419
```
Backtrace shows this is called from `CRM_Contribute_Form_Contribution_Main->setDefaultValues()`:
https://github.com/civicrm/civicrm-core/blob/4b75775/CRM/Contribute/Form/Contribution/Main.php#L270
(Ref 4b75775 is master at time of this report)
Expected behaviour
----------------------------------------
Contribution page should load, with defaults for all fields correctly applied
Environment information
----------------------------------------
* __CiviCRM:__ _Master, 5.70.2_
* __PHP:__ _8.0+_
Comments
----------------------------------------
I have a working patch for this, however I'm not sure the approach is entirely correct. The code in question appears to be trying to insinuate a Membership Type ID for, again an option (PriceFieldValue) which doesn't specify a membership type. Perhaps this line could... just be removed?5.72.0