In Approach D I introduced the idea of using ExpressionEngine’s Relationships to drive navigation for 3 level content. This installment builds on that approach by creating a menu that only shows the 3rd level pages when you click into that branch of the navigation.

To follow this tutorial you’ll need:

• The EE components covered in Approach A.
• The additions mentioned in Approach D - so essentially a weblog with content and relationship fields and an index template.
• Several entries posted with some of them being assigned to a parent page.
• The entries need to be ordered by date in an order that matches their position in the menu.  Put another way - the date ordering should be such that if you showed them all at the same time they would be in the right order - Parent A with it’s children before Parent B with it’s children.  Getting the children to show up correctly in all cases depends on this sort being correct.
• A template group and template structure such that url_titles will display in the segment_3 position.  If your structure is different you’ll need to adjust the code.

Note: this approach does require the query module, which isn’t included in the Core version of ExpressionEngine.

The Results
Let’s first look at the results - so you can determine whether the outcome is something you’re interested in building.  Here’s the working example.  The index loads initially only parent pages showing in the left nav - so these are pages with nothing assigned in the relationship field.

Clicking a parent page link will load that entry, and also refresh the left-nav with child pages for that section.  Clicking a child page loads that entry and keeps the navigation the same. Choose a different parent and the 3rd level options change to only show the children for that parent.  Behind the scenes - no javascript trickery, no CSS showing and hiding, no dynamic HTML - it all runs on straight EE conditionals with one query thrown in.

OK - so that’s the finished product.  Let’s take a look at what it takes to get there.  In this example I broke out the menu-building code into an e Embedded Template so that it could be easily reused from different areas of a site that needed the same type of navigation.

Index Template
Let’s start in the parent template - it features this code which calls the embedded template while passing in all the things the code in the embedded template needs to generate the navigation:

my_weblog_name: Used to set the weblog to create the navigation from.

my_index_entry: There will be one post in the weblog that holds the index content for this section - and we don’t want to display that post in the subnav.  Passing in the url_title of that entry will allow the embedded template to exclude it.

my_detail_path: We’ll need to build links in the embedded template so will need to know the path.  Note that you can use this in two ways - either have one template for everything or use an index/detail template arrangement.  In this example I’m using a single template.

my_relationship_field: The embedded template will need to know what field holds the relationships. Different weblogs will have different names for this field so its passed in as a variable.

Embedded Template
Now for the meat of the code - the embedded template.

There are essentially three parts to this code:

• Showing the parents only
• Showing children when a parent is selected
• Showing siblings when a 3rd level page is selected

First let’s look at the weblog:entries tag:

You can see we are using two of the passed in values to choose the right weblog, and exclude the post that represents the index entry.  We set the sort and turn dynamic=off so EE doesn’t look at the URL to choose its results.

Showing Parents Only
The first conditional finds entries that have no relationships assigned:

Showing Children When a Parent is Selected
Within this conditional is another:

The code assumes that when the index for this section is loaded there will be nothing in the segment_3 position.  So - remembering that we are still on an entry with no relationship specified - if there is something in segment three that means the user must have clicked a 2nd level—or parent - entry.  Now we need to show the children for this entry so the code uses the reverse_related_entries tag to do so:

Those two situations are the easy part.  The harder part is determining when a child entry has been selected and then displaying the siblings for that entry.

Showing Siblings When a 3rd Level Page is Selected
The first part - detecting when a 3rd level page has been selected - is handled by this if:elseif in the main conditional:

This finds the case when the currently-displayed entry has been assigned to a parent (so is a child page) and whose url_title is displaying (so has been selected).

Now for the trickiest part - finding other pages with the same parent - or siblings - to this page.  There is currently no built in tag to do this in ExpressionEngine, so we have to use a custom query (I won’t go into the specifics of the query here - I was only able to figure this out by bringing EE data into MSAccess where I could use the visual query builder to figure it out):

Note that the query uses the global homepage variable, the passed-in my_detail_path variable, and a query-specific variable of my_url_title to assemble the proper link.

So there you have it - a one weblog, one field group, one template way of building static navigation that requires no client-side trickery to only display children for one branch of the navigation tree at at time.

I do need to thank Rob Dircks of Dircks Associates for permission to share this code.  I developed some of the trickier parts as part of a project for Rob.

I’m considering a more detailed writeup of how it works down the road - but in a nutshell the select-boxes are dynamically populated by weblog:entries tags, a bit of Javascript assembles a URL from the entry_id of the selections, and the results are constructed with weblog:entries tags reading the entry_id’s from URL segments.

The nice part is that the results pages don’t use any cookies - and hence are able to be bookmarked by users, or sent via email by Espec sales people to prospective clients.

I’m pleased to announce that I’ve added a blog to Train-ee.  The Train-ee.com blog will be the home of a new Building an ExpressionEngine Site Series, this time covering the build of a church website.  You can read the full announcement over at Train-ee.com.

If you’ve looked over the changes and watched the preview video you know the biggest changes are that EE 2.0 is based on CodeIgniter and that the control panel has been reorganized and redesigned.

So first I thought of describing it like a sandwich - where the meat is the same but the bread is different...but that doesn’t quite get it.

I often think of houses and architecture when it comes to websites and applications, so next I thought about a house where the foundation is being revamped.  But EE 2 has more than just redecorating happening in the control panel - it’s also been reorganized which doesn’t quite map to the house metaphor.

So my working metaphor is that EE 2.0 is like taking your current CD/ DVD collection, buying a much nicer/sturdier/more expandable rack to store them in, and then re-organizing them while moving them into the new rack.  Same music that you love - just better organized in a better environment.  And maybe a few new CD’s to boot.

