PHP APIs Overview

[mtias]

This issue is an overview on the new PHP APIs remaining to be introduced or extended. Important aspects to keep in mind include internal consistency and consistency with other WP family of functions.

General

• *_has_blocks boolean check.
• Add a has_block( $block_name ) variation. Add has_block() function #3773
• Use has_blocks() to augment HTML classes like post_class. Generate body class for Gutenberg pages & provide helper function #4418, PR Add generic has_blocks function #8631
• Expose block data directly through REST API endpoints. Add block data to REST API (post) response data #4763
• Expand get_posts filter parameter to allow a blocks as a return shape. https://core.trac.wordpress.org/ticket/53602
• get_post_blocks() or get_blocks_from_post() returning an array of blocks with their data. PR Introduce get_blocks function #9208
• Strip Blocks from auto-generated excerpts. Strip Blocks from Auto-Generated Excerpts #7268 ; related get_the_excerpt is taking PHP out of memory in a block rendering #5572, PR Introduce strip_dynamic_blocks() for excerpts  #8984
• Make it easier to filter blocks on the server Apply a filter to each rendered static and dynamic block #11523

Block API

• Server-side awareness of block types. Block API: Server-side awareness of block types #2751
• • Introduce block definitions and implementations. Block API: Introduce block definitions and implementations #6733
• • Expose available blocks via an API. Expose available blocks via an API #4116
• • Proper server-side APIs for block modification. Proper server-side APIs for block modification #6494
• Pass the block name to the render callback. Pass the block name to the render callback #4671
• Pass inner content to render callback (optionally?). Pass content to render callback #5760
• Ability to register / hook a callback without the non-idiomatic register_block_type requirement. Calling render_callback() without register_block_type? #4723 Block API: Server-side awareness of block types #2751

To Consider

• A way to define block templates in page headers. Suggestion: Block templates in page template header #3835
• Support for accessing variations of a post in different languages through the REST API. Support for accessing variations of a post in different languages through the REST API #5958

Bugs

• get_the_excerpt is taking PHP out of memory in a block rendering. get_the_excerpt is taking PHP out of memory in a block rendering #5572, PR Introduce strip_dynamic_blocks() for excerpts  #8984

[mtias]

Note some of these functions depend on resolution to #8244.

[aduth]

Naming / prefixing was discussed in today's Slack Core Editor meeting:

https://wordpress.slack.com/archives/C02QB2JS7/p1534339558000100

tl;dr Tending toward wp_ prefixing, but favoring consistency where appropriate (i.e. register_block_type without prefix for consistency with existing register_post_type, register_taxonomy, register_rest_route).

[obenland]

Expand get_posts filter parameter to allow a blocks as a return shape.

Would you consider this a post-merge task? get_post() doesn't have any filters, so I'm not sure how we'd expand it from within the plugin

[mtias]

Would you consider this a post-merge task?

Might be good to start a core ticket / patch and keep it going until merge.

[gschoppe]

do_blocks() also still needs to be refactored to use the PHP PEG parser, rather than Regular Expressions. having two parallel systems to parse the post content, based on two different technology stacks, is going to lead to a lot of bugs with the small differences between the two implementations, as well as creating a dead end for users who need a proper block parse on page load.

The argument I've heard already is that people who need a full parse can use the PEG parser themselves, when they need it, but as soon as plugins start doing this, we will have sites where multiple passes of the PEG parser are being run by different plugins. At very minimum, we need a way to set a flag to trigger one canonical pass of the PEG parser that various plugins can hook into, rather than each implementing their own... of course, once we have that, the question remains: why isn't the PEG parser just being used on every load?

If the block-comment format is meant to be a data structure, it needs to be treated in a structured manner by both PHP and JS, not treated as structured by JS and as a content blob that we scrape with a regex by PHP.

[danielbachhuber]

Closed #4763 in favor of this issue, so it's make sure it's addressed one way or another here.

[mtias]

Many of these have been implemented, others are in progress, and the rest remain to be fleshed out for future versions. Moving this issue to 5.1.

[jmikrut]

Any update regarding #4763? Anxiously awaiting the ability to use Block data through the API in a granular manner.

[mcsf]

@jmikrut: Hi. The time is now good to revisit server-side registration of blocks, which is arguably a necessary step for better API-borne block data. See § Action Items in the summary of the last #core-editor chat.

[Legym]

Many sites are going down a headless WP + React/Vue frontend implementation. It would be beneficial to have a visual representation (block) in WP and have these front-end frameworks handle everything else client side.

Littering the front-end with v-html (vue) or dangerouslySetInnerHTML (react) is not ideal because we can't pass state down in a simple manner.

[solidevolution]

+1 to get raw block data instead of rendered html via REST API (or further, GraphQL)

[aslak-dirdal]

Any update on "Expose block data directly through REST API endpoints."?

[Soean]

@aslakagens For an update see the Block Type Registration RFC: https://github.com/WordPress/gutenberg/blob/add/block-registration-rfc/docs/rfc/block-registration.md

[mattpilott]

@aslakagens For an update see the Block Type Registration RFC: https://github.com/WordPress/gutenberg/blob/add/block-registration-rfc/docs/rfc/block-registration.md

That link is dead btw

[Soean]

It was moved, because it's implemented and not a RFC anymore: https://github.com/WordPress/gutenberg/blob/master/docs/designers-developers/developers/block-api/block-metadata.md

[mtias]

From all these, the " Expand get_posts filter parameter to allow a blocks as a return shape." is still something I think could be nice to introduce, particularly as server processing has matured and we have REST endpoints now as well.

[mattpilott]

Is there any movement or news on being able to access block data in the rest api like royboys gutenberg object plugin does?

[kuasha420]

@matt3224 I'm interested to know about this as well.

[mtias]

Check out #2649

[gziolo]

Ability to register / hook a callback without the non-idiomatic register_block_type requirement.

It's possible with the followin hook:
https://developer.wordpress.org/reference/hooks/register_block_type_args/

Pass the block name to the render callback.

It's possible with changes landed in #21467.

[gziolo]

I filed two tickets in WordPress Trac for better visibility of some remaining tasks.

Expand get_posts filter parameter to allow a blocks as a return shape

https://core.trac.wordpress.org/ticket/53602

Expose block data directly through REST API endpoints

https://core.trac.wordpress.org/ticket/53603

[mtias]

I'm going to close this now that the pending items are transferred.