[#12535] - finder_com allow empty search not recognised
- Expected Behaviour
- 29 Oct 2016
- Medium
- Build: master
- # 12535
Steps to reproduce the issue
create a finder (Smart Search) page with advanced search. Set Option to allow empty search.
open page and just click search button.
Expected result
Should reload page showing "NO RESULTS FOUND" in the results container.
Actual result
page is reloaded with no "NO RESULTS FOUND" in the results container
System information (as much as possible)
attached
systeminfo-2016-10-24T08-27-10+00-00.txt
Additional comments
I looked at the logic in the code at:
administrator/components/com_finder/helpers/indexer/query.php:255
and made the following adjustment. Seemed to make more sense ... and it worked.
// Check if we can search without a query string.
//*** possible bug here - not recognising the allow empty search flag ***//
// was:
// elseif ($this->empty && (!empty($this->filter) || !empty($this->filters) || !empty($this->date1) || !empty($this->date2)))
elseif ($this->empty || !empty($this->filter) || !empty($this->filters) || !empty($this->date1) || !empty($this->date2))
This is a related but different issue. #12490 addresses the rendering of the search button. This issue affects the actual obtaining "search" from the query class. The method rejects the query (search=false) as an empty query even though the flag to allow empty queries is set to true. Without search being set to true you can never get the "NO RESULTS FOUND" displayed.
I stepped through the code with xdebug and ran into this conditional statement that didn't look right considering what the variable $this->empty was meant to do if it was set true.
You know I'm curious why we're doing all this logic in the constructor, isn't that some kind of anti-pattern?
Thanks for bringing this up. It's a long-standing issue that's been on my to-do list for a very long time. I haven't addressed it yet because every time I've looked at it I've had doubts as to what the "correct" solution/behaviour should be.
I usually apply a hack similar to yours on those specific sites where I need an empty search to return all records rather than none. But is that what "allow empty search" is supposed to do? Your expectation is different from mine which proves my doubts are justified.
I'm thinking that in my case, an empty search should be interpreted as a wildcard. No search string means find everything. Should be something you can configure, as in what to do with an empty search.
Except if you look at the tooltip for allowing empty search it states that you must have a filter applied
zero-24
- | Labels |
Added:
?
|
||
Except if you look at the tooltip for allowing empty search it states that you must have a filter applied
That's right, and the code seems to back that up.
What I'm often asked to implement is where a search with no search terms and no filters (static or dynamic) (ie. a completely empty search) returns all records rather than none. You can't get that behaviour without hacking the component at the moment.
So I think there needs to be another configuration variable. Something like "Empty Search Returns" which can be either "All" or "None". This field has a showon so that it is only available if Allow Empty Search is set to Yes. Setting to "None", which is the default, gives the existing behaviour, but setting to "All" gives the behaviour I've described above.
Does that make sense? @nclifton @brianteeman
| Category | ⇒ | com_finder |
Indeed it does.
I read that tooltip. I didn't properly make sense of it at the time I suppose because I was thinking that having a filter made the "search" not empty. I found that what the tooltip was saying was dissonant, so I disregarded it, my bad.
I could have had a fixed filter defined, but I found that a fixed filter didn't have an "allow all or any" option on it's taxonomies. Every time a new article is added to the indexing that introduces a new item in a taxonomy the filter uses, the filter needs to be manually updated to add the new item to the filter taxonomy.
If you look at the tooltip for the option "allow empty search" you will see
that it is only intended to work with a filter
To me a search should only return what you have searched for. an empty
search with no filters that produces something other than an empty result
seems logically wrong to me. Also I suspect it was coded this way for
performance reasons
I would have to find a way for a plugin to "correct" (?) the behaviour so
it'd not be an upgrade issue.
At the moment the controller won't do a results view unless $this->search
is set to true.
I'm hanging a dependency on search results to display a contact link. The
finder filter parameters the have selected (not not selected) are passed
onto the contact form. I was expecting them to attempt a search before I
display that link. Maintaining a cognitive connection between not finding
what they are after and making a contact.
Ideally I am thinking now is that a null search should really be listing
all items ... hmmm.
I have an unresolved design intent here I need to look into.
On Mon, Oct 24, 2016 at 8:53 PM, Chris Davenport notifications@github.com
wrote:
Thanks for bringing this up. It's a long-standing issue that's been on my
to-do list for a very long time. I haven't addressed it yet because every
time I've looked at it I've had doubts as to what the "correct"
solution/behaviour should be.I usually apply a hack similar to yours on those specific sites where I
need an empty search to return all records rather than none. But is that
what "allow empty search" is supposed to do? Your expectation is different
from mine which proves my doubts are justified.—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
#12535 (comment),
or mute the thread
https://github.com/notifications/unsubscribe-auth/AH_qPk_GalLo-0RVML9olTY1DjMJDlv5ks5q3IAxgaJpZM4KehZ5
.
cliftonwebfoundry.com.au
neil.clifton@cliftonwebfoundry.com.au
M 0419140683
| Status | New | ⇒ | Expected Behaviour |
| Closed_Date | 0000-00-00 00:00:00 | ⇒ | 2016-10-29 19:51:44 |
| Closed_By | ⇒ | brianteeman |
As commented above I am closing this as it is not a bug and is the expected behaviour
This comment was created with the J!Tracker Application at issues.joomla.org/tracker/joomla-cms/12535.
Please see #12490
Does this address your problem? Or is it a different issue