Skip to content
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

Pass content to render callback #5760

mattheu opened this issue Mar 23, 2018 · 6 comments


Copy link

@mattheu mattheu commented Mar 23, 2018

Issue Overview

The block content is no longer available in the render callback. It was removed here.

However, it would be very useful to have this data available. I have 2 use cases.

  • I have a partially dynamic block. I am saving my block as HTML in the post content. But I want a small part of this to be modified.
  • I have a container block with nested children. The block is rendered in PHP. I have no way to get the child block data.

There are alternative ways to achive these goals. I could have my dynamic block fully rendered in PHP. I could just allow my container block to store all the data in the post content. However this isn't very flexible.


This comment has been minimized.

Copy link

@gschoppe gschoppe commented Apr 4, 2018

Other necessary situations for content to be accessible inside the render callback include:

  • Members-Only functionality - two different sets of blocks are served to different users
  • Fallback data functionality - if a query fails, render a set of blocks as a fallback (imagine no results found on a recent posts block)
  • Contextual rendering - render content in one way for a single page, another for the archive view, and a third for the RSS/Atom feeds

This comment has been minimized.

Copy link

@bobbingwide bobbingwide commented Apr 5, 2018

I have quite a few more examples where the block content is required by the dynamic block renderer. Some of these are mentioned in the above referenced issue; oik-block/22.

In more complicated examples the content of the shortcode / block may require pagination to:

  1. Make the content appear more manageable on the front end.
  2. Reduce server processing for each request.

My solutions, which involve shortcodes, perform pagination logic against the shortcode content.


This comment has been minimized.

Copy link

@mcsf mcsf commented Jul 17, 2018

This is probably something to have. The issues cross-referenced above may suggest other use cases. Further, here's a use case for the core Gallery block:

#3852 (comment)


This comment has been minimized.

Copy link
Contributor Author

@mattheu mattheu commented Jul 17, 2018

Just for reference - there's a pretty stale PR here #6239


This comment has been minimized.

Copy link

@gschoppe gschoppe commented Jul 17, 2018

For two of the examples I provided above, it is also necessary to have the ability to pass child block objects into a render callback. Member content, for example, should be able to contain any number of blocks, and then conditionally choose whether to render them or not. This functionality is currently possible with nested shortcodes, so should not be regressed by moving to Gutenberg blocks.

The referenced PR does not appear to include this functionality.


This comment has been minimized.

Copy link

@pento pento commented Jul 30, 2018

Passing the content to the render callback was re-added in #8077, it'll be released in Gutenberg 3.4. 🙂

Passing the child block objects is a little trickier, and will likely require replacing the current do_blocks() regex with a much faster parser. See #8244 for an overview ticket of the various approaches towards that.

@pento pento closed this Jul 30, 2018
@mtias mtias mentioned this issue Aug 1, 2018
6 of 16 tasks complete
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
None yet
6 participants
You can’t perform that action at this time.