Some Drupal blocks don't render properly

I believe this is touched on in upcoming alpha.

I've created a patch that adds support for rendering the content in the blocks both on the editor page and the rendered page. I suspect it won't work with all kinds of blocks because some of the blocks require a specific context that the current page might not have.

The patch works on top of the 8.x-1.x branch of the repo as of 2018-10-08 (188dd52a1f).

Peter, on dev branch, the block rendering at frontend was already working. In fact, also working on alpha-3 but the text filter that handles the block rendering was disabled by default:
(admin/config/content/formats/manage/gutenberg)

At dev branch, the text filter is now enabled by default.

Anyway, I quickly reviewed your patch and it seems you took a different approach for rendering the blocks. Would care to do a short summary of your approach?

Thanks.

When you say the dev branch, which branch do you mean? The only branch I see is 8.x-1.x and that's the one I've been using. Is there another repository? I'm using https://git.drupal.org/project/gutenberg.git.

I think the difference between your approach and my approach is that for mine you can also do blocks that have context. In yours, custom blocks were working fine, but blocks that need context weren't working. For example, if I'm editing a basic page, with the latest version of the 8.x-1.x branch, if you try to add the Drupal block called "Title [Content]" to the page, you just get a "Loading..." in the block area in the editor. And you get this error in watchdog:

Drupal\Component\Plugin\Exception\ContextException: The 'entity:node' context is required and not present. in Drupal\Core\Plugin\Context\Context->getContextValue() (line 71 of web/core/lib/Drupal/Core/Plugin/Context/Context.php).

If I save the page, I just get that same error when viewing the page.

With my approach, when editing, the AJAX call passes the current page path to /editor/blocks/load, and then it sets up the context as if we are on that page when it renders the block. So when you add the "Title [Content]" block, you get the current page title of the page you are editing in that block in the editor and it also renders when you view the page.

Never mind about the dev branch questions. I think that was all just because I thought the rendering was broken because the blocks like "Title [Content]" weren't working and you thought the rendering was working because custom blocks were working.

Ok, some misunderstandings here...

• mkostrzewa reported that Drupal blocks weren't being rendered at frontend. Since he reported he was using alpha-3, I assumed it was all Drupal blocks and the issue was because the text filter (Gutenberg block filter) was disabled.
• I mentioned dev branch when it should be 8.x-1.x ;)

Peter, good work by adding, at least, the path context. But I tested your patch and I'm afraid the Page title block still doesn't work. I've tested with a fresh install + 8.x-1.x + patch #5.

Just to clarify, I tried to add the Page title [core] block. Can't find Title [Content] on my install.

I looked into this in some depth. I think "Page title [core]" is probably the hardest block to get to work properly. The title handling has tons of special cases (see: https://www.drupal.org/node/2359901). The way Drupal works right now you have to generate the entire render array for the page in order to get the title because modules are allowed to change the title based on content in the page.

I looked at how the block_field module handles this block and it just sets the title to "Block" if you try and add that block via a field.

I tried just setting the title to "[Title]" when editing, but then rendering it properly when viewing, but even that is tricky because in order to get Drupal to set the title on the block when rendering the page, you need to get the block into the BlockRepository and it needs to be visible in a region for Drupal to set the title on it. The setTitle for the title block happens really late in the render process in the middle of where Drupal is converting the render array to HTML.

I looked into subscribing to the KernelEvents::VIEW event to try and get the title out of the render array, but that actually happens a tiny bit too early because it gets called a little before the HTMLRenderer does its title editing stuff.

The closest I've gotten so far is to implement a new DisplayVariant that inherits from BlockPageVariant and override just setTitle to grab the title and set that on any TitleBlockPluginInterface blocks. The problem with that is that BlockFilter returns the block already rendered to HTML and that happens as the render array is getting created which is all happening way before the DisplayVariant stuff happens. This makes sense with how filters for text fields are supposed to work.

There's some other modules that let you insert blocks into content so I'm going to look into those to see if they can insert this block and then maybe steal their technique.

I looked at some other plugins:

shortcode: doesn't do blocks
insert_block: doesn't work with the title block
panels: works with title block

I haven't looked at exactly how Panels works, but it does it in a way similar to the last thing I tried which is that Panels overrides DisplayVariant. Of course, Panels isn't trying to be a text editor, so it doesn't try to render blocks during the filter phase.

I'm thinking now maybe we can do some combined thing where the filter doesn't return straight html, but instead returns something that we can then turn into a render array that includes a block.

I believe all available blocks now render fine (RC).