Every time a page view occurs, wordpress is sending a complex non-indexed query below. The exact same query is sent over and over and it seems that it is being passed through some "caching" code. But why doesn't the cache actually prevent re-executing the query over and over?

The query being caught, which is asked repeatedly on every page view, is:

# Query_time: 0 Lock_time: 0 Rows_sent: 320 Rows_examined: 1608
SELECT post_id, meta_key, meta_value FROM wp_postmeta WHERE post_id IN 
(2366,2363,4066,...etc, about 30 entries);

I noticed this using log-queries-not-using-indexes in mysql.

The pertinent call stack is:

  • wp_get_nav_menu_items(3) in nav-menu.php (around line 495) calls
  • get_posts in post.php (around line 1461) calls
  • WP-Query->query in query.php (around line 2941) calls
  • WP-Query->get_posts in query.php (around line 2767) calls
  • update_post_caches in post.php (around line 4454) calls
  • update_postmeta_cache in post.php (around line 4474) calls
  • update_meta_cache in meta.php (around 560)
  • which makes the nasty SELECT statement

The SELECT statement is basically getting all the info from wp_postmeta for menu items whose post_id there has term_taxonomy_id = 3 in wp_term_relationships.

In other words, it's getting some metadata corresponding to the menu bar.

But, why is the cache updated, and db re-queried, on every single page view? I have very little clue how the cache works (I'm just starting to read about it) and that's why I'm writing here. All I can say is that the "cache_results" is automatically turned on inside of the call to WP-Query->get_posts around line 1970. That's great, but why might the cache get refreshed on every single page view? If the cache is operating as I would normally expect a cache to operate, I don't get why it keeps making this query over and over.

How can I best fix the lack of effective caching? Or is this the expected behaviour?

(xref: http://wordpress.org/support/topic/core-code-caching-issue-w-nav )

  • This problem seems to be resolved in the trunk (as of Nov 17 2012).
    – daveagp
    Nov 18, 2012 at 4:37

1 Answer 1


The Codex page for the Object Cache class holds the answer to this:

By default, the object cache is non-persistent. This means that data stored in the cache resides in memory only and only for the duration of the request. Cached data will not be stored persistently across page loads unless you install a persistent caching plugin.

  • That's really good to know that I am not crazy. Can I ask your opinion on fixing it? The logical place seems to be in wp_get_nav_menu_items (around line 470 of nav-menu.php) and I can add 'cache_results' => false to $defaults. Of course, this involves editing the core code and I can't see any other way (I even checked the calling code which is in wp_nav_menu of nav-menu-template.php). Is this a reasonable fix? Could someone hosting their own code fix this? Should I report it as a bug? Thanks for your advice!
    – daveagp
    Nov 14, 2012 at 1:53
  • Let me say also that the fix I mentioned above definitely works, and it seems sensible to me... except perhaps if you're admin, why would you be caching the info related to a navigational menu?
    – daveagp
    Nov 14, 2012 at 1:59
  • off the top of my head, you could possibly add a filter to set update_post_term_cache without having to edit a core file, however, I question whether you're actually making things more efficient- you're just delaying the query and possibly making it slower by having to query for each piece of meta data individually later when WP tries to fetch it from cache and it's not there. meta data is used to store menu data and is needed on the front end.
    – Milo
    Nov 14, 2012 at 2:12
  • (1) I have switched from 'cache_results' => false to just use both of 'update_post_meta_cache' and ...term_cache to false which may be more specific? (2) As far as I (hopefully) understand, the posts are still queried in the same way (within lines 2633--2657 of query.php) and now simply not cached (line 2767). I don't see how this could be slower since the cached results were never re-accessed before being thrown away... keep in mind the whole reason wp_get_nav_menu_items is called is to generate the menu, so we don't need it afterwards... does that sound plausibly correct?
    – daveagp
    Nov 14, 2012 at 4:34
  • I suppose, but I don't see how not caching it in memory really speeds anything up. If you were to use a persistent object cache you'd definitely see a major speed increase by caching that data, so I'm not sure I understand the point of what you're trying to do.
    – Milo
    Nov 14, 2012 at 4:54

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.