Development issueshttps://lab.civicrm.org/groups/dev/-/issues2023-05-23T00:11:48Zhttps://lab.civicrm.org/dev/core/-/issues/4306New SMS screen crashes due to extra space in {htxt id ="id-sms_..."} in Group...2023-05-23T00:11:48ZjhungerfordNew SMS screen crashes due to extra space in {htxt id ="id-sms_..."} in Group.hlpOverview
----------------------------------------
After updating from Civi 5.57.x to 5.61.2, pressing "New SMS" or navigating to /civicrm/sms/send?reset=1 results in this error message:
```
Sorry, due to an error, we are unable to fulfi...Overview
----------------------------------------
After updating from Civi 5.57.x to 5.61.2, pressing "New SMS" or navigating to /civicrm/sms/send?reset=1 results in this error message:
```
Sorry, due to an error, we are unable to fulfill your request at the moment. You may want to contact your administrator or service provider with more details about what action you were performing when this occurred.
Invalid {htxt} tag. Wrapped 10 opening-tags and 12 closing-tags.
```
Reproduction steps
----------------------------------------
1. Navigate to /civicrm/sms/send?reset=1
Current behaviour
----------------------------------------
Some of the page content is present, but most of it is replaced with the error message mentioned above.
Expected behaviour
----------------------------------------
It should have a form for selecting the SMS provider, as well as "Next" and "Cancel" buttons.
Environment information
----------------------------------------
* __CiviCRM:__ 5.61.2
Comments
----------------------------------------
The bug is caused by the extra spaces in the last two {htxt} tags in this file:
https://lab.civicrm.org/dev/core/-/blob/master/templates/CRM/SMS/Form/Group.hlp#L50-53
This regex doesn't match the extra space, so it throws an exception when the count of `{htxt}`s doesn't match the count of `{/htxt}`s:
https://lab.civicrm.org/dev/core/-/blob/master/CRM/Core/Smarty/plugins/prefilter.htxtFilter.php#L21
Removing the extra spaces fixes the page:
`{htxt id="id-sms_provider-title"}`
and
`{htxt id="id-sms_provider"}`https://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/wordpress/-/issues/141getUFLocale() is not setting the proper locale2023-05-19T18:47:06ZshaneonabikegetUFLocale() is not setting the proper locale## Overview
Presently, the function ```getUFLocale()``` obtains the interface language for Wordpress with integration with WPML. The present formula is using incorrect ```apply_filters``` to generate the wrong locale for front-endusers....## Overview
Presently, the function ```getUFLocale()``` obtains the interface language for Wordpress with integration with WPML. The present formula is using incorrect ```apply_filters``` to generate the wrong locale for front-endusers.
This was discovered while working validating the pull request [#289](https://github.com/civicrm/civicrm-wordpress/pull/289) for better WPML integration for front-end users.
## What should happen
The link should be generated in the language that the current user has set.
## What is the problem
```php
// Maybe override with the locale that WPML reports.
elseif (defined('ICL_LANGUAGE_CODE')) {
$languages = apply_filters('wpml_active_languages', NULL);
foreach ($languages as $language) {
if ($language['active']) {
$locale = $language['default_locale'];
break;
}
}
}
```
According to the docs, ```apply_filters('wpml_active_languages', NULL)``` only retrieves a list of languages, but this has no bearing on the user's current language. The value ```$language['active']``` refers to whether the language is active or not. In my case, I have seen this reported as _false_ in some cases where languages are active - go figure :shrug: .
So we need to use ```apply_filters('wpml_current_language')``` [to obtain](https://wpml.org/wpml-hook/wpml_current_language/) the users front-end language.
I'll post a patch for this and link it to this one.
cc @kcristianohttps://lab.civicrm.org/dev/wordpress/-/issues/140Event registration confirmation page no longer shown. Error: Could not find v...2023-12-07T09:30:02Zdarren.woodsEvent registration confirmation page no longer shown. Error: Could not find valid value for id.WordPress 6.2, Civi ESR 5.57.5.
The confirmation page after event registration is no longer shown (for both Test and Live links). Instead, the attached error is shown:-
![image](/uploads/602b80ebba49507af86158d362c9b164/image.png)
The ...WordPress 6.2, Civi ESR 5.57.5.
The confirmation page after event registration is no longer shown (for both Test and Live links). Instead, the attached error is shown:-
![image](/uploads/602b80ebba49507af86158d362c9b164/image.png)
The workaround is to embed the event registration page as a shortcode. However the confirmation page and confirmation emails show a link to the event info page, which then has the "Register" button taking people to the wrong page.
I'm wondering if this can be fixed, or if we need to override the confirmation and event info pages somehow to redirect users to the WordPress page (perhaps using a naming convention).
Thanks!https://lab.civicrm.org/dev/core/-/issues/4300FormBuilder: Client-side email validation doesn't work2023-07-07T03:55:58ZkcristianoFormBuilder: Client-side email validation doesn't workThis is a follow up issue to https://lab.civicrm.org/dev/core/-/issues/4173 and relayed to https://lab.civicrm.org/dev/core/-/issues/4174#note_90537
Steps to Reproduce:
- Build WP site with latest CiviCRM - Cureently using WP 6.2.1 and...This is a follow up issue to https://lab.civicrm.org/dev/core/-/issues/4173 and relayed to https://lab.civicrm.org/dev/core/-/issues/4174#note_90537
Steps to Reproduce:
- Build WP site with latest CiviCRM - Cureently using WP 6.2.1 and CiviCRM 5.61.2
- Create a submission form with the following Fields - all required
- First Name
- Last Name
- Email
- Phone
Compete the form, but for email use `meatme` as the email address.
- expected behavior - fails validation
- Actual behavior form submits
Email validation not working client side or server side. I have confirmed this on WP and Drupal 7.
~~Possibly related - on phone or address - add a second item (second phone in my testing). Do not choose a location type. Form submits, but the record does not update CiviCRM. This behavior only exists on WP, I cannot reproduce on Drupal. I can break this out as another issue if needed. But adding here as I see this as validation failing.~~
EDIT: The location issue is fixed in WP with the master branch.
ping @eileen @colemanw @shaneonabike @JonGold As we all commented on original issue notifying and asking for feedback and comments on a possible way to fix.https://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/4295SearchKit - non-core legacy search tasks don't work with contributions2023-05-24T07:05:24ZufundoSearchKit - non-core legacy search tasks don't work with contributionsReproduction steps
----------------------------------------
1. Create a SearchKit with contribution entities
1. Enable an extension with a legacy search task (e.g. https://lab.civicrm.org/ufundo/ukgiftaid/-/tree/searchkit-actions )
1. Ta...Reproduction steps
----------------------------------------
1. Create a SearchKit with contribution entities
1. Enable an extension with a legacy search task (e.g. https://lab.civicrm.org/ufundo/ukgiftaid/-/tree/searchkit-actions )
1. Task appears in the ACTIONS menu for the contributions
2. But the popup when you click the action fails ( "Unable to reach the server. Please refresh this page in your browser and try again.")
Current behaviour
----------------------------------------
![image](/uploads/f8f841892e5741e9544b5797aa07fbfd/image.png)
```
We can't load the requested web page. This page requires cookies to be enabled in your browser settings. Please check this setting and enable cookies (if they are not enabled). Then try again. If this error persists, contact the site administrator for assistance.<br /><br />Site Administrators: This error may indicate that users are accessing this page using a domain or URL other than the configured Base URL. EXAMPLE: Base URL is http://example.org, but some users are accessing the page via http://www.example.org or a domain alias like http://myotherexample.org.<br /><br />Error type: Could not find a valid session key.
```
Expected behaviour
----------------------------------------
Action form should appear in the pop up.
Comments
----------------------------------------
`SearchDisplay::getSearchTasks` currently generates qfKey for legacy search task forms based on hard-coded class `CRM_Contribute_Controller_Task` in this line https://github.com/civicrm/civicrm-core/blob/a599e40ad27ebcd9d4b8e80bf0a5904983d5ee82/ext/search_kit/Civi/Api4/Action/SearchDisplay/GetSearchTasks.php#LL196C1-L196C77
This causes tasks using any other class controller fail due to the mismatch.
Couple of potential fixes incoming...ufundoufundohttps://lab.civicrm.org/dev/core/-/issues/4289Multi record Profile forms not saving and redirecting on "Add New Record".2023-11-08T14:04:31Zdarren.woodsMulti record Profile forms not saving and redirecting on "Add New Record".Overview
----------------------------------------
Multi record Profile forms are no longer respecting the "Redirect URL" for the Profile:-
![image](/uploads/3b349b061965a160ec7a51cfab703972/image.png)
Reproduction steps
----------------...Overview
----------------------------------------
Multi record Profile forms are no longer respecting the "Redirect URL" for the Profile:-
![image](/uploads/3b349b061965a160ec7a51cfab703972/image.png)
Reproduction steps
----------------------------------------
1. Under "Administer/Custom Data and Screens/Display Preferences" deselect "Enable Popup Forms".
2. Create a multi record custom data group and add a field.
2. Create a Profile which exposes these fields as a standalone form, setting the "Redirect URL" to be a valid URL.
3. Embed this Profile in a WordPress page using a shortcode, e.g.: [civicrm component="profile" gid="16" mode="edit" hijack="0"]
4. View the Page and click "Add new record", enter some valid data and click "Submit button.
Current behaviour
----------------------------------------
Form data is not saved and user is redirected to /civicrm/profile/edit which results in a blank WordPress page.
Expected behaviour
----------------------------------------
Form data is saved and user is redirected to the Redirect URL.
Environment information
----------------------------------------
CiviCRM 5.61.2
WordPress 6.2
Comments
----------------------------------------
_Anything else you would like the reviewer to note._https://lab.civicrm.org/dev/core/-/issues/4284Allow deletion of primary email2023-05-27T04:50:27ZlarsssandergreenAllow deletion of primary emailOn the Contact Summary tab, you can delete a contact's non-primary email, but you cannot delete their primary email. Seems like you should be able to delete any email, primary or not. If you delete a primary email, the next email on the ...On the Contact Summary tab, you can delete a contact's non-primary email, but you cannot delete their primary email. Seems like you should be able to delete any email, primary or not. If you delete a primary email, the next email on the list should become primary.
This is also kind of annoying if you want to add a new primary email and delete the old one, in which case you have to add the new email, make it primary, save, re-open the edit window and then delete the old primary email.https://lab.civicrm.org/dev/core/-/issues/4283Search Kit did not install automatically (Civi 5.61.1 FR and Drupal 7.97.FR2023-05-25T13:23:57ZWebmasterBouclierSearch Kit did not install automatically (Civi 5.61.1 FR and Drupal 7.97.FROverview
----------------------------------------
Funny issue while doing a fresh installation of CiviCRM 5.61.1 FR on a Drupal 7.97 FR (not an upgrade). Search Kit is available in the extensions and indicatated as "Obligatoire" (mandato...Overview
----------------------------------------
Funny issue while doing a fresh installation of CiviCRM 5.61.1 FR on a Drupal 7.97 FR (not an upgrade). Search Kit is available in the extensions and indicatated as "Obligatoire" (mandatory). But it is not outlined in green as the other extensions allready installed. And there is no button to install it.
While trying to install Mosaico, system tell me that Search Kit needs to be installed before.
The Search Kit were not created in the Civi database.
More details and screenshots on chat.civicrm.org : [https://chat.civicrm.org/civicrm/pl/ea5osnwhrj855regwhjkbpse9y](https://chat.civicrm.org/civicrm/pl/ea5osnwhrj855regwhjkbpse9y)
Is this a bug in the installation process of SearchKit?
I solved the issue by using API3 install process, and that solved my problem.
But I understand that Search Kit should have installed itself automatically.
PHP 7.3
MySQL 5.7
Hosting OVH (France)https://lab.civicrm.org/dev/core/-/issues/4279Add support for loading ECMAScript Modules (ESM)2023-10-16T11:57:58ZtottenAdd support for loading ECMAScript Modules (ESM)Introduction
-------------
There was [a recent announcement](https://web.dev/import-maps-in-all-modern-browsers/) about a milestone -- all major browsers [now support](https://caniuse.com/import-maps) ECMAScript Modules (ESM) with "impo...Introduction
-------------
There was [a recent announcement](https://web.dev/import-maps-in-all-modern-browsers/) about a milestone -- all major browsers [now support](https://caniuse.com/import-maps) ECMAScript Modules (ESM) with "import-maps". Import-maps make ESM viable for complex applications (like CiviCRM) without requiring NodeJS during deployment.
The aim of this issue is to fully support ESM for JS development in CiviCRM -- by leveraging browser support for import-maps. It is broken down into a few sections:
* Part 1: Basic ESM Support
* Part 2: Import Map Support
However, because this is relatively new functionality with some risk and compatibility issues, the approach described here is an incremental phase-in -- where specific files/pages/extensions may use ESM (without requiring it for existing screens).
Background
----------
* As discussed in https://gist.github.com/totten/5c34e3885a4fe7002f990e09395b4294, one major factor in updating CiviCRM's Javascript tooling is support for ECMAScript Modules (ESM).
* ESM has increasingly become necessary for a wide of range Javascript tools and libraries.
* Originally, browsers did not support ESM. Instead, JS developers used NodeJS-based tools (such as Webpack or Rollup) to convert ESM's into basic Javascript. However, browser support for ESM has improved over the years.
* For a decent introduction to the concepts of ESM and its import-maps, see (e.g.) https://blog.logrocket.com/es-modules-in-browsers-with-import-maps/ (**Reading this #4279 will be easier if you've already been introduced to the concepts.**)
* This issue corresponds to [approach 4 in the gist](https://gist.github.com/totten/5c34e3885a4fe7002f990e09395b4294#approaches-to-linkingloading-es6-for-civicrm), except that (now) Firefox and Safari both have native support for import-maps.
Part 1. Basic ESM Support
--------------------------------
CiviCRM currently allows you to add Javascript to a page. For example:
```php
Civi::resources()->addScript('doStuff();');
Civi::resources()->addScriptFile('my_extension', 'js/foo.js');
Civi::resources()->addScriptUrl('https://example.com/bar.js');
```
generates output like:
```html
<script type="text/javascript">
doStuff();
</script>
<script type="text/javascript" src="https://example.com/path/to/my_extension/js/foo.js"></script>
<script type="text/javascript" src="https://example.com/bar.js"></script>
```
ESM documents are slightly different from regular Javascript documents -- e.g. they support the `import` and `export` keywords. Browsers require a different declaration for ESM:
```html
<script type="module">
import doStuff from './do-stuff.js';
doStuff();
</script>
<script type="module" src="https://example.com/path/to/my_extension/js/foo.js"></script>
<script type="module" src="https://example.com/bar.js"></script>
```
On the PHP side, we probably need a way to flag resources as ESMs. Perhaps:
```php
Civi::resources()->addScript('import doStuff from \'./do-stuff.js\'; doStuff();', ['esm' => TRUE]);
Civi::resources()->addScriptFile('my_extension', 'js/foo.js', ['esm' => TRUE]);
Civi::resources()->addScriptUrl('https://example.com/bar.js', ['esm' => TRUE]);
```
or
```php
Civi::resources()->addModule('import doStuff from \'./do-stuff.js\'; doStuff();');
Civi::resources()->addModuleFile('my_extension', 'js/foo.js');
Civi::resources()->addModuleUrl('https://example.com/bar.js');
```
Other considerations:
* Does it matter if or how ESM's appear in `hook_civicrm_coreResourceList`? Assuming we keep our current file-names (`*.js`), then there'd be no way to distinguish vanilla JS files from ESM files. OTOH, that hook was [deprecated circa 5.31](https://docs.civicrm.org/dev/en/latest/hooks/hook_civicrm_coreResourceList/). The newer `hook_civicrm_alterBundle` should be more agreeable (e.g. allowing `$bundle->addModuleFile()`, `$bundle->filter()`, etc).
* Is it absolutely necessary to add more methods or flags to `Civi::resources()`? Hypothetically, we could do a global swap in all generated HTML (replace `<script type="text/javascript">` with `<script type="module">`). However, [there are differences of interpretation](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Guide/Modules#other_differences_between_modules_and_standard_scripts) - e.g. wrt scoping and global variables. I did a quick hack to use `type="module"` globally... and the page didn't render. Nothing's impossible, but changing all-at-once feels like a heavier lift.
Part 2. Import Map Support
-----------------------
Outputting `<script type="module">` is a prerequisite for using ESM's in Civi. However, it's not sufficient - a CiviCRM deployment is split across various folders (*what with core, core-exts, downloaded-ext's, CMS plugins, and so on*). With basic ESM's, it's tricky to reference all these folders.
By adding an import-map, we can load dependencies from all these different folders.
For example, on a site with `civicrm`, `search_kit`, and `mosaico`, you might generate an import-map that looks like this:
```html
<script type="importmap">
{
"imports": {
"civicrm/": "https://example.com/modules/civicrm/js/",
"search_kit/": "https://example.com/modules/civicrm/ext/search_kit/js/"
"mosaico/": "https://example.com/files/civicrm/ext/mosaico/js"
}
}
</script>
```
which would enable imports from those paths, as in
```javascript
import searchFoo from 'search_kit/foo.js';
import mosaicoFoo from 'mosaico/foo.js';
```
There are a few important considerations here. In no particular order...
* [Quote](https://developer.mozilla.org/en-US/docs/Web/HTML/Element/script/type/importmap): "Only the first import map in the document with an inline definition is processed; any additional import maps and external import maps are ignored." -- This means that the importmap will (eventually) be subject to contention among applications like CiviCRM, Drupal, WordPress, etc. We'll (eventually) need a way to integrate the import-maps from different applications.
* AFAICS, the CMS's do not currently have a standard way to handle import-maps. But it's on their radar. (Ex: [Drupal issue](https://www.drupal.org/project/drupal/issues/3331393), [WP/Gutenberg issue](https://github.com/WordPress/gutenberg/issues/36716)) We should expect that (eventually) some CMS's will define their own registry. Even when they don't, we should expect *other* CMS plugins will start adding import-maps.
* There is a _logical namespace_. We need some guideline for organizing in the logical-namespace.
* Example: Map between CiviCRM extension-names and ESM folders (as in the `search_kit` and `mosaico` items above).
* Given that every page is limited to one import-map, that means the _logical namespace_ will be shared between Civi extensions and `$open_ended_future_cms_stuff`. We should probably use a prefix.
* Should we automatically map all extensions -- or require an opt-in (e.g. `hook_civicrm_esm` or `hook_civicrm_importMaps`)? How confident are we that CiviCRM extensions should be mapped 1-to-1 with ESM's folder namespace?
* "The `src`, `async`, ... attributes must not be specified." ([source](https://developer.mozilla.org/en-US/docs/Web/HTML/Element/script/type/importmap)) -- The entire importmap must be outputted inline as part of the top-level HTML page; you can load an external map (`<script type="importmap" src="url">`). However, this should eventually change as [WICG's specs define define a way to move the importmap to a `src`](https://github.com/WICG/import-maps#import-map-processing).
Given the constraints and expectation of future change, this approach comes to mind:
1. Define `hook_civicrm_esmImportMap(array &$importMap)` as a way for CiviCRM (core/exts) to modify the import-map.
2. Define `mixin/esm@1.0.0`. This is our first-best-guess at how to map between extensions and ESM folders, Maybe:
```php
return function ($mixInfo) {
Civi::dispatcher()->addListner('hook_civicrm_esmImportMap', function (&$importMap) use ($mixInfo) {
$logicalPath = 'civicrm/' . $mixInfo->shortName . '/';
$physicalPath = Civi::resources()->getUrl($mixInfo->longName) . '/';
$importMap[$logicalPath] = $physicalPath;
});
}
```
3. Provide an initial implementation which fires `hook_esmImportMap` and outputs the `<script type="importmap">...</script>` in the page-header.
* However, we should expect that (in the future) UF-integrations will need to swap this -- they will instead ask CiviCRM for `$importMap` and pass that to a CMS API.
* Additionally, if this mechanism is swappable, then that should improve the prognosis for adding the [es-module-shims](https://github.com/guybedford/es-module-shims) to extend compatibility to older browsers.https://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/4277Add NOT CONTAINS to API & SearchKit2023-05-29T00:19:12ZlarsssandergreenAdd NOT CONTAINS to API & SearchKitAll of the other operators have a negated equivalent, but not CONTAINS. This would be useful in SearchKit if you wanted to find contacts that don't have a particular Preferred communication method or other similar queries, which currentl...All of the other operators have a negated equivalent, but not CONTAINS. This would be useful in SearchKit if you wanted to find contacts that don't have a particular Preferred communication method or other similar queries, which currently aren't possible.
Will have to update the code in [PR 26068](https://github.com/civicrm/civicrm-core/pull/26068) once this done, to allow this to be used on serialized fields in SearchKit.
I'll give this a shot unless there are objections.https://lab.civicrm.org/dev/core/-/issues/4275pear/pear-core-minimal patch no longer needed2023-05-04T17:32:57Zcollinhainespear/pear-core-minimal patch no longer neededOverview
----------------------------------------
The pear/pear-core-minimal package has updated recently which included [this patch](https://lab.civicrm.org/dev/core/-/blob/master/composer.json#L283).
Reproduction steps
---------------...Overview
----------------------------------------
The pear/pear-core-minimal package has updated recently which included [this patch](https://lab.civicrm.org/dev/core/-/blob/master/composer.json#L283).
Reproduction steps
----------------------------------------
1. Create new composer project requiring civicrm/civicrm-core also ensuring that composer patches are allowed to be applied.
Current behaviour
----------------------------------------
The following exception is thrown when installing:
```
...
1 out of 1 hunk ignored
Could not apply patch! Skipping. The error was: Cannot apply patch https://patch-diff.githubusercontent.com/raw/pear/pear-core-minimal/pull/11.patch
In Patches.php line 331:
[Exception]
Cannot apply patch Apply patch to fix creation of dynamic properties in PEAR_Error class (https://patch-diff.githubusercontent.com/raw/pear/pear-core-minimal/pull/11.patch)!
```
Expected behaviour
----------------------------------------
Composer installs as expected.
Environment information
----------------------------------------
<!-- Some of the items below may not be relevant for every bug - if in doubt please include more information than you think is neccessary. -->
* __CiviCRM:__ 5.60.0
* __PHP:__ 8.1
* __CMS:__ Drupal 9.5.x
Comments
----------------------------------------
I think the patch is no longer required.
[Related pear/pear-core-minimal pull request](https://github.com/pear/pear-core-minimal/pull/11).https://lab.civicrm.org/dev/core/-/issues/4274SearchKit: Entities that are no longer results of the search remain selected2023-05-25T15:54:17ZlarsssandergreenSearchKit: Entities that are no longer results of the search remain selectedIf you search for Contacts in SearchKit, select all or some of the Contacts, then edit your search to make it more specific and click search again, the previously selected Contacts, who may not be within the results of the current search...If you search for Contacts in SearchKit, select all or some of the Contacts, then edit your search to make it more specific and click search again, the previously selected Contacts, who may not be within the results of the current search, remain selected. This not only gives nonsensical totals (`100 selected of 10 results`), it can result in unintended changes, for instance if you were to add or remove the Contacts from a group, expecting to be adding or removing the results of your current search, not the results of your previous search (not a theoretical concern, this actually happened to me).
I think the solution is pretty simple, just clear the selection of entities whenever we search again. I can't see why we would want the selected entities to remain selected when we are doing a new search.https://lab.civicrm.org/dev/translation/-/issues/82Spelling error in Dutch deprecation notice2023-05-04T13:50:48ZJanecSpelling error in Dutch deprecation noticeCurrent: APIv3 is de legacy versie van CiviCRM's API. Hoewel nog ondersteunt, raden wij het gebruik in nieuwe projecten af.
Should be: APIv3 is de legacy versie van CiviCRM's API. Hoewel nog ondersteund, raden wij het gebruik in nieuwe ...Current: APIv3 is de legacy versie van CiviCRM's API. Hoewel nog ondersteunt, raden wij het gebruik in nieuwe projecten af.
Should be: APIv3 is de legacy versie van CiviCRM's API. Hoewel nog ondersteund, raden wij het gebruik in nieuwe projecten af.https://lab.civicrm.org/dev/core/-/issues/4271CRM_Core_Error: DB Error: unknown error: Expression 3 of SELECT list is not i...2023-05-02T09:47:12ZkenorbCRM_Core_Error: DB Error: unknown error: Expression 3 of SELECT list is not in GROUP BY clause and contains nonaggregated columnOverview
----------------------------------------
The following error happens when trying to generate a Report from a Dashboard after selecting multiple choice field:
> CRM_Core_Error: DB Error: unknown error: Expression 3 of SELECT li...Overview
----------------------------------------
The following error happens when trying to generate a Report from a Dashboard after selecting multiple choice field:
> CRM_Core_Error: DB Error: unknown error: Expression 3 of SELECT list is not in GROUP BY clause and contains nonaggregated column
Reproduction steps
----------------------------------------
1. Having Contact with custom group field set with the field type: Multiple choice option of type Integer Drop-down select list (Req=Yes)
2. Go to the existing Dashboard page at: /civicrm/report/instance/%
3. Select Multiple choice integer field (mentioned before)
4. Got an error "**Fatal error: DB error**".
Current behaviour
----------------------------------------
The following error happens on clicking 'View results' on Dashboard page.
```
[message] => DB Error: unknown error
[function] => exceptionHandler
[class] => CRM_Core_Error
[type] => ::
[args] => Array
(
[0] => stdClass Object
(
[__CLASS__] => DB_Error
[error_message_prefix] =>
[mode] => 16
[level] => 1024
[code] => -1
[message] => DB Error: unknown error
[userinfo] => SELECT SQL_CALC_FOUND_ROWS civicrm_contact.id as civicrm_contact_civicrm_contact_contact_id , civicrm_contact.display_name as civicrm_contact_civicrm_contact_display_name , civicrm_value_custom_77.custom_455 as civicrm_value_custom_77_custom_455 FROM civicrm_contact civicrm_contact
LEFT JOIN civicrm_value_custom_77 civicrm_value_custom_77 ON civicrm_value_custom_77.entity_id = civicrm_contact.id WHERE ( ( civicrm_contact.contact_type IN ( 'Individual') ) ) AND ( ( civicrm_contact.contact_sub_type LIKE '%�Foo�%' ) OR ( civicrm_contact.contact_sub_type LIKE '%�Bar�%' ) ) AND ( civicrm_value_custom_77.custom_455 IS NOT NULL ) AND ( ( civicrm_contact.contact_type IN ( 'Individual') ) ) AND ( ( civicrm_contact.contact_sub_type LIKE '%�Foo�%' ) OR ( civicrm_contact.contact_sub_type LIKE '%�Bar�%' ) ) AND ( civicrm_value_custom_77.custom_455 IS NOT NULL ) GROUP BY civicrm_contact.id LIMIT 0, 50 [nativecode=1055 ** Expression #3 of SELECT list is not in GROUP BY clause and contains nonaggregated column 'db.civicrm_value_custom_77.custom_455' which is not functionally dependent on columns in GROUP BY clause; this is incompatible with sql_mode=only_full_group_by]
...
modules/civicrm-ext/nz.co.fuzion.extendedreport/CRM/Extendedreport/Form/Report/ExtendedReport.php
[line] => 1737
[function] => buildRows
[class] => CRM_Report_Form
```
Expected behaviour
----------------------------------------
_What should happen._
Environment information
----------------------------------------
<!-- Some of the items below may not be relevant for every bug - if in doubt please include more information than you think is neccessary. -->
* __Browser:__ _112.0.5615.49_
* __CiviCRM:__ _5.39.1_
* __PHP:__ _7.3.33-8_
* __CMS:__ _8.9.20_
* __Database:__ _MySQL 5.7.40_
* __Web Server:__ _Apache/2.4.54 (Ubuntu)_
Comments
----------------------------------------
_Anything else you would like the reviewer to note._https://lab.civicrm.org/dev/core/-/issues/4268Incorrect membership status on payment failure2023-04-28T13:04:50ZMonish DebIncorrect membership status on payment failureOverview
----------------------------------------
If there is an active membership A and the user selects & renews for a different membership B, then on payment failure membership B retain the old membership status (current/new) instead ...Overview
----------------------------------------
If there is an active membership A and the user selects & renews for a different membership B, then on payment failure membership B retain the old membership status (current/new) instead of pending.
Reproduction steps
----------------------------------------
1. A user has active membership A
1. User made a live donation for membership B (that belongs to the same membership org)
1. Payment fails due to some reason.
Current behaviour
----------------------------------------
The user has an active membership B linked with a Pending (Incomplete transaction) contribution.
Expected behaviour
----------------------------------------
The membership status should be set to Pending
Environment information
----------------------------------------
* __Browser:__ _Firefox 59.0.1/Chrome 78.0.3904/Safari 13_
* __CiviCRM:__ _Master_
* __PHP:__ __8.0_
* __CMS:__ _Drupal 8_
* __Database:__ _MariaDB 10.4_
* __Web Server:__ _Apache 2.4_Monish DebMonish Debhttps://lab.civicrm.org/dev/core/-/issues/4263Form Builder: Re-ordering custom field multiple choice options causes front-e...2023-04-26T17:50:35ZshaneonabikeForm Builder: Re-ordering custom field multiple choice options causes front-end IDs to changeOverview
----------------------------------------
We created a sweet little Form Builder that submits the entered information into a CiviCase. In some cases, I needed to show/hide some additional fields based on what they entered in _Int...Overview
----------------------------------------
We created a sweet little Form Builder that submits the entered information into a CiviCase. In some cases, I needed to show/hide some additional fields based on what they entered in _Interests_ so I added some front-end JQuery.
![Selection_002](/uploads/0ac63ecf7496c8681612f49871c5cded/Selection_002.png)
Later, without realizing, the _Interests_ checkbox list was re-ordered, which in tern seems to have changed the IDs for each checkbox item.
![Selection_003](/uploads/38b07ebc39582dae20addf515d642127/Selection_003.png)
Example use-case
----------------------------------------
1. Create a Custom Field set (associated to Individual in my case)
2. Add a ```Alphanumberic``` checkbox field called _Interests_
3. Create a FormBuilder
3. Add _Interests_ field
4. Save and view the form
5. Check the IDs associated to a few checkbox items
6. Edit the _Interests_ checkbox options and re-order them
7. View the form
Current behaviour
----------------------------------------
Presently, I had assumed that perhaps the ID being generated would actually be associated to the actual checbkox ID and would be static (not changing on order change).
Proposed behaviour
----------------------------------------
Is it possible that Form Builder use the actual Multiple Choice ID or if this isn't unique enough perhaps we could use something like ```<field-name>-<field ID>-<multiple choice ID>```https://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.0