Development issueshttps://lab.civicrm.org/groups/dev/-/issues2021-01-31T21:41:49Zhttps://lab.civicrm.org/dev/wordpress/-/issues/88Jquery error on wordpress 5.6 : I can't add custom data fields from the GUI2021-01-31T21:41:49ZjonathandhnJquery error on wordpress 5.6 : I can't add custom data fields from the GUIHi, I'm using Wordpress 5.6 and CiviCRM 5.33.2 and the field type input selector use a broken Jquery selector when I tried to add a custom data field.
![Screen shot](/uploads/84ec11dc8aba255b7321626ccdd824b6/Capture_d_écran_2021-01-20_...Hi, I'm using Wordpress 5.6 and CiviCRM 5.33.2 and the field type input selector use a broken Jquery selector when I tried to add a custom data field.
![Screen shot](/uploads/84ec11dc8aba255b7321626ccdd824b6/Capture_d_écran_2021-01-20_à_11.27.53.png)https://lab.civicrm.org/dev/core/-/issues/2317CiviMail, Tracked Opens and Unique Opens should also be counted when click-th...2023-06-17T00:00:49Zjustinfreeman (Agileware)CiviMail, Tracked Opens and Unique Opens should also be counted when click-through events occurs to workaround issues where the tracked open, pixel is blocked by the email clientCiviMail, Tracked Opens and Unique Opens should also be counted when click-through events occurs to workaround issues where the tracked open, pixel is blocked by the email client. Thus enabling some statistics to be captured and avoid si...CiviMail, Tracked Opens and Unique Opens should also be counted when click-through events occurs to workaround issues where the tracked open, pixel is blocked by the email client. Thus enabling some statistics to be captured and avoid situations where Tracked Opens and Unique Opens have a statistic of 0 but all the other metrics have non-zero numbers.
PS. I had always thought that this was already the case, but discovered otherwise whilst investigating a support request. Quite surprised.
This would also require a documentation change.
Agileware Ref: CIVICRM-1649https://lab.civicrm.org/dev/core/-/issues/2316Symfony 4.3+: CI warnings due to change in EventDispatcherInterface2024-02-27T23:15:40ZtottenSymfony 4.3+: CI warnings due to change in EventDispatcherInterfaceOverview
----------------------------------------
Symfony 4.3 changed the contract for `dispatch()`: https://symfony.com/blog/new-in-symfony-4-3-simpler-event-dispatching
Consequently, on systems running Symfony 4.3 or newer, there are ...Overview
----------------------------------------
Symfony 4.3 changed the contract for `dispatch()`: https://symfony.com/blog/new-in-symfony-4-3-simpler-event-dispatching
Consequently, on systems running Symfony 4.3 or newer, there are warnings about using the old contract.
Loosely, they swapped the order of the parameters (`$event`<=>`$eventName`), made `$eventName` optional, and (for the transition-period of 4.3+) allowed the parameters to be given in *either order*. For context, the signature evolution is roughly:
```php
public function dispatch(string $eventName, Event $event = null); // 2.x, 3.x, 4.0 - 4.2
public function dispatch(string|object $event, string|object $eventName = null); // 4.3+
public function dispatch(object $event, string $eventName = null); // 5.x
```
cc @seamuslee
Reproduction steps
----------------------------------------
Go to https://test.civicrm.org/job/CiviCRM-E2E-Matrix/ and view test results for drupal9-clean w/Civi 5.33 or 5.34
Current behaviour
----------------------------------------
When running E2E tests on Drupal 9, the test completes with a warning:
```
10x: Calling the "Symfony\Component\EventDispatcher\EventDispatcherInterface::dispatch()"
method with the event name as the first argument is deprecated since Symfony 4.3,
pass it as the second argument and provide the event object as the first argument instead.
```
Expected behaviour
----------------------------------------
No warnings... But the real question is how to achieve that. See "Comments".
Environment information
----------------------------------------
<!-- Some of the items below may not be relevant for every bug - if in doubt please include more information than you think is neccessary. -->
* __CiviCRM:__ 5.33
* __PHP:__ 7.3
* __CMS:__ D9
Comments
----------------------------------------
(A) Merely writing code to follow the new contract is not a problem. The main problem is the dependency-hell aspect -- e.g. one is likely to get squeezed between D8 (`symfony/event-dispatcher` 2.x-3.x), D9 (`symfony/event-dispatcher` 4.x), and D10 (presumed 5.x or later). The warning is telling you to prepare for Symfony 5.x. But doing so requires that you break away from Symfony 3.x. Put another way: *You cannot fix the warnings on Civi-D9 without breaking Civi-D8.*
(B) Here's an interesting tidbit: from the POV of a subclass of `EventDispatcher`, the Symfony 4.2=>4.3 update is a contract break. Implementations of `EventDispatcherInterface` which target 2.0-4.2 (e.g. Civi) should not be used by consumers which target 4.3+ (e.g. D9). However, to date, we have avoided any functional problem because (a) on a substantive level, the Civi and Drupal dispatchers are *de facto* separate subsystems with different contracts/audiences and (b) on a syntactic level, the 4.2/4.3 contracts are close enough to avoid hard compilation error.
(C) I think we have a few basic options:
* __Hard D8=>D10 Switch__: Ignore or discard the warnings for immediate future. Kill D8/S3 support sometime before adding D10/S5 support. Here are a couple variants on that:
* __Wait...Wait...Go!__: Drupal 8 support is [slated to end in November 2021](https://www.drupal.org/docs/understanding-drupal/drupal-9-release-date-and-what-it-means/what-happens-to-drupal-8-now-that). In theory, we could stop supporting Civi-D8/S3 for new releases after Nov 2021 -- and then begin the transition to the new contract. But we'd probably want to move this along quickly, since D10 is [slated for 2022](https://www.drupal.org/project/drupal/issues/3118143).
* __Major Version Alignment__: This could potentially be made easier-to-communicate if we do a major-version increment on Civi and setup version-alignment in the same way that Drupal/Symfony are doing (e.g. S3/D8/Cv5; S4/D9/Cv6; S5/D10/Cv7).
* __Break away from `symfony/event-dispatcher`__: `CiviEventDispatcher` would not (going forward, on S4+ builds) directly extend `symfony/event-dispatcher` classes. Instead, do one of these:
* __Hard fork__: Copy from `symfony/event-dispatcher` circa 4.2 and build out parallel classes with different namespace where we can control contracts/scheduling
* __Mapped namespace/Soft fork__: Update our build system (e.g. composer plugins) to allow multiple/coexisting versions of Symfony packages. These technically use the same code as `symfony/event-dispatcher`, but it's automatically rewritten to non-conflicting namespaces (along the lines of https://github.com/humbug/php-scoper).
* __Change to [PSR-14](https://www.php-fig.org/psr/psr-14/)__: A standard is meant to be more stable than an implementation. The problem here is the substance of the PSR-14 contract -- it's disagreeable with all of Civi's existing events, including/especially `hook_*` and `GenericHookEvent`.5.57.0https://lab.civicrm.org/dev/core/-/issues/2315CiviCRM Event, Feature Request. Expand the Require participant approval? feat...2023-06-16T05:03:32Zjustinfreeman (Agileware)CiviCRM Event, Feature Request. Expand the Require participant approval? feature to allow automatic approval based on contact being in one of specified list of Groups / Smart GroupsThis is a feature request. It would be useful to expand the Require participant approval? feature for Events to allow automatic approval based on contact being in one of specified list of Groups / Smart Groups. Thus when someone register...This is a feature request. It would be useful to expand the Require participant approval? feature for Events to allow automatic approval based on contact being in one of specified list of Groups / Smart Groups. Thus when someone registers, if they exist in any of the groups they are approved. If not, then their Participant Status is waiting for approval.
This feature would provide a more automated and intelligent approach for approving participants for an event, without requiring manual human intervention, as is the case currently.
Would require a documentation update, https://docs.civicrm.org/user/en/latest/events/online-event-registration/#participant-approval
Agileware Ref: CIVICRM-1647https://lab.civicrm.org/dev/core/-/issues/2314CiviCRM Event, Participant Approval feature for Events is disabled because th...2023-06-16T05:03:31Zjustinfreeman (Agileware)CiviCRM Event, Participant Approval feature for Events is disabled because the Participant Status options are disabled by default when CiviCRM is installedCiviCRM Event, Participant Approval feature for Events is disabled because the Participant Status options are disabled by default when CiviCRM is installed. This does not make a lot of sense, because the Participant Approval can be toggl...CiviCRM Event, Participant Approval feature for Events is disabled because the Participant Status options are disabled by default when CiviCRM is installed. This does not make a lot of sense, because the Participant Approval can be toggled on/off on a per Event basis.
Completely hiding the Participant Approval feature from the user interface, by default is an odd decision and one that I would argue should be changed so that it is enabled by default.
These are the Participant Statuses that need to be enabled for the Participant Approval feature to work.
![Screenshot_20210120_094108](/uploads/e52f0f378d92b64f7eaf7aaa11c68156/Screenshot_20210120_094108.png)
This change would require the documentation also be updated, https://docs.civicrm.org/user/en/latest/events/online-event-registration/#participant-approval
Agileware Ref: CIVICRM-1646https://lab.civicrm.org/dev/core/-/issues/2313Searchkit - activity record type not intuitive2021-02-01T21:08:14ZeileenSearchkit - activity record type not intuitiveSearches involving activity contacts are complicated - the lowest hanging fruit is probably the activity_contact.record_type_id title - Activity Contact Type?Searches involving activity contacts are complicated - the lowest hanging fruit is probably the activity_contact.record_type_id title - Activity Contact Type?5.35.0https://lab.civicrm.org/dev/core/-/issues/2312Searchkit - separate calls for results & count2021-02-01T03:28:04ZeileenSearchkit - separate calls for results & countSearch kit gives the appearance of doing nothing on a search with a slow-ish query but this is the count() part of the search. By separating this part out the user experience is much betterSearch kit gives the appearance of doing nothing on a search with a slow-ish query but this is the count() part of the search. By separating this part out the user experience is much better5.35.0https://lab.civicrm.org/dev/core/-/issues/2311Search-kit - specific search2021-03-07T23:20:33ZeileenSearch-kit - specific search@colemanw documenting this specific desired search
- contact has a donation where total_amount > x
- contact has no donations of financial type = y
https://phabricator.wikimedia.org/T271333@colemanw documenting this specific desired search
- contact has a donation where total_amount > x
- contact has no donations of financial type = y
https://phabricator.wikimedia.org/T271333https://lab.civicrm.org/dev/core/-/issues/2310Search-kit - better user experience for bulk updates2021-02-01T03:27:40ZeileenSearch-kit - better user experience for bulk updatesRequest that we provide feedback (progress bar) when doing a bulk update from search kit
I did a search for 100,000 activities via search kit, chose to update the date using the update option and selected 'update 100,000 activities'. No...Request that we provide feedback (progress bar) when doing a bulk update from search kit
I did a search for 100,000 activities via search kit, chose to update the date using the update option and selected 'update 100,000 activities'. Nothing happened. Except it did. Around about 20k activities were updated & we wound up with some js errors when it presumably timed out at the php level.
Being able to update large numbers is a winning feature of search kit - but it needs a progress bar5.35.0https://lab.civicrm.org/dev/core/-/issues/2309CiviCRM Find and Merge Duplicate Contacts, does not validate the weight and w...2021-02-16T14:50:20Zjustinfreeman (Agileware)CiviCRM Find and Merge Duplicate Contacts, does not validate the weight and weight threshold, possible to set a weight threshold which can never be achieved.CiviCRM Find and Merge Duplicate Contacts, does not validate the weight and weight threshold, possible to set a weight threshold which can never be achieved. Resulting in a defunct duplicate matching rule and lots of duplicate contacts.
...CiviCRM Find and Merge Duplicate Contacts, does not validate the weight and weight threshold, possible to set a weight threshold which can never be achieved. Resulting in a defunct duplicate matching rule and lots of duplicate contacts.
As shown in the screenshot below.
![Screenshot_20210119_123755](/uploads/ad5ca958cbed1ba9fcd0d0e7f0b73fd0/Screenshot_20210119_123755.png)
Agileware Ref: CIVICRM-16445.36.0Monish DebMonish Debhttps://lab.civicrm.org/dev/core/-/issues/2308Improve activity import to support updates2022-06-14T21:00:49ZeileenImprove activity import to support updatesAs I've delved through this code I don't think it makes sense for the checkbox about matching options to be used on the activity form. The reason for it on the contact form is the multiple possible options. For activity it is either an i...As I've delved through this code I don't think it makes sense for the checkbox about matching options to be used on the activity form. The reason for it on the contact form is the multiple possible options. For activity it is either an id match, if present, or nothing
I think ideally this would be dependent on activity id being mapped on the specified row - ie it could be possible to have a combination of with & without.
@DaveD tracking gl for this5.51.0https://lab.civicrm.org/dev/core/-/issues/2307Mapping a contact gives invalid argument supplied.2021-01-19T13:00:07ZspalmstromMapping a contact gives invalid argument supplied.Overview
----------------------------------------
_Please describe your problem or bug in detail._
_If you have already posted on https://civicrm.stackexchange.com or https://chat.civicrm.org, please include the link to that conversatio...Overview
----------------------------------------
_Please describe your problem or bug in detail._
_If you have already posted on https://civicrm.stackexchange.com or https://chat.civicrm.org, please include the link to that conversation._
Reproduction steps
----------------------------------------
1. Click on **Contact -> View**.
1. Click on **Map** by the postal address
1. You get ```Warning: Invalid argument supplied for foreach() in CRM_Utils_System_Drupal8->appendBreadCrumb() (line 193 of <Drupal root>/vendor/civicrm/civicrm-core/CRM/Utils/System/Drupal8.php)```
Current behaviour
----------------------------------------
Before seeing the map you get
Warning: Invalid argument supplied for foreach() in CRM_Utils_System_Drupal8->appendBreadCrumb() (line 193 of <Drupal root>/vendor/civicrm/civicrm-core/CRM/Utils/System/Drupal8.php)```
Expected behaviour
----------------------------------------
You should just see the map.
Environment information
----------------------------------------
* __Browser:__ _Edge_, but irrelevant
* __CiviCRM:__ _5.33.1_ <!-- If this problem relates to an upgrade, then specify both old and new versions -->
* __PHP:__ _7.4/_ but probably irrrelevant
* __CMS:__ _Drupal 9.1.2_ but the issue may occur elsewhere.
* __Database:__ _MySQL 8.0_ but probably irrelevant.
* __Web Server:__ _IIS 10_ but probably irrelevant.
Comments
----------------------------------------
_Anything else you would like the reviewer to note._
Line 170 of ```<CiviCRM core>/CRM/Contact/Form/Task/Map.php``` reads
```
CRM_Utils_System::appendBreadCrumb($bcTitle, $redirect);
```
However, the function in ```<CiviCRM core>/CRM/Utils/System/Drupal8.php``` say reads:
```
public function appendBreadCrumb($breadcrumbs) {
```
In other words, it is expecting a single parameter, no two, and that is an array.
The error can be cured by replacing the offending line with:
```
// CRM_Utils_System::appendBreadCrumb only takes one argument, an array
// of breadcrumbs, not two.
$breadcrumbs[0]['title'] = $bcTitle;
$breadcrumbs[0]['url'] = $redirect;
CRM_Utils_System::appendBreadCrumb($breadcrumbs);
```
In other words passing a breadcrumb array. Whilst I have only mentioned Drupal8.php, the other files have the same call interface, I believe.
The issue can be reproduced under [https://d9-master.demo.civicrm.org/civicrm/contact/map?reset=1&cid=186&lid=1](https://d9-master.demo.civicrm.org/civicrm/contact/map?reset=1&cid=186&lid=1) which is running 5.35.1 alpha if you enable Google mapping.
```
Warning: Invalid argument supplied for foreach() in CRM_Utils_System_Drupal8->appendBreadCrumb() (line 193 of /srv/buildkit/build/d9-master/vendor/civicrm/civicrm-core/CRM/Utils/System/Drupal8.php).
CRM_Utils_System_Drupal8->appendBreadCrumb('Contact', '/civicrm/contact/view?reset=1&cid=186') (Line: 60)
CRM_Utils_System::__callStatic('appendBreadCrumb', Array) (Line: 171)
CRM_Contact_Form_Task_Map::createMapXML(Array, 1, Object, 1, 'Contact') (Line: 92)
CRM_Contact_Form_Task_Map->preProcess() (Line: 608)
...
```5.35.0https://lab.civicrm.org/dev/core/-/issues/2306Fix rendering of Dashlet placeholder2021-01-18T21:15:14ZhaystackFix rendering of Dashlet placeholderOverview
----------------------------------------
When dragging a Dashlet in the Available Dashlets panel, the layout of the panel jumps unexpectedly.
Reproduction steps
----------------------------------------
1. Click on **Available D...Overview
----------------------------------------
When dragging a Dashlet in the Available Dashlets panel, the layout of the panel jumps unexpectedly.
Reproduction steps
----------------------------------------
1. Click on **Available Dashlets**.
1. Drag a Dashlet.
1. Notice layout jump.
Current behaviour
----------------------------------------
Dragging a Dashlet in the Available Dashlets panel causes the layout to jump unexpectedly.
Expected behaviour
----------------------------------------
Dragging a Dashlet in the Available Dashlets panel should not cause the layout to jump unexpectedly.
Comments
----------------------------------------
PR to follow.haystackhaystackhttps://lab.civicrm.org/dev/core/-/issues/2305Logging tables shown as 'different' incorrectly after upgrading to MariaDB 10...2021-02-01T21:21:42ZJKingsnorthLogging tables shown as 'different' incorrectly after upgrading to MariaDB 10.4.xWe recently upgraded to MariaDB 10.4.x and have been running into some problems with logging.
1) \CRM_Logging_Schema::columnsWithDiffSpecs - has an exception for dealing with 'timestamp' fields that default to the current timestamp (you...We recently upgraded to MariaDB 10.4.x and have been running into some problems with logging.
1) \CRM_Logging_Schema::columnsWithDiffSpecs - has an exception for dealing with 'timestamp' fields that default to the current timestamp (you don't want that to happen in the logging tables) however the format for how that is described by MariaDB has changed in recent versions of MariaDB:
https://mariadb.com/kb/en/now/
> When displayed in the INFORMATION_SCHEMA.COLUMNS table, a default CURRENT TIMESTAMP is displayed as CURRENT_TIMESTAMP up until MariaDB 10.2.2, and as current_timestamp() from MariaDB 10.2.3, due to to MariaDB 10.2 accepting expressions in the DEFAULT clause.
2) \CRM_Logging_Schema::columnsWithDiffSpecs - is showing this as a 'difference' for all id fields where the original table is not NULLABLE, but the logging table is NULLABLE and has a default of NULL. In this screenshot the 'original' table is displayed first, followed by the logging table:
![image](/uploads/7877a50bc74e5750ea9690220e00bf2d/image.png)
This is hitting the condition (same lines as above):
```
elseif ($civiTableSpecs[$col]['COLUMN_DEFAULT'] != CRM_Utils_Array::value('COLUMN_DEFAULT', $logTableSpecs[$col]) &&
!strstr($civiTableSpecs[$col]['COLUMN_DEFAULT'], 'TIMESTAMP')
) {
```
My guess is that the COLUMN_DEFAULT was not 'NULL' by default prior to our upgrade to MariaDB 10.4.x, or it's reporting it differently through the SHOW TABLE / COLUMNS commands? I suggest we alter the elseif to account for this case.
---
The symptom of these is that it tries to ALTER all the applicable ID columns every time an extension is enabled, which times out if your logging tables are large. Because it doesn't actually change the schema, it does this _every_ time an extension is enabled/disabled. Or when fixSchemaDifferences is triggered.
---
PR: incoming5.35.0https://lab.civicrm.org/dev/core/-/issues/2304Mailing List Subscription page does not display authenticated users their exi...2023-06-16T19:32:16Zjustinfreeman (Agileware)Mailing List Subscription page does not display authenticated users their existing group subscriptions, therefore unable to determine which groups to subscribe or unsubscribeThe built-in CiviCRM Mailing List Subscription page (/civicrm/mailing/subscribe/?reset=1) does not display authenticated users their existing group subscriptions, therefore they are unable to determine which groups to subscribe or unsubs...The built-in CiviCRM Mailing List Subscription page (/civicrm/mailing/subscribe/?reset=1) does not display authenticated users their existing group subscriptions, therefore they are unable to determine which groups to subscribe or unsubscribe. It would be great to add this as a feature. Would make this page much more useful.
Agileware Ref: CIVICRM-1641https://lab.civicrm.org/dev/core/-/issues/2303Token plan - what is it2021-10-12T02:27:21ZeileenToken plan - what is itAt the moment I'm looking at the civimember backoffice code and there is a lot of mess around the tokens in the receipts - it's hard to fix it up without knowing where we are going. The receipt template is shared between 3 forms Back off...At the moment I'm looking at the civimember backoffice code and there is a lot of mess around the tokens in the receipts - it's hard to fix it up without knowing where we are going. The receipt template is shared between 3 forms Back office membership, Back office membership renewal, back office batch entry.
Broadly speaking there are 5 types of tokens in the receipt
1) form specific - this is text entered on the form that is not stored in the db. I think there might be one other submission dependent variable
2) membership specific - this are various values relating to the membership or memberships in the form
3) contribution specific - only one contribution would ever be relevant to the given form
4) contact specific
5) weird invoicing format
| token | notes |
| ------ | ------ |
| {contact.email_greeting} | loaded from token system |
| {$customValues}|Name=>value array of fields that were present on the form - not batch|
| {$formValues.total_amount}| contribution.total_amount|
| {$formValues.contributionType_name} | contribution.financial_type|
| {$totalTaxAmount}| contribution.tax_amount|
| {$formValues.total_amount} | contribution.total_amount|
| {$receive_date} | contribution.receive_date|
| {$currency}| contribution.currency|
| {$formValues.paidBy} | contribution.payment_instrument|
| {$formValues.check_number}| contribution.check_number|
| {$membership_name}| used for single quick-config membership|
| {$membership_start_date}| used for single quick-config membership|
| {$membership_end_date}| used for single quick-config membership|
| {$lineItem}|When quick config is not in use this is iterated to present line item details, could be loaded from contribution|
| {$dataArray}| Augments lineItem with tax details when invoicing is enabled|
| {$cancelled} | I think this is never assigned|
| {$isPrimary}| Appears to be unnecessary as inner ifs achieve the same|
| {$billingName}| submission specific from payment form|
| {$address}|submission specific from payment form|
| {$credit_card_type}|submission specific from payment form|
| {$credit_card_number}|submission specific from payment form - field is just the last 4 digits|
| {$credit_card_exp_date|submission specific from payment form|
| {$formValues.receipt_text_signup} | submission-specific, no reason not to just use {$formValues.receipt_text} for both|
| {$formValues.receipt_text_renewal} | submission-specific, no reason not to just use {$formValues.receipt_text} for both|
|{$headerStyle}| assigned within the template, if we ever moved logo to db would look at moving to a db-stored message header or field|
|{$labelStyle}| as above|
|{$valueStyle}| as above|
| {$logo}| Not available but we really should offer this as a token
| {$messageHeader}| Not available but we really should offer this as a token|https://lab.civicrm.org/dev/drupal/-/issues/153Drupal 8 profile validation not finding the right profile when validating sub...2023-02-15T06:04:10ZDaveDDrupal 8 profile validation not finding the right profile when validating submission on CMS user tabsIn drupal 8/9, like in drupal 7, the CMS user record by default has the Name and Address profile available for editing on the CMS side. As noted in passing at https://lab.civicrm.org/dev/drupal/-/issues/117#note_40124 the validation for ...In drupal 8/9, like in drupal 7, the CMS user record by default has the Name and Address profile available for editing on the CMS side. As noted in passing at https://lab.civicrm.org/dev/drupal/-/issues/117#note_40124 the validation for this form isn't working fully in drupal 8/9.
It appears to be a name vs label problem. The drupal 8 implementation uses the label to look up the profile. I have a quickie fix below but am mulling it over a bit since there's a lot of other things wrong with this form, e.g.
* https://lab.civicrm.org/dev/drupal/-/issues/113
* https://lab.civicrm.org/dev/drupal/-/issues/117
* https://lab.civicrm.org/dev/core/-/issues/2301
```diff
index 37e7ead..b18bb04 100644
--- a/src/Form/UserProfile.php
+++ b/src/Form/UserProfile.php
@@ -75,7 +75,12 @@ class UserProfile extends FormBase {
$this->profile = $profile;
// Search for the profile form, otherwise generate a 404.
- $uf_groups = \CRM_Core_BAO_UFGroup::getModuleUFGroup('User Account');
+ $uf_groups = \CRM_Core_BAO_UFGroup::getModuleUFGroup('User Account', 0, TRUE, \CRM_Core_Permission::VIEW, array(
+ 'id',
+ 'name',
+ 'title',
+ 'is_active',
+ ));
if (empty($uf_groups[$profile])) {
throw new ResourceNotFoundException();
}
@@ -109,7 +114,7 @@ class UserProfile extends FormBase {
* {@inheritdoc}
*/
public function validateForm(array &$form, FormStateInterface $form_state) {
- $errors = \CRM_Core_BAO_UFGroup::isValid($this->contactId, $this->ufGroup['title']);
+ $errors = \CRM_Core_BAO_UFGroup::isValid($this->contactId, $this->ufGroup['name']);
if (is_array($errors)) {
foreach ($errors as $name => $error) {
```
Relatedly, this seems an odd return value if it couldn't find the profile. Shouldn't it return an error?
https://github.com/civicrm/civicrm-core/blob/a7b9631b60548092f8c3056c375dd4b81606dbd4/CRM/Core/BAO/UFGroup.php#L785
FYI @alandixon @spalmstrom5.59.0https://lab.civicrm.org/dev/core/-/issues/2302Recaptcha causing contribution forms to fail due to duplicate recaptcha submi...2023-07-15T05:03:20ZddsystemsRecaptcha causing contribution forms to fail due to duplicate recaptcha submission.I’ve tracked down the captcha issue on the contribution form, it is related to the fact that the recaptcha rules are being set twice, so the first one succeed, but the second one fails. What I’ve found is in this file:
./wp-content/plu...I’ve tracked down the captcha issue on the contribution form, it is related to the fact that the recaptcha rules are being set twice, so the first one succeed, but the second one fails. What I’ve found is in this file:
./wp-content/plugins/civicrm/civicrm/CRM/Contribute/Form/Contribution/Main.php starting at line 284
$this->buildCustom($this->_values['custom_pre_id'], 'customPre');
$this->buildCustom($this->_values['custom_post_id'], 'customPost');
These functions reference the buildCustom function found in:
./wp-content/plugins/civicrm/civicrm/CRM/Contribute/Form/ContributionBase.php at line 612
At the bottom of this function (around line 766) there is the following logic
if ($addCaptcha && !$viewOnly) {
$this->enableCaptchaOnForm();
}
The function this references is just a few lines below this call.
Since Civicrm seems to store the rules in a non-associative array you can have multiple rules with the same name, and it ends up checking each one of them, and due to the nature of recaptcha, a validation is only good once, so when it tries to validate the second time it will inevitably fail and throw the captcha error.https://lab.civicrm.org/dev/wordpress/-/issues/87Recaptcha causing contribution forms to fail due to duplicate recaptcha submi...2021-01-16T15:36:35ZddsystemsRecaptcha causing contribution forms to fail due to duplicate recaptcha submission.I’ve tracked down the captcha issue on the contribution form, it is related to the fact that the recaptcha rules are being set twice, so the first one succeed, but the second one fails. What I’ve found is in this file:
./wp-content/plu...I’ve tracked down the captcha issue on the contribution form, it is related to the fact that the recaptcha rules are being set twice, so the first one succeed, but the second one fails. What I’ve found is in this file:
./wp-content/plugins/civicrm/civicrm/CRM/Contribute/Form/Contribution/Main.php starting at line 284
$this->buildCustom($this->_values['custom_pre_id'], 'customPre');
$this->buildCustom($this->_values['custom_post_id'], 'customPost');
These functions reference the buildCustom function found in:
./wp-content/plugins/civicrm/civicrm/CRM/Contribute/Form/ContributionBase.php at line 612
At the bottom of this function (around line 766) there is the following logic
if ($addCaptcha && !$viewOnly) {
$this->enableCaptchaOnForm();
}
The function this references is just a few lines below this call.
Since Civicrm seems to store the rules in a non-associative array you can have multiple rules with the same name, and it ends up checking each one of them, and due to the nature of recaptcha, a validation is only good once, so when it tries to validate the second time it will inevitably fail and throw the captcha error.https://lab.civicrm.org/dev/core/-/issues/2301Warning: count(): Parameter must be an array or an object that implements Cou...2023-01-11T16:31:48ZspalmstromWarning: count(): Parameter must be an array or an object that implements Countable when saving My Profile or Name and AddressOverview
----------------------------------------
_Please describe your problem or bug in detail._
_If you have already posted on https://civicrm.stackexchange.com or https://chat.civicrm.org, please include the link to that conversatio...Overview
----------------------------------------
_Please describe your problem or bug in detail._
_If you have already posted on https://civicrm.stackexchange.com or https://chat.civicrm.org, please include the link to that conversation._
Reproduction steps
----------------------------------------
1. Click on **My Account**.
1. Click on the **Edit** tab.
1. Click on **Name and Address** tab.
1. Get the warning message.
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._
```
Warning: count(): Parameter must be an array or an object that implements Countable in include() (line 15 of sites\default\files\civicrm\templates_c\en_GB\%%4D\4DC\4DC76B26%%body.tpl.php).
```
Note that this appears to be instance dependent. I had one instance that showed it, and one that did not.
Expected behaviour
----------------------------------------
_What should happen._
No error message.
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 necessary. -->
* __Browser:__ Edge_ but probably irrelevant.
* __CiviCRM:__ _5.33.1_ <!-- If this problem relates to an upgrade, then specify both old and new versions -->
* __PHP:__ _7.4__ but probably irrelevant.
* __CMS:__ _Drupal 9.1.2_
* __Database:__ _MySQL 8.0_
* __Web Server:__ _IIS 10_
Comments
----------------------------------------
_Anything else you would like the reviewer to note._
This is not always reproducible. It can be cured by the following change to
```
<Drupal Root> web/custom-civicrm/templates/CRM/Form/body.tpl
```
```
+++ b/body
@@ -14,10 +14,7 @@
{if $form.hidden}
<div>{$form.hidden}</div>
{/if}
-{if (isset($form.errors))}
- {*
- If $form.errors isn't set, we get warning messages
- *}
+
{if ($snippet !== 'json') and !$suppressForm and count($form.errors) gt 0}
<div class="messages crm-error">
<i class="crm-i fa-exclamation-triangle crm-i-red" aria-hidden="true"></i>
@@ -33,7 +30,6 @@
</ul>
</div>
{/if}
-{/if}
{* Add all the form elements sent in by the hook *}
{if $beginHookFormElements}
```
If there has been an error, one would expect $form.errors to be set.5.59.0Monish DebMonish Deb