🇬🇧United Kingdom @Sophie.SK

We saw this recently but it was combined with another error that prevented the second field from being saved at all:

An AJAX HTTP error occurred.
HTTP Result Code: 200
Debugging information follows.
Path: /admin/structure/webform/manage/sophie_s_test_webform?ajax_form=1&_wrapper_format=drupal_ajax
StatusText: parsererror
ResponseText: 
Warning:  foreach() argument must be of type array|object, string given in /var/www/html/docroot/core/lib/Drupal/Component/Utility/NestedArray.php on line 330
Warning:  foreach() argument must be of type array|object, string given in /var/www/html/docroot/core/lib/Drupal/Component/Utility/NestedArray.php on line 330

Which we were able to resolve by applying the patch from 🐛 _wrapper_format=drupal_ajax is always added, instead of updated when the param is already available Active .

The autocomplete message still occurs on our sites but we can at least add multiple fields in one pageload now.

Adding support for this :)

There is a Smart Content Paragraphs contributed module but it has a lot of very hard-coded features (eg requesting a user's location by default, requiring a patch to disable), stores a ton of extra cookies that aren't wanted, and doesn't use any of the great work in this module (it posts an array of data back to a controller that determines whether or not to show the Paragraphs).

It's a useful basic module, but it would be good to have better support from within the Smart Content module, especially as it's not covered by the Drupal security coverage.

Adding related issue. The problem in 🐛 Warning: Undefined array key "#webform_key" in WebformManagedFileBase.php Needs review seems to be identical, but was closed as non-reproducible last week.

Patch in #8 also worked against a 10.4.7 site.

We had the issue with a brand new installation of Webform.

The error only seems to appear on the second time you try to add/delete an element without refreshing the page:

• Select '+ Add element' at top of page
• Choose an element and save
• Select '+ Add element' for a second time (or select 'Save + Add element' in fly out menu)
• Choose and element and try to save
• Result: Ajax error in console

Same also applies for deleting. The first time you can delete the element without issue. If you try and delete a second item, the error appears
If you refresh the page in between adding / deleting the element, then the addition / deletion is successful.

Applying this patch has resolved the Ajax error. We still have a console error, but the one that was preventing new elements from being added seems to have been fixed.

Leaving as "Needs work" as it sounds like this still needs to be re-rolled against Drupal 11 though.

This comes up in our pull requests a lot as well. My preference is to not include the backslash but I think I'm in the minority.

My preference is for a coding standard and consistency. It looks like the precedent generally is to include the backslash, so lending my support for this change.

Minor grammar fix (remove unnecessary apostrophe).

Pushed an update to the branch to bring it up-to-date with latest changes from 3.0.x, and resolve the merge conflict.

sophie.sk → made their first commit to this issue’s fork.

What a gnarly bug :D

Just to say this patch has applied cleanly to Drupal 10.3.10 and resolved our client's issue:

1. Field primary_reason has an Ajax callback that populates & returns the secondary_reason field.
2. The additional_information field should show depending on the value chosen in the secondary_reason field, determined using the #states array.

Now the patch is applied, the additional_information field is correctly showing/hiding.

We've had a similar issue - upgrading from 1.7.0 to 2.0.6 caused our scripts to stop being added to the page. Removing all conditions resolved the issue.

I've linked another issue, 🐛 script embed breaking Active , which has a patch attached and may resolve the problem?

Attaching a re-rolled patch against the latest 2.0.x code.

Works well for me - should it have an update hook to make sure a value is added to config (even if it's empty)?

Tagging on support for this.

We'd like all /user paths (/user, /user/login, /user/password) to redirect to Saml, which can be achieved by disallowing local user logins.

However for a subset of users we'd like them to be able to use one-time login links to access the site in the event of an emergency or Saml downtime, therefore need the /user/reset paths to be accessible.

All client users login using Saml, but historically the dev team haven't had SSO accounts set up. They are slowly being rolled out but this is a long process, therefore the dev team needs access via one-time login.

Additionally in the event of an emergency outage the team at the hosting provider (Acquia) need to be able to create and login to an account without going via Saml, therefore need access via one-time login link.

To get around this our current configuration is to allow local logins, and the client has configured a Cloudflare redirect that directs users from /user to the Saml login page. However they've found that adding any query string (eg /user?dfgkjhdflg) prevents that redirect from happening, and that there are extra paths they didn't realise existed!, so we'd really like to leverage the default functionality from this module.

Our ideal configuration/outcome would be:

1. When an anonymous user accesses /user, /user/password, /user/login, or any of those with a query string, they are redirected to Saml login.
2. If a non-allowed user creates a one-time login link and uses that to login, they are redirected to the Saml login.
3. If an allowed user creates a one-time login link and uses that to login, they are able to login without going via Saml.

The patch works, but is definitely a hack. A configuration option, eg "Allow use of one-time login links", would be useful - potentially with allowed roles/user IDs, the same as the default login.

Seeing the same issue with Site Studio/layout canvas field on a content type.

Clicking "Resume" causes the page to reload and the "Do you want to continue editing?" message to appear again, ad infinitum.

The resuming behaviour works fine on content types without a layout canvas field.

Rerolled against 11.x, and also 10.2.x, which is the version of Drupal I'm running and needed it to be rerolled.

Since this causes a reduction in service for clients, and can happen randomly, I'm raising the priority to "Major".

Happy to help out testing any patches.

Ah, I'm so glad you posted this. One of our clients has had this same issue this week, having followed the steps outlined in a Search API Solr issue previously: https://www.drupal.org/project/search_api_solr/issues/3401710 💬 Updating to 4.3 Errors Fixed

It would be good to know what the cause is and when there may be a fix.

This patch has resolved the issue for me :)

The PR needs rebasing onto the dev branch but otherwise, marking as RTBC.

Thanks for spotting and fixing this :)

made a small change for coding standards, and committed! (apologies - I forgot to give you credit for the change.)

Sophie.SK → made their first commit to this issue’s fork.

Thanks for the work all - merged :)

Sophie.SK → made their first commit to this issue’s fork.

Thanks both! Added you both for credit and merged the PR.

Hi @Mably - I don't think I have the capacity to help any more. I'm not in an organisation where this module is used frequently.

Good luck finding another maintainer :)