Drupal Tvi


Our First Site Built with Drupal 8 - How we did it.

I'm happy to say that we relaunched our parent agency's site on Drupal 8 within one day of Drupal 8's release, however it would have been the same day if we didn't encounter some last minute 'drush up' fails causing us to rebuild some parts of the site (all the the page manager variants that magically disappeared in the updates). Regardless, we got it up and here are the highlights of our experience and also a few mini tutorials.

Drupal.tv was created by students of the career-changing Debug Academy and is currently maintained by its staff, alumni, and supporters. Drupal.tv Newsletter. Learn about new videos, conferences and articles by the Drupal Community. I agree to receive Drupal.tv's newsletter. You can unsubscribe at any time by clicking the link in the footer of. In Drupal 8, site building feels very familiar to Drupal 7, so getting accustomed to the new system wasn't difficult at all. However the feeling of impotence set in when we realized that our usual method of building a site had to change since our goto toolset wasn't available. The idea behind the Taxonomy View Integrator (TVI) is simple yet powerful: You edit an existing vocabulary (or term!) and you can select a specific view and display that you will be used to render the specific terms ( either for the whole vocabulary or the specific term. If you need an example to better understand the power in your fingertips. I created two vocabularies taxonomy: products and gallery. Created two different views of these terms. Includes standard representation 'Taxonomy term' and now on the product page of the node are. To further clarify, I did some additional tests. Starting out, the vendor directory doesn't exist. The first composer install puts all packages into the vendor directory. If I then remove the vendor directory and run composer install again, the same thing happens. However, if I leave the vendor directory and run composer install again, the packages end up where they are supposed to.

Building a real site in Drupal 8

We started in the D8 Beta stage with a fresh install, then scratched our heads because our usual building block D7 modules weren't ready yet, like page manager, panels, panelizer, webform, to name a few. I feel like we were a bit spoiled in D7 because we leveraged contrib modules so much that going back to template files felt a bit foreign. So this forced us to rethink and get back to the basics of building a Drupal site.



Working with Twig

There are a ton of great tutorials out there to get you started with building a new twig theme, so I won't go there. Once you get past those nuances, the actual theming process is very similar to D7. Just edit your template files and add the twig variables.

The coolest part about Twig is enabling the Twig debugging, which shows you in the code where theme file suggestions begin and end. This made it really stupid-easy to find out what theme files we needed to edit.

The hardest part about working with Twig is getting the variables you want. You can use {{ dump }} which always caused me to run out of memory or {{ kint() }} which worked but didn't always show me what I was looking for. Ex. When I was seeking out the url of an unrendered image field, if took hours of searching to find the right answer. Thank god for stackexchange because many answers are there, but I think we're in need of a resource to explain how those answers were derived.

For example, to display an image field URL in a twig template file, it's {{ node.field_your_image.0.entity.uri.value }}. This wasn't something we could find in the array dumps.

Drupal Tvi

To sub-theme or not to sub-theme

We never really needed subthemes. When we first started building Drupal sites back in 2008, we always built our own themes. If you're starting with pre-built html and css mockups, then just inserting Drupal's theme variables is quite easy.

I think it's best to start out this way because then you get a feel for what drupal outputs naturally, whereas if you always used a base-theme, you don't know if the output you're looking at was a product of native drupal or some magic of the sub-theme. Some people may not care about this, but you will care when you have to debug something and you don't know where to look first – was it drupal, the sub-theme, or a module?

So our approach with Twig was the same, no sub-theme. The cleanliness of Drupal's output in D8 is wonderful and very easy to work with.

Adding in some Bootstrap

We're huge fans of the bootstrap framework and in D7 we had the best setup – bootstrap base theme with the panels bootstrap layout builder. This allowed us to rapidly build bootstrap sites extremely easily.


In Drupal 8, the bootstrap base theme wasn't really necessary for our site as we could just simply add in the bootstrap coding through our theme files. In the past, the area where we really needed the bootstrap theme's magic was for theming form elements since bootstrap has a particular group of form classes and structure that takes some finagling to get drupal to output. Luckily in our case, we only have one form and it was easy enough to form_alter to get the structure needed.

Site Building

In Drupal 8, site building feels very familiar to Drupal 7, so getting accustomed to the new system wasn't difficult at all. However the feeling of impotence set in when we realized that our usual method of building a site had to change since our goto toolset wasn't available.

