Updating Page#url_name should touch related Nodes for cache invalidation

[robinboening]

Is your feature request related to a problem? Please describe.

A menu cache is swept only when applying a direct change to the menu. In the case where a menu node is coupled with a Page, the node doesn't store the url but delegates to the Page, hence the node itself receives no update when the URL updates.

The reason why it currently doesn't lead to 404s is because the legacy page feature kicks in and redirects to the latest url. Anyhow, I believe the nodes should keep up to date with the page information.

Describe the solution you'd like

I think whenever a Page#url_name gets updated the corresponding menu nodes should be touched in order to invalidate the menu cache.

[tvdeyen]

Every time a page gets updated all related nodes get updated as well.

alchemy_cms/app/models/alchemy/page.rb

Line 147 in c998f08

after_update -> { nodes.update_all(updated_at: Time.current) }

Do you have an example where this does not work for you?

[robinboening]

Every time a page gets updated all related nodes get updated as well.

alchemy_cms/app/models/alchemy/page.rb

Line 147 in c998f08

after_update -> { nodes.update_all(updated_at: Time.current) }

Do you have an example where this does not work for you?

Wow, I completely missed that piece of code!

I've seen my menu not picking up url changes, but I'll check again later tonight when I am back at the computer.

[robinboening]

@tvdeyen I just ran some tests in a more debuggable environment (local dev) with caching activated.

tl;dr – I found the same behaviour as initially explained.

For my tests I am using the auto generated menu partials (_wrapper + _node), hence they contain <% cache menu do %> and <% cache node do %>.

1. As expected, the first request writes all the fragments. Without changing anything, the second request reads the fragment from the enclosing cache block. Great, so far.
2. I update the URL path of a page associated with one of the menu nodes (I made sure I am in the right language tree).
3. The third request reads the exact same fragment which was created by the first request.

[afdev82]

The main problem with the menu cache is that the root node is not updated / touched.
The update_all doesn't trigger any ActiveRecord callbacks, see here, so the ancestors of the node are not updated.
Anyway, the problem is similar to this. For that reason, the root node would not be touched anyway, not invalidating the wrapper view cache.
I just made some tests to confirm what I'm saying.

• activate the dev cache with ´bin/rails dev:cache´.
• load a page with a menu
• go to the admin menu section and move a node under another node or change the slug of a page related to a node
• reload the page

If we open the log and look for the lines starting with "Write fragment views/alchemy/menus/", we find them only on the first load, not in the second. We have only "Read fragment views/alchemy/menus/" on the second.
Also I looked at the updated_at in the database and the updated_at of the root_node is not updated, but only the node with the change and, only in case of move, also the ancestors.
I tested using the v6.0.0-rc3.

[tvdeyen]

The update_all doesn't trigger any ActiveRecord callbacks, see here, so the ancestors of the node are not updated.

@afdev82 ah, sure. Thanks for pointing that one out.

[tvdeyen]

Ha, TIL touch_all

[tvdeyen]

@robinboening could you please test #2226 ? I tested and it worked for me. Would appreciate if you could make some testing as well @afdev82

[afdev82]

I tested the branch and it works.

[tvdeyen]

@afdev82 thanks. @robinboening what do you think?