Entity Views Attach: Use Views Almost Anywhere

Entity Views Attach (EVA) is a wonderfully useful Drupal module which makes Views more powerful.

EVA allows you to automatically attach any view to content, comments or terms.

We're going to show you 2 examples of EVA in use. Both of them solve problems that were asked by our members this week.

First, we'll see how to sort terms however we want and then we'll see how to add an image for a file download link.

Example #1: Sort taxonomy terms

You can download EVA from https://drupal.org/project/eva.
Here's the first problem we face. We don't have any way to contol the order of our taxonomy terms. Our training member wanted to take control of the ordering and sort these terms alphabetically.

Let's go and create a view that will sort our terms.

• Go to Structure > Views > Add New View
• Choose to show "Taxonomy terms" and then select the terms you want to show. In this example, we'll show "Tags".
• Choose the Display format you want, but you must choose to show fields.
• Click Continue and edit.

• At the top of the Views screen, click Add and then choose EVA Field.

• You will now see a new area of Views called "Entity Content Settings":

• Click Entity Type and choose where you want to attach this View to. In our example, we chose "Node".

It's worthing noting that you can also use EVA to attach Views to Comments, Terms or users. For example, you might want create a View showing the content that a user has created and show it on their profile. In that instance, you would choose "User".

• Click Bundles and choose which content type you want to attach this View to. In our example, we choose "Article".

Finally, we need to make sure that EVA will only pull in the terms that have been added to the content we're looking at. Otherwise, we'd end up with a very long list.

• Under Advanced, click Add next to Relationships.
• Check the box "Taxonomy term: Content with term" and then on the next screen, check "Require this relationship".

You are now free to create the view as you wish. Here's one change we need for our example:

• Under Sort Criteria, choose to sort the view how you wish. In this example, we choose "Taxonomy term" and "Sort ascending".

• Save the view.
• Visit any article on your site with terms and you'll see that your new view has been attached:

If you want to remove the original Tags field, go to Structure > Content types > Manage Display and move the "Tags" field to the "Hidden" area:

Example #2: Changing a download link into an image

Here's an alternate example of EVA in action. In this example, our member wanted to change a file name into a "Download image".
We've shown how to do this before with Display Suite. Now we'll show how do it with EVA. The image below shows the problem - the file name is showing instead of a download button that we can style.

• Go to Structure > Views > Add New View
• Choose to show an "Unformatted list" of "fields"

• Click Add > EVA Field
• Click to add a new field and choose "File: Path"

• Check "Display download path instead of file storage URL"

• Check the box for the "REWRITE RESULTS" area.
• In the Text area, use HTML to show an image and a link. We can use the Replacement patterns to automatically insert the URL with [field_file]. To do this, you will need to know the URL to the image, which in this example is http://bit.ly/19ZE2db.

• Look under "Entity Content Settings", Click Entity Type and choose where you want to attach this View to.
• Click Bundles and choose which content type you want to attach this View to.

We now need to add both a Contextual Filter and a Relationship.

• Contextual Filter: select "Content: NID"
• Relationship: select "Content: File". Make sure to check the "Require this relationship" box.

That should complete the process and the image will show. Click on it and you'll download the file.

Remove Duplicate Views Results

When you are building a Drupal site and creating views, it's not uncommon to find that your view is showing the same result multiple times.

Here are two common ways to remove duplicate views results.

Option 1: Distinct

This is how Views describes the Distinct option:
"If there are multiple identical items, each will be displayed only once. You can use this to try and remove duplicates from a view, though it does not always work."

• Open the Advanced area.
• Next to "Query settings", click "Settings".

• Check the boxes, "Distinct" and "Pure Distinct".

Option 2: Aggregation

Aggregration is often used to perform calculations on field data. For example, you can use Aggregation to count the number of content items in a particular content type. Or you could use it count the average number of comments on your content.
However, if the Distinct option doesn't work, we can use also try to use aggregation to remove duplicate items.

• Open the Advanced area.
• Next to "Use aggregation", click "No".

• Check the "Aggregate" box.

• On the left-hand side of the view, notice that "Aggregation settings" is now an option in several areas.
• Click "Aggregation settings" for your Filter Criteria.

• Choose "Count DISTINCT".

• Click on the name of your Filter Criteria.
• Choose "is equal to" and set "Value" to "1".

Colorbox Pop-ups with Drupal Images and Videos

A lot of sites like to show media inside pop-ups. Using pop-ups can make it easier for visitors to quicky browse through multiple images or videos.

In this tutorial, we're going to show you how to use the Colorbox pop-up with Drupal.

We'll see how to display both image and video fields inside a pop-up window.

Installation

Install these two modules:

• https://drupal.org/project/colorbox
• https://drupal.org/project/libraries

Now we need to get the actual Colorbox files:

• Download the Colorbox plugin from https://github.com/jackmoore/colorbox/archive/1.x.zip
• Unpack those files and rename the folder to "colorbox"
• Upload those files to your "sites/all/libraries" directory. Make sure the path to the plugin file becomes: "sites/all/libraries/colorbox/jquery.colorbox-min.js"