The scary world of contrib modules

Everytime we enabled a module, it was a scary, cross-your-fingers moment. So many known reliable modules from Drupal 7, could easily blow up a site in D8. Backup and Migrate, Admin Menu, and Webform caused fatal errors for us making the site unusable. We quickly learned that deleting the module and then deleting everything in /sites/default/files/php was a way to recover.

Page Manager & Panels

We use Page Manager, Panels, and Panelizer a lot. And for the custom layouts we needed for the new site, we had to make them work. Page Manage actually kinda works and Panels kinda works. Panelizer, as of this writing, does not.

We used a custom (Page Manager) page for each page in the site and then created custom panel layouts for each – since the panels layout builder doesn't work yet. There isn't documentation for how to actually add custom layouts so we figured that out with some trial and error. Here's a mini-tutorial on that:

How to create a custom Panels layout in Drupal 8

1. Add a yourtheme.layouts.yml to your theme. Here is an example with for our blog layout:

2. Create actual files for the custom panel layout in your theme. In this case it's:

  • sites/themes/yourtheme/layouts/blog/blog.html.twig
  • sites/themes/yourtheme/layouts/blog/blog.png
  • sites/themes/yourtheme/layouts/blog/blog.css

3. In blog.html.twig you simply add your custom markup and variables for the regions you defined in the yourtheme.layouts.yml file. So in this case, our file looked like

And that's basically it. Clear your cache and now you should be able to select it when you add a Panel to your Page.

Views rocks

It's great having views right out of the box. It works just like Drupal 7, so no surprises there. I was right at home. Now that all the taxonomy pages are driven by views, that made it really easy to theme them without the need for an extra module like TVI or Taxonomy display.

No views theming suggestions

Drupal tvi

One feature missing in D8 Views, that was extremely helpful in D7 views, was the Theming Information link in each view that showed you all of the theme file suggestions you could use to theme each part of the view output. The syntax of the files names are always so long and confusing, and then you have single and double dashes with underscores and more dashes, it can be a nightmare for someone with a little dyslexia (like me). So we had a separate D7 install with the same views just so we could get the theme filename suggestions. Eventually, not having the theme suggestions, forced me to learn their syntax, so I guess that made me a better themer in the end.

Blocks rocks

I found that a majority of my content now lives in blocks. In D7 there was this big anti-block movement, but in D8 it's kind of the only available tool. When building a Panel layout, you can't create custom content panes, they aren't there yet, so the only option is to add blocks.

What's nice about D8 blocks is that they have block-types, can have fields added, and can be added more than once on the blocks layout page. The UI is a little confusing because when you delete a custom block from the blocks layout page, it just deletes its placement, not the actual block. But once you get used to it, it's all very functional.


For many years Webform was our goto form module. In D8, it's not ready. Entity form was our next option (eform in D8) and it does allow you to build form with native fields, however it relies on Rules to send emails… and Rules isn't ready yet. So the only option left, which I didn't even consider was the built-in Contact module. For years, it's been a pooped-on module no one uses. But in this case, it was the only option that actually worked. And paired with Contact Storage, which saves the form submissions, it's a workable solution.

While Contact module does work, I consider it a temporary solution until webform is ready. It's not very customizable, like you can't change the email formatting or the button label without digging into code.

For client projects, we'll need something easy for them to use to build and edit forms with and Webform fits the bill. People have been complaining for year about Webform not using Drupals built-in fields, but from a UI stand point I don't want to have to explain to clients was Booleans are or what a List (Integer) is versus a List (float). Webform makes it easy and end-users like easy.

For spam protection, Honeypot is available! And you know how we love honeypot.

What I'm looking forward to

The site building experience for Druapl 8 was ultimately a positive one. Once all the contrib modules catch up it will be useable for our client projects.


For SEO, we don't have a metatag module that works yet, so we had to add meta descriptions by code. That wasn't too fun. Here's another mini tutorial:

How to add a meta description tag in Drupal 8

Open up your yourtheme.theme file and add the following:

You need to create a case for each url.

The Admin menu

I'll admit, I don't like the built in toolbar. It takes too many clicks to get around and I'm always moving it to the left, then top, expanding options on the left, but you can't expand options from the top – it's very frustrating. I want the Admin Menu module. It might not be mobile friendly, but when building a site on a desktop, I'll take all the speed I can get and Admin Menu lets me move quickly.

