🇺🇸United States @wheelercreek

I'm seeing the same issue.

When I var_dump the variable in BlockClassHelperService.php on line 196 it showed as a long string of block names in JSON notation. The array_merge function is expecting an array.

I then added this line after line 196:
$block_classes_stored = json_decode($block_classes_stored, true);

The error went away then, but on the second time I saved it came back this time complaining that the value I was trying to pass through json_decode was already an array. I removed my added line and saving the block worked fine.

So maybe we need to add a function there to test if the string is in JSON notation?

I ran into the same issue - unable to view any orders. We can view the orders list page, but when we try to view an order we're getting this error. I had to downgrade to doctrine/collections 1.8.0 and now it's working.

#38 patch didn't help me, site was still down. I had to add the lines to Composer conflict, and rolled back to Drupal 10.2.7.

What I did:

"conflict": {
        "drupal/drupal": "*",
        "drupal/core-composer-scaffold": ">10.2.7",
        "drupal/core-project-message": ">10.2.7",
        "drupal/core-recommended": ">10.2.7"
    },

#6 -- worked for me. I tried all the others. Exporting my site config with Drush helped me find it. For me the issue was with module "Block Visibility Groups"

Regarding #42 - yes I'm finding that any old font-awesome code is causing the page to choke and I cannot even edit the page. I was getting the icons to show but then the trying to edit the page locks-up.

But the new patches (#43 and 44) do allow for the FA ckeditor icon to be usable. Seems to be working well on a new page without any existing FA code in it.

In case it helps someone else you need to import these two .yml files:

field.storage.commerce_order.shipments.yml

langcode: en
status: true
dependencies:
  module:
    - commerce_order
    - commerce_shipping
id: commerce_order.shipments
field_name: shipments
entity_type: commerce_order
type: entity_reference
settings:
  target_type: commerce_shipment
module: core
locked: true
cardinality: -1
translatable: false
indexes: {  }
persist_with_no_fields: false
custom_storage: false

field.field.commerce_order.default.shipments.yml

langcode: en
status: true
dependencies:
  config:
    - commerce_order.commerce_order_type.default
    - field.storage.commerce_order.shipments
id: commerce_order.default.shipments
field_name: shipments
entity_type: commerce_order
bundle: default
label: Shipments
description: ''
required: false
translatable: false
default_value: {  }
default_value_callback: null
settings:
  handler: 'default:commerce_shipment'
  handler_settings: {  }
field_type: entity_reference

I had similar issue and found that order types was missing the default shipping field:
https://www.drupal.org/project/commerce_shipping/issues/3241197#comment-... 🐛 Shipping checkout flow setting is not recognized until first order with shipment is placed Active

I was having the same problem and #5 fixed it for me. I'm running Drupal 10.2.2, and commerce shipping 8.x-2.7.

Mine was a fresh install (not an upgrade). If you go to Configuration > Orders > Order Types and then click to fields, there should be a field there for shipments.
(/admin/commerce/config/order-types/default/edit/fields)

For some reason my install was missing this field. I had a Drupal 9 site running drupal commerce with almost the same setup, and I was able to export the needed config files and then imported them into my D10 site, and now the shipping information is showing up on my Order Information page on checkout.

Looks like if I create the payment gateway as a card element rather than payment element, that works. So I think that will do for me.

wheelercreek → created an issue.

I realize that patching or appending is the recommended way to do this (to keep up with possible future security updates), but if anyone is looking for a quick way to prevent scaffolding from reverting a file, you can also just exclude it:

https://www.drupal.org/docs/develop/using-composer/using-drupals-compose... →

I have a bunch of custom commands in my .htaccess to accommodate another PHP application running on the same web root, and this issues has hit me 4-5 times now. Not dealing with it any more.

wheelercreek → created an issue.

wheelercreek → created an issue.

I'm not seeing a patch here for version 3.1.22, is there one?

This is same issue I'm seeing as reported here:
https://www.drupal.org/project/permissions_by_term/issues/3289053#commen... 📌 Automated Drupal 10 compatibility fixes for Permissions by Term Fixed

The new release (3.1.22) has not fixed the issue for me. I'm still seeing this error when I attempt to create or edit content:

Twig\Error\LoaderError: Template "__TwigTemplate_1204b7436b150da256126149d5547692" is not defined. in Twig\Loader\ChainLoader->getCacheKey() (line 98 of /code/vendor/twig/twig/src/Loader/ChainLoader.php)

Drupal 9.5.7

Drupal 9.5.5 - Patch #2 did not work for me. We have a content type with multiple paragraph fields, and these fields have entity reference revisions. Some of these paragraphs contain other paragraph fields.

I found the problem is fixed by going through every field in the revisions and making sure to check the box "Users my translate this field". I did this even though there is the warning about how paragraphs do not support translations. This fixed the error and at least now I can update the content. Otherwise the nodes are stuck & cannot be updated (in any field).