Searching in content should work without prefix. Nobody will know that you have to prefix it with "content:". I would leave that and just include to search in the article content.

Searching in content should work without prefix. Nobody will know that you have to prefix it with "content:". I would leave that and just include to search in the article content.

Ok, have updated the patch accordingly.

This would be nice,
but it will have terrible performance on websites with a few thousand articles or more
even timeouts if you have 10,000+ articles

the clause LIKE %word% is OK on

• a varchar 255 title column (or 400 for alias column) with a few backend users

but LIKE %word% on 2 longtext columns ?

And even if you use a real search index, and solve the performance issue
you will hit the UX problem

• users 90% - 95% of the time would search for words that they want to find in the title

so if you enable this always it would be better to priotirize results and return matched articles having the words in the title first and then matches in the content

or add a selector
Search in title
Search in title and content

I suggest to replace prefixes with a new select box as @ggppdk mentioned.

Example:

<select name="searchIn">
  <option value="title">Search in Title</option>
  <option value="content">Search in Content</option>
  <option value="id">Search by Id</option>
  ...
</select>

Yes a selector exactly like @csthomas suggested will be good UX and will give this possibility to small websites without destroying performance on large websites (as searching in content with LIKE will be optional and not default behaviour)

@laoneo at a minimum the search should only search the title by default. If it searches everything by default then it will effect performance. The prefix is the correct method. As is the ability to set the prefix in a select

IMO if these quick filters are going to start searching content and not just titles it needs to be consistent across core. I don't believe the intent of these filters was to ever be a full search similar to the frontend com_search and its plugins, and personally I'm not sure that we should make these filters behave as a full search, but if we're going to I'd suggest that the filters should most likely offer searching the same fields that the com_search plugins query at a minimum per component.

Ok then I will go back to the prefix.

Putting all available prefixes in a select box is a good idea, but out of scope for this patch.
That should be done separately, and consistently for all components.

If you guys really want to have an explicit search in the full content, then I'm also in favor of @csthomas solution with a drop down which defines in what to search. We should stop adding hidden features which are not obvious and will never get documented.

If you guys really want to have an explicit search in the full content, then I'm also in favor of @csthomas solution with a drop down which defines in what to search. We should stop adding hidden features which are not obvious and will never get documented.

I see no general problem with using prefixes for searching. I see it as a power user feature which I personally like very much (btw also available here on Github).

But creating a dropdown for this can still be done afterwards to make it more visible.

Update language string:
COM_CONTENT_FILTER_SEARCH_DESC="Search in title and alias. Prefix with ID: or AUTHOR: or CONTENT: to search for an article ID, article author or article content."

The difference between Github and Joomla is that on Github it is properly documented https://help.github.com/articles/searching-issues-and-pull-requests/ which is not the case for Joomla. So, if this feature gets ever into Joomla, only the people participating in this pr, the guy who merged it and you do know it.

Don't get me wrong, I really like the idea, but it should be done properly.

The difference between Github and Joomla is that on Github it is properly documented which is not the case for Joomla.

I updated the tooltip which now describes the 3 available prefixes: id, author and content.
Is there any other places where this needs to be documented?

if we stop using everything in joomla that isnt documented then there wont be much left ;)

This is what I was talking about the other day when you did the issue, without prefix we also face a user issue. Users are not used to searching full content this could have a mass negative effect on the community.

Prefix is ok... but even I only found out about the ID prefix last week ?.

Ideally we should leave as is, and add in additional filter options. Multi-select option I.e. title is selected by default, the. Allow description, custom fields, image etc.

restarted drone

I have tested this item ✅ successfully on f8d42f1

I have tested this item ✅ successfully on f8d42f1

RTC

Taking off RTC as this should also be implemented in the featured model as the change in the string is displayed there too

Please complete PR.

Waiting for PR to be completed

Taking off RTC as this should also be implemented in the featured model as the change in the string is displayed there too

Good catch, fixed now!

I have tested this item ✅ successfully on 234bf55

I have tested this item ✅ successfully on 234bf55

Back to RTC