This won’t work as you expect it, PHP is intended for server rendered blocks, it isn’t aware of the editor context unless it’s told the context. But to do that you need to read it in and pass it to the component on the JS side, and then read it in again on the PHP side. On top of that, you can’t use raw block markup like this inside a PHP rendered block, PHP rendered blocks are meant to be monolithic with no internal blocks, the editor is neither aware of nor understands when you return internal blocks that are printed via PHP like this.
So key takeaways:
- You can’t return raw block markup in rendered PHP like this
- Inner blocks are meant to be inner blocks, you can’t define them entirely in PHP.
- You’re very likely to cause compatibility issues and break block verification as it’s not expecting child blocks on a block that doesn’t support children. It’ll also cause issues because the save component won’t generate what it’s expecting.
- This particular approach is a dead end and not fixable, you will need to take a different approach
- Instead of
<!-- wp:post-title /-->you would need to render the block directly and return the rendered version- Most likely this means
the_title() - If you insist on the use of block markup, it will need to be passed through a function that renders the block such as
do_blocks( https://developer.wordpress.org/reference/functions/do_blocks/ ), but these will not be editable, the editor will see it as raw HTML only. You will also need- You might need to use
parse_blocksandrender_blockto provide context such as the current post for them to show the correct.
- You might need to use
- Most likely this means
- Do you actually need a custom block? A Block pattern with a query loop and title block that’s locked so the user can’t edit/rearrange it would be far simpler and easier, and more future proof
Fundamentally a server side rendered block is an opportunity to use PHP to render a chunk of HTML that could change on each view. It’s not intended as a container block and was designed with the intention of it being a singular monolithic component. There may be ways of allowing child blocks if you give up on using PHP in the editor and only use it on the frontend, but these add complexity, still rely on pure JS block editor and save components, and still don’t use raw block markup like your question does ( a synced pattern or a block template would be the method for defining the inner blocks )