Make WordPress Core

Opened 2 years ago

Closed 2 years ago

Last modified 2 years ago

#55239 closed defect (bug) (fixed)

Filter hook wp_sitemaps_taxonomies_entry passes Term ID not Object

Reported by: ravanh's profile RavanH Owned by: peterwilsoncc's profile peterwilsoncc
Milestone: 6.0 Priority: normal
Severity: minor Version: 5.9.1
Component: Sitemaps Keywords: has-patch needs-refresh
Focuses: docs Cc:


The filter hook wp_sitemaps_taxonomies_entry in wp-includes/sitemaps/providers/class-wp-sitemaps-taxonomies.php line 125 $term parameter is announced as being a WP_Term object but it is actually the term ID. This is caused by the default query argument fields=ids.

I worked around it by adding the filter:

add_filter( 'wp_sitemaps_taxonomies_query_args', function($args) { $args['fields'] = 'all'; return $args; } );

To fix this, I'd suggest either forcing the fields argument to "all" by adding

$args['fields'] = 'all';

before the WP_Term_Query on line 102 or changing the filter hook @param WP_Term $term Term object. description to reflect that $term can be different things depening on what is passed into the term query fields argument.

My preference would be the first suggestion, as that would generate the most predictable behavior and most usefull data passed through the filter. But then again, it might break plugins that are currently using the filter and expecting an ID...

Change History (7)

This ticket was mentioned in PR #2348 on WordPress/wordpress-develop by RavanH.

2 years ago

  • Keywords has-patch added

Force fields=all for the WP_Term_Query to make sure the wp_sitemaps_taxonomies_entry filter passes a WP_Term instead of the (unexpected) term ID.

Trac ticket:

swissspidy commented on PR #2348:

2 years ago

Just changing the query & type would be a backward compatibility break for everyone currently expecting $term to be an integer (despite the wrong docblock).

We should fix the wp_sitemaps_taxonomies_entry filter & docblock instead to actually pass the term ID because that's the current behavior. If we wanna pass the full term object we can add it as the fourth argument.

Like so:


  • Filters the sitemap entry for an individual term. *
  • @since 5.5.0
  • @since 6.0.0 Added fourth argument for the term object. *
  • @param array $sitemap_entry Sitemap entry for the term.
  • @param int $term_id Term ID.
  • @param string $taxonomy Taxonomy name.
  • @param WP_Term $term Term object. */

$sitemap_entry = apply_filters( 'wp_sitemaps_taxonomies_entry', $sitemap_entry, $term->term_id, $taxonomy, $term );

#3 @audrasjb
2 years ago

  • Focuses docs added
  • Keywords needs-refresh added
  • Milestone changed from Awaiting Review to 6.0

Moving for 6.0 consideration.

RavanH commented on PR #2348:

2 years ago

@swissspidy that would actually break my own implementation because I worked around it by adding this filter:
add_filter( 'wp_sitemaps_taxonomies_query_args', function($args) { $args['fields'] = 'all'; return $args; } );
with result that $term does pass the WP_Term object...

Still, you're probably right to consider it more likely to break things for others when changing the default behaviour. I've added your suggestion to the PR :)

#5 @RavanH
2 years ago

During testing, I just noticed that setting $args['fields'] = 'all' (back to its original intended value?) reduces the number of DB queries by a huge number on large taxonomy term sitemaps. Just as an added bonus :)

#6 @peterwilsoncc
2 years ago

  • Owner set to peterwilsoncc
  • Resolution set to fixed
  • Status changed from new to closed

In 52834:

Sitemaps: Pass term object to wp_sitemaps_taxonomies_entry filter.

Add a forth parameter to the wp_sitemaps_taxonomies_entry filter to pass the entire WP_Term object.

Correct the documentation for the second parameter of the wp_sitemaps_taxonomies_entry filter to indicate it is a term ID rather than term object.

Props RavanH, swissspidy, audrasjb.
Fixes #55239.

peterwilsoncc commented on PR #2348:

2 years ago

Committed in dcb118ef8f2ba1405f18bd52e431963fe30f3f57 (canonically

Note: See TracTickets for help on using tickets.