Come together with the global Drupal community in Rotterdam, 28 Sept – 1 Oct 2026. Sessions, contribution, connection, and Early Bird savings until 8 June.Hi!
Views Fast Search works really great - it's much faster than the implementation of the views module :)
Still, I have some small suggestions
1) It would be a great feature if you can define the search index type. I know, in most cases only the index type 'node' exists, but if someone handles the indexing with own modules there could be more types. So, I used the option field for this setting.
2) I like the idea of combining words with AND or OR, but in some cases it's only relevant to join words only with 'OR', so I thought about changing the operator select field to define how words are combined. I though about 3 values: first a "custom" value for using the filter like now, than the "and" value, where all words are automatically joint with ANDs and the "or" value, where words are combined with OR (without typing in all the ORs).
3) When using views fusion, the $query->set_distinct(); statement isn't allowed (the complete query would crash). Instead of this it's better to use the extra node distinct filter for fused views.
I attached a patch, which implements my 3 suggestions. So, would be great, if we find some solutions together.
| Comment | File | Size | Author |
|---|---|---|---|
| views_fastsearch.patch | 3.02 KB | mh86 |
Comments
Comment #1
douggreen commentedThanks! I'll need to look at this a little closer and have a few things explained.
Why'd you remove set_distinct()? Did you see 110462? This might only be fixed in Drupal 5.
I don't want to confuse the user by offering too many options. Do you envision that the operator will always be hidden and this feature is only for site builders? I could see dropping support for the word "AND" altogether because it's pretty much implied.
Do the additional operators make it easier for the user?
What does query->get_table_name do? I'm sure I could dig in and figure it out, but since you appearantly already have, could you point me to the docs, or explain it?
Comment #2
douggreen commentedAs I've received no response to the questions in the last week, I'm closing this issue without fixing it. If you care to respond to the questions, please re-open the issue. Thanks!
Comment #3
mh86 commentedHi!
Sorry for no response...
Well, concerning the set_distinct operator, this might be an issue for the views_fusion to avoid problems.
The query->get_table_name returns the alias of a given table, exactly what your code does, but with the advantage that this function considers alias
prefixes.
Concerning the operator, I was searching for an easy solutions to join words with 'or' without explicit typing in each time 'OR'. I know, this operator might be a bit confusing for users, but you'll hide it anyway.
Comment #4
douggreen commentedThanks for the follow up!
The AND and CUSTOM behaviors are almost identical. I think it would be less confussing to just offer the current operator (that you called CUSTOM) and the new OR operator. Would you take issue if I narrowed it down to two options instead of three?
Do you need this patch for 4.7, or can I just make it to Drupal 5?
Comment #5
mh86 commentedyes, you are right, there is nearly no difference between CUSTOM and AND, so only CUSTOM and OR are absolutely ok.
I'll need a 4.7 and a 5. version, so would be great if you can apply it to 4.7 too!
Thanks
Comment #6
douggreen commentedI've checked in patches for D47 and D5. If you have problems please flush your Drupal cache first and if you still have problems, reopen the issue. Thanks!
Comment #7
douggreen commented