On the gench site I’m currently working on, I wanted to display a song and audio player on each CD product page. I have two content types I used for this: “Product display” with most of the CD information (title, artist, label, cover image, price, etc.) and “Song” which includes the mp3/player, song title and an entity reference field that points back to the Product display.
I knew I wanted each Product display page to display the song/player in the Second side bar. I suppose I could have created a view and block for each song and then used each view block’s config to display each on the appropriate Product display page. But this seemed like madness to me! Is the client to be expected to create a new song, view and block each time they want to add a product/CD?! True, the client in this case is “only” my husband, but he’s generally a decent guy, so I figured there had to be a better way.
And there is. What we want is to create just one view and one view block that is “content aware.” In other words, when the Product/CD page loads, this view block will also load and it will ask and find out “what CD page am I on right now?” Once it knows what CD page it’s on, it looks for all content types of “Song” which have that particular CD associated with it and displays just those songs.
This means the client just has to create a new product and a new song when adding inventory to their online store. As long as they do that, the new Product display page will automatically include an audio player with a free song from that product/CD.
Here’s how I did it…
Created content type = Product display (I actually didn’t create this content type as it comes with the commerce kickstart distro). Note: this content type doesn’t contain any info about or relationship to other content types.
Created content type = Song which has a text field for song_title, a file field for uploading the mp3 song and an entity reference field which lists all Product display nodes. For this entity ref field, you want the target to be Node and the mode should be Simple. While I’m here, I go to Manage Display and set the Teaser to display just Song title, MP3 and the entity reference field (as an entity id).
Using my new content types, I created a bunch of Products and a bunch of Songs. I made sure to select the corresponding product/CD from the Gench Productdisplay picklist on each Song edit page.
Now we’ll create the view, which is really where all the magic happens. Create a new block view.
Most of this is pretty straightforward. I’m filtering for all published songs and I’m displaying the results as an unformatted list of Teasers (but you could use fields if you prefer). And I’m displaying only one item, but could increase it.
Here’s the magic part…
First I add a Relationship. In the select list that appears, I scroll down to the Entity References and select “Entity Reference: Referenced Entity” for field_gench_productdisplay. I make the relationship required.
Next, we’re going to add a Contextual Filter. Add one and select Content: Nid as the type. On the config page, make sure the relationship is selected and under “When the filter value is not available,” select the Provide Default Value and “Content ID from URL.” I accept all the other default values and save my changes. Now I save my view.
The only thing left to do is reveal this new block view in my Second Sidebar region using Drupal’s block admin interface. For this project, I set the block to display only on productdisplay/* pages.
This basic technique saves me a TON of work, simplifies updates for the client, and can be used in a number of situations. This example happened to be an audio file and player, but I’m also using content-aware block views throughout the site. For example the CD reviews you see on this page.
As cool as all this is, I’m still puzzled about something: am I being silly making Song a separate content type from Product display? Couldn’t I have just added song title and mp3 fields to my Product display content type? Had I done that, I’m pretty sure I could still create a magic view as described above (though my filter criteria would be a little different and I wouldn’t need the relationship). It seems this would make things even more streamlined for the content updater. I’m not really sure why I gravitated towards making Song a separate content type, but I’m now second guessing this decision. If anyone has an opinion on this, I’d love to hear it. I find the Drupal documentation “out there” does a good job of explaining how to do things, but sometimes leaves noobs like me in the dark as to whether to do certain things.