35 - An Alternate Staff Directory Using the ExpressionEngine Member Management Module
In the last post I outlined the advantages and disadvantages of building a church Staff Directory using either ExpressionEngine‘s built in Member Management Module or another weblog. While I chose the weblog approach for my sample site, I thought I would build out an alternate version using the Member Management Approach in case that would also be valuable.
Query Module Required
This build approach does require the query module, which is not available in the Core version of EE.
Overall Build Approach
At a high level the build approach here is the same - I need to create structures to hold content, then do some content entry, then code some templates to draw that content out. The difference with this approach is that the structures that hold the content are a new member group and some member profiles, vs. a weblog and weblog posts like in the previous build.
Create a New Member Group
I created a new member group called “Staff”. I configured it such that the group would have access to the Control Panel (so that staffers would be able to login and maintain their profile via the “My Account” tab) but locked down everything else - no access to any other area.
Created Custom Profile Field
I noted that the default profile fields don’t include one for a phone number, so I had to add a custom profile field. This can be done in the CP under:
Admin › Members and Groups › Custom Profile Fields
I added a field with the following name, display name, type, and formatting:
phone, Phone, Text Input, formatting=None
I also set “Visible in Registration Page” to Yes, so that when new staffers join the church they could use EE’s default new member registration page (see the docs for how to link to that registration form) and be able to fill in the phone number on it.
Member Image Configuration
I need two images for this design - a thumbnail for the index page and a bigger image for the profile page. I decided to use EE’s avatar spot for the thumbnail, and the member photo for the larger one. An alternative would be to use only the member photo, and then use the Image Sizer plugin for the smaller one. Make sure both avatars and member photos are enabled, paths are correct, and size limits will work in the design. These settings are configured under:
Admin › Members and Groups › Membership Preferences › Avatar Preferences and
Admin › Members and Groups › Membership Preferences › Member Photo Preferences
Member Registration
I then registered Members into the New Staff Group using the Control Panel Form. Once the basics were in I edited each members profile to add their title (in the occupation field), bio, phone number fields, and both images.
Staff-Directory/Alternate-Index Template
As usual I’ll include the complete templates in the companion files - let’s just look at the core code here:
{exp:query sql="SELECT member_id FROM exp_members WHERE group_id = '8'"}
{exp:member:custom_profile_data member_id="{member_id}"}
{!--The switch variable handles applying the required different css to every other entry --}
<div class="{switch="staffBorder rtMargin|staffBorder"}">
<a href="{path='staff-directory/alternate-profile'}{member_id}/"><img src="{avatar_url}" width="{avatar_width}" height="{avatar_height}" alt="{screen_name}'s avatar" /></a>
<h4><a href="{path='staff-directory/alternate-profile'}{member_id}/">{screen_name}</a></h4><br />
<p><em>{occupation}</em></p>
<p>{phone}<br />
{email}<br /></p>
</div>
{/exp:member:custom_profile_data}
{/exp:query}
OK - so there are a couple of things new to this series going on here.
Query Module
The first is the use of the Query Module. The query module is handy for retrieving data from EE’s database when the built-in tags don’t do what you need. You will need to know how to write SQL statements - which could be a whole series of tutorials in itself.
Custom Profile Data Tag
The reason I needed the Query Module here was due to a limitation of the next tag - the Custom Profile Data tag.
The Custom Profile Data tag will accept a member_id as a parameter, but it’s not a looping tag. I can’t even give it multiple member_id’s in a piped list (at least not according to the documentation). So - In order to make a loop I nested the Custom Profile Data tag in the Query tag. The Query tag provides the looping, and feeds the Custom Profile Data tag the member_id.
Note that the switch variable is still available within the Query tag - handy here as the classes need to alternate to get our layout correct.
Now - on the single entry page showing the content for a specific member, I’ll also need to feed a member_id to the Custom Profile Data tag. To do that I appended member_id to the end of the link. This will put the member id in the URL, where on the single entry template I’ll be able to grab it using a segment variable.
Staff-Directory/Alternate-Profile Template
In this template the Custom Profile Data tag is used 3 times - once for the page title, once for the sidebar contact info, and once for the main content. I’ll just cover the main content area tag pair below - so you can see how the segment variable comes into play:
<h2>Staff Profile</h2>
<div class="content_page_right">
{exp:member:custom_profile_data member_id="{segment_3}"}
<div class="post">
<h3>{screen_name}</h3>
<img class="ministry_photo" src="{photo_url}" width="{photo_width}" height="{photo_height}" alt="{screen_name}'s photo" />
{bio}
</div>
{/exp:member:custom_profile_data}
</div>
Again - I forced the member_id into the link on the index template, so when one of those links is followed the member_id is put into the 3rd segment location in the URL. That allows me, on this template, to now grab that value using a segment variable and feed it to the Custom Profile Data tag as a parameter.
The Results
Here is the Alternate Version of the Staff Directory. It should playout on the public side of the site looking exactly the same as the weblog-based version.
Which is Better?
So having now seen how this version went together you might be asking which I think is better. There isn’t honestly a clear answer - it’s going to depend on the larger picture of the specific site you are building. This approach would put the ability and responsibility of profile maintenance on the shoulders of the staff members themselves (which may or may not be a good idea). If these staffers are also posting blog entries or participating in the Forums then this content would also be easily usable in those contexts, so centralizing it would be nice.
But I do also lose a nice URL for the profile pages, having a member id rather than name, and I also lose the ability to easily tie together staff members with audio messages using weblog relationships., so I think for my project I still prefer the weblog-based approach, but it was a nice challenge to also build it out this way for comparison.
Category Navigation
