Posted by Aren Cambre on June 30, 2009 at 9:31pm
| Project: | References |
| Version: | 7.x-1.x-dev |
| Component: | Code: node_reference |
| Category: | feature request |
| Priority: | normal |
| Assigned: | Unassigned |
| Status: | needs work |
Issue Summary
Please support autocomplete in Views exposed filters for nodereferences. Currently nodereference exposed filters are either a dropdown or multiselect. Either way is painfully difficult if you have a huge list of candidates, especially when sorting needs don't result in a data list that works well with either kind of selector.
Comments
#1
I agree, the autocomplete widget in node reference is not reflected in exposed filter in views. This makes nodereference filters painfull to use...
#2
I'm afraid this will be falling down the queue unless someone can come up with a patch for review. Postponing until that happens.
#3
+1
Want
#4
Subscribing....
#5
Suscribing too ...
#6
I've rolled a patch that does this. Seems to work for me for both user and node reference, although I have not extensively tested.
I've also added the ability to select multiple nodes in the one node reference widget the same way as taxonomy auto-complete by comma separating values. This only works when "force single" is unchecked.
Not 100% sure on the approach I've taken, so reviews appreciated.
#7
#8
I've added your patch but I don't see how to choose an autocomplete widget in my exposed filter. My node reference field is an autocomplete but even after applying your patch, I see no way to get rid of the select list in my exposed filter in Views.
#9
If the patch is working correctly, it should be the first option you choose when creating a new nodereference filter. I can't explain it any better, as I'm not sure exactly what it's called. It's one of the base options, not one of the extra options. Can you see the choice when creating a new nodereference filter?
#10
+1 Important feature !
#11
Quick note: although I haven't closely reviewed the code (and I must admit I'm much more familiar with the internals of Views than CCK), I tested patch #6 on a site with Views 6.x-2.7 and CCK 6.x-2.6 and it appears to work beautifully. Here are some screenshots of the patch in action on an admin view I created to do advanced filtering of products on a bookstore site I'm working on. The author, editor and foreword fields are all node references to person nodes that represent authors and such. First two are shots of editing the view -- you see the overview of the filters and now the noderef filters have the gear icon to configure them. Then you see what you get when you click the gear -- a choice of exposed filter widget type. Then are two shots of the actual view -- what you see when you first load the page and once you auto-complete an author name and apply the filter. Before, this page was a bit painful to load (and use) with giant select boxes with close to 1000 options in them. Now, it's nice and snappy and much more usable. Yay!
#12
Does not return any names for me.. could it be because i'm using the realname module?
#13
subscribe
#14
Putting back to active. I don't think it should be needs review because there's no patch to review, and not postponed because there's nothing else blocking progress on this issue besides finding someone with time. I think active is the appropriate status until something changes.
#15
There's a patch for review in #6, which has been reviewed in #11. So I think needs review is the correct status, as there is a patch.
#16
Cant we move this into a seperate module? I dont like patching cck for this.
#17
@domidc: I agree. Please see #690478: Maintainer needed for D7 versions of nodereference / userreference.
#18
subscribing
#19
Subscribing
#20
+1 for CCK core for Drupal 6 for this issue.
#690478: Maintainer needed for D7 versions of nodereference / userreference suggests that there would be more work in the long run if this was moved out into a seperate module. I strongly think that this feature should be part of the core NodeReference / UserReference module (in Drupal 7) where ever the base modules reside. Anyone want an exposed filter on 100,000 nodes?
Seperating it here means trying to merge two seperate modules latter on, this seems like a lot more work than simply adding the feature before starting to seperate out the node / user reference functionality. So maybe this should be applied to 7.x-2.x-dev ASAP and back ported to 6.x-(2/3).x first?
Anyway this was just my 2 cents before going off to try and find a way to do this without having to hack a major module.
#21
Subscribing
#22
@Alan D.--the point of #690478: Maintainer needed for D7 versions of nodereference / userreference is that there are no core node/userreference modules. So seems this would have to be implemented in the contrib module.
Huh? Don't see what that has to do with core vs. contrib.
#23
@Aren Remember the 250,000 + Drupal 6 users and D7 is at least 4? months away. Have these already been taken out? That references is only a uncommented task so it is difficult to see what the road map here.
To get this in D6, then you are suggesting.
Split D7 fields, implement the feature, backport into D6? Timeline - 2 months, 4 months, never? This seems harder than just implementing now then everything is in place as the new contrib module is split out latter. Just my 2c
The "Anyone want an exposed filter on 100,000 nodes?" is just a reason for the need, nothing else. The project we are doing currently has 5 different fields that are going to need some form of widget that can handle this, each having > 10,000 references. Having a seperate module that implements a single field widget is not the best path IMHO (I've gone down that path many times - things break and code is duplicated), but either a series of processing callbacks or a new contrib module appears to be the only path forward at the moment, (we try to avoid hacking modules).
#24
subscribing
#25
This may be getting too philosophical, but putting new features in the latest branch first is the safest way of doing things. Worst case scenario is the feature doesn't get backported to old versions, and that is a minor problem because you can always upgrade.
#26
+1 subscribing
#27
Does this apply to CCK3?
#28
The patch in #6 has one nasty little bug (typo) in userreference_autocomplete_value, which breaks userreferences without an assigned view.
Changed '$nids =' to '$uids =' on one line. The rest is the same; all credit for the patch still goes to cdale.
#29
Oops, some more bugginess in userreference_autocomplete_value(). You don't want a db_rewrite_sql() on a user query.
#30
So... no commit-love on this?
#31
Yes please.
#32
subscribed
#33
Friends, anybody else tested the patch in #29? It seems to work fine in my test server. Anyway I'm not php expert to evaluate the code, hence I request developers to confirm if this patch can be used (when time permits).
I don't expect my site to be upgraded to Drupal-7 in the immediate future, and if this patch is not going to get committed, I have to opt to patch my installation.
Would like to have some opinion about this.
#34
Work for me!
Thanks
#35
Subscribing
this is a so cool feature, is there any way to include it into the next release of CCK?
#36
Just corrected the paths in the patch for it to apply correctly from drush make.
#37
When I use auto-complete with any titles that have special characters, the patch in #29 goes crazy. [Found no valid post with that title]
Anybody else having this issue?
#38
+1 here. The patch in #36 appears to be working for me
#39
sub
#40
Lets get this moving...
Someone should volunteer for #690478: Maintainer needed for D7 versions of nodereference / userreference and get this puppy in. Then maybe we can get a back-port!
I'd volunteer myself, but I'm on holiday for the next 6 months ;)
#41
subscribe
#42
+1 subscribe
#43
#36 works great EXCEPT if you uncheck "Force single"
#44
per #43
#45
Subscribe
#46
nodereference and userreference for Drupal 7.x are now maintained separately in the References module: moving issue over there.
#47
Um, Since I have dozens of drupal 6 sites how about if we leave this issue here too?
#48
@gstout: I think the idea is to fix it in D7's references module first, then backport it to D6 (if possible). That's the (often annoying and pointless) workflow that the rest of the community (and core itself) follows. The concept is that it prevents regressions where something is fixed or added in an earlier version which doesn't work or exist in the newer version. In practice, it often means that working code sits in the queue for months or years, especially since the people trying to fix something need it working in the version of core they're using, not some future version they might not be using for another year or more...
#49
I use D6 exclusively as well, but in favour of D7 momentum, I'm for keeping it tagged as-is.
#50
Categorizing.
#51
+1
#52
Subscribing. Hoping for a D6 version sometime.
#53
subscribing
#54
hoping for this for D7
#55
+1
#56
subscribing - but hoping for backport to D6
#57
subscribing
#58
The patch in 36 is missing an 's' on line 326 such that {user} should be {users}, the patch is working on CCK 3.x for Drupal 6 as well. I haven't opened the references module code at all yet. How much does it differ from the old CCK implementation?
#59
subscribing
#60
subscribing
#61
i am a little bit confused. is it avaliable in d7 dev version or not?
#62
this has to be a part of http://drupal.org/project/views_autocomplete_filters
#63
+1, totally agree
#64
I agree with TechNikh #62 (though it doesn't work like that, yet), but also think this should just be out of the box in both References and CCK.