Hey all,

I’m in the middle of using EE for a record label site, and I’ve hit a bit of a hitch in regards to listing tour dates.  Here’s a brief overview of what I’m doing ... if anyone has any suggestions, I’d be happy to hear them!

The main requirement I wanted to fulfill was to not make the label have to enter an expiration date for the tour dates.  Why?  Aside from the obvious reason that it’s doubling data entry, it’s also because of the required time parameter, which defaults to the current time (or close to).  This means that not only does that date have to be entered twice, but that the time has to be adjusted as well - preferably to 23:59 that day, or 00:00 the next day - or else the show will disappear before it’s over (ie. enter a show at 10 AM one day, and it will disappear at 10 AM the day of the show.)

I found the best way to get around this was to use the “start_on” parameter when calling my tour dates.  Using Fresh Variables I created a variable called {today} that looks like this:

And then called my tour dates like so:

This way it doesn’t matter what time the entries had in their entry_date - they’ll show for the entire day of their show.

The problem comes when I am displaying a single band’s tour dates.  Every tour date is linked to a band using a relationship field (all bands exist in the “bands” weblog.)  Unfortunately, this means I can’t filter out a specific band using an entries loop from the “tours” weblog (as the “seaarch” parameter doesn’t search relationship fields.)  So I use {reverse_related_entries} from within an entries loop for the “bands” weblog.  BUT - {reverse_related_entries} does not make use of the “start_on” parameter!

To get around this when I want to list all of the shows for a band, I can do this:

This is obviously very inefficient, as I’m pulling all entries - future AND past - from the database, and only showing the ones dated for today or later.  But it DOES work.  However, when I want to show only a small list of tour dates - say the next 5 shows - I can’t.  The “limit” parameter will start from the oldest entry in the database (since I have to sort ascending), so my conditional will strip out any results, giving me nothing.

Obviously I need a better solution.  Here are ideas I think might work, but that I’m not sure how to implement:

- Use some PHP to dynamically count and increment the number of results being show in the loop, and stop it at my desired number of entries.  I tried this but it seems that I require a mix of “input” and “output” parsing to be successful.  Plus, it’s terribly inefficient (still calling up all past and future entries, when all I need is future.)

- Find/write a plugin that uses JavaScript to automagically set the expiration_date to match the entry_date, but set to 23:59, only in the “tours” weblog.  This way, I don’t have to worry about using “start_on” - shows will just expire - and the label folks won’t have to double their data entry.

- Run some sort of cron script that does the same thing as above, directly modifying the database.

- Use the Query module to create my entries loop instead.  Since this involves a relationship field, I really have no clue where to begin.

What would be really awesome is if I could somehow hack the {reverse_related_entries} tag to accept the “start_on” parameter.  I’ve seen a few other posts here asking for that tag to accept this argument as well.

Any ideas, suggestions, or bits of code? 

Hmmm, I think I’d approach this by using categories - each band having a category.

Bands weblog
- when entering data for the band assign it to the bands category

Tours weblog
- when adding a tour date assign it to the bands category

Each band page is then called via a category tag link so you can then pull in all data for that category from any weblog…

That should take care of getting the right stuff listed. The easy way of getting dates listed showing “todays” gig would be to set up two custom date fields in the tours weblog…

Gig start date - ie the day of the gig, or start date if it’s a multi day thing
Display until date - normally you’d set this to the day after the gig which saves faffing about with expiry dates

I recently made a site for our band and that’s the way I did it anyway!

In the end I’ve decided to indeed use categories - thanks for the idea.  It’s not ideal, but it’s the most flexible for now.  I’m still setting up each band as an entry in the “bands” weblog, but then also assigning each band to its own matching category, and using this same category group for all the other weblogs (tours, releases, mp3s, news items, etc).  So instead of associating each entry with a band via a “relationship” custom field, I just use the category.  There’s still duplication of data whenever you create a new band (as you have to create a matching category), but it’s very flexible.

For those curious - I then changed my “category keyword” trigger to be “bands”, so the urls make good sense when I want to filter by band (category).  I can also use the “related_categories_mode” parameter on a band’s page to pull entries from other weblogs that are only related to that band.  As well, I’m using some embeds on band-specific pages, like so:

Ultimately, I’d be happier if “reverse_related_entries” was as flexible as the weblog:entries tag itself, so that I wouldn’t have to use work-arounds like this - but it’ll do!

Glad it worked for you, at least it stops the head scratching for a while!