Feeds

Author

Upgrade Your Drupal Skills

We trained 1,000+ Drupal Developers over the last decade.

See Advanced Courses NAH, I know Enough
Apr 07 2021
Apr 07

Switch view modes for all entity types editorially with our new Drupal module!

Interaction with the View Mode Switch Field Modul 

Separating content from layout, ensuring high flexibility for the editorial team when creating content, as well as a simple and consistent CMS - this all sounds absolutely reasonable and can also be implemented very well in Drupal. With its modular structure and the ability to extend its functions through various contrib modules, this is already possible in Drupal. Nevertheless, in our projects we have noticed over and over again that editors need even more predefined layouts (e.g. for different arrangements in text-image elements, teaser variants, etc.) from which they can select individually and thus determine the output.

Different view modes Layout variants of the configured view modes in the output

This idea is not a new one. There are and have been different approaches within the Drupal world for managing output options:

  • In Drupal 7, there were two major players Display Suite (ds) and Panels (panels) for layouting content. Both had their advantages and disadvantages, but both have lost their relevance in Drupal 8/9 due to the Layout Builder.
  • With the Layout Builder in Drupal 8/9, the editorial team can be extremely flexible in customizing the layout of content. Even too flexible, so that it is also up to them to take care of the consistency in the layout of the page.
  • For Drupal 8/9 there is a contrib module called "View Mode Selector", which provides a similar functionality as our new module. This gives the editors a choice of (only) one defined view mode, which in practice is usually not enough.

So why yet another new module?

Quite simple: We were missing versatility and flexibility for site builders as well as editorial teams. Especially for larger projects, when the Drupal site is extensive and many people are involved in the editorial team, this becomes more and more important.

This is when it is extremely helpful to be able to select different predefined view modes with different layouts/templates for all relevant entities and still maintain the layout consistency of the site. This is how the View Mode Switch Field module was born.

In a nutshell, the View Mode Switch Field module does the following: It allows site builders to provide different defined view modes for fieldable entities. This allows editors to choose between predefined view modes and thus control entity output more flexibly. For example, editors can highlight article teasers in a listing or change the arrangement of image text paragraphs.

Layout Builder View Mode Switch Field Configuration of the layout variants as view modes with the help of the layout builder

The simple magic behind the View Mode Switch Field module

Site builders can include any number of view mode switch fields per entity bundle, so that editors can independently switch one or more view modes per field. Of course, the created view modes can be subsequently adjusted, changed or even deleted - without affecting the content of the Drupal page itself. Any configuration change to the corresponding view modes will also be applied to existing content. In case of missing view modes the layout jumps back to the defined default setting.

To use the module, there are only a few simple steps for site builders:

  • Create and design the view modes.
  • Add and configure one or more view mode switch fields via the Field UI - here it is possible to allow any number of view modes to be switched per field and to define which view modes can be switched to.
Settings View Mode Switch Field Modul Field configurations of the View Mode Switch field

A wide range of benefits

As mentioned before, the View Mode Switch Field module mainly improves versatility and flexibility for site builders and editors. This is still quite general and applies to many Drupal modules. So here we want to give you very specific points where the module will help you:

  • Content and layout are still considered separately. This means that both can be adjusted independently of each other.
  • The module strikes a good balance between freedom and flexibility for the editorial team and compliance with CI guidelines. The editorial team is only given really necessary options, so that a consist look and feel of the design is automatically preserved.
  • Data structures (e.g. the field set of a paragraph) only have to be defined once and can still use different output options. Instead of creating a new paragraph type for another display, e.g. an inverted text-image combination, this can be controlled by selecting the view modes.
  • By avoiding duplications in the data structure, the editing interface becomes and remains lean and clear.
  • The way the module works avoids possibly unperforming preprocesses and templates for the actual layout switching. In addition, the use of view modes ensures very good cache behavior and thus high performance.
  • Subsequent global layout changes affect all (new and existing) entities. For comparison: e.g. with Layout Builder, the layouts overwritten per entity are decoupled from updates.
  • The implementation based on the Drupal Core Field API enables site builders to perform all the functions already known for entity fields - for example, generating entity listings based on specific View Mode Switch field values (whether for editorial overviews or administrative information).

Last but not least

As an agency, we handle a wide variety of projects and like to use the View Mode Switch Field module for them. The module is particularly useful in Drupal projects that use a component-based layout/design approach. Editors can use it to select individual building blocks (entity bundles) from a ready-made construction kit (content types, paragraph types, etc.) and display or "paint" them differently (view modes with defined layouts).

