Skip to end of metadata
Go to start of metadata


Views Cookbook - Advanced Recipes for Every Web Occasion

Views build and render cycle

consists of four stages

  • Pre-view stage
    • is when the view object is just about to be processed
    • This is a good time to add new arguments. 
  •  In the Build stage,
    • The view object is being processed and constructed.
    • The query isn't built yet.
    • Displays are attached.
    • By the end of this phase, query is built and ready to be executed.
  • Execution stage
    • is when the query is being executed and a array of results is being constructed
  • Render stage
    • has the pre-render cycle and post-render cycle
    • Pre render results are processed by handlers but haven't been rendered yet.
    • Post-render results are converted into markup.

Pre-view hooks

Pre-view hooks can conditionally switch active display. If you have different filters based on the personalization settings, you may flip displays vs alter filters for better performance.

They can also be used to update contextual filters and load values from user temporary storage or state, as well as, evaluate additional permissions based on the current user account object or pass a custom value based on the database query.

Build hooks

  • hook_views_pre_build()

          alter list of attached displays

  • hook_views_query_alter()

          add conditions, sort, grouping 

Execute hooks

  • hook_views_pre_execute()

          last opportunity to alter views object before query is called 

  • hook_views_post_execute()

          has information about the result  this is useful for building custom pagers and render conditions

Render hooks

  • hook_views_pre_render()

          alter results prior to rendering

          can be called from the theme

  • hook_views_post_render()

          results are converted into markup objects

          markup string can be manipulated with regexp

          cache tags can be altered 

Views plugins

  • plugins and handlers
  • plugins participate in views construction /creation process
    • they are responsible for wizard build process, rows, displays, pagers, cache and more
  • handlers are plugins that participate in the build process of the query object.
    • They filter, contextual, filter, sort, relationships

Filter plugin

  • "[my_module]/Plugin/views/filter" namespace
  • Needs "@ViewsFilter" annotation that has plugin id
  • valueForm() - filter form
  • query() - modifies query object
  • adminSummary() - summary for editors in Views UI

custom date range filter, filter by computed properties

Sort plugin

  • "[my_module]/Plugin/views/sort" namespace
  • Needs @ViewsSort annotation that has plugin id
  • query() - modifies query object

natural sort, sort by computed values

Area handler

  • "[my_module]/Plugin/vies/area" namespace
  • Needs @ViewsArea annotation that has plugin id
  • defineOptions() - default values for options
  • buildOptionsForm() - options form for editors
  • render() - Returns valid Drupal Render Array

custom functionality in views header/footer

It can be reused on multiple pages/views

Access Handler

  • "[my_module]/Plugin/views/access" namespace
  • Nees @ViewsAccess annotation that has plugin id, title, help
  • summaryTitle() - text in the editorial UI
  • access() - custom access callback + logic
  • alterRouteDefinition() - additional permissions or role restrictions

Style plugin

  • "[my_module]/Plugin/views/style" namespace
  • Needs @ViewsStyle annotation that has plugin id, title, help, theme, display_types
  • defineOptions()- defulats for the options
  • buildOptionsForm() - plugin options form for editors

custom style: tabs, accordions, masonry grid


I think that this presentation gave some insight on how views work and how some plugins can be used to manipulate the processes that go into each view. 

Creating Ready-Made Development Environments Using Lando


  • Aims to automate several tasks that plague developers
  • Solution to handle version control of php and other technologies

Creating development environments 

  • local machine
  • Ideally same across all developers on a team

Infrastructure is complicated

  • Packages are hard to keep up to date
  • Sometimes, a version conflicts with some other software

Teams are more specialized than they used to be.

It is common that we are all "experts" in our own mind which can lead to different methods of upgrading technologies.

Time is money, simplifying local environment set up can save money.

Lando supports php, mariadb, mysql, sola,r apache, redis, nodejs, and memcacheo out of the box

Lando can bring one line change to version changes such as dev and production.

example for Lando: 

name: chromatic

recipe: drupal9


php: "7.4"

webroot: web

xdebug: false

via: nginx

No sever commands are needed.

Not all developers have to be updated.

Checkout branch and run lando start then lando db-import chromatic-latest-db.sql.gz

Opportunities for further automation


Lando seems like it would help smooth the transition between older versions of technologies to newer ones. I'm not sure how hard this would be to implement into legacy systems though. Most package managers have to be installed and then used going forward. 

Dissecting Tailwind: A Design Tokens Tale

Why use Tailwind?

  • Tailwind allows you to rapidly build modern websites without leaving your html
  • Tailwind is a utility-first CSS framework packed with classes like flex, pt-4, pb-8, text-center and roate-90.


  • CSS utility classes and separation of concerns
  • Solution to BEM class naming guidelines
  • Tailwind has added utility classnames.

HTML elements are content semantics.

CSS class names are design semantics.

