WP Patterns with GenerateBlocks blocks show as 1 block since updating to v 7.0

Hi GenerateBlocks support,

Since updating our site from WordPress 6.x to WordPress 7.0, we are seeing a major editor workflow issue with content that was originally inserted from unsynced patterns.

We make very heavy use of unsynced patterns across my site, and many of those patterns contain GenerateBlocks v2 blocks, including Query, Looper, Loop Item, Element and Text blocks.

After the WordPress 7.0 update, many blocks that were previously editable as normal nested blocks now appear in the editor as a single pattern/section-style block with the black double-diamond pattern icon. To access the actual inner blocks, editors have to right-click and select “Detach”.

This is causing confusion for our editors because it makes old unsynced pattern content look like a synced/component-style pattern, even though the content appears to still be local to the post.

I have already tried the official WordPress 7.0 opt-out setting:

`php
add_filter(
‘block_editor_settings_all’,
function ( $settings ) {
$settings[‘disableContentOnlyForUnsyncedPatterns’] = true;

return $settings;
},
PHP_INT_MAX
);
`

I confirmed in the browser console that this setting is reaching the block editor:

`js
wp.data.select(‘core/block-editor’).getSettings().disableContentOnlyForUnsyncedPatterns
`

This returns true.

However, the affected GenerateBlocks blocks still appear as pattern/section blocks in the editor.

Here is an example of one affected block. This is a GenerateBlocks Query block inside a list item. The full block markup is still stored locally in the post content, but the block has metadata.patternName attached:

`html
<!– wp:generateblocks/query {“uniqueId”:”146848c5″,”tagName”:”div”,”globalClasses”:[“oe-height-1-1″,”oe-width-1-1″],”query”:{“post_type”:[“page”],”posts_per_page”:”1″,”post__in”:[125569]},”metadata”:{“patternName”:”core/block/156160″,”name”:”OE Card – Nav Menu style BG change on hover (GBv2)”}} –>
`

There are also nested GenerateBlocks blocks with their own metadata.patternName values, for example GenerateBlocks Element and Text blocks used for cards and buttons.

My questions are:

1. Are you aware of this WordPress 7.0 issue/behaviour affecting GenerateBlocks content inserted from unsynced patterns?

2. Is this expected WordPress core behaviour, or is there anything GenerateBlocks-specific that could be contributing to the issue?

3. Is it safe to remove metadata.patternName from existing saved GenerateBlocks block markup, while leaving the actual GenerateBlocks block attributes, uniqueId, styles, CSS, global classes, and inner blocks intact?

4. Do you have, or are you planning, an official migration/fix for sites with lots of old unsynced pattern instances?

5. Would you recommend using the WordPress setting disableContentOnlyForUnsyncedPatterns, or is there a better GenerateBlocks-compatible workaround?

The main goal is to restore the pre-WordPress-7 editing experience for existing unsynced pattern content, so editors can see and edit the inner GenerateBlocks blocks directly without having to manually detach hundreds or thousands of pattern instances.

Thanks.

https://postimg.cc/gallery/Fcv8K08