WordPress.org

Make WordPress Core

Opened 4 years ago

Closed 21 months ago

Last modified 21 months ago

#16182 closed defect (bug) (duplicate)

object_term_cache is never cleared for custom post types with non-shared taxonomy

Reported by: prettyboymp Owned by:
Milestone: Priority: normal
Severity: major Version: 3.0
Component: General Keywords:
Focuses: Cc:

Description

wp_insert_post() calls clean_post_cache() after updating the post. However, when clean_object_term_cache() is called, it passes is hard coded to pass in the post_type of 'post'. So the object_term_cache is never cleared for any taxonomies that are part of the post object type's taxonomies.

Change History (13)

comment:1 @mikeschinkel4 years ago

  • Cc mikeschinkel@… added

comment:2 @prettyboymp4 years ago

Sorry for the complete typo on this:

wp_insert_post() calls clean_post_cache() after updating the post. However, when clean_object_term_cache() is called, it is hard coded to pass in the post_type of 'post'. So the object_term_cache is never cleared for any taxonomies that are part of the post object type's taxonomies.

comment:3 @scribu4 years ago

Related: #14485

comment:4 follow-up: @nacin4 years ago

Regression?

comment:5 in reply to: ↑ 4 @SergeyBiryukov4 years ago

Replying to nacin:

Regression?

No, it's the same in 3.0.

comment:6 @prettyboymp4 years ago

Adding steps to reproduce:

  1. Create a custom post type
  2. Create a custom taxonomy and register it to the custom post type, but not the normal post
  3. Setup persistent object caching
  4. Setup and call code that uses get_the_terms() on an instance of the custom post type for the custom taxonomy
  5. Update the selected terms for the custom post through the admin
  6. Call get_the_terms() a second time, the terms will be pulled from cache with the previous value.

comment:7 @prettyboymp4 years ago

The simple fix would be to update the wp_cache_delete() call within the clean_post_cache() function to be based off of the post_id's post type. Though this section should probably be re-factored to merge clean_post_cache() and clean_page_cache() into one function and calling the unique functionality through a 'clean_{$post_type}_cache' hook.

Due to the 3.1 time line, I think the simple fix should be implemented now and we should come back to the bigger re-factoring later.

comment:8 @mdawaffe4 years ago

  • Keywords needs-patch added

This bug is lame. Can you workaround with the clean_post_cache hook?

comment:9 @prettyboymp4 years ago

Just because there is a work around doesn't mean it isn't a bug. It has the potential to cause a lot of issue when cache is holding on to a different value than the DB is and for the taxonomies that are linked to 'posts' or 'pages' to act completely differently from any other taxonomy is a debugging nightmare.

comment:10 @nacin4 years ago

  • Version changed from 3.1 to 3.0

Not a regression, moving version.

comment:11 @c3mdigital21 months ago

  • Keywords close added; needs-patch removed
  • Resolution set to invalid
  • Status changed from new to closed

This was fixed in r20569 which passes the $post object to all cache cleaning functions.

comment:12 @ocean9021 months ago

  • Keywords close removed
  • Milestone Awaiting Review deleted
  • Resolution changed from invalid to duplicate

Duplicate of #20486.

comment:13 @mdawaffe21 months ago

Sorry, prettyboymp, I just saw your three year old reply :)

By "this bug is lame" I meant "This bug in annoying". I did not mean that the bug report was bad or that we shouldn't fix it. I suggested the workaround in case you were being hit by this bug and couldn't wait until it eventually got fixed in core.

Apologies for being unclear.

Note: See TracTickets for help on using tickets.