"Search Categories" does not list/search sub-/childcategories, Tree is broken in "Edit Post"

[lloydbudd]

Categories Search does not search children categories

Env: 2.8-bleeding r10204

Repro: Always

STEPS

1. Create category 'Cities'
2. Create category 'Victoria' with parent category 'Cities'
3. Search categories for 'Victoria'

ACTUAL RESULTS
No matching results are found.

EXPECTED RESULTS
The category Victoria is listed as a result.

ADDITIONAL DETAILS

I think category search was added in WP 2.5, I confirmed that it and 2.7 exhibit this problem.

[minusonebit]

See also #8955 (closed as duplicate of this).

I have confirmed this behavior in the most current stable release (2.7).

[minusonebit]

See also #8619. Possible fix here?

[suit]

category overview

[suit]

categories (edit post)

[suit]

Also if no search is active, the category listing is broken (see categories.png)

Subcategory Mac OS is present in the dropdown, but not in the listing. If "Mac OS" is moved to another category, the category "Linux" gets lost.

As you can see in categories2.png, the category listing is also broken in the edit screen

If no category is attached to the post, the tree works fine. but once if a category is selected, the tree gets messed up (Nintendo Wii and Nintendo DS should be subcategories of "Spiele")).

I've tested this with a new installed WP2.7 without any plugins and default theme (just a few posts for testing).

[suit]

the tree-broken-problem also described here: #8613

[mrmist]

Everything should have a milestone.

[pp19dd]

I believe this is not a search problem, but, a display bug. For example, if you comment these two lines (64, 65) out of 2.7.1's /wp-admin/includes/template.php :

		if ( $category->parent != $parent )
			continue;

Then the search results appear as they should (well, almost- the display is out of whack and pagination appears to be always out of touch).

I think the problem comes from the way the display routine is done, or specifically how it tries to reconstruct the search results visually against the entire category list, and then tie that with the _get_term_hierarchy('category') output.

[Denis-de-Bernardy]

Confirming it's a display bug. Two potential fixes:

• We list all parents for every matched category
• We ignore the hierarchy on searches

Assuming we list all parents for every matched category, we'll fix #8613 as well.

[Denis-de-Bernardy]

err, nevermind on the #8613, wrong ticket.

[Denis-de-Bernardy]

patch removes the wacky parent check for categories, so that the hierarchy is ignored in searches.

[Denis-de-Bernardy]

I considered listing all of the parents, but it seemed messy from a performance standpoint. Also considered changing get_terms() to return the parents directly in searches, but it felt wrong.

[ryan]

(In [11123]) Include subcats in search results. Props Denis-de-Bernardy. fixes #8632

[ryan]

Good enough for now. Maybe MPTT will help, if and when we switch to that.

[pp19dd]

Pagination issue, after the patch.

[pp19dd]

The previously submitted patch works as a pretty good bandaid; however, as you can see, the pagination is still slightly out of sync with reality. The query pagination behaves like it should, when applicable - meaning that the actual query and consequent results are realistic. However, the display issue still persists. In the screenshot I uploaded, 21 pages are offered for 1 search result.

[ryan]

We get to pick which bug we like least. At the moment there is no fix for everything.

[ryan]

"PHP Notice: Undefined variable: my_parent in /Applications/MAMP/htdocs/trunk/wp-admin/includes/template.php on line 70"

[pp19dd]

First of all, I'm a pragmatist and I agree with you that bugs get picked one at a time depending on their severity.

Replying to ryan:

"PHP Notice: Undefined variable: my_parent in /Applications/MAMP/htdocs/trunk/wp-admin/includes/template.php on line 70"

Sounds like you have strict error reporting on. That variable is undeclared prior to looping. I think inserting a $my_parent = true; prior to that while statement will take care of the issue; however, these are still bandaids. That particular coding style is repeated in several places throughout that file.

On a bigger scale, I think that this routine should be as primitive as possible and that the actual display, pagination and filtration should take place through AJAX. In terms of code efficiency - as it is, *all* the categories/subcategories are already queried prior to displaying, regardless of search return. Something as simple as dojo's Dijit.FilteringSelect could provide the functionality in one fell swoop.

However, that's overtly ambitious. It seems like this pagination question (and the undeclared variables) should be a larger philosophical issue of how to make searches and search options consistent. For example, the public-facing site search ignores subcategories as a listing, etc. Perhaps categories, content items, and others should have a "searchable?" checkbox and maybe a priority weight.

I'd reopen this bug, but, the patch seems 99% effective to me. As it is, the WP backend is being redesigned and who knows which direction it will follow. Think we should be aware of this limitation but keep the bug closed.

[Denis-de-Bernardy]

I'll get the pagination issue fixed. It's actually related to something else -- the count is based on the total number of cats rather than the returned number of cats.

[Denis-de-Bernardy]

patch for the notice is attached, and I'm pretty certain it'll fix a separate bug related to category trees as well (couldn't find it)

[Denis-de-Bernardy]

Pagination patch is also attached. it and the notice fix both need some testing.

The notice fix in particular, because it will actually make some code work, that didn't until now.

[ryan]

Related: #9661

[Denis-de-Bernardy]

ah, there it is. I knew I had read about this somewhere. :-)

[hailin]

this is fixed in #9661, which fixes the root cause and other issues of cat_rows.

[Denis-de-Bernardy]

Re-opening, as I'd rather let Ryan or another core dev close this one.

Your notice fix seems better (mine is a quick and dirty fix that is clearly marked as needs testing), but the pagination patch is definitely committable and might get forgotten if this gets closed as dup

[hailin]

oops, sorry, I missed your pagination patch.

[Denis-de-Bernardy]

Replying to hailin:

oops, sorry, I missed your pagination patch.

hehe. part of the issue I had with the notice fix is that I wasn't entirely certain of what should be testing, so I had mostly no idea of the bugs it was introducing -- but you certainly seem to understand that part.

[ryan]

(In [11139]) cat_row fixes. Props hailin. fixes #9661 see #8632

[Denis-de-Bernardy]

@Ryan: There is one patch left (pagination) and I believe we're good to go on this one.

[ryan]

(In [11140]) Fix category search pagination. Fix caching of empty term results. Props Denis-de-Bernardy. fixes #8632

[ryan]

Fixed caching of empty get_terms() results. That way our extra call to get_categories() during searches is always cached for when we call it again from cat_rows().