Conflicting name with other element(s)

joe huggans → made their first commit to this issue’s fork.

I may have opened an MR into the wrong branch (2.1), apologies and please advise if so. I can create some tests if you need?

The tests are failing for this because the $form['elements'] array does not always exist, it exists for webforms but not necessarily other forms.

I'm not sure if there is a consistent way to check if a form element exists, can we assume they are always in either $form or $form['elements']?

If not, would it be better to just add a random suffix to the end of the name of the field?

Created new branch (3134078-for-2.2 ) from 2.2, and opened MR (merge request !56) for 2.2. Will work on tests next.

This really does need to be done in 2.2, not in 2.1.
The MR!55 is unusable because it is mostly changes to make 2.1 identical to 2.2 by cherry-picking commits that were made to 2.2.
The MR should really be just a few lines of code. And it should include a test case to test this specific new feature.

Some tests provided, let me know if I can improve these in any way or if I've done anything wrong and I will fix it.

I'm not sure how to get past the phpstan failure in the tests.

tr → changed the visibility of the branch 3134078-conflicting-name-with to hidden.

The phpstan error is because the real class name should be \Drupal\Component\Serialization\Yaml
The "Core" version is just an alias, which I guess phpstan doesn't like for some reason. Best to change it to Component everywhere IMO.
Also, "webform" should be added to the cspell list in .gitlab-ci.yml

But other than that it looks great.

Thank you for the help! All seems to be passed now.

This looks good to me. I will leave this issue open for a few days to allow people to comment if they want, then I will commit it.

After updating to version 2.2.1 I've started getting webform error messages related to this change.

The error is:

TypeError: array_key_exists(): Argument #2 ($array) must be of type array, null given in array_key_exists() (line 151 of modules/contrib/honeypot/src/HoneypotService.php).
Drupal\honeypot\HoneypotService->addFormProtection() (Line: 234)
honeypot_webform_submission_form_alter() (Line: 552)
Drupal\Core\Extension\ModuleHandler->alter() (Line: 78)
Drupal\webform\WebformThirdPartySettingsManager->alter() (Line: 678)
Drupal\webform\WebformSubmissionForm->buildForm()
call_user_func_array() (Line: 536)
Drupal\Core\Form\FormBuilder->retrieveForm() (Line: 284)
Drupal\Core\Form\FormBuilder->buildForm() (Line: 48)
Drupal\Core\Entity\EntityFormBuilder->getForm() (Line: 1250)
Drupal\webform\Entity\Webform->getSubmissionForm() (Line: 112)
Drupal\webform\Element\Webform::preRenderWebformElement()
call_user_func_array() (Line: 113)

It appears that are circumstances where the $form['elements'] is not set on webforms. It seems in my clients case to be related to access controls where the form may not be rendered if the user is logged in.

I think we need to check if the $form['elements'] is also set in the if statement on line 151 of HoneypotService.php

Yes, we need to check $form['elements'] exists, I tried to create a new MR but made a mess of it, sorry.

MR should be good now. Can you modify the test too, to check for this case?

I'm able to recreate the error from #29 with a CLOSED webform, but unable to replicate by changing the access setting for the Webform.

I will add a test, not sure exactly what to test for but this test checks that the filename has not been altered for the honeypot field.

I'm able to recreate the error from #29 with a CLOSED webform, but unable to replicate by changing the access setting for the Webform.

After some more testing, the settings which triggers the error for me were:

1. In the "Submissions" tab, enable the "Confidential submissions" option.
   • Note: If you have the "General" > "Disable saving of submissions" option enabled, you won't see this option.
2. Set the Access > "Create submissions" permissions to be both anonymous and authenticated users.
3. Visit the form while logged in as a basic authenticated user who doesn't have any permissions to bypass access restrictions.

Thanks @pcate. Using your instructions I have managed to recreate the error, and it is fixed by checking if $form['#webform_id'] is empty.

@tr do you require a test for these circumstances also?

@pcate: If you apply the patch from MR!57, does it fix the issue on your site?

@joe huggans: I think the MR and the test are fine as they are, if @pcate can confirm that it fixes the problem on his site.

@pcate: If you apply the patch from MR!57, does it fix the issue on your site?

@tr, I've tested MR #57 and can confirm it does fix the error.

This seems to have addressed my issues in https://www.drupal.org/project/honeypot/issues/3506174 🐛 PHP errors when a webform is closed Active

That's good enough for me.

This was not released yet, right? I see this issue mentioned in https://www.drupal.org/project/honeypot/releases/2.2.1 → , but afaik 2.2.1 introduced https://www.drupal.org/project/honeypot/issues/3506174 🐛 PHP errors when a webform is closed Active , which is marked as duplicate of this issue

A problem with the initial commit was reported in #29 so the issue was reopened to fix that problem.
2.2.1 has MR!56, the next release will also have MR!57. You can use the patch from MR!57 or use the -dev release if you want the fix immediately.

Aha, sorry, got confused for a second. Thanks for the clarification!

Automatically closed - issue fixed for 2 weeks with no activity.