While working with Webforms embedded in Gutenberg as Drupal Block I encountered an issue. On submitting webform such an error occurs:

The website encountered an unexpected error. Please try again later.</br></br><em class="placeholder">LogicException</em>: Bubbling failed. in <em class="placeholder">Drupal\Core\Render\Renderer-&gt;executeInRenderContext()</em> (line <em class="placeholder">585</em> of <em class="placeholder">core/lib/Drupal/Core/Render/Renderer.php</em>). <pre class="backtrace">Drupal\Core\Render\MainContent\HtmlRenderer-&gt;prepare(Array, Object, Object) (Line: 117)
Drupal\Core\Render\MainContent\HtmlRenderer-&gt;renderResponse(Array, Object, Object) (Line: 90)
Drupal\Core\EventSubscriber\MainContentViewSubscriber-&gt;onViewRenderArray(Object, &#039;kernel.view&#039;, Object)
call_user_func(Array, Object, &#039;kernel.view&#039;, Object) (Line: 111)
Drupal\Component\EventDispatcher\ContainerAwareEventDispatcher-&gt;dispatch(&#039;kernel.view&#039;, Object) (Line: 156)
Symfony\Component\HttpKernel\HttpKernel-&gt;handleRaw(Object, 1) (Line: 68)
Symfony\Component\HttpKernel\HttpKernel-&gt;handle(Object, 1, 1) (Line: 57)
Drupal\Core\StackMiddleware\Session-&gt;handle(Object, 1, 1) (Line: 47)
Drupal\Core\StackMiddleware\KernelPreHandle-&gt;handle(Object, 1, 1) (Line: 106)
Drupal\page_cache\StackMiddleware\PageCache-&gt;pass(Object, 1, 1) (Line: 85)
Drupal\page_cache\StackMiddleware\PageCache-&gt;handle(Object, 1, 1) (Line: 47)
Drupal\Core\StackMiddleware\ReverseProxyMiddleware-&gt;handle(Object, 1, 1) (Line: 52)
Drupal\Core\StackMiddleware\NegotiationMiddleware-&gt;handle(Object, 1, 1) (Line: 23)
Stack\StackedHttpKernel-&gt;handle(Object, 1, 1) (Line: 693)
Drupal\Core\DrupalKernel-&gt;handle(Object) (Line: 19)

Steps to reproduce:
1. Create block with a reference to any webform.
2. Enable that block in a Content Type.
3. Place a block with webform and save node (note that currently there is a bug with node save and it can be done only via method described here: https://www.drupal.org/project/gutenberg/issues/3021675#comment-13240205)
4. Try to submit form.

Support from Acquia helps fund testing for Drupal Acquia logo

Comments

kszarek created an issue. See original summary.

kszarek’s picture

Here I introduce a patch that fixes issue of having more than one render context.

sayco’s picture

Kamil I reviewed your patch, however, it will only solve the webform issue, by breaking the functionality to load block instances.
I will try to find some better solution for that.

marcofernandes’s picture

Status: Needs review » Needs work

  • sayco committed 84f1a29 on 8.x-1.x
    Issue #3078027 by sayco: Metadata bubbling error
    
sayco’s picture

Assigned: kszarek » marcofernandes
Status: Needs work » Needs review
FileSize
777 bytes

I've managed to fix the issue and pushed the changes to the dev branch. I'm also attaching a patch, so it could be used for stable and older branches. Not much that was changed, mostly the issue was caused by calling render method instead of renderRoot on renderer service.
Still would be great to review the patch. If everything is fine, then we could safely close this issue.

onedotover’s picture

One side effect of using renderRoot() as opposed to render() is library attachments are not added using renderRoot(). So blocks using something like the following will not have their attachments included:

  public function build() {
    $content = [
      '#markup' => 'Example.',
      '#attached' => [
        'library' => [
          'my_module/library_name'
        ]
      ]
    ];

    return $content;
  }
marx009’s picture

Hi, the patch in #6 is merged into the stable release but it makes webforms unable to be sent by ajax (as said in #7). I've reverted the code from #6 and everything (including inline form errors) works. Also I couldn't reproduce the inital bug. Is it possible that the initial problem has been resolved somewhere else and usage of renderRoot is now a new problem?

onedotover’s picture

I checked this on 8x.1.9 and the issue in #7 still exists. When I revert that patch, my block libraries load properly.

marx009 brings up a good question. I also tested a webform block both with AJAX and without and was able to submit as a block with #6 reverted.

sayco’s picture

Well, this is smth that we definitely need to look at. Initially calling only the
->render()
throws some other errors.
I think we might need to add a render context to render method to avoid metadata bubbling error, simillary to what was suggested here https://drupal.stackexchange.com/questions/273908/rendered-webform-has-n...

marcofernandes’s picture

Status: Needs review » Needs work
GlarDup’s picture

Is there any progress or a workaround for this issue?
I'm using a block with a webform, but because the form doesn't have javascript, antibot prevents submission. I don't like having to turn off antibot for my webforms.

kevin-philippe’s picture

Status: Needs work » Needs review
FileSize
424 bytes

Here I introduce a patch that fixes issue on 8.x-2.0-beta2.

szeidler’s picture

Status: Needs review » Reviewed & tested by the community

Patch #13 works good for me. Without the patch adding Drupal blocks can be really painful, when you use conditionally attached libraries instead of global styles.css and js.

sayco’s picture

The patch #13 works indeed, but I wouldn't consider it as a real fix. It's more kind of a workaround for the time being.

I believe that the real implementation should be quite similliar to what we have defined for example in Drupal\views\ControllerViewAjaxController (from the core views module)
It looks more or less like this.

        $context = new RenderContext();
        $preview = $this->renderer->executeInRenderContext($context, function () use ($view, $display_id, $args) {
          return $view->preview($display_id, $args);
        });
        if (!$context->isEmpty()) {
          $bubbleable_metadata = $context->pop();
          BubbleableMetadata::createFromRenderArray($preview)
            ->merge($bubbleable_metadata)
            ->applyTo($preview);
        }

I don't have time for now to do proper implementation and testing, but we should go rather this way.
In theory, this piece of code should be working for our case. Would be great if someone could check/test it :-)

$context = new RenderContext();
$output = $this->renderer->executeInRenderContext($context, function () use (&$render) {
  return $this->renderer->render($render);
});

if (!$context->isEmpty()) {
  $bubbleable_metadata = $context->pop();
  BubbleableMetadata::createFromRenderArray($output)
    ->merge($bubbleable_metadata)
    ->applyTo($output);
}

return $output;
sayco’s picture

Status: Reviewed & tested by the community » Needs work
szeidler’s picture

Thanks for the input @sayco.

The difference is, that return $view->preview($display_id, $args); returns a render array, $this->renderer->render($render); an object. Therefore it cannot be used like this.

thorandre’s picture

Title: Metadata bubbling error. » Metadata bubbling error
Version: 8.x-1.x-dev » 8.x-2.x-dev
Priority: Normal » Major
Issue tags: +v2.1

Assigned to Marco. Bumping to major. Planning to solve this in an upcoming release v2.1 before the summer.

szeidler’s picture

Status: Needs work » Active

I just checked this once again. It seems that this issue has been resolved in 8.x-2.x via #3107797: Dynamic render blocks support (API rework using WordPress block parser rather than regex). I just tried to reproduce the problem with current stable 8.x-2.0 and libraries get attached now, embedded views ajax blocks are working and also webform does not throw an metadata bubble error anymore.

Could someone check and verify this? If yes, we might be able to close this one.

hkirsman’s picture

I don't have any cache errors with 2.0

thorandre credited roborn.

thorandre’s picture

thorandre’s picture

Status: Active » Fixed

Status: Fixed » Closed (fixed)

Automatically closed - issue fixed for 2 weeks with no activity.

rudam’s picture

it still not possible to attach libraries using hook 'preprocess_gutenberg_block'
tryed both DEV and 2.2

I want to dynamicaly add libraries for each block instead of a global css as #14 said.
Using 'preprocess_field_gutenberg_text' to grab all the block names in the field and then attach their libs.

szeidler’s picture

May I ask you to open a follow up issue with your issue description? Otherwise it's easy to forget about your comment.

The bug fixed in the issue was basically for example:
A views block has the library attached. This was not bubbled up meaning when the block was placed in Gutenberg then the library was invoked, unless it was attached at another non Gutenberg component. And this appears to be working as far as I can see it.

rudam’s picture

sure!