I have a node type called page which references a node type called slider. I am using the Drupal 8 rest module to make updates to content.

I make a PATCH request to update the slider content and it says the content had been updated. When I view the slider content I can see the updated version all good but when I view the page (which renders the reference entity) it is still showing the older revision of the slider.

When I update the page by saving it to sending a PATCH to update the page then it shows the most recent version.

Is there a way to update a entity reference field (slider in this case) and also have the parent (page) also auto update with the changes?

  • This is not a REST issue, invalidating takes place on the entity level. Looks more like an issue with viewing the content, that the cache tags of the child entity are missing in the rendered parent. – 4k4 Feb 3 '18 at 18:45
  • I don't think it's a REST issue either. I think the issue is with entity references. When a child node gets updated through REST the parent still references the previous version of it. So when we view the parent it shows the older revision. – harnamc Feb 3 '18 at 19:38
  • I think an issue with revisions is unlikely too, if this is a standard reference field, which doesn't save revisions. @Harnamc, can you add how you render the child entities in the page? – 4k4 Feb 4 '18 at 10:51
  • to test all ideas, what happens when you make the patch request then run drush cr or (clear the drupal cache), does it still show the older version ? if so then you may need to work in the good old fastion \Drupal::service('page_cache_kill_switch')->trigger(); – taggartJ Feb 5 '18 at 5:41

When the referenced child node is updated in the database this triggers automatically a cache invalidation.

In this case there are three theming levels, page, parent node and child node. They all need to be invalidated when an entity involved gets updated.

But this only works when they are tagged properly. You only need to have the children tagged, because tags bubble up to the parent.

For debugging check the response header X-Drupal-Cache-Tags. To enable this header copy sites/default/default.services.yml to services.ymland set:

  # Cacheability debugging:
  # Responses with cacheability metadata (CacheableResponseInterface instances)
  # get X-Drupal-Cache-Tags and X-Drupal-Cache-Contexts headers.
  # For more information about debugging cacheable responses, see
  # https://www.drupal.org/developing/api/8/response/cacheable-response-interface
  # Not recommended in production environments
  # @default false
  http.response.debug_cacheability_headers: true

Now you can check the response headers in the browser debugging tools and see which cache tags are missing in the page.

  • Do we need to invalidate the cache after the PATCH request or before? Also how do you invalidate the cache for the child node? – harnamc Feb 15 '18 at 19:26
  • A patch request is the same as an edit in UI, it resaves the entity and this invalidates all cached render items tagged with the entity id, see api.drupal.org/api/drupal/… and api.drupal.org/api/drupal/… – 4k4 Feb 15 '18 at 19:59

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.