Using Views in Complex Pages

Question

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

Answer 1

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.

Answer 2

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.

Answer 3

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!