A look back at Drupal Dev Days 2017

Authored on
Changed
Tags

From March 21 to 25, 2017, the Drupal Developer Days took place in Seville. Around 280 people attended.

It was very enjoyable and enriching to be in contact with the international community and the many French people on site :).

The atmosphere is quite different from a DrupalCon, you're less lost in the crowd and it's easier to approach and talk with "influential/well-known" people in the community.

In terms of venue, we were in the fort of a pirate-themed amusement park. The central area of the fort served for sprints, meals, and keynotes alike. While having a single area for sprints was actually quite nice, the fact that it also hosted keynotes meant you were somewhat obliged to attend them, and it was a bit difficult to focus on anything else.

Here is a summary of the 5 days with the talks I attended.

Tuesday

Sprint:

Challenges of using a single theme for a complex multi-site Drupal 8 installation

A presentation on how to organize a theme so it can be used across multiple sites sharing a common visual base. When dealing with several similar-looking sites with the same functionality, typically a multisite setup, the usual approach is to have a shared theme and use theme inheritance. However, in a project with tight scheduling constraints, it can be worthwhile to design a single well-thought-out theme.

Particular emphasis was placed on the importance of organizing SASS files to avoid side effects and make the most of SASS features (includes, mixins, etc.).

Above all, the importance of communication at every stage of the project between front-end developers and the rest of the team, project managers, other developers (site building, back end). So that needs such as specific CSS classes or particular configuration (fields in views rather than view modes) can be surfaced as early as possible to facilitate theming work.

A Cautionary Tale for Defensive Programmers

A presentation on how and why to ensure that code errors surface as early as possible (in development at least) and/or make debugging easier by providing the necessary information. For example, by suggesting possible resolutions.

For this, using typed parameters on method inputs and outputs, as well as throwing exceptions, is very useful. Be careful to only catch exceptions if you intend to perform an operation before re-throwing them, or if you actually want to handle them.

Drupal 8.3.0: The features are ready. Are you?

Presentation of the new features brought by version 8.3.0, including many interface improvements. A reminder of Drupal 8's development cycle with the adoption of semantic versioning and a minor release every 6 months.

Also a reminder of the experimental modules concept and a review of their current status. Apart from Migrate, experimental modules should not be used on projects. Personally, I also use the inline form errors module since it stores nothing in the database, no table and no configuration.

Wednesday

The organizers surprised us with a singer/guitarist duo performing very enjoyable music during lunch.

Sprint:

  • Discussion with bojanz about the D8 port of the commerce licence module asking him to document the expected architecture in the corresponding issue so we can help with the port (needed for the drupal.fr website) and about the integration of users in Inline entity form. On this topic, a custom form is the better approach; too many things are handled in a non-generic way in core for user forms.
  • Discussion with Wim Leers about the Entity share module and a possible approach to resolving https://www.drupal.org/node/2860886 for adding data stored in field values such as the title and alt attributes of image fields.
  • Update on issue https://www.drupal.org/node/2713495: regarding a display problem in the Features back office.
  • Created a patch to convert a SimpleTest test to a PHPUnit functional test in the Features UI module.

All your data are belong to geo

The first keynote of these Drupal Dev Days, focused on the importance of geolocating data to enable visualization and better understanding. There was also an overview of geolocation modules and external mapping services.

Advanced Configuration Management with Config Split et al.

Presentation of the various possible uses of the config split module, along with different configuration management workflows.

I remain in favour of using Features, as I prefer to have the configuration that belongs to a module kept inside that module rather than mixed in with other configuration files.

An interesting point: there is an event triggered when a configuration entity requires a content entity that is not present.

Thursday

Sprint:

  • Added screenshots to the Views issue regarding result summary display.
  • Created a patch for specific entity reference field data in JSON API.

Drupal, platforms and the future of e-commerce

A presentation on the importance of engaging customers and truly seeing them as a community, in order to sell in niche markets since mainstream markets are already taken and unbeatable.

Build the community first, even if it means meeting them where they already are, like Facebook. Then try to sell. Leverage the fact that people want to feel proud of certain purchases, for example, buying the latest smartphone versus buying a cable.

