I finally figured it out. Just posting it here if anyone needs to do this as the Gutenberg documentation lacks code examples. With reference to the below code, blockIndex is the block you are dealing with; and startIndex and endIndex are ranges to annotate in context of the block: // Get latest modified content of … Read more
I’ve spent all day debugging this issue, and by looking at the code I can guess we shared the same problems: assuming $script_handle is CUSTOM-block-ref-holder, the PHP file is almost correct. wp_set_script_translations needs the full path to work. In your case, although you probably need to adjust for your path, it should be something like … Read more
Just for others that see this post, as I am sure you are already aware, the noreferrer is added as a security fix for IE and Edge browsers and a few others, that do not support the rel=”noopener” security fix for links that are opened in a new tab. To remove the noreferrer, it is … Read more
That’s not how that component works. onRemove is called when the link is unlinked, via a button that only appears when certain conditions are met: { onRemove && value && ! isEditingLink && ! isCreatingPage && ( <Button className=”block-editor-link-control__unlink” isDestructive variant=”link” onClick={ onRemove } > { __( ‘Unlink’ ) } </Button> ) } https://github.com/WordPress/gutenberg/blob/6eac4a26f143c7378c3b39b5a83271538f36dfa9/packages/block-editor/src/components/link-control/index.js#L270 When … Read more
This is caused by wptexturize and the use of a standard <div> to contain your code. See https://developer.wordpress.org/reference/functions/wptexturize/ Instead, markup code as code: Text enclosed in the tags <pre>, <code>, <kbd>, <style>, <script>, and <tt> will be skipped. This list of tags can be changed with the no_texturize_tags filter. Note that the HTML block just … Read more
If you turned on script debugging or the SCRIPT_DEBUG constant in WordPress, then you would’ve noticed that your block type causes React to throw this warning: “Warning: React does not recognize the tagName prop on a DOM element.“, so when developing block types, you should enable script debugging — at least, you’ll know your code … Read more
After discovering the exact problem in this case, the request headers being too large because ServerSideRender sending too many attributes in a GET request, I opened a ticket on the Gutenberg development repository proposing a few possible solutions for this issue. And the issue had actually already been addressed because I wasn’t the first one … Read more
ServerSideRender uses the Block Renderer API endpoint (/wp/v2/block-renderer/<name>) which does not parse inner blocks, hence the $content in your block render callback would naturally be empty. However, retrieving the inner blocks is pretty easy and as you’ve thought, you can set the blocks (or their content) as an attribute that you would pass to ServerSideRender. … Read more
This worked for me, add this to the end of your themes functions.php file: add_action(‘admin_head’, ‘wp_blocks_fullwidth’); function wp_blocks_fullwidth() { echo ‘<style> .wp-block { max-width: unset; } </style>’; }
as @Alvero pointed out in the comments, instead of just supplying wp-api in the block registration, you now need to specify wp-api-fetch. $index_js=”sample-post/index.js”; wp_register_script( ‘sample-post-block-block-editor’, plugins_url( $index_js, __FILE__ ), array( ‘wp-blocks’, ‘wp-i18n’, ‘wp-element’, ‘wp-api-fetch’, ), filemtime( “$dir/$index_js” ) ); Then within your block, you call it using the wp.apiFetch function: var registerBlockType = wp.blocks.registerBlockType, el … Read more