Gutenberg: 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

• [x] *_has_blocks boolean check.
• [x] Add a has_block( $block_name ) variation. #3773
• [x] Use has_blocks() to augment HTML classes like post_class. #4418, PR #8631
• [ ] Expose block data directly through REST API endpoints. ~#4763~
• [ ] Expand get_posts filter parameter to allow a blocks as a return shape.
• [ ] get_post_blocks() or get_blocks_from_post() returning an array of blocks with their data. PR #9208
• [x] Strip Blocks from auto-generated excerpts. #7268 ; related #5572, PR #8984
• [ ] Make it easier to filter blocks on the server #11523

Block API

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

To Consider

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

Bugs

• [x] get_the_excerpt is taking PHP out of memory in a block rendering. #5572, PR #8984

[mtias]

Note some of these functions depend on resolution to https://github.com/WordPress/gutenberg/issues/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

[matt3224]

@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.

[matt3224]

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