Tiled Gallery: editor crashes converting Gallery → Tiled Gallery after a Tiled→Gallery round-trip ("Cannot read properties of undefined (reading 'filter')")

[davemac]

Impact

Crashes the whole block editor — the full-screen "The editor has encountered an unexpected error" boundary. Reproducible 100% of the time on the round-trip described below. In the non-crashing case the same code path silently drops the gallery's images.

Steps to reproduce

1. New post. Add a Tiled Gallery block with a few images.
2. Select it → block switcher → Transform to → Gallery. (works fine)
3. Select the resulting Gallery block and open the block-type switcher (or Transform to → Tiled Gallery).
4. The editor crashes immediately — it throws as soon as the switcher renders the Tiled Gallery transform preview.

Expected

The Gallery converts back to a Tiled Gallery, preserving its images.

Actual

Full-screen "The editor has encountered an unexpected error".

Console / stack

TypeError: Cannot read properties of undefined (reading 'filter')
    at f         (jetpack/_inc/blocks/editor.js)   // image filter helper
    at transform (jetpack/_inc/blocks/editor.js)   // tiled-gallery "from: core/gallery"
    at switchToBlockType → block-switcher preview → React render

Root cause

The Tiled Gallery from: ['core/gallery', 'jetpack/slideshow'] transform (extensions/blocks/tiled-gallery/transforms.js) does roughly:

transform: ( { images } ) => {
    const filtered = images.filter( ( { id, url } ) => id && url );
    ...
}

After Tiled → Gallery, the intermediate v2 core/gallery stores its images in nested core/image inner blocks and leaves the top-level images attribute undefined, so images.filter() throws.

The same root assumption means the transform silently produces an empty Tiled Gallery for any modern (v2) gallery whose top-level images array is empty.

Suggested fix

Default images, and recover it from innerBlocks (the transform already receives them) so the images survive the round-trip:

transform: ( { images = [] }, innerBlocks ) => {
    if ( ! images.length && innerBlocks?.length ) {
        images = innerBlocks
            .filter( ( b ) => b.name === 'core/image' && b.attributes?.url )
            .map( ( { attributes } ) => ( {
                id: attributes.id, url: attributes.url,
                link: attributes.link, alt: attributes.alt,
            } ) );
    }
    const filtered = images.filter( ( { id, url } ) => id && url );
    ...
}

Environment

• Jetpack 15.9
• WordPress 7.0
• Reproduces with only Jetpack active (no other plugins needed)
• Workaround: reload the post between the Tiled→Gallery and Gallery→Tiled steps. A freshly parsed gallery has images: [] rather than undefined, so it no longer crashes (though images are still dropped).

[Tejas-Raj01]

Hi team / @davemac,

Just a quick heads-up: While fixing the round-trip crash for this issue, I noticed that the exact same vulnerability exists in another part of the codebase (projects/packages/forms/src/blocks/shared/settings/transforms.js), which wasn't covered in the original report.

That file makes the same assumption (expecting images to always be an array) and could trigger the exact same Cannot read properties of undefined crash under similar conditions.

Since it's outside the original scope, I haven't included it in this PR yet. Would you like me to push the fix for it into this PR (#50025), or would you prefer I open a separate issue/PR for that specific file? Let me know how you'd like to proceed!

[davemac]

Thanks for jumping on this @Tejas-Raj01 - the fix in #50025 looks good. Defaulting images and recovering from innerBlocks is the approach I used on for a temporary fix too. Happy to see it merged for this issue.

On the second file though - I had a look at projects/packages/forms/src/blocks/shared/settings/transforms.js on trunk and I don't think it handles images at all? It transforms form-field blocks (text, choice, options), so I don't think it shares this images.filter vulnerability.

The file that does is the Slideshow block: projects/plugins/jetpack/extensions/blocks/slideshow/transforms.js. Its from transform for [ 'core/gallery', 'jetpack/tiled-gallery' ] calls the same unguarded getValidImages( images ), so a core/gallery → jetpack/slideshow transform will crash in the identical way once a v2 gallery leaves images undefined.

Since that's a separate block, I'd lean towards keeping this PR focused on Tiled Gallery and opening a separate PR for Slideshow rather than widening the scope here. Either way, happy to test whatever you put up.

[Tejas-Raj01]

Hi @davemac,

Ah, you are absolutely right! I must have mixed up my file paths while grepping through the codebase. Great catch, and thank you for pointing out the actual culprit in the Slideshow block (extensions/blocks/slideshow/transforms.js).

I completely agree with your approach. I will leave this current PR (#50025) exactly as is so it remains focused solely on the Tiled Gallery fix.

I'll go ahead and create a separate PR to address the identical getValidImages( images ) vulnerability for the Slideshow block. I'll tag you in that new PR once it's ready for testing.

Thanks again for the detailed review and guidance!

[Tejas-Raj01]

Hi @davemac,
Following up here — I've applied the same images = [] default + innerBlocks recovery approach used in #50025 to fix the identical getValidImages( images ) crash in the Slideshow block's from: [ 'core/gallery', 'jetpack/tiled-gallery' ] transform.
I also verified that caption is intentionally included in the recovered image data here — unlike the Tiled Gallery fix, the Slideshow block actually renders captions (slideshow.js uses RichText with tagName="figcaption"), so dropping it during a Gallery → Slideshow transform would silently lose that data.
Ran the existing test suite and linting locally, all passing. Happy to make any adjustments if you spot anything during review. Thanks again for catching this one!