Display-only Pseudo Fields in Drupal 8

In the past I’ve been happy to rely on Display Suite to create what I call “Frontend Only” (DSField) fields (which I created via php). These fields appeared in the Manage Displays screens so that site admins can easily drag them around in the display as needed. As it turns out, you can achieve nearly the same result using a few built-in hooks in Drupal 8. The Display Suite DSField plugin has a few handy helpers like the ability to only show the field on specific display mode forms (e.g., show the field on Full content but not on Teaser). You can still control whether or not the display-only field renders if you use the core hooks, so we’ll be okay.

Before I show the code, let me give some background.

This is a paragraph bundle with a machine name of news3col. This bundle has a News Items field and a Tag field. If the user picks items via the former, the latter won’t render. If the user does not pick News Items but does pick a tag we load a View filtered on the chosen tag. Lastly, if using tags, we render a More link to the listing page filtered on the tag, otherwise we render a More link to the listing page without the tag filter.

Below you’ll see what the Manage Display screen looks like. Notice how I include the name of the module where the custom field comes from; this makes it easy to track down the source.

Manage Display screen

To get these custom fields to show up on the Manage Display screen you can use hook_entity_extra_fields_info(). These should go in your custom module’s .module file. My module is called bps.

After a cache rebuild the two fields will appear.

Next, we need to make them do something. This is done via hook_ENTITY_TYPE_view().

These functions show a few things:

  1. How to check for a component on an entity and do something if it exists
  2. How to render a view as a pseudo display-only field
  3. How to check if an entity field has a value
  4. How to render a link to a URL with parameters
  5. How to pass contextual filter values via query parameters
    1. My listing view is a block that lives on a basic page at /news (not a Views-based page).
    2. This block has a “Has Taxonomy Term ID” filter with “Provide default value” set to “Query parameter”. This is how I am able to affect filters via the URL (like /news?tags=5).
The last piece of the puzzle is optional. In my case I needed more control over the paragraph output itself, so I had to make use of these two fields. They’re available in the content array as shown below:

What About Twig for Everything?

Great question! I too wondered this, so I attempted to meet my goals with Twig and Twig  Tweak.

I was able to achieve the exact same results with no PHP and the following twig template code (replaces what’s shown just above this section):

So, which will I ultimately commit to the repo? Pseudo-fields, or Twig?

I prefer the transparency of the pseduo-field, php-based approach. The site admins can clearly see that we’re introducing a few extra “Fields” via PHP. If we brought the view into play via Twig it wouldn’t be too obvious why a view was being rendered. With that said, there is a lot more code in the pseudo-field solution. I’m on the fence, especially if I drop a warning message on the display mode edit screen suggesting that there is some logic in a twig template.

Tagged with: , ,
Posted in Development

Leave a Reply

Your email address will not be published. Required fields are marked *

*