[wp-trac] [WordPress Trac] #11575: Category search bug
WordPress Trac
wp-trac at lists.automattic.com
Mon Jan 25 09:45:29 UTC 2010
#11575: Category search bug
--------------------------+-------------------------------------------------
Reporter: arena | Owner: dd32
Type: defect (bug) | Status: accepted
Priority: normal | Milestone: 3.0
Component: Taxonomy | Version: 2.9
Severity: major | Keywords: 2nd-opinion dev-feedback
--------------------------+-------------------------------------------------
Comment(by dd32):
All that strange logic that you're removing is to do with paging, not
searching.
{{{
// If the page starts in a subtree, print the parents.
}}}
Thats related to paging, If the page starts with a subchild, Print the
parents (Even if they were on the previous page)
How do you deal with paging in that code? I dont see any at all.
Setting the offset + number is beneficial for non-hierachial taxonomies,
as it reduces memory load.
I agree that it could be made much more efficient by lazy-loading the
required terms, I'm not sure how that'll work with paging though, infact,
i really cant see how that'll work with paging well.
> Not sure current code handles correctly a hierarchy of more than 20
parents (current list limit)
The same happens if you have the limit set to 5. or 50.
I agree with Nacin here actually, Skip the rows, and simply display the
hierachy inline with the result. It may take a bit of UI work to get
something that displays it whilst not removing the context of it, but its
doable. And a lot cleaner than displaying all the parent nodes.
You're not loosing any information about the search result, mearly adding
context to it. It'll work with any taxonomy.
> Your proposal would only apply when searching categories !
Not sure that matters, Its only categories (hierachial taxonomies) which
are affected..
--
Ticket URL: <http://core.trac.wordpress.org/ticket/11575#comment:21>
WordPress Trac <http://core.trac.wordpress.org/>
WordPress blogging software
More information about the wp-trac
mailing list