Ju'Z[ed]

pouyawebio wrote:

This is actually expected behavior, not a bug.

The Featured Image block only exposes resolution controls when it has a post context (like inside a Query Loop). Outside of a Query block, WordPress treats it as a dynamic image without a specific post instance, so the size selector is intentionally hidden.

In other words:

 - Inside Query Loop → post context exists → sizes available

 - Outside Query → no fixed post → sizes removed

Workarounds:

 - Wrap the Featured Image inside a Query Loop (even with 1 post)

 - Use a normal Image block instead if you need fixed sizing

 - Control dimensions via CSS (width/height/object-fit)

 - Advanced: you can set sizes in theme.json or filter render_block_core/post-featured-image

So this is more of a design limitation of Gutenberg rather than a missing feature.

Thank you for the detailed explanation. I now understand the design intent behind this behavior.

In my specific case, the pattern containing the Featured Image block is used within a custom Query Loop. Users can create their own patterns and assign them to each post type displayed in the query. However, even in this context, the resolution options remain unavailable for the Featured Image block when it’s placed inside a pattern—despite the pattern being used within a Query Loop.

I attempted to programmatically add post context using the render_block_context filter, but it didn’t resolve my issue:

add_filter('render_block_context', function ($context, $parsed_block) {
    if ($parsed_block['blockName'] === 'core/post-featured-image') {
        $context = [
            'postId'   => 1,
            'postType' => 'post',
        ];
    }
    return $context;
}, PHP_INT_MAX, 2);

Is there a way to ensure the Featured Image block recognizes the post context when used inside a pattern within a custom Query Loop? Alternatively, are there other filters, hooks, or methods to restore the resolution options in this scenario?

If this isn’t currently possible, are there plans to address this limitation in future WordPress updates? It would significantly enhance flexibility for developers and designers working with reusable patterns and custom Query Loops.

Thanks again for your help!

Update on the issue:

The error was occurring during wp db import db.sql, not during the search-and-replace step. The search-and-replace wasn’t working because the import itself was failing.

What fixed it: Two things were critical:

• Adding the --defaults flag to the wp db commands:

wp db import db.sql --defaults

• Disabling SSL in the MySQL configuration by adding:

[client]
ssl=0

Removing this configuration caused the import to fail again, so it was also necessary.