Early Bird Registration for DrupalCon Portland 2024 is open! Register by 23:59 PST on 31 March 2024, to get $100 off your ticket.
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->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->prepare(Array, Object, Object) (Line: 117)
Drupal\Core\Render\MainContent\HtmlRenderer->renderResponse(Array, Object, Object) (Line: 90)
Drupal\Core\EventSubscriber\MainContentViewSubscriber->onViewRenderArray(Object, 'kernel.view', Object)
call_user_func(Array, Object, 'kernel.view', Object) (Line: 111)
Drupal\Component\EventDispatcher\ContainerAwareEventDispatcher->dispatch('kernel.view', Object) (Line: 156)
Symfony\Component\HttpKernel\HttpKernel->handleRaw(Object, 1) (Line: 68)
Symfony\Component\HttpKernel\HttpKernel->handle(Object, 1, 1) (Line: 57)
Drupal\Core\StackMiddleware\Session->handle(Object, 1, 1) (Line: 47)
Drupal\Core\StackMiddleware\KernelPreHandle->handle(Object, 1, 1) (Line: 106)
Drupal\page_cache\StackMiddleware\PageCache->pass(Object, 1, 1) (Line: 85)
Drupal\page_cache\StackMiddleware\PageCache->handle(Object, 1, 1) (Line: 47)
Drupal\Core\StackMiddleware\ReverseProxyMiddleware->handle(Object, 1, 1) (Line: 52)
Drupal\Core\StackMiddleware\NegotiationMiddleware->handle(Object, 1, 1) (Line: 23)
Stack\StackedHttpKernel->handle(Object, 1, 1) (Line: 693)
Drupal\Core\DrupalKernel->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.
Comment | File | Size | Author |
---|---|---|---|
#13 | gutenberg-fix-metadata-bubbling-3078027-13.patch | 424 bytes | kevin-philippe |
#6 | gutenberg-fix-metadata-bubbling-3078027-5.patch | 777 bytes | sayco |
#2 | gutenberg-fix-metadata-bubbling-3078027-1.patch | 539 bytes | kszarek |
Comments
Comment #2
kszarek CreditAttribution: kszarek commentedHere I introduce a patch that fixes issue of having more than one render context.
Comment #3
sayco CreditAttribution: sayco commentedKamil 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.
Comment #4
marcofernandes CreditAttribution: marcofernandes at Frontkom commentedComment #6
sayco CreditAttribution: sayco commentedI'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.
Comment #7
onedotover CreditAttribution: onedotover commentedOne 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:
Comment #8
marx009 CreditAttribution: marx009 commentedHi, 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?
Comment #9
onedotover CreditAttribution: onedotover commentedI 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.
Comment #10
sayco CreditAttribution: sayco commentedWell, 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...
Comment #11
marcofernandes CreditAttribution: marcofernandes at Frontkom commentedComment #12
GlarDupIs 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.
Comment #13
kevin-philippeHere I introduce a patch that fixes issue on 8.x-2.0-beta2.
Comment #14
szeidler CreditAttribution: szeidler at Ramsalt Lab commentedPatch #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.
Comment #15
sayco CreditAttribution: sayco commentedThe 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.
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 :-)
Comment #16
sayco CreditAttribution: sayco commentedComment #17
szeidler CreditAttribution: szeidler at Ramsalt Lab commentedThanks 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.Comment #18
thorandre CreditAttribution: thorandre at Frontkom commentedAssigned to Marco. Bumping to major. Planning to solve this in an upcoming release v2.1 before the summer.
Comment #19
szeidler CreditAttribution: szeidler at Ramsalt Lab commentedI 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.
Comment #20
hkirsman CreditAttribution: hkirsman commentedI don't have any cache errors with 2.0
Comment #22
thorandre CreditAttribution: thorandre at Frontkom commentedComment #23
thorandre CreditAttribution: thorandre at Frontkom commentedComment #25
rudam CreditAttribution: rudam commentedit 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.
Comment #26
szeidler CreditAttribution: szeidler at Ramsalt Lab commentedMay 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.
Comment #27
rudam CreditAttribution: rudam commentedsure!