That’s better...but it still seems like there should be a better way to describe the changes that EE 2 is bringing.  How about it - any better metaphors out there?

You can read the full description on Train-ee.com, but the main goal of the screencast is that it gets you over that panic-attack moment of looking at a finished site comp, and now wondering just how the heck do I configure ExpressionEngine to power this site?

I felt this was an important one to get out there, as through my consulting work I’ve seen a number of EE sites that have foundational issues.  And—just like trying to build nice straight and level walls on a crooked and irregular home foundation is tough, so it is with EE.  The trouble is when you’re new to EE it’s just so easy to make poor choices that come back to bite you later—so hence this screencast with some recommendations for a solid ExpressionEngine Architecture.

I’ve been getting a few more than normal spam comments the last couple of days.  I noted in my search logs that they are coming in with referrer phrases like

community “Remember my personal information” “Notify me of follow-up comments.”

then hand-entering comments for the sole purpose of linking to their site.

In other words, they are targeting EE blogs by using the default labels on the comments form in their searches.  I’ve changed the labels on my comments form this morning to some alternate wording to see if it helps mitigate the spam.

EE techie note - this was one of those payback moments for implementing my weblogs all with a shared comments form.  Even though I run four blogs on the site, changing the wording in one template took care of all of them.

But I just need to say it again—for ExpressionEngine-based projects or not, EngineHosting just rocks.  I’ve been a happy customer of theirs - for client sites, Boyink.com (and now Train-ee) - for a few years now and have had nothing but good experiences every time I’ve contacted them.  It’s so nice to be able to pitch projects and make a recommendation for hosting with 100% confidence that my clients will be happy with the service.

Lately I had an issue that was somewhat “outside of the box” and Nevin responded in a very generous manner.  I don’t know if he’s a drinking man but I am looking forward to buying him a beverage of his choice at the upcoming SXSW conference.

Thanks again EngineHosting!

As I think through it, though, it seems a waste to build a “sample” site when there are so many churches and ministries that could actually use the thing.

So, yes, I am considering ignoring my own advice and writing a blog series covering the build of an EE-based website that would, at the end of the series, be turned over to a church or ministry that could really use it.  The series would then be compiled/edited into a book just like the Small Business series, and sold via Train-ee.com.

Yes, it might be crazy - or at least I am considering my less-than-stellar experiences with church websites.

So with that as the kernel of the idea, I’m looking for input on how to best structure the project so that the site-recipient is best set up for post-launch success, and I have the material for a book targeted at another audience.

I’m thinking of things along these lines:

• Recipient must identify a developer who will “inherit” the site and make all future changes to.  This developer will be provided with the book resulting from this series.  The goal here is that once done building the site I can hand it off and not be responsible for it forever.
• Recipient must be, as an organization, at least two years old, with a healthy ministry.  I want to avoid putting a lot of work into a site for an organization that dies either during the process or shortly thereafter.
• Recipient must furnish a design template and logo before the project begins (Debatable here - documenting the design process might be interesting as well, but that would involve someone else as I’m really out of the design business these days.)
• Recipient must purchase hosting and a copy of ExpressionEngine.
• Recipient must be committed to actually using the site once live.  I’m not sure how you can require commitment but I want to see the site get picked up and taken seriously in the day to day running of the recipient.  Maybe the recipient has to be already active on the internet - just using something like Blogger that isn’t meeting their needs any longer. Or maybe the recipient would need to furnish a content maintenance plan involving staff and schedules.
• Recipient can’t be in a hurry.  The last series took roughly 5 months to complete, and I’d expect this to be the same.

Other thoughts or ideas?

The other day—while putting the book together actually - I ran across another handy place to use the homepage variable - in the Weblog Path Settings.

Path Settings are where you tell EE where the Weblog URL, the Comments Page URL, the Search Results URL are for a given weblog.  Some of these get defaulted when you create the weblog.

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 homepage variable 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.

One less thing to worry about when launching a site = well worth it.

Why this, why now?

Simple - over the past 12-18 months I’ve seen a large increase in the number of contacts for ExpressionEngine work - not from end users, but from other developers and design firms.  The story is usually roughly the same - they have a project, EE looks like it’d be a great fit, but they don’t yet have the internal expertise to do the ExpressionEngine implementation.

While I certainly don’t mind hiring myself out as a subcontractor on those projects, it just seemed like there should be a better way to get the EE implementation knowledge out there that would help these firms help themselves.

Now - there are plenty of existing resources out there where you can learn about EE but I think what has been missing are some content types - books, screencasts, webinars, etc. that would appeal to people with different learning styles, and more of the step-by-step tutorial type content that’s been so popular here on Boyink.com

And yes - before you ask (or go peek, if you haven’t already), the content offered via Train-ee won’t (in most cases anyway) be free.  At least now, to start with, each item will be purchased on an individual basis with other pricing schemes being considered for the future. My hope is that, by charging a modest amount for each item, the site will generate enough revenue to justify continually adding new content while also ensuring that each item is of high quality and hence—a good value for your investment.

And please note - I fully expect that Train-ee.com is going to be an ongoing learning process on my part.  I’ve never ventured outside of the “work for hire” model of web development - so I hope you’ll understand if you see some pricing fluctuations or other site changes going on as I (hopefully) respond to market conditions and demands.

From a design point of view my goal was to get something workable and relatively consistent across different EE modules (wiki, discussion forum, member templates) as quickly as possible.  The best way to do that seemed to be to orient the site design towards existing themes for those elements, so the main site design is a mashup of the What’s your solution template available from solucija.com and some default EE elements.

The site uses the EE Simple Commerce Module to handle the transactions, and the EE discussion forum module for post-sale support.

So - what’s available for purchase on the site?  Read the next post…