So if I add a
language-plaintext class to a Code block’s
code element, to prevent highlight.js from highlighting it, WordPress’ block editor gives me the dreaded “unexpected or invalid content.” Only way out is to convert it to a Custom HTML block (which in this case is kind of okay).
Share on Mastodon used to rely on (only) the transition_post_status hook to kick off a request to Mastodon’s API. Then Gutenberg came.
So if I add a
TIL: Looks like, if you’re looking to display (or otherwise use) post meta in WordPress’ block editor (but not ever have it updated by the front end),
register_rest_field()is your friend, rather than
Quick recap, mostly just for me: In the classic editor, you have a custom meta box. You hit “Save,” “Publish,” “Update,” etc., it will submit the page; on the back end, you now have access to the various $_POST variables and can use them to update, e.g., (custom) post meta (“custom fields”). Easy peasy. With…
Working on a Facepile “theme” block for IndieBlocks, which would show a post’s “like,” “bookmark,” and “repost” webmentions. Doesn’t support the Webmention plugin, yet. (It does work with IndieBlocks’ webmentions, which use a slightly different set of custom fields, etc.)
In reply to https://jan.boddez.net/articles/conditionally-display-innerblocks. Neat Gutenberg trick: you …
In reply to.
Neat Gutenberg trick: you can have a block accept (and store)
InnerBlocks, yet still employ a server-side render callback in which you can run all sorts of logic before returning … the block’s “static” contents.
Works for things other than
InnerBlocks, too, by the way.
The trick is
$block->render( array( 'dynamic' => false ) ), which returns whatever was saved in the editor. And that can still contain dynamic content, by means of
Been adding a few blocks to IndieBlocks where I output certain elements only if there really is something to show.