Development issueshttps://lab.civicrm.org/groups/dev/-/issues2022-03-19T14:06:02Zhttps://lab.civicrm.org/dev/core/-/issues/3004Consider removing the font-size12pt, font-size11pt classes2022-03-19T14:06:02ZBradley TaylorConsider removing the font-size12pt, font-size11pt classes`civicrm.css` contains the following CSS:
```
.crm-container .font-size11pt {
font-size: 1.1em;
}
.crm-container .font-size12pt {
font-size: 1.2em;
}
```
These are used, but rarely and inconsistently, throughout the CiviCRM codeba...`civicrm.css` contains the following CSS:
```
.crm-container .font-size11pt {
font-size: 1.1em;
}
.crm-container .font-size12pt {
font-size: 1.2em;
}
```
These are used, but rarely and inconsistently, throughout the CiviCRM codebase. I see the following issues with these classes:
- These classes are used inconsistently, and I can't imendiately see what the rules are that decided their use.
- Then these classes are used, just the font-size is adjusted, which can lead to the area around that label appearing cramped.
- Using font-size alone to pull attention to a label is fairly lazy design, and can look like a UI mistake rather than a feature.
- These classes are treated inconsistently in different CiviCRM themes.
- These class names are not semantic, and also are not strictly accurate given we're using `em` not `pt`.
I've looked through the Git hsitory and I can only find one occurance of someone having used one of these classes since the migration from SVN 9 years ago. So I suspect I'm not the only one unsure when and why these classes should be used!
Therefore I'd like to propose that these two classes, along with any references to them, are removed.https://lab.civicrm.org/dev/backdrop/-/issues/4Class civicrm_plugin_argument_default_civicrm_id not loaded2021-12-22T21:39:08ZherbdoolClass civicrm_plugin_argument_default_civicrm_id not loadedNeed to put `civicrm_plugin_argument_default_civicrm_id` in `hook_autoload_info`.Need to put `civicrm_plugin_argument_default_civicrm_id` in `hook_autoload_info`.https://lab.civicrm.org/dev/drupal/-/issues/172Deprecated function drupal_get_installed_schema_version() in 9.3, but with a ...2022-01-02T15:47:07ZDaveDDeprecated function drupal_get_installed_schema_version() in 9.3, but with a twistdrupal_get_installed_schema_version() is deprecated in drupal:9.3.0 and is removed from drupal:10.0.0. Use \Drupal\Core\Update\UpdateHookRegistry::getInstalledVersion() or \Drupal\Core\Update\UpdateHookRegistry::getAllInstalledVersions()...drupal_get_installed_schema_version() is deprecated in drupal:9.3.0 and is removed from drupal:10.0.0. Use \Drupal\Core\Update\UpdateHookRegistry::getInstalledVersion() or \Drupal\Core\Update\UpdateHookRegistry::getAllInstalledVersions() instead. See https://www.drupal.org/node/2444417
This is in vendor\civicrm\civicrm-core\CRM/Utils/System/Drupal8.php:
```
public function getModules() {
$modules = [];
$module_data = \Drupal::service('extension.list.module')->reset()->getList();
foreach ($module_data as $module_name => $extension) {
if (!isset($extension->info['hidden']) && $extension->origin != 'core') {
$extension->schema_version = drupal_get_installed_schema_version($module_name);
$modules[] = new CRM_Core_Module('drupal.' . $module_name, ($extension->status == 1));
}
}
return $modules;
}
```
The reason I haven't just put up a simple replacement PR is because if you look at the above function you'll notice schema_version is never used. If you look at the docblock in Base.php it says "List modules installed in the CMS, _including enabled and disabled ones_." Looking at the drupal 7 version (in DrupalBase.php), it does this:
`'SELECT name, status FROM {system} WHERE type = \'module\' AND schema_version <> -1'`
which means only the modules that are installed (but possibly disabled - that's what status is). Now in drupal 8 there is no concept of disabled, it's either installed or uninstalled, but the drupal 8 code is including all of them. In drupal 8 $extension->status means installed or uninstalled.
So two options are:
1. Try to match the drupal 7 implementation/docblock, which means excluding it if $extension->status is 0, and always passing 1 as the second parameter to CRM_Core_Module(), because disabled doesn't mean anything in drupal 8.
2. Leave it the way it is and just remove the unused line about schema_version.
Trying to track down where this gets used, it seems it's mostly in ManagedEntities, which I usually stay away from, and I'm not even sure why ManagedEntities would be dealing with drupal modules other than civicrm itself.
So I'm tempted to stop thinking about it and do item 2.5.46.0https://lab.civicrm.org/dev/core/-/issues/3001Escape single quotes in token html output2022-03-17T23:12:32ZeileenEscape single quotes in token html outputWhen rendering message templates with tokens it is reasonable to do something like
```
{if '{contact.last_name}'}
Dear {contact.prefix_id:label} {contact.last_name}
{else}
Dear {contact.first_name}
{/if}
```
However, this breaks if...When rendering message templates with tokens it is reasonable to do something like
```
{if '{contact.last_name}'}
Dear {contact.prefix_id:label} {contact.last_name}
{else}
Dear {contact.first_name}
{/if}
```
However, this breaks if the name is "O'Reily" as the single quote breaks the string.
There are 2 aspects to this
1) when the token is being rendered in html the text is being parsed through [htmlentities](https://www.php.net/manual/en/function.htmlentities.php). We are doing this without specifying any flags - so we fall back to ENT_COMPAT - switching to ENT_QUOTES solves this in the context of html tokens and I think it's probably more correct and more secure. I'm going to put [up a patch for that](https://github.com/civicrm/civicrm-core/pull/22285).
![image](/uploads/eda8db04ea8db39b46f7f6894d50425d/image.png)
2) when the token is being rendered in text the raw result is returned - I'm not quite sure the best approach here. Our principle of using smarty-like escaping would suggest we should support something like
``{$articleTitle|escape:'quotes'}``https://lab.civicrm.org/dev/core/-/issues/3000Can't save a shared address twice when you have custom address fields2021-12-25T19:34:53ZJonGoldCan't save a shared address twice when you have custom address fieldsThis is a regression from https://github.com/civicrm/civicrm-core/pull/21313, which is in Civi 5.42+.
### Steps to replicate
* Create an address custom field (it may have to be a certain type; it happens with alphanumeric select-autocom...This is a regression from https://github.com/civicrm/civicrm-core/pull/21313, which is in Civi 5.42+.
### Steps to replicate
* Create an address custom field (it may have to be a certain type; it happens with alphanumeric select-autocomplete for sure).
* Create or re-save an address on a contact (to create its custom field record).
* On a second contact, share the address from the first contact and save.
* Edit the address on the second contact and save.
### Expected result
Saves successfully.
### Actual result
`"DB Error: already exists"`
### Comments
The `entity_id` on a custom value field must be unique, but the PR mentioned above forces an `INSERT` when copying the custom fields of the original address.5.45.0https://lab.civicrm.org/dev/core/-/issues/2999Get API Error: "invalid string" if param value contains `select` string in it2023-11-02T11:36:40ZjitendraGet API Error: "invalid string" if param value contains `select` string in itTo replicate execute the following apis.
```
civicrm_api3('Contact', 'get', ['display_name' => 'selecton person name']);
```
or
```
civicrm_api3('Contribution', 'get', [
'sequential' => 1,
'source' => "xxxxselect xxxx",
]);
```
...To replicate execute the following apis.
```
civicrm_api3('Contact', 'get', ['display_name' => 'selecton person name']);
```
or
```
civicrm_api3('Contribution', 'get', [
'sequential' => 1,
'source' => "xxxxselect xxxx",
]);
```
or any other entity with `select` string in the param value.
The problematic part is https://github.com/civicrm/civicrm-core/blob/master/api/v3/utils.php#L884-L886, which results into an error if param value contains `select` string in it.
Seems to be present in core from a long time. Why is input params considered as an invalid string for SELECT? Is it to avoid any SQL queries in the params? If yes, probably we can replace it with a more valid check? eg an existence of select, from, etc?https://lab.civicrm.org/dev/core/-/issues/2997Search Builder (not Search Kit): groups not searched correctly2023-11-01T05:03:24Zaydunsaidan.saunders@squiffle.ukSearch Builder (not Search Kit): groups not searched correctlyOverview
----------------------------------------
In Search Builder, searching for both 'in group' and 'not in group' produces incorrect results.
As [reported in SE](https://civicrm.stackexchange.com/questions/40893/search-builder-fails...Overview
----------------------------------------
In Search Builder, searching for both 'in group' and 'not in group' produces incorrect results.
As [reported in SE](https://civicrm.stackexchange.com/questions/40893/search-builder-fails-in-group-and-not-in-group-search).
![Screenshot_from_2021-12-17_11-18-41](/uploads/10a879d4a29aa0ec727f2ff47c1527e2/Screenshot_from_2021-12-17_11-18-41.png)
NB: this is handled correctly in Search Kit and I doubt anyone will want to put effort into fixing this in Search Builder.
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:__ _Master (5.46.alpha1)_ <!-- If this problem relates to an upgrade, then specify both old and new versions -->https://lab.civicrm.org/dev/core/-/issues/2996Increment recommended php version2021-12-20T20:30:34ZeileenIncrement recommended php versionPHP has just EOLed php 7.3 https://www.php.net/eol.php
We are just about to release the 5.45 ESR and we could take the opportunity to drop support for older php & mysql ie drop support for php 7.2 & mysql 5.6
The gut check in informal ...PHP has just EOLed php 7.3 https://www.php.net/eol.php
We are just about to release the 5.45 ESR and we could take the opportunity to drop support for older php & mysql ie drop support for php 7.2 & mysql 5.6
The gut check in informal discussion was to leave that for the next ESR and instead just increase our recommended versions.
While we support php 8.0 if has pretty low usage at the moment - so 7.4 seemed like the right pick
https://github.com/civicrm/civicrm-core/pull/222655.46.0https://lab.civicrm.org/dev/core/-/issues/2995From Email Address Options Bug2023-11-27T05:03:22ZLKuttnerFrom Email Address Options BugWhen sending some emails, such as using CiviRules and the MailAPI extension, the display name of the specified from email address option is being read from the non-ui editable Name column, while the email address is read from the Label c...When sending some emails, such as using CiviRules and the MailAPI extension, the display name of the specified from email address option is being read from the non-ui editable Name column, while the email address is read from the Label column. This results email being sent with the display name of FIXME when using the from email address that was created during the initial CiviCRM set-up. The Name of the first created email address is "FIXME" <info@example.com"> and is not editable via the user interface. This record can be updated by editing option_group_id 31 value 1 in the database.https://lab.civicrm.org/dev/core/-/issues/2993Add option to delete old log files during rotation2023-11-02T05:03:25ZJoeMurrayAdd option to delete old log files during rotationOverview
----------------------------------------
_When creating a new log file, optionally remove old ones like logrotate allows (https://linux.die.net/man/8/logrotate)._
Example use-case
----------------------------------------
CiviCR...Overview
----------------------------------------
_When creating a new log file, optionally remove old ones like logrotate allows (https://linux.die.net/man/8/logrotate)._
Example use-case
----------------------------------------
CiviCRM's simplistic log creation does not actually rotate, it just makes more files for the logs and never deletes any (https://github.com/civicrm/civicrm-core/blob/5433c81f5648bf484ef16debeca3c7e6e98d1a11/CRM/Core/Error.php#L684). This can be dangerous for systems where there is little to no active monitoring of logs, eg small orgs without a provider, or on a shoestring budget. It is also dangerous in cases where a change starts to generate high volumes of error messages, eg a client recently misconfigured a civirule and GBs of log were produced every hour. Running out of disk space causes hard crashes of sites.
It is standard practice to have a process in place to ensure that logs do not end up taking too much disk space. We propose allowing a setting to be added to civicrm.settings.php (eg NUM_LOG_FILES_TO_RETAIN) that would allow the number of logs to be retained to be specified. The default setting would be 0, meaning an infinite number, which would retain current behaviour. We would also be happy to make it another number such as 6, which would be 6 months or more than 1.5GB.
My understanding is that settings that can be added to civicrm.settings.php should be included as comments with explanation that can be uncommented, so we will do this.
Current behaviour
----------------------------------------
_CiviCRM generates log files with random hash names, and creates new ones every month or when the file exceeds 256MB. Log file space grows continuously unless log files are manually deleted._
Proposed behaviour
----------------------------------------
_When a new log file is created, if a maximum number of log files has been specified, then delete those over that number, starting with oldest first_
Comments
----------------------------------------
_To reduce the complexity of the settings pages, we propose that this be implemented as a setting that could be optionally specified in civicrm.settings.php._Monish DebMonish Debhttps://lab.civicrm.org/dev/core/-/issues/2992cancelling preApproval payment and continue with credit card does not work.2023-11-21T05:03:16Zsunilcancelling preApproval payment and continue with credit card does not work.Overview
----------------------------------------
This issue related to preApproval payment. its present on Contribution and Event registartion form.
E.g Paypal Express.
Reproduction steps
----------------------------------------
1. Se...Overview
----------------------------------------
This issue related to preApproval payment. its present on Contribution and Event registartion form.
E.g Paypal Express.
Reproduction steps
----------------------------------------
1. Set up Paypal Pro account (live and test mode).
1. The configure Processor on Contribution page.
1. Visit online page (live or test mode).
1. Select amount and click on Paypal Button
1. It redirct you to login page, there is link to cancel the process,link look like this
`http://drupal7.test/civicrm/contribute/transact?_qf_Main_display=1&qfKey=CRMContributeControllerContribution67xqxb55jcow0k0gcs8sc8c4cs0c4sc00s4gcwg0skg84ws840_7945&cancel=1&token=EC-1V540554M6477413R` . Click on it. It redirect you to main page.
1. Now this time do the transaction using credit card.
1. Once you reach to CiviCRM confirm page and click to pay amount. You will get the error like this
`Payment Processor Error message :Express Checkout PayerID is missing.`
In Case of event registration, we were not passing qfkye to cancel url. when we cancel the payment on paypal express login page.. we are getting `Could not find valid value for id` Error.
After correcting the cancel url we need to apply same changes to reset `preApproval` data to continue payment with other method without resetting the page.https://lab.civicrm.org/dev/drupal/-/issues/171Drupal 10 requires Guzzle 72022-07-10T15:27:07ZDaveDDrupal 10 requires Guzzle 7It doesn't seem like there is any major change but I'm not super-familiar with everywhere civi uses guzzle: https://github.com/guzzle/guzzle/blob/master/UPGRADING.md#other-backwards-compatibility-breaking-changes
The main thing at the m...It doesn't seem like there is any major change but I'm not super-familiar with everywhere civi uses guzzle: https://github.com/guzzle/guzzle/blob/master/UPGRADING.md#other-backwards-compatibility-breaking-changes
The main thing at the moment is you need to do something like `composer require guzzlehttp/guzzle:"6.3.0 as 7.4.0"` just to get the civi files downloaded, but that's obviously not the right thing to do.5.52.0https://lab.civicrm.org/dev/core/-/issues/2989Import of contribution fails when invalid campaign id is provided2022-02-01T23:27:10ZKurund JalmiImport of contribution fails when invalid campaign id is providedCurrently, we do not validate campaign id hence contribution import silently fails to import.Currently, we do not validate campaign id hence contribution import silently fails to import.5.47.0https://lab.civicrm.org/dev/core/-/issues/2988Civi Scss compliler is autoloaded, and its (old) verion conflict with more re...2023-10-30T05:03:24ZjbonlineaCivi Scss compliler is autoloaded, and its (old) verion conflict with more recent ones causing fatail errorsHi there,
It seems there is a issue / conflict between CiviCRM Scss compiler and my wordpress theme (gantry 5) Scss compiler.
We've discussed it [here](https://chat.civicrm.org/civicrm/pl/mfsmpmhewjyd7p7srbe1h9cyfa) where I've linked w...Hi there,
It seems there is a issue / conflict between CiviCRM Scss compiler and my wordpress theme (gantry 5) Scss compiler.
We've discussed it [here](https://chat.civicrm.org/civicrm/pl/mfsmpmhewjyd7p7srbe1h9cyfa) where I've linked what put me on track to think is was due to Civi Scss compiler.
A workaround is to rename the folder `civicrm/civicrm/vendor/scssphp`
Let me know if you want more detail
Cheers
PHP 7.4
WP 5.8.2
Civi 5.40.2
Gantry 5.5.6 (theme I use that also bundle an scss compiler, but there are many others)https://lab.civicrm.org/dev/wordpress/-/issues/116Issue related to Civi and WP Scss compiler causing fatal error2021-12-09T15:17:29ZjbonlineaIssue related to Civi and WP Scss compiler causing fatal errorHi there,
It seems there is a issue / conflict between CiviCRM Scss compiler and my wordpress theme (gantry 5) Scss compiler.
We've discussed it [here](https://chat.civicrm.org/civicrm/pl/mfsmpmhewjyd7p7srbe1h9cyfa) where I've linked w...Hi there,
It seems there is a issue / conflict between CiviCRM Scss compiler and my wordpress theme (gantry 5) Scss compiler.
We've discussed it [here](https://chat.civicrm.org/civicrm/pl/mfsmpmhewjyd7p7srbe1h9cyfa) where I've linked what put me on track to think is was due to Civi Scss compiler.
A workaround is to rename the folder `civicrm/civicrm/vendor/scssphp`
Let me know if you want more detail
Cheers
PHP 7.4
WP 5.8.2
Civi 5.40.2
Gantry 5.5.6 (theme I use that also bundle an scss compiler, but there are many others)https://lab.civicrm.org/dev/core/-/issues/2986PCP: Account creation profile does not support contact image2023-10-28T05:03:27ZKurund JalmiPCP: Account creation profile does not support contact image## Steps to replicate
* Create a profile with contact image field (Image URL)
* Include this profile as a part of PCP account creation process
* Contact image is never uploaded.## Steps to replicate
* Create a profile with contact image field (Image URL)
* Include this profile as a part of PCP account creation process
* Contact image is never uploaded.https://lab.civicrm.org/dev/core/-/issues/2985Original value is displayed after setting custom event field blank2023-01-21T04:07:10ZBobSOriginal value is displayed after setting custom event field blankOverview
----------------------------------------
Attempting to change the value of a custom event field from non-blank to blank results in the original value being populated in the form after the form is saved. If the form is subsequent...Overview
----------------------------------------
Attempting to change the value of a custom event field from non-blank to blank results in the original value being populated in the form after the form is saved. If the form is subsequently saved again, then the original non-blank value is written to the DB.
Reproduction steps
----------------------------------------
1. Create a custom event fieldset.
1. Add a custom field of type Alphanumeric, Single line input field. Accept all default settings.
1. Edit an event.
1. Set the new custom field to a non-blank value and save the event.
1. Set the new custom field to a blank value and save the event.
Current behaviour
----------------------------------------
The custom field displays the non-blank value. If the form is saved, the blank value currently in the DB is overwritten with the non-blank value.
Expected behaviour
----------------------------------------
The custom field should display the last saved value: blank.
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:__ Chrome Version 96.0
* __CiviCRM:__ _5.45.alpha1_ <!-- If this problem relates to an upgrade, then specify both old and new versions -->
* __PHP:__ _7.4_
* __CMS:__ _Drupal 7.82_
* __Database:__ _MariaDB 10.4_
* __Web Server:__ _Apache 2.4_
Comments
----------------------------------------
Confirmed on dmaster.demo.civicrm.org5.59.0https://lab.civicrm.org/dev/core/-/issues/2984APIv4: Confusing error when calling CaseType API2021-12-09T21:08:05ZtottenAPIv4: Confusing error when calling CaseType APIOverview
----------------------------------------
`CaseType.get` API has a confusing disposition.
Reproduction steps
----------------------------------------
1. Disable CiviCase
1. Call `cv api4 CaseType.get`
Current behavior
--------...Overview
----------------------------------------
`CaseType.get` API has a confusing disposition.
Reproduction steps
----------------------------------------
1. Disable CiviCase
1. Call `cv api4 CaseType.get`
Current behavior
----------------------------------------
The call to `CaseType.get` begins executing - but it fails in the middle of query-building.
```
cv api4 CaseType.get -v
Entity: CaseType
Action: get
Params: {
"version": 4,
"checkPermissions": false
}
[Symfony\Component\Debug\Exception\FatalThrowableError]
Type error: array_merge(): Argument #1 must be of type array, null given
Exception trace:
() at /home/m/bknix/build/tmp/web/sites/all/modules/civicrm/Civi/Api4/Query/Api4SelectQuery.php:223
array_merge() at /home/m/bknix/build/tmp/web/sites/all/modules/civicrm/Civi/Api4/Query/Api4SelectQuery.php:223
Civi\Api4\Query\Api4SelectQuery->buildSelectClause() at /home/m/bknix/build/tmp/web/sites/all/modules/civicrm/Civi/Api4/Query/Api4SelectQuery.php:149
Civi\Api4\Query\Api4SelectQuery->getSql() at /home/m/bknix/build/tmp/web/sites/all/modules/civicrm/Civi/Api4/Query/Api4SelectQuery.php:165
Civi\Api4\Query\Api4SelectQuery->run() at /home/m/bknix/build/tmp/web/sites/all/modules/civicrm/Civi/Api4/Generic/DAOGetAction.php:111
Civi\Api4\Generic\DAOGetAction->getObjects() at /home/m/bknix/build/tmp/web/sites/all/modules/civicrm/Civi/Api4/Generic/DAOGetAction.php:99
Civi\Api4\Generic\DAOGetAction->_run() at /home/m/bknix/build/tmp/web/sites/all/modules/civicrm/Civi/Api4/Provider/ActionObjectProvider.php:68
Civi\Api4\Provider\ActionObjectProvider->invoke() at /home/m/bknix/build/tmp/web/sites/all/modules/civicrm/Civi/API/Kernel.php:149
Civi\API\Kernel->runRequest() at /home/m/bknix/build/tmp/web/sites/all/modules/civicrm/Civi/Api4/Generic/AbstractAction.php:234
Civi\Api4\Generic\AbstractAction->execute() at /home/m/bknix/build/tmp/web/sites/all/modules/civicrm/api/api.php:85
civicrm_api4() at phar:///home/m/bknix/bin/cv/src/Command/Api4Command.php:145
Civi\Cv\Command\Api4Command->execute() at phar:///home/m/bknix/bin/cv/vendor/symfony/console/Command/Command.php:257
Symfony\Component\Console\Command\Command->run() at phar:///home/m/bknix/bin/cv/vendor/symfony/console/Application.php:850
Symfony\Component\Console\Application->doRunCommand() at phar:///home/m/bknix/bin/cv/vendor/symfony/console/Application.php:193
Symfony\Component\Console\Application->doRun() at phar:///home/m/bknix/bin/cv/src/Application.php:46
Civi\Cv\Application->doRun() at phar:///home/m/bknix/bin/cv/vendor/symfony/console/Application.php:124
Symfony\Component\Console\Application->run() at phar:///home/m/bknix/bin/cv/src/Application.php:15
Civi\Cv\Application::main() at phar:///home/m/bknix/bin/cv/bin/cv:27
require() at /home/m/bknix/bin/cv:14
```
Expected behavior
----------------------------------------
Either:
* Allow `CaseType` API calls to work. Return the list of case types.
* OR... Disallow `CaseType` API calls. Give a clear error; eg
* `CaseType.get API is unavailable.`
* `Cannot process request. CiviCase is disabled.`https://lab.civicrm.org/dev/core/-/issues/2983On "My Contact Dashboard", what is the Manage Case link in the relationships ...2024-02-26T05:03:22ZDaveDOn "My Contact Dashboard", what is the Manage Case link in the relationships section supposed to do?At civicrm/user, in the relationships section, if you have a relationship to a case there's a link under More at the right that says Manage Case. But clicking it does nothing. Also there's an error on the page because it's trying to crea...At civicrm/user, in the relationships section, if you have a relationship to a case there's a link under More at the right that says Manage Case. But clicking it does nothing. Also there's an error on the page because it's trying to create the link as CRM_Core_Action::NONE but there is no offset 0 in the $links array, but I'm not sure if that's the full reason it fails.
It looks like it's supposed to do a popup-y version of manage case? Except it looks like the link if it were working would be e.g. civicrm/case/ajax/details?caseId=1&cid=3&snippet=4, which just gives a little table.
I'm just wondering if it's worth trying to fix or to just remove it. I have no idea when it broke - never even knew it existed.https://lab.civicrm.org/dev/core/-/issues/2982Repeat Contributions CiviReport warnings: Formatting non-numeric values is no...2021-12-09T00:48:06ZDaveDRepeat Contributions CiviReport warnings: Formatting non-numeric values is no longer supportedWhole screen fills with ones like this:
`User deprecated function: Formatting non-numeric values is no longer supported: 100.00 (2) Caller: CRM_Utils_Money::format in CRM_Core_Error::deprecatedWarning() (line 1060 of /srv/buildkit/build...Whole screen fills with ones like this:
`User deprecated function: Formatting non-numeric values is no longer supported: 100.00 (2) Caller: CRM_Utils_Money::format in CRM_Core_Error::deprecatedWarning() (line 1060 of /srv/buildkit/build/dmaster/web/sites/all/modules/civicrm/CRM/Core/Error.php).`
It must be the `(2)` part it doesn't like. Perhaps that repeat count should be its own column.
It's also showing `<br/>` in the column heading, which I assume is from the recent smarty escaping PRs.5.46.0