Now configure Colorbox:

• Go to Configuration > Colorbox
Check the box "enable colorbox load"

Colorbox with Image Fields

• Go to Structure > Content types > Manage fields
• Add an image field
• Click the Manage Display tab
• Set the format the image to Colorbox.

• Click Save.
• You'll now see some formatting options for the colorbox on this field:

• Click the small cog icon and those images will show:

• Go and create a content item using your new image field. In this example, I've uploaded 4 beach photos:

• Click any image and you'll get the videos showing inside a colorbox. If this doesn't happen the first time for you, clear Drupal's cache.

Colorbox with Video Fields

Now we'll show you to display video inside a pop-up. We're going to use the Video Embed Field.

• Install the Video Embed Field module.
• Go to Structure > Content types > Manage fields
• Add a Video Embed field
• Click Manage Display
• Set the Format to Thumbnail Preview w/Colorbox:

• Go and create a content item using your new video field:

• Drupal will automatically create a thumbnail for you from the video:

• Click the thumbnail and you'll get the video inside a pop-up:

Should I Re-use Existing Drupal Fields?

Drupal gives you the ability to re-use fields. If you have an "Image" field, you could choose to use that same field on every content type on your site.

However, it's not always clear whether re-using fields is a good idea. Sometimes it is, sometimes it isn't.

Here's an overview of the advantages and disadvantages to consider before re-using Drupal fields.

General advice on re-using fields

You can choose the "Add existing field" feature whenever you go to Structure > Content types > Manage fields:

The Drupal.org documentation does not recommend that you re-use fields:

"It is recommended to create new fields, rather than reusing existing ones, unless you have a clear reason to do so".

That's also the general consensus amongst Drupal professionals that I talk with. There's nothing inherently wrong with re-using fields, and it can be a useful approach in some situations, but it can also cause more problems than it solves.

Advantage: simplicity and time-saving

The Drupal Field UI documentation says this:

"reusing fields can save you time over defining new fields."

That's true, but the time-savings are very small. A more compelling advantage is that re-using fields can sometimes make site administration simpler. Web Initiative sum this up nicely:

"Reuse of fields can also reduce the system’s complexity. Instead of creating and maintaining 10 different fields, Drupal admins maintain only two fields and their documentation. Database administrators only need to improve performance of two extra tables. KISS is always a good principle."

It definitely would be easier to apply permissions, setting and design elements to one re-used field rather than 10 unique fields.

Advantage: some content works well with re-used fields

Back to the Drupal Field UI documentation again:

"reusing fields also allows you to display, filter, group, and sort content together by field across content types. For example, the contributed Views module allows you to create lists and tables of content. So if you use the same field on multiple content types, you can create a View containing all of those content types together displaying that field, sorted by that field, and/or filtered by that field."

One comment writer on the Drupal.org documentation makes the same point about Views. They point out that Views can combe content in sophisticated ways. So, if you have multiple different content types, with different date fields, then Views can combine them into a single view. However, they also point out that Views isn't so sophisticated with sorting. So, if you have multiple different content types, with different date fields, then Views will struggle to sort the content on all those different date fields..

Disadvantage: Re-used fields are inflexible

Brandon Williams on Twitter summed this up nicely:

"at first it's a good idea, but give it a few weeks, reqs change, you end up creating separate ones anyway"

To a large degree, if you choose re-used fields, you are limiting the changes you can easily make to your data later.

Disadvantage: Re-used fields make data harder to export or migrate

Re-using fields could become an issue when you need to export your data or when you need to migrate to a new version of Drupal or another platform.
Each Drupal field has it's own database table, as shown below. Extracting that data can be tough. The Features module (the most common way to export Drupal data) struggled for a long time with shared fields, although current versions can handle them more effectively.

Whenever you start to build dependencies between codebases or database tables, you add complexity to your site.

Advantage or disadvantage? Performance

The Drupal documentation outlines one possible benefit of re-using fields:

"From a performance point of view, you don't want to have a gazillion fields on your Drupal site. If a content type (or other entity) has a lot of fields, saving the content will result in a lot of database writes that might take time. Also, the field configuration itself might take a lot of memory to load from the cache (and that is done pretty often)."

This thread on Stack Overflow has a very relevant discusion on performance. It includes this comment:

"A real problem however is the number of fields you have. Because currently in Drupal 7, the complete field configuration of all fields, no matter if they're loaded or not, is fetched from the cache on every single request. I've seen sites with 250+ fields, where loading and unserializing the field configuration takes 13MB+ memory." (that has been improved with Drupal 7.22)

So, re-using fields could possibly give small performance improvements by letting us have a lower total number of fields.

However, those small improvements may lost elsewhere. This from Web Initiative again:

[fields] extra complexity to a Drupal system. When creating a new field, the field’s definition is added to the field class table and the field’s configuration is added to the field instance table; meanwhile, a new table is added to the Drupal database to store the field data. Database tables add complexity to the system. In addition, queries of nodes will incur JOINexpressions of tables to field data. Multiple JOINs will impact database performance since MySQL responds poorly to queries with multiple JOINs of tables if not properly configured."