Problem/Motivation
Sometimes want to restrict matching autocomplete to strings that match only at the beginning, not anywhere.
Also, the size should be exposed, similar to the text field widget.
Proposed resolution
expose the size, create a match setting, expose it.
Remaining tasks
- add tests. contributor task doc to write tests: http://drupal.org/node/1468170
- get review. contributor task doc to do review: http://drupal.org/node/1488992
User interface changes
Yep. As described above: expose the size and match setting and when match is "starts with", the autocomplete will only match terms that match at the beginning.
Defaults on field edit tab:
API changes
yes. add parameters for passing the entity and bundle to taxonomy_autocomplete()
like:
function taxonomy_autocomplete($field_name, $entity_type, $bundle_name)
.
[kept the field_name as the first parament.]
so can get the match setting from the instance returned from $instance = field_info_instance($entity_type, $field_name, $bundle_name);
Original report by @mstrom81
Hi there,
I noticed what is either a bug, or a UX issue with the autocomplete. Let's say the terms I have in the taxonomy are Architecture and Basketball. After typing in "a", you would expect to only see Architecture, however Basketball also shows up. That's because there's an issue with the db query.
Within taxonomy.pages.inc, there's a method called "taxonomy_autocomplete". It has the following db query code:
// Select rows that match by term name.
$tags_return = $query
->fields('t', array('tid', 'name'))
->condition('t.vid', $vids)
->condition('t.name', '%' . db_like($tag_last) . '%', 'LIKE')
->range(0, 10)
->execute()
->fetchAllKeyed();
The issue is with the following line:
->condition('t.name', '%' . db_like($tag_last) . '%', 'LIKE')
It's looking for LIKE %tag_last%, where it should be looking for LIKE tag_last%.
->condition('t.name', db_like($tag_last) . '%', 'LIKE')
For most use cases I've seen of autocomplete, it looks for terms beginning with whatever the user entered. It seems that most people wouldn't be used to the functionality of autocomplete as-is in this widget.
Any thoughts?
Comment | File | Size | Author |
---|---|---|---|
#50 | 1120144-50.patch | 4.27 KB | djpable |
#43 | 1120144-43.patch | 10.96 KB | tstoeckler |
#43 | interdiff-42-43.txt | 3.28 KB | tstoeckler |
#42 | 1120144-42.patch | 13.3 KB | tstoeckler |
#29 | tax-defaults-2012-12-24_0100.png | 93 KB | YesCT |
Comments
Comment #1
magnusk CreditAttribution: magnusk commentedIt's not a bug, that's how it's designed to work. Maybe there should be a new option to constrain the autocomplete widget so it matches either at the beginning of the name or anywhere in the name.
Comment #2
Taxoman CreditAttribution: Taxoman commentedSubscribing - goes against 8.x first.
Comment #3
xjmRe-titling for clarity.
Comment #4
magnusk CreditAttribution: magnusk commentedThe feature request is to match any part of the term, instead of current behaviour which is to match the initial letters only. I do think the option to pick one or the other behaviour would be useful. I have several times copied and modified autocomplete functions mainly because I wanted generalized matching.
Comment #5
xjm#4: Sorry, I'm confused... the current behavior does match anywhere in the term. The initial post is a request to either match only from the beginning, or weight matches from the beginning first.
Comment #6
Taxoman CreditAttribution: Taxoman commented"anywhere in the term" also includes in the middle of any word, not just the first letter of any word in multi-word terms.
Edit: ah, and yes, initially this issue is about just the beginning of each word, so this seems to work like that anyway. I would personally prefer the possibility to at least configure this to match inside words too, but that might be for a different feature request.
Comment #7
magnusk CreditAttribution: magnusk commentedSorry, I'm the one who got confused.
Comment #8
YesCT CreditAttribution: YesCT commentedHere is a first try at a suggestion for adding options to the autocomplete for terms.
Comment #9
YesCT CreditAttribution: YesCT commented(the screenshot above is from 7.x, but 8.x is similar. this should be done first in 8.x)
the match anywhere only should show when the drop down is autocomplete.
(OR, should there be a configure link, as eventually each drop down might have some configurable options?)
Here is some related code
from
core/modules/node/lib/Drupal/node/Plugin/views/wizard/Node.php
// Add the autocomplete textfield to the wizard.
$form['displays']['show']['tagged_with'] = array(
'#type' => 'textfield',
'#title' => t('tagged with'),
'#autocomplete_path' => 'taxonomy/autocomplete/' . $tag_field_name,
'#size' => 30,
'#maxlength' => 1024,
'#field_name' => $tag_field_name,
'#element_validate' => array('views_ui_taxonomy_autocomplete_validate'),
);
That has "settings" for size of the autocomplete.
Also the whole
core/modules/taxonomy/lib/Drupal/taxonomy/Plugin/field/widget/TaxonomyAutocompleteWidget.php
which shows
Seems like we can add a setting like
"match_anywhere" = TRUE,
Comment #10
YesCT CreditAttribution: YesCT commentedSide thought. are there other settings that might want to be set? like size of the text field?
Comment #11
YesCT CreditAttribution: YesCT commentedwhile working on this, I found this error in saving any widget select form. #1872786: Can't change widget types
Comment #12
nod_If we have the match "starts with" it will allow us to use the HTML5 datalist form thing. Which would be nice.
Comment #13
YesCT CreditAttribution: YesCT commentedwould it be more clear to have a checkbox "match anywhere" where being checked means match anywhere and not being checked means "match starts with" ?
OR
have two radio buttons:
match anywhere (default)
match starts with
?
Comment #14
YesCT CreditAttribution: YesCT commentedAlso, I dont know very much about plugins or widgets, from a code perspective:
Would this be better as
I. the same autocomplete widget, but exposing some of the "settings", as suggested above with a checkbox, or 2 radio button choices.
Or
II. making a different autocomplete widget, to make a total of 4 choices in the tags widget choice, adding "Autocomplete term widget (tagging) match starts with"
?
I'm guessing I. But I'm having trouble coding it up.
Comment #15
YesCT CreditAttribution: YesCT commentedWell, for now, I'm thinking that just unchecking a "match anywhere" is not obvious to be "starts with". so trying to go with radio buttons.
Here is just a start. I still do not know how to get at the widget setting, or how to expose the widget settings form.
Comment #16
fenda CreditAttribution: fenda commentedFor reference I looked at the user autocomplete in core and that is only matching on the first character. Perhaps it's irrelevant.
Comment #17
fenda CreditAttribution: fenda commentedSome comments on patch #15!
Comment #18
YesCT CreditAttribution: YesCT commented@drupaljoe HA! you found the radio buttons? I could not find them. I was looking in field settings and the widget tab!
I did not even look in edit.
Please try applying the patch and then installing. (or maybe clearing the caches)
Here is an example of what I usually do to quickly clear a site and reinstall:
#1855002: "Field settings" tab needs renaming to "Field storage settings" might help a bit.
It says that the field settings tab needs to be renamed global settings.
It also asks for discussion on renaming the edit tab to field settings.
My inability to find the radio buttons, that *I* wrote, would speak toward doing that!
The location these settings appeared might imply that the placeholder (and this) autocomplete match would not be global to everywhere this field is shared.
I find shared fields really hard to consider in terms of the correct behavior without a use case. So if someone could put forth a use case for shared fields and how the widget settings should or should not be shared, that might help.
Is the widget shared with a shared field? If not, that for sure puts these under the edit. (It's a bit hard to test that small part though, because I cannot save the widget tab right now... #1872786: Can't change widget types)
Well, here is a screen capture of the edit tab.
Yes, the description should totally be clarified, shortened, etc. I wonder if it could even be eliminated with the right title and option word choices.
Suggestions for other description, title, and option choices are very welcome.
Comment #19
YesCT CreditAttribution: YesCT commentedI'm assuming that the placeholder and the match setting only show when the autocomplete widget is used. So those would not be on this edit tab with a different widget selected.
So, I think it would help to put them in a "Autocomplete" fieldset, grouped together.
OR
To call them
Autocomplete placeholder
Autocomplete match
But I suspect that that repeating of Autocomplete in their title is not elegant, and would not make sense when the widget settings are used in another setting.
I tried to see what other context these widget settings would show in, and views what the one I thought of, but I got a ton of errors when I tried to add a tags autocomplete exposed filter to an enabled front page view... so I could not test that.
If someone could give steps to reproduce how to see this tags autocomplete in another context, that would be really helpful.
Comment #20
YesCT CreditAttribution: YesCT commentedSince the text field widget exposes the size of the field, I think it makes sense for the autocomplete to do the same thing.
Comment #21
YesCT CreditAttribution: YesCT commentedI added some comments near the @todo with wild guesses for how to access the widget match setting.
Next step: getting hints or an actual way of accessing that, to get this to work.
Also, I added the field size, after we get this working, we can take that out and make a separate issue to add it in if that is needed. I modified the title to sort of make it clear that we are dealing with autocomplete settings without repeating "autocomplete" in each title.
Comment #22
YesCT CreditAttribution: YesCT commentedHere is the wild guess part.
Comment #23
chx CreditAttribution: chx commentedWhat you need is to pass an entity and a bundle besides the field name to taxonomy autocomplete so that you can retrieve the instance.
Comment #24
YesCT CreditAttribution: YesCT commentedThis tries to send the entity and bundle every time. I wonder if I can do this though, because maybe the vocabulary is used across entities or bundles.
Also, this is not working: [edit: I forgot to reinstall, so the reason it is not working is different] there is no autocomplete... in the autocomplete field. I'll take a break for a while...
Comment #26
YesCT CreditAttribution: YesCT commentedwith help from chx to point out the cause of the fail...
but still need to look at why it's not autocomplete anymore.
Comment #27
YesCT CreditAttribution: YesCT commentedah ha. found where the widget itself was needing the additional arguments. now the autocomplete is back.
Comment #28
YesCT CreditAttribution: YesCT commentedoops. forgot to uncomment the actual implementation that pays attention to the match setting. this does that.
So! this is ready for review.
Next steps:
To test:
Comment #29
YesCT CreditAttribution: YesCT commentededit the field, shows the size and match (in addition to the placeholder) widget setting
If change settings to size 20, placeholder "type tags", match "starts with" and follow the steps to test, where tags "one" and "another one" exist.
only see "one" since setting is "starts with"
I'll update the issue summary.
Comment #31
Frank Ralf CreditAttribution: Frank Ralf commentedJFTR
The error message from the test bot:
Comment #32
Frank Ralf CreditAttribution: Frank Ralf commented@drupaljoe (#16)
Thanks for the pointer! JFTR the corresponding code in taxonomy.pages.inc (D7) is:
So it's just the additional "%" in the condition which makes the input match elsewhere as only the start of the string.
Comment #33
YesCT CreditAttribution: YesCT commentedRight, see the variable: $condition_pattern in the patch.
But @nod_ in #12:
I'm not sure if we want to do that here, or in a follow-up... since I'm not sure exactly what "using" that means exactly.
Comment #34
YesCT CreditAttribution: YesCT commentedI think I'll try this again later tonight. I might know more now than I did last time I tried. :)
I'll also go for a follow-up for the html5 concern since no-one felt strongly one way or the other.
Comment #35
YesCT CreditAttribution: YesCT commented#28: drupal-taxonomy_autocomplete_match_anywhere-1120144-28.patch queued for re-testing.
Comment #37
YesCT CreditAttribution: YesCT commentedcustom taxonomy stuff might be going away in #1847596: Remove Taxonomy term reference field in favor of Entity reference
how would that effect the ability to do this in 7.x?
Comment #38
YesCT CreditAttribution: YesCT commentedthe fail in EditorSelection looks like a random failure to me, as that test passed locally.
for my curiosity, how do I get the settings 'match' index declared? adding match to the plugin in the comments did seem to do it.
I want to use index 'match' like: $match = $instance['widget']['settings']['match'];
in core/modules/taxonomy/taxonomy.pages.inc
I thought some magic in core/modules/taxonomy/lib/Drupal/taxonomy/Plugin/field/widget/TaxonomyAutocompleteWidget.php
adding match to settings in the plugin definition would take care of that.
but it is not enough because getting the warning:
"Drupal\taxonomy\Tests\TermTest Undefined index: match taxonomy.pages.inc 149 taxonomy_autocomplete()"
Where can I look for how to use/modify plugins?
Comment #39
andypostI'd prefer to see this setting as Checkbox according core UI suggestions
This would be simple if() else {}
Comment #40
YesCT CreditAttribution: YesCT commentedda_wehner seemed to think it could be done with something to do with views.
I'll keep my eye on that, and try and get it in as part of views conversion.
Comment #41
tstoecklerIn fact we can move this issue to 7.x directly. Even though the taxonomy term reference does not support this feature currently, the generic entity reference does. See \Drupal\entity_reference\Plugin\field\Widget\AutocompleteWidgetBase::settingsForm(). And as @YesCT posted, the taxonomy reference is being deprecated in favor of just that.
I will re-roll the patch for 7.x in a minute.
Comment #42
tstoecklerHere we go. I added some tests for the taxonomy itself but we should also test the widget settings form. Maybe we could get some feedback on the backportability. I think as the strings added (not modified!) here are in Drupal 8 it would seem like a sensible choice IMO.
Oh, and I just now saw that this is still assigned to YesCT. Sorry, if you were working on this. I really gotta check that more often...
Comment #43
tstoecklerThis time with less debug and less commented out test methods.
Also some notes for reviewers:
* I directly used the code that is in the entityreference autocomplete in D8. Therefore this patch should be basically immune to UI reviews, as anything that isn't OK with this UI should be fixed in D8 first in a separate issue.
* I also changed the form values, form API keys, etc. to match those in D8. In D8 the values match the EntityQuery operators, which don't exist in that form in D7, but I don't see any reason to change them to anything else.
* Because it was impossible to actually re-roll this, I had to more or less re-write (or actually re-copy-paste) this from scratch. Therefore I took the liberty of changing a few trivial things. Most noticable is that I changed the URL to be $entity_type/$field_name/$bundle, because field_info_instance() is called in that order. And conceptually we're passing instance information, it's just that instances have no unique identifiers in D7.
Comment #44
tstoecklerOh, also: as can be seen in the interdiff, I forgot to change the order of the arguments in the place where the URL is actually requested. Therefore if #42 *passes* comes back green, we need additional tests as it really shouldn't.
Comment #45
YesCT CreditAttribution: YesCT commentedNo worries, I was waiting to see how the depreciate went in d8. :)
Unassigning from me.
Comment #46
YesCT CreditAttribution: YesCT commentedneeds work per #44
Comment #46.0
YesCT CreditAttribution: YesCT commentedupdate issue summary to use issue summary template, clarify remaining tasks, and add screenshot of current fix.
Comment #47
dariogcode CreditAttribution: dariogcode commentedI'm very interested in this too. I have a taxonomy with city names with state for example Alcaraz; (Albacete), Almansa (Albacete), etc and the "anywhere" search produce no good result when the user search city starting with "Alba"
I know this is a important change but do you think is possible to have in the next Drupal 7 releases? I want to use the patch but my concern is if this won't be merged in the future and the client update the core, this changes will be lost.
Thanks!
Comment #48
dariogcode CreditAttribution: dariogcode commentedI tried the patch in #43 and when used the autocomplete I got the following error:
Comment #49
YesCT CreditAttribution: YesCT commented#2372225: Add sort setting for taxonomy term autocomplete results is (for a little bit) exploring adding a setting per bundle similar to what this was doing back in #28.
Comment #50
djpable CreditAttribution: djpable as a volunteer commented1120144-43.patch
There is something wrong in the #43 patch.
I'm submitting mine fore those who:
Comment #51
giupenni CreditAttribution: giupenni commentedWork for me
Comment #52
giupenni CreditAttribution: giupenni commentedStrange, works in my local installation but not works in production site.
Comment #53
vbouchet