The following accounts have interacted with this PR and/or linked issues. I will continue to update these lists as activity occurs. You can also manually ask me to refresh this list by adding the props-bot label.

If you're merging code through a pull request on GitHub, copy and paste the following into the bottom of the merge commit message.

Co-authored-by: priethor <priethor@git.wordpress.org>
Co-authored-by: youknowriad <youknowriad@git.wordpress.org>
Co-authored-by: t-hamano <wildworks@git.wordpress.org>
Co-authored-by: fabiankaegy <fabiankaegy@git.wordpress.org>
Co-authored-by: Mamaduka <mamaduka@git.wordpress.org>
Co-authored-by: gziolo <gziolo@git.wordpress.org>
Co-authored-by: mtias <matveb@git.wordpress.org>

To understand the WordPress project's expectations around crediting contributors, please review the Contributor Attribution page in the Core Handbook.

Size Change: +65 B (0%)

Total Size: 1.95 MB

_{compressed-size-action}

I like this feature, but note that it's not recommended to use the ServerSideRender component when creating custom blocks:

https://github.com/WordPress/gutenberg/blob/trunk/packages/server-side-render/README.md#serversiderender

Additionally, we may need to enable skipBlockSupportAttributes by default; otherwise, we'll end up with double rendering of borders, padding, shadow support, etc.

See #44491 for more details.

skipBlockSupportAttributes

@t-hamano Can you speak a bit more about this, does that mean that we can't have automatic support for all these block supports automatically in these php only blocks?

does that mean that we can't have automatic support for all these block supports automatically in these php only blocks?

No. I'm happy to move forward with this PR, but I'm saying that we may need to change our policy for the ServerSideRender component.

If this PR is shipped, more developers may create blocks that use the ServerSideRender component internally. On the other hand, the README for the ServerSideRender component mentions the following:

ServerSideRender should be regarded as a fallback or legacy mechanism, it is not appropriate for developing new features against.

New blocks should be built in conjunction with any necessary REST API endpoints, so that JavaScript can be used for rendering client-side in the edit function. This gives the best user experience, instead of relying on using the PHP render_callback. The logic necessary for rendering should be included in the endpoint, so that both the client-side JavaScript and server-side PHP logic should require a minimal amount of differences.

I would like to resolve this contradiction somehow. One way to do this would be to remove the above note from the ServerSideRender component.

Yeah! this is fine for me I think. I think for these php only registered blocks, I think ServerSideRender is fine but if you're writing a specific Edit component for your block you should probably avoid it. I don't know how to codify this though.

I also think both things can be true at the same time. Using the ServerSideRender component does not provide the user with the best experience. It is slower to render attribute changes, and inline editing of fields is simply not possible. That doesn't mean there isn't value to this for specific, simple blocks that don't really have much to configure.

This new method for registering blocks using only PHP will never be the default for building rich, interactive blocks. But it is a nice entry way for simple blocks.

Any limitations for ServerSideRender will apply to PHP-only blocks; we should document those to avoid wrong assumptions by consumers.

Examples:

• Complex block supports don't work out of the box - blockGap support preview does not work with ServerSideRender #69323.
• Inner Blocks aren't supported - ServerSideRender does not expose block's content #10478.

I'm sure more shortcomings of SSR rendering will come to light when folks start using this method.

I'm pondering whether we should keep this for WP 7.0 (so plugin only for now without php backport)

I also think there is no rush for this, and it could make sense to target 7.0 so that we include some followups

Flaky tests detected in e35eab1.
Some tests passed with failed attempts. The failures may not be related to this commit but are still reported for visibility. See the documentation for more information.

🔍 Workflow run URL: https://github.com/WordPress/gutenberg/actions/runs/17982357960
📝 Reported issues:

• [Flaky Test] should select the wrapper div for a group #71211 in /test/e2e/specs/editor/various/block-hierarchy-navigation.spec.js

Additionally, we may need to enable skipBlockSupportAttributes by default; otherwise, we'll end up with double rendering of borders, padding, shadow support, etc.

Good catch @t-hamano , there is a double border (although no double padding):