Since it is extremely important to us that our projects run smoothly at all times, we equip them with automated tests by default. The View Mode Switch Field module also comes with extensive test classes that ensure the runability of the module code for various scenarios.

The View Mode Switch Field module is shared in the Drupal community and is available for anyone to download. Try it out and feel free to give us feedback in the Drupal issue queue!

Oct 21 2014
Oct 21

Don't you know that, too? You or your team is building a site and during this process all implemented parts are styled through templates and CSS. The CSS files (at best you are using a CSS preprocessor like SASS are getting bigger, more sophisticated and even more confusing - not to mention that these files are getting almost unmaintainable and more and more error-prone. Of course you can reduce risks a little by sticking to standards like SMACSS, but you will reach a point where it is almost impossible to keep track of all changes - especially when a team of several members is involved.

By now at the latest, you should have a styleguide that provides an overview of all styled components of the site... But where will you find the time to create one now? And who takes care of it to ensure that all future components will be included? There is a simple solution - the Living Styleguide!

At DrupalCon Amsterdam 2014 there was an interesting session by John Albin Wilkins, which covered this topic. Apart from an introduction about agile development, he explained in detail how team members may automatically create a styleguide during the development process by using the Knyle Style Sheets (KSS) tool or more specifically by its Node.js implementation kss-node. This automated styleguide allows to examine and review every component of the site on its own - even without the context of the actual site itself.

Sounds complicated, but it isn't!

kss-node is easily installed by the help of Node Packaged Modules with a one-line command (`$ npm install -g kss`). Now you only need to place a `styleguide.md` file in the source directory of your style files (the directory containing e.g. CSS, SASS or LESS files), which is used as the entry page for your styleguide and may be filled with any generic information about your project at will.

The following command then generates the styleguide:

$ kss-node "path/to/styles-directory" "destination/of/styleguide-files" 

Visit the kss-node project page for a full reference of the `$ kss-node` command.

The styleguide directory now contains all generated styleguide files. But wait... apart from the entry page, which was generated from the `styleguide.md` file, it is completely empty?!

This happens, because we do not provide any real data for the parser yet. But this is also done in a breath: With the help of simple annotations in the comments of your style files, you may provide information about the expected markup and its corresponding styles. It is even possible to provide Modifiers for different states of a component (e.g. `:hover`- and `:active` state of a button). Here is a basic SASS example:

_buttons.scss

// Buttons

//

// Just add your descriptive text about buttons here //

// Styleguide 1

// General styles

//

// Add even more descriptive text...

//

// :hover - State: Hovered

// :active - State: Active

// .btn-medium - Size: Medium

// .btn-large - Size: Large

//

// Markup:

// 

// // Label

 

//

//

// Label

//

//

// Styleguide 1.1

.btn {

background: #83B81B; border: 2px solid #83B81B; color: #fff; font-family: sans-serif; font-size: 0.75em; padding: 1em; text-decoration: none;

&:hover {

background: #fff;

color: #83B81B;

} &:active {

background: #fff; border-color: #000; color: #000; } &.btn-medium { font-size: 1.25em; } &.btn-large { font-size: 2em; } }

Visit the KSS projct page for a full annotation syntax reference.

Et voilá: After running the `$ kss-node` command explained above again, the styleguide now contains a new Buttons section, which provides previews for all Modifier variants of the button component.

More styleguide examples

And there is even more...

  • As Markdown is supported, all annotations may contain any Markdown syntax
  • Use `$ kss-node --init "your-template"` to initialize a custom styleguide template, which then may be adjusted to all your special needs. Add the `--template "your-template"` option when running `$ kss-node` to use this template for generating the styleguide
  • Generation/updates of a styleguide may be automated with a task manager like Gulp
  • ... Everything else is up to you!

It will be interesting to see how this tool will mature in the future and if there will even be a Drupal integration for the automated generation of all the source code snippe

About Drupal Sun

Drupal Sun is an Evolving Web project. It allows you to:

  • Do full-text search on all the articles in Drupal Planet (thanks to Apache Solr)
  • Facet based on tags, author, or feed
  • Flip through articles quickly (with j/k or arrow keys) to find what you're interested in
  • View the entire article text inline, or in the context of the site where it was created

See the blog post at Evolving Web

Evolving Web