Well - at least it will be traditional in the sense that there will be four days spent in a classroom learning EE hands-on from an experienced professional, with the ability to ask questions and interact with others in the room.

That’s where any similarity to off-site training you’ve had in the past will (hopefully) end. 

The first difference is the location.  This class will be held in a vacation destination - a scenic resort town nestled close to Lake Michigan and renowned for it’s beautiful sunsets, clean beaches, bikepaths and an historic downtown with home-town coffee shops and microbreweries.

The second difference is the venue.  We’ve all suffered through training in an instantly forgettable generic space.  Learn ExpressionEngine in a brand-new, funky, hip and green hotel located within walking distance of restaurants and shopping.

The third difference is the after-hours activities.  Rather than leaving you to while away the evenings alone in your hotel room, we’re planning a number of events to get you out to experience the area and hang out with the others in the class.

For more information on the location, venue, course content, and schedule/cost please visit the new classroom section here on Train-ee.com.

If you have any questions not answered by that page please feel free to contact me directly via either Train-ee or Boyink.com

Sign up now - the conference room is only so big!

First, an Editorial Decision
As the template came designed it had left-column space for an event title, short description and an image.  While this is certainly do-able with EE, I’ve decided to eliminate the image.

Why?

Well - past experience.

If I implement an image for events here’s what will happen: the person wanting to get the event posted on the site won’t have an image available, or it will be the wrong size and format, or they will provide a cheesy clip art or Microsoft Word Art abomination that will do nothing but distract from the overall site look and feel.  I’m not sure what it is about the church environment that engenders this sort of “creativity;” but, if I never see a church bulletin or website filled with poor-quality squished and stretched words running in all different directions on the page, it’ll be too soon.

Actually - I’ve already created the opportunity for this situation on the ministry detail pages by allowing images there. For that matter any time a content administrator is allowed in to the EE Control Panel to enter text they’ll usually be able to upload images as well.

Tip: Create Guidelines
Put together some editorial guidelines for the site and go over them with each content contributor.  Schedule regular meetings if need be.  Do whatever it takes to communicate to this group that the intent of the website is to tell the church story, and the God story, in a professional manner to visitors.  Part of doing the job in a high-quality way is to not use low-quality graphics that come out of tools like Microsoft Word. 

If your church is large enough I’d recommend appointing a graphic designer - someone the others can go to when they need some sort of imagery.  The goals here are graphics that are high quality, consistent, and inline with the overall site design.  Also appoint a site editor - someone who has the authority to say “no, sorry” to a cruddy graphic. Think of this person as a gardener - someone with a loving vision for this space but willing to pull weeds, pinch dead leaves, and prune growth that’s heading in the wrong direction.

It won’t be an easy chore - in many churches the leaders of individual departments or ministries are used to generating their own marketing materials and doing so without any kind of guidelines or approval processes.  The results, however, speak for themselves.  Walk through the entryway of many churches and pick up a sample of all the different pieces of literature being set out - and you’ll probably find there is no consistency in colors/fonts/logo treatment, etc.  I’ve seen cases where the church name wasn’t even consistently used.  Church websites are typically no different.  Do what you can to change that.

OK - enough of Mike’s ranting.

Overall Approach

• Update embeds/events to replace static content with EE code to pull events dynamically
• Update site/index to replace mission statement with EE code to pull weblog entries

Updating embeds/events
First - remember that I created an embedded template from this code in case I wanted to use it multiple times across the site.  I’m still uncertain if that will happen - so for now I’ll leave it embedded.  If it ends up only being used on the home page I’ll just move the code back to live in site/index again.

Here is the new code -

Let’s tackle the weblog:entries tag first.  After specifying the events weblog I have it limited to only showing 5 entries.  This might change depending on how the home page progresses - I’ll show more or fewer events in order to keep the design holding together.

After that is the disable parameter - always a good idea to turn things off that you don’t need for performance reasons.

The dynamic="off" ensures that this tag won’t try to read anything from the URL.  The URL for the home page should never contain a url_title that would confuse this tag, but again it’s just a good habit to get into.

Skipping the start_on for the moment, the show_future_entries is required here; otherwise only events from today and older will show.

Events are sorted “asc” in order to get the one happening soonest to be first.

OK - now back to that start_on parameter.  This might be flogging the obvious, but I don’t want to show any past events.  I want them to drop off the home page as soon as they pass.  In order to achieve that, I can use the start_on parameter.  However, this can’t be a fixed date, it has to be a rolling start date such that it’s always starting on the current date.  In order to do that the current_time global variable is used as a value for the parameter.  Note that code is straight from the EE Docs.

With the weblog:entries tag now configured let’s move on.  The h4 tags are straightforward - just displaying the entry title and date/time using some date formatting.

Next up is displaying the event details, and this is where I’ve used some plugins.

What’s a Plugin?
ExpressionEngine was designed to be modular, which would allow both EllisLab and 3rd parties to extend its functionality in different ways.  There are basically three different ways to add functionality to ExpressionEngine - plugins, modules, or extensions.  What’s the difference?  The EE KnowledgeBase has this to say:

Plugins are small run-time enhancements. They are simple to create and free to be distributed. The plugin architecture is designed to enable you to affect the output of ExpressionEngine in a wide variety of ways.

Modules are larger systems that can be integrated into the ExpressionEngine control panel. Almost anything that can be achieved as a stand-alone application can be designed as an ExpressionEngine module.

Extensions are “hooks” in the system that allow you to pass information and add functionality to existing interfaces (like the Publish page for example).

So - why plugins here?

In short - to get EE to return weblog contents in a form that the template was designed around.

Here is the event code coming into this chapter:

I’ve dropped the image, which would leave:

The h4 tag is being filled with the title and date code, so that’s set.  This leaves the description blurb:

There are two constraints with this code.  First is the length - if I plug the event_description field in directly, the events area would quickly trash our home page design because the event_description will likely have multiple paragraphs of text (and possibly images).

Second, this code is not marked up with paragraph tags, and the event_description field is set to a format of “XHTML”, which means its content will be returned marked up paragraph tags.

What to do?

One solution would be to create a custom field just for this purpose.  You could limit its length and set the formatting to “none” and be done.  However, that creates another chunk of content that has to be created and entered for each event, and I like to reuse content where possible.

So - it’s plugins to the rescue. If you are new to using plugins, you can get an overview of them in the documentation.  There is also a list of available plugins on ExpressionEngine.com.  The list is the “official repository” - you’ll also find plugins in the EE forums.  My recommendation is to only use what you find in the list as they should be more reliable and offered by more reliable providers than what you might find in the wild.

I’ve used two that should be installed by default in EE, but if not you can find them in the library (installation instructions found at the above link):

HTML Strip
Word Limiter

Note that these are both “first-party” plugins, which means they were created by the EE programmers.  This means they should be safe to use, won’t break with future upgrades, and are eligible for support in the EE forums.

So let’s look at that line of code again:

It’s easiest to visualize this in an “inside-out manner”.  First take the contents of event_details and return them.  Then strip the HTML - so the p tags are removed.  Then, limit the words returned to 10.  Note that you can change the parse order (or order in which the plugins are evaluated) if need be - the Using Plugins page has the details on how to do that.  I will say that I’ve only ever needed to do that once.

Results
You can view the rendered index page, but here also is the rendered code for one event now:

Aha - now I’m getting content returned in a manner that the templates were designed around, while not increasing my content entry workload.  This is what good content management is all about.

Now I will say - the home page is less interesting without the images for each event.  I’m thinking when I get to the gallery implementation I’ll come back and add some “latest photos” thumbnails to the home page - just for another splash of imagery.  But for now it’ll do.

Oh—you can update the link to the full event calendar while you’re here.  The code is:

Cool?  Cool.

Adding Weblog Posts
You’re over the hump now - pulling weblog entries to the home page is a simple matter.  Here’s the new chunk of code:

Nothing new to see here - I’ve just whittled it down to two posts and used some existing CSS styles for formatting. 

Companion Files
And - we’re done for this chapter!  You can view the updated home page at:  http://church.train-ee.com.

Here are the companion files - which include updated embeds/events and site/index templates:
23-Events-to-Home.zip

Looks like the photo gallery is next!

So - at this point I’ve a relationship established between an event and a ministry.  The event detail page is showing a link to “sponsoring ministry”, but I also want the ministry detail pages to show links to “upcoming events”.  From an individual ministry point of view this provides them a nice little mini home page with all the important information someone would want to know.

