WordPress.org

Make WordPress Core

Opened 7 years ago

Closed 21 months ago

#8214 closed enhancement (fixed)

get_terms should support term descriptions

Reported by: AaronCampbell Owned by: wonderboymusic
Milestone: 3.7 Priority: normal
Severity: normal Version:
Component: Taxonomy Keywords: has-patch
Focuses: Cc:

Description

Right now you can't use get_terms to get terms based on description. I think it should treat description just like name, so I added a description__like argument that works just like the name__like argument. In my case, I wanted only terms that had a description, so I called it like this:

$args = array('description__like' => '_');
get_terms('post_tag', $args);

Attachments (5)

8214.001.diff (4.6 KB) - added by AaronCampbell 7 years ago.
Adds descriptionlike arg to get_terms
8214.002.diff (1.5 KB) - added by aaroncampbell 4 years ago.
8214.diff (1.5 KB) - added by aaroncampbell 4 years ago.
8214.2.diff (1.7 KB) - added by wonderboymusic 22 months ago.
8214.3.diff (4.0 KB) - added by wonderboymusic 21 months ago.

Download all attachments as: .zip

Change History (14)

@AaronCampbell7 years ago

Adds descriptionlike arg to get_terms

comment:1 follow-up: @filosofo7 years ago

Wouldn't it be more useful if the searched-for term could be matched anywhere in the description? The way you have it, whatever description__like is set to would have to appear at the beginning of the description.

Maybe call it instead search__description have it be like this:

$where .= " AND tt.description LIKE '%{$search__description}%'";

comment:2 in reply to: ↑ 1 @Denis-de-Bernardy6 years ago

Replying to filosofo:

Wouldn't it be more useful if the searched-for term could be matched anywhere in the description? The way you have it, whatever description__like is set to would have to appear at the beginning of the description.

it does. from a performance standpoint, though, if this gets heavily used and an index is used on the description field, it won't be used in the query unless it's anchored to the beginning of the string.

comment:3 @Denis-de-Bernardy6 years ago

  • Keywords needs-patch added; has-patch needs-testing removed

comment:4 @janeforshort6 years ago

  • Milestone changed from 2.8 to Future Release

Punting due to time constraints. Will reconsider in future dev cycle.

comment:5 @kevinB5 years ago

  • Cc kevinB added

@aaroncampbell4 years ago

comment:6 @aaroncampbell4 years ago

  • Cc aaroncampbell added
  • Keywords has-patch 2nd-opinion added; needs-patch removed

I just refreshed the patch. It still matches only the beginning of the description just like name__like only matches the beginning of the name. I know it's somewhat limiting but performance-wise it seems better. Maybe we should also consider adding tt.description to the search? Something like:

if ( !empty($search) ) {
	$search = like_escape($search);
	$where .= " AND (t.name LIKE '%$search%' OR tt.description LIKE '%$search%')";
}

@aaroncampbell4 years ago

comment:7 @aaroncampbell4 years ago

The latest patch (8214.diff) is just refreshed for trunk. It still makes description__like work JUST like name__like in get_terms().

@wonderboymusic22 months ago

comment:8 @wonderboymusic22 months ago

  • Keywords 2nd-opinion removed
  • Milestone changed from Future Release to 3.7

Refreshed against trunk, was blowing up. None of our wildcard queries are optimal

@wonderboymusic21 months ago

comment:9 @wonderboymusic21 months ago

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

In 25241:

Introduce description__like arg to get_terms(). Make description__like and name__like perform LIKEs with a wildcard on both sides of passed string. Previously, strings had to match the beginning of the name, so searching for burrito in This is a burrito would fail. Adds unit tests.

Props aaroncampbell for the original patch, 5 years ago.
Fixes #8214.

Note: See TracTickets for help on using tickets.