#8632 closed defect (bug) (fixed)
"Search Categories" does not list/search sub-/childcategories, Tree is broken in "Edit Post"
Reported by: |
|
Owned by: |
|
---|---|---|---|
Milestone: | 2.8 | Priority: | normal |
Severity: | major | Version: | 2.7 |
Component: | Administration | Keywords: | has-patch needs-testing |
Focuses: | Cc: |
Description
Categories Search does not search children categories
Env: 2.8-bleeding r10204
Repro: Always
STEPS
- Create category 'Cities'
- Create category 'Victoria' with parent category 'Cities'
- 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.
Attachments (6)
Change History (43)
#1
@
16 years ago
- Keywords search catagory catagories added
- Severity changed from normal to critical
- Version changed from 2.5 to 2.7
#4
@
16 years ago
- Milestone 2.8 deleted
- Summary changed from Categories Search does not search children categories to "Search Cateogries" does not list/search sub-/childcategories, Tree is broken in "Edit Posts"
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).
#7
@
16 years ago
- Summary changed from "Search Cateogries" does not list/search sub-/childcategories, Tree is broken in "Edit Posts" to "Search Categories" does not list/search sub-/childcategories, Tree is broken in "Edit Post"
#8
@
16 years ago
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.
#9
@
16 years ago
- Keywords search category categories removed
- Severity changed from critical to major
#10
@
16 years ago
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.
#13
@
16 years ago
- Keywords has-patch tested added; needs-patch removed
patch removes the wacky parent check for categories, so that the hierarchy is ignored in searches.
#14
@
16 years ago
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.
#17
@
16 years ago
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.
#18
@
16 years ago
We get to pick which bug we like least. At the moment there is no fix for everything.
#19
follow-up:
↓ 20
@
16 years ago
"PHP Notice: Undefined variable: my_parent in /Applications/MAMP/htdocs/trunk/wp-admin/includes/template.php on line 70"
#20
in reply to:
↑ 19
@
16 years ago
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.
#21
@
16 years ago
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.
#23
@
16 years ago
- Owner changed from anonymous to Denis-de-Bernardy
- Status changed from reopened to new
#24
@
16 years ago
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)
#26
@
16 years ago
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.
#31
@
16 years ago
- Resolution duplicate deleted
- Status changed from closed to reopened
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
#33
in reply to:
↑ 32
@
16 years ago
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.
#35
@
16 years ago
@Ryan: There is one patch left (pagination) and I believe we're good to go on this one.
See also #8955 (closed as duplicate of this).
I have confirmed this behavior in the most current stable release (2.7).