New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

PHP APIs Overview #8352

Open
mtias opened this Issue Aug 1, 2018 · 5 comments

Comments

Projects
5 participants
@mtias
Contributor

mtias commented Aug 1, 2018

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. #3773
  • 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
  • Strip Blocks from auto-generated excerpts. #7268 ; related #5572, PR #8984

Block API

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

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

  • get_the_excerpt is taking PHP out of memory in a block rendering. #5572, PR #8984
@mtias

This comment has been minimized.

Show comment
Hide comment
@mtias

mtias Aug 1, 2018

Contributor

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

Contributor

mtias commented Aug 1, 2018

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

@danielbachhuber danielbachhuber referenced this issue Aug 7, 2018

Closed

3773 add has block functions #8340

4 of 4 tasks complete

@danielbachhuber danielbachhuber added this to the WordPress 5.0 milestone Aug 7, 2018

@aduth aduth added this to To Do in API freeze via automation Aug 15, 2018

@aduth aduth referenced this issue Aug 15, 2018

Merged

Add generic has_blocks function #8631

4 of 4 tasks complete
@aduth

This comment has been minimized.

Show comment
Hide comment
@aduth

aduth Aug 15, 2018

Member

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

Member

aduth commented Aug 15, 2018

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

pento added a commit that referenced this issue Aug 16, 2018

Add generic has_blocks() function (#8631)
This deprecates `gutenberg_post_has_blocks()`.

See #4418, #8352.
@obenland

This comment has been minimized.

Show comment
Hide comment
@obenland

obenland Aug 20, 2018

Member

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

Member

obenland commented Aug 20, 2018

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

This comment has been minimized.

Show comment
Hide comment
@mtias

mtias Aug 20, 2018

Contributor

Would you consider this a post-merge task?

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

Contributor

mtias commented Aug 20, 2018

Would you consider this a post-merge task?

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

obenland added a commit that referenced this issue Aug 21, 2018

Introduce get_blocks function
A convenient wrapper for `gutenberg_parse_blocks()` that can be used as a template tag as well, complimentary to `has_blocks()` and `has_block()`.

See #8352.

@obenland obenland referenced this issue Aug 21, 2018

Open

Introduce get_blocks function #9208

3 of 3 tasks complete

@danielbachhuber danielbachhuber referenced this issue Aug 22, 2018

Closed

Pass content to block render callback #6239

4 of 4 tasks complete
@gschoppe

This comment has been minimized.

Show comment
Hide comment
@gschoppe

gschoppe Aug 22, 2018

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.

gschoppe commented Aug 22, 2018

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment