I would like to use Views to create content for custom content type pages. This seems to be consistent with the use of Views in the Admin pages of Drupal 8. I'm running into problems integrating Views (the page content) with the page layout of the page. This should be simple -- but it does not seem to be. In all of this I would like to use the base features of Drupal 8 without custom or contributed modules.

The key functions that I am working to implement is being able to embed a View anywhere I would like in a page. Said another away, I would like to embed several Views (page content) into specific portions of a complex page structure (page layout).

  • In Drupal 6 we have a content type and associated template file. Embedding a View in the template is straight-forward -- we use PHP code.
  • I tried creating Views as Blocks and placing them in different Block layout areas. This became complicated quickly -- to much so. The problem is the page layout must become part of the Views. There may be a solution involving the creation of custom Block layout regions and make the Views part of these new region. The page design has several layers of content for mobile devices. We would need Block layout regions for "Layer 1", "Layer 2" and "Layer 3" which are all part of the page Body. I don't know if this will work.
  • I created a custom module that creates a Block for the page. I can render whatever I want including layout elements and embedded Views content. The problem is I am quickly generating a lot of custom code -- one of my goals is to avoid this.
  • I'm starting to look at Page Manager and Panels for a solution. Bringing these modules into the design for a seemingly simple problem does not seem like the correct answer.
  • It seems there should be a simple way to embed a View into a Twig file associated with a content type. This is where we started -- the Drupal 6 approach. This simple solution has been difficult for me to achieve.

Any ideas?

The content we want to create has four parts. All four portions of content is a part of the "content" region of the page -- the top and three overlays. Here is a rough prototype: raystedman.org/d8/landing

  • 1
    It's difficult to understand your situation from what you say. For example, "The problem is the page layout must become part of the Views." and the more description that follows is unclear to me. If you could explain more clearly how the content breaks down, are these content types or arbitrary pages, etc., then we might be able to give more precise answers. Generally speaking complex but easily manageable layouts usually requires the use of contrib modules, but in many cases this leads to a simpler site overall than a mass of custom code and templates.
    – Jonathan
    Commented Dec 25, 2015 at 18:31
  • Thanks for your question Jonathan! The content we want to create has four parts. All four portions of content is a part of the "content" region of the page -- the top and three overlays. Here is a rough prototype: raystedman.org/d8/landing
    – Greg Sims
    Commented Dec 26, 2015 at 18:58

3 Answers 3


It seems like you have a content type, and there are many different content items of that type, each content item being its own "page".

Each content item has fields containing content unique to that content item. But on the page for each content item, you would also like to show multiple views listing other content (of the same or different content types). The content of these views is not the same for every page, but is filtered or tailored in some way to fit the current content item.

These views and fields appear in various regions of the page, which will be rendered in various ways depending on device, including as tabs.

If all this is true, then your problem is all about how to generate views tailored to the current content items. This is a very common problem, and there are many different solutions.

  • You could write the whole thing in custom code, slipping in the view at a number of possible points in the rendering process.

  • You could take use the power of views to take on the task of rendering of the content type, and the views_field_view to embed your child views inside the main view. Views provides tabbed pages which might suit you.

  • In D7, you would reach for the Entity Views Attachment (EVA) module (with 50k installs). This module does one thing and does it simply: it enables you to add a view as a field on a content item and pass that item as an argument to the view. Sadly, it has no D8 port.

  • In D7, you could use Panelizer, Panels and Ctools. Together these allow you to take over the page rendering for a content type, defining regions on the page, allocating regular fields and/or "views content panes" to regions, and passing the current content item as context arguments to the view. The Panels approach is mature, beloved of many Drupal professionals, powerful and flexible. The Panels family is in heavy development for D8 are expected to become useable in the next few months.

  • Display Suite allows you to add extra display fields to a content item, and these can include views. By setting the views to use contextual filters, they can get the identity of the current content item from its URL and filter themselves based on that. The only disadvantage of this route is that because of this URL dependence you don't get the contextual filter of the view working properly if the view is embedded in another view, it only works on the content item's page. DS is a major Drupal module, and has a relatively mature D8 release.

  • Views_field_view already has a working D8 port. It works similarly to EVA. The only catch is that it's more sophisticated, in that it allows editors to specify view arguments for each content item. If you don't want this, you can set the current content item as the "default" and choose to "force the default".

  • Display fields is a new D8 module. It gives EVA-like functionality, alongside other useful things. See https://www.drupal.org/node/2639296 for notes on how to use it for views.

  • 'Views field formatter' is yet another module in the same space. It's D8 version is almost but not quite ready.

Which of these options you choose may depend in part on how you want to handle the tabs, whether these are Drupal-managed navigation leading to separate URLS, or whether they are just part of the theme-managed HTML page controlled by CSS or Javascript.

  • This is a great reply Johathan! I've thought about the trade-offs with regard to using tabs. I don't see the value of having separate URLs for portions of the same page. We are working on a Huge website and the number of URLs we have is difficult to manage as it is. I am leaning heavily towards "theme-managed HTML page controlled by CSS or Javascript" -- the prototype I posted is done with Bootstrap. What do you think of the trade-offs between a module driven approach vs. Views for content and Twig for layout -- as suggested by Berdir?
    – Greg Sims
    Commented Dec 30, 2015 at 2:11
  • Specifying everything in code like this seems to be ignoring a large part of what Drupal can offer. Placing blocks in regions, and using contextual filters in views to filter based on content id from url, are now core Drupal functionality and can take you a long way to what you want. It would seem to make sense to use something like this, probably supplemented by Page_manager and possibly by Panels. I'd place and define things by UI, and then use the theme layer to style and tab-ify. Please accept my answer if you like it:)
    – Jonathan
    Commented Dec 30, 2015 at 11:06

You can still embed views in templates, just prepare them in yourtheme_preprocess_TEMPLATE(&$variables), put them in $variables['some_key'] and then display in your template as {{ some_key }}.

I'm starting to look at Page Manager and Panels for a solution. Bringing these modules into the design for a seemingly simple problem does not seem like the correct answer.

I don't see why it wouldn't be. It's possible to do a lot more with just Drupal 8 core than before, but not everything. Using contrib modules is perfectly fine, as long as you try to not add every single module out there to your site.

The only problem is that it is a bit early for many contrib modules unless you know what you're doing and can dig into the code in case you run into issues.


I had exactly same problem. I had set "access" to certain "roles" I had defined. I had not checked "Authenticated User", since I did not want all roles to have access. So I made checked "Authenticated User" and it worked fine. I then went back and unchecked "Authenticated User" and low and behold, it still worked... only Drupal knows why!

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.