Adding Events to Ministries Detail
If you look at the updated Crafty Old People ministry page, you’ll see that the left column now has “Upcoming Events”.  These link to the event detail page, and are only the events that are sponsored by the Crafty Old People.

I’ll provide the complete updated template in the companion files below, but in the mean time here is the code that’s pulling those events in.  Give it a once-over then I’ll hit the specifics:

So nested in a weblog:entries tag is the reverse_related_entries.  Why reverse_related and not related_entries?

If you remember - the relationship field that ties these two content types together is in the Event weblog.  That makes an event the parent and the ministry is the child.  Since in this code I’m in a weblog:entries tag that is specifying the child (Ministry) weblog, I need to use reverse_related_entries to pull parent (Event) information.

With me?

So it’s the reverse_related_entries tag and within that tag I need to specify the parent (Events) weblog.  Keep in mind that you might have multiple content relationships - so the tag needs to know where to look in this case.  Since I’m dealing with date-related content, I’ve specified a sort such that the next upcoming event is listed first.

Now - it’s a given that not all ministries will have events.  So I’m using the “if no_reverse_related_entries” conditional to look for that case and display a message if so.  You might include a link to “view all other events” here if you want.

Now I have the following code:

What I didn’t want was events that had already passed to show in this list.  This code compares the date of the event to a Standard Global Variable called current_time.  If the entry date is larger (further out) than the current time the event displays.

Honestly, this isn’t ideal.  You’ll see in the next chapter that with the weblog:entries tag there is a better way to limit its results to just the entries in the future.  It’s called the start_on parameter.  However - it’s not available as a parameter on reverse_related_entries.  There is a feature request that you can add your support to if you want.

So what’s this mean?  If a ministry had events, but they’re all in the past, the if_no_results won’t trigger as it’s not looking at date.  The code will then proceed to try and list the events.  The second conditional will evaluate to true for all events, so the result will be an empty list with no “sorry Charlie” message for the user.

One option is to close out past events—as reverse_related_entries will honor status and not pull those.  But that strips history from your site as then those events won’t show on the master calendar.  Taking that approach further you could configure the master events calendar and detail pages to pull entries with either an open or closed status - so closed events would come off the ministry detail pages but still show in other spots on the site.  For my purposes I’m going to leave things as-is - there’s always the hope that EE 2.0 will have extended relationship handling (and for the record—I don’t know!).

In the next chapter I’ll cover pulling events to the home page.  I had intended to include it here - but as part of displaying the event information I’ll need to use a couple of plugins.  I haven’t yet covered plugins in this series so I’ll break that out into its own chapter.

Companion Files
Just one for this chapter - an update ministries/detail.
22-Events-to-Ministries.zip

Where I’m Headed:
With the Calendar Index in place, I now need to have those event title links go somewhere, and a place to display all the remaining content for the event.  You can get a preview of where I’m headed by viewing the finished result of the calendar details template.

This template will serve the following purposes:

• It will display the complete event information.
• It will allow site visitors to comment on the event - questions beforehand or reviews afterwards.
• The comments could also be used as an informal event RSVP - just by asking people to post a quick comment if they intend on coming.
• It will serve as a link target for other places on the site that will display events (the home page and on ministry detail pages).
• It will link to the sponsoring ministry for the event.

The Steps
I already have the basic weblog, template group and content entered—so this chapter should be pretty quick and easy.  Here are the overall steps:

• Create a events/details template
• Copy ministries/details as a starting point
• Tweak the title and location indicators
• Change content area code
• Update events/index to add links

Create events/details
Create a new template in your Events template group.  I’ve named mine “details”—you can choose a different template name, just remember to use your name in all the links pointing at the template.  The ministries/details template is a good starting point for events/details, so either choose to copy it while creating the new template or copy/paste the code in once you’ve created a blank template.

Tweak the Title and Location Indicators
Go through the top part of the template code and change any references from “ministries” to “events”.  You’ll find them in the static page title text, the weblog parameter for the dynamic part of the page title, the body_id tag, and the my_location variable in the main navigation embed.

Change the Content Area Code
As usual I’ll provide the complete template code in a text file at the bottom of this post.  Here’s the content area code it will contain - take a scan through it then I’ll cover the highlights after:

