Updating Next.js entity types should clear caches using relevant cache tags
At the moment, updating Next.js entity types is not clearing any caches when configuration is updated. This means that if any of the entity pages are cached, the cached version of the page is still served even if the rendering of the entity should change based on the Next.js entity types configuration.
Steps for reproducing
- Enable dynamic page caching
- Generate new node using any content type and visit the node page
- Visit
/admin/config/services/next/entity-typesand configure the entity type to be rendered using Next.js - Visit the node page again and confirm that the page is still rendered by Drupal
- Clear all caches
- Confirm that now the page is rendered using the Next.js preview
Bug confirmed. Adding this to the current work I'm doing on preview (where we fixed a bug with the router cache rebuild: #217)
Thanks @lauriii
I've moved this to the 1.3.0 release since the work done in #217 might take a while and be probably added in the 2.0.0 release.
The fix here would be something like the following, correct?
Override \Drupal\Core\Config\Entity\ConfigEntityBase::invalidateTagsOnSave in \Drupal\next\Entity\NextEntityTypeConfig. Get the entity view builder for the target entity type and merge in \Drupal\Core\Entity\EntityViewBuilder::getCacheTags to the invalidated tags.
[$entity_type_id, ] = explode('.', $this->id(), 2);
Edit: that method isn't the greatest, since it calls \Drupal\Core\Cache\Cache::invalidateTags and doesn't collect tags. By default it collects cache tags from \Drupal\Core\Entity\EntityBase::getListCacheTagsToInvalidate. But overriding that and returning {ENTITY_TYPE_ID}_view doesn't seem right. And \Drupal\Core\Entity\EntityBase::getCacheTagsToInvalidate is only called on update.
Maybe an event subscriber listening for configuration events is better to handle insert and update.