Greetings from Baltimore! Below are some highlights of a few of the great sessions I was able to attend today.

If you'd like more detail about these topics, be sure to come to the May 1 meeting of the Grand Rapids Drupal User Group!

Opening Keynote

After the usual pre-conference workshops, code sprints, and pre-keynote silliness, DrupalCon Baltimore proper kicked off Tuesday morning with the traditional keynote address. Drupal creator Dries Buytaert highlighted current successes and challenges in Drupal 8 adoption, showing that version 8 is the default choice for most new installations, but that the install base for 7 is huge and there is a lot of migration work to do. The key obstacle here is that the core Migrate module still has a number of weaknesses and types of content it cannot fully support.

The core development team has adjusted their release strategy to improve the developer experience, and mitigate the difficulties that will come with the eventual Drupal 8 to Drupal 9 transition. Instead of introducing many new features in Drupal 9 and removing outdated code all at once, new features are being introduced at each minor Drupal 8 release, coming out once every 6 months. More importantly, APIs are not changed or removed during these minor releases, so any module that works for Drupal 8.3 should work identically in Drupal 8.4. At some point, it will be time for the release of Drupal 9, but this release will be identical to the final Drupal 8 release, except with deprecated APIs removed.

Session recording

Section 508 Refresh, Accessibility & the Law in the USA

Mike Gifford of OpenConcept Consulting presented this session about the state of the art of accessibility for Drupal sites. With the recent enacting of the Section 508 Refresh legistation, new requirements will come into play based on WCAG 2.0.

The first item of note is the broad scope of the ADA, which means that almost every site needs to seriously consider compliance with these standards, even if they are not government-funded. The sales pitch: "Good web developers are not as expensive as lawyers."

Section 508 was designed to address the technology of 1997, which implied things like not requiring JavaScript. WCAG 2.0, on the other hand, addresses four general principles, rather than specific technology concerns. Interfaces must be perceivable, operable, understandable, and robust.

A few highlights of items to watch for in each category:

• Perceivable: Use text alternatives for all non-text content, including not just images, but video/audio (transcripts). Instructions should not be conveyed only through sound, shape, size, or visual orientation.
• Operable: Don't allow "keyboard traps" of widgets that don't let you navigate away with keyboard alone. Make sure the focus order of page elements is sensible. Make the purpose of a link clear from its text (as opposed to "click here").
• Understandable: Make sure that not only the default language of content but also the language of parts (if different) is exposed to assistive technology. Check for spelling errors; they can confuse screen readers.
• Robust: Check for HTML/XHTML validation and parsing errors in source code.

Drupal sets up good initial defaults (such as required alt attributes on image fields in Drupal 8), but these alone don't guarantee full WCAG 2.0 AA compliance out of the box. Developers should use testing tools, such as tenon.io and WAVE Toolbar. It is best to regularly perform manual testing, ensuring keyboard-only navigation works well.

Session recording

The Right Tool for the Job: Content Layout in Drupal 8

This session, led by Kathryn McClintock, was extremely popular! Due to fire marshal restrictions, a lot of attendees had to be turned away, and the presenter agreed to hold a repeat performance later to accommodate them.

Handling variable layouts is a common struggle for Drupal site builders. We compared and contrasted a wide range of techniques for handling these in Drupal 8. Some of these included:

• Blocks, which are full-fledged entities in Drupal 8, and can have their placement fine-tuned with the Block Visibility Groups or Context modules
• Panels, a divisive and all-or-nothing approach
• WYSIWYG, possibly with inline templates, which is easy to get set up but error-prone to maintain
• Paragraphs, a flexible way to handle linear sequences of chunks of content
• Display Suite, a way to alter page layouts based on selected view modes

Paragraphs came out on top as the most robust and general-purpose solution, with Panels and Panelizer a good option for sites with extremely varied pages and Display Suite a contender for more highly-structured sites.

Session recording

Building reusable websites on Drupal 8: lessons learned from transforming rednoseday.com

