CiviCRM Core issueshttps://lab.civicrm.org/dev/core/-/issues2024-02-14T09:53:44Zhttps://lab.civicrm.org/dev/core/-/issues/4982Form builder - Extension provided entity settings2024-02-14T09:53:44ZseamusleeForm builder - Extension provided entity settingsJMA is in the progress of working on a geographically targeted petition extension
At the moment we have some additional settings that we get a user to set when creating the petition page in Form Builder. These get injected by the alter ...JMA is in the progress of working on a geographically targeted petition extension
At the moment we have some additional settings that we get a user to set when creating the petition page in Form Builder. These get injected by the alter angular hook https://lab.jmaconsulting.biz/extensions/geotargetedpetitions/-/blob/main/geotargetedpetitions.php?ref_type=heads#L76 however this means that even on non petition related form builder forms they will show up.
This is about seeing if there is a better way to achieve this and or see if we can get them put onto the specific settings page for say GeotargetedPetition Entity.
@JoeMurray @Edselopez @colemanwhttps://lab.civicrm.org/dev/core/-/issues/4979Should `die()` be called when a DB Query fails?2024-02-14T09:49:16ZhaystackShould `die()` be called when a DB Query fails?Overview
----------------------------------------
As the title says, when a DB Query fails, `CRM_Utils_File::runSqlQuery()` [calls](https://github.com/civicrm/civicrm-core/blob/fd4913060d8e944a99abe30c22ba670ed0e51a9a/CRM/Utils/File.php#...Overview
----------------------------------------
As the title says, when a DB Query fails, `CRM_Utils_File::runSqlQuery()` [calls](https://github.com/civicrm/civicrm-core/blob/fd4913060d8e944a99abe30c22ba670ed0e51a9a/CRM/Utils/File.php#L327) `die()` and all script execution stop *ahem* dead. Is this intentional?
Reproduction steps
----------------------------------------
1. Install the "Deduper" Extension (v1.7) via the API (sorry @eileen :dove:)
1. See the unrecoverable error "**Cannot execute INSERT INTO civicrm_contact_name_pair_family (id, name_a, name_b, is_most_common_form, is_active) VALUES (65, 'Takahashi', '髙𣘺', 0, 1)**".
Current behaviour
----------------------------------------
There's no way to trap this and continue with a script that installs Extensions via the API.
Edit: apparently there [is a way](https://stackoverflow.com/a/16925225) but this seems a less than sensible way to go about trapping the error.
Expected behaviour
----------------------------------------
A script that installs Extensions via the API should be able to trap the error as an `Exception` with `try/catch` and act accordingly.https://lab.civicrm.org/dev/core/-/issues/4978Creating a user was not succesful2024-02-14T09:48:02ZBetty DolfingCreating a user was not succesfulI wanted to add a user to civistandalone, but had to try 5 times, before I was succesful.
I tried in FF first and after 5 times I switched to Chrome. Then a user was created.
I have the impression that not so much the browser caused th...I wanted to add a user to civistandalone, but had to try 5 times, before I was succesful.
I tried in FF first and after 5 times I switched to Chrome. Then a user was created.
I have the impression that not so much the browser caused the problem, but some kind of error.
However, I only saw for a split second an error message in the right hand corner, so am not aware of the _type_ of error.
For now I am ok and when I add users, I will just keep on trying till I am succesful.
But when Civi stand alone is beyond the beta version, this needs to be fixed.https://lab.civicrm.org/dev/core/-/issues/4976Standalone: Timezone improvements2024-02-07T18:41:29ZDaveDStandalone: Timezone improvementsIt doesn't look like standalone has a setting for a site-wide default timezone. It means anywhere where anonymous sees timestamp fields (as opposed to datetime fields) they'll see whatever the server default is, but without a way for the...It doesn't look like standalone has a setting for a site-wide default timezone. It means anywhere where anonymous sees timestamp fields (as opposed to datetime fields) they'll see whatever the server default is, but without a way for the average site admin to "fix" it. At the moment I'm drawing a blank as to which screens this would be. Something like a creation date, or an activity date if you have doctorwhen installed.
I also don't see where php's timezone gets set, which is somewhat equivalent to a site-wide default. There might be some places where that will come up, but am also drawing a blank on where at the moment. Drupal sets it in drupal somewhere, and see e.g. what wordpress does for civi: https://github.com/civicrm/civicrm-core/blob/888e65374f208e6d79ff8adc68d0adfa05575277/CRM/Utils/System/WordPress.php#L732https://lab.civicrm.org/dev/core/-/issues/4975FormBuilder: Case Status field shows disabled statuses2024-02-23T15:32:47ZnoahFormBuilder: Case Status field shows disabled statusesThe Case Type admin screen (e.g. civicrm/a/#/caseType/1) allows you to disable some case statuses for a given case type.
When you create a Case submission form in FormBuilder, and add the Case Status field to the form, all case statuses...The Case Type admin screen (e.g. civicrm/a/#/caseType/1) allows you to disable some case statuses for a given case type.
When you create a Case submission form in FormBuilder, and add the Case Status field to the form, all case statuses are available in the resulting widget, regardless of whether they're enabled for the case type.
You can manually remove some of the status options, but they won't stay in sync with the Case Type admin screen.https://lab.civicrm.org/dev/core/-/issues/4972IOS 17 params encoding issue Activity, Contacts, Relationships, Events entity2024-02-09T11:18:51ZBohdanDmytryshynIOS 17 params encoding issue Activity, Contacts, Relationships, Events entityOverview
----------------------------------------
For apps linked on or after iOS 17 and aligned OS versions, URL parsing has updated from the obsolete RFC 1738/1808 parsing to the same RFC 3986 parsing as URLComponents. This unifies the...Overview
----------------------------------------
For apps linked on or after iOS 17 and aligned OS versions, URL parsing has updated from the obsolete RFC 1738/1808 parsing to the same RFC 3986 parsing as URLComponents. This unifies the parsing behaviors of the URL and URLComponents APIs. Now, URL automatically percent- and IDNA-encodes invalid characters to help create a valid URL. You can read about it more https://developer.apple.com/documentation/foundation/url/3126806-init.
How URL looks like in normal form:
/sites/all/modules/civicrm/extern/rest.php?key=KEY&civimobile =1 &api_key =APIKEY &entity =Activity &action =get &json =%7B%22sequential%22:1,%22is_deleted%22:0,%22is_current_revision%22:1,%22is_test%22:0,%22contact_id%22:%222%22,%22status_id%22:%7B%22NOT+IN%22:[%222%22,%223%22]%7D,%22return%22:%22subject,activity_date_time,activity_type_id,status_id.name,status_id,status,priority_id,priority_id.label,priority_id.name,details,duration,source_contact_id,assignee_contact_id,target_contact_id,activity_type_id.label,status_id.label,short_description,location,case_type_is_active,can_edit,can_delete%22,%22options%22:%7B%22limit%22:20,%22sort%22:%22activity_date_time+DESC%22%7D%7D
How URL looks like in IOS 17:
/sites/all/modules/civicrm/extern/rest.php?key=KEY&civimobile=1&api_key=APIKEY&entity=Activity&action=get&json=%257B%2522sequential%2522:1,%2522is_deleted%2522:0,%2522is_current_revision%2522:1,%2522is_test%2522:0,%2522contact_id%2522:%25222%2522,%2522status_id%2522:%257B%2522NOT+IN%2522:%5B%25222%2522,%25223%2522%5D%257D,%2522return%2522:%2522subject,activity_date_time,activity_type_id,status_id.name,status_id,status,priority_id,priority_id.label,priority_id.name,details,duration,source_contact_id,assignee_contact_id,target_contact_id,activity_type_id.label,status_id.label,short_description,location,case_type_is_active,can_edit,can_delete%2522,%2522options%2522:%257B%2522limit%2522:20,%2522sort%2522:%2522activity_date_time+DESC%2522%257D%257D\
So API doesn’t accept query params in IOS 17. Lower IOS versions and Android work as expected
Environment information
----------------------------------------
* __CiviCRM:__ _Master/5.67.3/5.69.4
* __PHP:__ 7.3/8.0+https://lab.civicrm.org/dev/core/-/issues/4966Packaged SearchKit cannot be multilingual2024-02-03T18:48:06ZbgmPackaged SearchKit cannot be multilingualPackaged SearchKits, such as CiviCampaign, support translation into a single language, but not into multiple languages.
For example:
- Go to Admin > Localization > Languages
- Enable a second language (such as French), no need to enabl...Packaged SearchKits, such as CiviCampaign, support translation into a single language, but not into multiple languages.
For example:
- Go to Admin > Localization > Languages
- Enable a second language (such as French), no need to enable multi-lingual
- Enable the "language switcher" extension
- Leave the default site language to English
Then go to the Campaign Dashboard, and switch the language to French. The UI will still be mostly in English.
While still being in French, go to Administer > System Settings > Cleanup Cache: flush the cache.
Then reload the Campaign Dashboard, and it will be in French, but only in French.
CiviCRM stores the evaluated strings in the civicrm_search_display` table.https://lab.civicrm.org/dev/core/-/issues/4965Afform dies for contacts if no ID or contact_type2024-02-05T02:42:57ZufundoAfform dies for contacts if no ID or contact_typeA second slightly weird Afform edge case I hit today.
Example afform:
```A
<af-form ctrl="afform">
<af-entity data="{source: 'Enquiry form'}" type="Contact" name="Contact1" label="Contact email" actions="{create: true, update: true}"...A second slightly weird Afform edge case I hit today.
Example afform:
```A
<af-form ctrl="afform">
<af-entity data="{source: 'Enquiry form'}" type="Contact" name="Contact1" label="Contact email" actions="{create: true, update: true}" security="RBAC" />
<fieldset af-fieldset="Contact1" class="af-container" af-title="Contact">
<p class="af-text">Follow up contact email</p>
<div af-join="Email" data="{is_primary: true}">
<af-field name="email" />
</div>
</fieldset>
<button class="af-button btn btn-primary" crm-icon="fa-check" ng-click="afform.submit()" ng-if="afform.showSubmitButton">Submit</button>
</af-form>
```
The form gives on submit "No contact_type given to CRM_Contact_BAO_Contact::hasName".
It looks like the Afform api Submit action is trying to check whether a submitted contact entity has a name OR email (so is creatable) - but the name check throws an exception if no contact_type is provided - even if there was a viable email.
Potentially having a Contact entity without a specified contact_type is _a bad idea_ ... but I can see a use case like the above where you want people to be able to submit an email, that might then be deduped against contacts of any type? (Testing now I realise this doesn't work out-of-the-box because deduping is within contact types... but you might have some later hooks onto the submit event to deal with this maybe...?)
Potential patch incoming at any rate.https://lab.civicrm.org/dev/core/-/issues/4964Attaching multiple contacts to an activity in afform dies if one in the middl...2024-02-07T10:27:26ZufundoAttaching multiple contacts to an activity in afform dies if one in the middle is missingHit an issue today with trying to assign multiple contacts to an activity with an afform.
Example afform:
````
<af-form ctrl="afform">
<af-entity data="{source_contact_id: 'user_contact_id', activity_type_id: '1', **target_contact_id...Hit an issue today with trying to assign multiple contacts to an activity with an afform.
Example afform:
````
<af-form ctrl="afform">
<af-entity data="{source_contact_id: 'user_contact_id', activity_type_id: '1', **target_contact_id: ['Individual1', 'Individual2', 'Organization1']**}" type="Activity" name="Activity1" label="Activity 1" actions="{create: true, update: true}" security="RBAC" />
<af-entity data="{contact_type: 'Individual', source: 'Meeting Log'}" type="Contact" name="Individual1" label="Chair" actions="{create: true, update: true}" security="RBAC" />
<af-entity data="{contact_type: 'Individual', source: 'Meeting Log'}" type="Contact" name="Individual2" label="Minute Taker" actions="{create: true, update: true}" security="RBAC" />
<af-entity data="{contact_type: 'Organization', source: 'Meeting Log'}" type="Contact" name="Organization1" label="Host Organisation" actions="{create: true, update: true}" security="RBAC" />
<button class="af-button btn btn-primary" crm-icon="fa-check" ng-click="afform.submit()" ng-if="afform.showSubmitButton">Submit</button>
<fieldset af-fieldset="Activity1" class="af-container" af-title="Meeting">
<af-field name="subject" />
</fieldset>
<fieldset af-fieldset="Individual1" class="af-container" af-title="Chair">
<div class="af-container">
<div class="af-container af-layout-inline">
<af-field name="first_name" />
<af-field name="last_name" />
</div>
</div>
</fieldset>
<fieldset af-fieldset="Individual2" class="af-container" af-title="Minute Taker">
<div class="af-container">
<div class="af-container af-layout-inline">
<af-field name="first_name" />
<af-field name="last_name" />
</div>
</div>
</fieldset>
<fieldset af-fieldset="Organization1" class="af-container" af-title="Host Organisation">
<af-field name="organization_name" />
</fieldset>
</af-form>
```
Fill in all the contacts and you get an activity with 3 contacts.
If you skip Individual2 (Minute Taker), however... what happens? The Activity, Individual1 and the Organisation are created, but only Individual1 is linked to the Activity...
Think the issue is with the splicing here https://github.com/civicrm/civicrm-core/blob/1880f9bdfe20be6e1d0a47a74c2b480b6f27e055/ext/afform/core/Civi/Api4/Action/Afform/AbstractProcessor.php#L355 - patch incoming :slight_smile:https://lab.civicrm.org/dev/core/-/issues/4958Deprecated function CRM_Contact_BAO_ContactType::retrieve2024-03-15T20:43:33ZPradeep Nayakpradpnayak@gmail.comDeprecated function CRM_Contact_BAO_ContactType::retrieveOn edit of contact subtype get a deprecation error
/civicrm/admin/options/subtype/edit?action=update&id=2&reset=1
Deprecated function CRM_Contact_BAO_ContactType::retrieve, use API. CRM_Core_Error::deprecatedFunctionWarning CRM_Contact_...On edit of contact subtype get a deprecation error
/civicrm/admin/options/subtype/edit?action=update&id=2&reset=1
Deprecated function CRM_Contact_BAO_ContactType::retrieve, use API. CRM_Core_Error::deprecatedFunctionWarning CRM_Contact_BAO_ContactType::retrieve CRM_Admin_Form::retrieveValues CRM_Admin_Form::preProcess Array ( [civi.tag] => deprecated )
```2024-02-02 11:34:18+0000 [warning] Deprecated function CRM_Contact_BAO_ContactType::retrieve, use API.
CRM_Core_Error::deprecatedFunctionWarning
CRM_Contact_BAO_ContactType::retrieve
CRM_Admin_Form::retrieveValues
CRM_Admin_Form::preProcess
Array
(
[civi.tag] => deprecated
)
```https://lab.civicrm.org/dev/core/-/issues/4957attempt to access invalid property :_tagGroup Caller: CRM_Contact_Form_Edit_T...2024-02-08T09:56:27ZRobert J. Langattempt to access invalid property :_tagGroup Caller: CRM_Contact_Form_Edit_TagsAndGroups::buildQuickForm Array ( [civi.tag] => deprecated )Overview
----------------------------------------
After upgrading from a CiviCRM 5.67.1 site to 5.69.4-ESR, I saw many messages in the watchdog log like these resulting from loading a Membership Contribution page that contains checkboxe...Overview
----------------------------------------
After upgrading from a CiviCRM 5.67.1 site to 5.69.4-ESR, I saw many messages in the watchdog log like these resulting from loading a Membership Contribution page that contains checkboxes for mailing list groups in the profile:
* attempt to access invalid property :_tagGroup Caller: CRM_Contact_Form_Edit_TagsAndGroups::buildQuickForm Array ( [civi.tag] => deprecated )
* Notice: Indirect modification of overloaded property CRM_Contribute_Form_Contribution_Main::$_tagGroup has no effect in CRM_Contact_Form_Edit_TagsAndGroups::buildQuickForm() (line 112 of /mysite/modules/contrib/civicrm/CRM/Contact/Form/Edit/TagsAndGroups.php).
Furthermore, and more importantly, the checkboxes are no longer rendered at all on the form.
Since the error message says that `:_tagGroup` is an invalid property, a search through the CiviCRM code turns up several references to it `$form->_tagGroup` in file `civicrm/CRM/Contact/Form/Edit/TagsAndGroups.php` (including the line 112 cited in the message above).
Is there a straightforward fix for this? We signed up for ESR to reduce the need to regularly update, but can't update to the current ESR version when it breaks membership signups.https://lab.civicrm.org/dev/core/-/issues/49565.69.1 critical error: Undefined array key "crmSearchTasks" in "ext/search_ki...2024-02-07T10:25:28ZDmitry Smirnov5.69.1 critical error: Undefined array key "crmSearchTasks" in "ext/search_kit/search_kit.php" on line 61```
PHP Warning: Undefined array key "crmSearchTasks" in ext/search_kit/search_kit.php on line 61
PHP Warning: Trying to access array offset on value of type null in ext/search_kit/search_kit.php on line 61
PHP Fatal error: Uncaught T...```
PHP Warning: Undefined array key "crmSearchTasks" in ext/search_kit/search_kit.php on line 61
PHP Warning: Trying to access array offset on value of type null in ext/search_kit/search_kit.php on line 61
PHP Fatal error: Uncaught TypeError: in_array(): Argument #2 ($haystack) must be of type array, null given in ext/search_kit/search_kit.php:61
```https://lab.civicrm.org/dev/core/-/issues/4955Upgrade to Smarty52024-02-01T10:45:19ZeileenUpgrade to Smarty5Now that we have upgraded many sites to Smarty3 Smarty5 is on the cusp of being release....
See related issue https://lab.civicrm.org/dev/core/-/issues/4954 on getting to Smarty4
The upgrade from Smarty 3 or 4 to Smarty 5 has some mino...Now that we have upgraded many sites to Smarty3 Smarty5 is on the cusp of being release....
See related issue https://lab.civicrm.org/dev/core/-/issues/4954 on getting to Smarty4
The upgrade from Smarty 3 or 4 to Smarty 5 has some minor challenges.
https://smarty-php.github.io/smarty/5.x/upgrading/
1) assign_by_ref needs to be replaced with assign wherever it appears (yay I've been wanting to get rid of those)
2) some php-language modifiers will stop working without intervention (not sure how affected we are but if some are common it is easy to 'make them work')
3) before we can see / address the above there is a problem with our Smarty compatibility class. Our Smarty class has functions like `getTemplateVars()` to allow sites still on Smarty2 to call the v3 functions. That particular function has a different signature in Smarty5 so overriding it causes fatals
Proposal
1) Check Smarty5 into packages like Smarty4 - see https://github.com/civicrm/civicrm-packages/pull/380
2) the path fix in Smarty4 will allow easy switch to Smarty5 for developers
3) Move `getTemplateVars()` & any other functions in the same boat from being on our Smarty compatibility class to being 'hacked onto' the Smarty 2 code in our packages folder.
4) replace assign-by-ref with assign
- That should be enough to get us to the point where we can get dev sites to load and from there we can figure out if we have to scale a mountain or a molehill to move to Smarty5 instead of 3 or 4 when we do our force changehttps://lab.civicrm.org/dev/core/-/issues/4954Upgrade to Smarty4....2024-03-15T21:05:34ZeileenUpgrade to Smarty4....Now that we have upgraded many sites to Smarty3 & seem close to ironing out the issues I had a go at Smarty4 and was able to get it working. The extra fixes were entirely in our core compatibility layer so the challenges of moving a site...Now that we have upgraded many sites to Smarty3 & seem close to ironing out the issues I had a go at Smarty4 and was able to get it working. The extra fixes were entirely in our core compatibility layer so the challenges of moving a site from Smarty2 to Smarty4 are now equivalent to moving to Smarty3.
https://smarty-php.github.io/smarty/5.x/upgrading/#removed-php-constants
One annoying thing we did was name our Smarty mixin & the define in a version specific way. In fact there is nothing v2 specific about our mixin and the methodology of defining ` CIVICRM_SMARTY3_AUTOLOAD_PATH` works for Smarty4 as well as it does for Smarty3. If it wasn't for those naming issues I would recommend we simply replace the contents of packages/smarty3 with the Smarty 4 library.
However, given where we are I recommend we
1) merge Smarty4 into packages here https://github.com/civicrm/civicrm-packages/pull/380
2) add a new define `CIVICRM_SMARTY_AUTOLOAD_PATH` - respect it but fall back to `CIVICRM_SMARTY3_AUTOLOAD_PATH` if present
3) update our demo sites / build sites etc to Smarty4
4) update all our messaging to encourage people to use Smarty4 not 3 (but if they have already switched to 3 don't further message as being off Smarty2 is enough to flush out any extension or issues that would impede our medium term plans to put Smarty4 in vendor & stop shipping Smarty3
Note that Smarty4 hard-fails on `{php}` tags in tpls whereas Smarty3 has a backwards compatibility layer that would have supported it, had we chosen to enable it, which we didn't.5.72.0https://lab.civicrm.org/dev/core/-/issues/4952PHP 8.3 Support2024-01-31T22:32:21ZJoeMurrayPHP 8.3 SupportThis is an epic for PHP 8.3 support.
PHP 8.3 was released 2023-11, has active support till 2024-12-8, and security support till 2025-12-08.
Some extra motivation to support 8.3 sooner rather that later is the significant performance im...This is an epic for PHP 8.3 support.
PHP 8.3 was released 2023-11, has active support till 2024-12-8, and security support till 2025-12-08.
Some extra motivation to support 8.3 sooner rather that later is the significant performance improvements it has, up to 55% for D10 over 8.1: https://kinsta.com/blog/php-benchmarks/
Reference: [https://www.php.net/manual/en/migration83.incompatible.php](https://www.php.net/manual/en/migration83.incompatible.php)
See also [thttps://php.watch/versions/8.3](https://php.watch/versions/8.3) and [https://www.php.net/releases/8.3/en.php](https://www.php.net/releases/8.3/en.php).
Here are the breaking changes listed here for reference. Almost all seem like they would be difficult to search for and identify in the codebase. Whack-a-mole from running on edge test servers might be a helpful approach.
- [ ] Uses of traits with static properties: Uses of traits with static properties will now redeclare static properties inherited from the parent class. This will create a separate static property storage for the current class. This is analogous to adding the static property to the class directly without traits.
- [ ] Assigning a negative index to an empty array: Assigning a negative index $n to an empty array will now make sure that the next index is $n+1 instead of 0.
- [ ] Class constant visibility variance check: Class constant visibility variance is now correctly checked when inherited from interfaces.
- [ ] WeakMap entries whose key maps to itself: WeakMap entries whose key maps to itself (possibly transitively) may now be removed during cycle collection if the key is not reachable except by iterating over the WeakMap (reachability via iteration is considered weak). Previously, such entries would never be automatically removed.
- [ ] Date: The DateTime extension has introduced Date extension specific exceptions and errors under the DateError and DateException hierarchies, instead of warnings and generic exceptions. This improves error handling, at the expense of having to check for errors and exceptions.
- [ ] DOM: Calling DOMChildNode::after(), DOMChildNode::before(), DOMChildNode::replaceWith() on a node that has no parent is now a no-op instead of a hierarchy exception, which is the behaviour demanded by the DOM specification.
Using the DOMParentNode and DOMChildNode methods without a document now works instead of throwing a DOM_HIERARCHY_REQUEST_ERR DOMException. This is in line with the behaviour demanded by the DOM specification.
Calling DOMDocument::createAttributeNS() without specifying a prefix would incorrectly create a default namespace, placing the element inside the namespace instead of the attribute. This bug is now fixed.
DOMDocument::createAttributeNS() would previously incorrectly throw a DOM_NAMESPACE_ERRNAMESPACE_ERR DOMException when the prefix was already used for a different URI. It now correctly chooses a different prefix when there's a prefix name conflict.
New methods and properties were added to some DOM classes. If a userland class inherits from these classes and declare a method or property with the same name, the declarations must be compatible. Otherwise, a typical compile error about incompatible declarations will be thrown. See the list of new features and new functions for a list of the newly implemented methods and properties.
- [x] FFI: C functions that have a return type of void now return null instead of returning the following object object(FFI\CData:void) { }
- [ ] Opcache: The opcache.consistency_checks INI directive was removed. This feature was broken with the tracing JIT, as well as with inheritance cache, and has been disabled without a way to enable it since PHP 8.1.18 and PHP 8.2.5. Both the tracing JIT and inheritance cache may modify shm after the script has been persisted by invalidating its checksum. The attempted fix skipped over the modifiable pointers but was rejected due to complexity. For this reason, it was decided to remove the feature instead.
- [ ] Phar: The type of Phar class constants are now declared.
- [ ] Standard: The range() function has had various changes:
A TypeError is now thrown when passing objects, resources, or arrays as the boundary inputs.
A more descriptive ValueError is thrown when passing 0 for $step.
A ValueError is now thrown when using a negative $step for increasing ranges.
If $step is a float that can be interpreted as an int, it is now done so.
A ValueError is now thrown if any argument is infinity or NAN.
An E_WARNING is now emitted if $start or $end is the empty string. The value continues to be cast to the value 0.
An E_WARNING is now emitted if $start or $end has more than one byte, only if it is a non-numeric string.
An E_WARNING is now emitted if $start or $end is cast to an integer because the other boundary input is a number. (e.g. range(5, 'z');).
An E_WARNING is now emitted if $step is a float when trying to generate a range of characters, except if both boundary inputs are numeric strings (e.g. range('5', '9', 0.5); does not produce a warning).
range() now produce a list of characters if one of the boundary inputs is a string digit instead of casting the other input to int (e.g. range('9', 'A');).
```
<?php
range('9', 'A'); // ["9", ":", ";", "<", "=", ">", "?", "@", "A"], as of PHP 8.3.0
range('9', 'A'); // [9, 8, 7, 6, 5, 4, 3, 2, 1, 0], prior to PHP 8.3.0
?>
```
The file() flags error check now catches all invalid flags. Notably FILE_APPEND was previously silently accepted.
- [ ] SNMP: The type of SNMP class constants are now declared.https://lab.civicrm.org/dev/core/-/issues/4947Proposal: Store Contribution Page ID in the `civicrm_contribution_recur` table2024-02-01T10:23:33ZjaapjansmaProposal: Store Contribution Page ID in the `civicrm_contribution_recur` tableOverview
----------------------------------------
When a recurring contribution is created with a contribution page. Also store the contribution page ID in the `civicrm_contribution_recur` table.
This works already for 'normal' contrib...Overview
----------------------------------------
When a recurring contribution is created with a contribution page. Also store the contribution page ID in the `civicrm_contribution_recur` table.
This works already for 'normal' contribution.
Example use-case
----------------------------------------
1. CiviRules can be used when a new Contribution Recur is added and a condition can then be used which Contribution Page this came from.
Current behaviour
----------------------------------------
Currently for the 'normal' contributions the contribution page ID is stored in the `civicrm_contribution` table.
Proposed behaviour
----------------------------------------
1. Add a column to the `civicrm_contribution_recur` table called `contribution_page_id`
2. When a contribution recur is added through a Contribution Page then store the contribution page id into this column
3. Optional we can show the data from this field in the user interface when a user views a contribution recur
Workaround
----------------------------------------
There is a workaround with an extension: https://lab.civicrm.org/extensions/storecontributionpageidoncontribrecurjaapjansmajaapjansmahttps://lab.civicrm.org/dev/core/-/issues/4946DB error on gender searches2024-02-01T16:06:14ZyashodhaDB error on gender searchesWe should NOT allow non numeric values for gender option values.
gender_id in the database expects numeric values instead, we should form rule for such entities.We should NOT allow non numeric values for gender option values.
gender_id in the database expects numeric values instead, we should form rule for such entities.yashodhayashodhahttps://lab.civicrm.org/dev/core/-/issues/4944Mass SMS continue button creates a new mass SMS2024-02-02T13:10:39ZDaveDMass SMS continue button creates a new mass SMSCame up during PR review.
The screens appear as though it's editing the existing one but there's a warning about missing ssid, so I assume it's not getting passed on so it then creates a new one.
1. Mailings - New SMS.
1. Fill out the ...Came up during PR review.
The screens appear as though it's editing the existing one but there's a warning about missing ssid, so I assume it's not getting passed on so it then creates a new one.
1. Mailings - New SMS.
1. Fill out the fields. Click Next.
1. Click Continue Later.
1. This takes you to the Find Mass SMS screen and you'll see your draft.
1. Click the Continue link at the far right.
1. It looks as though you're editing the draft, but click Next and then Next again, and then click the Continue Later button.
1. Note in the Find Mass SMS screen there's now two draft mailings.https://lab.civicrm.org/dev/core/-/issues/4941Number field input validation does not respect decimal separator setting (eve...2024-02-12T17:14:12ZDetlev SieberNumber field input validation does not respect decimal separator setting (event custom field)## Overview
This is a variant of https://lab.civicrm.org/dev/core/-/issues/4154, regarding custom fields for events of type _This iPlease describe your problem or bug in detail._
_If you have already posted on __https://civicrm.stackex...## Overview
This is a variant of https://lab.civicrm.org/dev/core/-/issues/4154, regarding custom fields for events of type _This iPlease describe your problem or bug in detail._
_If you have already posted on __https://civicrm.stackexchange.com__ or __https://chat.civicrm.org__, please include the link to that conversation._
## Reproduction steps
1. Under Administer \> Localization \> Languages, Currency, Locations, set "Thousands Separator" to "." (dot) and "Decimal Delimiter" to "," (comma).
2. Create a custom field extending Events. Data type: Number.
3. Edit an existing event (or: add a new event). In the number field, enter a number that includes a comma, such as "1,5".
4. Press Save: nothing happens
5. Reload page: Error message appears "**Error One of parameters (value: 1,5) is not of the type Float**"
## Current behaviour
Validation fails with the error message "**Error One of parameters (value: 1,5) is not of the type Float**"
## Expected behaviour
Validation should not fail for decimal numbers with decimal separator ","
## Environment information
* **CiviCRM:** 5.69.3
* **PHP:** 7,4, 8.1
* **CMS:** Drupal, WordPress
## Comments
This bug was fixed for some fields with #4154 (https://github.com/civicrm/civicrm-core/pull/28369)
Also, I believe this is some kind of regression, because in a system of one of my clients, this did work \~15 months ago. However, tbh I have no clear idea when it broke. (and still, it cannot completely excluded that the existing data was entered with decimal separator ".")5.71.0https://lab.civicrm.org/dev/core/-/issues/4940Proposal to Change the Invoice date in the default Invoice message template t...2024-02-08T10:45:03ZeileenProposal to Change the Invoice date in the default Invoice message template to contribution.receive_dateThis spins off one discussion topic from https://lab.civicrm.org/dev/core/-/issues/1403 -
As part of our general effort to make the WorkflowMessage templates operate independently of the quickform layer (ie be available as actions from ...This spins off one discussion topic from https://lab.civicrm.org/dev/core/-/issues/1403 -
As part of our general effort to make the WorkflowMessage templates operate independently of the quickform layer (ie be available as actions from SearchKit etc) we should clarify which value is used for the invoice_date in the default message template that we ship from \`{$invoice_date}\`
```html
{domain.now|crmDate:"Full"}
or
{contribution.receive_date|crmDate:"Full"}
```
If we change the default it will affect new installs and un-customised templates. I'm not proposing any push upgrade on the customised templates at this stage so for most invoice-using sites this will be no change at this point. However, I am going to try to 'complete' the variable to token changes in this template so that anyone who is updating their customised template or installing a new site is using the tokens (& hence will be able to benefit from message previewability via MessageAdmin now & sending & rendering from outside QF if they install a relevant extension /when we add to core).
Potentially if we want to make it clear to people that they can change it we can use one of
```html
{domain.now|crmDate:"Full"}{* Code comment: - You can replace the domain.now token with this to show the contribution date instead {contribution.receive_date|crmDate:"Full"} *}
OR
{contribution.receive_date|crmDate:"Full"}{* Code comment: - You can replace the domain.now token with this to show the current date instead with {domain.now|crmDate:"Full"} *}
```
Note that the assumption in this gitlab is that any change would be opt in for existing sites (since basically everyone who uses invoices puts a logo in there). There is a proposal at https://github.com/civicrm/civicrm-core/pull/28630 that would force a change on everyone. I'm not convinced we should do a force update because it is pretty clear from the code & code history that the use of now was a deliberate attempt to meet a use case. However I have added an option to the emjoi poll below to allow people to vote for a forced update - basically a string_replace on upgrade.
EMOJI POLL Options
1) :boom: Change to {domain.now|crmDate:"Full"}
2) :man_dancing_tone2: Change to {contribution.receive_date|crmDate:"Full"}
3) :avocado: Change to 1 with additional in-code comments per above
4) :bellhop: Change to 2 with additional in code comments per above
5) :pick: Do 2 with a forced upgrade to replace {$invoice_date} with the above with {contribution.receive_date|crmDate:"Full"}