2

I am using the Signup module, and I am looking to create a view that shows all events and the avatars (default Drupal user picture field) of the users that have signed up for each event.

Here is a mockup of what I am trying to achieve. I have everything but the avatars so far.

View Mockup

See export of the View I have so far

  • Remember to award the bounty if you found an answer fulfilling. – googletorp Apr 12 '11 at 18:47
1
+100

Doing something like this is pushing views to it's limits. You want to pull in a lot of data and group it by the node id. I'm not sure if all this is possible through the views interface, though I believe it will be possible with the engine that's running views.

Instead of trying to achieve this rather complex view, which may become something, that's hard to modify, you could do this quite easily using more and simpler queries. Such a simple solution could look like this:

  1. You could create a simple view, which display all the info except the signups. (Node title etc)
  2. Signup already has a view, which will display the people that signed up for an event. With a little bit of modification, you could make it show the avatar of the users that has signed up for an event. Then you could embed this view in either a preprocess function and/or a template for the view you created in step 1.
  3. You're done.

The ideal thing would be to create all of this in a single view, but sometimes you have to think about what the cost will be compare to the gains. I doubt you will be able measure any performance differences, unless you list hundreds if nodes with signups. But the time you save doing it this way is quite a lot.

This is the same with views itself, it's inefficient, but nothing important (for most sites) and it allows us to save lots of time, not having to code queries, theme functions etc.

Update:

Embedding a view with arguments (like node id) is pretty simple:

$html = views_embed_view($name, $display_id, $arguments)

Or in your case

$html = views_embed_view('signup_user_list', 'default', array('nid' => $nid));
  • The default signup views provide the list of users that have signed up for a given node by taking the node id from the URL. Is there any way to achieve this outside of the node then (providing the view as mockup above), even if it only gives me the username, instead of user's picture? – user842 Apr 7 '11 at 22:33
  • @Nigel: I updated with example code for embedding the view. – googletorp Apr 8 '11 at 8:23
  • How can I modify my view to reference it then? event 1 > Event 1 Attendees, Event 2 > Event 2 Attendees in a single view. – user842 Apr 8 '11 at 17:25
  • @Nigel: My entire point is that you shouldn't do this in a single view, but add the second view via template or preprocess whatever suits you best. – googletorp Apr 8 '11 at 18:01
  • gotcha. Sorry for the confusion. it's getting way beyond my skillset and therefore misunderstood your answer. – user842 Apr 8 '11 at 18:03
0

Create a "Group" named "Event". You don't need to install all of the OG modules, just a few. You dont need to create a group content type: you simply need an "Event".
People create Events and join Events. Go into group default permissions and make the group public by allowing people to join the event without subscribing.

You may want to use the "String Replace" module to easily customize some of the language to your liking, or over-ride the group theme functions. "String Replace" is simple and fast, but can be a bit too universal (it's up to you). Either can help make the language of joining to be just as you want. The template over-ride will allow you to make additional changes to the user interface.

Use a view, and a custom template.tpl.php! Done! Its fast, light weight and easy. Users will never know they are joining a "Group" and the results you get will exactly match what you want. Easy as PIE!

  • O don't want to use OG to achieve what I want. It totally undermines the basis for the functionality in the site. Is there nothing in signup that will help me to achieve this? – user842 Apr 2 '11 at 15:07
  • The biggest issue with OG as a solution is not its features or functionality, its that people associate Groups with things like groups.drupal.org or facebook groups. OG is simply a system to relate content and/or users to a container called a "group". That is a technical term, in fact a "group" meets all of your needs to associate users in a structured manor and would be very easy to handle. I wish there was a better way to name the module then to call it "groups" since the word "groups" is so limiting to people. – MGParisi Apr 2 '11 at 17:44
  • How does OG "Fundamentally undermines the functionality in the site?" – MGParisi Apr 2 '11 at 17:50
  • OG will add overhead to the site. The is no need for users to join groups, have a group directory etc.. The site is just an event site to which people sign up/rsvp to single events. One content type (event) and a user signs up. Trying to keep it simple. I am surprised that there is no way to define a relationship in views or something to achieve it? I can display avatars of users that are signed up on the node itself (referencing the node id in the url), but there must be a way to show each event with each signed up user in a single block display? – user842 Apr 2 '11 at 19:36
  • OG is the simple solution. Unfortunately its hard for people to break out of the notion that OG = "Groups" as defined within social networking. A group is an association of people to a node type. The word group is used by the definition found in the dictionary, not by the associations with Social Networks. The end user never has to see, hear or know he is joining a Group. Many people are using OG and you will never know it. I would create a content type named "event" and when a user signs upto it, they are signing up to an EVENT! – MGParisi Apr 3 '11 at 20:45
0

Add a user reference to your content type if it doesn't already include one and include it on your view with a relationship.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy