CiviCRM Options fields and PHP 8

Looks like a problem in civicrm and not in the w_c module. The params sent from webform_civicrm is unchanges in PHP v7.4 & v8. There's an issue already raised in core - https://lab.civicrm.org/dev/core/-/issues/3942. I think this ticket should be fixed by the same.

Above core issue is closed now. PR https://github.com/civicrm/civicrm-core/pull/23305 fixes the problem. Should be a part of CiviCRM version 5.58.

I found that the PR Jitendra mentions doesn't fix the problem when FALSE is passed - just an empty array. I wrote a second patch https://github.com/colemanw/webform_civicrm/pull/829 but my coworker couldn't replicate the issue so we closed it. Mentioning it just in case someone finds this problem persisting after they upgrade to 5.58.

I don't think it is an issue with Civi. I tested it with module version 6.2.2 and 6.2.1 using the same Civi code and it works with the older version of the module.

@roblog it's tricky - there are two very closely related bugs. Could you please try applying my patch https://github.com/colemanw/webform_civicrm/pull/829 and see if it fixes the problem?

If not, does applying https://github.com/civicrm/civicrm-core/pull/23305 to your CiviCRM fix the bug?

@MegaphoneJon,
I just wanted to comment that I have a D7/CiviCRM 5.57.0 website (with Webform CiviCRM) that we recently pushed to Drupal 8.1 and have experienced WSOD on submissions where the culprit appears to be a single checkbox that is linked to a CiviCRM text checkbox field.

I applied the patch from your PR and it appears to have resolved the issue: https://github.com/civicrm/civicrm-core/pull/23305/files

Cheers,
Andrew

@Megaphonejon, the w_c patch (829) had no effect. The Civi patch (23305) fixed the second of my issues but not the first.

So a field set to Live Options, but with no default value set, and no submission value works with the second patch applied.

But a field set to Static Options but with only a single option enabled, and a default value submitted still does not work with either patch and gives the following error:

TypeError: array_filter(): Argument #1 ($array) must be of type array, string given in array_filter() (line 726 of ~/httpdocs/web/modules/contrib/webform/src/Plugin/WebformElement/OptionsBase.php)

@roblog I saw that error fairly recently, and it had to do with how the default value was set. Having anything in the "Value" box on the "General" tab when configuring the field caused this. Is that perhaps the issue?

@Megaphonejon, the Value field is empty. Here is the YAML for the field:

civicrm_1_activity_1_activity_activity_type_id:
  '#type': civicrm_options
  '#title': 'Activity Type'
  '#civicrm_live_options': 0
  '#options':
    58: 'Resident survey'
  '#default_value':
    - '58'
  '#access_create_roles':
    - administrator
  '#access_update_roles':
    - administrator
  '#access_view_roles':
    - administrator
  '#extra':
    aslist: 1
    multiple: 0
  '#form_key': civicrm_1_activity_1_activity_activity_type_id
  '#parent': civicrm_1_activity_1_fieldset_fieldset
  '#default_option': '58'

I still think the default may be at play. What happens if you remove the last line of that YAML? I know that may be necessary functionality but it would be good to isolate the bug.

Does not solve the problem I'm afraid.

@roblog Can you test this patch please - https://github.com/colemanw/webform_civicrm/pull/839

I've replicated the problem in a test and have included the test in the PR so it does not regress again.

Thanks.

@jitendrapurohit Apologies for taking so long to reply. I'm afraid that I still get the same error message after applying the patch:

TypeError: array_filter(): Argument #1 ($array) must be of type array, string given in array_filter() (line 726 of /modules/contrib/webform/src/Plugin/WebformElement/OptionsBase.php)

Although I should mention the patch was applied to a site running version 6.2.3 whereas I originally reported it with module 6.2.2. (Just thought I would mention in case it is relevant.)

@awasson I missed your message earlier that https://github.com/colemanw/webform_civicrm/pull/829 solved your issue. Are you able to provide a form that reliably has the error? I'd love to get this merged but I don't feel like I have the evidence to prove it fixes a problem.

@MegaphoneJon,
Yes, I have a form for membership applications and in one membership category a single checkbox is optional.

Prior to applying the changes at https://github.com/civicrm/civicrm-core/pull/23305/files it would fail 10/10 times. I manually added the changes to my copy of the site and the error has not shown up since. It is absolutely necessary.

Cheers,
Andrew

@roblog With the steps mentioned in the description, I can still replicate the issue and confirm that PR 839 fixes the problem immediately after being applied.

Can you pls try using the latest webform + webform civicrm and then apply 839 to see if it fixes?

If it fails, please attach the affected webform here so we can look further.

Thanks.

https://patch-diff.githubusercontent.com/raw/colemanw/webform_civicrm/pu...
won't apply on Version: 6.2.4

PR 839 applies to 6.x but tests where likely run prior to us adding D10/PHP8 to the test matrix. I'll add a trivial commit to re-trigger the tests to see if we can catch the TypeError.

Ok I've done that -> tests (including D10/PHP 8) are running now ->

And the results are in: PR 539 passes on Drupal 10 / PHP 8 / dev-master

@KarinG Do you mean PR 839 rather than 539?

The patch from https://github.com/colemanw/webform_civicrm/pull/839/files doesn't apply to webform_civicrm 6.2.4.
If manually applied to v 6.2.4, I still had an issue.

Along with the patch changes, I found I also had to add

if (gettype($val) == 'array'){
$element['#webform_multiple'] = true;
}

in function _fillCiviCRMData.
Hope this helps someone.

Yes I mean PR 839 (see screenshot).

Github actions shows it applies cleanly to 6.x (current master) and that it runs clean on D10 / PHP 8:

https://github.com/colemanw/webform_civicrm/actions/runs/5060315754/jobs...

If you git clone and checkout 6.x then you can apply the patch now. Alternatively, wait until we issue a new release.

What combo of Drupal, CiviCRM and PHP are you running?

Hi @KarinG

Its
Drupal Version 9.5.8
CiviCRM 5.58.1
PHP 8.0.28
webform_civicrm 6.2.4

CiviCRM 5.58.x can run on PHP 8.x but there will be tons of notices. We run D10/PHP8.x with CiviCRM dev-master for that reason.

As you can see in the matrix our D9.5/CiviCRM 5.58.x test runs using PHP7.x -> https://github.com/colemanw/webform_civicrm/actions/runs/5060315754/jobs...

I've merged PR 839 so you can now
git clone https://github.com/colemanw/webform_civicrm.git
(without the need to apply the patch).

Has PR 839 made it into a released version?

>Has PR 839 made it into a released version?

Yes, its included in v6.2.5 https://www.drupal.org/project/webform_civicrm/releases/6.2.5 →