Development issueshttps://lab.civicrm.org/groups/dev/-/issues2022-09-14T16:40:24Zhttps://lab.civicrm.org/dev/core/-/issues/3843Searchkit: Cases join tables have changed2022-09-14T16:40:24ZDaveDSearchkit: Cases join tables have changedIn 5.49.5 for example:
![Untitled2](/uploads/445fdd0daeb3eb82cef5e7f62099444f/Untitled2.png)
In master (5.54):
Note the case contacts have disappeared. (The weird "case case type" is just weird but functions ok.)
![Untitled2](/upload...In 5.49.5 for example:
![Untitled2](/uploads/445fdd0daeb3eb82cef5e7f62099444f/Untitled2.png)
In master (5.54):
Note the case contacts have disappeared. (The weird "case case type" is just weird but functions ok.)
![Untitled2](/uploads/1a8d8bb801fc6070126cb380591728a4/Untitled2.png)https://lab.civicrm.org/dev/core/-/issues/3838Middle name is evaluating to literal word null in addressee greeting2022-09-14T21:42:11ZDaveDMiddle name is evaluating to literal word null in addressee greeting1. Create a contact without a middle name and save.
2. Look at the addressee greeting on the contact summary.
This seems to have started in master (5.54).1. Create a contact without a middle name and save.
2. Look at the addressee greeting on the contact summary.
This seems to have started in master (5.54).5.54.0https://lab.civicrm.org/dev/core/-/issues/3837Checking one of the preferred communication method boxes on contact gives dep...2022-09-13T21:27:07ZDaveDChecking one of the preferred communication method boxes on contact gives deprecation about BAO form layer something`User deprecated function: Form layer formatting should never get to the BAO Caller: CRM_Contact_BAO_Contact::create in CRM_Core_Error::deprecatedWarning() (line 1111 of .../CRM/Core/Error.php).`
1. Create a contact.
2. In communication...`User deprecated function: Form layer formatting should never get to the BAO Caller: CRM_Contact_BAO_Contact::create in CRM_Core_Error::deprecatedWarning() (line 1111 of .../CRM/Core/Error.php).`
1. Create a contact.
2. In communication prefs, check e.g. SMS for preferred communication method.
3. Click save.
Seems to have started in 5.52.5.53.1https://lab.civicrm.org/dev/core/-/issues/3829Barcodes in event badges missing data after updating to CiviCRM 5.45.72022-11-17T21:28:44ZLKuttnerBarcodes in event badges missing data after updating to CiviCRM 5.45.7When printing event badges from event participant search results and selecting _Name Badges - Print_ or clicking _Save and Preview_ in Event Name Badge Layouts, the barcodes in the PDFs created no longer include the contact_id and partic...When printing event badges from event participant search results and selecting _Name Badges - Print_ or clicking _Save and Preview_ in Event Name Badge Layouts, the barcodes in the PDFs created no longer include the contact_id and participant_id. The short barcode that is displayed only includes the hyphen that is usually in between, as specified in line 260 of Badge.php.
`$data['current_value'] = $formattedRow['values']['contact_id'] . '-' . $formattedRow['values']['participant_id'];`
The barcodes were printing fine until recently upgrading from CiviCRM 5.39.4. I see that there were [changes committed](https://github.com/civicrm/civicrm-core/commit/3fd42bb541eaa2861048f1c74b3da537887812b1#diff-b732ac83b0f3272ae759a9163725022788567c65717578b263d294e5ba1c3d7f) on Jan 16 that may be related.
We are on D7 with PHP 7.3.29. Thank you for any assistance you can offer in resolving this.5.54.1https://lab.civicrm.org/dev/core/-/issues/3828Import of contributions (update existing) -> error for total_amount = "0"2022-09-01T01:36:04ZDetlev SieberImport of contributions (update existing) -> error for total_amount = "0"(This issue is related to #3820 )
----------------------------------------
In some use case for contribution import, it is needed to update the total_amount to "0".
However, since 5.51(?) this creates an error:
`Missing required fields...(This issue is related to #3820 )
----------------------------------------
In some use case for contribution import, it is needed to update the total_amount to "0".
However, since 5.51(?) this creates an error:
`Missing required fields: Contribution ID OR Total Amount`
In the past, it was okay to set this field to "0". However now, I have to set it to "0.00" in order to make the update parser understand, that the value is not empty...
Of course, this is a minor issue, since there is an easy workaround. However, out there might be regular import procedures relying on "total_amount='0' ".
Reproduction steps
----------------------------------------
1. Create a csv file for import of contributions as "update contribution", with transaction_id as key and total_amount = "0"
2. Import the file
3. Workaround: set the total_amount in the import file to total_amount = "0.00" -> this will work.
Current behaviour
----------------------------------------
total_amount = 0 is not accepted and produces an error when trying to import
Expected behaviour
----------------------------------------
total_amount = 0 is accepted and updates the total_amount to "0.00"
Environment information
----------------------------------------
CiviCRM 5.52.2 (with patch https://github.com/civicrm/civicrm-core/pull/24367 )5.52.2https://lab.civicrm.org/dev/core/-/issues/3826Searchkit: Contribution tasks like receipt give fatal error2022-11-30T16:28:35ZDaveDSearchkit: Contribution tasks like receipt give fatal error1. Do searchkit search for contributions.
2. Pick one, and choose Print Receipt from the actions dropdown.
3. Network error - cannot be reached etc.
The problem is the qfkey and url don't match so [validation for the key](https://github...1. Do searchkit search for contributions.
2. Pick one, and choose Print Receipt from the actions dropdown.
3. Network error - cannot be reached etc.
The problem is the qfkey and url don't match so [validation for the key](https://github.com/civicrm/civicrm-core/blob/ea2f82c3c3e5b48da69561b5a057e8513a8b8ce6/CRM/Core/Controller.php#L312) fails. One is for the form, and the other is a controller.
I can reproduce on dmaster.demo.
This is somewhat related to the problem I'm having getting the ids from searchkit contribution tasks, but which is maybe a bit broken so now I'm not sure: https://lab.civicrm.org/documentation/docs/dev/-/merge_requests/1023
I tried to understand https://github.com/civicrm/civicrm-core/commit/813e32efc234f08517c130602ecebf6a32a0819d where this was added and while I get that there's a desire to separate it from the existing search tasks, it's maybe making it difficult to [reuse existing contribution search tasks](https://docs.civicrm.org/dev/en/latest/searchkit/tasks/#legacy-search-tasks). I assume that PR was working at some point, but the task doesn't seem to be working now.5.53.1https://lab.civicrm.org/dev/core/-/issues/3820Import of contributions (update existing) -> error for all contributions "No ...2022-09-01T01:36:49ZTobias KrauseImport of contributions (update existing) -> error for all contributions "No matching Contact found for ()"Drupal 9.4, CiviCRM 5.52.2, PHP 8.0
- Go to /civicrm/contribute/import
- choose a csv file contribution data
- Settings: Update existing contributions
- in mapping we connect a column "contribution id" with the CiviCRM field "Contributi...Drupal 9.4, CiviCRM 5.52.2, PHP 8.0
- Go to /civicrm/contribute/import
- choose a csv file contribution data
- Settings: Update existing contributions
- in mapping we connect a column "contribution id" with the CiviCRM field "Contribution id (match to contribution record)"
- the main purpose in our case is to update the contribution status
We used a testing CSV with 10 entries and for each of them there is the same error: "No matching Contact found for ()". For all contributions in the CSV the contributions in CiviCRM and the contacts exists. The error appears in CRM/Contribute/Import/Parser/Contribution.php on line 481 within the check
`empty($formatted['contact_id'])`
Here I get confused: I am not able to choose contact id as a matching field but it seems this method expects this value to be set. In our CSV there is a column with the contact id - but as I said it cannot be matched to a contact id field in CiviCRM.
As this worked before (updating existing contributions with the field matching without contact id set) for years something might have changed here.5.52.2https://lab.civicrm.org/dev/core/-/issues/3803DB Error when Create User Record2022-08-24T23:31:04ZolivierDB Error when Create User RecordOverview
----------------------------------------
When I try to create a user with "Create user Record", the CMS user is correctly created, but a new Civicrm user is added.
----------------------------------------
1. Check that eamil ad...Overview
----------------------------------------
When I try to create a user with "Create user Record", the CMS user is correctly created, but a new Civicrm user is added.
----------------------------------------
1. Check that eamil address is uniq
![image](/uploads/89c495169035d1a108c89c5ad8f6ca73/image.png)
2. And don't exist on CMS side
![image](/uploads/d00bae41921431beba67e8e2372793c6/image.png)
3. In Civicrm Contact view, click Actions/Create user record, fill password and click Add
![image](/uploads/9842df81c429868c64c3b1738857cfe3/image.png)
4. Got an error "**Fatal error: DB error**".
![image](/uploads/444c20f47378581115126e784456e75b/image.png)
5. CMS user is created
![image](/uploads/798e2941d70bb7895d109e81cab5e055/image.png)
6. but another Civicrm user is created vith the same email
![image](/uploads/32d8fc6c3bd36adf1c016618d40beb90/image.png)
![image](/uploads/97de7340588be1790285830adb029112/image.png)
![image](/uploads/9b40f9477af6f1bb7a1de7ddf95a5b0f/image.png)
7. CMS error :
![image](/uploads/b3fc540aeca5a43a222852c3ed3478ad/image.png)
Expected behaviour
----------------------------------------
No new user created and CMS userID should be associated to existing Civicrm
Environment information
----------------------------------------
* Civicrm 5.51.2 (but same behavior in previous versions)
* PHP 7.4.19
* Drupal 9.4.5
Comments
----------------------------------------
In /vendor/civicrm/civicrm-core/CRM/Core/BAO/UFMatch.php, line 250, ll the information on the Civicrm account is deleted, and only the email address is present. In the continuation of the treatment, it is not possible any more to find the account thus a new account is created in /vendor/civicrm/civicrm-coreCRM/CoreBAO/CMSUser.php
Proposal
----------------------------------------
Replace in /vendor/civicrm/civicrm-core/CRM/Core/BAO/UFMatch.php, line 250
$params = ['email' => $primary_email];
by
$params['email'] = $primary_email;5.53.0https://lab.civicrm.org/dev/core/-/issues/3799CiviCRM Reports, setting the Report option "Available for Dashboard?" will no...2022-08-14T03:14:20Zjustinfreeman (Agileware)CiviCRM Reports, setting the Report option "Available for Dashboard?" will now add the Report to all users Dashboards, which is new and undesirable behaviourAs observed in CiviCRM 5.51.2 when updating a CiviCRM Report. Setting the Report option "Available for Dashboard?" will now add the Report to all users Dashboards, which is new and undesirable behaviour. If lots of new reports are being ...As observed in CiviCRM 5.51.2 when updating a CiviCRM Report. Setting the Report option "Available for Dashboard?" will now add the Report to all users Dashboards, which is new and undesirable behaviour. If lots of new reports are being added, this quickly SPAMs all the existing Dashboards with the new reports.
The previous behaviour was that the report would not be displayed on the Dashboard until it was manually added.
Screen recording of this behaviour on https://dmaster.demo.civicrm.org/civicrm/dashboard - CiviCRM 5.54.alpha1
![Peek_2022-08-12_15-55](/uploads/4f8ab99408be96a25e3aa0259646c4bf/Peek_2022-08-12_15-55.gif)
Agileware Ref: CIVICRM-20325.52.2https://lab.civicrm.org/dev/core/-/issues/3797Not a Valid Integer - Bug 5.52.02022-08-11T18:08:22ZsavionleeNot a Valid Integer - Bug 5.52.0Overview
----------------------------------------
_Please describe your problem or bug in detail._
When making a traditional mailing or Mosaico mailing on CiviMail, I am trying to create a mailing but my select2 dropdowns are not interpr...Overview
----------------------------------------
_Please describe your problem or bug in detail._
When making a traditional mailing or Mosaico mailing on CiviMail, I am trying to create a mailing but my select2 dropdowns are not interpreting the options correctly so it is display as blanks.
When i try to update them, it says the id is not valid.
Reproduction steps
----------------------------------------
1. Click on **Mailings -> New Mailing (Traditional) or New Mailing**.
1. Click on **Responses** or **Publication** and wait for the event listener to fire off.
1. Got an error "**optout_id is not a valid integer**" or something similar.
Current behaviour
----------------------------------------
_What happens currently. Please provide error messages, screenshots or gifs ([LICEcap](http://www.cockos.com/licecap/), [SilentCast](https://github.com/colinkeenan/silentcast)) where appropriate._
![image](/uploads/42c808b2cbd0e079ee686d8988abf49a/image.png)
When i try setting them i get these errors:
![image](/uploads/6afba3e6c5b30d76853a063c7a4e8baf/image.png)
Looking at my debug console and network request, the following POST errors are generated:
`{"error_field":"optout_id","type":"integer","error_code":2001,"entity":"Mailing","action":"create","is_error":1,"error_message":"optout_id is not a valid integer"}`
with the payload sending this in the optout_id slot of the json payload
`"optout_id":"string:7"`
Clearly i believe that the value should be 7, but it is coded as a `string:7`
I suspect that this is a parsing issue with a JS resource sent to me because the GET response of:
`page: CiviCRM
q: civicrm/ajax/rest
entity: Mailing
action: getsingle
json: {"id":"ID#"}`
returns valid integers:
` "reply_id": "8",
"unsubscribe_id": "5",
"resubscribe_id": "6",
"optout_id": "7",`
Expected behaviour
----------------------------------------
_What should happen._
The event listener should pass an integer instead of a string saying `string:7`
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:__ _Edge 104.0.1293.47/Firefox 103.0.2_
* __CiviCRM:__ _Master/5.52.0..._ <!-- If this problem relates to an upgrade, then specify both old and new versions -->
* __PHP:__ _7.0/7.1/7.2/7.3/...__
* __CMS:__ _WordPress 5.9.3..._
* __Database:__ _MariaDB 10.8/..._
* __Web Server:__ _Apache ..._
Comments
----------------------------------------
_Anything else you would like the reviewer to note._https://lab.civicrm.org/dev/core/-/issues/3794civicrm_admin_ui: Changes custom field groups to extend Contacts2022-08-11T01:07:11ZJonGoldcivicrm_admin_ui: Changes custom field groups to extend ContactsOverview
----------------------------------------
I have incomplete information, but it seems serious enough to report anyway.
Current behaviour
----------------------------------------
My client informed me that custom field groups ha...Overview
----------------------------------------
I have incomplete information, but it seems serious enough to report anyway.
Current behaviour
----------------------------------------
My client informed me that custom field groups had all changed to extend Contacts. I confirmed this. I then compared the advanced log tables to Apache logs.
There are a large number of calls to `POST /wp-admin/admin.php?page=CiviCRM&q=civicrm%2Fajax%2Fapi4`. Based on the advanced logs, I'm reasonably sure this was my client adjusting the weight of various fields. The first "real" GET request preceding this was `GET /wp-admin/admin.php?page=CiviCRM&q=civicrm%2Fadmin%2Fcustom%2Fgroup%2Fedit&action=update&reset=1&id=3&snippet=json`.
I'll also note that my client deleted some custom field groups just prior to this.
I'm uncertain of the version, since we had to switch to a beta to fix a different urgent issue, but it should be close to stock 5.51.colemanwcolemanwhttps://lab.civicrm.org/dev/core/-/issues/3793Path for imports through the UI causes permission issues2022-08-10T04:15:54ZbriennePath for imports through the UI causes permission issuesImports through the UI (such as Import Contributions from the Contributions menu) use the same path for the import summary page as the Import Contacts summary page in the UI (civicrm/import/contacts/summary). This causes the import to fa...Imports through the UI (such as Import Contributions from the Contributions menu) use the same path for the import summary page as the Import Contacts summary page in the UI (civicrm/import/contacts/summary). This causes the import to fail if the user does not have the "Import Contacts" permission, even if they do have the proper permissions for other imports.
I am currently working on a fix for this and should have a PR in the next few hours for the release candidate 5.53.
**Steps to Replicate:**
1. Login as a user who does not have the Import Contacts permission
2. Go to **Contributions > Import Contributions**
3. Go through the process of importing a csv file with a test contribution
4. After clicking **import now**, a queue runner will briefly pop up, and then the page will show an error message: "you are not authorized to access this page."
5. Note that the url is civicrm/import/contacts/summary
**Why:**
PR #23669 seems to have introduced this bug (in version 5.51), specifically in the [Import.xml file, lines 20-27](https://github.com/civicrm/civicrm-core/blob/d7a8ffbdd8ee5cf98f712358f261f023f7ebf015/CRM/Core/xml/Menu/Import.xml#L21)5.53.0https://lab.civicrm.org/dev/core/-/issues/3786CiviCRM 5.51, Import Participants when matching by External / Contact ID alwa...2022-08-09T04:21:33Zjustinfreeman (Agileware)CiviCRM 5.51, Import Participants when matching by External / Contact ID always matches to Contacts with ID < 10Import Participants when matching by External / Contact ID always matches to Contacts with ID < 10
This is due do an incorrectly replaced Error generation function in core commit [972906b](https://github.com/civicrm/civicrm-core/commit/...Import Participants when matching by External / Contact ID always matches to Contacts with ID < 10
This is due do an incorrectly replaced Error generation function in core commit [972906b](https://github.com/civicrm/civicrm-core/commit/972906b33960dd2126bcb5629faec188f6d1a8f9) (Merged for 5.51.0)
**Steps to reproduce**
1. Create a CSV with a Contact External ID or Contact ID, Event Title, Registration Status
2. Set up the import to match on Contact External ID or Contact ID
3. Map the other fields
4. Execute import
**Error**: Import will execute and create Participant records associated all with Contact ID: 1 or Contact ID: 2 (or another ID < ID:10). Not matching against the correct Contact ID.
Agileware Ref: CIVICRM-20255.52.2https://lab.civicrm.org/dev/core/-/issues/37845.51 regression - Contribution import - external id/contact id matches to wro...2022-08-09T04:22:24Znoah5.51 regression - Contribution import - external id/contact id matches to wrong recordsOverview
----------------------------------------
5.51 introduced a bug whereby contributions were assigned to the wrong contacts if external id or contact id was used as a matching field.
Reproduction steps
----------------------------...Overview
----------------------------------------
5.51 introduced a bug whereby contributions were assigned to the wrong contacts if external id or contact id was used as a matching field.
Reproduction steps
----------------------------------------
1. Make sure you have a contact whose id is 1.
2. Create another contact whose id *starts with* 1. E.g. 11, 1002...
3. Give the second contact an external identifier.
4. Create a CSV for contribution import; include an external id column; create a valid row that uses the external id from the last step.
5. Run the contribution import, using external identifier as a match-to-contact field.
Current behaviour
----------------------------------------
The imported contribution is attached to contact id 1.
Expected behaviour
----------------------------------------
The imported contribution should be attached to the contact with the specified external id.
Comments
----------------------------------------
PR forthcoming5.52.2https://lab.civicrm.org/dev/core/-/issues/3781Fatal Error on upgrade to 5.52.02022-08-18T23:26:03ZkcristianoFatal Error on upgrade to 5.52.0After upgrade from 5.51.3 to 5.52.0 the browser returns a 500 error.
php log shows:
```
[05-Aug-2022 11:41:51 UTC] PHP Fatal error: Declaration of Symfony\Component\DependencyInjection\ServiceLocator::has(string $id) must be compatible...After upgrade from 5.51.3 to 5.52.0 the browser returns a 500 error.
php log shows:
```
[05-Aug-2022 11:41:51 UTC] PHP Fatal error: Declaration of Symfony\Component\DependencyInjection\ServiceLocator::has(string $id) must be compatible with Psr\Container\ContainerInterface::has($id) in /home/wpcv/public_html/wp-content/plugins/civicrm/civicrm/vendor/symfony/dependency-injection/ServiceLocator.php on line 46
```
There is no corresponding entry in ConfigAndLog nor the apache error log
I thought it might be extended reports due to https://github.com/eileenmcnaughton/nz.co.fuzion.extendedreport/issues/516 But doing a git checkout of master first had no effect.
This had not come up in the testing I had done on generic sites, but this did occur on the first production site I upgraded. I'll look further as it may be something site-specific. Logging an issue in case any others have the same problem.
Env:
Apache 2.4
php 7.4
mariadb 10.3
WP 5.9.3
CiviCRM 5.52.0 (upgrade from 5.51.3)https://lab.civicrm.org/dev/core/-/issues/3774Can't submit backend credit card contribution unless you have at least one pa...2022-08-04T21:07:47ZJonGoldCan't submit backend credit card contribution unless you have at least one payment processor that supports a future start dateIf you don't have a payment processor that supports a future start date, you can't submit a credit card contribution.
### Steps to replicate
* On a buildkit site, add a PayPal Pro payment processor. The creds don't have to be valid.
* S...If you don't have a payment processor that supports a future start date, you can't submit a credit card contribution.
### Steps to replicate
* On a buildkit site, add a PayPal Pro payment processor. The creds don't have to be valid.
* Submit a backend credit card contribution with PayPal Pro. Should go through (or tell you invalid credentials).
* Delete the default processor of type "Dummy Payment Processor".
* Submit another backend credit card contribution with PayPal Pro.
### Expected Result
Absence of a dummy test processor shouldn't affect the ability to submit a credit card processor.
### Actual result
```
Please correct the following errors in the form fields below:
Date Received is a required field.
```
### Why
In `CRM_Contribution_Form_AbstractEditPayment::assignProcessors()` is this line:
```
$this->assign('processorSupportsFutureStartDate', CRM_Financial_BAO_PaymentProcessor::hasPaymentProcessorSupporting(['FutureRecurStartDate']));
```
This will return `TRUE` if *any* payment processor supports a future start date. Which in turn causes the `receive_date` to appear on `templates/CRM/Contribute/Form/Contribution.tpl`.
Without the `receive_date` on the form, even hidden, you can't submit the form.
The workaround is to create a dummy processor on your site. I have to run, but tomorrow I'll try to put together a PR that fixes this at the template level.
Is this a regression? I mean, technically yes, but it's two years old. And tricky to catch because the test suite creates the dummy processor in `setUp()`. To catch this we might have to move that out of `setUp()` and into its own helper function.5.52.0JonGoldJonGoldhttps://lab.civicrm.org/dev/core/-/issues/3767Import 'encountered an unexpected error' between Step 2 and 3 with 500 rows2022-08-16T22:38:33ZStoobImport 'encountered an unexpected error' between Step 2 and 3 with 500 rowsUsing 5.51.1 Import Contacts the error "The website encountered an unexpected error. Please try again later." This phrase occurs in the CiviCRM code base in several .php files, but is not a normal onscreen backtrace debug output and noth...Using 5.51.1 Import Contacts the error "The website encountered an unexpected error. Please try again later." This phrase occurs in the CiviCRM code base in several .php files, but is not a normal onscreen backtrace debug output and nothing giving more clues in Civi's log files that I can tell.
It occurs in this situation: a file of 500 rows x 30 columns after about 3 seconds of loading after pressing the button in Step 2 to continue to Step 3.
No error appears when that same file is split in half to only 250 rows.
I have tried this same full CSV file (500 rows) on a 5.50.4 install and there is no error.
The import for Individuals with typical data (name, email phone) but does contain several custom fields and an employer relationship. There are also some special characters (international names) I wonder if the import is not handling those well.
Although I cannot provide you my data I would be happy to test if you have a test bed and a way to generate similar testing data of this nature for an import. I hope this has been helpful.https://lab.civicrm.org/dev/core/-/issues/3766Patches for league/csv don't get patched for drupal 9 (https://github.com/civ...2022-08-02T18:53:22ZDaveDPatches for league/csv don't get patched for drupal 9 (https://github.com/civicrm/civicrm-core/pull/24046)It's not so much a regression as a recent change outputs warnings and doesn't work as intended, but effectively it's not doing anything different than before so it's not a functional bug yet.
After https://github.com/civicrm/civicrm-cor...It's not so much a regression as a recent change outputs warnings and doesn't work as intended, but effectively it's not doing anything different than before so it's not a functional bug yet.
After https://github.com/civicrm/civicrm-core/pull/24046
```
Applying patches for league/csv
https://raw.githubusercontent.com/civicrm/civicrm-core/cacdbfaeaed8e04d504bf2fc604536137c03abeb/tools/scripts/composer/leage_csv_fputcsv.patch (Adding in eol support to fputcsv for php8.1)
Could not apply patch! Skipping. The error was: Cannot apply patch https://raw.githubusercontent.com/civicrm/civicrm-core/cacdbfaeaed8e04d504bf2fc604536137c03abeb/tools/scripts/composer/leage_csv_fputcsv.patch
https://github.com/thephpleague/csv/commit/380f884922a6cdaaaaab3ad4bfc7d1d710af736e.patch (Remove deprecated flag from php8.1)
Could not apply patch! Skipping. The error was: Cannot apply patch https://github.com/thephpleague/csv/commit/380f884922a6cdaaaaab3ad4bfc7d1d710af736e.patch
https://github.com/thephpleague/csv/commit/613db0b20157a1114cb1f9a801bd4c9c1f609cdf.patch (Fix php8.1 deprecation errors part 1)
Could not apply patch! Skipping. The error was: Cannot apply patch https://github.com/thephpleague/csv/commit/613db0b20157a1114cb1f9a801bd4c9c1f609cdf.patch
https://github.com/thephpleague/csv/commit/49e2b08ca025ebaf87a904b5645f535c807b6f10.patch (Fix php8.1 deprecation errors part 2)
Could not apply patch! Skipping. The error was: Cannot apply patch https://github.com/thephpleague/csv/commit/49e2b08ca025ebaf87a904b5645f535c807b6f10.patch
https://github.com/thephpleague/csv/commit/b83e972caea3cd22e7aaf65c5cffff1d49b46b69.patch (Fix php8.1 notice issues part 3)
Could not apply patch! Skipping. The error was: Cannot apply patch https://github.com/thephpleague/csv/commit/b83e972caea3cd22e7aaf65c5cffff1d49b46b69.patch
```5.53.0https://lab.civicrm.org/dev/core/-/issues/3765Can't upgrade drupal 9 fully after https://github.com/civicrm/civicrm-core/pu...2022-07-31T01:19:31ZDaveDCan't upgrade drupal 9 fully after https://github.com/civicrm/civicrm-core/pull/24085 - compile plugin failshttps://github.com/civicrm/civicrm-core/pull/24085/files#r933814768
http_build_query gets defined in the new shim, ~~and then guzzle itself tries to redefine it but of course it doesn't check if someone else has defined it first since i...https://github.com/civicrm/civicrm-core/pull/24085/files#r933814768
http_build_query gets defined in the new shim, ~~and then guzzle itself tries to redefine it but of course it doesn't check if someone else has defined it first since it belongs to guzzle.~~ I'm not sure the reason but the error is
```
Compile: Generate CCL wrapper functions
> @php -r "require_once '.../vendor/autoload.php'; Civi\CompilePlugin\TaskTransfer::import(); \CCL\Tasks::template($GLOBALS[\Civi\CompilePlugin\TaskTransfer::GLOBAL_VAR]);"
PHP Fatal error: Cannot redeclare GuzzleHttp\http_build_query() (previously declared in ...\vendor\civicrm\civicrm-core\guzzle_php81_shim.php:29) in ...\web\core\includes\guzzle_php81_shim.php on line 29
Script @php -r "require_once '.../vendor/autoload.php'; Civi\CompilePlugin\TaskTransfer::import(); \CCL\Tasks::template($GLOBALS[\Civi\CompilePlugin\TaskTransfer::GLOBAL_VAR]);" handling the shell-runner event returned with error code 255
Fatal error: Cannot redeclare GuzzleHttp\http_build_query() (previously declared in ...\vendor\civicrm\civicrm-core\guzzle_php81_shim.php:29) in ...\web\core\includes\guzzle_php81_shim.php on line 29
Subcommand @composer compile returned with error code 255
```5.53.0https://lab.civicrm.org/dev/core/-/issues/3756hook_civicrm_geocoderFormat does not alter address components2022-08-03T00:27:09ZAllenShawhook_civicrm_geocoderFormat does not alter address components**Steps to repro:**
1. Create an extension named `geocoderformat` containing this hook implementation:
```
function geocoderformat_civicrm_geocoderFormat($geoProvider, &$values, $xml) {
$values['county_id'] = 2;
}
```
2. Install clean...**Steps to repro:**
1. Create an extension named `geocoderformat` containing this hook implementation:
```
function geocoderformat_civicrm_geocoderFormat($geoProvider, &$values, $xml) {
$values['county_id'] = 2;
}
```
2. Install clean civicrm 5.49.5, enable this extension, and configure geocoding (*eg set "Administer => Mapping => Geocoding Provider" to "Google"*).
3. For any contact, save a new address in California, being sure to leave the county field empty, and observe that the county is forced to "Contra Costa".
4. Install clean civicrm 5.51.1 (I think 5.51.0 will also demonstrate the problem), enable this extension, and configure geocoding.
3. For any contact, save a new address in California, being sure to leave the county field empty, and observe that the county is not altered.
**Best guess as to the cause:**
Changes in cb695d3e4baa5d332d3f7f4a1105bb2c090ec4ee (pinging @colemanw) caused `CRM_Utils_Hook::geocoderFormat('Google', $values, $xml)` to be called in a context in which `$values` is never used.
**Suggested solution:**
The `CRM_Utils_Geocode_Google::makeRequest()` method should receive `$values` as a parameter-by-reference.
I'm planning to submit a simple PR along those lines.5.52.0