Contrib.social

Introduce revision cache tags and invalidate them on revision save/delete

Open on Drupal.org →
Created on 17 May 2017, over 8 years ago
Updated 22 October 2024, about 1 year ago

Problem/Motivation

In #2878438-8: Update {content_revision_tracker} after the most recent (draft) revision is deleted → alexpott has noticed that we don't invalidate cache tags when deleting an entity revision. Currently we don't have any support for revision cache tags, but with the ongoing usage of forward/non-default revisions we need to introduce revision cache tags.

Proposed resolution

  • The revision cache tag "entity_type_id:rev:rev_id" has to be invalidated on revision delete.
  • The revision cache tag "entity_type_id:rev:rev_id" has to be invalidated when saving an existing entity revision without creating a new one.
  • When creating a new forward/non-default revision the cache tag "entity_type_id:latest_forward_revision" has to be invalidated in order to invalidate e.g. views that are cached based on a content from the lastest non-default revision.
  • Should we allow the EntityViewBuilder to cache the rendered output of a non-default revisions?

Remaining tasks

Remove the manual views cache invalidation introduced in the test from #2878438: Update {content_revision_tracker} after the most recent (draft) revision is deleted → .

User interface changes

API changes

Data model changes

📌 Task
Status

Active

Version

11.0 🔥

Component

entity system

Created by

🇩🇪Germany hchonov 🇪🇺🇩🇪🇧🇬

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

Merge Requests

Comments & Activities

Not all content is available!

It's likely this issue predates Contrib.social: some issue and comment data are missing.

  • First commit to issue fork.
  • Merge request !9910Invalidate entity tags on revision save/delete → (Open) created by mstrelan
  • Comment about 1 year ago →
    🇦🇺Australia mstrelan

    I agree with @berdir in #2. Have started an MR to do this when revisions are deleted.

    Should this be reclassified as a bug? Here are steps to reproduce, there is likely a simpler way to reproduce this though.

    1. Install Drupal with demo_umami profile
    2. Create a view showing content revisions, filtered by "is latest revision", sorted by "revision create time" desc
    3. Add the revision id and moderation state fields to the view
    4. Edit the node at the top of the view, create a new draft revision
    5. Load the view, take node of the revision id and moderation state of the page that was edited
    6. Delete the latest revision, repeat step 5, note it hasn't changed
    7. Clear cache and repeat step 5, note it has changed
  • Pipeline finished with Success
    about 1 year ago
    Total: 1665s
    #317659
contrib.social Blog FAQ Discussions
Production build 0.71.5 2024