Skip to content


Subversion checkout URL

You can clone with HTTPS or Subversion.

Download ZIP


Don't invalidate menu_cache on Page changes #1774

benliles opened this Issue · 11 comments

7 participants


The menu cache currently gets cleared when pages are changed or deleted by connecting to the pre_save and post_delete signals.

This is an expensive operation when a site is large and there are timeouts on the cache to handle flushing these changes in an appropriate amount of time.


By the way, just discovered that this is getting done in the method as well which means that it happens multiple times.


The current strategy is to have the cache-timeout as high as possible, as the building of the menu is rather expensive as you noted. Short of more fine-grained caching or a way to pre-fill the cache, I don't see us changing this strategy any time soon.


I saw that the menu cache is not refresh when you just disable a page to "show on menu" and when you just "edit" her.

@digi604 digi604 added this to the 3.0 milestone
@digi604 digi604 added the blocker label

@digi604 , @ojii : I would like to investigate this issue, do you have recommendation on the way to go?
Should we add a "clear cache" option in the toolbar ? add a setting to make this refresh on page change optional ?


the chache version needs to be increased if something 'relevant' happens.


@digi604 : define relevant ? :) Should we only "fix" the fact that the cache refresh is triggered multiple times?


on the page:

  • if a page moves that is in the menu
  • if in menu changes
  • if application_urls or application_namespace changes
  • if soft_root changes
  • if navigation_extenders changes
  • if limit_visibility_in_menu changes

on title:

  • if title or menu_title changes
  • if path changes

multiple cache clears surely should be avoided


ack - putting this on my todo list

@digi604 digi604 removed the blocker label

Hey all, just to provide some info to this. i recently added/updated, the page cache so that it uses a "Cache Versioning Strategy", so, this is about as inexpensive as it can get for cache invalidation, since everything, including the very keys we use for the cache, are stored in the cache itself.

Read here for more detail:

I recently looked into retrofitting the menu cache to use a similar strategy. Unfortunately, such a change will not be a trivial exercise since the current menu cache mechanism needs to perform queries to be able to find the correct keys to clear. This is because there are multiple "dimensions" that the cached menu can exist within [ menu × language × site × ? ]. The existing code uses the database to store the keys, but more importantly, to provide the query mechanism required to find the keys to invalidate.

Perhaps someone with more brains and/or more determination than I can figure out how to implement this querying capability with the cache versioning strategy, then, invalidating the menu cache will be tremendously more efficient to the point that performing hundreds of invalidations back-to-back will have virtually no performance impact, and thereby addressing @benliles’ requirements and will generally make the whole menu cache more performant.

@yakky yakky modified the milestone: 3.0.X, 3.0
@yakky yakky modified the milestone: 3.0.X, 3.0.6
@yakky yakky modified the milestone: 3.0.X, 3.X
@mkoistinen mkoistinen added the menus label
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Something went wrong with that request. Please try again.