Make Patternkit Pattern Entity Cache Invalidation Configurable

Created on 20 August 2024, 6 months ago

Problem/Motivation

Every Patternkit block includes cache tags for both the specific Patternkit Pattern entity and the pattern's asset ID, like the following:

  • patternkit_pattern:<entity_id>
    • Example: patternkit_pattern:1
  • pattern:<asset_id>
    • Example: pattern:@patternkit/atoms/example/src/example

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 very large 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 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 if desired. 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. To account for this diversity, this behavior should be configurable.

Steps to reproduce

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.

  1. Install a site locally with the following modules enabled:
    • Patternkit
    • Patternkit Example
    • Layout Builder
  2. Enable cache header output
  3. Configure the Basic Page content type to use layout builder with per-page overrides enabled
  4. Configure the default layout for Basic Page and add an instance of "[Patternkit] Example"
  5. Create 3 new Nodes of the Basic Page content type: Page 1, Page 2, and Page 3
  6. Edit the layout for Page 3, override the layout saving a change to the content of the example pattern block

This is the default behavior and should represent what happens before changes in this issue as well as afterward with the default configuration in use. 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.

  1. 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
    1. Edit the file at modules/patternkit_example/lib/patternkit/src/atoms/example/src/example.twig in the Patternkit module directory
    2. Add some visible markup, such as <strong>UPDATED</strong>, into the template so it will be clearly visible when the new template is used
    3. Clear the Patternkit cache to discover the update: drush pkcc
    4. As an administrator, edit the layout for Page 3, edit the example block, and confirm the button to "Update pattern" is available at the top of the pattern form
  • As an anonymous user, view all three pages confirming a successful cache response on each
  • As an administrator, edit the layout for Page 3, 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".
  • As an anonymous user, view all three pages expecting to see a cache miss for each
  • As an anonymous user, view Page 1 and Page 2 expecting to see the original markup for each example block not including your manual changes
  • As an anonymous user, view all three pages confirming a successful cache response on each
  • As an administrator, edit the default layout for the Basic Page content type, 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".
  • As an anonymous user, view all three pages expecting to see a cache miss for each
  • Instructions to come.

    Proposed resolution

    • Add a configuration option to control whether these cache tags should be invalidated
    • Default this configuration option to match the current behavior

    Remaining tasks

    User interface changes

    API changes

    Data model changes

    Feature request
    Status

    Active

    Version

    9.1

    Component

    Module Core

    Created by

    🇺🇸United States slucero Arkansas

    Live updates comments and jobs are added and updated live.
    Sign in to follow issues

    Merge Requests

    Comments & Activities

    • Issue created by @slucero
    • 🇺🇸United States slucero Arkansas
    • 🇺🇸United States slucero Arkansas

      slucero changed the visibility of the branch 3469294-make-patternkit-pattern to hidden.

    • 🇺🇸United States slucero Arkansas
    • 🇺🇸United States slucero Arkansas

      After further testing, I've uncovered that the existing behavior (the currently proposed default) is not terribly helpful for several reasons:

      • When patterns are used in the default layout for a content type, the cache tags present for it don't matter as much for invalidation during pattern updates since the related updates to the default layout invalidate a tag like config:core.entity_view_display.node.page.default which is present on every page of that content type using that display mode regardless whether it is overridden. Due to this, every page of that content type will be invalidated regardless.
      • When used on overridden layouts, including the invalidation of the patternkit_pattern:<id> cache tags will result in all pages containing this pattern being invalidated when a single instance of the pattern is updated. These other blocks won't show any changes, however, since they still point to the prior revision of the pattern entity. The same behavior is true for pattern:<asset_id>cache tags which also get invalidated on update with this setting enabled.

      Based on these findings, I'll be updating the default value for this new setting to FALSE which will represent a change in behavior for most sites already. This change should be for the better, however, by bringing cache invalidation more in line with visible changes to the content.

    • Status changed to Needs review 5 months ago
    • 🇺🇸United States slucero Arkansas
    • 🇺🇸United States slucero Arkansas
    • 🇮🇳India minsharm India

      Steps to test

      1. Install a site locally with the following modules enabled:
        • Patternkit
        • Patternkit Example
        • Layout Builder
      2. Enable cache header output
      3. Configure the Basic Page content type to use layout builder with per-page overrides enabled
      4. Configure the default layout for Basic Page and add an instance of "[Patternkit] Example"
      5. Create 2 new Nodes of the Basic Page content type: Page 1, and Page 2
      6. Edit the layout for Page 2, override the layout saving a change to the content of the example pattern block
      1. As an administrator, navigate to the Patternkit settings page at /admin/config/user-interface/patternkit, enable the checkbox for "Entity cache tag invalidation" under "Advanced settings", and click the "Save configuration" button
      2. 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
        1. Edit the file at modules/patternkit_example/lib/patternkit/src/atoms/example/src/example.twig in the Patternkit module directory
        2. Add some visible markup, such as <strong>UPDATED</strong>, into the template so it will be clearly visible when the new template is used
        3. Clear the Patternkit cache to discover the update: drush pkcc
        4. 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
      3. As an anonymous user, view both pages confirming a successful cache response on each
      4. Results : Both pages show the previous content (before template changes), indicating that the cache is serving old content due to a cache hit.

      5. 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".
      6. As an anonymous user, view both pages expecting to see a cache miss for each
      • Results:
      • Page 1: Shows a cache miss, displaying old content since Page 1 should not have been affected.
      • Page 2: Shows the updated content and cache miss, confirming that the cache for Page 2 was correctly invalidated and updated.
      1. Ensure all pattern instances are up to date by running drush pkbu
      2. Clear all caches with drush cr
      3. As an anonymous user, view each page twice ensuring the second view returns a cache hit for each
      4. Results: Both pages return cache hit on second visit.

      5. 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
        1. Edit the file at modules/patternkit_example/lib/patternkit/src/atoms/example/src/example.twig in the Patternkit module directory
        2. Add some visible markup, such as <strong>UPDATED AGAIN</strong>, into the template so it will be clearly visible when the new template is used
        3. Clear the Patternkit cache to discover the update: drush pkcc
        4. 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)
      6. As an anonymous user, view both pages confirming a successful cache response on each
      7. Results: Both pages return cache hit

      8. 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".
      9. As an anonymous user, view all both noting the page cache result
        • Expect to see a cache hit on Page 1 with the content of the block showing the previous edits
        • Expect to see a cache miss on Page 2 with the content of the block showing the latest edits
      • Results:
      • Page 1: Shows the previous content (old template) with previous edits, confirming a cache hit.
      • Page 2: Shows the latest content with new template changes, with cache miss
    • Status changed to RTBC 5 months ago
    • 🇺🇸United States slucero Arkansas
    • Pipeline finished with Skipped
      4 months ago
      #293607
      • slucero committed f4d9b274 on 9.1.x
        Issue #3469294 by slucero, minsharm: Make Patternkit Pattern Entity...
    • 🇺🇸United States slucero Arkansas

      Merged for inclusion in the 1.0 release.

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

    • Status changed to Fixed 14 days ago
    • First commit to issue fork.
    • 🇺🇸United States krisahil

      @slucero, I re-opened this issue, because the latest update hook did not save the config entity. I'm proposing a fix in this MR: https://git.drupalcode.org/project/patternkit/-/merge_requests/144

      Thank you.

    • 🇺🇸United States slucero Arkansas

      @krisahil, good catch and thank you for opening up the MR to address it already! That looks good to me. Let's go ahead and get it merged in and I'll cut a new 1.0.1 release so it's available for anyone who hasn't started the process to upgrade to 1.0 yet.

    • Pipeline finished with Skipped
      14 days ago
      #403081
    • 🇺🇸United States slucero Arkansas

      Merged for inclusion in the 9.1.1 bug fix release.

    Production build 0.71.5 2024