Show Future Entries
Note the use of the “show_future_entries” in all weblog:entries tags.  If you don’t specify this the page will come up blank when you try to bring up the details for an event that hasn’t happened yet.  Note that the same change needs to happen in the weblog:entries tag that builds the page title.

Commenting
Adding the ability to comment on an event is easily done by adding :

This is when the time invested in setting up comments as embedded templates really pays off.

Handling Fields That May Be Empty
This code has two areas that look for fields having content before displaying them.  The first one is for an event cost.  Not all events will have a cost, and I don’t want the template to show a blank “Cost” area if there hasn’t been one entered.  So the following code first checks for a value in the event_cost field and only displays the whole div if there is a cost:

Note that I’ve used a shorthand approach to the if statement.  I could also use:

Which is also saying “if event_cost is not equal to empty”.  You can reference the documentation on conditionals for other comparison operators.

The other area that checks for an empty field is for the event sponsoring ministry:

So why is this one different?  Because event_sponsoring_ministry is a related entries field.  It just works differently and rather than checking for an empty field you have to check for the 0 value instead.

Related Entries
OK - now I’m to the new and cool stuff in this series.  The assumption I made when creating this calendar is that many of the events would be put on by specific ministries in the church.  If that is indeed the case then I wanted to be able to link an event to a ministry and vice-versa.  Rather than force a content administrator to manually create those links I’m using ExpressionEngine’s relationship ability to programmatically link them.  By setting up a relationship field in the events fieldset, specifying the Ministries weblog as its source, and choosing a ministry for each event as it gets entered, now I can use the related_entries tag to pull that value out and display it:

Note that this code is within a parent weblog:entries tag, and I’ve had to specify an id which is the name of the field holding the relationship.  Within the related_entries tag I could pull any of the content from the related post in the Ministries weblog—but for my needs just wanted a linked title.

Explaining Relationships
There is also the reverse_related_entries tag - so how do you know when to use which?

I always tend to visualize relationships as a pipe.  At each end of the pipe is a post - in this case the post holding the Event content is at one end of the pipe.  The post holding the Ministry event is at the other end of the pipe.  The outside of the pipe has an arrow painted on it.  The arrow points from the post where the relationship was created, and points to the post that was chosen in the drop-down field.

Now when I’m coding if I’m dealing with one of those two posts and want to look at the other one, I just look at the arrow on the pipe. If I’m looking through the pipe in the same direction as the arrow, my code needs the related_entries tag.  If I’m looking against the arrow, I need reverse_related_entries.

The other way to think about it is parents and children.  The post where the relationship is established is the parent post, and the post chosen in the relationship drop-down is the child.  If you are working with a parent and need content from a child, then you use related_entries.  If you are working with a child post and want information from the parent, it’s reverse_related_entries.

In the next chapter I’ll show the use of reverse_related_entries by editing ministries/detail to list each event the ministry has coming up.

Update events/index to Add Links
With the content of events/detail now in place, the only remaining thing is to edit events/index to point links at the new template.
This code

Just needs to change to:

Companion Files
The zip archive below includes:

• New events/details
• Updated events/index
• Updated stylesheets/style

21-Events-Details.zip

Until next time - cheers!

Preview the Results
Before getting your hands dirty with the code, take a look at the completed calendar index on the sample site.  I want you to make sure it’s what you’re after before proceeding.  You can see that EE generates the calendar view, and if you look at either July or August of 2008 there are entries that show up that display a linked title.  At the moment the link doesn’t go anywhere - that requires a detail template that I’ll cover in the next chapter.

If you mouse over a link, you should get the browser title pop-up that displays a bit more information about the event—the start time, the duration and the location.

That’s roughly half the calendar functionality I’ll be covering in this series.  The other half will be the detail template (that the title will link to) and implementing an events RSS feed.

If that works for you, keep reading…

Overall Implementation Steps

• Create events weblog
• Create events custom field group
• Add fields to the group
• Enter content
• Create events template group
• Update embeds/main_nav
• Update stylesheet/styles
• Add code to events/index
• Create embeds/event_rollover_title

Create an Events Weblog
Event calenders in ExpressionEngine are powered by a standard weblog - so I’ve created a new weblog and named it “Events”, with a short name of “events”. 

Create an Events Custom Field Group
Events have their own unique data structure, so a new field group is required. Create an “Events” custom field group.

