Since updating to 2.0-beta6 from 2.0-beta4 my views loading on page load are very slow. There is a blank space where the view is suppose to be and when the view loads it is causing content reshuffling/flashing. Rolled back to beta4 and it's working as it should.

CommentFileSizeAuthor
#18 3380691-18.patch14.59 KBseanb
#16 3380691-16.patch6.94 KBseanb

Comments

danthorne created an issue. See original summary.

galactus86’s picture

I also had a similar issue with the view no longer loading. But no flashing on our end.

Note to downgrade we used composer require drupal/viewsreference:2.0.0-beta4

frankdesign’s picture

I am seeing the same issue. No flashing - the view simply doesn't load. Seems to be an issue with BigPipe as when the view doesn't load, there is an empty span in it's place with a class with a long name that includes bigpipe. It's also intermittent, which is a pain to try and find the source of the issue.

Downgrading to beta4 resolves the issue.

mikesimmons’s picture

.

rviner’s picture

Same happens for me. Downgrading fixes the issue.

seanb’s picture

In #2919092: Viewsreference embeds Views without cache, breaking Dynamic page cache we introduced a lazy builder to solve issue related to caching. This inserts a div which should be replaced with the view when the page is loaded. I am not sure why the view fails to load in some cases, would you be able to debug this? I'd be happy to commit a fix.

ricovandevin’s picture

I'm not sure about the "slow loading" part. But as for "no longer loading" and "big pipe" the following can be relevant. In #2919092: Viewsreference embeds Views without cache, breaking Dynamic page cache a lazy builder has been introduced to improve cacheability of pages with views references on it. This has landed in the 2.0.0-beta5 release. This means that from that release on indeed the output of the views reference field only contains a render placeholder.

We have had an issue with this in a project where we checked in templates whether the view actually had "real" content.

{% set rendered_content %}
  {{ content }}
{% endset %}
{% if rendered_content|striptags|trim %}
  {{ rendered_content|raw }}
{% endif %}

Now that the views reference field only returns a placeholder (which is an empty HTML tag) the template does not render anything this way. We have been able to solve this by making the check in the template a little but smarter.

{% set rendered_content %}
  {{ content }}
{% endset %}
{% if rendered_content|striptags|trim or 'drupal-render-placeholder' in rendered_content %}
  {{ rendered_content|raw }}
{% endif %}

I'm not sure if we should really call this a bug in the Views Reference Field. But I will leave this issue open because I'm not sure whether this is the actual issue others ran into.

yustintr’s picture

@seanb in my project we check the content like this content.field_YOUR_PARAGRAPH[0]['contents']['#view'].result, but when i debug its breaks on the ['contents'] part because the lazy_builder steps comes in front of it. Maybe this helps to fix the issue

I think the issue here is that the twig is loadend before the view has renderd and thats why there is no data

seanb’s picture

Ah yes, the problem with checking the view content is that this makes caching the field a lot harder. You can still execute and render the view yourself. Or we could have an option on the formatter (maybe even a second formatter), that makes the use of the lazybuilder optional and preserve the old way of rendering.

finex’s picture

Hi, I'm also experiencing this bug: with BigPipe enabled the view does not load. I've simply put a views reference field inside a paragraph without further customization on the template.

freed_paris’s picture

Similar issue when using beta6 version :

AssertionError : When a #lazy_builder callback is specified, no properties can exist; all properties must be generated by the #lazy_builder callback. You specified the following properties: #context. dans assert() (ligne 337 de htdocs/web/core/lib/Drupal/Core/Render/Renderer.php).

I downgraded to beta4 and it works again

Fred

randalv’s picture

Title: Latest version slow to load views. » Latest version slow to load views or doesn't load views at all.

I'm running into an issue with the beta5 and beta6 versions where an anonymous user will not see the view results. Logged in users do not get this issue.
The view itself is being rendered (the exposed form and so on is there), but the results never are.

I can't for the life of me figure out why. There are no console errors, and the #lazy_builder placeholder gets replaced properly as well.

I'm also feeling forced to revert to beta4 to restore the functionality. If I do find a cause/solution, I'll post it here.

jalpesh’s picture

I am also running into the same issue where no view data getting load after updating module. I have used views_get_current_view() to fetch current view.

Downgrading the module to composer require drupal/viewsreference:2.0.0-beta4 works fine.

scott_euser’s picture

Status: Active » Closed (duplicate)
Related issues: +#3304746: BigPipe cannot handle (GET) form redirects (EnforcedResponseException)

We have noticed if we apply the patch here BigPipe and GET requests start to play nice again: https://www.drupal.org/project/drupal/issues/3304746
Hopefully that is helpful for anyone else coming across this issue.

Would suggest we close this issue as the problem is in Core then and not here. Not quite sure the right 'closed' status here - I supposed its 'Closed (duplicate)' since the issue is raised in the core issue queue.

seanb’s picture

Title: Latest version slow to load views or doesn't load views at all. » Issue 2919092 breaks BC and causes issues for existing sites
Status: Closed (duplicate) » Needs work

I think #2919092: Viewsreference embeds Views without cache, breaking Dynamic page cache broke BC and a lot of custom code. For that reason the issue is probably valid. Renamed the title.
I'm going to revert the changes in #2919092: Viewsreference embeds Views without cache, breaking Dynamic page cache and introduce the lazy builder option as a new formatter for people that want/need it.

seanb’s picture

Status: Needs work » Needs review
StatusFileSize
new6.94 KB

Attached patch should work with the latest version. Could you please check if that fixes the issue?

kleve’s picture

Also having the same problem with nothing rendered when logged in and BigPipe enabled.

Patch from #16 adds a new layzy builder option to display the views. Tested with both display options. Nothing is rendered except the big-pipe-placeholder.

Also tested with the proposed patch in #14 https://www.drupal.org/project/drupal/issues/3304746. No change. Nothing is rendered except the big-pipe-placeholder.

Tested patch from #14 and #16. Nothing is rendered except the big-pipe-placeholder.

The solution for us was to simply downgrade the module
composer require drupal/viewsreference:2.0.0-beta4

seanb’s picture

StatusFileSize
new14.59 KB

Sorry about that, some changes were missing in my previous patch (forgot to git add before creating it). Could you try this one?

kleve’s picture

Tested patch from #18 with 2.0.0-beta6.

With the old display format viewsreference the views are displayed for both logged in/anonymous users.
If I switch to the new display format viewsreference (layzy builder) the views are displayed for anonymous but not for logged in users.

Not sure if this is good or bad news :) But it looks like the patch works for existing sites using the old display format.

seanb’s picture

Thank you for testing! This at least solves the issues for the existing formatter currently broken in the latest release (for some sites). We can continue the development and debugging of the lazy builder in new issues. If someone else could also check and RTBC this I will try to commit this asap and create a new release.

kthull’s picture

Status: Needs review » Reviewed & tested by the community

Also confirming #18 fixed our logged in user missing views

  • seanB authored 7e23834d on 8.x-2.x
    Issue #3380691 by seanB, danthorne, Kleve, ricovandevin, yustinTR,...
seanb’s picture

Status: Reviewed & tested by the community » Fixed

Thanks! Committed.

Status: Fixed » Closed (fixed)

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