Posted by etcetera9 on September 11, 2009 at 2:25pm
15 followers
| Project: | Views PHP Filter |
| Version: | 6.x-1.0-beta1 |
| Component: | User interface |
| Category: | feature request |
| Priority: | normal |
| Assigned: | Unassigned |
| Status: | needs review |
Issue Summary
Any chance to have an option to use this module with user ID instead of node ID?
Comments
#1
Good idea!
In my case I would want to filter the view by Content taxonomy terms - e.g. by visiting a page that is connected to one particular term ($node->taxonomy->tid) the view would show only users that have choosen that term in their profiles (as Content Taxonomy Fields).
#2
Here is a initial patch . I did not tested it but the code looks fine :)
#3
Hi dereine,
Thanks for your work!
I applied the patch correctly though and the option is still missing in the "Add filters" for user section of views-filters...
Can you take a quick look into it if time allows? Thanks!
Node: Node ID PHP handler is working correctly.
#4
@mitkoru Did you used a node or a user view?
If you have a node view, you have to add the relationship of the node author.
Next version. Renamed some stuff.
#5
@dereine
I use both a user view or a node view but the "User ID PHP handler" doesn't appear anywhere.
1) If I use a user view I wouldn't have to define a relationship, right? "User ID PHP handler" should appear anyway? But I don't have it in my list of filters. "Node: Node ID PHP handler" is there though.
2) If I use a node view under relationships I have only the relation to "Node: Content Profile" (that is because I'm using Content profile module). Anyway, if I load the realtionship to "Node: Content Profile" in filters the usual User filters do appear, but "User ID PHP handler" isn't among them, just like in 1).
That is after the patch from #4.
Sorry for not seeing a probably obvious thing and thanks for your support!
#6
Thank you for the work on this, but this won't be going into this module. The module is designed specifically to return what a view presents -- that being nodes. The idea is, any filtering on anything -- including UIDs -- can be done within the PHP and returned as a list of nodes.
In other words, what you want to do with the module is unnecessary, when you could just do an SQL find in your PHP "WHERE uid IN $uidList" and make $uidList whatever you want it to be. This patch would just be a slippery slope of adding unnecessary additional criteria that can be handled within the PHP -- first user, then category ID, then posting status... etc. It is a small, simple and elegant module because it decides to address specifically and exclusively the most direct result of a view -- a set of nodes.
#7
Views return a lot of different things, not just nodes. When you select your view type, you can choose from Nodes, Comments, Files, Node revisions, Users and other types.
I have a case where I need to create a view to return a specific set of users. It sounds like if this fix is going to go anyplace, we should create a new project. I'll see if I can get it working and go from there.
Thanks for your help dereine!
#8
@mitkoru, I had to flush my cache, but once I did that I was able to get a User ID filter to show up when I created a view type of 'User' under the 'User' list. Testing now.
#9
I couldn't get the patch file to work but I used it to update my viewsphpfilter install. Here is a patch that worked for me.
#10
That's true in D6. Sorry -- mistakenly thought this was marked as a D5 issue.
Doesn't really change, however, the fact that this filter presents itself as Node: Node ID. Clearly not a User filter.
What you want is basically a new filter to be provided in the module. I can't argue that it'd be nice if this module contained PHP filters for all Views-supported content types; that would balloon the module's size, most likely.
That's still not really a reason *not* to do it. I'll say, though, that if the module were to go from a node-only Views1-style construct to one that more conforms with D6's Views2 multiple content types, I wouldn't want to cherry-pick just one additional content type and add that, and then have to deal with this again when someone came back and asked, "hey, why can't I use a PHP filter on comments?"
I'll entertain a patch that would allow the multiple content types available in Views2. A one-shot patch for one of those seems like a lot of trouble for little return.
#11
Changing status and reopening to note that a patch to handle any Views2-offered content type will be considered.
#12
Great. As I understand it, Views 2 by itself (in Drupal 6) supports query types of Node, Node Revision, File and User.
Other modules add other query types such as that of: Location & Term (Taxonomy)
So, to confirm, it sounds like once we can extend the patch to also support Node Revision and File we'll get it to you here and go from there. Thanks!
#13
It would be able to hook_views_data_alter and
1) iterate above each table.
2) check whether this is a base table
3) add a views php filter field
4) in the handler we get the base table and the base field( for example nid, uid, vid, fid) and do everything whats needed there.
#14
Add to the list of tables all optional core modules that Views handles by default. I think that would be 15 or so content types, IIRC. (Should be anything that shows up in the modules directory in the Views tarball.) Since it can be done iteratively, like dereine points out in comment 13, that shouldn't be a problem, I think.
#15
+1 subscribing
#16
Subscribing.
#17
+1 subscribing
#18
I think the user id concept is needed, but the patch doesn't seem to do anything for me. I can add php code for the node id php filter, but nothing for a user id php filter.
My case: I need to provide a list of allowable values for a user reference field, so the view I provide must be a user type view. I need to reference users added in a cck user reference field in a related node, but I can't use a node id argument or filter with a cck user reference field in a user type view. The ability to code a custom php filter here would be ideal.
#19
DERAINE and GNASSAR ! Thank you. This just opened up Views functionality to a whole new level.
I do believe php filter showing up in a the Users View is just as important as the Node View.
thanks again for the module and the patch
#20
Subscribing
wish that available to term view type , PHP filter using tid
#21
So is anybody willing to roll a patch like what is suggested in comments #13 and 14, or am I going to have to do this myself? :) I don't use that functionality, so I wouldn't be the best person to ask to make it, I'm betting.
#22
I"m having a hard time imagining cases where people would want to filter on things other than nodes and users. Perhaps there will be cases for that, but for now I'd encourage you to get the User filter patch into this module and then wait for someone else who needs some other view type to extended as is described in #13 & #14.
#23
I can think of uses very quickly off the top of my head for using this for node revisions, comments, aggregator items, and terms. I'm sure there are uses for the others.
The "right" way to handle this, since this is not named "PHP Node and User filter" :), is to handle all default types. It's kind of silly to start adding types individually when the code to programmatically add all native supported types is actually *shorter*.
In the meanwhile, this module has handled node IDs since back when nodes were the only things you could pull into Views (Views 1.x/Drupal 5.x), so this is very much expected behavior and as documented. So I'd rather change it to conform correctly to Views 2.x, by including all its default content types, or not at all.
Marking as "postponed" until someone (possibly me, but that might be a while) actually gets around to making that patch as described in #13 and #14; that way the issue can remain open and people can see the user ID patch if they need it.
#24
The patches don't work for the current release. I think this would be some nice functionality to add to the module as well, and although I agree there are use cases for comments and more, I think node/user are by far the two biggest use cases for views
#25
subscribe
#26
It has been a while, has anyone got a patch for the latest release?
I am using the user content type and would like to filter out any users whom have a blank field in their profile.
#27
Once I figured out the Views data structure, it was actually super easy to get it to work on every base table available in the current views install. Views and Views PHP Filter were put together in a beautifully modular fashion, so once the filters are defined, "it just works"
The attached patch was tested on the users and nodes tables, but should work fine for pretty much any base table supported by views.
You'll need to clear your cache after updating.
#28
+++ viewsphpfilter.views.inc Locally Modified (Based On LOCAL)@@ -6,20 +6,24 @@
+ if ($myfield = $table['table']['base']['field']) { //check if this is a base table
Drupal uses a codestyle of 2 spaces, please use this as well
Doesn't this line causes notices on NON-base tables?
+++ viewsphpfilter.views.inc Locally Modified (Based On LOCAL)@@ -6,20 +6,24 @@
+ 'name table' => $table_name,
This informations isn't needed, in theory $this->table is provided as well on the filter, but this shouldn't be fixed here
Update status.
#29
Updated patch with drupal coding standards and to remove one other hard-coding reference to nid.
As far as I can tell, only base tables have $table['table']['base']['field'], so by adding this if statement at the beginning, we only add filters to tables which are have base information. If there's no base table info, no filter is added for that table. In any case, I don't get any warnings on my system.
<?phpif ($myfield = $table['table']['base']['field']) {
?>
'name table' was in the original module, so I left it as is, replacing "node" with the name of the table we're creating the filter for. My knowledge of Views doesn't go deep enough to know if this is required or not, so better safe than sorry ;-)
<?phparray(
'name table' => $table_name,
)
?>
#30
Bumping this so hopefully more folks review it... I haven't had a chance to look at it myself, but it's exactly what I was asking for in #14. Doing it programmatically over the base tables makes more sense, is easier, and leads to more straightforward code (that ends up being half the size of the original code). I hope folks get a chance to review it, or that I get a chance to take a look soon myself.