🇺🇸United States @kmonty

It looks like this was already resolved in an unrelated Gitlab migration issue 📌 Gitlab CI yml & Drupal 11 support Fixed : https://git.drupalcode.org/project/block_list_override/-/commit/c4725035...

If anyone else is looking into why Layout Builder broke after this was merged in, you can find a patch here 🐛 Uncaught TypeError in sidebar.js after updating to the latest Gin theme RTBC

Note: our team similarly encountered this issue. This patch resolved it.

It looks like this was merged into the 1.x branch in error, so that branch won't be able to be updated without this being pulled out.

2.x RELEASE branch was just 1.x with this PR merged in. The 2.x DEV branch is years out of date.

Might be a good opportunity to move to semvar while cleaning this up?

We just encountered the same issue after updating the latest RC of Gin.

Actions:
1. Created a PR for the 3.0.x branch that @andybroomfield created.
2. Patched the 2.0.x branch, as that is the current supported version of the module.
3. Confirmed this resolved our team's error.

kmonty → changed the visibility of the branch 2.0.x to hidden.

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

kmonty → created an issue.

@Rajeshreeputra Thanks for changing the status of `2.0.3`

I just wanted to nudge that hopefully Focal Point makes this a pattern for releases in the future :)

Thanks for maintaining a great module!

No patch here, so this can't be RTBC

I just wanted to +1 this.

Other projects will leave releases like `2.0.3` as supported (but not recommended) so it doesn't flood Admin UIs with a scary red banner asserting a module is unsupported.

This can inject stress into teams, especially from non-technical stakeholders who are security-focused.

Great call, @anybody! I just looked at the 2.x branch and jQuery isn't used / required as a library. I'll leave it up to the maintainers to close this as outdated, but it strikes me as something that could be.

I think it makes sense to remove the dependency. Core can require it, but the module itself doesn't need to. Eventually the goal is to remove the jQuery dependency from core (as I understand it), so it seems reasonable to get ahead of that.

I found a bug with the latest patch with Webform Submissions. It causes a PHP error Recursive rendering attempt aborted for webform_submission1html. In progress: Array ( [webform_submission1html] => webform_submission1html ).

Reproduction steps:

1. Be on Core 10.2.4 and the latest stable release of Webform. Apply the patch as of the 15.03.2024 commits.
2. Setup a basic Webform, submit a form (will be submission ID #1)
3. Go to /admin/structure/webform/submissions/manage and go to View the submission you just put in.
4. Instead of seeing a list of fields that you filled in, you just see the "Submission information"
5. If you have dblog enabled, you can see the PHP error in the latest log messages

Our QA team tested the patch file (not the MR) which removes the library and found no issues.

+1 for removing the library entirely, as IE 11 has been at end of support for near two years now.

+1 RTBC

I think this should be higher than `normal`, as it's a security threat.

kmonty → created an issue.

I'd say this is `Needs Work`, as this is an `ugly, temporary solution`.

At the very least, it should remove the dependency on jQuery.

Several people reporting issues. Moving back to Needs Work.

The new patch is just for my suggested changes against the 8.x branch and not updating the existing patch. It also does not include eslint changes.

Minor change, but the `once` dependency should be included in the wrapper function.

So:

(function (Drupal, drupalSettings) {
[...]
})(Drupal, drupalSettings);

becomes:

((Drupal, drupalSettings, once) => {
[...]
})(Drupal, drupalSettings, once);

Also, this should be run through eslint, as it doesn't match Drupal's Prettier rules (single quotes instead of double quotes, no unnamed funcs, incomplete code comments // If no error messages exist, the etc.)

I won't go as far as modifying the child issues, but calling out we found a breaking regression that was implemented in beta7. 🐛 Regression > Patch for "webform entity reference formatters not supporting translations" in 6.2.0-beta7 breaks Webform embeds within untranslated entities Active

kmonty → created an issue.

Here is a small patch we wrote to add a setting to enable the display of the signature file.

There are probably more elegant ways to write this, such as:

1. Doing a file_exists check.
2. Changing the logic to be disable_signature instead of enable_signature. As this patch is written now, a database update hook would be required before merging this into the branch. That said, it was a quick way for our team to solve this.

Hoping this helps folks for now. We might pick this back up to improve the patch if the maintainers seem interested in merging at some point + offer up guidance as to what their preferred implementation is. Cheers!

Our team is satisfied that this is sufficient to get us to be able to deploy the security release. I didn't look into if this needs tests or anything. Again, just prioritized getting today's security release out. Hope this helps folks!

Note: patch was written against `3.0.x-dev` but it applies cleanly to `3.1.0`

I have a patch working on localdev. Going to have our QA team give it a test before posting here. Assigning to myself for now.

I'm currently working on a patch based off the work done here: https://www.drupal.org/project/language_switcher_menu/issues/3348242 🐛 SA-CORE-2023-003 Fixed