Development issueshttps://lab.civicrm.org/groups/dev/-/issues2023-06-01T13:38:11Zhttps://lab.civicrm.org/dev/core/-/issues/4325Extra `<br>` tags inserted into rich text fields2023-06-01T13:38:11ZdtwExtra `<br>` tags inserted into rich text fieldsOverview
----------------------------------------
Extra `<br>` tags being inserted between HTML elements in rich-text fields, including between list items! And two being inserted between paragraphs. The html is clean in the editor, but t...Overview
----------------------------------------
Extra `<br>` tags being inserted between HTML elements in rich-text fields, including between list items! And two being inserted between paragraphs. The html is clean in the editor, but this is how it's being rendered on the front-end.
https://civicrm.stackexchange.com/questions/31535/br-tags-inserted-in-rich-text-fields-custom-fieldsets-when-displayed-as-tabs
Reproduction steps
----------------------------------------
"I added a custom field set to contacts, which I set to appear in a tab, then a 'note' type field and set it to be rich text. On a contact record, I added a couple of paragraphs (by hitting return between them) - looks good on the backend, but 2 x `<br>` tags between each `<p>` appearing on the front-end."
Current behaviour
----------------------------------------
Extra `<br>` tags are added
![CiviCRM_Screenshot_2023-05-31_152744](/uploads/7d62b59e050c00c5b9405a2268685eaf/CiviCRM_Screenshot_2023-05-31_152744.png)
![CiviCRM_Screenshot_2023-05-31_152938](/uploads/182e333899f70faa9405c5fe64e154e8/CiviCRM_Screenshot_2023-05-31_152938.png)
Maybe related to this change: https://issues.civicrm.org/jira/browse/CRM-11598
Expected behaviour
----------------------------------------
Extra `<br>` tags should not be added. Spacing should be handled with CSS.
Comments
----------------------------------------
_Anything else you would like the reviewer to note._5.63.0https://lab.civicrm.org/dev/core/-/issues/4323Date is incorrect when editing a contribution2023-11-09T19:36:12ZJDrueryDate is incorrect when editing a contributionWhen editing a contribution, Date Received is always set 05/30/2013 in the edit dialog. Under Payment Details, the date is correct (see first and second images below). When adding a new date in the Edit Contribution dialog, the popup cal...When editing a contribution, Date Received is always set 05/30/2013 in the edit dialog. Under Payment Details, the date is correct (see first and second images below). When adding a new date in the Edit Contribution dialog, the popup calendar always defaults to May of 2013. The year selector doesn't allow selecting anything after 2013 (third and fourth images).
A workaround is to change Date Preferences for activityDateTime. Changing the end offset from the default setting of 10 to 0 allows for dates up to the current year. I suspect this bug is caused by the end offset being interpreted as number of years before the current year, instead of number of years after the current year. Setting the end offset to -10 has the same effect as setting it to +10 (only dates 10 years before the current year are allowed).
![image](/uploads/68cdb261f247a35c092d34cab44e8f52/image.png)
![image](/uploads/501943aeba9f96ff61e9a0cd5c7449d5/image.png)
![image](/uploads/cba0d6b5a42f2b81ec28cd8e77890062/image.png)
![image](/uploads/d4d9340b4c377ef828a4a4cadf3a09ac/image.png)5.66.0https://lab.civicrm.org/dev/core/-/issues/4317Import contribution fails with custom fields2023-07-05T23:48:39ZPhilipp MichaelImport contribution fails with custom fieldsOverview
----------------------------------------
When importing contributions with field mappings to a custom field, the process fails after continuing from step 2 of 3.
Reproduction steps
----------------------------------------
1. Cl...Overview
----------------------------------------
When importing contributions with field mappings to a custom field, the process fails after continuing from step 2 of 3.
Reproduction steps
----------------------------------------
1. Click on **Contributions -> Import Contributions**.
1. Choose mandotory options and continue to step 2.
1. In "Matching CiviCRM Field" choose at least one custom field and try to continue to step 3
1. Got an error "**TypeError: CRM_Import_Parser::getFieldMetadata(): Return value must be of type array, null returned**".
Current behavior
----------------------------------------
Regardless of the provided CSV data, the process fails with:
```
TypeError: CRM_Import_Parser::getFieldMetadata(): Return value must be of type array, null returned in CRM_Import_Parser->getFieldMetadata() (line 1768 of /var/www/html/vendor/civicrm/civicrm-core/CRM/Import/Parser.php).
CRM_Import_Parser->getFieldMetadata('Zu_belastendes_Konto.nur_anstehende_Zuwendungen._IBAN') (Line: 165)
CRM_Contribute_Import_Parser_Contribution->getMappedRow(Array) (Line: 221)
CRM_Contribute_Import_Parser_Contribution->validateValues(Array) (Line: 2551)
CRM_Import_Parser->validateRow(Array) (Line: 1842)
CRM_Import_Parser->validate() (Line: 90)
CRM_Import_Form_MapField->postProcess() (Line: 612)
CRM_Core_Form->mainProcess() (Line: 144)
CRM_Core_StateMachine->perform(Object, 'next', 'Next') (Line: 43)
CRM_Core_QuickForm_Action_Next->perform(Object, 'next') (Line: 203)
HTML_QuickForm_Controller->handle(Object, 'next') (Line: 103)
HTML_QuickForm_Page->handle('next') (Line: 355)
CRM_Core_Controller->run(Array, NULL) (Line: 319)
CRM_Core_Invoke::runItem(Array) (Line: 69)
CRM_Core_Invoke::_invoke(Array) (Line: 36)
CRM_Core_Invoke::invoke(Array) (Line: 88)
Drupal\civicrm\Civicrm->invoke(Array) (Line: 83)
Drupal\civicrm\Controller\CivicrmController->main(Array, '')
call_user_func_array(Array, Array) (Line: 123)
Drupal\Core\EventSubscriber\EarlyRenderingControllerWrapperSubscriber->Drupal\Core\EventSubscriber\{closure}() (Line: 580)
Drupal\Core\Render\Renderer->executeInRenderContext(Object, Object) (Line: 124)
Drupal\Core\EventSubscriber\EarlyRenderingControllerWrapperSubscriber->wrapControllerExecutionInRenderContext(Array, Array) (Line: 97)
Drupal\Core\EventSubscriber\EarlyRenderingControllerWrapperSubscriber->Drupal\Core\EventSubscriber\{closure}() (Line: 169)
Symfony\Component\HttpKernel\HttpKernel->handleRaw(Object, 1) (Line: 81)
Symfony\Component\HttpKernel\HttpKernel->handle(Object, 1, 1) (Line: 58)
Drupal\Core\StackMiddleware\Session->handle(Object, 1, 1) (Line: 48)
Drupal\Core\StackMiddleware\KernelPreHandle->handle(Object, 1, 1) (Line: 106)
Drupal\page_cache\StackMiddleware\PageCache->pass(Object, 1, 1) (Line: 85)
Drupal\page_cache\StackMiddleware\PageCache->handle(Object, 1, 1) (Line: 48)
Drupal\Core\StackMiddleware\ReverseProxyMiddleware->handle(Object, 1, 1) (Line: 51)
Drupal\Core\StackMiddleware\NegotiationMiddleware->handle(Object, 1, 1) (Line: 23)
Stack\StackedHttpKernel->handle(Object, 1, 1) (Line: 718)
Drupal\Core\DrupalKernel->handle(Object) (Line: 19)
```
Environment information
----------------------------------------
* __CiviCRM:__ _Master/5.60/5.62/5.64_
* __PHP:__ _8.0_
* __CMS:__ _Drupal 9.5.9_
* __Database:__ _MariaDB 10.4.28_
Comments
----------------------------------------
I've tested latest versions and can reproduce it in 5.60 and later. It was probably caused with changes in [Update Contribution Import to use apiv4 field names, prior to adding hooks](https://github.com/civicrm/civicrm-core/pull/25886). The way of getting custom fields available for import has changed, which leads to different field keys respectively option values. Previously you got the short version "custom_xy", now you get a long database field name like one.
5.59:
![mapping-custom-fields-options-5.59](/uploads/e4f4adc83357fd0c3e7613b6f92d5bb2/mapping-custom-fields-options-5.59.png)
5.60 (and 5.62, 5.64):
![mapping-custom-fields-options-5.62](/uploads/d0f7573c8f279bc53c794949d3183ea9/mapping-custom-fields-options-5.62.png)
The import parser can't find related field meta data regarding to those keys.
I'm not sure, if those key names provided by the API are intended and therefor can't provide a PR.5.63.0https://lab.civicrm.org/dev/core/-/issues/4310Membership HTML output on contribution pages causing layout errors due to unc...2023-05-24T07:36:13ZFrancis (Agileware)Membership HTML output on contribution pages causing layout errors due to unclosed div - 5.61 regressionOverview
----------------------------------------
[commit:dfc5fb9](https://github.com/civicrm/civicrm-core/commit/dfc5fb948b0cb11947b3b75131b54b1c365f08b1) caused a regression in the display of the Membership block, where the logic wrapp...Overview
----------------------------------------
[commit:dfc5fb9](https://github.com/civicrm/civicrm-core/commit/dfc5fb948b0cb11947b3b75131b54b1c365f08b1) caused a regression in the display of the Membership block, where the logic wrapping the "makeContribution" context skips both the closing div and the javascript portion that replaces the auto renew checkbox with a note in force autorenewal mode.
Reproduction steps
----------------------------------------
1. Create a membership contribution page.
2. Attempt to use the contribution page.
Current behaviour
----------------------------------------
The membership block escapes its containment matrix, causing an unclosed div error on the form. This manifests in the browser as a layout nesting issue.
The [W3 validator](https://validator.w3.org/nu/) explains the problem as:
```
Error: End tag form seen, but there were open elements.
From line 1779, column 3; to line 1779, column 9
>↩ ↩ ↩ </form>↩
Error: Unclosed element div.
From line 692, column 3; to line 692, column 128
↩ ↩ <div class="crm-contribution-page-id-7 crm-block crm-contribution-main-form-block" data-page-id="7" data-page-template="main">↩↩
Fatal Error: Cannot recover after last error. Any further errors will be ignored.
From line 1779, column 3; to line 1779, column 9
>↩ ↩ ↩ </form>↩
```
In addition to this, if the membership type should force autorenewal, it may not due to a missing javascript section.
Expected behaviour
----------------------------------------
There should be no layout nesting issue, and all divs should be closed appropriately.
The script to advise the end use on autorenewal should function.
Environment information
----------------------------------------
* __CiviCRM:__ _Master, 5.61.x_
* __PHP:__ 8.0
* __CMS:__ WordPress 6.2.25.61.4https://lab.civicrm.org/dev/core/-/issues/4305Implementing hook_civicrm_alterAngular breaks href attributes that include so...2023-05-24T10:43:11ZDaveDImplementing hook_civicrm_alterAngular breaks href attributes that include some angular expressionsSee also https://chat.civicrm.org/civicrm/pl/xqbryepb4fra5f6smn8uazbeoc
searchkit has a line like this in the code: `<a href="#/create/{{:: row.data.api_entity + '?params=' + $ctrl.encode(row.data.api_params) }}">`
If you implement alt...See also https://chat.civicrm.org/civicrm/pl/xqbryepb4fra5f6smn8uazbeoc
searchkit has a line like this in the code: `<a href="#/create/{{:: row.data.api_entity + '?params=' + $ctrl.encode(row.data.api_params) }}">`
If you implement alterAngular, even if you don't change anything, it breaks that code because the `+`'s become spaces. e.g.
```php
function myextension_civicrm_alterAngular(\Civi\Angular\Manager $angular) {
$changeSet = \Civi\Angular\ChangeSet::create('dosomething')
->alterHtml('~/crmSearchAdmin/searchListing/buttons.html',
function (phpQueryObject $doc) {
// it breaks even if you don't do anything here
});
$angular->add($changeSet);
```
The problem seems to be in DOMDocument itself (or maybe libxml). It treats href specially, but is picky about which characters it encodes. It will encode `{`, `[`, `&`, `$`, etc but not `+`, `.`, `=`, etc, and amazingly not even `%`. So then when you urldecode it turns the `+` into a space, and if you had something like `%12` in your original string, it would end up decoding that into a single char. It serves you right a bit for using those chars in a filename/url, but it's legal.
This seems inconsistent/error-prone.
And note it only does this for href attributes, e.g.
```php
<?php
$d = new DOMDocument();
$d->loadHTML('<a href="abc/!@#$%12*-.+(){}[]=" data-foo="abc/!@#$%12*-.+(){}[]=">');
echo $d->saveHTML();
```
gives
```
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN" "http://www.w3.org/TR/REC-html40/loose.dtd">
<html><body><a href="abc/!@#%24%12*-.+()%7B%7D%5B%5D=" data-foo="abc/!@#$%12*-.+(){}[]="></a></body></html>
```
So while Civi\Angular\Coder could maybe be updated somehow, there isn't really a way for it to know if you meant something like `%2C` to be a literal percent followed by 2C, or if you meant `,`, and ditto for all the other characters it skips. So using ng-href instead seems like a good way of avoiding the problem, just as noted in the chat it's hard to enforce this. But core could do it at least.5.63.0https://lab.civicrm.org/dev/core/-/issues/4303Custom field post help results in "Unable to load help file."2023-05-23T22:58:09Zwil_SRQCustom field post help results in "Unable to load help file."Overview
----------------------------------------
See https://civicrm.stackexchange.com/questions/44976/custom-field-post-help-results-in-unable-to-load-help-file/44978#44978
Clicking the blue help bubble for a custom field yields the e...Overview
----------------------------------------
See https://civicrm.stackexchange.com/questions/44976/custom-field-post-help-results-in-unable-to-load-help-file/44978#44978
Clicking the blue help bubble for a custom field yields the error message "Unable to load help file." The log records an exception, [attached.](/uploads/8a35ccf2e69e50a8104f8ae8e755f715/log1.txt) Non-custom fields are working normally.
Reproduction steps
----------------------------------------
1. Locate or create a custom field with field post help text
1. Go to a Create or Edit page that allows filling the custom field
1. Click the blue help bubble
Current behaviour
----------------------------------------
Described in the overview.
Expected behaviour
----------------------------------------
The field post help text displays in a pop-up at the top right of the page.
Environment information
----------------------------------------
* __CiviCRM:__ _5.61.1_
* __PHP:__ _7.4.33_
* __CMS:__ _Drupal 7.97_
* __Database:__ _MySQL 5.7.42_
*
Comments
----------------------------------------
This error is new (regression), but I don't know when it emerged. [Lars](https://civicrm.stackexchange.com/users/3533/lars-sg) confirmed correct operation on 5.58.1 and the problem on dmaster.5.61.3https://lab.civicrm.org/dev/core/-/issues/4298CiviMail - throw 400 (Bad Request) rather than 500 (Server Error) if public u...2023-07-27T17:17:06ZufundoCiviMail - throw 400 (Bad Request) rather than 500 (Server Error) if public url endpoints hit with bad parametersOverview
----------------------------------------
Urls for CiviMail public endpoints like `civicrm/mailing/open` have a few required parameters, identifying the user / url etc. How should we handle if params aren't valid?
Current behavi...Overview
----------------------------------------
Urls for CiviMail public endpoints like `civicrm/mailing/open` have a few required parameters, identifying the user / url etc. How should we handle if params aren't valid?
Current behaviour
----------------------------------------
Current standard behaviour Civi-wide for missing/invalid params is a `CRM_Core_Exception`, which in turn results in a 500 server error.
Proposed behaviour
----------------------------------------
I think a 400 Bad Request error is more appropriate, for the "public" CiviMail links in particular.
Comments
----------------------------------------
It also helps with detecting and blocking spammy click behaviour, which I've seen with random permutations of parameters and things like this.5.65.0https://lab.civicrm.org/dev/core/-/issues/4282Membership for regression in 5.612023-06-10T01:11:59ZeileenMembership for regression in 5.61Refer https://lab.civicrm.org/dev/core/-/issues/4272#note_90443 and
https://github.com/civicrm/civicrm-core/pull/26170Refer https://lab.civicrm.org/dev/core/-/issues/4272#note_90443 and
https://github.com/civicrm/civicrm-core/pull/261705.61.2https://lab.civicrm.org/dev/core/-/issues/4281`{help}` tags that don't specify the `file` parameter no longer work on windows2023-05-19T14:00:48ZDaveD`{help}` tags that don't specify the `file` parameter no longer work on windowsSeems to have broke in 5.57 with https://github.com/civicrm/civicrm-core/commit/d80e8fa62cad6661a0882753a8babf5512f9bb12. Now it just throws an error.
An example is on the activity form if you click the help bubble for assignee.
I see ...Seems to have broke in 5.57 with https://github.com/civicrm/civicrm-core/commit/d80e8fa62cad6661a0882753a8babf5512f9bb12. Now it just throws an error.
An example is on the activity form if you click the help bubble for assignee.
I see - it's because on windows it doesn't match the regex because it has `\` instead.5.63.0https://lab.civicrm.org/dev/core/-/issues/4278Import "fill" doesn't respect location type for email/phone2023-05-04T22:10:09ZJonGoldImport "fill" doesn't respect location type for email/phoneOverview
----------------------------------------
If you use the "Fill" strategy for duplicate records in Contact Import, phone and email will be skipped if *any* phone/email exists, regardless of location type. Addresses import correct...Overview
----------------------------------------
If you use the "Fill" strategy for duplicate records in Contact Import, phone and email will be skipped if *any* phone/email exists, regardless of location type. Addresses import correctly.
Reproduction steps
----------------------------------------
1. Create a contact with a Home phone number.
1. Create a CSV with two columns - that contact's ID, and a Work phone number.
1. Import with the "Fill" strategy for duplicate records, matching on contact ID.
Current behaviour
----------------------------------------
Work phone number isn't imported.
Expected behaviour
----------------------------------------
Work phone number is imported.
Comments
----------------------------------------
Similar to https://lab.civicrm.org/dev/core/-/issues/4269 but amazingly is not a regression. This was fixed years ago for addresses, but not phones/email.5.63.0JonGoldJonGoldhttps://lab.civicrm.org/dev/core/-/issues/4272Unreleased regression: Membership selction fails validation2023-06-10T01:11:59ZbrienneUnreleased regression: Membership selction fails validationOverview
----------------------------------------
A Contribution page that includes a Membership selection is failing validation with a message indicating a Membership has not been selected, even when a selection has been made.
Reproduc...Overview
----------------------------------------
A Contribution page that includes a Membership selection is failing validation with a message indicating a Membership has not been selected, even when a selection has been made.
Reproduction steps
----------------------------------------
1. Create a Membership Price Set (**Memberships > Manage Price Sets > Add Set of Price Fields**). Use a *Select* or a *Radio Button* for the *Field Type*.
1. Create a Contribution Page. On the *Memberships Tab*, select the *Price Set* made in the previous step.
1. After saving, click **Contribution Links > Test-drive**
2. Select a membership, fill out the rest of the form, click **Contribute**.
3. Instead of making the contribution, a validation error is displayed at the top of the Contribution page.
Current behaviour
----------------------------------------
On a Contribution page with a Membership selection, even if a Membership is chosen, the submission is not successful, and the user receives the following message:
```
Please correct the following errors in the form fields below:
Please select one of the memberships.
```
![Selection_077](/uploads/aa0c7792cec6eebdaeda6064cfea703c/Selection_077.png)
Expected behaviour
----------------------------------------
If a Membership is selected on the Contribution page, it should be recognized as such and pass the validation.
----------------------------------------
* __CiviCRM:__ _Master (5.61aplpha1)
Comments
----------------------------------------
I used `git bisect`, and the issue seems to have been introduced by PR 25754 [Extract isMembershipPriceSet (useForMember)](https://github.com/civicrm/civicrm-core/pull/25754). The exact commit id is `e4992726cc41cbef54aead6dd28d010c1640419f`5.61.0https://lab.civicrm.org/dev/core/-/issues/4269Import "Fill" option doesn't work on email/phone fields2023-05-04T20:14:52ZJonGoldImport "Fill" option doesn't work on email/phone fieldsOverview
----------------------------------------
If you use the "Fill" strategy for duplicate records in Contact Import, it only sometimes fills email/phone numbers.
Reproduction steps
----------------------------------------
1. Create...Overview
----------------------------------------
If you use the "Fill" strategy for duplicate records in Contact Import, it only sometimes fills email/phone numbers.
Reproduction steps
----------------------------------------
1. Create a SearchKit query on demo data for individuals where Primary Email is empty and Primary Phone is empty.
1. Export their contact IDs.
1. Open the CSV, and a phone and email field. Populate the values.
1. Import with the "Fill" strategy for duplicate records, matching on contact ID
Current behaviour
----------------------------------------
Of 16 contacts, 4 were filled. The other 12 were not.
I left the email blank on one record. I received an import error for that record.
Expected behaviour
----------------------------------------
All contacts should get the phone and email filled. Leaving a non-match field blank should not result in an import error.
Comments
----------------------------------------
This is certainly a regression but I can't tell you exactly when.5.61.0JonGoldJonGoldhttps://lab.civicrm.org/dev/core/-/issues/4262Auto detect line endings Deprecated2023-05-02T21:57:19ZTony Maynard-SmithAuto detect line endings DeprecatedThe civicrm.settings.php file, about line 581, tries to set the PHP ini function auto_detect_line_endings, which is now Deprecated (in PHP 8.1) and no longer required.
Remove this from the settings file.
(This is on my v5.60.0 system...The civicrm.settings.php file, about line 581, tries to set the PHP ini function auto_detect_line_endings, which is now Deprecated (in PHP 8.1) and no longer required.
Remove this from the settings file.
(This is on my v5.60.0 system, but this has been upgraded from earlier versions. Even if fixed in new installs, an upgrade should now fix it.)5.62.0https://lab.civicrm.org/dev/drupal/-/issues/186drupal 9: Create User Record action crashes if using first+last+email as unsu...2023-07-05T23:49:05ZDaveDdrupal 9: Create User Record action crashes if using first+last+email as unsupervised ruleSee https://civicrm.stackexchange.com/questions/44841/create-user-record-action-on-a-contact-summary-page-throws-error-is-this-a-bug
Putting as regression for now but not completely sure.
Doesn't happen in drupal 7.See https://civicrm.stackexchange.com/questions/44841/create-user-record-action-on-a-contact-summary-page-throws-error-is-this-a-bug
Putting as regression for now but not completely sure.
Doesn't happen in drupal 7.5.63.0https://lab.civicrm.org/dev/core/-/issues/4248Clicking View and Edit Price Fields for a Price Set no longer tells you which...2023-06-10T21:48:41ZDaveDClicking View and Edit Price Fields for a Price Set no longer tells you which pages/events it's being used inIt used to have a little table at the top telling you which contribution pages or events the price set is used in.
It works in 5.49.4, not working in 5.58 or on dmaster.demo (5.62). But I'm not sure when it broke.
It looks like the cod...It used to have a little table at the top telling you which contribution pages or events the price set is used in.
It works in 5.49.4, not working in 5.58 or on dmaster.demo (5.62). But I'm not sure when it broke.
It looks like the code that includes the table is still there, so probably a change somewhere else to those variables? https://github.com/civicrm/civicrm-core/blob/3a2072cdea58b674bd51e3f1f871b410980e8940/templates/CRM/Price/Page/Set.tpl#L29-L315.62.0https://lab.civicrm.org/dev/core/-/issues/4247Fatal error on membership batch data entry with sending receipt2023-04-20T21:33:19ZandreiyFatal error on membership batch data entry with sending receiptOverview
----------------------------------------
When trying to submit membership in batch having Send Receipt checkbox enabled, civi will throw a fatal error due to a bug in code.
Reproduction steps
----------------------------------...Overview
----------------------------------------
When trying to submit membership in batch having Send Receipt checkbox enabled, civi will throw a fatal error due to a bug in code.
Reproduction steps
----------------------------------------
From Membership -> Batch Data Entry -> Select Type: Membership -> Save -> Check "Send Receipt" -> Validate & Process the Batch -> Ignore Mismatch & Process the Batch?
Current behaviour
----------------------------------------
On submit will throw this fatal error:
```
Fatal error: Uncaught TypeError: Argument 1 passed to CRM_Utils_Date::formatDateOnlyLong() must be of the type string, null given, called in wp-civi560/web/wp-content/plugins/civicrm/civicrm/CRM/Batch/Form/Entry.php on line 949 and defined in wp-civi560/web/wp-content/plugins/civicrm/civicrm/CRM/Utils/Date.php on line 472
TypeError: Argument 1 passed to CRM_Utils_Date::formatDateOnlyLong() must be of the type string, null given, called in wp-civi560/web/wp-content/plugins/civicrm/civicrm/CRM/Batch/Form/Entry.php on line 949 in wp-civi560/web/wp-content/plugins/civicrm/civicrm/CRM/Utils/Date.php on line 472
```
Expected behaviour
----------------------------------------
It should process the memberships without throwing error.
Environment information
----------------------------------------
Tested on a clean civibuild instance with latest CiviCRM and WP.
* __Browser:__ _Arc 0.98.2_
* __CiviCRM:__ _5.60_
* __PHP:__ _7.4.27_
* __CMS:__ _WordPress 6.2_
* __Database:__ _MySQL 5.7.36_
* __Web Server:__ _Apache 2.4.53_
Comments
----------------------------------------
The issue seems to be [this line](https://github.com/civicrm/civicrm-core/blob/5.60/CRM/Batch/Form/Entry.php#L930), it attempts to fetch before find, which lead to empty `$membership` object. Replacing it with `$membership->find(TRUE)` fixes the problem.5.61.0https://lab.civicrm.org/dev/core/-/issues/4242Formbuilder: Labels of filters double-escape html2023-04-17T17:10:58ZDaveDFormbuilder: Labels of filters double-escape html1. Create a search formbuilder.
2. Add a filter to the form.
3. Change the label to `Foo & Bar`
4. Note that the form displays it as `Foo &amp; Bar`
5. Go back to edit the form and it is escaped there too.1. Create a search formbuilder.
2. Add a filter to the form.
3. Change the label to `Foo & Bar`
4. Note that the form displays it as `Foo & Bar`
5. Go back to edit the form and it is escaped there too.5.62.0https://lab.civicrm.org/dev/core/-/issues/4240Cannot set Entityref fields via APIv4 Explorer - on multi-value data2023-06-08T18:04:44ZAndrew WestCannot set Entityref fields via APIv4 Explorer - on multi-value dataOverview
----------------------------------------
Adding EntityRef data in APIv4 explorer fails on multi-value data, because validation in CRM_Utils_Type doesn't support EntityRef.
Reproduction steps
-----------------------------------...Overview
----------------------------------------
Adding EntityRef data in APIv4 explorer fails on multi-value data, because validation in CRM_Utils_Type doesn't support EntityRef.
Reproduction steps
----------------------------------------
1. Create a multi-value data set for all Individuals
2. Add an EntityRef field linked to Activities
3. Try to set it via the APIv4 Explorer
As of this second this is failing on the WP Demo site:
https://wpmaster.demo.civicrm.org/wp-admin/admin.php?page=CiviCRM&q=civicrm%2Fapi4#/explorer/Custom_Test_Multi/create?values=%5B%5B%22entity_id%22,%2256%22%5D,%5B%22Test_EntityRef_on_Multi%22,%22459%22%5D%5D
![image](/uploads/ae4edfeeabbdbf601725271349774929/image.png)
Current behaviour
----------------------------------------
There's one error in CRM_Utils_Type::escape() and two in CRM_Utils_Type::validate()
**CRM_Utils_Type::escape**
Just needs EntityReference added to the switch statement (I think)
**CRM_Utils_Type::validate**
Needs EntityReference added to $possibleTypes (I think)
Needs a case added for EntityReference. This works as a temporary workaround:
```
case 'EntityReference':
// null is valid
if (strlen(trim($data)) == 0) {
return trim($data);
}
return (int) $data;
```
But presumably it needs some kind of validation like happens in ContactReference:
```
case 'ContactReference':
// null is valid
if (strlen(trim($data)) == 0) {
return trim($data);
}
if (CRM_Utils_Rule::validContact($data)) {
return (int) $data;
}
break;
```
Environment information
----------------------------------------
Replicated on 5.60 and 5.62alpha15.61.0https://lab.civicrm.org/dev/core/-/issues/4227Contact import (new) deletes contact fields2023-07-11T16:34:41ZBjörn EndresContact import (new) deletes contact fieldsOverview
----------------------------------------
It seems like the "new importer" that has been implemented with [5.51](https://lab.civicrm.org/groups/dev/-/issues/?sort=updated_desc&state=closed&milestone_title=5.51.0&label_name%5B%5D=...Overview
----------------------------------------
It seems like the "new importer" that has been implemented with [5.51](https://lab.civicrm.org/groups/dev/-/issues/?sort=updated_desc&state=closed&milestone_title=5.51.0&label_name%5B%5D=comp%3AImport&first_page_size=100) has slightly changed its behaviour: if you import/update contacts with empty fields these fields will be deleted, where they used to be ignored (pre 5.51).
Reproduction steps
----------------------------------------
1. Import test contact using the "Import Contacts" menu item with [this file](/uploads/5c56a58c83b7a1fcd5f69ddab02a5c23/ISSUE-4227_step1.csv) and check whether the contact was created.
2. Update the contact by using the import again with [this file](/uploads/62ef3aa3a3c6b975d2dbfa7d060248fc/ISSUE-4227_step2.csv), setting the "For Duplicate Contacts" setting to "Update"
3. Observe, that the birthday field in the new contact was deleted.
Current behaviour
----------------------------------------
Currently, the contact's birthday field is deleted.
Expected behaviour
----------------------------------------
Contact's birthday field should be left untouched, as was the behaviour pre ``5.51.0`` (tested with ``5.40.2``).
Environment information
----------------------------------------
Reproduced on ``dmaster``.
----------------------------------------
This might be an intentional change in behaviour, but I haven't found any documentation on this.5.62.0https://lab.civicrm.org/dev/core/-/issues/4217Can no longer search by case id in file-on-case2023-04-02T22:11:40ZDaveDCan no longer search by case id in file-on-casehttps://civicrm.stackexchange.com/questions/44732/file-on-case-no-longer-works-by-case-id
It works in 5.56, not in 5.57+.
Candidates:
* github.com/civicrm/civicrm-core/pull/24976
* github.com/civicrm/civicrm-core/pull/24974https://civicrm.stackexchange.com/questions/44732/file-on-case-no-longer-works-by-case-id
It works in 5.56, not in 5.57+.
Candidates:
* github.com/civicrm/civicrm-core/pull/24976
* github.com/civicrm/civicrm-core/pull/249745.60.0