Managing online calendars and event registration can present a huge challenge. Without a dynamic system, the task is nearly impossible. Generating the HTML required to display a calendar and all the various presentation options (day, week, month views, and so on) is unreasonable; and worse, because the events are time-sensitive, remembering to update “next” or “upcoming” event lists can be onerous. Nothing looks worse than having last week’s meeting listed first on your Upcoming Events page.
Even with dynamic systems, you tend to be constrained to certain parameters with fixed options. However, by taking advantage of the flexibility of Drupal and building on the powerful base of Views, you can accommodate nearly any variation on event listings for your site.
This chapter introduces the following modules:
- Date
Provides a field for entering date and time information, as well as libraries to handle operations like date math and time zone conversion
- Calendar
A view style for displaying a list of site content in a rich calendar display
- Flag
A flexible utility module that enables administrators to add on/off toggle switches to entities such as nodes and comments
To follow along with the hands-on example in this chapter, you should install Drupal using the Events installation profile. The completed website will look as pictured in Figure 6-1 and at http://events7.usingdrupal.com. For more information on using the book’s sample code, see the Preface.
The Aurora Book Club is a rather social group of local book enthusiasts. They hold semiregular monthly meetings and events for both current and prospective members. Members want to be able to see when and where the next meeting is happening. Additionally, members should be allowed to post their own events to the site. Events should have start and end times and dates, as well as information about the event and where it will take place. To make it easy for members to see what is happening soon, there should be a short list of upcoming events in addition to the full calendar. The calendar needs to offer day, month, and annual views, and a way for members to subscribe to the club’s calendar using Microsoft Outlook or Apple’s iCal. Finally, since the club members would like to know how many cookies to bring and how many chairs to have on hand, the club president has asked that we include a way to track who plans to attend each event.
In order to build Aurora Book Club’s site, we need to investigate two main features: event management and attendance tracking.
At one time, doing event management in Drupal meant the choice between a module called Event, which provided an out-of-the-box event handling solution with some assumptions about how that handling should work, or a combination of the Date, Calendar, and Views modules, a more flexible but also a more “elbow grease required” solution to accomplish the same thing. Nowadays, however, the choice is pretty much made for you. While the Event module was popular during the days of Drupal 5 and earlier, in later years the Drupal community has clearly clustered around the flexibility that the Field and Views modules offer, which enables site builders to tailor features to their sites’ exact needs. Too bad that those old, historical modules that no one uses anymore have claimed such great namespaces!
With the “building block” approach, the Date module will provide a date/time entry field on our events, and the Views module will provide us with event listings. And with the Calendar module layered on top of these views, we can deploy a feature-rich and filterable calendar display in a few clicks.
The Signup module is designed specifically for the purpose of tracking event attendance, and has some nice features such as the ability to email reminders to attendees prior to an event. However, this module was unavailable for Drupal 7 and was undergoing development at the time of this writing.
Instead, we will use this opportunity to highlight a helpful general-purpose module called Flag. Flag allows users to mark or “flag” a piece of content. This functionality can be used for a myriad of useful purposes, including marking content as offensive, allowing users to bookmark interesting stories, and even letting users mark events as “attending” or “not attending.”
First, we’ll set up a few basics for our site just using Drupal core. The main thing that we need to start is a content type to handle our events. Log into the Aurora Book Club site with the username admin, password oreilly, if you are using the installation profile.
We’ll start by creating a new, basic content type just for events. We just need the event name and description along with an easy way to add the event location. We won’t promote it to the front page, as we want more control over the display of events in our forthcoming calendar. We will, however, leave comments enabled, for more of a “social” vibe for the site.
In the administrative toolbar, go to Structure→“Content types” (admin/structure/types) and select “Add content type” (admin/structure/types/add) to create a new content type called Event, using the settings from Table 6-1.
When finished, click the “Save and add fields” button.
Now, add a text field to store the location of the event (that is, where the event takes place). At the event field listing page (admin/structure/types/manage/event/fields), complete the “Add new field” form using the values from Table 6-2.
Click Save. This will take us to the configuration settings page for the Location field. We will just use the default settings here, so click the “Save field settings” button, and then “Save settings” on the following form, to finish.
Now that we’ve got the content type created and configured properly, we need to grant permissions to our members to allow them to create events.
In the administrative toolbar, go to People→Permissions (admin/people/permissions) and set the permissions as shown in Table 6-3. Click the “Save permissions” button when you are done.
The main building block for the site is our new Event content type. The information that we need it to provide us with is “where” and “when.” We have taken care of the “where” part in our initial setup. The Date module helps us effectively answer the “when” question, in an incredibly flexible manner.
As mentioned previously, our real interest in the Date module is the ability to add a field to our Event content type to indicate date and time. However, looking at the Date module more closely, there are a few extra pieces worth noting.
A core requirement of all modules in the Date package is the Date API module. The Date API module provides a set of underlying functionality for date handling. These functions consist of things like utility functions for generating month and day names, converting between date formats, and even generating date input select boxes. Though covering the full extent of the API is outside the scope of this chapter, it is worth noting that any module in Drupal that performs any sort of date handling or manipulation could take advantage of this module.
The Date module also ships with modules to extend a basic date field functionality, like Date All Day, which lets you specify that an event happens for an entire day, or Date Repeat, which offers support for repeating dates, so you can schedule recurring events (weekly, every third Monday, etc.).
Date Tools is a utility module in the package. It sports a Date Wizard, which can autocreate a content type, date field, view, and calendar from a form you fill out. Once you’ve read this chapter and understand how the underlying mechanics work, this feature can be useful for shortcutting future site buildouts. The Date Tools module also provides conversion tools that can change your data from one type of date field to another, and import tools that can help migrate data from the legacy Event module to date fields.
Finally, the Date module offers integration with other contributed modules through the Date Context, Date Migration, and Date Views modules, which expose date field data to the Context (http://drupal.org/project/context), Migrate (http://drupal.org/project/migrate), and Views modules (http://drupal.org/project/views), respectively.
At its most basic level, the Date module itself defines three field types for adding date fields to content types, depending on how you care to represent them. The differences among these fields are summarized in Table 6-4.
Table 6-4. Fields offered by the Date module
Name | Description | Example | Database storage |
|---|---|---|---|
| Date | Date field types are stored using the database system’s internal “datetime” format for date handling. It has the advantage of being able to use database-specific functions for date handling, including ease of extracting a single part of the date, but with the caveat of inconsistent support across database systems. | 2012-02-24 01:28:00 | datetime |
Date (ISO format) | Store a date in the database as an ISO8601 date, used for historical (pre-1000 A.D.) or partial dates (for example, only a year and no day or month). This field type should be avoided otherwise, as it’s extremely expensive to sort and perform conversions on this style of date. | 2012-02-24T01:28:00 | varchar(20) |
Date (Unix timestamp) | Datestamp field types are stored using the common Unix timestamp format containing the number of seconds since January 1, 1970. As such, these have a limited date range available (1901 A.D.–2038 A.D. on most systems) but are quick to calculate time zone offsets and sort in listings. A legacy format that is supported across all database systems. | 1330075725 | int(11) |
Warning
For much, much more than you ever wanted to know about the pros and cons of various date storage formats, there’s an interesting discussion on the Events working group at http://groups.drupal.org/node/731.
Because the Aurora Book Club has no intention of moving from MySQL, and all dates will be well within “normal” ranges, we will be using the standard Date field type for our site.
In addition to the base field types, the Date module also defines three form elements for entering date information, which are pictured in Figure 6-2:
- Select list
Presents a series of drop-down lists for each of year, month, day, hour, minute, and second, based on the configured granularity for the date field defined by the data settings.
- Text field
Provides a simple text field for date entry that will then be converted to the appropriate storage format. The advantage of this widget is that it lets advanced users enter dates much faster. However, for the uninitiated, it can be frustrating if your natural date entry format is not properly recognized.
- Pop-up calendar
Adds an elegant, user-friendly option for date value entry. This widget uses JavaScript to present a calendar pop up when a user clicks in the date text field. The user can then click the date on the calendar to select the date that he wants.
If the Date Repeat Field module is enabled, you will also see an extra option for each element to add it with “Repeat options.” This will add another fieldset below the form element, where you may configure it as a recurring event, as shown in Figure 6-3.
Here, you may specify the frequency with which an event should recur: for example, every week, the first Monday of the month, or daily except for statutory holidays. Rather than making a separate Event node for each repetition of the event, which would get costly in terms of data storage (not to mention annoying to update if a title or description needed changing), Date Repeat Field stores the repetition patterns in a format called RRULE from the iCalendar specification. The Calendar module can then read these rules and display the events as intended, as well as generate feeds for easy import into other calendar applications such as iCal or Outlook.
For Aurora Book Club’s purposes, meetings aren’t predictable enough to make them repeating events. However, the “Pop-up calendar” form element offers improved usability for date selection, so we will incorporate it into our site.
There are quite a few settings available specific to date fields and different from other field types, as shown in Figures 6-4 and 6-5.
- Date attributes to collect
This setting dictates how much information will be retained about the dates supplied. The check boxes for Year, Month, Day, Hour, Minute, and Second can be selected independently to provide extreme flexibility. For instance, if we wanted someone’s birthday (but not a full birth date), we could select only Month and Day like “July 10.” For the purpose of event management, the default selection of Year, Month, Day, Hour, Minute is suitable, which allows us to display the date like July 10, 2008 - 7:30.
Note that this setting will impact the date entry widget, in that only the appropriate options will be displayed.
- Collect an end date
Optionally, you can specify an end date for a given date, which we’ll want to do for Aurora Book Club since we’re tracking events and when they begin and end. However, for fields such as birthday, this setting would remain off.
- Time zone handling
The time zone handling settings allow us to configure how time zones should affect the stored date values and whether conversions should be performed. The options are described in Table 6-5.
Table 6-5. Date field time zone options
Option
Description
Site’s time zone
The time zone specified for the entire site, specified in the administrative toolbar at Configuration→“Regional and language”→Regional Settings (admin/config/regional/settings). Useful for making sure each date field shares a consistent time throughout the site, even if users are from different time zones.
Date’s time zone
Adds a “Time zone” drop-down next to the date widget to specify the time zone for the date. Useful for sites where many users from many different time zones will be creating events across the globe.
User’s time zone
The time zone specified in each user’s account settings (if the “Users may set their own time zone” option is enabled under Configuration→“Regional and language”→Regional Settings (admin/config/regional/settings). This option is useful if you mainly have events in one time zone, but users from many different places, and want to ensure the start time always appears correct for your visitors.
UTC
Coordinated Universal Time (UTC), which is informally equivalent to GMT. This is a standard time zone that is the same across all systems.
No time zone conversion
For events with dates only, rather than dates and times, or for sites with both local events and users. This option performs no time zone conversions on the date.
For the book club, we will not have to worry about doing time zone conversions, as all members will be local.
Warning
You should set this time zone handling value with care, especially when dealing with international events posted to an international audience. The last thing you want is for your band’s rock concert to show up on the wrong day of the week if it’s viewed by a reader a few time zones away from you!
- Repeating date
With the optional Date Repeat Field module enabled, you can specify a particular date field to allow repeating events.
- Cache dates
If you’re using date fields that can accept multiple or repeating values, this advanced setting can speed things up by precaching them for quicker retrieval. For single date values, it has no effect. If you’re not actively experiencing date-related performance problems—such as with the Full Calendar module—leave this unchecked.
- Date entry options
The “Date entry options” setting allows us to configure the format that will be used when displaying the date value. A variety of international formats are supported. There is also a “Custom format” option for the “Select list” and “Text field” widgets, which allows an arbitrary date format to be used for ultimate flexibility. The custom format is set using PHP’s
date()formatting syntax (http://php.net/date).- Starting year/Ending year
This setting gives us control over how many years will be listed in the widget for a user to select from. If the current year is 2012, you can allow people to choose between 2009 (−3 years) and 2015 (+3). For our event site, there is probably little point in using a wide range here, particularly to allow support for events in the distant past. However, for something like a birthday field, this can be handy to ensure validity of values.
- Time increments
The “Time increments” setting allows us to constrain the granularity of minutes stored in a date field. By default, minutes may be entered in 15-minute increments, which only exposes minute selections of 00, 15, 30, and 45.
- Display all day
If you’re using the Date All Day module, this checkbox will appear, which lets you expose an “All day” selection on the date widget.
- Position of date part labels
With this advanced setting, you can customize where you would like to display the label in relation to its field: above the field, within the field (either as an option in a select list or inserted inside a text field), or not at all.
The “Select list” widget has a few more options. Despite its name, we can actually have text field entry for certain values in the date, mixing drop-downs and text fields. For instance, rather than having a select list of 31 days, we could set Day to be a text field input, in which case Drupal will render the input as select lists for year and month with a small text field for day. This option again allows us full control over the widget and a chance to select the interface that’s easiest to use for our target audience.
- Default values
The “Default values” setting specifies what value the field starts with when presented to the user. The “No default value” and Now settings are pretty straightforward. Relative will let you set the default to a date that is relative to the current time, such as two days from now. To set up a relative default, you must enter a value in Customize Default Value that uses PHP’s
strtotime()syntax, such as +2 days. You can find out more aboutstrtotime()at http://www.php.net/manual/en/function.strtotime.php.
As you can see, the Date module offers options for nearly any date entry use case that you can imagine!
In this section, we will enhance our basic Event content type by adding a date field, so that members may schedule meetings.
In the administrative toolbar, click on Modules (admin/modules) and enable the following modules:
Date/Time package
Date
Date API
Date Popup
Next, go to Structure→“Content types” (admin/structure/types) and click the “manage fields” link for the Event content type (admin/structure/types/manage/event/fields). Complete the “New field” form with the values in Table 6-6. As noted earlier, the Date field type is most appropriate for our site, since it is more performant than ISO dates, and our date values will remain within “normal” ranges.
Click Save. This brings us first to the field settings page for our new Time field. It’s worth taking a moment to discuss the available options and why we’re choosing the ones that we are:
The “Date attributes to collect” setting dictates which fields will appear in the form. Because it’s pretty unusual to schedule events down to the second, we will go for just Year, Month, Day, Hour, and Minute granularity (the default).
Most meetings will happen over a range of time; for example, 12pm to 2pm on August 29. As a result, we want to check the “Collect an end date” option to add a second field to any date field for exactly this purpose. However, for the odd day-long event, such as April 16, National Librarian Day, we want to make specifying the “to date” optional.
For “Time zone handling,” because the Aurora Book Club is a local book club with all members in the same region, there is no reason to factor time zones into the meeting events. Therefore, we will set this value to “No timezone conversion.”
Enter the values in Table 6-7, and click the “Save field settings” button to complete adding the configuration.
On the second settings form we can use most of the defaults. Change the field values as shown in Table 6-8.
Click “Save settings,” to return to the “Manage fields” tab (admin/structure/types/manage/event/fields). Reorder the fields as follows and click Save:
Name
Time
Location
Body
With the content type fully created, our members can now post events to the site! To try it out, go to “Add content”→Event (node/add/event) and complete the form with the settings in Table 6-9, then click Save. If all has gone well, you should see something like the page in Figure 6-6. Go ahead and create a few more events for the Aurora Book Club.
Now that we’ve created our Event content type and started populating some content, it’s clear that we need to add in a way to access all our event data. For part of the book club’s requirements, we need an Upcoming Events listing that will allow members to quickly see the meetings happening in the coming days or weeks. To achieve this, we will use the Views module to create our block. Keep in mind that when building views of event data, we generally want to do our sorting or our limiting on the new date field we added, not the content’s created or updated time, as we normally do.
We will create a simple block view of published events where the event’s time field is in the future. In terms of the views configuration, having a date value “greater than now” represents dates “in the future.” Finally, the view will be sorted in chronological (or ascending) order of the event’s date (not the event posting’s created date). When completed, this section will look as pictured in Figure 6-7. Clicking the event name link in the block will take you to the full information.
In the administrative toolbar, click Modules (admin/modules) and enable the following modules:
Chaos Tool Suite package
Chaos tools
Date/Time package
Date Views
Other package
Advanced help
Views package
Views
Views UI
Once the modules are enabled, go to Structure→Views (admin/structure/views) and click “Add new view” (admin/structure/views/add).
Fill out the view form using the values in Table 6-10.
Table 6-10. The Upcoming Events view configuration values
View setting
Value
View name
Upcoming Events
Description
Checked; “A block list of upcoming events”
Show Content of type Event sorted by Newest first Create a page
Unchecked
Create a block
Checked
Block settings Block title Upcoming Events (default) Display format
HTML list of titles (linked)
Items per page
5 (default)
Clicking the “Continue & edit” button places us in the full Views interface with our basic view built. From here, we can customize our view.
First, we will add our time field to our view. In the Fields section, click the “add” button, and select the “Content: Time” field. Click the “Apply (all displays)” button, then uncheck the “Create a label” box to remove an unnecessary “Time:” label on each entry. Click the “Apply (all displays)” button to save the field.
Next, we’ll use our time field to only show future events. Date handles this slightly oddly compared to other modules, with a single filter for all date fields that can then be more specifically configured. In the Filter criteria section, click the “add” button, and select “Date: Date (node).” Click the “Apply (all displays)” button to save, and then choose the “Content: Time (field_time)” field as the “Date fields” value on the next screen.
Click “Apply and continue” to configure the filter. Under “Operator,” choose “Is greater than or equal to,” and change the “Select a date” field to “Enter a relative date,” and type
now. This is a relative value that will be constantly updated so our site will never show stale events in the Upcoming Events sidebar. Cool! When you’re finished, click the “Apply (all displays)” button.Now we will sort our events by the event date (not the date the content was created). In the “Sort criteria” section, click the “add” button, select “Content: Time - start date (field_time)” and click the “Apply (all displays)” button to save. On the next screen, make sure the “Sort ascending” setting is selected and click the “Apply (all displays)” button again.
We should also remove the old post date sort, which is no longer needed. Under “Sort criteria,” click the “Content: Post date (desc)” link and click the Remove button.
Save the view, which should now look like Figure 6-8.
Because we created a block view, we should see no change to our site until we enable the block that we’ve created. To do this, go to Structure→Blocks (admin/structure/block). Drag the “View: Upcoming Events” row to the “Left sidebar” region (or simply change the region value in the drop-down) and click “Save blocks.”
If you close the Overlay, you should now see a sidebar block on the left side of the page with your new Upcoming Events block, as pictured back in Figure 6-7!
Although a simple list of upcoming events is very useful (particularly in a sidebar block), the book club has additional requirements for the display of the event data. As is extremely common for event management websites, this site needs an interactive calendar for browsing through past and future events. We will implement this feature using the Calendar module in conjunction with Views.
The Calendar module provides a new view type that shows the results of a view in a calendar rather than a list or table as with the default view types. Figure 6-9 shows the list of Drupal community events from http://groups.drupal.org/events, which also uses the Calendar module. Because Calendar builds on top of Views, all the standard Views tricks work to enhance a calendar, such as exposing filters for “Event type” as groups.drupal.org does.
The Calendar view type is one of the more complicated ones available. It provides full day, week, month, and year views of the event data on our site, with lots of links between views and paging through days, months, and years. To achieve this rich functionality, Calendar requires certain views arguments to exist, and to be ordered and configured in a certain way.
The Calendar view type then determines which view the user would like to see based on the arguments that exist. For example, if our view URL is calendar, the Calendar view will handle the paths described in Table 6-11.
In addition to creating a nice online calendar, the Calendar module can handle the need for book club members to be able to update their desktop calendars (in Microsoft Outlook or Apple’s iCal) with the event information from the book club site. To do this, the desktop applications use a standardized format known as iCalendar, or iCal for short. Calendar comes with the Calendar iCal module, which allows us to easily provide this format for the interested members.
Figure 6-10 shows the groups.drupal.org events calendar after being imported from http://groups.drupal.org/ical to the Apple iCal desktop application.
In this section, we’ll be enabling the Calendar view of book club events. Although this is potentially a daunting task, the Calendar module conveniently comes with a default view that handles most of the difficult bits for us. In this section, we’ll alter that default calendar view to fit our requirements.
Figure 6-11 shows the finished Aurora Book Club calendar. Note the small iCal icon in the bottom-right corner. Clicking this link will download the calendar to an appropriate desktop application.
In the administrative toolbar, click Modules (admin/modules) and enable the following modules:
Date/Time package
Calendar
Calendar iCal
Go to Structure→Views (admin/structure/views). You should now see “calendar” listed and enabled by default.
Click the arrow next to the “edit” button in the Operations column next to the view, and choose “clone” in order to make your own version of it (admin/structure/views/view/calendar/clone). Give it a name of Aurora Calendar.
First, let’s tell it to only show Event content in the calendar. Do this by clicking the “add” button in the Filters section, and selecting “Content: Type.” Click “Apply (all displays),” then check the box under “Content types for Event,” and click “Apply (all displays)” once more.
By default, the Calendar view uses the date the node was last changed to place events on the calendar, but we want to use the time of the event instead. Under the Advanced section on the right, in the “Contextual filters” section, click on the “Date: Date (node)” link. Scroll down to the “Date field(s)” field, uncheck “Content: Updated date,” and check “Content: Time - start date (field_time)” instead. Then click “Apply (all displays).”
We need to make a similar adjustment for fields. In the Fields section, add the “Content: Time” field and uncheck the “Create a Label” box, as we did with the event block. Then, remove the “Content: Updated date” field by clicking on it and then the Remove button. This will show our event’s date, rather than the node’s last updated date, in the view.
As a minor cosmetic item, note that the current title of the view in preview is “calendar.” Let’s change that to “Aurora Book Club’s Calendar of Events” by clicking on the “title” link in the Title section and changing it. Click “Apply (all displays)” when finished.
Finally, we should add an entry to the main menu so visitors can find the calendar page. The default view already provides us with a path of “calendar,” which makes sense for us to keep. To add this to the menu link, edit the “Page settings” section according to Table 6-12. Click Apply after you enter the menu settings.
Save the view, which should look like Figure 6-12.
Now we have a working events calendar that users can reach by clicking on the “Events calendar” link in the main menu navigation. Next, we need a way for club members to sign up for these events.
The Flag module is an incredibly flexible module that allows you to create relationships between users and content on your site. After you create a flag, an item can be marked with it a few different ways, including links displayed below content, as shown in Figure 6-13, or checkboxes displayed on the edit form, as shown in Figure 6-14.
Upon installation, the Flag module defines a “bookmark” relationship, allowing users to maintain a list of bookmarks (or posts they find interesting) on the site. However, this default behavior only touches the surface of the Flag module’s flexibility. Some possible uses for Flag include:
A “favorite” or “bookmark” flag to mark content
A “promote” flag (or many different promote flags) that is similar to the default “Promote to Frontpage” checkbox
An “offensive” flag for comments or nodes
A “friend” flag that allows users to mark other users as friends
As you can see, there are a variety of uses for flagging content. After creating a flag for some purpose, you can construct views that create lists of content that has been flagged by users. We’ll use this functionality to let users indicate whether they plan to attend a book club event. Once the flag relationships are created, we can create a view to list the attendees of a particular event.
The Flag module offers an incredible array of flexible options, detailed as follows:
- Flag type
Each flag can be associated with a particular type of entity: nodes, comments, or users. This makes the Flag module a versatile tool that can be applied to many different situations, from bookmarking pieces of content to marking comments as abusive to establishing relationships between users.
- Global flag
By default, flags are per user; for example, each user can have a separate list of items that she’s flagged as her favorite. If the “Global flag” option is selected, however, the flag becomes a binary yes or no, associated with the piece of content directly. This setting is useful for setting up a “Featured content” flag, where a piece of content either is, or is not, featured across the entire site.
- Messages settings
The Flag messages settings, shown in Figure 6-15, allow fine-grained control over all text related to the flag: the link text and description for flagging and unflagging content, and the confirmation messages shown to users who interact with the flag.
- Flag access
The Flag access settings, as illustrated in Figure 6-16, allow you to set which role or roles may set or unset a flag. This allows you to specify that only editors may mark a piece of content as “Featured content,” or that normal authenticated users may Like, but not Un-Like, content. Additional restrictions follow, which vary depending on the type of flag, to dictate whether or not users can only flag their own content (or themselves, in the case of a user flag). For example, it probably doesn’t make sense for users to be able to flag their own content as “Best of site.” Finally, for comment and node flags, in this section you can choose which content types are flaggable.
- Display options
Finally, you can choose how the flag should be displayed in the UI, as shown in Figure 6-17. Choose any combination of options for how flags should appear: a checkbox on the content edit form, links shown in the teaser view or full page of a node, or on a user profile. The Flag module even allows you to choose how the link represents itself when output, for ultimate control over your site’s user experience. Select from a JavaScript toggle that can turn the flag on and off without a page refresh, a standard link, or even a confirmation form (which, naturally, has configurable confirmation and unconfirmation text settings).
The Flag module also ships with the Flag Actions module, which allows you to associate one or more system tasks (publish or unpublish content, send an email, and so on) to take place when a flag is used. Flexible options exist for performing actions only after a flag has hit a certain threshold (for example, once five users have flagged something as “abusive”), and also to repeat the action every n times that this threshold is reached.
Figure 6-18 shows the Flag Actions module in action. Here, we’ve added a custom action to the Bookmarks flag so that once 10 or more people have flagged it as a favorite, the content will automatically get promoted to the front page. This is a useful way to involve your community in deciding what content is interesting and relevant on your website.
In this section, we will configure the Flag module to allow our users to indicate that they are attending our events, as pictured in Figure 6-19:
In the administrative toolbar, go to Modules (admin/modules) and enable the “Flags package: Flag” module.
Now go to Structure→Flags (admin/structure/flags) to manage the defined flags. By default, the Flag module defines a Bookmarks flag when installed. We can either add a new flag or edit the default one to suit our purpose. As we won’t be using Bookmarks on this site, we’re going to edit the default. Click the “edit” link next to the bookmark flag (admin/structure/flags/edit/bookmarks). Fill out the form according to Table 6-13.
Table 6-13. Attendance flag configuration
Field
Value
Name
attendance
Title
Attendance
Global flag Unchecked (default) Messages Flag link text
attend this event
Flag link description
Attend this event
Flagged message
You are attending this event
Unflag link text
cancel attendance
Unflag link description
Cancel attendance to this event
Unflagged message
You are no longer attending this event
Flag access Flag access Flag and Unflag both checked for authenticated user (default) Unflag not allowed text (leave blank - default) Flag access by content authorship No additional restrictions (default) Flaggable content Article: Unchecked, Event: Checked Display options Display link on node teaser Unchecked
Display link on node page Checked (default) Display check box on node edit form Unchecked Link type JavaScript toggle Clicking Submit will create our attendance flag. We can now go to any events that we previously created and click the “attend this event” link.
The book club would like users to see a list of who will be attending each event. For this, we will need to create a new view, pictured in Figure 6-20.
In the administrative toolbar, go to Structure→Views and click on the “Add new view” link (admin/structure/views/add).
Complete the form according to Table 6-14 and then click the “Continue & edit” button.
The first thing we need is a relationship to give us access to the flag information related to our users in our view. Open the Advanced section, and click the “add” button in the Relationships section. Check the “Flags: User’s flagged content” relationship and click “Apply (all displays).” Complete the relationship settings based on Table 6-15 and click “Apply (all displays)” once more.
We want our view to show the users who have flagged a given Event node; therefore, we need to add a contextual filter for the Node ID that was flagged. To do this, we click the “add” button for “Contextual filters.” Check the “Flags: Content ID” argument and click “Apply (all displays).” We only want this list to appear for Event nodes, so we need to limit when this contextual filter is used. Configure the filter as shown in Table 6-16, then click Apply.
Table 6-16. Settings for the Flags contextual filter
Advanced: Contextual filter
Value
When the filter value IS NOT in the URL Display contents of “No results found” When the filter value IS in the URL or a default is provided Specify validation criteria : Checked
Validator: Content
Content Types: Event: Checked
Let’s add the aforementioned “no results found” text by clicking the “add” button in the No Results Behavior section on the right. Check “Global: Text area” and click “Apply (all displays).” Give it a label of “No attendees” and fill out the text field with “No attendees for this event yet.” Then, click “Apply (all displays).” Now when we click on an event with no signups yet, it will show this text instead of a blank page.
It would be helpful if the attendees were listed in an ordered list so that we could quickly glance at the total number of people attending. To add this functionality, we need to change the style of the view. Click the Settings link for “Format: HTML list” and set the “List type” field to “Ordered list.” Click “Apply (all displays)” to save the change.
To complete the view, we need to add the display as a tab on the event node. Complete the View Page settings according to Table 6-17.
Save the view, which should look like Figure 6-21.
Now, when you visit an Event post, you should see an Attendees tab. Clicking on that tab will display a list of all of the users who have said they will attend the event.
The site we have built covers all of the needs for the club. Down the road, the members may want to spruce things up a bit. Here are a few modules that could round out the site even more:
- Full Calendar
An alternative to the Calendar module that provides a JavaScript-based drag-and-drop calendar through an alternate Views format.
- Countdown
This module adds a block that shows the time left until an event. This is a nice way to let people quickly know that the next meeting is in four days or four hours.
- Flag Actions (part of the Flag module)
The Flag module can be set up to send emails, and to unpublish or delete nodes upon reaching certain flagging thresholds. Although this feature is most commonly used for things like community flagging of spam or offensive content, it can also be used to notify someone by email if, say, more than 10 people will be coming to an event and a second person needs to be asked to supply refreshments.
- OpenLayers
Instead of just typing a location in a text field, you can use the OpenLayers module to let people use a map to select the location for each event, and view a map containing all events across the city.
In this chapter, we have looked at building an event management site for the Aurora Book Club, making use of the Date field, the Calendar plug-in for Views, and the Flag module for handling attendance. The book club now has a handy calendar that is displayed on the site and available in iCal format. They also have an easy-to-find list of all the attendees. The site is simple and easy to use, yet fits all of the club’s needs quite nicely.
Here are all the modules we referenced in this chapter:
Additional resources: