Make WordPress Core

Opened 6 years ago

Last modified 4 years ago

#46004 assigned enhancement

Allow actions based on blocks in the current content

Reported by: joostdevalk's profile joostdevalk Owned by: francina's profile francina
Milestone: Future Release Priority: normal
Severity: normal Version:
Component: Bootstrap/Load Keywords: has-patch dev-feedback
Focuses: Cc:

Description

We're finding ourselves having to do stuff based on which blocks are in the page, and others are probably experiencing the same thing. So I think it's wise to add an action in the WP bootstrap that allows for people to do something based on which blocks will be on the page. For now only for singular pages, but as Phase 2 of Gutenberg is expanded, this should probably be expanded to other page types.

Attachments (1)

parsed_blocks.diff (985 bytes) - added by joostdevalk 6 years ago.
First patch

Download all attachments as: .zip

Change History (7)

@joostdevalk
6 years ago

First patch

This ticket was mentioned in Slack in #core-editor by joostdevalk. View the logs.


6 years ago

This ticket was mentioned in Slack in #meta by joostdevalk. View the logs.


6 years ago

#3 @birgire
6 years ago

That sounds interesting.

Few things come to mind:

This would mean doing the block parsing twice on the singular post content, on each page load, since the other parse_blocks() is in do_blocks(). I've not profiled parse_blocks() but I wonder how it scales with the size of the post content?

Blocks can be removed dynamically from the post content, e.g. via the render_block filter, so in that case there might be some mismatch regarding what blocks are actually displayed on the page and what blocks are seen within the parsed_blocks action.

I also wonder if has_blocks() would be useful as a pre condition or e.g. as a second input argument available for parsed_blocks action callbacks. I can imagine in some cases it would be helpful to know if there are no blocks at all.

If get_post_content() is used, then one would need to handle cases like when:

  • the post content is password protected
  • the post content is split up into sub-pages e.g. with <!--nextpage-->
  • ...

I would also think having use cases would help to better understand the need for such an action and what's needed to implement it.

#4 @francina
4 years ago

  • Milestone changed from Awaiting Review to 5.8
  • Owner set to francina
  • Status changed from new to assigned

#5 @desrosj
4 years ago

@francina can you provide a status update on this one since you moved to 5.8?

I think answers to @birgire's questions would be a great first step. I'm a bit skeptical this will be ready in time for feature freeze on 25 May.

#6 @francina
4 years ago

  • Milestone changed from 5.8 to Future Release

I was overly confident about the timeline I believe. Changing to future release.

Note: See TracTickets for help on using tickets.