Peter Vanhee of Comic Relief presented this case study of a way to handle multiple sites that share a brand.

Their effort began by using Drupal's multi-site installation feature, with new subdomains for different years of their campaign. They discovered that this is a fraught approach, because with a multi-site installation new sites could not innovate without compromising the integrity of existing ones. After coming to this conclusion, the team decided to focus their new efforts on building a platform that could power all of their sites, while keeping the code bases independent.

The design process for the new sites began using Pattern Lab. They used KSS to document their CSS choices, and then generated Twig templates from their Pattern Lab components that could later be used in the Drupal theme. This process will allow them to re-use some of these components on other sites, even those not built in Drupal.

To build flexible landing pages, they iterated through several techniques before arriving at one that suited them. This echoed much of the conversation from the previous session. They first used Panels with Panelizer. Then, to handle more structured content, they added Paragraphs into the mix, embedded in certain panels. On the third iteration, they realized Panels was no longer needed at all, and Paragraphs did the work alone, but using Block Reference paragraphs to pull in reusable content from the Blocks system.

Finally, to package their effort up in a reusable fashion, they created a custom installation profile, and provided default content for the site in JSON format. Composer completed the effort as a way to create new sites using the fruits of their labor.

Automated testing also played a big part in their effort. They use tools to test many aspects of the sites, including:

• Code Quality: CodeSniffer, phpmd, phpcpd
• Configuration: config_devel
• Distribution installation: composer drupal:install
• Behavior: Behat
• Visual regression: BBC's Wraith

Session recording

Magento and Drupal fall in love: A new way to approach contextual commerce at enterprise scale

Justin Emond and Mike DeWolf from Third & Grove presented this case study about Quicken. Their project began when Intuit spun off Quicken into a separate company, forcing Quicken to abandon some of their existing infrastructure and find replacements. They had an outdated e-commerce system, which would no longer be available to them in the new organization. They were already on Drupal as a web platform, but needed a new commerce solution.

After considering alternatives. they chose Magento 2 as their commerce solution. Why not Drupal Commerce? There were several factors, but chief among them are that many fewer integrations were available in Commerce than Magento, and that Magento is much more proven and optimized at scale—while they couldn't offer precise numbers, they did reveal that Quicken is now the highest-volume Magento sales site on the web.

Drupal serves all of the front-end experience, while Magento itself is headless. Wherever possible, content is synchronized from Magento out to Drupal, rather than real-time calls. By doing this, there is only one platform to theme. Magento can also live behind the firewall, with no exposure to the internet except via the APIs that Drupal calls. There are no requirements for accounts on both systems for users, so no single sign-on component. This does, however, limit the Magento components that can be used, in the cases where they rely on the Magento user interface.

Magento holds the UPC, Price, Stock level, product variations, and legal data. This should correspond to what the fulfillment team needs; they should never need to log in to Drupal. Everything else, such as product descriptions, imagery, and so forth, is in Drupal; this should be the domain of the marketing routine.

Session recording

Devel - D8 release party

Moshe Weitzman covered the features of Devel, now being released officially for Drupal 8. All of the indispensable features from Drupal 7 are still here, with some new goodies to help us out. These include:

• Integration with core admin toolbar
• A list of services available in the container
• Routing information, mapping route names to paths
• Configuration Editor and State Editor (the new iterations of the Variable Editor from Drupal 7)
• Three new Twig functions, devel_dump, devel_message, and devel_breakpoint, which allow for debugging inside Twig
• New devel "dumpers," corresponding to the stalwart dpm() function from Drupal 7. These use the new Drupal 8 plugin system, so they support a variety of output formats.
• The "vardumper" module which upgrades dumps to provide links to account edit pages, corresponding class definitions in IDEs, etc.
• The webprofiler submodule, which replaces the legacy query logger with much, much more detail about the active request
• Improvements to Devel Generate, which now supports all field types, because D8 Fields can generate their own sample data from their definitions.

All told, this was an exciting way to wrap the first day, with a lot of promising ways to find errors and improve performance in our sites!

Session recording