Partial fix Member search does not apply non-grouped single content type constraints to search

[Xon]

Affected version

2.1.7

In actionMember, there is this code;

$content = $this->filter('content', 'str');
if ($content && $searcher->isValidContentType($content))
{
   $query->inType($content);
   $constraints['content'] = $content;
}
...
$grouped = $this->filter('grouped', 'bool');
if ($grouped && $content && $searcher->isValidContentType($content))
{
   $typeHandler = $searcher->handler($content);
   $dummyConstraints = [];
   $query->forTypeHandler($typeHandler, $this->request, $dummyConstraints);

   $query->withGroupedResults();
}

forTypeHandler is only called if grouped is true, which doesn't make sense for something like a thread content type.

 

[Mike]

So this is sort of a bug, sort of something we don't want to change.

Generally speaking, exposing type-specific constraints to the member search is not something that was intended. Member searches have always been designed to be much more limited than the general search system.

On the basis that the "grouped" concept has been around for a while -- though entirely unused by the core -- that has remained, but the accidental ability to set additional constraints has been removed. (That mostly fell out of the need to call forTypeHandler; there is now a method to setup a type handler without passing in a request object for constraints.)

Related to this, the "content" limit will now return all types that apply to that content type. For example, for content=post, that means both post and thread. This is actually the behavior that existed with grouped though it differs from before. This doesn't affect any out of the box links. If you do really just want a specific content type, you can pass this in via a "type" input instead. (Grouping is only supported with the existing "content" approach.)