Add the following fields to the group.  I’ve listed the field name, label, type, size and formatting options for the fields I’ve added:

• event_duration, Event Duration, Text Input, 3, None
• event_location, Event Locations, Drop-down List, manually populated, None
• event_cost, Event Cost, text input, 4, none
• event_contact_name, Event Contact Name, text input, 128, none
• event_contact_phone, Event Contact Phone, text input 128, none
• event_contact_email, Event Contact Email, text input, 128, none
• event_details, Event Details, text area, 6 rows, XHTML

And One More
While planning this section initially I was going to tie together events and ministries using categories.  I’m going to do a bit of a direction change and use relationships instead.  Using categories only nets me being able to show related events on Ministry category pages—so if you view the Ministries for Singles I’d be able to pull the upcoming events for singles - but I see a couple of issues with that approach.  The design of the Ministries index template doesn’t allow for another content type to display and I don’t want to go down the path of a category-specific template.  Using categories also doesn’t easily allow me to pull ministry-specific events to a ministry detail page—and I think that’s a more helpful connection than the category level tie-in.

Relationships will let me create a direct connection between an event and a ministry.  I’ll be able to use that connection to link from a ministry detail page to an event, and from an event detail page to the sponsoring ministry.

So I’ve added one more field to my Events field group - a relationship field:

Name:
event_sponsoring_ministry

Label:
Event Sponsoring Ministry

Field Type:
Relationship

Weblog to Create Relationship With:
Ministries

Display Criteria:
I choose “Sort by Title” in “Ascending” order

In this chapter all we’ll do is setup the field and assign a related Ministry while entering content.  In the next chapter I’ll show how to pull related Ministry information to the Events detail view.

Connect the Field Group to the Weblog
Make sure to assign the new field group to the Events weblog via the “Edit Groups” link in Weblog Management.

Enter Content
Go ahead and post some new entries in the Events weblog. There are a couple of new things to note here:

Make sure to click the Date tab and assign choose an Entry Date that’s in the future.  The time of the post will be used as the event starting time so round it off to a nice “top of the hour” number.  The other new thing is to now use the relationship field - so for every post choose a sponsoring ministry in the drop-down.  I found that putting a number of events on one date helped me with formatting the calendar visually.  Keep in mind that you can edit your entries to assign new entry dates to move events around the calendar for formatting purposes.

Create an Events Template Group
With the content structures in place I’ll now work on pulling the content to the site.  Create a new template group named “events”.  Since the content is full-width like the Beliefs page, it made a good starting point - so I copied that code into the new events/index template.

Coding the Template
The first order of business is to change all references of “beliefs” to “events” - so the page title, the body id, and the variable in the main navigation embed.  Then in the main content div you can remove all the code there entirely.

I used the calendar code from the EE documentation as a starting point for my code - the “big” version which is the second example on that page.  I also used the provided calendar css as a starting point.

After some tweaks - here is the guts of my events/index template - take a scan through it and then I’ll highlight the changes I had to make from the example code I used as a starting point:

Here are the changes I had to make from the sample code I copied from the EE docs:

• Changed the weblog it references - to “events” in my case
• Changed the next_path and previous_path values - and just referenced this index template
• Added “show_future_entries="yes” to the calendar tag - otherwise the calendar will only show events for today or ones that had passed

With those changes I had a working basic event calendar.

Getting Tricky with Embeds
I wanted to take it a step further though and see what it would require in order to be able to pull custom fields to the calendar view - so users could get more event information without having to click through to the detail page.

Remember that the weblog:calendar tag doesn’t support custom fields by default.  However - it does return entry_id.  Using that as a bridge I was able to pull custom field content to the index template by using an embedded template with an embedded variable.  I decided that directly displaying more content on the calendar would visually junk it up so decided to pull custom field content into the link title attribute .  The result? Mousing over an event link will pop up the little browser tooltip and display the event start time, duration and location.

So I created a new template in my embeds group called “event_rollover_title”.  It has the following code:

and then added a calling template in events/index:

Here’s how it works:
The parent weblog:calendar tag returns entry_id, which gets passed to this embedded template.  This embedded template takes the entry_id and uses it as a parameter on a weblog:entries tag, which as you know returns all custom fields.  The fields within the weblog:entries pull out the post time (used here as an event start time), duration, and location.  This text is assembled and returned to the calling template as the link title text.

