🇳🇱Netherlands @nielsva

nielsva → created an issue.

Since we need to fix this issue yesterday, I've cooked up the following preprocess method which now lives in a custom module. Placing it here for anyone in need.

```
/**
* Sets the correct Claro / Gin classes.
*
* This is a workaround until the following issue is solved.
* https://www.drupal.org/project/drupal/issues/3093189#comment-15053368 🐛 Fieldgroup vertical tabs Active
*
* @param array $element
* The element containing vertical tabs.
*
* @return array
* The resulting pre-rendered element.
*/
public static function verticalTabs(array $element): array {
$groupTypeIsDetails = isset($element['group']['#type']) && $element['group']['#type'] === 'details';
$groupsArePresent = isset($element['group']['#groups']) && is_array($element['group']['#groups']);

if ($groupTypeIsDetails && $groupsArePresent) {
$groupName = $element['#group_name'];
$childrenKeys = Element::children($element, TRUE);
foreach ($childrenKeys as $childKey) {
if (!isset($element[$childKey]['#group']) || $element[$childKey]['#group'] !== $groupName) {
continue;
}

$type = $element[$childKey]['#type'] ?? NULL;
if ($type === 'details') {
// Add BEM class to specify the details element is in a vertical
// tabs group.
$element[$childKey]['#attributes']['class'][] = 'vertical-tabs__item';
$element[$childKey]['#vertical_tab_item'] = TRUE;
}
}
}

return $element;
}

```

Hi @danflanagan8, thanks for the reply. I narrowed it down to the following conditions:

1. This only occurs on Claro (based) themes
2. This only occurs on non Form API based usages of field_group's vertical tabs, eg. view mode of a node.

I noticed that core/themes/claro/src/ClaroPreRender.php:88 seems to be dependent on a `$element['group']['#groups'][$group_key][$child_key]['#type']` variable which is not set at this point. This seems to make sense when I look into `field_group` which seems to not set these when rendered outside a Form API context, see: field_group/src/Element/VerticalTabs.php:26.

The `\Drupal\claro\ClaroPreRender::verticalTabs` should be setting a `vertical-tabs__item` class on the `` element. If that is done, it would hide the `` and I think that everything should be fine.

Though, the `$element['group']['#groups']` element does not seem to be the right place to add the attributes to. I'm guessing the Claro prerender should be revisited, but I'm not entirely sure. What's your assessment on this?

I'm seeing this issue as well, using 8.x-3.4 and Gin 8.x-3.0-rc1. Therefor I think this may be reopened.

Whoops, scratch that, wrong patch. This should be the correct one:

Agreed, MR 11 could easily be updated with MR12, just merged that into MR 11 so that is leading again. We're currently patching this issue, using the attached patch extracted from the MR.

Just to be clear, this probably needs some extra work, handling all the exceptions from the api.

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

Patch for reference what we are currently applying to our project and not patching from the actual MR.

I've done a suggestion on how to fix this, but I'm not entirely sure if this is the right way. Though, I would think this is a safe way to solve this issue where it will self recover from a serialized state and reinitialise it's Order object.

Feedback wanted.

We're also seeing this bug and can pretty neatly reproduce the problem. We've also got commerce_shipment enabled which automatically generates the correct shipment methods. Some things that catch my eye are:

1. The order should not yet have existed before landing on `checkout/12345/order_information`, only then this error triggers on our "Continue to review" button and does so in a AJAX request in the background.
2. If you add shipment address info and the shipment methods are attempted to be displayed, it will not show the shipment methods.
3. If you've done that, refreshing the page will strangely show all shipment methods.
4. At this point, you can click on "Continue to review" without triggering the error.

This issue has arrived in our project when upgrading Drupal core and a lot of contrib modules, but notably we also update commerce contribs:

drupal/commerce                    | 2.30.0       | 2.33.0    
drupal/commerce_cart               | 2.30.0       | 2.33.0    
drupal/commerce_checkout           | 2.30.0       | 2.33.0   
drupal/commerce_mollie             | 1.7.0        | 1.10.0    
drupal/commerce_number_pattern     | 2.28.0       | 2.33.0   
drupal/commerce_order              | 2.28.0       | 2.33.0    
drupal/commerce_payment            | 2.28.0       | 2.33.0   
drupal/commerce_price              | 2.30.0       | 2.33.0    
drupal/commerce_pricelist          | 2.4.0        | 2.8.0   
drupal/commerce_product            | 2.30.0       | 2.33.0   
drupal/commerce_shipping           | 2.2.0        | 2.6.0   
drupal/commerce_store              | 2.30.0       | 2.33.0    
drupal/commerce_store_domain       | 1.0.0-rc2    | 1.0.0

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