We experienced an issue where views embedded via viewfield would occasionally show up empty until caches were cleared. On further investigation we discovered we could replicate this be adding a query string to the page request that passes and invalid value for one of the exposed filters, e.g:

/news : works - displays all news articles
/news?field_release_date_value[max]=invalid_value : displays no results and a validation message
/news : displays no results
Clear caches then \news : works - displays all news articles

Support from Acquia helps fund testing for Drupal Acquia logo

Comments

PQ created an issue. See original summary.

PQ’s picture

Patch attached

jerdavis’s picture

Does the view referenced in the field use AJAX for submission? What are your cache settings on the view itself?

Looking at my local, each view in the $elements array has it's own #cache key under #content. That #cache on mine includes url.query_args in the contexts array, as well as others. I haven't attempted to fully reproduce your example yet, but wanted to better understand your local configuration.

PQ’s picture

Thanks for looking into this @jerdavis,

Looking at a couple of the views that I know were affected, in both cases "Use AJAX" was set to "Yes" and "Caching" to "Tag based".

I did notice that although the individual elements had the url.query_args context in $elements[$delta]['#content']['#cache'], debugging via xDebug it seemed that the cache information added at that level was not bubbling up to the entity cache or page cache but cache information added via $elements['#cache'] was.

Basically, the code that calls ViewfieldFormatterDefault::viewElements() is ultimately called from these lines in Drupal\Core\Entity\Entity\EntityViewDisplay::buildMultiple():

          $build_list[$id][$name] = $field_access->isAllowed() ? $formatter->view($items, $view_langcode) : [];
          // Apply the field access cacheability metadata to the render array.
          $this->renderer->addCacheableDependency($build_list[$id][$name], $field_access);

What is returned from $formatter->view($items, $view_langcode) appears to contain no information about the #cache array of each field value so nothing useful is getting passed through to $this->renderer->addCacheableDependency().

PQ’s picture

Maybe we should merge each field value instance's cache tags and cache contexts (and max age?) into the field level cache array.

jerdavis’s picture

I'm comparing this to what's going on in Entity Reference to see how the cache data is being bubbled up.

jerdavis’s picture

Do you have Dynamic Page Cache enabled? What are your site's general cache settings? I'm having a hard time reproducing the basic behavior you descrived.

PQ’s picture

Both Internal Dynamic Page Cache and Internal Page Cache are enabled, Browser and proxy cache maximum age is set to one month. Not sure if it's a factor but the viewfield is attached to a paragraph type and the paragraph is in a paragraph field on a node.

I've looked though the theme layer and custom modules to see if we've done anything out of the ordinary in respect to the rendering of the node, paragraph, field or view and haven't found anything.

jerdavis’s picture

Do you have any other cache modules installed? I'll try testing with the viewfield on a paragraph and see if I can reproduce the issue.

  • jerdavis committed aef60a6 on 8.x-3.x
    Issue #3078940 by PQ, jerdavis: Results of embedded views with exposed...
jerdavis’s picture

Status: Active » Fixed
FileSize
0 bytes

Alright. I was able to reproduce this once I had paragraphs installed. I also needed to set a URL alias on the parent node. Part of what seemed to be happening here was likely connected to the updates to prevent Viewfield from rendering if the view results were empty. To negate the problem I instantiated a CacheableMetaData class, then merged any $view->element's #cache data into that class. After iterating over any views in the field it's then applied to $elements before returning.

Patch attached, merged into 8.x-3.x.

jerdavis’s picture

Looks like my patch creation failed! Here's the diff https://git.drupalcode.org/project/viewfield/commit/aef60a6

PQ’s picture

Good work, thanks for that. Odd that the issue only appears when there's an alias! I was trying to replicate it on a vanilla install today but failed, probably because of I didn't set an alias.

Status: Fixed » Closed (fixed)

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