CiviCRM Core issueshttps://lab.civicrm.org/dev/core/-/issues2024-03-26T21:44:23Zhttps://lab.civicrm.org/dev/core/-/issues/5111PHP8.1 Deprecated function: fseek():2024-03-26T21:44:23ZbobisHDPHP8.1 Deprecated function: fseek():Overview
----------------------------------------
On php8.1 the below error will appear:
```Deprecated function: fseek(): Passing null to parameter #2 ($offset) of type int is deprecated in FileReader->seekto() (line 125 of /opt/bitnam...Overview
----------------------------------------
On php8.1 the below error will appear:
```Deprecated function: fseek(): Passing null to parameter #2 ($offset) of type int is deprecated in FileReader->seekto() (line 125 of /opt/bitnami/apps/civicrm/htdocs/sites/all/modules/civicrm/packages/PHPgettext/streams.php)```
The code in this file that causes the error is:
```php
function seekto($pos) {
fseek($this->_fd, $pos);
$this->_pos = ftell($this->_fd);
return $this->_pos;
}
```
After changing this to
```php
function seekto($pos) {
fseek($this->_fd, $this->_pos);
$this->_pos = ftell($this->_fd);
return $this->_pos;
}
```
It seems to make the error go away.
If you have already posted on:
- https://civicrm.stackexchange.com
- https://chat.civicrm.org/civicrm/pl/yfx7e3un4f8nifxq1iknj5amjw
Environment information
----------------------------------------
* __Browser:__ Firefox
* __CiviCRM:__ 5.71.0
* __PHP:__ 8.1
* __CMS:__ Drupal 7.100
* __Database:__ MariaDB 10.6.16
* __Web Server:__ Apache/2.4.52https://lab.civicrm.org/dev/core/-/issues/3808[ext:message_admin] Available preview choices should be based on the site's c...2024-03-26T18:25:12ZDaveD[ext:message_admin] Available preview choices should be based on the site's configIt has fixed choices. And formatting like the comma/dot separators it uses may or may not make sense for the selected preview.It has fixed choices. And formatting like the comma/dot separators it uses may or may not make sense for the selected preview.https://lab.civicrm.org/dev/core/-/issues/5069standalone: permanent "session already active" errors2024-03-26T14:20:29ZRichstandalone: permanent "session already active" errorsEvery page, including the login form has:
* session_set_save_handler(): Session save handler cannot be changed when a session is active [2]
/var/www/standalone.localhost/web/core/CRM/Utils/System/Standalone.php line 567
* sessi...Every page, including the login form has:
* session_set_save_handler(): Session save handler cannot be changed when a session is active [2]
/var/www/standalone.localhost/web/core/CRM/Utils/System/Standalone.php line 567
* session_start(): Ignoring session_start() because a session is already active [8]
/var/www/standalone.localhost/web/core/CRM/Utils/System/Standalone.php line 580
I first encountered this while reviewing https://github.com/civicrm/civicrm-core/pull/29352 but after experiencing it once, I could not get it to repeat, so thought it was a random local thing. But now it's back.
I have some installs that don't have it, and others that do; I'm trying to figure out how to reproduce/what makes the difference.https://lab.civicrm.org/dev/core/-/issues/4994Standalone - issues with haveibeenpwned on password setting screen?2024-03-26T11:33:19ZufundoStandalone - issues with haveibeenpwned on password setting screen?RichRichhttps://lab.civicrm.org/dev/core/-/issues/2Display Inbound Email: linefeed suppressed2024-03-26T10:22:28ZDetlev SieberDisplay Inbound Email: linefeed suppressedWhen viewing an activity of type inbound email, the text is displayed in "details". However, althought the database contains it in plain text and html, it is displayed as plain text without LFs, what makes it hardly readable.When viewing an activity of type inbound email, the text is displayed in "details". However, althought the database contains it in plain text and html, it is displayed as plain text without LFs, what makes it hardly readable.4.7.31https://lab.civicrm.org/dev/core/-/issues/4803Custom Fields on Campaign are hidden on validation2024-03-26T07:53:12Za.valllloveraCustom Fields on Campaign are hidden on validation## Overview
When trying to submit a new Campaign with a Type that have custom fields, if the valdator return some error/fields missing, the custom fields are hidden.
## Reproduction steps
1. Create some Custom Fields for a Campaign Ty...## Overview
When trying to submit a new Campaign with a Type that have custom fields, if the valdator return some error/fields missing, the custom fields are hidden.
## Reproduction steps
1. Create some Custom Fields for a Campaign Type. **Administer -\> Customize Data and Screens -\> Custom Fields**
2. Create new Campaign. **Campaigns-\> New Campaign**
3. Select the Campaign Type that have the custom fields but **don't input the title** (for easier validation). The custom fields appers at bottom.
4. Click **Save**
5. The custom fields are hidden because validator tells you to fill the Title field.
## Current behaviour
![Error Campaign.gif](/uploads/41a8748520c6037df7d5a7d502762670/Error_Campaign.gif)
## Expected behaviour
Custom fields should still remain after validation fails.
## Environment information
* **CiviCRM:** _Master/5.69.alpha1_https://lab.civicrm.org/dev/core/-/issues/5061New structure for getFields array in `.entityType.php`2024-03-25T20:55:29ZcolemanwNew structure for getFields array in `.entityType.php`Currently getFields reads from a `schema/xml` file with some wonky formatting. The plan in #4999 is to migrate those `.xml` files to `.entityType.php` files. So now we have a clean slate to decide how those files should be formatted.
No...Currently getFields reads from a `schema/xml` file with some wonky formatting. The plan in #4999 is to migrate those `.xml` files to `.entityType.php` files. So now we have a clean slate to decide how those files should be formatted.
Note: This will not affect the output of `DAO::fields()` or `APIv(3|4).getFields`, as we'll add a compatibility layer and tests to ensure those remain unchanged. But since we're replacing the underlying source of the data with something new, we get to clean that up.
Here are all the current keys in the schema/xml files, and what we plan to do with it in the new file. Many of the proposed changes would improve consistency with APIv4.getFields.
| Old key from `xml` | What to do | New key in `php` | Notes |
| ------ | ------ | ------ | ------ |
| `<name>` | ⚠️ index by | | Use name as array key, omit from array values |
| `<title>` | ✅ keep | `title` | |
| `<required>` | ✅ keep | `required` | |
| `<add>` | ✅ keep | `add` | |
| `<pseudoconstant>` | ✅ keep | `pseudoconstant` | snake_case all values in array |
| `<default>` | ✅ keep | `default` | |
| `<contactType>` | ✅ keep | `contact_type` | |
| `<deprecated>` | ✅ keep | `deprecated` | |
| `<readonly>` | ✅ keep | `readonly` | |
| `<serialize>` | ✅ keep | `serialize` | |
| `<localizable>` | ✅ keep | `localizable` | |
| `<usage>` | ✅ keep | `usage` | |
| `<component>` | ✅ keep | `component` | Ok, but it smells bad to have columns belonging to one component in another component's table :nose: (fixme for another day) |
| `<localize_context>` | ✅ keep | `localize_context` | Obscure property only used by 3 fields, but it's easier to keep it. |
| `<type>` | ⚠️ rename | `sql_type` | |
| `<crmType>` | ⚠️ rename | `data_type` | Historically this was inferred by `<type>` but a few fields explicitly declare `<crmType>` |
| `<uniqueName>` | ⚠️ deprecate | `unique_name` | We can't get rid of it yet but we can discourage it & stop indexing by it at every layer except `DAO::fields()` |
| `<uniqueTitle>` | ⚠️ deprecate | `unique_title` | Are title & attributes[label] not enough? |
| `<comment>` | ⚠️ rename | `description` | |
| `<html>` | ⚠️ rename/reorganize | `attributes` | `type` gets moved out (see `<html><type>` below), while `length` gets moved in as `maxlength` |
| `<html><type>` | ⚠️ move/rename | `input_type` | |
| `<length>` | ⚠️ rename | `attributes[maxlength]` | That seems better. |
| `<import>` | ⚠️ move | `usage[import]` | |
| `<export>` | ⚠️ move | `usage[export]` | |
| `<foreignKey>` | ⚠️ move+reformat | `entity_reference` | This tag is outside of `<fields>` in the xml but doesn't need to be. Let's move it into the getFields array. |
| `<dynamicForeignKey>` | ⚠️ move+reformat | `entity_reference` | Conceptually the same as above so can share the same name. |
| `<permission>` | ⚠️ reformat | `permission` | Convert `<or>` tags to nested array format used by `CRM_Core_Permisison::check()`. |
| `<drop>` | ❌ remove | | `<drop>` designates a field has been dropped, but in that case let's just [remove it](https://github.com/civicrm/civicrm-core/pull/18244) from the array as nothing else was being done with it. |
| `<rule>` | ❌ remove | | Unused as of [PR#29611](https://github.com/civicrm/civicrm-core/pull/29611). |
| `<headerPattern>` | ❌ remove | | Unused as of [PR#29612](https://github.com/civicrm/civicrm-core/pull/29612). |
| `<dataPattern>` | ❌ remove | | Appears to be unused in `universe`. |
| `<fulltext/>` | ❌ remove | | Apparently unused. Ignored by GenCode when writing DAOs. |https://lab.civicrm.org/dev/core/-/issues/539Create a hook for custom relative date filters (CRM-16195)2024-03-25T15:18:49ZJonGoldCreate a hook for custom relative date filters (CRM-16195)To summarize: From the time relative date filters debuted in 4.2(?) until 4.7, each release added a number of relative date filters that one person needed and the rest of the world didn't. To prevent this happening forever, we moved rel...To summarize: From the time relative date filters debuted in 4.2(?) until 4.7, each release added a number of relative date filters that one person needed and the rest of the world didn't. To prevent this happening forever, we moved relative dates into an OptionGroup, and intended to give the ability to create new ones.
I worked on this last year but some cleanup PRs got stalled. They're all merged now so I'm submitting this.
While @eileen did work recently to support relative dates like "32 months in the past", it's still not possible to do relative dates like, "from 6 months ago to the end of this year", or "from Thanksgiving to Christmas". A former client of mine had reports that went from October to September, but this was NOT their fiscal year.
A simple hook facilitates the creation of custom relative date filters. I'll submit tests, but you can see an extension that uses it here: https://github.com/MegaphoneJon/com.megaphonetech.relativedatetest5.9JonGoldJonGoldhttps://lab.civicrm.org/dev/core/-/issues/5110afform: Display option "Remember Filters" not keeping value2024-03-25T15:01:10Zjensschuppeafform: Display option "Remember Filters" not keeping value## Overview
The display option "Remember Filters" in search displays does not retain its value when the configuration form is being reloaded.
## Reproduction steps
1. Create a _SearchKit_ search with a search form
2. Add a form displa...## Overview
The display option "Remember Filters" in search displays does not retain its value when the configuration form is being reloaded.
## Reproduction steps
1. Create a _SearchKit_ search with a search form
2. Add a form display (e.g. _Table_)
3. add some exposed filters
4. Check _Remember Filters_
5. Reload the configuration form for that form display
## Current behaviour
The option seems to be stored and filter values are being stored per user. The option field (checkbox) however is not set when reloading the config form of the form display. Saving the config form without changing that option still seems to retain its value (still storing filter values). So the config form does not reflect the actual option value.
## Expected behaviour
The option should be set when re-visiting the form display config form. Saving the form should respect the value (unchecked: unset the option).
## Environment information
* **Browser:** _Chromium 123.0.6312.58_
* **CiviCRM:** _5.71.0_https://lab.civicrm.org/dev/core/-/issues/3681Double down or remove use of empoweredBy in invoice template2024-03-25T05:03:20ZeileenDouble down or remove use of empoweredBy in invoice templateThe invoice template but exactly ZERO of the other templates adds the `empoweredBy` CiviCRM logo to the header.
As part of trying to consolidate template handling code I want to EITHER
- switch to using a token for the empoweredBy imag...The invoice template but exactly ZERO of the other templates adds the `empoweredBy` CiviCRM logo to the header.
As part of trying to consolidate template handling code I want to EITHER
- switch to using a token for the empoweredBy image OR
- remove it from the invoice template (on new installs- but in the long-term it might break on existing ones if I do that)
I feel an emoji poll coming on - go on - be Caesar - thumbs up it lives - thumbs down it dies (although death would be slow & gradual in this case)
Tangential issues
- invoice also uses an image-based horizonal line - I'm leaning towards making that a token `{formatting.line}` but that is for a separate issue
- this brings up a bunch of feature requests around what WOULD be useful in place of the empoweredBy. I did chat with Tim on that & will try to put it in another issuehttps://lab.civicrm.org/dev/core/-/issues/2975Drupal8/composer: upgrading do not move vendor files to the library folder2024-03-25T05:03:19ZcalbasiDrupal8/composer: upgrading do not move vendor files to the library folderOverview
----------------------------------------
I've upgraded from civicrm 5.36 to 5.43 using composer. I have no composer nor database errors but website menu, panels, etc. are not shown.
It seems some library files are missing on l...Overview
----------------------------------------
I've upgraded from civicrm 5.36 to 5.43 using composer. I have no composer nor database errors but website menu, panels, etc. are not shown.
It seems some library files are missing on libraries folder (but not at vendor folder). Copying some of them from vendor to library folder solves inspector errors...
Reproduction steps
----------------------------------------
1. Upgrade the code:
- composer update civicrm/civicrm-{core,packages,drupal-8} --with-dependencies
- update database
Current behaviour
----------------------------------------
Website don't load menu, panels, floating panels. Just the most basic info (html).
The inspector show errors (a couple of library files are missing)
```
The resource from “https://my_domain/libraries/civicrm/core/ang/resetLocationProviderHashPrefix.js?r=ZdPSJ” was blocked due to MIME type (“text/html”) mismatch (X-Content-Type-Options: nosniff).
The resource from “https://my_domain/libraries/civicrm/core/js/crm-angularjs-loader.js?r=ZdPSJ” was blocked due to MIME type (“text/html”) mismatch (X-Content-Type-Options: nosniff).
The resource from “https://my_domain/libraries/civicrm/core/ang/resetLocationProviderHashPrefix.js?r=ZdPSJ” was blocked due to MIME type (“text/html”) mismatch (X-Content-Type-Options: nosniff).
Loading failed for the <script> with source “https://my_domain/libraries/civicrm/core/ang/resetLocationProviderHashPrefix.js?r=ZdPSJ”.
The resource from “https://my_domain/libraries/civicrm/core/js/crm-angularjs-loader.js?r=ZdPSJ” was blocked due to MIME type (“text/html”) mismatch (X-Content-Type-Options: nosniff).
```
After copy the missing errors:
```
cp js/crm-angularjs-loader.js /var/www/my_website/web/web/libraries/civicrm/core/js/
cp resetLocationProviderHashPrefix.js /var/www/my_website/web/web/libraries/civicrm/core/ang/
```
I think the composer info is OK:
```
"extra": {
"installer-paths": {
"web/core": ["type:drupal-core"],
"web/libraries/{$name}": ["type:drupal-library"],
```
In fact, vendor/civicrm/civicrm-core has updated files, but not /libraries/civicrm/core
Environment information
----------------------------------------
* __CiviCRM:__ _5.43.2_ <!-- If this problem relates to an upgrade, then specify both old and new versions -->
* __OS:__ _Debian 10__
* __PHP:__ _7.3__
* __CMS:__ _Drupal 8 (updated version)..._
* __Database:__ _MariaDB_
* __Web Server:__ _Apache 2_https://lab.civicrm.org/dev/core/-/issues/2239Make submitting of A/B mailing atomic2024-03-24T05:03:29ZromainMake submitting of A/B mailing atomicThe [API function that submits A/B mailings](https://github.com/civicrm/civicrm-core/blob/master/api/v3/MailingAB.php#L100) performs the following actions:
1. submits mailing A (= set scheduled date to now)
2. submits mailing B
3. di...The [API function that submits A/B mailings](https://github.com/civicrm/civicrm-core/blob/master/api/v3/MailingAB.php#L100) performs the following actions:
1. submits mailing A (= set scheduled date to now)
2. submits mailing B
3. distribute recipients between A and B
4. set status of the A/B mailing from Draft to Testing, regardless of what happened in previous steps
I can see 3 problems in this code:
- Recipients distribution happens after submitting mailing. So if we are unlucky (i.e. if a mailing job picks up the mailings right at that moment) the mailing sender can start sending the mailings before the distribution has happened
- None of the steps checks whether the earlier steps reported any error
- The change is not atomic: if an error happens, there is no attempt to undo the earlier steps
These problems can have various consequences, from my experience:
- The submitting works but setting the status fails: the A/B mailing is being sent but this has status Draft. Opening it will display a report but it will not be possible to pick the Final
- The submitting fails but setting the status works: the A/B mailing is not sent but has status Testing. Opening it will display the composer but it will not be possible to submit the mailing.
- In any of the previous cases, if the distribution worked fine any attempt to send again the mailing without precaution will cause the distribution to happen again, which means that recipients of mailing A will be reset to whole target group and mailing B and C will receive due percentage of that group, **without removing the recipients they already got in previous submit**, hence duplicate sendings. That one can be even worse when the error is a deadlock, and the query is retried.
I *think* that making all 4 steps happen in a single DB transaction would solve all the problems I mention here.
Would that be a good approach? If so, does it make sense to put the whole function in a transaction regardless of the target status, or shall the function be re-organised a bit to have the status setting done in the case statement and make only the `Testing` use case atomic?
With those answers, I'm happy to work on a PR.https://lab.civicrm.org/dev/core/-/issues/3775Disable Deadlock retries for Mailing Jobs2024-03-24T05:03:28ZseamusleeDisable Deadlock retries for Mailing JobsSo CiviCRM added a feature which re-tries the same query x number of times by default that is 3 when either a deadlock or a lock wait timeout is hit which is useful, but in the concept of mailing job processing it is not so useful becaus...So CiviCRM added a feature which re-tries the same query x number of times by default that is 3 when either a deadlock or a lock wait timeout is hit which is useful, but in the concept of mailing job processing it is not so useful because it means it can get tied up on get_lock queries re-trying them a silly number of times when it should be moving onto the next thingseamusleeseamusleehttps://lab.civicrm.org/dev/core/-/issues/5108Inconsistent handling of tag name and tag label2024-03-23T14:15:54ZDetlev SieberInconsistent handling of tag name and tag label## Overview
When you change a tag in the tag tree, only the label is changed, the name remains the old entry. So after changing and reloading, in the tag tree the old entry is still shown - despite the previous change.
In the contact s...## Overview
When you change a tag in the tag tree, only the label is changed, the name remains the old entry. So after changing and reloading, in the tag tree the old entry is still shown - despite the previous change.
In the contact summary, the change is not reflected: Because there, the tag name is used, not the tag label. Which also seems, hmm..., interesting...
## Reproduction steps
1. Tag a contact with a specific tag from the tag tree
2. Click on **Contacts -\> Manage Tags**
3. Rename the previously selected tag
4. Reload the tag list -\> again, the old label/name is shown
5. Reload the contact from step 1.: -\> again, the old label/name is shown
## Current behaviour
Renaming the tag in the tag tree only changes the field civicrm_tag.label, not the field civicrm\_tag.name.
This "might" be what we want - however, on several occasions, the tag name is used instead of the tag name.
## Expected behaviour
I would recommend, that both name and label should be changed.
## Environment information
* **CiviCRM:** 5.69.5https://lab.civicrm.org/dev/core/-/issues/3787Issue with SQL import with > and < in the SQL query2024-03-23T05:03:32ZseamusleeIssue with SQL import with > and < in the SQL queryOverview
----------------------------------------
When using the SQL import datasource there is an issue in recent versions of CiviCRM due to the user job entity.
Reproduction steps
----------------------------------------
1. Create tab...Overview
----------------------------------------
When using the SQL import datasource there is an issue in recent versions of CiviCRM due to the user job entity.
Reproduction steps
----------------------------------------
1. Create table in database that contains at least a field called id and insert some rows, less than 15 would be enough
1. Ensure that your role has permission to use the SQL datasource
1. Click on **Contacts -> Import Contacts**.
1. Select SQL mode and enter an SQL like `SELECT * FROM <table name> WHERE id > 5 AND id <= 12`.
1. Got an error "**Fatal error: DB syntax error**".
Expected behaviour
----------------------------------------
Should be able to move onto the Field mapping stepps
Environment information
----------------------------------------
* __CiviCRM:__ _5.49.5_
Comments
----------------------------------------
It seems to be because we are getting the sqlQuery from the userJob entity as per https://github.com/civicrm/civicrm-core/blob/master/CRM/Import/DataSource/SQL.php#L85 and https://github.com/civicrm/civicrm-core/blob/master/CRM/Import/DataSource.php#L225 and that seems to have an html encoded value for < and > so the query includes > etc rather than > in it
ping @eileenhttps://lab.civicrm.org/dev/core/-/issues/3785participant field group sort order does not reflect configured order2024-03-23T05:03:29Zmagnolia61participant field group sort order does not reflect configured orderOverview
----------------------------------------
We have several custom field groups for participants.
Some for a specific event type, some others for specific participant roles
Current behaviour
---------------------------------------...Overview
----------------------------------------
We have several custom field groups for participants.
Some for a specific event type, some others for specific participant roles
Current behaviour
----------------------------------------
Currently the order in which the custom field groups are displayed while editing of viewing does not reflect the sort order that we selected in the custom field group settings. There is even a difference between viewing and editing a participant the one is ascending, the other descending.
Proposed behaviour
----------------------------------------
The sort order of the custom field groups for participants follows the selected order of the custom field groups. They are not groupes by selector (event type, role, etc), but follow the order that is configured.
Comments
----------------------------------------
I have no clue where to find this, and I'm not really a coder. Probably this is a very small change if you know where to look for.https://lab.civicrm.org/dev/core/-/issues/5057Make descriptions visible in drop down2024-03-22T18:22:38ZyashodhaMake descriptions visible in drop downAll the select2 drop-down are mostly option values which do have a description field in the database.
It will be useful to use this for display in select2 drop-downs.
We already show description for entities like events. It will be help...All the select2 drop-down are mostly option values which do have a description field in the database.
It will be useful to use this for display in select2 drop-downs.
We already show description for entities like events. It will be helpful to choose options for the user(if options do indeed explanation and are configured as such)https://lab.civicrm.org/dev/core/-/issues/5109Smarty 3 causes crash if exception thrown, e.g. by crmAPI2024-03-22T15:10:45ZRichSmarty 3 causes crash if exception thrown, e.g. by crmAPIOverview
----------------------------------------
I think this is a general problem that could occur if a smarty function throws an exception. The page crashes with:
> undefined extension class 'Smarty_Internal_Method_Trigger_Error'
[...Overview
----------------------------------------
I think this is a general problem that could occur if a smarty function throws an exception. The page crashes with:
> undefined extension class 'Smarty_Internal_Method_Trigger_Error'
[chat mention](https://chat.civicrm.org/civicrm/pl/gnqn1rihnprc7er1fcssqd1j6r)
Reproduction steps
----------------------------------------
I edited EventInfo.tpl to put this in:
```
{crmAPI var='local_date_time' entity='Event' action='getvalue' return="custom_115" id=$event.id}
```
Note that I had a custom_115 field defined for all events, but this event did not have a value for that field.
Visit the page that uses that template.
Crash.
Environment information
----------------------------------------
* __CiviCRM:__ 5.70 - 5.71.1
* __PHP:__ 8.1
* __CMS:__ D7
Comments
----------------------------------------
I'm not sure, but from memory api3 getvalue has changed; it now gives an *error* saying:
> "error_message": "field custom_115 unset or not existing"
I'm sure before it just used to return nothing.
Or it could be that before Smarty 3, it was happy to treat nothing as '' and now it's more picky.
I think the main problem seems to be that the exception/error handling is broken in Smarty3. Obviously if there's a bug in the template, it's going not to work, but it oughtn't crash the whole page.
The code that throws the error that causes the crash is CRM/Core/Smarty/plugins/function.crmAPI.php L35:
$smarty->trigger_error('{crmAPI} ' . $e->getMessage());https://lab.civicrm.org/dev/core/-/issues/5100Payment appears as 123 units of $1 rather than one unit of $123 if using othe...2024-03-22T14:38:36ZwmortadaPayment appears as 123 units of $1 rather than one unit of $123 if using other amount fieldOverview
----------------------------------------
This appears to be a regression in CiviCRM 5.69 upwards. If you create a contribution pages that allows other amounts the amount in that field is recorded in the quantity field of the li...Overview
----------------------------------------
This appears to be a regression in CiviCRM 5.69 upwards. If you create a contribution pages that allows other amounts the amount in that field is recorded in the quantity field of the line item rather than the unit price.
It looks like the quantity and the unit price have been swapped.
Reproduction steps
----------------------------------------
1. Create a contribution page with the other amounts section enabled
2. Visit the contribution page and type an amount in 'Other amount' field
3. View the contact record - note that the quantity is the amount and the unit price is 1.00
![image](/uploads/c16ed4be20e97bb2f86d63d5842d481e/image.png)
![image](/uploads/2e27e1f53dfca423a63ef4d98a5f0042/image.png)
![image](/uploads/85840162f1fc088ddcd6de5c7565ea5d/image.png)
Current behaviour
----------------------------------------
The amount is recorded in the quantity field. The unit price is $1.00.
Expected behaviour
----------------------------------------
The quantity is 1. The amount is recorded in the unit price field.
Environment information
----------------------------------------
Tested in CiviCRM 5.69, 5.70 and 5.73alpha1 (current dmaster). It is an issue in all three versions.
I'm not sure when this stopped working, but think it is quite recent.5.71.2https://lab.civicrm.org/dev/core/-/issues/3833PHP 8.2 Dynamic Properties are deprecated2024-03-22T12:22:59ZBradley TaylorPHP 8.2 Dynamic Properties are deprecatedSee https://wiki.php.net/rfc/deprecate_dynamic_properties.
I see this as a big one, which could require a significant number of fixes for CiviCRM. The RFC has a good example showing what has changed:
```
class User {
public $name;
...See https://wiki.php.net/rfc/deprecate_dynamic_properties.
I see this as a big one, which could require a significant number of fixes for CiviCRM. The RFC has a good example showing what has changed:
```
class User {
public $name;
}
$user = new User;
// Assigns declared property User::$name.
$user->name = "foo";
// Oops, a typo:
$user->nane = "foo";
// PHP <= 8.1: Silently creates dynamic $user->nane property.
// PHP 8.2: Raises deprecation warning, still creates dynamic property.
// PHP 9.0: Throws Error exception.
```
There are many uses of dynamic properties in CiviCRM core which fall into multiple categories:
1. Known undeclared properties. For example `CRM_Activity_Form_Task_Batch` repeatedly references `$_fields` which should just be defined.
2. Dynamic properties. The main example of this is `CRM_Core_DAO`. PHP allows for this use-case by either extending `stdClass` or using the new ` #[AllowDynamicProperties]` attribute. Where possible we should prefer extending `stdClass` which is likely to have better long-term support (i.e. into the PHP 9.x series)
3. Typo's etc. Cases where the property is defined, but later referenced with a different name. These are easy; we just fix the typo (whilst ensuring we don't break any backwards compatiability for plugins using the wrong spelling)
I suggest CiviCRM developers should start to be made aware of this now, to avoid making the problem worse. Incrementally starting to fix the issue, a class or two at a time, seems like a good idea.
In many cases it's not clear why dynamic properties (or declared properties for that matter) are being used instead of a standard variable. This might be a good chance to start annotating properties as either:
- `@api`; designed to be used within hooks, on singletons etc by CiviCRM extensions
- `@internal`; not designed to be used by extensions, and liable to be removed without deprecation.