Train-ee | Learn Expression Engine Fast

23 - Pulling Events to the Home Page

Continuing with the events theme, this chapter looks at pulling church event information to the site’s home page.  While I’m there I’ll also replace the Mission Statement area with the latest posts from the Weblog, as I don’t think mission statements are the best use of home page real estate - ever.  New coding approaches covered in this chapter include the use of plugins - which will allow the reuse of content while keeping the site design happy.  I’ll also use a new parameter on the weblog entries tag - the start_on parameter.

 

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. 

Looks like the photo gallery is next!

Category Navigation

<< Previous Entry   

Next Entry >>

 

Previous Comments

Add Your Comment

Comment on this Post

1. Name:
2. Email:
3. URL:
4. Comment:
5. Remember Me?
6. Email Notify of Response?
7. Enter this word:
   In this field: