Events functionality is an important part of We want to make it more useful both for event organizers and event attendees.

Current events listing is a calendar view and is not very convenient for finding events.

Proposed resolution

As a first step for making events on g.d.o more amazing we want to redesign this page, to make it primary point for anyone looking for Drupal-related events.

We collected events on g.d.o usecase to help inform our decisions. There is also a prototype by MBD, created during redesign of, to serve us as a guide.

Note that we are currently implementing more simple version, which can be done while we are still on Drupal 6. Things like map of events etc. will be discussed when g.d.o will run on Drupal 7 (for example on Commons #1524868: Have D7 GDO run a distribution profile (such as Drupal Commons))

Page on development site:

Deployment instructions

  1. Enable Better exposed filters module (Latest 6.x-2.x dev)
  2. Remove events -> event path alias at admin/build/path/list/event
  3. Add custom date format "M j, Y H:i" and "Events signup" format type
  4. Deploy latest code in BZR (includes theme & modules)
  5. Make sure admin/build/features has misc in Default state
  6. Configure "recent_signups: Block" block to show only on events and events/* This block should be above "Drupal Events Activity" block.
  7. Configure "Drupal Events Activity" block to show only on events and events/*. Make sure it has title "Drupal Events Activity".
  8. Configure "Modr8 moderator's block" for not to show it on events and events/*
  9. Add default user picture: at admin/user/settings set it to sites/all/themes/bluecheese/images/default-avatar.png
  10. Make sure "Events" item of the top menu links to new /events page and it's first on the left.


Version:» 6.x-1.x-dev

Just throwing some ideas down...these will probably eventually need to be split into separate issues.

Needs dates displayed

One major element missing from this mockup is the event's actual dates. And in fact I'd suggest an exposed filter that allows multi-select of month-year combos, or something like that. Otherwise, it's nigh on impossible to plan your travel.

This could replace the # of attendees column or the organizers column (since there are often multiple organizers).

Location preferences

Country? Ideally, I'd be able to set preferences so that only events from my countries of choice displayed. As Drupal gets bigger, more events will be created. Seeing lots of events happening in a far away land isn't that useful.

Event types

I like that the events are split into Event type and the default is latest. I think these should be the Event type filters, keeping them short if they're to be displayed as tabs as in the mockup

Local Meeting
Regional Camp or Summit
Virtual Meeting

Currently events be classified as only one Event type, but would we ever want to specify that a Training event is also Virtual?
Otherwise we'd have Online Training and Local Training?

I'm Going = signup?

In the mockup, you can quickly mark whether you're attending various events. Is this equivalent to signup ?

In that case, we'd need additional button states: Signups closed and Cancel signup

Title:make events more like redesignmake events more like redesign prototype
Priority:Normal» Major

Also, I think having a calendar view of events within one's groups membership should be retained. Perhaps a smaller version?

A fun thing might be to duplicate the d.o. homepage map for Groups events ... that would need some additional thinking though.

Another thing missing is the ability to browse upcoming events by location (country, city). Obviously we don't have a location field yet but if groups get a location field (see #1074208: Add a location field to group and event content types, then any event within them should automatically get this same location copied to event nodes (should it be overrideable?).

I'll work on a mockup.

(Priority set to major for our upcoming sprint)

Also, I think having a calendar view of events within one's groups membership should be retained. Perhaps a smaller version?

I made a feature request related to this at #1007966: add gid arguments to calendar blocks.

+1 for location field.

Note that it is also confusing that there is location information in the timezone. I nearly travelled to Amsterdam, because in the teaser was written 18:00-20:00 Europe/Amsterdam. In fact the event was close to the German border.

One more problem with these is that the design assumes we will never have more than ~15 characters of data in any of the fields. I think the table will get hard to read when the node has actual titles in it and actual lists of organizers. We'll need some visual separation between columns of the table to fix that.

We also probably want the title to link to the node and the organizers to link to the user profile of the organizers.

Webchick and I discussed some in irc and she's mocking alternative ideas.

Title:make events more like redesign prototypemake events on g.d.o more amazing

We also started compiling some use cases/user stories in a wiki page (as someone looking for an event, and as an event organizer)

tom_o_t added some pretty big wishlist items for event organizers. :) I guess it would also be helpful to ranked these by priority at some point.

Yes, I want to +1 this and say that even experienced users of G.D.O have skipped by the date and asked me recently when something starts. We really have to make it clearer when folks should arrive.

Assigned:Unassigned» twardnw
new115.56 KB

Taking this one on, here's the most recent mockup provided to me.

twardnw: is the scope of what you're doing including all events or just DrupalCamps?

I sense that there will be a proliferation of new groups if location fields are added to groups (i.e. Los Angeles, CA) but not to individual events (Santa Monica, Culver City, Downtown LA, Long Beach, Hollywood, Pasadena, etc.), but perhaps that's a separate issue than this one. Does anyone know if this has been asked and answered already?

I think the location field discussion is outside the scope of a page redesign.

What do people want to see when they first land on the events page? In it's current version, when I see it, there is too much info to be useable (before adjusting the filters). I think only including 'mid-size' events (camps, summits, etc) on the main page would be ok, but then have an obvious route to another view (possibly close to the current view design) with more granularity.

As for the map, that's not possible until the location discussion is settled, so some other content could go there in the interim. An ad/image for the next 'large' event (Denver, Munich, etc) could be placed there

I think the location field discussion is outside the scope of a page redesign.

Based on the link to (from the issue summary), it looks like the original mockup shows new events, user group meetings, trainings, DrupalCons and virtual meetings. Of course, a lot has changed in 3 years.

Where did the mockup mentioned in #9 come from?

As an aside, I hold to my previous statement that location fields for local meetups should be considered. There are mega groups (such as Los Angeles, which has 7 monthly meetups a month) where one location field won't suffice for the entire group.

The mockup in #9 was given to me by jredding when he, drumm, and myself were discussing

Let's stick to discussing location in #1074208: Add a location field to group and event content types. Until we have geocoded locations, any mapping won't happen. We can still make a nice page without a map.

new132.57 KB

Here's where I am right now.

How should we direct users to a more in-depth search page?

I think we should find a place for navigation to other types of events right on this page. has a select box for event types, but select boxes can be cumbersome to use. I think we just want a set of links to filter somewhere, maybe like the "or filter by…" block at

The "Post a DrupalCamp" link should be "Post an event." This is for all events, not just DrupalCamps.

If we want to stick a photo in the placeholder, you can try a Creative Commons licensed one on Flickr

What events should the initial view show?

I like the idea of the filter/links in a block

IMO it should be all upcoming in descending order of how soon they happen. The idea there is to show activity rather than to be immediately useful.

Another strategy could be
* If the user is a member of groups show them events in their groups
* If there are no events in their groups or they aren't in groups, show events from the whole site

I like where this is going. What about integrating these together?

Ok, so current thought is to:

Status:Active» Needs review
new160.28 KB
new6.94 KB
new4.72 KB

Starting with just a new front page for events, can work on adding more functionality in little bits.

deployment instructions:

  • Change path on current calendar (/event) page to /events/calendar
  • Create new view 'events_frontpage' (txt file attached)
  • bluecheese CSS changes and new tpl files (in diff file)

Has to be done after #969940: Deploy bluecheese on

Screenshot attached, can also be seen on the dev site :

Assigned:twardnw» dougvann

What are the barriers to realizing this initiative? What can I do to help?
I've got time to commit to this and am very willing and able.
- DV

I think the biggest thing was waiting for bluecheese deployment. There are some other issues with locations, but that shouldn't keep us from getting a new page deployed, we can add that function later, if it is added to groups/events.

Feel free to poke around in, you can drush uli user 1 if you want.

I think the call to action for the "calendar" should be bigger and posting an event maybe smaller. The ratio that people will click them seems the opposite of their prominence on the page.

From a technical level, how do things become "featured" on this page?

From a process perspective, how will we decide what gets featured?

This is just a view of upcoming: DrupalCon's, Camps, Sprints, and Trainings.

Nothing filtered on it beyond that at this point.

new26.24 KB
new1.64 KB

I added filters to the page and adjusted the columns to match our grid system. is running this. A new set of patches is attached. Review from our new site maintainers, Ezra and Scott, would be great.

I think the idea was to not provide filters on this page, having it more as a landing page, and then direct the user elsewhere if they don't see what they're looking for.

We hired a team of great designers to create

We've now drifted pretty significantly away from that.

I'd like us to make sure that when we drift from it we are doing it with intention. So, the original version has filters at the top of the page as tabs. What is our goal by removing those filters?

We should keep our event browsing focused. If one listing page can do the job well, we should stick to one page.

I think a simple list is better use of the space than the calendar view. We could clean up the calendar a bit and it would be a neat way to show everything going on for certain days. But, I think the simple list will be nicer. A gridded list provides a bit more space to each event. And we get our trainings list,

The main reason I didn't go ahead and replace the calendar is that I couldn't find a way to add the ics version. That either needs more work with the view, or adding/changing a display on the old events page.

I'm looking at the dev site. Looking good!

My 2 cents:

  • Small thing that's missing from event listings is the year. Cons and Core dates can get posted over a year out, so a year might be helpful (also it confirms that it isn't in the past!).
  • The UI text probably needs an overhaul, since events can be virtual, but that can come later (also ... do anonymous users need different info from auth?)
  • Should we prefix group name with a label? Otherwise ... I don't really know what the last line here means, and the title doesn't provide location :))
    Drupal Coworking Friday
    April 6
    Florida, Drupal Coworking
  • Would love to see the sidebar blocks be related to events... maybe featured events, events in my groups etc

I do really like the table format proposed in

It seems super useful to be able to see all upcoming events in my groups, and see at a glance if I'm signed up. I haven't been watching this issue as closely so perhaps there's a reason we aren't using that layout, and I missed it.

Thanks for the feedback, Lisa.

Prefixing with group names could get ugly, though I agree an indicator of context (i.e. group) is valuable. We've got a fair number of group names that are 40+ characters:

| count(1) | ceiling(length(title)/10)*10 |
|        1 |                           70 |
|        6 |                           60 |
|       22 |                           50 |
|       71 |                           40 |
|      142 |                           30 |
|      332 |                           20 |
|      386 |                           10 |

I find the gridded event list much harder to scan than the vertical one. With a gridded list, the viewer has to scan horizontally as well as vertically.

Is that style of event listing used successfully elsewhere?

I share greggles concern in #29 and lisarex's in #31 that we've deviated too far from the original design. Let's move back to a vertical list.

Also, regarding the "I'm going" link -- There are some cases where a simple toggle link is insufficient:

- DrupalCamps, which do event signup on a dedicated site away from GDO. We could provide an "event signup" URL field and render that field in the listing if it's populated, and provide a toggle link if not.

- Events like the NYC Drupal Group that require their full name to be populated in order to sign up: #1175322: Sign up for event require first name and last name. In these cases we could detect that and provide a link to the node, perhaps.

Assigned:dougvann» Unassigned

+1 to moving back towards the original design. I'm going to drush uli user 1 and play with the view.

#32, we could leave off the label; my sense is it's learnable that the terms underneath indicate group.

#33, yep, for offlist signup it can be a link or just an indication that the signup is located elsewhere.

The basic idea behind the grid is that jredding wanted something like for Drupal. Having a good list of trainings is a big goal for us,

Personally, I can see how the grid is less useful. As we add more events and more details, it does look harder to read. We needs something for Drupal, not repurposed from wordpress. This was originally meant as a splash page only, which it may work at, but I do think the calendar should be replaced.

For the MBD mockup, we should treat it as a guide, not exact implementation. It is from over 2 years ago and things change. For signups, I think we should just skip the column rather than figure out how to populate it well.

Agreed we should use the MBD design as a guide and not try to match perfectly. I also find the grid harder to read than a straight list.

If we want this to splash then having some impressive stats would be good:

* Number of camps in the last year
* Number of signups in the last week
* Number of total events that will occur in the next week/month

Assigned:Unassigned» lisarex

I've cloned the view and am working on a table layout at I'll annotate a screenshot with the extra bits that need doing / discussion and will post it here.

The grid view is still around at

How is this going? What needs more work on the table? I think we want to remove the 'offsite signup' column completely.

The grid can be removed completely. It is backed up in this issue if we ever revisit it.

new618.06 KB

Here's a mockup that attempts to illustrate how this would look, for both logged in and anon users. I've incorporated greggles's awesome suggestions from #36.

Thoughts? Will require a bit of extra work to implement.

EDIT: Noticed the When/where didnt get copied over to the 2nd screen; my bad! It'll be the same as on the left though.

This looks great overall!

However, "Featured Events" raises some red flags. What does that mean? Do we need an approval process around that? I'm not sure what "Uniqueness" module does. I think I'd prefer that to be "Events this week" or something less potentially contentious. :)

It'd be cool if "offsite signup" could link to said site. :)

I'm wondering about the utility of the "signup" column. Aside from some major rockstars, most people aren't going to be attending more than one, maybe two, of the events listed at a given time. So for 99% of the table, that column isn't terribly useful and most people can remember the 1% they are planning on attending. :)

Greggles and I had further discussion in IRC about "Featured."

- "Featured" might make sense if it were an advertising thing to raise revenues (as long as it was clearly marked as advertising). For example, if Lullabot or Acquia wanted to pay money so their paid training event was "Featured." But it doesn't make sense for camps, sprints or other things like that, because they are basically doing the DA's work of promoting/improving Drupal for us, at no cost to us. I don't see much sense in charging them money to promote that.
- "Featured" implies an editorial process of some kind, which implies some events are more "special" than others, and also implies that there is an elite cabal somewhere that's deciding who is worthy and who isn't. I don't really like that in the context of community events.
- Because of the above, if "Featured" is actually an automated listing, we'd probably be better off to re-title the block to what it's automated by. For example, "Popular events" or "Upcoming events" or "Events in your area" or whatever.

Ideas for automation:

- Sort by # of signups (would exclude events like DrupalCon though or others with off-site registration, so sub-optimal)
- Sort by radioactivity (some algorithm based on # of comments, +1s, views, sign up data, etc. — caution! likely to find "events with the biggest active flamewar" :P)
- Sort by start date (same as what does)

Greg also looked into it and said the word "featured" wasn't in either the MBD or DA comp, though "Major" was added in the work product somewhere, probably as a way to condense "sprints, training, camps, cons" (so random IRC meetings and the like don't show up there).

...all of which is a really long way of saying, "Let's pick a different title than 'Featured' for that block, please." :) Unless it's for fundraising, and then make it look more obviously like an ad, with a link to clear directions on how to get your event featured there.

new511.61 KB

Thanks for the feedback! Revision attached.

Michelle, I agree about the signup column. It will be messy to display and implement (at least for now), so I've removed it.

webchick, good points. I've renamed the block and updated the notes in the comp. It needs to be automated, without any 'volunteer overhead' to maintain the list. We can talk about exactly what the Radioactivity module includes though...

I also got rid of the year in the table display; didn't think it was adding much value.

The pager and "When" filters both offer ways to browse different times. Are both needed? Only the pager would be easiest to implement.

"Groups" filtering for anonymous users, and authenticated, can be done just by browsing to the group page, which has the "Group events" block.

This could leave only the "Type" filter, making more room for the content, or a map in the future.

Internally, the marketplace preview filters are not pretty. For a single filter, we might be able to implement it as another view sorted by number of events in each type.

For Activity, I think time periods should be rolling windows instead of calendar-based. Calendar-based is "next month" = May 1 to 31; it is a little harder to implement and you end up with fluctuations in the numbers, May has a lot less signups on April 2 than 29th. Rolling window is "next month" = next 30 days; easier to implement, consistent numbers, and what we actually do for "This week" on

For reference, I added an interesting events block to based on radioactivity. In the current DB on that server (not sure how old that is) it shows 3 camps and 1 sprint.

I'm all back to the drawing board with this ... handles events really well but the key difference is that they really only have one type of event, whereas we have 7. That said, how important is the type as a filter/facet? I wonder if it's just sufficient to display the type. Just need to think how to handle these.

I do think that authenticated users, the default should be displaying events in your groups, and showing you events you might be interested in. For anonymous, the emphasis should be on helping you find events of interest, plus getting you logged in. Thoughts?

sreynen, the site wouldn't render when I checked today.

I think type would be optional if there were an easy way of separating "meat space" events from virtual events. That's primarily what I use those filters for, to try and figure out where I need to fly. :)

Can the event submission form have a multi-select list for which type of event it is? Many of our physical events are valuable to people who attend in-person as well as online.

Take, for instance, our meetup tonight. It featured a presentation that was given remotely:

The code sprint and barn raising that we had this weekend had a short Features demo:

In both cases, we had live broadcasts via a Google+ Hangout.

new553.08 KB

OK, here's an updated prototype. Bear in mind this is based what we can implement now, on the D6 version of g.d.o. but I think it will be useful to get feedback on this, once live, to shape the D7 version of Commons (and we can do much cooler stuff for D7 version like location coordinates & map :))

@christefano, that seems useful to make 'virtual' an extra option for every event but I think it needs more discussion, probably in a separate issue.

Latest mockup looks great. I prefer table-less layout and how it's broken down by time periods. Of course it goes away from the original prototype by MBD, but I like its more "human" look. Also Lisa Rex made a good point on IRC of this version being more responsive-friendly.

I'm wondering about usefulness of the recent signups block for auth users. For anonymous users it can be good to show activity, but for authenticated I'd prefer to see something more relevant to them, for example "my signups" or at least Recent signups in my groups not all the groups on g.d.o.

Issue summary:View changes

explained the mockup

Issue summary:View changes

issue summary update

Issue summary:View changes

small fixes

I've updated issue summary. Please comment on the latest prototype by lisarex. We need to finalize the design in order to implement it before this issue turns 2 years old :)

new446.3 KB

Annotated the latest D6 mockup.

Note: The horizontal bars merely ask for visual horizontal line (either border-bottom or background-color for headings). Not asking for (ugly) table styling. ;)

Hi sun,

You've x-ed out several parts of the design and labeled them "useless."

Can you provide some explanation for why you feel those parts of the design don't add value?

In general it would be helpful to stick to specific, constructive feedback versus words like "useless" which are emotionally charged but not particularly descriptive.

Feedback on #49: I'm torn between the two main event listing displays.

I like the table-based design on the right because it's more information dense and is likely to be faster to implement. However, I can see the benefits of grouping events by time period as they're done on the left.

I suggest changing the label from "online meeting" to "can be attended remotely" or something similar, since often user groups happen in person with the option to attend online.

I like that we display the overview statistics about events on GDO - In my mind it helps solidify the idea that Drupal is highly active for folks who are new to the site or to Drupal.

The stream-style view of recent signups seems like a fun display since it highlights individual participation and is a way of randomly showcasing individual events.

However, if there were a higher priority listing of content I could see that taking less space (eg show fewer signups) or potentially being removed if there's something really high value to replace it.

In general, this looks good. More specific comments:

* It seems odd that the first text is suggesting you go somewhere else (the calendar view). That should probably be preceded by some text explaining what to do here, if not removed entirely, since the same link is on the bottom already.
* I prefer the non-table view as a step toward prioritizing the more important info, which is harder to do in fixed grids.
* "next 7 days" and "next 30 days" suggest both lists start from today, which would mean duplicate events. But the alternative would be something like "next 7 days" and "7-30 days," which seems unclear. "this week" and "this month" have the same problems, and also introduce ambiguity about when those ranges start (1st of the month or today? monday, sunday, or today?) Maybe "next 7 days" and "next 30 days" should be collapsed into a single list?
* I like the recent signups list as a way to demonstrate individual participation, but it seems about twice as long as it needs to be to make that point.

Title:make events on g.d.o more amazingRedesign events view
new38.58 KB
  1. To clarify #52: The overall event statistics and recent signups might be nice for marketing, but don't add any value for authenticated users. Instead, they're adding visual clutter only. At minimum, let's limit the recent signups block to anonymous users. That said, showing signup info publicly inherently leads to privacy concerns for people who want to sign up for an event but don't want to publish their activity this transparently. Lastly, if the event stats have to be displayed for authenticated users, then place them into the footer, so they don't draw away the user's entire attention.
  2. re: #55: The Today/This week/This month/Later headings and sections don't have to be 100% exact in terminology, nor in content. As long as the event entry dates start with the weekday. The (starting) weekday is apparently missing in the mockup. The sections merely serve as a simple visual categorization.
  3. It's probably a good idea to put the filters into the right sidebar instead. They are optional, but the current design mockup presents them first.
  4. A cut-off list of attendees per event would be helpful; e.g., 3-4 usernames. (perhaps that's D7-only material though)
  5. Showing who invited you to an event would be helpful. (perhaps that's D7-only material though)
  6. The "My events" view should ideally look identical to the resulting visual design here, merely with additional constraint on the current user.
  7. For the "My events" view, we also need to consider an empty view.

That said, let's not re-invent the wheel.

Various usability experts have studied this field for a long time already. We can simply copy the layout and content concepts from sites that have a first-class UX for events. Alas, Facebook happens to be one of those:


(Apparently, that's the "My events" view, but the view for all events looks pretty much identical.)

  • Simple sections to separate the schedule into basic groups.
  • Exactness of sections isn't important. The visually emphasized weekday sufficiently clarifies the exact day and date.
  • Minimalistic simplicity instead of information overload. — That said, the basic event location (e.g., city) is important, though most often contained in the event title already.
  • Optional filter options are available, but not front-loaded.
  • Ability to see more. — Though a simple pager is more than sufficient here.

new163.42 KB

Seems everyone prefers non-table layout, so I took it as basis and moved things around a bit.

sun, yes, we're def missing a location but there's currently no location field in the current D6 Event content type //needs issue??

tvn, thanks for doing a revision.

just some comments on your version

-I think the checkbox for 'events I'm going to' is potentially confusing because it's not clear if this is specific to sign up module or whether there's another way to indicate that you're attending (and in the case of something like a camp, this probably an off list sign up anyway)

- check with drumm, but I think it's easier to implement "next 30 days" than "next month". sreynen makes a good point that there will be duplicates so a "next 30 days" is prbably sufficient.

otherwise, it looks good!

also, for travel planning purposes, what are some good increments? 30 days, 60 days, and "later"

I'm not sure I explained my date grouping concern well before. A specific example may help.

Let's say I'll have some free time to travel around the beginning of June and I'd like to see what events are happening then. When I see "later this month" or "this month," I don't know whether I should expect to find early-June events there or in the next section. When I see "30 days," I know that's where I want to look. So I like something like "30 days" because it makes the list easier to skim.

The main benefit of something like "this month" seems to be that it sounds more natural, less like an equation. If we're talking about getting rid of the week group, it might be good to consider month names as the section headers. Those would make it easy to skim without seeming very formal.

Lanyrd, Facebook uses months as groupings.
Meetup groups by day/

Months seems fine to me. Someone who is implementing this should speak up ... :) has a nice implementation with the map, but I can't find a way to see all upcoming events in a filterable list.

"Events I'm going to" meant the ones I signed up to (and probably the ones where I am organizer), but if it's confusing lets remove it.

I like months names as section headers, but I'd love to have current month divided into sections like on mockup, so:
Later this week
Later this month

To me "Later this month" does not seem confusing, this month is May, so I would look for early June events in the next section.
Most confusing is week as it can start on Sunday or Monday, so maybe we could go without it, just Today - Tomorrow - Later this month

That said ultimately I would go for something which is easier to implement and can be done faster. So if grouping just by month is much easier than adding all other sections - lets do it first.

Would it be difficult to attach camp/summit logo to go with these?

kattekrab, that probably can be done, but lets implement at least basic redesign first.

Development site is available at
If anyone wants to help with implementation - request SSH access to the site (follow instructions at

Issue summary:View changes

adding link to big image

Whatever you build, if you could provide a JSONP-capable feed so I could build a mobile app to fetch the events view, I'd be ecstatic. :-)

Chris Johnson, that's outside the scope of this redesign, so you should open a new issue for it if you don't want it to get lost here.

How can I help? I'm new to this redesign programs bu I'd like to get up to speed so a little mentoring would help.

Hi primerg! Help with implementation of the redesign on development site will be highly appreciated!

We have a mock-up of the events page to be implemented, with minor things like grouping of events to be figured out during implementation. We already have a development site available: and I see you already requested SHH access #1626966: I want an SSH access to g.d.o events development site (great!). Once you get an access, you can change password for user 1 (we have instructions for this) and start implementing new design. I'd suggest to start with creating basic view of events.

You can join #drupal-groups IRC channel where I or maintainers could answer your questions and provide some help along the way.

Component:Miscellaneous» User interface
Assigned:lisarex» Unassigned
Status:Needs review» Needs work

thanks tvn! I'll hop to IRC once i have my ssh access and configured my environment.

Status:Needs work» Needs review

Please review -

My issues:

  1. I tried to implement Later this week and this month but I'm not sure about the rules. Is this just grouping of the results? So Later this week would mean any event that is this week but not today and tomorrow? Then Later this month are events not this week?
  2. In the Drupal Events Activity - is this just a text?
  3. In the Recent signups, is the Date at the bottom the date of the event?
  4. In the views exposed filter, I installed better_exposed_module to make the Event types checkboxes. I am not sure if I am allowed to create a module to make the radio buttons into a single checkbox. It doesn't look like there is an available option in the better_exposed_module module to use single checkbox.
  5. for the Post an Event link, is there a reusable css class for that? I tried looking in other pages but cannot find an element using the green button without text.

5 - found it!

primerg, this is looking great.

I believe the answers to your questions are 1) yes, 2) these are live stats, just like the "Develop with Drupal" list on the front page of, 3) yes, and 4) it's probably better to patch the existing module, which already has an issue open: #1171952: Yes-No Checkboxes

Beyond "yes" on 1 and 3, the questions suggest there's room for usability improvement there, as users will very likely face the same uncertainties. But this is already far clearer than what we have currently, so that shouldn't slow down implementation.

primerg, looks great indeed!

Your questions:
1. yes
2. what sreynen said, mock-up contains example stats, maybe greggles or someone else could comment with the exact list of stats which are interesting/possible to implement
3. yes
4. what sreynen said :)
5. more correct class for Post event button would be .action-button, looks the same though

Some notes:
a. "Post an Event link" block should be shown only to auth users, for anonymous users clicking that button gives "Access denied" message.
b. Later the path to the view you're working on should be changed to /events and current /events calendar view should be moved to /calendar or something like that
c. "Only events I am going" and "Only events in my groups" should not be available for anonymous users.
d. Considering Lisa's comment #58 - maybe it is better to rename "Only events I am going to" to "Only my signups", to make it clear that these are events you signed up to on g.d.o ?
e. It seems that "Drupal-Stammtish in Frankfurt am Main" event is stuck on top of the list whatever filter I chose. I see that you are working on the view right now so I will test it later.

Thanks for the review. here is an update:

1 - implemented. One thing I am still trying to work out is display the date based on the user's date. Right now, all dates displayed on server time. I assume that is the preferred method to display the date, right?
2 - I'll try to contact greggles and see how it was done
3 - same issue as 1
4 - patch has been submitted. . It is still a work in progress though. I still have issues with the item's weight

Haven't touched the issues brought up by tvn.

1 - done

from tvn's notes:
a - done
b - done
c - not yet sure how to do this without using the hook_alter
d - done
e - done

I've updated the blocks to show them on /events instead of /events_list. (View got moved to
View filtering works fine!

Couple more notes:
1. Last grouping title I can see is "Later this week", there are no "Later this month" etc. ?
2. We should add some empty text to the view for when nothing is found - "Sorry, no events found in this category. " or something like that.
3. It is better to change "Today" "Tomorrow" etc. titles to be h2 instead of h3.

new2.86 KB

Here is a patch for the new block statistics

notes from #78
1 - fixed
2 - done
3 - done

Status:Needs review» Needs work

Great start! The patch in #80 needs a little work. We sill need that existing stats block to work, so this needs to be in a new block function.


+          WHERE node.status=1 AND node.type IN ('event') AND DATE_FORMAT(FROM_UNIXTIME(event.field_start7_value), '%Y') = '$year'";

I think that could be better written as:

+          WHERE node.status=1 AND node.type IN ('event') AND event.field_start7_value > unix_timestamp() - 60*60*365";

The same applies to the second query.

The third query:

$count = db_result(db_query("SELECT COUNT(*) FROM {signup_log} signup_log WHERE signup_time >= '$date_fr' AND signup_time < '$date_to';"));

The $date_fr (which should be $date_from) and $date_to are predictable, values, but just for consistency could use placeholders more like:
$count = db_result(db_query("SELECT COUNT(*) FROM {signup_log} signup_log WHERE signup_time >= %d AND signup_time < %d", $date_from, $date_to));

And for the last query I suggest doing a similar "unix_timestamp()" trick and finding if the date is within the next 31 days seems good to me.

Status:Needs work» Needs review
new2.66 KB

thanks greggles for the review. Here is an update.

Note about the patch: I did not use the unix_timestamp but instead use a combination of FROM_UNIXTIME, DATE_SUB and DATE_ADD. I found it more accurate to check by YYYY-MM than computing in timestamp. Let me know if you have a better suggestion.

Regarding the queries, please see if I understand the requirements correctly:

  1. events coming up next month - I believe the calculation for the whole month of next month, right? So if today is June, I'm calculating events for the whole month of July. Correct?
  2. camps this year - camps for the whole year from January to December? Or signups from today up to the end of this year? I did the first one.

primerg, one last note about the titles. We need to have something after "Later this month", because right now all events of all the next months (July, August, September..) go under that title. Can we add months titles after "this" month ends?
For example, today is June so under "Later this month" we have June events. Then title "July" - July events, "August" - August events etc. till the end of the year. And then the title "Next year" and the list of next year's events (if any).

Apart from that looks really good! I hope soon we can deploy this on the live site.

A visual inspection of the patch in #82 looks good to me.

#83 done - added the titles.

Thanks primerg!
In the mockups we had urls for events under titles, but event node type on g.d.o has no such field right now, so I added event_url field and added it to the view. I am going to fix css a bit to have event url and groups on the same line.

We still need to decide what to do with
- Only my signups
- Only events in my group
showing them for anonymous users makes no sense.

Also I like Recent signups block a lot, maybe we should show more than 3 signups there?

Issue summary:View changes

updating summary

I cleaned css a bit and moved it from the separate file to styles.css. I moved list of groups to the left and added Groups labels, to make the list more readable especially when there are too many groups and event has no url.

Changed Recent signups block to show 5 signups instead of 3.

We will need to add default user pic to g.d.o to always show something in the recent signups block. I suggest we use default_avatar.png from images folder of Bluecheese theme.

Overall I think this is ready for drumm's review and deployment. In the issue summary I started to write deployment instructions, primerg please take a look if I missed anything - any patches you applied to any modules, any config settings somewhere etc.

Issue summary:View changes

adding deployment instructions

Issue summary:View changes


new1.95 KB

Attached patch for Bluecheese

Issue summary:View changes

adding image location

Issue summary:View changes

adding link to Bluecheese patch

I updated the deployment instruction. Will be posting a patch to hide checkboxes "Only my signups" and "Only events in my group" from anonymous users.

new4.09 KB

Patch for hiding the checkboxes "Only my signups" and "Only events in my group" from anonymous users. Included in the patch comment#82 since I am using the same file.

new25.57 KB

Here is an updated patch with all the dependencies and default views. Not sure if this is the best practice combining the default views to the existing one.

Issue summary:View changes

Updated issue summary.

this is looking really good!

The only thing that could possibly cause issues is this no way to filter by date. That is, you are only able to page forward. However, it might not be a problem since the other filters can make the list a reasonable length.

However, don't let that hold things up.

Issue summary:View changes


Assigned:Unassigned» drumm

@drumm, please review these patches and if they're good, let's deploy this before the week ends or kick it back for some more work.

Status:Needs review» Needs work
  • Are the deployment instructions in the issue summary fully updated? #91 makes it sound like there might be less steps since more is in code.
  • The event type floating to the right looks disconnected from the rest of the event. Can it be inline on the left with something?
  • We should avoid PHP in Views, or anywhere that might be updated through the UI. Can that code go into an alter hook or in the theme?
  • #1171952: Yes-No Checkboxes hasn't passed testing and hasn't had any recent feedback from the module author. I'd like to see a bit more on this before hacking the module in production.

I'll try to work on the last 2 issues early next week.

I realize I'm pretty late to the game and implementation has already started. However, I've used the interface on multiple occasions and I know what would've made it more useful for me.

1. One of the things I liked about the early mockups was the "my location" link. It would be helpful to be able to search not just by country and city, but also by region ( East / Midwest / Southeast if USA ) or state. Companies are more likely to send folks cross country. Individuals are probably more likely to want to stay within their region. I guess this is where maps come in handy. Particularly if the user has set a location on their profile and the map automatically zooms to their state, which would eliminate 2 clicks from selecting country, then region.

2. If there will be tabs for content types, should sprints be included? Giving community members a fast way to participate in a code sprint could be beneficial for getting stuff done.

3. I understand not wanting to clutter up the interface, would it be possible to offer an "advanced search" functionality for power users who are looking for specific events with a lot more options on a different page? Like specific date ranges or multiple regions / states. Maybe offer a block that would list the currently selected options ( think about it like shopping on best buy or amazon ) and also with a "View this search in a calendar".

I just transferred the code in the views to groupsorg.module. Will be providing the patch later. Will be closely looking at #1171952 for possible updates.

Thanks primerg. #1171952 should get some attention from the module maintainer soon, so we are getting closer to deploying this! Please review deployment instructions when you attach patches, maybe they'll need some changes.

re #94 I don't think that event type looks disconnected, if we move everything to one side - the list will look unbalanced.

crimsondryad, you have some good ideas, but we are in the middle of upgrade to Drupal 7 right now, so please note from the issue summary:
"Note that we are currently implementing more simple version, which can be done while we are still on Drupal 6. Things like map of events etc. will be discussed when g.d.o will run on Drupal 7"

As for the sprints - there will be checkbox for sprints to show only this type of events.

@tvn, fair enough. I'm not expecting anyone to change direction on my account, just trying to get my oar in so I don't miss the opportunity later. :)

Issue summary:View changes

removing to-do, it's done

Issue summary:View changes

Updated issue summary.

Status:Needs work» Needs review
new6.43 KB

Please check wrong issue!

new6.43 KB

removed the dependency to views_customfield wrong issue! :D

Status:Needs work» Needs review

Patch for #1171952: Yes-No Checkboxes has been committed, we can now use 6.x-2.x-dev of BEF.

just a side note, maybe you already know it. recently the folks from launched a free service which nicely presents event data from g.d.o

might provide some inspiration for follow up developments

Issue summary:View changes

Updated issue summary.

Issue summary:View changes

updating instructions

I've replaced BEF on the development site with the latest -dev release, seems to be working fine.

Status:Needs review» Needs work

primerg - I think you have the wrong patch, this isn't COD.

oh my! so sorry. :D this is what happens when you have a lot of open tabs

Status:Needs review» Needs work

I noticed there are 2 new templates in bluecheese, views-view--event-list--page-1.tpl.php and views-view-field--event-list--field-start7-value.tpl.php, which were not included in Are they needed?

Issue summary:View changes

Correct instructions.

I also can't find default_avatar.png. Leftover from a previous approach?

Issue summary:View changes

Cross out now-done todo

It's "default-avatar.png", fixed typo in the issue summary.

I think may be ready. Please double check everything.

Couple of configuration comments:

Blocks 'og: New groups' and 'frontpage: Block hot' should not be shown on

Block "recent_signups: Block" should be above "Drupal events activity".

Top menu item "Events" should be first on the left.

Apart from that looking good.

Edit: updated deployment instructions with comments above

Issue summary:View changes

fixing -

Took another look at the staging site and found the following:

1. Checkbox title should be: Only events in my groupS

2. "Drupal events activity" block has no title (should be same as block name).
3rd line should probably be: "X event signupS last week"

3. Recent signups are missing starting dates below event titles

4. We need to add 1 more css rule for urls field

.view-event-list .views-field-field-url-value p {
  margin-bottom: 0.346em;

Issue summary:View changes

updating instructions

I cleaned up the deployment instructions a bit. Some of the block configuration is removed as I already took care of "og: New groups", "frontpage: Block hot", and "Post an Event link" on the live site.

I also added the missing .tpl.php files mentioned in #109.

I expect implementing changes from #114 could touch the theme and module. Please provide a patch for the theme and re-export the feature module, which includes groupsorg.module. Specifically, the "Drupal events activity" block title should be in $block['subject'] in groupsorg_event_stats_block_view().

Assigned:drumm» Unassigned

I made a fresh dev site for this,, where you can run through the deployment instructions and work on changes.

I did steps 2,5,6,7,8 of deployment instructions on events2.

Since you decided not to use /calendar url, link to Calendar on the bottom of the events page should be changed to /event.

"Modr8 moderator's block" should also be configured for not to be shown on events events/*

new408 bytes

Patch for Bluecheese for #114

1. Checkbox title should be: Only events in my groupS - in the view
2. "Drupal events activity" block has no title (should be same as block name). - added title on block configuration page
3rd line should probably be: "X event signupS last week" - in the groupsorg.module

Changed old event view to be on /calendar url instead of /event.

Issue summary:View changes

Deployment cleanup

Issue summary:View changes


new357 KB

Fixed: 3. Recent signups are missing starting dates below event titles - by adding custom date format "M j, Y H:i" and "Events signup" format type which is used by Recent signups view and was missing.

Recreated feature attached.

Issue summary:View changes


Status:Needs work» Needs review

Status:Needs review» Needs work

From IRC: it shows "Later this week" and event from July30 and then "Today" and all future events fine

I did some code cleanup, including handling more cases in views-view-field--event-list--field-start7-value.tpl.php; like "2" instead of "02" and showing the ending month or year if the date spans across multiple months or years.

Basically, the remaining problem in _groupsorg_views_events_date_group() is that it doesn't consider time zones, like views-view-field--event-list--field-start7-value.tpl.php appears to do properly. So, it doesn't have an accurate idea of what "today" is.

I also noticed that views-view--event-list--page-1.tpl.php only appears to do something special with $attachment_before, adding a "Today" header. As far as I can tell, we're handling it via the groupsorg_preprocess_views_view() and no attachments are used. So can this template be removed?

hi drumm. Yes, views-view--event-list--page-1.tpl.php can be removed. It was part of an experiment to use attachments.
do you need help in cleaning up _groupsorg_views_events_date_group()?

Without being aware of this ongoing improvements we launched the service to find Drupal events easier. Beside general great resonance by the community, calls came up like "Can we have this on g.d.o.?"

After reading through all this comments incl. referenced issues I think pretty much every kind of thinkable future feature is captured (most of it here One thing that is definitely clear: Wait for D7 upgrade (which is not far ahead) to implement the cool stuff where a lot is based on the geo-information.

So I’d like to start my help around this topic on the opposite, on the create event form, with sharing my findings after enrich and partly correct about 200 events listed on drupical.

Create Event form improvements (

  • Time: When entering time - point out that it is 24h format (or warning when entering e.g. 8:00)
    At current there are a couple of events that begin accidental in the morning.
  • Date: When a date is entered that is more than one year in the future display a warning if sure
    (e.g. is set to 2012 but was in 2011 and node was created on October 18, 2011)
  • Signup settings: Signup is enabled by default, when you disable it and click on Preview then it will be enabled again, and it is hard to recognize it as it is collapsed. (I assume it’s a D6 cck issue and is solved in D7 core field, it’s already issued here #1545852: Signup set to "no" goes back to "yes" on preview)
  • Title: Maybe provide a guideline what to cover in the event title.
    Is it necessary to include venue + full date + time? Below 2 extreme examples which also blow up the current calendar view:
    • "Boston Drupal Meetup - Roof Garden in Kendall Square - August 7, 2012 @ 6:30 pm"
    • "High Performance Drupal Meetup at Citrus Studios at the Yahoo! Center in Santa Monica on August 7, 2012"
  • Delete: Make it possible to delete self created events (some events are listed twice)
    Is there a good reason why it is not possible now?

Ok, so far my first inputs. Looking forward to discuss this topic with some of you at Drupalcon Munich! (and here as well)

Hi Michael!

You can help us right now in Commons 3 issue queue with your drupical experience: #1715132: As a community member, I'd like to browse/search events on map :)

I also mentioned your comment in a List (create) an event page in Commons 3.x interactive prototype.

Status:Needs work» Needs review

I did some work fixing this and I think is ready for review again.

Looking good. "Today" and all other headers work correctly for me.

Status:Needs review» Fixed


I'm going to clear out the dev sites so we can have a fresh start for followups, if necessary, and have space for other dev sites.

Status:Fixed» Closed (fixed)

Automatically closed -- issue fixed for 2 weeks with no activity.

Issue summary:View changes