[wp-trac] [WordPress Trac] #56577: Add short-circuit filter to `wp_setup_nav_menu_item`

WordPress Trac noreply at wordpress.org
Thu Sep 15 10:08:26 UTC 2022


#56577: Add short-circuit filter to `wp_setup_nav_menu_item`
-------------------------+-----------------------------
 Reporter:  david.binda  |      Owner:  (none)
     Type:  enhancement  |     Status:  new
 Priority:  normal       |  Milestone:  Awaiting Review
Component:  Menus        |    Version:
 Severity:  normal       |   Keywords:
  Focuses:  performance  |
-------------------------+-----------------------------
 While looking into a memory consumption of navigation menus on some blogs
 with huge menus, I have noticed that to decorate a nav menu item via
 `wp_setup_nav_menu_item` function generates a lot of data.

 To decorate a nav menu item of `post_type` type, for instance, requires
 [https://core.trac.wordpress.org/browser/trunk/src/wp-includes/nav-
 menu.php?rev=53508#L847 the original object to be fetched] in order to
 grab it's [https://core.trac.wordpress.org/browser/trunk/src/wp-includes
 /nav-menu.php?rev=53508#L849 permalink] and
 [https://core.trac.wordpress.org/browser/trunk/src/wp-includes/nav-
 menu.php?rev=53508#L852 title] only.

 However, in case there's a menu consisting of multiple posts and/or pages
 with large content, the whole original object is much larger than the data
 which are actually needed.

 IMHO, in case of a WordPress install with a persistent object cache
 backend, it would be beneficial to cache the fully decorated nav menu item
 (output of the `wp_setup_nav_menu_item`) in order to bring that from cache
 on subsequent requests instead of decorating the nav menu item over and
 over.

 On a site which I've been investigating, the difference in between
 original objects fetched from memcache in order to decorate the nav menu
 item vs. obtaining the already decorated and cached nav menu item was 300M
 vs. 3.19 (yes, the nav menu is huge, consisting of ~1000 items, mostly
 posts).

 However, I don't think that caching the decorated nav menu is something
 what core should do by default (eg.: it does not make sense w/o persistent
 object cache backend), so I wonder if it would make sense to add a short-
 circuit filter to the `wp_setup_nav_menu_item` function which would allow
 plugins to implement the caching layer.

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/56577>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform


More information about the wp-trac mailing list