You don't necessarily need a website, use social media to your advantage and outsource logistics to dedicated services (Amazon, for example).

Introducing the UI Patterns module: use atomic UI components everywhere in Drupal 8

The module allows declaring reusable components and automatically generating a style guide.

Currently, patterns must be declared in YAML files, but future integration with systems like Pattern Lab and Fractal (tools used to manage components) is planned.

Within a component, you declare fields, which can themselves be other components and optional demo data.

The module provides a theme function per component, usable in renderable arrays as well as Twig templates. There is also an equivalent theme function that uses the demo data defined in the YAML file. It is also possible to associate each component with libraries, even libraries declared directly in the component's YAML file so they are loaded when needed.

Sub-modules provide integration with fields, layouts, views, Display Suite, and Field Group, enabling these components to be used in those contexts by mapping the fields declared in the pattern to the fields placed in a field group, for example.

Suggestions, primarily aimed at preprocess functions, are set up and differentiated based on their context (views, field_group, etc.) to allow targeted preprocess functions.

A very promising module that requires solid upfront scoping and good component breakdown on a project, but enables strong long-term maintainability.

Commerce 2.x: Lessons learned

The people developing Drupal Commerce started from the following observation/assumption:

  • they need many external libraries (including their own generic libraries) installable via Composer
  • Drupal 8 itself requires many libraries, which will make the use of Composer increasingly mandatory
  • Drupal 8 targets more complex sites, with "smaller" sites now being built in WordPress or Wix (even if Drupal 8 can serve small sites, it's true that technical knowledge is required for anything beyond site building).

Hence the idea that Drupal 8 users have an increasingly technical profile, including the need to use tools like Composer.

As a result, it was assumed that even site builders would embrace Twig at a minimum.

Drupal Commerce is therefore primarily aimed at developers.

Many configuration elements have been removed in favour of overridable, preprocessable Twig templates, or configuration declarable via YAML files directly in modules. In order to avoid maintaining rarely-used configuration interfaces that would not meet the business needs of e-commerce sites.

Drupal Commerce now more easily addresses more complex use cases, even though Commerce is designed to handle the simple case right out of the box. Time will tell whether even smaller sites can benefit from Drupal Commerce's advances.

Do your best to make your web page accessible

An awareness session on accessibility, a reminder of its importance and its benefits for SEO. Tips, a list of modules. And above all, accessibility should not be left to the end of the project.

Friday

Sprint:

  • Reviewing issues
  • Translations: no more French strings without a suggestion for version 8.3.0-rc2
  • Translation mentoring: teaching beram how to contribute translations.

Drupal 8 Caching overview

A presentation on the different cache types in Drupal, with a basic usage reminder.

Information on the need to use a cache backend other than the database since Drupal 8 has a caching system capable of storing page renders indefinitely, and Drupal 8 caches by URL for anonymous users, the cache can grow very large very quickly.

Also a reminder about the Lazy Builder, a cache mechanism that allows caching parts of a page while keeping a non-cached variable section inside such as a flag link.

The Views Custom Cache Tags module was also mentioned (which I had not yet tested), allowing you to define your own cache tags for use in views and invalidate them manually in custom code. The goal is to avoid systematically flushing the views cache on any entity modification. For example, adding, deleting, or modifying content defaults to flushing the cache of all content-based views. Whereas views are often filtered by a specific content type or a particular filter combination. Custom invalidation based on actual needs avoids unnecessary cache flushes.

Wait, there's more! - Advanced debugging tactics

A packed collection of debugging tips and tools, very interesting. It's always worthwhile learning new tricks for the tools you use every day.

Notably the PhpStorm macro system, which allows recording sequences of commands to replay later.

Devel - D8 release party

An interesting presentation on the evolution of Devel in Drupal 8.

Regarding the Twig Xdebug module, there is already a twig function devel_breakpoint that does the same thing.

Be careful to clear the data collected by the webprofiler, as each request can add up to 2MB of collected data.

An XHProf integration is currently in progress.

Improving content creation with Paragraphs

A presentation of the Paragraphs module, but the most interesting point was the Paragraphs Collection module still very experimental but with some very good ideas, for example:

  • a paragraph library: by design, paragraphs are tied to their parent entity and cannot be reused on another entity. The paragraph library idea allows reuse by selecting existing paragraphs to clone.
  • paragraph behaviors/properties: a common case is a "title, text and image" paragraph type where you need to offer the option of placing the image either on the left or the right. Currently this is handled by adding a field for that choice, with the rest done in preprocess functions or Twig templates. The paragraph behaviors idea is to store the "image left or right" information in a serialized form directly in the paragraph rather than in a field. Which, for complex paragraphs like slideshows with many options, avoids creating numerous fields.

Saturday

Sprint:

  • Discussion with Webchick and xjm about experimental modules. The new experimental module system, which should not be used in production (with exceptions like Migrate), left me puzzled regarding the stability of community modules. Notably with Drupal 8.3.x and the layout module that Display Suite, Panels, and Page Manager will rely on. For example, DS has had a stable version since Drupal 8 was released, and now there is another version relying on an experimental core module, how do you manage the update path? My concerns also extended to the pace of progress on these modules and the bandwidth of their maintainers, since they now theoretically have to maintain one version not relying on experimental modules and another that does...
    I was reassured that experimental modules are now introduced at beta rather than alpha stage, to help them reach stable status faster, unlike earlier experimental modules (which are still in that state!), such as Workflow and Content moderation.
    In the case of DS and Panels, they were already relying on a shared Layout Plugin module, which reduced the work needed to adapt to core. And there is prior discussion with the maintainers of these modules before any experimental module is introduced into core.
    A perspective I had not previously considered: experimental modules allow code to be introduced "quickly" into core, enabling contributors to test and develop faster and more easily than if the code remained as patches buried in issues. So they are indeed not for use on projects.
    Note: This discussion took place in the afternoon; Webchick's keynote was in the morning.
  • Discussion with Berdir about caching and Redis cache, particularly regarding an issue of caches not being cleared: https://www.drupal.org/node/2765895 the problem has since been resolved.
  • Discussion with beram about translation management in Entity share.

Debunking Myths to Drupal 8 Adoption

Webchick's keynote, with a reminder of the experimental module system, and a presentation of efforts to ease adoption since many clients are still waiting for certain modules to become stable or be ported, but due to the lack of Drupal 8 projects, maintainers don't have the time to stabilize or port those modules. The classic chicken-and-egg dilemma.

Getting up to speed with testing on Drupal 8

A workshop on automated testing with Drupal 8. Originally planned as a 4-hour workshop but scheduled in a 2-hour slot (and ultimately lasting 3 hours :)), it ended up being primarily a walkthrough of a Drupal 8 project skeleton with everything needed for testing: https://github.com/pfrenssen/drupal-project.

Very interesting to see scripting via Phing, I may look at replacing some custom scripts with Phing, or possibly Ansible, which seems more complex but also more powerful.

Overview of all test types: PHPUnit (unit, kernel, functional), Behat, JavaScript, browser emulators, etc.

Drupalize remote data with external entities

A presentation of the Remote entity API module, which allows displaying remote data in Drupal and manipulating it like content entities. Enabling the use of display modes, for example.

The module stores no data on the site (aside from possibly cache). From quick testing, the field tables for fields added to this entity type are not created.

Downsides include, for example, integration with Search API, how do you invalidate data indexed by Search API when the data is modified outside the site? Similarly, how do you build invalidatable caches? Views integration is missing. Multi-value field handling is lacking, and currently the parsing of external data only works on fairly simple structures such as those found at http://jsonplaceholder.typicode.com.

A promising module, I would summarize it as an advanced version of the core Aggregator module.

Conclusion

A very enriching event, both in terms of knowledge gained and connections made within the community.

Thanks to the organizers for this great event.

Thanks to the participants and to the people who mentored me.

And thanks to Smile for sending me there.

Comments

Add new comment

About text formats