Make WordPress Core

Opened 6 years ago

Closed 5 years ago

#42361 closed enhancement (wontfix)

get_term returns NULL before filters

Reported by: socki03's profile socki03 Owned by:
Milestone: Priority: normal
Severity: minor Version: 4.7
Component: Taxonomy Keywords: has-patch reporter-feedback
Focuses: Cc:


So, this might be a super specific issue, but we utilize a plugin called CPT-onomies, which modifies CPTs to be also utilized as taxonomies, which means it manipulates the system in a few ways, but, for the most part it's been working great!

Ever since the taxonomy changes that came about somewhere between 4.5 - 4.7, error log files have been sort of exploding due to object term caches being full of NULL values. I believe I've come up with a fix to that solution outside of core, but I have come across an issue with the function get_term.

This chunk of code is run around lines 746-750:

	if ( is_wp_error( $_term ) ) {
		return $_term;
	} elseif ( ! $_term ) {
		return null;

before any filters are run on $_term, mainly, on line 761:

    $_term = apply_filters( 'get_term', $_term, $taxonomy );

I know I might be a bit out of my depth, but is there a reason that NULL is returned if the $_term is false before the filters are run?

I understand the return if a WP_Error is encountered, but if there is a different pairing that is needed outside the what the core interprets as a Term/Taxonomy relationship, could that if false/return null be run after the filters?

Thanks for bearing with me through this!

Attachments (1)

42361.diff (753 bytes) - added by socki03 6 years ago.
Move if $_term is false to after the filters are run.

Download all attachments as: .zip

Change History (6)

6 years ago

Move if $_term is false to after the filters are run.

#1 @socki03
6 years ago

  • Keywords has-patch needs-testing added
  • Severity changed from normal to minor

I realized I left out that this was happening in taxonomy.php, but I believe the diff I added should provide the necessary change. It keeps the if ( ! $_term ) but move it to after the two filters are run, so as to leave the possibility of hooking into the system and not returning a null value. Also added a line of notation for why its happening.

This ticket was mentioned in Slack in #core by socki03. View the logs.

6 years ago

#3 @welcher
6 years ago

  • Keywords reporter-feedback added; needs-testing removed

@socki03 thanks for the ticket and the patch!

My first thought is that the function returns before running the filters so as to not pass data to any number of filters being added.

I would also ask that you can confirm that this issue persists even without the plugin installed. There is not much core can do if the plugin in question is the root cause.

#4 @boonebgorges
6 years ago

Hi @socki03 - To expand a bit on the first point made above by @welcher, the change you've proposed would mean that the get_term and get_{$taxonomy} filters could in some cases receive an empty value instead of a term object or an integer (as the documentation states). This is likely to cause PHP notices in large numbers of plugins, and potentially introduce more serious issues, at the same time that it fixes the notices in the plugin you've referenced.

Out of curiosity, how does this change fix an error in cpt-onomies? Looking briefly at the code, I don't see at a glance how the change would make a difference. The plugin doesn't appear to use either of these filters.

#5 @boonebgorges
5 years ago

  • Milestone Awaiting Review deleted
  • Resolution set to wontfix
  • Status changed from new to closed

Closing based on the discussion above. This is a case where the PHP notices are demonstrating a problem with the filter callbacks, which the plugin developer should address.

Note: See TracTickets for help on using tickets.