Part IV in the Behind the Curtain series was delayed for longer than I anticipated. So without further ado, let’s dive right in, shall we? The topic of Part IV is relationships. Relationships can be a very powerful tool when designing the data structure of your site. For some, relationships are clouded in mystery, and not having seen them used in a practical sense, they either avoid relationships, or use them poorly. So we’ll look at a real world example that I used when redesigning our site, and this will perhaps help you identify with this feature of ExpressionEngine.
I disagree, sigork. The entire purpose of a Wiki is collaboration and working with articles (i.e. one large field as opposed to any number of custom fields). The individual features here are not subject to interpretation nor authored by many people (nor do they regularly change). Custom fields and a weblog are much more appropriate, at least for us. The terminology might be stumbling block here: these aren’t ‘blogs’, they are data containers.
The short answer, though, is no, no such relationship could be made, at least not without some custom development and an artificial method to create the associations. Sounds like a lot of work when this feature is ready to go out of the box and works perfectly. And having some of the content for this page controlled in the Publish page, and some in a front-end Wiki is rather jarring. You really can’t get much more straight forward than what I’ve done here; I’m afraid I’m not seeing the benefit of having any of this in a wiki.
I am one who would fall into the “cloudy” category regarding relationships. Could you please explain why you used the {reverse_related_entries} tag instead of the {related_entries} tag?
I am one who would fall into the “cloudy” category regarding relationships. Could you please explain why you used the {reverse_related_entries} tag instead of the {related_entries} tag?
Sure thing, jshcutt.
It all boils down to how the information is presented and displayed. The decision was basically made for me by the design. Related entries show one entry per custom field. So to get the presentation that I have here with related entries, I would need one custom field per every possible feature, and to publish a new feature, I’d have to publish the new entry in “Features Entries” and go to the parent “Features Category” entry, and swim through a list of relationship custom fields for the next empty one, and select my newly published feature entry. On the template side of things, I’d have to have a {related_entries id=“foo”} tag for every custom field.
Reverse relationships allow me to make my “Categories” the actual children, and the individual features the parent. This lets me have only one relationship field, and only have to publish or modify one entry to add and make changes.
If that break down doesn’t help you (it’s late afternoon and very hot, so my explanation is probably not super) try thinking of it this way: A parent can only show one child per custom field, but a child can without any custom fields at all show all of its parents.
I need to make an MP3 audio archive that consists of multiple mp3’s from multiple speakers at multiple events. (sounds like fun, huh?)
After reading this Behind the Curtain, a light bulb went on. I created a weblog to hold the MP3 files that also has a category group with all of the possible events. That should take care of pulling up the files attributed to any particular event.
Should I now create a “Speaker” weblog to hold all of the speakers? Then I could relate entries from the MP3 weblog to the particular speaker in the “Speaker” weblog and use the {reverse_related_entries} to pull up all of the MP3’s attributed to any particular speaker.
In the moments that this is clear in my mind, it seems to be very similar to what you did with the features section of the EE site.
PS - Feel free to move this into a new location in the forums if necessary!
You are indeed correct; it’s a perfect parallel—so long as there is only one speaker per MP3. If there’s more than one speaker per MP3, then your MP3 weblog will need to have relationship fields (all pointing to the “Speaker” weblog) equal to the number of the highest possible number of speakers that will be attributed to an MP3 file.
On your features page, how would you have accomplished grouping some of the different features within your categories?
Maybe this will be clearer - I have some speakers who speak at multiple events. I have it already set up to create a relationship from the mp3’s to the speaker. I also have it set up to display the speaker, a picture, a bio, as well as any of the mp3’s that are related to him. My question is this - Is there anyway to group mp3’s from each event for a speaker that has multiple events to his credit?
But since the {exp:weblog:category_heading} is not inside of the {reverse_related_entries}, I get nothing. If I put it inside of the {exp:weblog:category_heading}, I get nothing either
That tag’s not meant to be nested (and is also intended only for category pages). What you are looking for is the category variable pair of the weblog entries tag (and by extension the reverse related entries tag pair).
But when I placed that inside of the {reverse_related_entries} tag, it loops through each of the mp3 entries. What I am trying to accomplish is one header that lists the event category for any applicable mp3’s.
