Not a bug Search for threads user has created ignores c[nodes] parameter

ivp

Active member
Affected version
2.2.4
Trying to find threads user has created within specific forum and time frame, e.g.

/search/search?c[users]=Admin&c[nodes][]=122&order=date&c[newer_than]=2021-04-14&c[older_than]=2021-05-15&search_type=thread

This returns threads from all forums instead of only ones from forum ID 122.

Meaning it ignores c[nodes] parameter.
 
The problem is search_type=thread doesn't actually implement any of the search_type=post filtering options.

For example, this works;

https://xenforo.com/community/search/search?search_type=post&c[nodes][1]=91&c[users]=xon&c[newer_than]=2021-04-01&c[older_than]=2021-05-01

But this does not;

https://xenforo.com/community/search/search?search_type=thread&c[nodes][1]=91&c[users]=xon&c[newer_than]=2021-04-01&c[older_than]=2021-05-01


This is due to limitations of how Enhanced Search builds it's search queries and interacting search handlers. It assumes there are two cases 1) no search handlers, so everything with no per-handler filtering 2) exactly 1 handler for the content type.

Except the "grouped" content type (ie thread) doesn't actually implement any filtering and is more of a placeholder for the post content type.
 
This isn't really a bug as not all search data handlers implement type-specific constraints -- you won't ever see us trying to use the thread type handler like this, for example. (If you build this search via the UI, you'll use the post handler.)

There is a different approach though: c[content]=thread while search_type=post. The post handler will normally return posts and threads. Passing that constraint in allows you to limit the content types.

Note that this is different than grouping. Grouping allows you to return only one result per thread, to try to avoid situations where a long thread may take up a disproportionate amount of the results.
 
Top Bottom