Global Redirect and Redirect

When you're redesigning a site, the urls are going to change, so the redirect module would be really handy to handle that… it's not ready yet. Instead we have a huge htaccess file of redirects and a stupid 404 page with a mullet guy. For Drupal 8, Global Redirect and Redirect are merging into Redirect, so don't install Global Redirect, also it will crash your site.

Final thoughts

Overall we used a lot less modules than we would have used in Drupal 6 or 7. The lack of available modules forced us to think outside the box and sharpen our chops when it comes to theming and site building. If you want to check out our parent agency site, click here. It's certainly not perfect, but it's our guinea pig Drupal 8 site and will be a continual work in progress.

Drupal 7 has an option to turn on a default View for Taxonomy term pages via the contrib module, Views. This is generally pretty good but if you want highly designed pages with additional custom fields than what the default view renders, you could simply update and customize this view but there's a few drawbacks:

  • You'll be overriding all Taxonomy Pages so it's not very granular.
  • Using the default Taxonomy View won't be too exportable in regard to things like Features.

Creating Taxonomy Theming Granularity

Enter the Taxonomy Views Integrator module aka 'TVI'. This is one of those nice little gems that you don't hear about too often but it's pretty powerful and allows for that granularity that we are looking for here. It enables you to customize only specified Taxonomies with a new custom Views override per Vocabulary. The added benefit is that you can keep the original Taxonomy path aliases. Other methods suggest hackish ways to override Taxonomy term pages by creating an alternate term path alias structure for the overrides but this gets pretty messy.

First Steps

Drupal 8 Tvi Module

It's probably a good idea to have a custom Vocabulary set up beforehand but theoretically you could use the default Tags Vocabulary that comes with the Article Content Type. You'll need the core Taxonomy module enabled but that's already by default with a typical Drupal 7 install. You'll also need the contrib module, Views as well. Next, download and enable TVI. TVI does not do much on its own, you need a view from which to reference for a specific Taxonomy to make this all work. I found the best method is to simply clone the default taxonomy_term view located at /admin/structure/views and customize it but you may need to 'enable' it first. When you clone this view, be sure to name the newly cloned view something meaningful, you can also edit the machine name at this point as well. Ideally, you are doing all this work on a dev or local site, not a live one.

Mind Your Path

Now that you have your new custom Taxonomy Term View, we need to make a few changes to some of the default settings that came with it. For the default 'Page Display', change the Path to something like nopath/%. It really doesn't matter what you put here as long as it's not the default term path which is taxonomy/term/% or any other real path in your site. The reason we do this is we don't want to intercept the original path of the Taxonomies' Alias.

Refining Arguments

The other change we want to do is to alter one the Contextual filters aka Views Arguments. Look under the View's advanced settings for Configure contextual filter: Content: Has taxonomy term ID (with depth). In my case I'm customizing a Vocabulary called 'Image Category', so for the setting, Specify validation criteria, I check the box for that given Vocabulary.

Drupal Tvi

Adding Additional Fields and Customizing

You can pretty much go to town with adding additional fields but you may need to add Views Relationships depending on what you are doing, just be aware of that, your milage may vary. Finally save your View. Note that because there's a Contextual Filter in play, you won't see a preview of your View right off the bat so you can use 'Preview with contextual filters' and fill in an id. For example, I have a Taxonomy term id of 273 so I can input that into the text box and see a preview after updating. This comes in handy as otherwise you are a bit in the dark during configuration.

Connect the Dots

All we've done so far is focus in on our custom Taxonomy Term Page View. However there's still a final step to put it all together. It's time to edit the Taxonomy you want to customize. Go to /admin/structure/taxonomy /[YOUR_VOCABLUARY]/edit. There's a new area called View usage, Check the box called Use view override. You'll see two new select lists appear which are self-evident, Using the view and View display. You can now select the View and display you customized from the cloned view as mentioned above. If all went well, now when you visit your custom Vocabulary term pages, presto, you should see your customized View in effect! One major note is that for any other Taxonomies you don't want customized, you'll simply need to set each to the default Taxonomy term View on the Vocabulary's edit page if you still want the defaults Views intercept to happen.

The possibilities are endless here and it will give your selectively overridden Taxonomy pages a unique look that can be highly designed, it gets away from boring lists of things that are typical of these type of pages.

Drupal Tvi Live


Drupal Tvi Online