One note I need to make about this approach is that it, due to it’s nested approach, it could be resource intensive if you have a lot of calendar entries.  For the couple of church sites I’ve been involved with, I wouldn’t be worried, as there are rarely more than a couple of entries a day.  I’ll also - in a future chapter - cover some caching approaches that will also help mitigate any performance concerns.

Don’t Forget
Don’t forget to update embeds/main_nav to make the link to events/index live.

Companion Files
The companion file zip archive for this chapter includes

• New events/index
• Updated stylesheets/style
• Updated embeds/main_nav
• New embeds/event_rollover_title

Here’s a link to download the companion files: 20-Events-Index.zip

Next up - the events detail template.

ExpressionEngine Calendar Overview
I know a number of you have been waiting for me to get to this part of the site build—and it has me a bit worried as I’m afraid the expectation is that I’ll show how to build this really great full-featured event calendar that slices and dices event information like something from Ronco.

The EE calendar just isn’t that complex, however, so I want to do a bit of work to manage your expectations before plowing into the code.  Let me lead off with an overview of the EE’s calendar function - a description I wrote in the comments on an earlier chapter in this series:

First - imagine a weblog. Now add an entry on the weblog.  It goes in with a publish date.  Many blogs have those little sidebar calendars that show you when posts were made - so if you posted an entry on the 6th of March that date would then become clickable.  Clicking on it would filter your current view down to just the entries posted on that date.

Got it?  Now - blow up that small calendar to be full-page, post some entries with future dates, and tell EE to show entries with future dates.  Throw the title of the post on the full-page calendar view. Link the title to another template that can show more details for one event.

That’s the essential EE calendar capability.  It’s basic weblog post information, plotted on a calendar view, with the ability to show entries with future dates, and link to another template that can show all the content for that one event.

Advantages
There are a number of advantages to using EE for an event calendar.  First - you can offer content administrators a consistent publish and edit process and interface.  Entering an event is the same as a new ministry. 

Second - you can take advantage of categories or relationships to group event content together with other content.  I plan on doing that here, using relationships to tie an event to a ministry so that I can show specific upcoming events on a ministry page.

Third - you if go down the path of memberships on your site you can allow any registered member to submit a calendar event using a Stand-Alone Entry Form.  Those entries can then take advantage of Custom Entry Status so that the new submission goes to “pending” status and doesn’t appear on the site.  You can then implement an Entry Notification such that a calendar administrator would get an email when a new event is submitted.  The calendar administrator would then review the event and if approved set the status to “Open” which would cause it to display on the site.

Disadvantages
The native EE calendar doesn’t do recurring or multi-day events - but there is a third-party plugin that adds that capability - so you post an entry, some details about how it repeats, and then your event shows on the full-page calendar view multiple times.

The native weblog:calendar tag doesn’t support custom fields, which means that on the full-page calendar view you are limited to what can display for each event.  Options are title, author, and entry_id. There are ways around this restriction that aren’t too hard, so I’ll cover one here.

EE’s calendar also doesn’t, inherently, work with categories. In other words, you can’t assign categories to the weblog driving your event calendar and then use native EE tags to link to a categorized view of the overall calendar.  You can get to this functionality with a bit of php trickery, but for this series I’ve decided to stay within the bounds of native EE functionality only.

There is no native iCal support - although there seems to be some movement in the forums around it.

Options
If native EE doesn’t meet your calendaring requirements the next option I’d suggest looking at is using a Google Calendar.  There is a relatively new Google Calendar Plugin for pulling information from a public calendar to EE.  However it doesn’t have much activity around it and I haven’t tested it—so don’t consider this link an endorsement.

Having Said All That
My plan here is to show the implementation of a simple event calendar using native EE tags.  I’ll push the bounds a bit, showing how to use entry_id as a bridge to pull custom fields to the full-page calendar view.  Other than that, this will be a very straightforward implementation.

In the Real World
My church uses the EE calendar but I have extended EE’s native functionality with the repEEt plugin linked to above.  I also implemented a Stand Alone Entry Form with workflow to allow calendar submissions by any registered member.  In all honesty if 10% of the events on the calendar were submitted that way it’d be great - in reality my wife and I “own” the web calendar and keep it updated based on what we hear going on while at church.

