Development issueshttps://lab.civicrm.org/groups/dev/-/issues2022-11-30T08:39:02Zhttps://lab.civicrm.org/dev/core/-/issues/4011Formbuilder: Error in date selection of grouped activities2022-11-30T08:39:02ZjmargrafFormbuilder: Error in date selection of grouped activitiesOverview
----------------------------------------
The data range picker of the Formbuilder does not work for Activities grouped by acitivity_type.
It should show the sum of activities per activity_type in a defined data range.
Instead th...Overview
----------------------------------------
The data range picker of the Formbuilder does not work for Activities grouped by acitivity_type.
It should show the sum of activities per activity_type in a defined data range.
Instead the result always shows the total sum of activities per activitiy_type - no matter what date range i select.
Reproduction steps
----------------------------------------
1. create a new Packaged Search with Searchkit. [saved-search.txt](/uploads/ecc2154067e2c15e2993679fd645ff54/saved-search.txt) with the following API Query Info:
```
{
"version": 4,
"select": [
"COUNT(subject) AS COUNT_subject",
"activity_type_id:label"
],
"orderBy": [],
"where": [],
"groupBy": [
"activity_type_id"
],
"join": [],
"having": []
}
```
2. Create an Table to view the Saved Search in a Table
3. Create a new Search Form with Formbuilder using this Saved Search Table
```
<div af-fieldset="">
<af-field name="activity_date_time" defn="{input_type: 'Select', search_range: true, input_attrs: {}}" />
<crm-search-display-table search-name="debug_activity" display-name=""></crm-search-display-table>
</div>
```
4. Add the date picker "date of the activity"
5. Use the Formbuilder and search for grouped data in a certain time range
Current behaviour
----------------------------------------
`COUNT_subject` does always show the same sum, no matter what date selection i choose
![data-range-2](/uploads/7612612fbe53450efee51373fa9f6000/data-range-2.png)
![issue-data-range-no-selection](/uploads/9dd3650f48840c5e1405db15433003c5/issue-data-range-no-selection.png)
![issue-data-range](/uploads/840e2efea6d12f4a6baf15b55bddf833/issue-data-range.png)
Expected behaviour
----------------------------------------
`COUNT_subject` should show the number of activities of a certain actitity_type in the defined data range.
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:__ _Firefox 107.0
* __CiviCRM:__ 5.50.4
* __PHP:__ 7.4.33
* __CMS:__ Drupal 9.4.8
* __Database:__ MySQL 5.7.7/MariaDB 10.4/..._
* __Web Server:__ _Apache 2.4/Nginx 1.16/..._
Comments
----------------------------------------
_Anything else you would like the reviewer to note._https://lab.civicrm.org/dev/core/-/issues/4010Proposal: SearchKit add optional labels to joins2022-11-30T08:39:20Zaydunsaidan.saunders@squiffle.ukProposal: SearchKit add optional labels to joinsOverview
----------------------------------------
Proposal: Add an optional label after a 'With' and use that in the Add dropdown. For Calculated Fields, this might another element in `FieldSpec`
Rationale
----------
1. If you add the...Overview
----------------------------------------
Proposal: Add an optional label after a 'With' and use that in the Add dropdown. For Calculated Fields, this might another element in `FieldSpec`
Rationale
----------
1. If you add the same entity multiple times you get eg:
![image](/uploads/c4a12ab363c6fae415a8028ad2575797/image.png)
with an Add dropdown of:
![image](/uploads/c09359051f68512ebf1f992c1f42fb60/image.png)
'Contact Contributions' and 'Contact Contributions 2' would be easier to use if you could add an optional label 'Completed contributions', 'Cancelled contributions', and then have those appear in the dropdown instead.
2. If you have several layers of joins, the titles get unwieldy. Those can be replaced by shorter, more meaningful labels.https://lab.civicrm.org/dev/core/-/issues/4009Proposal: SearchKit show Calculated Field entity refs as joins2022-11-30T08:39:36Zaydunsaidan.saunders@squiffle.ukProposal: SearchKit show Calculated Field entity refs as joinsOverview
----------------------------------------
If you join an entity using 'With' then it appears in the 'Add' dropdown as an expandable entity: - see 'Contact Contributions' in this image:
![image](/uploads/78451866fa4f155fb32594879e...Overview
----------------------------------------
If you join an entity using 'With' then it appears in the 'Add' dropdown as an expandable entity: - see 'Contact Contributions' in this image:
![image](/uploads/78451866fa4f155fb32594879efb754d/image.png)
However entities that are joined via Calculated Fields show differently so we get fields like 'Address (billing) Country' rather than a dropdown for Address providing access to all the address fields.
With the recently merged https://github.com/civicrm/civicrm-core/pull/25056, the `master_id` field appears in the list but none of its fields.
So can we make those entities show in the same way as those joined via 'With' ? (APIv4 Explorer does this).https://lab.civicrm.org/dev/core/-/issues/4007Proposal: SearchKit Templates2022-12-05T23:15:19ZcolemanwProposal: SearchKit TemplatesBackground
-------------
Olly is working on a new Extension called [SearchKit Reports](https://lab.civicrm.org/extensions/search_kit_reports) which is a collection of SavedSearches. The idea is to reproduce most of CiviReport using Searc...Background
-------------
Olly is working on a new Extension called [SearchKit Reports](https://lab.civicrm.org/extensions/search_kit_reports) which is a collection of SavedSearches. The idea is to reproduce most of CiviReport using SearchKit, and people can then use those packaged searches to get a jump-start on building their own searches.
Since these searches are intended to be used as templates, why not actually make them templates.
Rationale
-------------
I think this would benefit the SK UI because because so far, the "Packaged Searches" tab contains stuff the average user shouldn't mess with unless they know what they're doing; searches like "Administer Custom Fields" provide critical functionality to various CiviCRM screens that could potentially be broken if messed with.
Now the [SearchKit Reports](https://lab.civicrm.org/extensions/search_kit_reports) extension is introducing a bunch of packaged searches with the opposite intention. They provide *no* functionality out of the box and we *want* the user to mess with them & experiment as much as they want. We also want to encourage a workflow where they don't directly edit the packaged version but save a copy.
Design
-----------
I'm thinking that SavedSearchTemplates would:
1. Appear on their own tab in SearchKit
2. Not be runnable outside the SearchKit Admin UI - clicking on one would pull up a new pre-configured search (the same as clicking the "Clone" button on a SavedSearch)
3. Stored in their own table `civicrm_saved_search_template`
4. Can be created, updated & packaged like regular saved searches
To point 3, I thought about adding an `is_template` column like we do in the `civicrm_event` table, and then thought about what a PITA that column is, and is it really so hard to create a new table? No, not hard at all.https://lab.civicrm.org/dev/core/-/issues/4006PHP 8 - Undefined variable warnings in compiled Smarty templates2023-07-28T18:28:40ZAdam WoodPHP 8 - Undefined variable warnings in compiled Smarty templatesHave just upgraded to PHP 8.1 and CiviCRM 5.55.2.
We can now see a bunch of warnings about undeclared variables / array keys in the `error_log`, all of which seem to come from compiled Smarty template files in `templates_c`.
Below are ...Have just upgraded to PHP 8.1 and CiviCRM 5.55.2.
We can now see a bunch of warnings about undeclared variables / array keys in the `error_log`, all of which seem to come from compiled Smarty template files in `templates_c`.
Below are the most common repeat offenders (from a quick scan of the log), but there are probably more:
```
[Sun Nov 27 08:35:34.862647 2022] [fcgid:warn] [pid 62763] [client 92.2.56.169:60387] mod_fcgid: stderr: PHP Warning: Undefined array key "class" in /home/cses_org_uk/public_html/media/civicrm/templates_c/en_GB/%%11/11A/11A32C94%%UserDashboard.tpl.php on line 13, referer: https://cses.org.uk/membership/login
[Sun Nov 27 08:35:34.862655 2022] [fcgid:warn] [pid 62763] [client 92.2.56.169:60387] mod_fcgid: stderr: PHP Warning: Undefined array key "fields" in /home/cses_org_uk/public_html/media/civicrm/templates_c/en_GB/%%D2/D27/D2748E2E%%GrantApplicationDashboard.tpl.php on line 27, referer: https://cses.org.uk/membership/login
[Sun Nov 27 09:21:17.286322 2022] [fcgid:warn] [pid 64736] [client 66.249.76.73:54724] mod_fcgid: stderr: PHP Warning: Undefined array key "sidebarLeft" in /home/cses_org_uk/public_html/media/civicrm/templates_c/en_GB/%%EA/EAA/EAA96A89%%joomla.tpl.php on line 19
[Sun Nov 27 09:21:17.294758 2022] [fcgid:warn] [pid 64736] [client 66.249.76.73:54724] mod_fcgid: stderr: PHP Warning: Undefined array key "localTasks" in /home/cses_org_uk/public_html/media/civicrm/templates_c/en_GB/%%EA/EAA/EAA96A89%%joomla.tpl.php on line 56
[Sun Nov 27 09:21:17.294768 2022] [fcgid:warn] [pid 64736] [client 66.249.76.73:54724] mod_fcgid: stderr: PHP Warning: Undefined array key "registerClosed" in /home/cses_org_uk/public_html/media/civicrm/templates_c/en_GB/%%8E/8EE/8EE20E00%%EventInfo.tpl.php on line 6
[Sun Nov 27 09:21:17.294772 2022] [fcgid:warn] [pid 64736] [client 66.249.76.73:54724] mod_fcgid: stderr: PHP Warning: Undefined array key "summary" in /home/cses_org_uk/public_html/media/civicrm/templates_c/en_GB/%%8E/8EE/8EE20E00%%EventInfo.tpl.php on line 82
[Sun Nov 27 09:21:17.294774 2022] [fcgid:warn] [pid 64736] [client 66.249.76.73:54724] mod_fcgid: stderr: PHP Warning: Undefined array key "summary" in /home/cses_org_uk/public_html/media/civicrm/templates_c/en_GB/%%8E/8EE/8EE20E00%%EventInfo.tpl.php on line 97
[Sun Nov 27 09:21:17.294777 2022] [fcgid:warn] [pid 64736] [client 66.249.76.73:54724] mod_fcgid: stderr: PHP Warning: Undefined array key "profileGID" in /home/cses_org_uk/public_html/media/civicrm/templates_c/en_GB/%%77/771/771F796E%%Google.tpl.php on line 36
[Sun Nov 27 09:21:17.294780 2022] [fcgid:warn] [pid 64736] [client 66.249.76.73:54724] mod_fcgid: stderr: PHP Warning: Undefined array key 1 in /home/cses_org_uk/public_html/media/civicrm/templates_c/en_GB/%%8E/8EE/8EE20E00%%EventInfo.tpl.php on line 148
[Sun Nov 27 09:21:17.294783 2022] [fcgid:warn] [pid 64736] [client 66.249.76.73:54724] mod_fcgid: stderr: PHP Warning: Trying to access array offset on value of type null in /home/cses_org_uk/public_html/media/civicrm/templates_c/en_GB/%%8E/8EE/8EE20E00%%EventInfo.tpl.php on line 148
[Sun Nov 27 09:21:17.294786 2022] [fcgid:warn] [pid 64736] [client 66.249.76.73:54724] mod_fcgid: stderr: PHP Warning: Undefined array key 1 in /home/cses_org_uk/public_html/media/civicrm/templates_c/en_GB/%%8E/8EE/8EE20E00%%EventInfo.tpl.php on line 148
[Sun Nov 27 09:21:17.294789 2022] [fcgid:warn] [pid 64736] [client 66.249.76.73:54724] mod_fcgid: stderr: PHP Warning: Trying to access array offset on value of type null in /home/cses_org_uk/public_html/media/civicrm/templates_c/en_GB/%%8E/8EE/8EE20E00%%EventInfo.tpl.php on line 148
[Sun Nov 27 09:21:17.294791 2022] [fcgid:warn] [pid 64736] [client 66.249.76.73:54724] mod_fcgid: stderr: PHP Warning: Undefined array key "groupId" in /home/cses_org_uk/public_html/media/civicrm/templates_c/en_GB/%%FD/FD4/FD481315%%CustomDataView.tpl.php on line 176
[Sun Nov 27 09:21:17.294794 2022] [fcgid:warn] [pid 64736] [client 66.249.76.73:54724] mod_fcgid: stderr: PHP Warning: Undefined array key "emailMode" in /home/cses_org_uk/public_html/media/civicrm/templates_c/en_GB/%%79/79B/79BBF2EC%%SocialNetwork.tpl.php on line 11
```
Looking into one case in further detail (missing "summary" on line 82 of `EventInfo.tpl.php`), we see that the following Smarty code:
```smarty
<div class="vevent crm-event-id-{$event.id} crm-block crm-event-info-form-block">
<div class="event-info">
{* Display top buttons only if the page is long enough to merit duplicate buttons *}
{if $event.summary or $event.description}
```
Compiles into the following PHP:
```php
<div class="vevent crm-event-id-<?php echo $this->_tpl_vars['event']['id']; ?>
crm-block crm-event-info-form-block">
<div class="event-info">
<?php if ($this->_tpl_vars['event']['summary'] || $this->_tpl_vars['event']['description']): ?>
```
(i.e. there is no protection that the array index actually exists.)
So it looks like there may be an overall effort required here to tighten up the templates and/or corresponding page class PHP code to ensure that array indices are always declared correctly - and I'm happy to tackle some of these in the background - but is there any update from Smarty planned or pending that would affect this?
In this instance (and I suspect many of the others), I would suggest we use the `empty()` function to test for the variables in question:
```smarty
<div class="vevent crm-event-id-{$event.id} crm-block crm-event-info-form-block">
<div class="event-info">
{* Display top buttons only if the page is long enough to merit duplicate buttons *}
{if !empty($event.summary) or !empty($event.description)}
```https://lab.civicrm.org/dev/translation/-/issues/79Error in link on upgrade page after update database ready2022-11-30T18:23:15ZHanVError in link on upgrade page after update database readyI have today upgraded to version 5.55.2, on the screen after the database upgrade is an error in the link in the message:
Your Date Format settings have been automatically updated. (CRM/Upgrade/Incremental/php/FiveFiftyThree.php)
In the...I have today upgraded to version 5.55.2, on the screen after the database upgrade is an error in the link in the message:
Your Date Format settings have been automatically updated. (CRM/Upgrade/Incremental/php/FiveFiftyThree.php)
In the open tag it must be: href='%1'
I found the place with transifex.https://lab.civicrm.org/dev/core/-/issues/4005Minor formatting gripes with Contributions UserDashboard.tpl2023-10-17T14:38:15ZAdam WoodMinor formatting gripes with Contributions UserDashboard.tplRaising this as a minor residual issue / action vaguely related to historic issues https://lab.civicrm.org/dev/core/-/issues/2034 and https://lab.civicrm.org/dev/core/-/issues/2129, namely some incidental formatting issues spotted in the...Raising this as a minor residual issue / action vaguely related to historic issues https://lab.civicrm.org/dev/core/-/issues/2034 and https://lab.civicrm.org/dev/core/-/issues/2129, namely some incidental formatting issues spotted in the user dashboard template for recurring contributions.
Minor issues relating to spacing and formatting, will raise PR to close off.
1. No handling for if (installments == 0), i.e. the recurring contribution is open-ended. Just leaves a blank string which is confusing to users.
2. No spacing between clauses in 'Terms' - makes difficult to read. Also untranslated strings.
3. Unnecessary colon after 'Terms' in table header (doesn't match other header cells).
Screenshot below shows issues.
![image](https://user-images.githubusercontent.com/72983627/205190951-4db837e1-85df-4e38-a8b4-77ab1550a44b.png)
![image](https://user-images.githubusercontent.com/72983627/205190481-e8d642a5-9956-4fc3-a0d2-51f16187dca1.png)https://lab.civicrm.org/dev/core/-/issues/4004Fatal error in a Scheduled Job should not prevent other jobs runs from happening2022-11-30T08:31:30ZMichael McAndrewFatal error in a Scheduled Job should not prevent other jobs runs from happeningTake the example of a typical site with ~10 cron jobs configured to run every 5 minutes. The jobs are always run in the same order.
If job 3 exits with a fatal error, the following jobs will not run so a single failing job can cause ma...Take the example of a typical site with ~10 cron jobs configured to run every 5 minutes. The jobs are always run in the same order.
If job 3 exits with a fatal error, the following jobs will not run so a single failing job can cause many others to also 'fail' even if there is nothing wrong with them.
I don't think you can catch Fatal errors but wondering if there is another approach we can take (using sub processes or similar?) that will make our cron more resilient to failure within a specific job.https://lab.civicrm.org/dev/core/-/issues/4003Adding contacts via profile should reflect in source2023-01-24T16:14:59ZyashodhaAdding contacts via profile should reflect in source It would be helpful to have source field reflect the date of creation of contact and profile used.
**Proposal**
When a contact is created via a standalone profile, this information is added to the source field of the contact.
It shou... It would be helpful to have source field reflect the date of creation of contact and profile used.
**Proposal**
When a contact is created via a standalone profile, this information is added to the source field of the contact.
It should show : Profile *'profile name'* on *added date*.
This would be helpful in searches and very relevant to source field.yashodhayashodhahttps://lab.civicrm.org/dev/core/-/issues/4002API4 throws an exception when using `IN` and pseudoconstants aren't resolved2023-03-15T15:13:48ZJonGoldAPI4 throws an exception when using `IN` and pseudoconstants aren't resolvedConsider this API call in `mjwshared` (pinging @mattwire since he'll be interested):
```php
$paymentProcessorIDs = \Civi\Api4\PaymentProcessor::get(FALSE)
->addWhere('payment_processor_type_id:name', 'IN', ['Stripe', 'Globalpayments']...Consider this API call in `mjwshared` (pinging @mattwire since he'll be interested):
```php
$paymentProcessorIDs = \Civi\Api4\PaymentProcessor::get(FALSE)
->addWhere('payment_processor_type_id:name', 'IN', ['Stripe', 'Globalpayments'])
->execute()
```
This throws a fatal error when run if you don't have Stripe or Globalpayments installed. However, this seems inconsistent:
* If your operator is `=` not `IN`, you just get an empty set (e.g. `cv api4 PaymentProcessor.get +w 'payment_processor_type_id:name = "fake processor"'`).
* If your operator is `IN` but you're not using pseudoconstant lookup, you get an empty set, e.g. `cv api4 PaymentProcessor.get +w 'payment_processor_type_id IN [123456,234567]'`.
From a DX perspective, I think the correct result on the code in `mjwshared` is to return an empty set.JonGoldJonGoldhttps://lab.civicrm.org/dev/core/-/issues/4001Quick Search won't consider custom field groups2022-11-30T08:29:56Zartur.smigielskiQuick Search won't consider custom field groupsOverview
----------------------------------------
Quick search menu allow to select searchable custom fields but won't identify them by group
Reproduction steps
----------------------------------------
1. Add two groups for custom field...Overview
----------------------------------------
Quick search menu allow to select searchable custom fields but won't identify them by group
Reproduction steps
----------------------------------------
1. Add two groups for custom fields, any name, ex. group_1, group_2
2. For each of them add field with the same name "customnumber", searchable
3. Fill that field with random values for diffrent users
4. Edit quick search panel and pick one of that fields
5. Use quick search panel in menu
Current behaviour
----------------------------------------
It won't find matching records for group_1.customnumber or group_2.customnumber, it will always be the same field group_2.customnumber.
Reason: \CRM_Admin_Page_AJAX::getSearchOptions won't have info about custom field group, so it is searching only by name
```
CRM_Core_DAO::getFieldValue('CRM_Core_DAO_CustomField', substr($key, 7), 'id', 'name')
```
Expected behaviour
----------------------------------------
Search for group_1.customnumber or group_2.customnumber depending of which will be selected in quicksearch panelhttps://lab.civicrm.org/dev/core/-/issues/3998Add phpunit-bridge to unit testing2022-11-22T07:23:46ZDaveDAdd phpunit-bridge to unit testingSee https://github.com/civicrm/civicrm-core/pull/25009 for the results of what currently happens. The idea is that e.g. some php 8.x deprecations get hidden, but this package helps flush them out.
Some things that would need doing:
* A...See https://github.com/civicrm/civicrm-core/pull/25009 for the results of what currently happens. The idea is that e.g. some php 8.x deprecations get hidden, but this package helps flush them out.
Some things that would need doing:
* Adjusting the two propertybag tests so that they aren't trying to do the same thing. Or whatever the issue is there.
* A test listener(? or something) so that the deprecations become more visible rather than buried in the run output.
* What is "THE ERROR HANDLER HAS CHANGED!" about, and why is it in GIANT LETTERS? It appears after some test suite runs instead of where you would expect to see the deprecations. Possibly the suites where it appears somehow have their own error handlers in a way where it conflicts with phpunit-bridge.
FYI @totten @seamuslee. Not asking you to do anything just something you might be interested in.
P.S. To get a stack trace showing exactly where the deprecation is happening, you need to run locally and set SYMFONY_DEPRECATIONS_HELPER to a regex that matches the deprecation notice, as per https://symfony.com/doc/current/components/phpunit_bridge.html#display-the-full-stack-trace.
P.P.S. On windows depending on which of the 3^4 options you chose when you installed git, using `/` as the regex terminator confuses it and it gets rewritten as `C:/path/to/git/<the regex>`https://lab.civicrm.org/dev/core/-/issues/3996Event Registration that has error in Profile should continue to propagate Lin...2022-11-22T14:36:05ZshaneonabikeEvent Registration that has error in Profile should continue to propagate Line ItemsTo be honest I didn't know how to clearly define this title so feel free to change it.
## Problem
We encountered an interesting situation whereby during an Event registration the actual payment went through, but the Line items were mis...To be honest I didn't know how to clearly define this title so feel free to change it.
## Problem
We encountered an interesting situation whereby during an Event registration the actual payment went through, but the Line items were missing. When I looked further I discovered that there was an error due to missing / incorrectly configured fields in a Profile that was part of the Event registration.
This Profile was throwing an Exception, because it could not insert the record into the DB. I realize it makes sense to actually return that Exception, but what I question is whether the line items shouldn't be recorded. In this case, the transaction is completed (below), but the line items aren't there because of the exception.
![Selection_002](/uploads/45666402495106c8814a8de1d2837f1b/Selection_002.png)
## Recreate
1. Create a Custom Field set associated to a Contact, and add several fields
2. Create profile and add those fields
3. Create an Event
4. Add that Profile to the Event
5. Add a custom Price Set with several fields
6. Save
From this point, I'm not certain how this came about but I'm guessing the next steps would be:
1. Create a new set of Custom Fields identical to above and recreate associated to Participant and your Event type
1. Delete the first original Custom Field set, but not the profile
2. Register for the Event
I think where this happens is when the actual ```entity_id``` clashes (well in my case it was). So you would need to register multiple times to make this happen. In the DB teh value table for us was
```
civicrm_value_collector_det_16 | CREATE TABLE `civicrm_value_collector_det_16` (
`id` int(10) unsigned NOT NULL AUTO_INCREMENT COMMENT 'Default MySQL primary key',
`entity_id` int(10) unsigned NOT NULL COMMENT 'Table that this extends',
`name_of_individual_collecting_th_50` varchar(255) DEFAULT NULL,
`is_someone_collecting_this_order_51` tinyint(4) DEFAULT NULL,
`phone_number_52` varchar(255) DEFAULT NULL,
PRIMARY KEY (`id`),
UNIQUE KEY `unique_entity_id` (`entity_id`),
KEY `INDEX_phone_number_52` (`phone_number_52`),
KEY `INDEX_name_of_individual_collecting_th_50` (`name_of_individual_collecting_th_50`),
CONSTRAINT `FK_civicrm_value_collector_det_16_entity_id` FOREIGN KEY (`entity_id`) REFERENCES `civicrm_contact` (`id`) ON DELETE CASCADE
) ENGINE=InnoDB AUTO_INCREMENT=140 DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_unicode_ci |
```
## Actual Error
_DB Error: Constraint_ via
```
[debug_info] => INSERT INTO civicrm_value_collector_det_16 ( `is_someone_collecting_this_order_51`,
`name_of_individual_collecting_th_50`,`phone_number_52`,`entity_id` ) VALUES ( 0,'','',128 )
ON DUPLICATE KEY UPDATE `is_someone_collecting_this_order_51` = 0,
`name_of_individual_collecting_th_50` = '',`phone_number_52` = ''
[nativecode=1452 ** Cannot add or update a child row: a foreign key constraint fails
(`sitesite`.`civicrm_value_collector_det_16`, CONSTRAINT
`FK_civicrm_value_collector_det_16_entity_id` FOREIGN KEY (`entity_id`)
REFERENCES `civicrm_contact` (`id`) ON DELETE CASCADE)]
```
## Possible improvements
1. Process the transaction
2. Process line items
3. Save to DB
4. Process Profiles after?
or
1. Process transaction
2. Process Profile (if an exception cache it)
3. Continue as before
4. Throw Exception at end?
I'm not sure, but the fact that the transaction is passed we should ensure that the line items are saved too.
Sorry for the long text!https://lab.civicrm.org/dev/core/-/issues/3995FormBuilder: Autocomplete causes numerous network requests2022-11-18T16:54:03Zaydunsaidan.saunders@squiffle.ukFormBuilder: Autocomplete causes numerous network requestsOverview
----------------------------------------
On a FormBuilder form using an 'Existing entity' lookup results in multiple network requests.
Reproduction steps
----------------------------------------
1. Go to FormBuilder
2. Create n...Overview
----------------------------------------
On a FormBuilder form using an 'Existing entity' lookup results in multiple network requests.
Reproduction steps
----------------------------------------
1. Go to FormBuilder
2. Create new submission form (by default is for Individual)
3. Drag an 'Existing Contact' field onto the display
4. Add a page route, save, view page
5. Open up your browser's dev tools
6. Type something in 'existing contact' field
7. Select an entry
8. Observe repeated sequence of 'prefill', 'autocomplete' network requests:
![image](/uploads/04e0360aa2ac09ca5ab96248db02c41b/image.png)
Image from dmaster.demo.civicrm.org
Environment information
----------------------------------------
* __CiviCRM:__ _Master_ <!-- If this problem relates to an upgrade, then specify both old and new versions -->colemanwcolemanwhttps://lab.civicrm.org/dev/core/-/issues/3994Auto renew options for membership types are not saving for a contribution page2023-12-07T00:06:08ZKurund JalmiAuto renew options for membership types are not saving for a contribution pageSteps to replicate on vanilla CiviCRM install
- Membership type configuration
![Screenshot_from_2022-11-18_10-51-50](/uploads/02d45ded17660376a461d6738c287c48/Screenshot_from_2022-11-18_10-51-50.png)
- In the contribution page configur...Steps to replicate on vanilla CiviCRM install
- Membership type configuration
![Screenshot_from_2022-11-18_10-51-50](/uploads/02d45ded17660376a461d6738c287c48/Screenshot_from_2022-11-18_10-51-50.png)
- In the contribution page configuration try to make option 'Required' and save.
![Screenshot_from_2022-11-18_10-52-30](/uploads/9f50922426022defea7b99c53a386def/Screenshot_from_2022-11-18_10-52-30.png)
- However, it not saved
![Screenshot_from_2022-11-18_10-52-41](/uploads/57717f65ddd9e0df971821cafade9752/Screenshot_from_2022-11-18_10-52-41.png)5.69.0Kurund JalmiKurund Jalmihttps://lab.civicrm.org/dev/core/-/issues/3991Drop php 7.2 support from CiviCRM 5.58 (after 5.57 ESR)2023-11-28T10:48:51ZeileenDrop php 7.2 support from CiviCRM 5.58 (after 5.57 ESR)Per previous efforts to drop PHP version support I propose we drop 7.2 in 5.58. This means people who want another 6 months can use the ESR. Usage numbers for php 7.2 (around 1k) are around the levels where we dropped previous versions &...Per previous efforts to drop PHP version support I propose we drop 7.2 in 5.58. This means people who want another 6 months can use the ESR. Usage numbers for php 7.2 (around 1k) are around the levels where we dropped previous versions & support is starting to get harder - see https://github.com/civicrm/civicrm-core/pull/24952https://lab.civicrm.org/dev/wordpress/-/issues/134Clean URLs system check fails via API or cv2022-11-17T07:25:06ZJonGoldClean URLs system check fails via API or cvAs of CiviCRM 5.55, there is a check if Clean URLs are enabled.
Unfortunately, it does so by checking whether the `get_option()` function exists. This is fine via the web UI where WP boots first, but with `cv` or the API, WP boots afte...As of CiviCRM 5.55, there is a check if Clean URLs are enabled.
Unfortunately, it does so by checking whether the `get_option()` function exists. This is fine via the web UI where WP boots first, but with `cv` or the API, WP boots after CiviCRM. Since `CIVICRM_CLEANURLs` is a constant, once it's set to `0`, it's fixed at `0`.
E.g. in `cv`, `Civi\Cv\Util\BootTrait::_boot_full()` contains the following code!
```php
PharOut::prepare();
$output->writeln('<info>[BootTrait]</info> Call standard cv bootstrap', OutputInterface::VERBOSITY_DEBUG);
\Civi\Cv\Bootstrap::singleton()->boot($this->createBootParams($input, $output));
$output->writeln('<info>[BootTrait]</info> Call core bootstrap', OutputInterface::VERBOSITY_DEBUG);
\CRM_Core_Config::singleton();
$output->writeln('<info>[BootTrait]</info> Call CMS bootstrap', OutputInterface::VERBOSITY_DEBUG);
\CRM_Utils_System::loadBootStrap(array(), FALSE);
```
`\Civi\Cv\Bootstrap::singleton()->boot()` runs and `civicrm.settings.php` is evaluated before WP is booted at `\CRM_Utils_System::loadBootStrap(array(), FALSE)`.
### Next Steps
Maybe `CIVICRM_CLEANURLS` should be part of the `$civicrm_setting` global variable instead of a constant?https://lab.civicrm.org/dev/core/-/issues/3990force deduplication for event registrations: misleading help text → change su...2022-11-17T07:23:57ZAndreasandreas.howiller@civiservice.deforce deduplication for event registrations: misleading help text → change suggested workaround or add feature to CiviEvent?Sometimes you want to intentionally force duplicates for anonymous registrations for certain events. Some users even want this as their default in CiviEvent.
In the profile configuration there is the following hint how you should do th...Sometimes you want to intentionally force duplicates for anonymous registrations for certain events. Some users even want this as their default in CiviEvent.
In the profile configuration there is the following hint how you should do this:
> If you are using the profile as a contact signup and editing form - this option controls what happens if the data matches an existing contact record. Using this option user can update the matching record or create a duplicate record or otherwise he will get a 'duplicate record' warning, and their input will not be saved. Contact matching is based on your configured 'Strict' rule for identifying duplicate contacts. (Weiterlesen...)
>
> This setting is ignored if the profile is embedded in an online contribution, membership signup or event registration form. In this case a contact match always results in the transaction being linked to the matching contact.
>
> In all cases, the check for an existing matching contact uses the default "Individual Strict Duplicate Matching Rule" (match on email address). If you are concerned with existing contact data being over-written by anonymous visitors, you can modify this rule to make matches less likely (or even impossible). For example, if you NEVER want anonymous input to match (i.e. always create a new contact record) - edit that rule and set the 'weight threshold' higher than 10. You will then need to run Find Duplicates periodically using a different rule, and merge any duplicate records with their associated memberships, contributions, etc.
However, this kind of "suggested workaround" no longer works because you can no longer specify an unreachable threshold in the deduplication rules. In any case, the help text would have to be adapted.
However, the question arises how to deal with the actual requirement and I see at least two possibilities:
**Option A: Replacing the workaround**
Recommend in the help text to create an unachievable deduplication rule by using in the rule a field that is never used in the user's event registrations and advice them to set this rule for registrations when needed.
**Option B: add a feature in CiviEvent**
Add a "no deduplication" feature (like there is an option to deactivate deduplication in profiles) and add this option to the duplicate rule dropdown in the event configuration.
Any (other) ideas?https://lab.civicrm.org/dev/core/-/issues/3989Merging contacts should not overwrite empty source2023-07-05T23:48:38ZlarsssandergreenMerging contacts should not overwrite empty sourceIf you merge two contacts, the original with an empty source and the duplicate with some source value, the source value from the duplicate is copied to the original. This doesn't make sense, because the source of the contact is clearly n...If you merge two contacts, the original with an empty source and the duplicate with some source value, the source value from the duplicate is copied to the original. This doesn't make sense, because the source of the contact is clearly not whatever the source of the duplicate contact is — the contact already existed before that!
For example, we have lots of ten year old contacts with no source. A duplicate is created through an event registration now and these contacts can end up with a nonsensical source from an event this year when they have been in our database for a decade.
My proposal:
1. Remove the default selected checkbox for source when merging contacts manually. Source should never be overwritten by default, even if empty for the original contact. Users can still opt to overwrite with the newer source if desired.
2. Never overwrite source when batch merging, even if it is empty in the original contact. I think this is a sensible behaviour that doesn't need user intervention, but if there is a concern about this, we could also flag this as a merge conflict instead in this specific case.https://lab.civicrm.org/dev/core/-/issues/3988Cache race conditions2024-02-16T09:46:55ZJonGoldCache race conditionsA client was asking me to find out why a $2,500 donation failed. I found this error in the logs (full backtrace below):
```
Nov 10 10:58:40 [error] $Fatal Error Details = Array
(
[callback] => Array
(
[0] => CR...A client was asking me to find out why a $2,500 donation failed. I found this error in the logs (full backtrace below):
```
Nov 10 10:58:40 [error] $Fatal Error Details = Array
(
[callback] => Array
(
[0] => CRM_Core_Error
[1] => exceptionHandler
)
[code] => -5
[message] => DB Error: already exists
[mode] => 16
[debug_info] => UPDATE civicrm_cache SET data = 'YToxMDp7aToxO3M6OToiU2NoZWR1bGVkIjtpOjI7czo5OiJDb21wbGV0ZWQiO2k6MztzOjk6IkNhbmNlbGxlZCI7aTo0O3M6MTI6IkxlZnQgTWVzc2FnZSI7aTo1O3M6MTE6IlVucmVhY2hhYmxlIjtpOjY7czoxMjoiTm90IFJlcXVpcmVkIjtpOjc7czo5OiJBdmFpbGFibGUiO2k6ODtzOjc6Ik5vX3Nob3ciO2k6OTtzOjY6IlVucmVhZCI7aToxMDtzOjU6IkRyYWZ0Ijt9', created_date = FROM_UNIXTIME(1668095920), expired_date = FROM_UNIXTIME(1668117520) WHERE group_name = "metadata_5_54_1" AND path = "CRM_OG_activitystatus_883f1c0c1790789755f726d1e41232c2" [nativecode=1062 ** Duplicate entry 'metadata_5_54_1-CRM_OG_activitystatus_883f1c0c1790789755f726d...' for key 'UI_group_path_date']
[type] => DB_Error
[user_info] => UPDATE civicrm_cache SET data = 'YToxMDp7aToxO3M6OToiU2NoZWR1bGVkIjtpOjI7czo5OiJDb21wbGV0ZWQiO2k6MztzOjk6IkNhbmNlbGxlZCI7aTo0O3M6MTI6IkxlZnQgTWVzc2FnZSI7aTo1O3M6MTE6IlVucmVhY2hhYmxlIjtpOjY7czoxMjoiTm90IFJlcXVpcmVkIjtpOjc7czo5OiJBdmFpbGFibGUiO2k6ODtzOjc6Ik5vX3Nob3ciO2k6OTtzOjY6IlVucmVhZCI7aToxMDtzOjU6IkRyYWZ0Ijt9', created_date = FROM_UNIXTIME(1668095920), expired_date = FROM_UNIXTIME(1668117520) WHERE group_name = "metadata_5_54_1" AND path = "CRM_OG_activitystatus_883f1c0c1790789755f726d1e41232c2" [nativecode=1062 ** Duplicate entry 'metadata_5_54_1-CRM_OG_activitystatus_883f1c0c1790789755f726d...' for key 'UI_group_path_date']
[to_string] => [db_error: message="DB Error: already exists" code=-5 mode=callback callback=CRM_Core_Error::exceptionHandler prefix="" info="UPDATE civicrm_cache SET data = 'YToxMDp7aToxO3M6OToiU2NoZWR1bGVkIjtpOjI7czo5OiJDb21wbGV0ZWQiO2k6MztzOjk6IkNhbmNlbGxlZCI7aTo0O3M6MTI6IkxlZnQgTWVzc2FnZSI7aTo1O3M6MTE6IlVucmVhY2hhYmxlIjtpOjY7czoxMjoiTm90IFJlcXVpcmVkIjtpOjc7czo5OiJBdmFpbGFibGUiO2k6ODtzOjc6Ik5vX3Nob3ciO2k6OTtzOjY6IlVucmVhZCI7aToxMDtzOjU6IkRyYWZ0Ijt9', created_date = FROM_UNIXTIME(1668095920), expired_date = FROM_UNIXTIME(1668117520) WHERE group_name = "metadata_5_54_1" AND path = "CRM_OG_activitystatus_883f1c0c1790789755f726d1e41232c2" [nativecode=1062 ** Duplicate entry 'metadata_5_54_1-CRM_OG_activitystatus_883f1c0c1790789755f726d...' for key 'UI_group_path_date']"]
)
```
In `CRM_Core_OptionGroup::values()`, we check for a cached result. If we don't find one, we run the query, then cache the result. However, between the `$cache->has()` and `$cache->set()`, this value was added to the cache.
### How to resolve?
It seems to me like there's no way to avoid a race condition without recovering gracefully from this error.
It seems like a failure to write to cache shouldn't be fatal - could we catch `CRM_Utils_Cache_CacheException` and continue execution?
Backtrace
```
Nov 10 10:58:40 [debug] $backTrace = #0 /var/www/mysiten.org/vendor/civicrm/civicrm-core/CRM/Core/Error.php(954): CRM_Core_Error::backtrace("backTrace", TRUE)
#1 /var/www/mysiten.org/vendor/pear/pear-core-minimal/src/PEAR.php(944): CRM_Core_Error::exceptionHandler(Object(DB_Error))
#2 /var/www/mysiten.org/vendor/pear/db/DB.php(997): PEAR_Error->__construct("DB Error: already exists", -5, 16, (Array:2), "UPDATE civicrm_cache SET data = 'YToxMDp7aToxO3M6OToiU2NoZWR1bGVkIjtpOjI7czo5...")
#3 /var/www/mysiten.org/vendor/pear/pear-core-minimal/src/PEAR.php(575): DB_Error->__construct(-5, 16, (Array:2), "UPDATE civicrm_cache SET data = 'YToxMDp7aToxO3M6OToiU2NoZWR1bGVkIjtpOjI7czo5...")
#4 /var/www/mysiten.org/vendor/pear/pear-core-minimal/src/PEAR.php(223): PEAR::_raiseError(Object(DB_mysqli), NULL, -5, 16, (Array:2), "UPDATE civicrm_cache SET data = 'YToxMDp7aToxO3M6OToiU2NoZWR1bGVkIjtpOjI7czo5...", "DB_Error", TRUE)
#5 /var/www/mysiten.org/vendor/pear/db/DB/common.php(1928): PEAR->__call("raiseError", (Array:7))
#6 /var/www/mysiten.org/vendor/pear/db/DB/mysqli.php(943): DB_common->raiseError(-5, NULL, NULL, "UPDATE civicrm_cache SET data = 'YToxMDp7aToxO3M6OToiU2NoZWR1bGVkIjtpOjI7czo5...", "1062 ** Duplicate entry 'metadata_5_54_1-CRM_OG_activitystatus_883f1c0c179078...")
#7 /var/www/mysiten.org/vendor/pear/db/DB/mysqli.php(413): DB_mysqli->mysqliRaiseError()
#8 /var/www/mysiten.org/vendor/pear/db/DB/common.php(1234): DB_mysqli->simpleQuery("UPDATE civicrm_cache SET data = 'YToxMDp7aToxO3M6OToiU2NoZWR1bGVkIjtpOjI7czo5...")
#9 /var/www/mysiten.org/vendor/civicrm/civicrm-packages/DB/DataObject.php(2696): DB_common->query("UPDATE civicrm_cache SET data = 'YToxMDp7aToxO3M6OToiU2NoZWR1bGVkIjtpOjI7czo5...")
#10 /var/www/mysiten.org/vendor/civicrm/civicrm-packages/DB/DataObject.php(1829): DB_DataObject->_query("UPDATE civicrm_cache SET data = 'YToxMDp7aToxO3M6OToiU2NoZWR1bGVkIjtpOjI7czo5...")
#11 /var/www/mysiten.org/vendor/civicrm/civicrm-core/CRM/Core/DAO.php(494): DB_DataObject->query("UPDATE civicrm_cache SET data = 'YToxMDp7aToxO3M6OToiU2NoZWR1bGVkIjtpOjI7czo5...")
#12 /var/www/mysiten.org/vendor/civicrm/civicrm-core/CRM/Core/DAO.php(1675): CRM_Core_DAO->query("UPDATE civicrm_cache SET data = 'YToxMDp7aToxO3M6OToiU2NoZWR1bGVkIjtpOjI7czo5...", FALSE)
#13 /var/www/mysiten.org/vendor/civicrm/civicrm-core/CRM/Utils/Cache/SqlGroup.php(137): CRM_Core_DAO::executeQuery("UPDATE civicrm_cache SET data = %1, created_date = FROM_UNIXTIME(%2), expired...", (Array:3), TRUE, NULL, FALSE, FALSE)
#14 /var/www/mysiten.org/vendor/civicrm/civicrm-core/CRM/Core/OptionGroup.php(173): CRM_Utils_Cache_SqlGroup->set("CRM_OG_activitystatus_883f1c0c1790789755f726d1e41232c2", (Array:10))
#15 /var/www/mysiten.org/vendor/civicrm/civicrm-core/CRM/Core/PseudoConstant.php(262): CRM_Core_OptionGroup::values("activity_status", FALSE, FALSE, FALSE, NULL, "name", FALSE, FALSE, "value", "weight")
#16 /var/www/mysiten.org/vendor/civicrm/civicrm-core/CRM/Core/DAO.php(2837): CRM_Core_PseudoConstant::get("CRM_Activity_BAO_Activity", "status_id", (Array:8), "validate")
#17 /var/www/mysiten.org/vendor/civicrm/civicrm-core/Civi/Api4/Utils/FormattingUtil.php(264): CRM_Core_DAO::buildOptions("status_id", "validate", (Array:10))
#18 /var/www/mysiten.org/vendor/civicrm/civicrm-core/Civi/Api4/Generic/AbstractAction.php(530): Civi\Api4\Utils\FormattingUtil::getPseudoconstantList((Array:30), "status_id:name", (Array:10), "create")
#19 /var/www/mysiten.org/vendor/civicrm/civicrm-core/Civi/Api4/Generic/Traits/DAOActionTrait.php(178): Civi\Api4\Generic\AbstractAction->formatWriteValues((Array:10))
#20 /var/www/mysiten.org/vendor/civicrm/civicrm-core/Civi/Api4/Generic/DAOSaveAction.php(30): Civi\Api4\Generic\DAOSaveAction->formatWriteValues((Array:10))
#21 /var/www/mysiten.org/vendor/civicrm/civicrm-core/Civi/Api4/Provider/ActionObjectProvider.php(69): Civi\Api4\Generic\DAOSaveAction->_run(Object(Civi\Api4\Generic\Result))
#22 /var/www/mysiten.org/vendor/civicrm/civicrm-core/Civi/API/Kernel.php(149): Civi\Api4\Provider\ActionObjectProvider->invoke(Object(Civi\Api4\Generic\DAOSaveAction))
#23 /var/www/mysiten.org/vendor/civicrm/civicrm-core/Civi/Api4/Generic/AbstractAction.php(250): Civi\API\Kernel->runRequest(Object(Civi\Api4\Generic\DAOSaveAction))
#24 /var/www/mysiten.org/vendor/civicrm/civicrm-core/CRM/Contribute/BAO/Contribution.php(552): Civi\Api4\Generic\AbstractAction->execute()
#25 /var/www/mysiten.org/vendor/civicrm/civicrm-core/api/v3/utils.php(1319): CRM_Contribute_BAO_Contribution::create((Array:23))
#26 /var/www/mysiten.org/vendor/civicrm/civicrm-core/api/v3/Contribution.php(87): _civicrm_api3_basic_create("CRM_Contribute_BAO_Contribution", (Array:23), "Contribution")
#27 /var/www/mysiten.org/vendor/civicrm/civicrm-core/Civi/API/Provider/MagicFunctionProvider.php(89): civicrm_api3_contribution_create((Array:23))
#28 /var/www/mysiten.org/vendor/civicrm/civicrm-core/Civi/API/Kernel.php(149): Civi\API\Provider\MagicFunctionProvider->invoke((Array:8))
#29 /var/www/mysiten.org/vendor/civicrm/civicrm-core/Civi/API/Kernel.php(81): Civi\API\Kernel->runRequest((Array:8))
#30 /var/www/mysiten.org/vendor/civicrm/civicrm-core/api/api.php(133): Civi\API\Kernel->runSafe("Contribution", "create", (Array:10))
#31 /var/www/mysiten.org/vendor/civicrm/civicrm-core/CRM/Contribute/BAO/Contribution.php(3848): civicrm_api3("Contribution", "create", (Array:10))
#32 /var/www/mysiten.org/vendor/civicrm/civicrm-core/api/v3/Contribution.php(522): CRM_Contribute_BAO_Contribution::completeOrder((Array:5), NULL, 21523, NULL)
#33 /var/www/mysiten.org/vendor/civicrm/civicrm-core/Civi/API/Provider/MagicFunctionProvider.php(89): civicrm_api3_contribution_completetransaction((Array:9))
#34 /var/www/mysiten.org/vendor/civicrm/civicrm-core/Civi/API/Kernel.php(149): Civi\API\Provider\MagicFunctionProvider->invoke((Array:8))
#35 /var/www/mysiten.org/vendor/civicrm/civicrm-core/Civi/API/Kernel.php(81): Civi\API\Kernel->runRequest((Array:8))
#36 /var/www/mysiten.org/vendor/civicrm/civicrm-core/api/api.php(133): Civi\API\Kernel->runSafe("contribution", "completetransaction", (Array:9))
#37 /var/www/mysiten.org/vendor/civicrm/civicrm-core/CRM/Contribute/Form/Contribution/Confirm.php(2412): civicrm_api3("contribution", "completetransaction", (Array:9))
#38 /var/www/mysiten.org/vendor/civicrm/civicrm-core/CRM/Contribute/Form/Contribution/Confirm.php(861): CRM_Contribute_Form_Contribution_Confirm->processFormSubmission("100769")
#39 /var/www/mysiten.org/vendor/civicrm/civicrm-core/CRM/Core/Form.php(573): CRM_Contribute_Form_Contribution_Confirm->postProcess()
#40 /var/www/mysiten.org/vendor/civicrm/civicrm-core/CRM/Contribute/Form/Contribution/Main.php(1472): CRM_Core_Form->mainProcess()
#41 /var/www/mysiten.org/vendor/civicrm/civicrm-core/CRM/Contribute/Form/Contribution/Main.php(1220): CRM_Contribute_Form_Contribution_Main->skipToThankYouPage()
#42 /var/www/mysiten.org/vendor/civicrm/civicrm-core/CRM/Core/Form.php(573): CRM_Contribute_Form_Contribution_Main->postProcess()
#43 /var/www/mysiten.org/vendor/civicrm/civicrm-core/CRM/Core/QuickForm/Action/Upload.php(152): CRM_Core_Form->mainProcess()
#44 /var/www/mysiten.org/vendor/civicrm/civicrm-core/CRM/Core/QuickForm/Action/Upload.php(119): CRM_Core_QuickForm_Action_Upload->realPerform(Object(CRM_Contribute_Form_Contribution_Main), "upload")
#45 /var/www/mysiten.org/vendor/civicrm/civicrm-packages/HTML/QuickForm/Controller.php(203): CRM_Core_QuickForm_Action_Upload->perform(Object(CRM_Contribute_Form_Contribution_Main), "upload")
#46 /var/www/mysiten.org/vendor/civicrm/civicrm-packages/HTML/QuickForm/Page.php(103): HTML_QuickForm_Controller->handle(Object(CRM_Contribute_Form_Contribution_Main), "upload")
#47 /var/www/mysiten.org/vendor/civicrm/civicrm-core/CRM/Core/Controller.php(355): HTML_QuickForm_Page->handle("upload")
#48 /var/www/mysiten.org/vendor/civicrm/civicrm-core/CRM/Core/Invoke.php(319): CRM_Core_Controller->run((Array:3), NULL)
#49 /var/www/mysiten.org/vendor/civicrm/civicrm-core/CRM/Core/Invoke.php(69): CRM_Core_Invoke::runItem((Array:18))
#50 /var/www/mysiten.org/vendor/civicrm/civicrm-core/CRM/Core/Invoke.php(36): CRM_Core_Invoke::_invoke((Array:3))
#51 /var/www/mysiten.org/web/modules/contrib/civicrm/src/Civicrm.php(88): CRM_Core_Invoke::invoke((Array:3))
#52 /var/www/mysiten.org/web/modules/contrib/civicrm/src/Controller/CivicrmController.php(80): Drupal\civicrm\Civicrm->invoke((Array:3))
#53 [internal function](): Drupal\civicrm\Controller\CivicrmController->main((Array:3), "")
#54 /var/www/mysiten.org/web/core/lib/Drupal/Core/EventSubscriber/EarlyRenderingControllerWrapperSubscriber.php(123): call_user_func_array((Array:2), (Array:2))
#55 /var/www/mysiten.org/web/core/lib/Drupal/Core/Render/Renderer.php(564): Drupal\Core\EventSubscriber\EarlyRenderingControllerWrapperSubscriber->Drupal\Core\EventSubscriber\{closure}()
#56 /var/www/mysiten.org/web/core/lib/Drupal/Core/EventSubscriber/EarlyRenderingControllerWrapperSubscriber.php(124): Drupal\Core\Render\Renderer->executeInRenderContext(Object(Drupal\Core\Render\RenderContext), Object(Closure))
#57 /var/www/mysiten.org/web/core/lib/Drupal/Core/EventSubscriber/EarlyRenderingControllerWrapperSubscriber.php(97): Drupal\Core\EventSubscriber\EarlyRenderingControllerWrapperSubscriber->wrapControllerExecutionInRenderContext((Array:2), (Array:2))
#58 /var/www/mysiten.org/vendor/symfony/http-kernel/HttpKernel.php(159): Drupal\Core\EventSubscriber\EarlyRenderingControllerWrapperSubscriber->Drupal\Core\EventSubscriber\{closure}()
#59 /var/www/mysiten.org/vendor/symfony/http-kernel/HttpKernel.php(81): Symfony\Component\HttpKernel\HttpKernel->handleRaw(Object(Symfony\Component\HttpFoundation\Request), 1)
#60 /var/www/mysiten.org/web/core/lib/Drupal/Core/StackMiddleware/Session.php(58): Symfony\Component\HttpKernel\HttpKernel->handle(Object(Symfony\Component\HttpFoundation\Request), 1, TRUE)
#61 /var/www/mysiten.org/web/core/lib/Drupal/Core/StackMiddleware/KernelPreHandle.php(48): Drupal\Core\StackMiddleware\Session->handle(Object(Symfony\Component\HttpFoundation\Request), 1, TRUE)
#62 /var/www/mysiten.org/web/core/modules/page_cache/src/StackMiddleware/PageCache.php(106): Drupal\Core\StackMiddleware\KernelPreHandle->handle(Object(Symfony\Component\HttpFoundation\Request), 1, TRUE)
#63 /var/www/mysiten.org/web/core/modules/page_cache/src/StackMiddleware/PageCache.php(85): Drupal\page_cache\StackMiddleware\PageCache->pass(Object(Symfony\Component\HttpFoundation\Request), 1, TRUE)
#64 /var/www/mysiten.org/web/core/lib/Drupal/Core/StackMiddleware/ReverseProxyMiddleware.php(48): Drupal\page_cache\StackMiddleware\PageCache->handle(Object(Symfony\Component\HttpFoundation\Request), 1, TRUE)
#65 /var/www/mysiten.org/web/core/lib/Drupal/Core/StackMiddleware/NegotiationMiddleware.php(51): Drupal\Core\StackMiddleware\ReverseProxyMiddleware->handle(Object(Symfony\Component\HttpFoundation\Request), 1, TRUE)
#66 /var/www/mysiten.org/vendor/stack/builder/src/Stack/StackedHttpKernel.php(23): Drupal\Core\StackMiddleware\NegotiationMiddleware->handle(Object(Symfony\Component\HttpFoundation\Request), 1, TRUE)
#67 /var/www/mysiten.org/web/core/lib/Drupal/Core/DrupalKernel.php(709): Stack\StackedHttpKernel->handle(Object(Symfony\Component\HttpFoundation\Request), 1, TRUE)
#68 /var/www/mysiten.org/web/index.php(19): Drupal\Core\DrupalKernel->handle(Object(Symfony\Component\HttpFoundation\Request))
#69 {main}
```5.61.0