>>> [!note] Migrated issue <!-- Drupal.org comment --> <!-- Migrated from issue #3469294. --> Reported by: [slucero](https://www.drupal.org/user/1612534) Related to !144 !126 >>> <h3 id="summary-problem-motivation">Problem/Motivation</h3> <p>Every Patternkit block includes cache tags for both the specific Patternkit Pattern entity and the pattern's asset ID, like the following:</p> <ul> <li> <code>patternkit_pattern:</code> <ul> <li>Example: <code>patternkit_pattern:1</code> </li> </ul> </li> <li> <code>pattern:</code> <ul> <li>Example: <code>pattern:@patternkit/atoms/example/src/example</code> </li> </ul> </li> </ul> <p>This is appropriate to identify the content being rendered and ensure content gets invalidated when related changes take place, but for sites with a lot of content and repetition of the same patterns throughout much of it, unexpected invalidation of a tag spanning a large portion of the site's pages could have a significant performance impact. With the behavior as of the Beta 10 release, both of these tags are invalidated whenever a pattern block is updated to the latest version. Due to the revisioning of the pattern schema and template content into the pattern entity, blocks referencing the specific pattern revision prior to the update the rendered output of these blocks will remain unaffected, but regardless of this, the containing pages will be invalidated due to the entity ID and asset name invalidations being triggered. When a site is using pattern blocks in default layouts, changes from updating the pattern should affect all other pages using the same default layout, and thus the invalidation of those containing pages would be relevant, but this is already accounted for by the display mode cache tag. Alternatively, if a site is primarily using pattern blocks in overridden layouts, updating the pattern for a single instance should not affect other pages and invalidation of them would be unnecessary and wasteful. Sites behind CDN or other caching solutions in front of Drupal may not be as concerned about this broad invalidation, so to account for this diversity, this behavior should be configurable.</p> <h4 id="summary-steps-reproduce">Steps to reproduce</h4> <p>Testing for this is best handled on a local environment since it involves tracking cache invalidations and forcing pattern updates which is easiest to accomplished by modifying files locally.</p> <h5 id="setup">Setup</h5> <ol> <li>Install a site locally with the following modules enabled: <ul> <li>Patternkit</li> <li>Patternkit Example</li> <li>Layout Builder</li> </ul> </li> <li> <a href="https://www.drupal.org/docs/develop/development-tools/disabling-and-debugging-caching#s-disable-twig-cache-manually-the-old-way">Enable cache header output</a> </li> <li>Configure the Basic Page content type to use layout builder with per-page overrides enabled</li> <li>Configure the default layout for Basic Page and add an instance of "[Patternkit] Example"</li> <li>Create 2 new Nodes of the Basic Page content type: Page 1, and Page 2</li> <li>Edit the layout for Page 2, override the layout saving a change to the content of the example pattern block</li> </ol> <h5 id="test-with-entity-tag-invalidation-enabled">Test with entity tag invalidation enabled</h5> <p>This is the behavior as of the Beta 10 release, but returning to this with the new changes in place will require disabling the new setting. For this scenario, we expect to see the caches for all pages containing blocks using the same pattern, whether overridden or in default layouts, invalidated when one block instance is updated. To do this, we'll need to view the site in one browser window as an anonymous user while logged into another window to make the administrative updates being tested.</p> <ol> <li>As an administrator, navigate to the Patternkit settings page at <code>/admin/config/user-interface/patternkit</code>, enable the checkbox for "Entity cache tag invalidation" under "Advanced settings", and click the "Save configuration" button </li> <li>In your local files, update the template file for the "[Patternkit] Example" pattern to trigger detection of a new update to the pattern being available <ol> <li>Edit the file at <code>modules/patternkit_example/lib/patternkit/src/atoms/example/src/example.twig</code> in the Patternkit module directory </li> <li>Add some visible markup, such as <code>&lt;strong&gt;UPDATED&lt;/strong&gt;</code>, into the template so it will be clearly visible when the new template is used </li> <li>Clear the Patternkit cache to discover the update: <code>drush pkcc</code> </li> <li>As an administrator, edit the layout for Page 2, edit the example block, and confirm the button to "Update pattern" is available at the top of the pattern form</li> </ol> </li> <li>As an anonymous user, view both pages confirming a successful cache response on each</li> <li>As an administrator, edit the layout for Page 2, edit the example block, click the "Update Pattern" button, and save the block. Expect to see the altered content from your template edits visible in the block preview and click "Save layout".</li> <li>As an anonymous user, view both pages expecting to see a cache miss for each</li> <li>As an anonymous user, view Page 1 expecting to see the original markup for the example block not including your manual changes</li> <li>As an anonymous user, view Page 2 expecting to see the altered content from your template edits in the block</li> </ol> <h5 id="test-without-entity-tag-invalidation">Test without entity tag invalidation</h5> <p>The following scenario will test the cache invalidation behavior with the newly exposed setting disabled. This should be the new default behavior after implementing the code changes for this issue and running database updates if the setting has not been manually changed beforehand. With this alteration, updating the pattern for a single block should not trigger invalidation of other pages containing the same pattern.</p> <ol> <li>Ensure all pattern instances are up to date by running <code>drush pkbu</code> </li> <li>Clear all caches with <code>drush cr</code> </li> <li>As an anonymous user, view each page twice ensuring the second view returns a cache hit for each</li> <li>In your local files, update the template file for the "[Patternkit] Example" pattern to trigger detection of a new update to the pattern being available <ol> <li>Edit the file at <code>modules/patternkit_example/lib/patternkit/src/atoms/example/src/example.twig</code> in the Patternkit module directory </li> <li>Add some visible markup, such as <code>&lt;strong&gt;UPDATED AGAIN&lt;/strong&gt;</code>, into the template so it will be clearly visible when the new template is used </li> <li>Clear the Patternkit cache to discover the update: <code>drush pkcc</code> </li> <li>As an administrator, edit the layout for Page 2, edit the example block, and confirm the button to "Update pattern" is available at the top of the pattern form (Do not click the button yet)</li> </ol> </li> <li>As an anonymous user, view both pages confirming a successful cache response on each</li> <li>As an administrator, edit the layout for Page 2, edit the example block, click the "Update Pattern" button, and save the block. Expect to see the altered content from your template edits visible in the block preview and click "Save layout".</li> <li>As an anonymous user, view all both noting the page cache result <ul> <li>Expect to see a cache hit on Page 1 with the content of the block showing the previous edits</li> <li>Expect to see a cache miss on Page 2 with the content of the block showing the latest edits</li> </ul> </li> </ol> <h3 id="summary-proposed-resolution">Proposed resolution</h3> <ul> <li>Add a configuration option to control whether these cache tags should be invalidated</li> <li>Default this configuration option to prevent widespread cache invalidation on pattern updates</li> </ul> <h3 id="summary-remaining-tasks">Remaining tasks</h3> <h3 id="summary-ui-changes">User interface changes</h3> <ul> <li>New "Advanced settings" section on the Patternkit settings page at <code>/admin/config/user-interface/patternkit</code> <ul> <li>New "Entity cache tag invalidation" setting</li> </ul> </li> </ul> <h3 id="summary-api-changes">API changes</h3> <ul> <li>New <code>entity_cache_tag_invalidation</code> configuration value in <code>patternkit.settings</code> </li> </ul> <h3 id="summary-data-model-changes">Data model changes</h3> <p>None</p>