But - we’re a very small church with a small building.  We don’t have a ton of staff, committees, or different facilities to manage.  For us the combination of ExpressionEngine and repEET work well.

I won’t duplicate the help found at 5Pieces, or in the Monoslideshow documentation.  All that’s really different is the code needed to pull the image and thumbnail specifications in the XML file used by Monoslideshow.

You’ll also need the “Extract URL Plus” plugin offered in this EE forum thread.

Note that in my case I have two fields in the photoblog: thumbnail and full_size_image.  I don’t use captions so just plug the title in as the image title and description.  I have MSS configured to not show this data anyway as I prefer to just let the images speak for themselves.

In order to get the XML to output correctly for Monoslideshow to parse it, I had to wrap a weblog:entries tag inside of a category:archive tag.  There’s probably a more efficient way to do this with a custom query, but so far the performance seems acceptable.

Here’s the EE code required - keep in mind that there is more to the XML file that Monoslideshow requires.  This code goes in the file after the “preferences” portion of the file closes.
monoslideshow_xml.txt

Oh - this approach also assumes that all photoblog images are in the same directory.

I think the site_url and homepage variables are a couple of my favorites in ExpressionEngine. I’ve found that you can actually use these in the EE Control Panel - wherever paths need to be specified.  This includes:

• Weblog Path Settings
• File Upload Preferences
• Category Image URLs

Why would you want to use variables in these spots?

What happens to me quite often is - no matter how hard to I try to remember - I forget to change these paths after a site goes live.  Then when, for example, someone uses the Search, the path of the link returned still has the “temporary” domain name in it.  The link will still work, but it messes up your server logs and just doesn’t look as nice as getting the live URL in there.  Or - I decide to rename “index.php” to something more semantic and then have to go find all the places where “index.php” is stored.

So - what I discovered I could do is use the variables in those settings - and then they will inherit the change to the homepage and root URL setting automatically.

So, for example, rather than having a Search Results URL setting of :

I can specify:

Now when I change the “URL to the root directory of your site” and the “Name of your site’s index page” under Admin > System Preferences > General Configuration all those individual weblog paths will change as well.

With some paths -like category images - you won’t want the “index.php” in there since you are referring to an image and not a template.  In that case you can use site_url instead:

Variables in Control Panel path settings == one less thing to worry about when launching a site == well worth it.

Situation:
My church - Manna - wanted to have an “online directory” of member photos on the website.

One way to do this is to just use the Photo Gallery module and create a “members” category, upload some pics and title them with the member name.  While this would give you a nice online directory, what it doesn’t do is integrate with the existing profiles which get linked to blog posts and comments, etc.

However, the built in profiles don’t let you browse pictures - you can only navigate via the memberlist and click each name to view the full profile.  The profile may or may not include a photo.

For the situation where you met someone but can’t remember their name this isn’t a great arrangement.

What you really want is the best of both options - photos stored in the profiles where members can upload and maintain them on their own, where they get linked to blog posts and comments, but also have a “gallery” page where you can browse photos to find a name.

That’s where this little howto comes in.  Using the Query Module we can pull this data together in pretty short order.  Here’s the code I used (note that I’ve removed all formatting and specific paths, so you’ll need to edit those to work on your site):

This code:

• Only loads those members who have images
• Sorts the results by screen name
• Loads 4 images to a page
• Adds pagination links if there are more than 4
• Loads the member name and bio
• Links to the standard EE profile for each member

Voila!

Here’s the “straight-talk” around what happened with my church and this page. This approach was my response to being asked to put together an online directory on the site - with the expectation that I would bring my camera, take pictures of people, and post them to the site.  I’ve consistently avoided putting myself in such roles as I don’t want to be the “website update boy” for the church.  I’d much rather spend my time putting together ways to enable self-service for church members at large - so rather than taking on the creation and maintenance of a member photo gallery this approach put the responsibility for uploading photos in the hands of each member.

However in the end this member photo directory was one of those times when the technology was the easy part, but getting people to take action was the harder part.  Not enough people uploaded their own picture to make this page worthwhile - so it only lasted a few months on the site.

What this tells me is that that a photo directory just wasn’t that important to enough people - otherwise they would have taken the 10 minutes to upload a photo.