Improve Views Caching and Organization

We are currently being pretty inefficient with how our Views are cached. We need to look at all of the Views that have caching enabled and ensure we are caching to the level we would like. See comments for more information.

I had another ticket for improving our Views organization. Since these go hand-in-hand I figure they should be put together.

----- original description ----- Views that use tag based caching (aka likely all of them) fail to invalidate when new content is added to them. The end result is that new content doesn't appear on cached Views unless they are otherwise invalidated or cache is rebuilt manually.

To replicate the behavior:

1. Go to an Events view
2. Clone one of the events (ensure it's published so it will appear on the view)
3. Observe that for anonymous users, the event doesn't appear
4. Additionally, the load more will show duplicates because later pages have been invalidated correctly

We need to determine the cause of this issue and find a solution. As a temporary measure, manually rebuilding cache when this behavior pops up will resolve. We don't want to rely on this. Comments:

• In my research on this issue, I found an issue on the Pantheon Advanced Page Cache (PAPC) module related to this: (https://www.drupal.org/project/pantheon_advanced_page_cache/issues/2944229)

This suggests the issue was addressed in the 1.2 release of the module. Since we are far past that, there is more to the story.

On the README.md for PAPC, they suggest that for sites where PAPC was installed prior to 1.2 you should reinstall the module or run a terminus command to enable the new setting.

https://git.drupalcode.org/project/pantheon_advanced_page_cache#changing-listing-tags

I'll give this a shot. We've adopted the module at 1.0 and I'd be surprised if it was ever uninstalled or if this was ever addressed. If it works, we can just run a drush command on all our sites to make the change.

(Michael Lee - Sep 18, 2024)

• I still have yet to test but I can confirm that the following config is set on our live sites.

# pantheon_advanced_page_cache.settings.yml
override_list_tags: true

We want override_list_tags: false (Michael Lee - Sep 18, 2024)

• Confirmed that making this configuration change will now emit the node_list tag instead of the PAPC overriding the tag with node_emit_list

That's the good news. The bad news is that node_list is a very generic tag and corresponds to ALL nodes. That means if the Events view is cached and someone adds/updates/deletes a Basic page, the node_list tag will be invalidated and the Events view will be recached. This could lead to a bunch of unnecessary cache invalidation.

PAPC is attempting to protect against this by adding this override. However, I think it ultimately just confuses users because they are expecting new content to show up when they've added it.

We should look into a more elegant solution here. The Views Custom Cache Tags module allows for setting custom tags to more intelligently invalidate views caches.

It should also be noted that the People Directory page has the user_list tag. This tag works in a similar way, if ANY user is added/updated/deleted, it will invalidate the People Directory page cache. We definitely want to improve logic here. As a result, we should take a close look at all of our views using caching to ensure they have the best solution that works for them. (Michael Lee - Sep 18, 2024)

• Stage 1 of this will be to update our "big views"

People

• Cache should invalidate when a non-blocked user with the Unit Faculty/Staff role is Created/Updated/Deleted
• Any other User updates should not invalidate the directory Cache
• If a non-blocked user is blocked and was on the directory, this should invalidate cache

News

• Cache should invalidate when a published news story is Created/Updated/Deleted
• An unpublished news story should not invalidate cache
• If a published story is unpublished, this should invalidate cache
• Cache should not be invalidated if any other node type is Created/Updated/Deleted

Events

• Cache should invalidate when a published event is Created/Updated/Deleted
• Upcoming Events and Past Events should invalidate separate caches relevant to the views they will appear on
• If a published event is unpublished, it should invalidate cache
• Cache should not be invalidated if any other node type is Created/Updated/Deleted

This will require the following individual pushes:

1. Code Push - Add Views Custom Cache Tag
2. Config Push - Install Views Custom Cache Tag
3. Config Push - Update Views to use custom cache tags
4. Code Push - Add custom module for custom cache tag invalidation
5. Config Push - Install Custom Module

We can verify that invalidation is working as intended by using this command and verifying that cache age has updated:

curl -IH "Pantheon-Debug:1" https://example.osu.edu (Michael Lee - Sep 24, 2024)

assigned to @canini.16 and unassigned @lee.5151

assigned to @lee.5151