What are utility classes?

  • .clearfix is an old utility class but an example nonetheless 
  • utility classes do one very very small thing very well
    • .pt-4  ( padding -top: 1rem;)

What is utility-first?

  • utility-first == no components to start, just utility classes
    • class="bg-bright-blue-600"

Which utility classes are available?

  • go to has the ones that are included by default

size matters

  • by default, tailwind.css has 175,383 lines of CSS
  • 39,004 black lines
  • You should make your own utility classes as needed
  • tailwind.config.js is where you write the kind of utility classes you want to generate
  • specify a limited set of colors, breakpoints, spacing, fonts, font sizes to limit CSS
  • Run PurgeCSS tool on your tailwind.css
    • this tool scans your entire codebase and removes unused CSS classes which gets file size way down
  • Tailwind claims that your CSS grows slower
    • As you write newer CSS, fewer new property values enter the codebase

bundling CSS vs. Global CSS

  • tailwind's global CSS is on every page
  • bundled CSS is only pages where it is used ( can't be done as easily with tailwind)
  • because there is one CSS file, source order is VERY important
  • dynamic classnames can be hidden from PurgeCSS and break the component

Drupal gotchas

  • PurgeCSS has to scan your Twig
  • You can't enter whatever Tailwind Class inside Drupal content editing forms
  • every Drupal WYSIWYG class has to be in code somewhere

Design tokens

  • a limited set of colors, breakpoints, spacing, fonts, font sizes, etc.


  • tailwind uses abbreviations for everything


  • There were quite a few varying opinions on Tailwind. It definitely seems like a viable alternative to things like Bootstrap, but I am not sure if the advantages it brings outweigh the negatives and the time it would take to learn.

Webforms: Choose Your Own Adventure

Why use the webform module?

The webform module is powerful and flexible form builder & submission manager for drupal 8/9.

The module

  • Provides a webform content type
  • Tracks node specific submissions
  • Adds 'References' to the webform edit tab

Webform element features

  • Standard HTML inputs
  • Advanced HTML inputs
  • File uploads
  • Signatures
  • Buttons
  • Rating
  • Image Selection
  • Addresses
  • Entity references
  • Select menu enhancement
  • Computed values
  • Tooltips
  • Slideouts
  • Input masks
  • Word/character counter
  • Regex validation
  • Access controls
  • Unique values

The webform module ships with reasonable default settings, but everything is customizable.

Alternatives to webform modules:

  • Proprietary
    • JotForm
    • Google Forms
    • Wufoo
  • Open Source
    • Gravity
    • NinjaForms
  • Drupal Core


  • Provides a simple and easy to learn markup language for building & bulk editing a webform's elements

Webform Blocks

  • Make it easy to include a webform within layouts and panels
  • Allow a webform to be placed anywhere on the page
  • Allow a webform to be attached to any page on a website

Source entity

  • Tracks and creates a relationship to the Drupal entity from which a webform was submitted
  • allows a webform to be reused multiple times
  • determined via the current route or query string
  • can be used to track: 
    • site feedback
    • event registration
    • application evaluation


  • This presentation was very sporadic. I feel like I would have to get hand-on with the webforms module to get a full understanding of what it could be capable of.  


An Iterative Approach To Decoupling Your Existing Drupal Site With Gatsby

Can we decouple just two pages?

  • Yes, short term
    • Two pages built statically with Gatsby
    • All other content rendered by Drupal
  • long term
    • Any page on the site can be rendered primarily by either React or Twig

Project Structure

  • Monorepo style approach in single repository
  • Three main top level directories:
    • /fe-global
    • /docroot (drupal)
    • /gatsby
  • Front end globals:
    • Sass partials
      • global styles
      • design tokens


  • Focused on building functional components with as littler internal state as possible
  • Different data contexts:
    • Data sourced from Gatsby's GraphQL API
    • Directly within Drupal
    • Hardcoded data
  • Heavy use of storybook during initial phase


  • Content Model:
    • Created new content types for decoupled page templates
    • Continued using paragraphs
      • Surprisingly reasonable to access data via GraphQL API
      • High level of layout flexibility
  • Theme: 
    • Still have traditional Drupal theme
    • Imports partials and tokens fr0om fe-globals as needed

Building the site

  • npm ci && npm run build
  • cp -R gatsby/public docroot/public
  • composer install && vendor/bin/blt artifact:deploy

Component Module

  • Component not components (different modules)
  • Simplifies Drupal integration
    • Define configuration in .yml file alongside js
    • Derives component block from config
    • Can also specify form configuration
    • Form config values added to markup as data attributes

Making GraphQL Data Available Outside of Gatsby

  • Import cached menu data from Gatsby build
  • Gatsby build needs to run before Drupal build

An iterative approach doesn't eliminate all the challenges of decoupling.

In fact, it can introduce some new ones.

BUT it can be an effective way to prove the fit for your organization. 


  • I really think Gatsby is something worth looking into. I have not used Gatsby previously, but I plan to start gaining experience in the near future.


What is JSON:API?

  • JSON:API is a specification for how a client should request that resources be fetched or modified, and how a server should respond to those requests
  • Requires use of the JSON:API media type for exchanging data.


  • A zero(ish) configuration module
  • Drupal's data structures are incredibly well suited to the JSON:API
  • Instantly get APIs for your entities
  • Production ready out of the box

JSON:API vs. Core's REST Module

  • Core's REST module allows for anything (any format, any logic, any HTTP method) and extremely configurable. 
    • Powerful but complex and hence relatively brittle.
  • JSON:API focuses on exposing Drupal's biggest strength  (entites/data modeling) in a coherent manner

Collection of entities are a pain

  • Need to create REST export using Views
  • Need configurations for each ops like sorting, filtering, pagination, etc.

Things which JSON:API can't do

  • Processing business logic
  • New user registration
  • Login/Logout
  • Requesting a new password
  • Customizing response based on certain conditional configurations

When to choose JSON:API

  • Choose REST if you have non-entity data you want to expose
  • In all other cases, choose JSON:API

JS Web Components (Demo)


  • This demo showed off the component module for Drupal.
  • It was designed to reuse web components as much as possible
  • It only takes a .yml file
  • Auto-discovered by Drupal as long as the theme it lives in is active.
  • This looks very interesting, but would take further exploration. 

Decoupled Translations with Drupal and Gatsby

Decoupled Goal

  • Manage content
  • Interface translations in Drupal

Translations in Drupal

  • Content translations
    • Since Drupal 8, functionality is provided by a core module, Content Translations just needs to be enabled and configured
    • Managed by content editors in Drupal UI and translated field values are attached to a single node/entity
    • Can be exposed via JSON:API
  • Interface translations
    • Usually picked up by using the "t" function in templates
    • Managed in Drupal admin UI
    • Usually a one-off translation or when a new feature is deployed
    • They are note exposed via JSON:API. They aren't entities.

Translations in Gatsby

  • Content Translations
    • Nothing out-of-the-box, use source plugins to add content.
    • Can be sourced from anywhere really
    • Add the language via "page context" this allows the identification of what languages we should be using when on a specific page.
    • For Drupal use gatsby-source-drupal plugin with a patch
  • Interface Translations
    • Nothing out-of-the-box
    • The popular il8next framework is often used.

The interface translation process

  • Use t function in frontend code
  • Scan files to find t function usages
  • Push these to Drupal
  • Translate in Drupal UI
  • Pull that down into Gatsby
  • Show translated value in Gatsby


Migrating into Layout Builder

Transitional path for Drupal 8

New modern, column-based approach

Migrate api came to core in Drupal 8.

Source, process, destination are the the steps in manipulating data within Drupal.

Every node is allowed to have a layout override in Drupal 8.

Step 1

  • Migrate in the blocks
    • entity_id
    • delta
    • title
    • body

Step 2

  • Migrate in the nodes
    • nid
    • title
    • layout/body

Building a multisite platform to support your brands

It is better to design once.

Build an architecture with different variations for different use cases

Reuse to meet needs of organization

Better economies of scale

Less development time is required.

Decoupling Drupal for Data

Decoupling is a confusing term. It can mean a lot of things.

Progressive decoupling lets you create a dynamic data-driven web application within an existing Drupal instance.

Many different frameworks have lots of benefits and tradeoffs.  (I feel like making the decision of what technologies to use is half the battle.)

Sometimes just a view is not enough.

Knockout js is a framework I have never heard of before. 

It is open source and written in pure JavaScript.

Fireside chat: JavaScript ate the Web: Key lessons for the Drupal community

This either got rescheduled, retitled, or dropped from DrupalCon.

After several minutes of searching, I can't seem to find it anywhere.

Commerce without Compromise

Drupal commerce is created by Centarro which has a "booth" at DrupalCon.

Drupal commerce can leave the software freedom in place that other solutions such as Shopify take away.

Using Drupal commerce can add extra privacy when compared to other solutions, or at least, not take the data of vendors.

Shopify looks at personal identifiable information of vendors. This could be a problem with markets such as healthcare or other sensitive data.

I think that Drupal Commerce can be a very personalizable solution to ecommerce without compromises.

Future features are said to include a wizard to set up a store out of the box. This could be great and provide a much easier solution to ecommerce.


Automatic Update Initiative Keynote

The number one most important improvement for continued growth in Drupal is automatic updates.

Composer updates need to be secure.

I've never heard of Tuf before. The automatic updates rely on this framework. Might be interesting to check out

Automatic updates are also the number one requested feature to be added to Drupal Core.

Upgrading to Drupal 9 Using the Migrate API

Three processes and plugins.

Extract uses the Source plugin.

Transform uses the Process plugin.

Load uses the destination plugin.

Preparing for an upgrade

  • Create an inventory of modules used in the source and destination sites.
  • Understand the assumptions made by the API
  • Be aware of known issues and limitations.
  • Know the scope of the system.

Assumptions by the Migration API

  • Drupal core in source and destination sites updated to latest versions.
  • No configuration or content has been made to the destination site. Drupal 8/9 should be installed using the minimal installation profile.
  • Enable modules on both sites to attempt an automated upgrade path.

Upgrading custom modules and themes is not supported.

Using Drupal's Layout Builder with Gatsby ( Lightening Talk)

We were shown a demo of using the layout builder. 

The layout builder is an interesting take on page building and seems to be quite popular. 

I'd really like to dig into Gatsby and see what it is all about.

Lots of talks have included Gatsby and the Layout Builder so far (future of Drupal maybe?)

Securing PHP package repositories with Tuf

Less human interaction can actually be a good thing.

If we didn't already know... malware is bad.

Malware can "latch" onto php applications. 

Not a huge amount of information was actually given about Tuf. Might want to check on this later.

GitLab: the Open DevOps Platform

GitLab is a platform for the whole team.

Multiple tools are available for DevOps, but can create compatiblity issues.

GitLab wants everyone to contribute.

Winners in the digital economy are transforming HOW they are doing things.

GitLab is completely open source.

GitLab is trying to improve collaboration in the dev community.


Drupal 10 Readiness Initiative Keynote

Drupal 10 will be a refined version of Drupal 9.

Olivero will be new frontend theme. Going to become default.

Claro will be new backend theme.  Going to become default.

Currently these two themes are not stable in Drupal 9.

Lots of dependencies are going end of life. This is the reason for the Drupal upgrade.

Drupal 10 timeline:

  • Planned for June 2022

  • Fallback is August
  • Fallback for the fallback is December

Drupal 10: Modernizing Core JavaScript

There was a big focus on jQuery being dead or less and less supported.

Drupal 10 really sounds like it will have a few features that will be nice.

Support for more and more libraries is coming. This is with hopes of completely replacing jQuery.

Core ajax may be difficult to remove. 

Building Google-Like Site Search

There is a big focus on unstructured data.

This can find words, sentences, paragraphs, or lists that best answers the "question".

Three search algorithms are:

  • Named entity recognition
  • semantic text search
  • extractive QA

Drupal 7 to Headless Drupal 8/9 with Serverless ReactJS User

This presentation was interesting and included a few demos.

Most of the process involved adding an API layer to an existing application.

Gatsby was used in one of the demos for a static site.

The API layer returns information back to the React component.

The UI needs to be decoupled. 


Higher Education Summit

Migrating to the New Frontier

Princeton was given as an example.

365 websites were moved from legacy CMS to Drupal 7.

Lessons that were learned:

  • Don't just move it, improve it
  • Crawl
    • Learn Drupal (repetition is good to learn)
    • Build websites
  • Walk
    • Build a multisite platform
    • Migrate a website
  • Run
    • Automate migrations
    • Benchmark migrations

Migrating a site - Make it an education opportunity

Keep (most) content in case something needs to be reverted or included again later

Composer Package Management in Higher-Ed

Presentation was given by developers working at University of Texas.

Many universities are required to use big "software as a service" implementations.

I think using Composer makes a lot of sense. Brock and I used it to setup a local instance of Drupal before, and it is very similar to other package managers.

A user in the chat said that they asked about "integrated composer with a private repo", and they got the response that this feature would be available this summer. 

SeedMeLab: Hosting and managing rich data on Drupal

Problems with data:

  • Information dispersion - data, more often than not, is scattered. Users very often forget to include ALL of the information or refuse to.
  • Weak presentation - data requires context
  • Dark data - Data exists somewhere but can be hard to find

The motivation for SeedMeLab is to be able to actually use/reuse data that is gathered.  

SeedMeLab supports custom plugins.

The Advantages of Paragraphs over Layout Builder

I'm not a huge fan of the "round table discussion" format.  I feel like I learn more with a structured presentation.

"Paragraphs" is apparently another layout builder alternative.

Paragraphs is a little more free form when compared to layout builder.

Layout builder is more restrictive by putting things in columns.

In some instances, layout builder is a little too much, and paragraphs can be a better option

Layout builder needs a theme for each layout that is created. This can cause a lot more work for a small site.

Composer Package Management

This was another round table discussion.

Composer again seems like a very popular tool.  There are those who don't like it, but that is to be expected in literally any widely used software.

The site owner owns everything in their composer.json file.

This is to keep a definitive line of what the user has access to and can change.

I keep hearing Pantheon. I'm not sure what that is, but apparently it is widely used.