- I’m working on a site that contains several complicated views (many exposed filters). The views render entities using a couple different view modes. These view modes use Display Suite. Within these view modes I’ve leveraged DS custom fields for several needs.I needed to render a node “Edit” link within some of these view modes. The user would click the edit link, edit the node, then click “Save”. The system would then bring the user to the exact position of the page they were on before, filters and settings intact.This type of solution would work without Display Suite (leveraging other methods). You’re getting a DS-based example because that’s what the site called for.In my particular case I needed to separate the anchor from the edit link. If you’re okay having them in the same place you could skip Step 1 and just include the anchor within the markup for the edit link.
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.
[UPDATE January 30, 2020] After some discussions with a colleague I decided the world needs a Plugin-based approach to the solution below. We talked through how it’d work before going about our day. After writing the info file, .module file, and prepping the folder structure I realized I never checked to see if this already existed.
I was pleasantly surprised to see that Sutharsan had already created a module that fits the bill! Extra Field is nearly identical in structure and implementation as what I’d planned to build. I just finished writing my first ExtraField\Display plugin and it works beautifully! I will leave my post below in tact, but I highly recommend stopping here and simply using Extra Field. Note that the README.txt file is worth reading, and there is an extra_field_example sub-module that explains things quite well.
NOTICE: This works fine in Drupal 7. For Drupal 8 please note: https://www.drupal.org/node/2863420
This may not work with paragraph bundles (because you don’t have a Token view mode). Maybe there’s a way, but I don’t have time to mess with it.
Sometimes as a developer you need to provide your Drupal authors with the ability to choose different variations of a particular content object. For example, imagine you have a Callout paragraph bundle and you want the author to choose between a Dark or a Light colorscheme; if the user chooses Light, the font colors appear dark over a light background. To achieve this you need a dark or light class on the entity wrapper based on whichever the author chose; this would let you write CSS to target each color scheme. Using Display Suite this is an easy problem to solve and doesn’t require any preprocess code or other hand-coded solution.
Out-of-the-box, the Entity Reference module doesn’t provide a way to access the referrer entity’s fields from within the referenced entity. I have two ways of doing this. The first is to patch the entityreference module (not ideal unless this patch went out to the community via proper channels; perhaps I should get on that?). The second is to mimic entityreference’s “Rendered entity” field formatter but modify it to include the referrer information. I recommend the second method for now.
Disclaimer: As with most tasks in Drupal, there are several ways to do this. My goal here was to see how quickly it could be done without writing code and without introducing unnecessary complexity.
Goal — quickly implement a newsletter listing (using Views) that can be dropped into any paragraph field and can have a unique title per use.
The output would be a simple block from Views. We already use Display Suite, so naturally we use a DS-centric approach.