🇬🇧United Kingdom @Sophie.SK

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 :)