TypeError: Argument 2 passed to _captcha_insert_captcha_element() must be of the type array, null given, called in /src/web/modules/contrib/captcha/captcha.module on line 169 in _captcha_insert_captcha_element()
This is causing an error on a site that I'm working on. _captcha_get_captcha_placement is returning null and then that is passed to _captcha_insert_captcha_element causing the error. It looks like all other places run a sanity check on the placement variable so I'm adding a patch that does the same thing.
Comment | File | Size | Author |
---|
Issue fork captcha-3075256
Show commands
Start within a Git clone of the project using the version control instructions.
Or, if you do not have SSH keys set up on git.drupalcode.org:
Comments
Comment #2
kleinmp CreditAttribution: kleinmp at Zivtech commentedComment #3
cristiroma CreditAttribution: cristiroma as a volunteer commentedI don't think the patch is good, if you add the verification then the form will not have CAPTCHA. I think the root of the problem is the _captcha_get_captcha_placement and that needs to be investigated why it's returning null.
We had a similar issue with mailchimp subscription block:
In captcha.inc:223
In this our $placement_map[$form_id] = NULL for some reason but happened only in production. It went away after adding
if (FALSE) { } and then restore back. Some strange condition lead to $placement code being null (after a deployment)
Comment #4
pierre-nono CreditAttribution: pierre-nono commentedWith the latest version (beta3), with the option -enabled_default enabled then it will try to implement on views exposed form.
Even if the views is an admin page and the option allow_on_admin_pages to false.
And if the user don't have the permission to skip Captcha, then it will make the bug happen.
There are two points for me.
First the logic in captcha_form_alter() is wrong, I think.
Once it enter
It never check again if we are on an admin page.
should also be tested at the begining of the function. And if return TRUE, then we don't go beyond.
I will try to give a patch soon.
Second, even if we manage that, I think we need an option, or something to avoid automatically trying to alter the views exposed form.
Comment #5
pierre-nono CreditAttribution: pierre-nono commentedProbably not a true fix for this issue, and more a work around it. But it's solved our problem (#4).
Comment #6
wundo CreditAttribution: wundo at Chuva Inc. for Galoa Science commentedComment #7
alfaguru CreditAttribution: alfaguru commentedRerolled patch for latest version of captcha.
Comment #8
SpokjeLooks like this is happening when the module can't find a place to put the captcha, which in my case was because my form had no button and an action on the form defined in an external JavaScript.
I've added a patch that, as a last resort after going through all the currently defined options, puts the captcha at the end of a form instead of throwing an error and not displaying the captcha at all.
Your mileage may vary, but it worked in my use-case.
Comment #9
bsarchive CreditAttribution: bsarchive as a volunteer commented#8 seems to be working for me. Thanks.
Comment #10
Liam MorlandComment #11
Liam MorlandThe patch in #2 is very similar to the patch in #3099456: Argument 2 passed to CaptchaService::insertCaptchaElement() must be of the type array.
Comment #12
prabha.venkatesan CreditAttribution: prabha.venkatesan commentedWhen I apply this patch #8, the error message goes away and I can see only the Captcha element as an anonymous user. The form gives a warning " Unable to display this webform. Please contact the site administrator."
This happens when I close and reopen (unpublish and publish) both the webform content as well as the webform in structure.
PFA https://www.drupal.org/files/issues/2020-10-07/unable%20to%20display%20f...
Comment #13
gaele CreditAttribution: gaele commented#3099456: Argument 2 passed to CaptchaService::insertCaptchaElement() must be of the type array solves the TypeError bug, and is part of 8.x-1.3. It does not display a captcha widget when no buttons are found. Which is fine for my use case, but unlike the one described in #8, so I'm leaving this issue open.
Comment #14
dancbatista CreditAttribution: dancbatista at CI&T commentedI will work on it!
Comment #15
dancbatista CreditAttribution: dancbatista at CI&T commentedIn my case, I had the same results as described in #13.
Comment #16
AnybodyThe idea and patch in #8 looks good to me, could anyone write down clear steps to reproduce this in a fresh Drupal environment?
Alternatively or additionally, I think we'd need a test
Comment #17
Grevil CreditAttribution: Grevil as a volunteer and at DROWL.de commentedComment #18
AnybodyThanks @Spokje, I just added the code from your patch in #8 as MR. And it looks correct and useful to me to have this final fallback.
Please review. Afterwards I think this topic can be closed finally. The fallback should fix the last edge-case.
Comment #19
AnybodyComment #20
AnybodyComment #22
Grevil CreditAttribution: Grevil as a volunteer and at DROWL.de commentedI don't like the patch. We should get clear steps for replicating this behaviour, so we can find a better solution.
Currently, the method will look for an "actions" button group, if there is one, we set the captcha right before it. If there is no "actions" button group, we look for a button, and place it before the first button we find, if there is also no button, we set $placement to NULL and return it.
With the patch, we add a final check for handling $placement being NULL, and place the captcha before the actions button group. But the way this is written, we also add the button, even if no "actions" button group exist AND we add duplicate code.
Comment #23
AnybodyWell I think the situation isn't good yet, that's correct, but the patch doesn't make things worse from my perspective, it just adds a fallback to prevent errors.
As a follow-up #2698795: Better placement strategy should be seen, but sooner or later the module will need a general refactoring.
So I'm okay with both decisions, adding the proposed code as fallback or do nothing / wait for further progress here (which might never happen). You decide @Grevil, please set the status accordingly.
Comment #24
Grevil CreditAttribution: Grevil as a volunteer and at DROWL.de commentedI removed the changes, added another NULL check and changed the "insertCaptchaElement" attribute definition, so we can be 100% sure, that $placement is only NULL, when we set it NULL. I don't think further checks are needed, as the rest is handled inside insertCaptchaElement() (legacy name: _captcha_insert_captcha_element()), as it also handles cases where key, weight and path of the $placement variable is NULL, this also applies if the whole $placement variable is NULL! So this will probably fix all issues.
Comment #25
AnybodyDue to the used functionality (parameter typing) this is a 2.x (PHP 8) only change!
Comment #26
AnybodyComment #27
Grevil CreditAttribution: Grevil as a volunteer and at DROWL.de commentedAll tests are green! commiting this!