🇨🇦Canada @adixon

This patch should be reverted asap, it causes issues with Olivero. See below:

https://www.drupal.org/project/drupal/issues/3474666 🐛 Olivero theme have an error for Drupal 10.3 Active

https://www.drupal.org/project/google_tag/issues/3468036#comment-15811949 🐛 Problems with google tag i think after it upgraded to 2.0.6 Active

Following up Karin's observation about google tag module, this looks likely:

https://www.drupal.org/project/google_tag/issues/3468036 🐛 Problems with google tag i think after it upgraded to 2.0.6 Active

I found a couple of places where you're testing the url (for front or no-link) which can just be prefaced with a test whether it's external.

Patch attached.

Ah good to know I almost understand something here. If you have any experience with the biome configuration and have clues to share, or just want me to try and figure it out, I can start a patch/pr thing.

Indenting for Javascript in Drupal isn't a preference: https://www.drupal.org/docs/develop/standards/javascript-coding-standard... →

adixon → created an issue.

adixon → created an issue.

I'd guess it's php version related as well, sorry I didn't identify that in my original report.

I'm also new to the "?:" operator.

I can see my proposed fix on the 6.0.x branch but my brain can't handle the complexity of this required git setup ...

adixon → created an issue.

For sure, the source of the issue is that '#group' is used for the drupal group concept, and there's validation that assumes it's a string.

My patch might work for you, in that by the time the form gets to that level of validation, it probably doesn't need to care about #group.

On the other hand, your experience suggests that fixing this might be trickier than I thought or hoped.

Ultimately, the '#group' property that webform civicrm uses really needs a different key so that we're not colliding with the drupal '#group'.

I believe there's some work being done in that direction.

Confirmed for a D9 + php8.1 install.

For my example, there are a number of "existing contact" fields, some of which are filtered by group, and it appears that the ones that break are those that are not filtered by group (but maybe that's because that's as far as it gets ...).

I also notice that the group looks like this:

[#group] => Array
(
[] =>
)

The code is actually happy to skip the field if it's empty, but that's an array with a single empty entry, so the array itself isn't empty.

Conclusions:
1. It might work to just slightly fix how that #group value is being generated, and remove any empty group.
2. In the meantime, you can just patch your drupal core with something like this:

diff --git web/core/lib/Drupal/Core/Form/FormErrorHandler.php web/core/lib/Drupal/Core/Form/FormErrorHandler.php
index dfb52c072e..eabda5c87e 100644
--- web/core/lib/Drupal/Core/Form/FormErrorHandler.php
+++ web/core/lib/Drupal/Core/Form/FormErrorHandler.php
@@ -147,7 +147,7 @@ protected function setElementErrorsFromFormState(array &$form, FormStateInterfac
 
         // If this direct child belongs to a group populate the grouping element
         // with the children errors.
-        if (!empty($child['#group'])) {
+        if (!empty($child['#group']) && is_string($child['#group'])) {
           $parents = explode('][', $child['#group']);
           $group_element = NestedArray::getValue($form, $parents);
           if (isset($group_element['#children_errors'])) {

I'm interested in working on this, I have a client with a bootstrap3 based theme (a subtheme of the eponymous drupal theme).

Where is the code that generates the markup + classes?

Bootstrap3 didn't use flexbox, which is unfortunate, but the client was used to doing this via a different module (I believe they used a ckeditor4 plugin) and have a fair amount of existing markup and workflows that make use of bootstrap3 html+css, so getting this to work for bootstrap3 would be a bonus.

I'd be game even if this module just provided some method for overriding the markup and it needed a separate module to implement.

Thanks for sharing this experience, we've had the same thing on a couple of installations - i.e. the same error message, the same 6 tables created in the drupal database. Ignoring the error and removing the tables seems to work fine.