CiviCRM Core issueshttps://lab.civicrm.org/dev/core/-/issues2023-01-02T17:47:01Zhttps://lab.civicrm.org/dev/core/-/issues/3782Don't prevent contact with Cancelled membership from signing up online2023-01-02T17:47:01Zmattwiremjw@mjwconsult.co.ukDon't prevent contact with Cancelled membership from signing up onlineContribution page prevents signing up for a membership if the matched contact has an existing cancelled membership of the same type.
I don't really understand why https://github.com/civicrm/civicrm-core/pull/3531 ever got merged given t...Contribution page prevents signing up for a membership if the matched contact has an existing cancelled membership of the same type.
I don't really understand why https://github.com/civicrm/civicrm-core/pull/3531 ever got merged given that it seems no-one was in favour of restricting memberships in this way: https://issues.civicrm.org/jira/browse/CRM-14645
A restriction such as this could easily be put in place via the `validateForm` hook for anyone who actually needs it and it seems a pretty obscure restriction to have hardcoded in core.5.56.0https://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/3780Add an ability to set a field as hidden in formbuilder2023-12-21T07:20:06ZKurund JalmiAdd an ability to set a field as hidden in formbuilderKurund JalmiKurund Jalmihttps://lab.civicrm.org/dev/core/-/issues/3779Add display only field support for formbuilder2024-02-02T01:19:18ZKurund JalmiAdd display only field support for formbuildercolemanwcolemanwhttps://lab.civicrm.org/dev/core/-/issues/3778Event participant registered by contact ID2023-09-04T08:05:09Zmattwiremjw@mjwconsult.co.ukEvent participant registered by contact IDSee discussion at https://github.com/civicrm/civicrm-core/pull/23936
The existing field "registered_by_id" has a number of problems:
It does not get set if you add a registration via the backend forms.
It always gets set to the primary...See discussion at https://github.com/civicrm/civicrm-core/pull/23936
The existing field "registered_by_id" has a number of problems:
It does not get set if you add a registration via the backend forms.
It always gets set to the primary participant even when the user selects "Not X, or want to register a different person" (ie. URL has the parameter cid=0).
The "registered_by_id" field requires a participant ID and not a contact ID. This means that you cannot record that you registered one or more participants unless you are also a participant of that event.
Why not change registered_by_id to a contact ID? That's likely to have all sorts of unexpected impacts as the existing field is used in various wonderful ways (eg. registration emails behave a bit differently if there is a registered_by_id).
Does this fix everything?
No, not yet. That will require more work on the UI / mailing side of things to use the new field. But it's accessible as part of the Participant entity which means it can be used via the API and with searchkit.
This PR includes a little bit of UI work on the backend event participant form to allow you to set the new "registered by contact" field and this form will prefer that field.
What about setting the primary participant ID when they weren't the one registering?
Yes, this PR fixes that. It checks if the contact ID on the form is the same as the primary participant contact ID. If it's not it won't set the registered_by_id field.
Core patches:
- ~~https://github.com/civicrm/civicrm-core/pull/24167 - Add created_id field to civicrm_participant~~ merged
- ~~https://github.com/civicrm/civicrm-core/pull/24304 - Add code hook to set civicrm_participant.created_id~~ merged
- https://github.com/civicrm/civicrm-core/pull/24749 - Add 'Registered by Contact ID' to civireport
- _Need to extract patches from https://github.com/civicrm/civicrm-core/pull/23936 for Quickform UI etc._
- https://github.com/civicrm/civicrm-core/pull/24750 - Work in progress for participant forms.https://lab.civicrm.org/dev/core/-/issues/3777Afform: Radios should show default value when form is loaded/reset2023-09-02T05:11:54Zmattwiremjw@mjwconsult.co.ukAfform: Radios should show default value when form is loaded/resetSee #3449, #3450, https://github.com/civicrm/civicrm-core/pull/23413 (testing comments from @artfulrobot )
If you select a default value the filter is applied but it is not shown as "selected" when the form is loaded/reset.See #3449, #3450, https://github.com/civicrm/civicrm-core/pull/23413 (testing comments from @artfulrobot )
If you select a default value the filter is applied but it is not shown as "selected" when the form is loaded/reset.Kurund JalmiKurund Jalmihttps://lab.civicrm.org/dev/core/-/issues/3776CiviCRM - next version? Getting fit for future...2022-08-24T03:00:46ZTobias KrauseCiviCRM - next version? Getting fit for future...Sorry if this ticket is too general but I don't know where to go with my concerns.
We just updated our servers to PHP 8.0 (which was released im November 2020) and then I found some warnings in the logs about deprecated code. To find th...Sorry if this ticket is too general but I don't know where to go with my concerns.
We just updated our servers to PHP 8.0 (which was released im November 2020) and then I found some warnings in the logs about deprecated code. To find the reasons for these I diged into the code basis of CiviCRM and I found out that CiviCRM relys on very old frameworks (e.g. Smarty version 2.6 from the year 2016) or on frameworks not really actively maintained (zetacomponents/mail from the year 2020). Just two examples but I feel if I would check the other dependencies there might be some more old frameworks.
The tip for now from the Civi-community: stay on PHP 7.4 - which will reach end of life by November this year. Even PHP 8.0 will just receive security updates until November this year so that from November on PHP 8.1 would be the correct version - on which CiviCRM is absolutely not working as I already tested.
Now I got very concerned about the next years. We heavily use CiviCRM in our daily work for the administration of thousands of donators and newsletter subscribers and for the newsletter sending so that CiviCRM is the main tool of our daily work. And now CiviCRM already feels a little bit like a dinosaur to me - especially compared with Drupal 9 I am working with in general. I fear that CiviCRM cannot keep up with the ongoing developments of PHP (and JavaScript).
My question: are there any plans for updating the dependencies? Maybe even a plan to change to more modern frameworks like Twig? I found a roadmap where Form Builder, CiviCRM Standalone and UI Improvements are listed but this feels just like some new features based on the current code basis.https://lab.civicrm.org/dev/core/-/issues/3775Disable Deadlock retries for Mailing Jobs2024-03-24T05:03:28ZseamusleeDisable Deadlock retries for Mailing JobsSo CiviCRM added a feature which re-tries the same query x number of times by default that is 3 when either a deadlock or a lock wait timeout is hit which is useful, but in the concept of mailing job processing it is not so useful becaus...So CiviCRM added a feature which re-tries the same query x number of times by default that is 3 when either a deadlock or a lock wait timeout is hit which is useful, but in the concept of mailing job processing it is not so useful because it means it can get tied up on get_lock queries re-trying them a silly number of times when it should be moving onto the next thingseamusleeseamusleehttps://lab.civicrm.org/dev/core/-/issues/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/3773Deprecated function: Required parameter $sortCriteria follows optional parame...2024-03-20T05:03:26ZTobias KrauseDeprecated function: Required parameter $sortCriteria follows optional parameter $countEverytime cron runs I see this message in logs:
`Deprecated function: Required parameter $sortCriteria follows optional parameter $count in include() (line571 in /var/www/civi_live/vendor/composer/ClassLoader.php)`
After searching a li...Everytime cron runs I see this message in logs:
`Deprecated function: Required parameter $sortCriteria follows optional parameter $count in include() (line571 in /var/www/civi_live/vendor/composer/ClassLoader.php)`
After searching a little bit the only place which makes sense for this message is ezcMailImapTransport->sortFromOffset() in vendor/zetacomponents/mail/src/transports/imap/imap_transport.php
My setup:
- drupal 9.3.19
- CiviCRM 5.51.1
- PHP 8.0
I don't knowwhere this dependency comes from but this library needs an update for PHP 8.0 - or it should be considered to use another dependency. For IMAP handling I have good experiences with https://github.com/ddeboer/imaphttps://lab.civicrm.org/dev/core/-/issues/3772Notice: Undefined offset: 18 in CRM_Member_Form_Task_Batch->buildQuickForm()2022-08-03T21:11:30ZRobert J. LangNotice: Undefined offset: 18 in CRM_Member_Form_Task_Batch->buildQuickForm()Getting lots of log reports of the form
Notice: Undefined offset: 18 in `CRM_Member_Form_Task_Batch->buildQuickForm()` (line 144 of /.../civicrm/CRM/Member/Form/Task/Batch.php).
This is because the offending line is
```
CR...Getting lots of log reports of the form
Notice: Undefined offset: 18 in `CRM_Member_Form_Task_Batch->buildQuickForm()` (line 144 of /.../civicrm/CRM/Member/Form/Task/Batch.php).
This is because the offending line is
```
CRM_Utils_System::isNull($entityColumnValue[$typeId])
```
and it should be
```
CRM_Utils_System::isNull($entityColumnValue[$typeId] ?? NULL)
```5.53.0https://lab.civicrm.org/dev/core/-/issues/3771Undefined array key "rows" in Search.tpl.php when entering "Manage Groups"2022-08-19T13:10:03ZTobias KrauseUndefined array key "rows" in Search.tpl.php when entering "Manage Groups"Whenever a user comes to "Manage groups" (/civicrm/group) the PHP warning appears:
`Warning: Undefined array key "rows" in include() (line 6 of sites/default/files/civicrm/templates_c/en_US/%%7A/7A2/7A24E297%%Search.tpl.php).`
It comes...Whenever a user comes to "Manage groups" (/civicrm/group) the PHP warning appears:
`Warning: Undefined array key "rows" in include() (line 6 of sites/default/files/civicrm/templates_c/en_US/%%7A/7A2/7A24E297%%Search.tpl.php).`
It comes from CRM/Group/Form/Search.tpl:
`<div class="crm-accordion-wrapper crm-search_builder-accordion {if $rows and empty($showSearchForm)}collapsed{/if}">`
Seems that this code is not correct anymore as stated by Demerit's answer?! https://civicrm.stackexchange.com/questions/42384/undefined-array-key-rows-in-search-tpl-php-when-entering-manage-groups5.54.0https://lab.civicrm.org/dev/core/-/issues/3770Figure out how to offer preferredLanguage in api explorer with options2024-03-20T05:03:26ZeileenFigure out how to offer preferredLanguage in api explorer with optionsFrom discussion of adding preferredLanguage - options should be explorer-discoverable
https://github.com/civicrm/civicrm-core/pull/24116#pullrequestreview-1057986655From discussion of adding preferredLanguage - options should be explorer-discoverable
https://github.com/civicrm/civicrm-core/pull/24116#pullrequestreview-1057986655https://lab.civicrm.org/dev/core/-/issues/3768Improvement to Case Detail report2024-03-22T05:03:27ZyashodhaImprovement to Case Detail reportExpose some of the useful columns and filters :
- expose city in case detail report
- add filter for 'Activity type of the last activity'Expose some of the useful columns and filters :
- expose city in case detail report
- add filter for 'Activity type of the last activity'yashodhayashodhahttps://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/3764AuthX: API explorer URL wrong for WordPress2022-07-29T03:42:47ZMichael McAndrewAuthX: API explorer URL wrong for WordPressI think that the URL that the API explorer spits out for WordPress for authx is wrong.
Testing on a fresh buildkit install...
```shell
# Does not work!
CRM_URL='http://wp-demo.localhost:7979/wp-admin/admin.php?page=CiviCRM&q=civicrm%2F...I think that the URL that the API explorer spits out for WordPress for authx is wrong.
Testing on a fresh buildkit install...
```shell
# Does not work!
CRM_URL='http://wp-demo.localhost:7979/wp-admin/admin.php?page=CiviCRM&q=civicrm%2Fajax%2Fapi4%2FContact%2Fget'
# Works!
CRM_URL='http://wp-demo.localhost:7979/civicrm/ajax/api4/Contact/get'
CRM_AUTH='X-Civi-Auth: Bearer 123'
curl -X POST -H "$CRM_AUTH" "$CRM_URL" \
-d 'params=%7B%22limit%22%3A25%7D'
```
I assume that WordPress is going to always be in control of authentication to `wp-admin/admin.php` urls and hence that URL in the first example will never work.
@colemanw - it looks like you wrote the code that displays this - Adding a true param to the resUrl var to make it public fixes the issue I think. Will submit a PR...5.53.0https://lab.civicrm.org/dev/core/-/issues/3763Search Kit: Can't save data segments when two datepickers are present2022-10-05T23:02:48ZJonGoldSearch Kit: Can't save data segments when two datepickers are presentVideo shows replication steps, screenshot shows the final state of the form so it's easy to replicate.
Note that you don't need to create a second condition if the first condition uses "BETWEEN".![data-segment-save](/uploads/e327cf654310...Video shows replication steps, screenshot shows the final state of the form so it's easy to replicate.
Note that you don't need to create a second condition if the first condition uses "BETWEEN".![data-segment-save](/uploads/e327cf654310d9605871f4effca59619/data-segment-save.mp4)![Selection_1597](/uploads/4b907205661da04e25209e0a5e74488e/Selection_1597.png)5.53.0https://lab.civicrm.org/dev/core/-/issues/3759Logging table schemas should be updated when extension table schemas are updated2024-03-29T05:03:27ZJonGoldLogging table schemas should be updated when extension table schemas are updatedI just ran into an issue while enabling Geocoder on a relatively fresh Civi install. `install.sql` generated a table, then `hook_civicrm_managed` tried adding all those record in `.mgd.php`, which failed because `log_civicrm_geocoder` d...I just ran into an issue while enabling Geocoder on a relatively fresh Civi install. `install.sql` generated a table, then `hook_civicrm_managed` tried adding all those record in `.mgd.php`, which failed because `log_civicrm_geocoder` didn't exist.
I know this isn't a simple lift - but given the recent conversations that `civix` might phase out the generation of `.sql` files, this seems like the opportune moment to raise the issue.