Drupal Dev Days 2019


Videos from Drupal Dev (developer) Days 2019.

Video Sponsor(s) / Provided by
Curated Videos
Drupal 8 core has made its way "off the island" by leveraging industry standards like semantic versioning, package management, third-party libraries, and other external tools. This shift brings a lot of benefits but has also impacted how we manage release schedules, backward compatibility, and security. Drupal isn't alone in experiencing these impacts; they affect many CMSes, frameworks, and individual applications. This session explores some of the impacts, including addressing some of the following questions

- What's different about Drupal 8?
- What will be different about Drupal 9?
- ...And what about Drupal 10?
- How do third-party libraries affect release schedules and security procedures?
- What are some of the risks and drawbacks for applications using package managers like Composer, npm, and yarn?
- How can those risks be mitigated?
- Can (or should) we head back to the island?

In this short talk, I will discuss the best practices on developing modules for Drupal 8 with an eye on having them compatible with Drupal 9.

For those who don't know yet, Drupal 9 is just around the corner. After a brief discussion of what will change in Drupal when that new version is released, I will show some tools can already perform a health check in your current code.

Finally, we will conclude by discussing the trends in Drupal 8 development that indicate already which type of functions will eventually be deprecated, and how that can be leveraged to minimize future workloads.

Slides: https://speakerdeck.com/jcnventura/prepare-your-modules-for-drupal-9

As of late, the traditional content management system (CMS) has been much maligned due to the explosion of innovation happening in the headless and decoupled CMS market. Normally monolithic systems like Drupal and WordPress are increasingly having to contend with upstarts like Contentful and Prismic and new paradigms like the JAMstack. But despite the naysayers and prolific prognosticators of doom, all is not lost.

In fact, we are entering a CMS renaissance that will revolutionize the way digital experiences are architected, built, and managed — and the likes of which will touch and impact every single persona working with digital content today, whether in the context of accessibility, design, user experience, editorial workflows, or web development.

In this keynote, join Preston So, author of Decoupled Drupal in Practice (Apress, 2018) and Principal Product Manager at Gatsby, for a journey through the past, present, and promising future of content management in light of recent innovations. We’ll dive through the history of web development, going full circle from flat-file HTML websites to complex monolithic architectures to static site generators. We’ll consider the differences between the first wave of the CMS, which brought us storied luminaries like Vignette and Interwoven; the second wave, when Web 2.0 ruled the day and Drupal sprung onto the scene; and the third wave, when decoupled and headless solutions began to emerge onto the scene.

We use Dependency Injection every day on each website that we code. I would like to speak about the “Dependency Injection Container” inside Drupal 8.
Not how to use it but how it’s implemented. I will propose you to have a new look at "Service Definition", how Drupal handles the "build" of its services. It’s very interesting to see how Drupal’s problematics are different from the Symfony’s ones (Dynamic container vs static container).
The aim of this talk is to explain all the concepts behind DIC (Services Container, Container Builder, Services, Tags, Compiler, Dumper ...) and to see how to interact with Service Definition in Drupal 8 (Service Provider, Compiler Pass).
I will not speak about the “Dependency Injection” pattern, there are already many articles well written on the web.

62 000 websites use Drupal Commerce to power their stores today, 8 000 of which are already on Drupal 8. With over 500 contributors and over 1200 people in the #commerce Drupal Slack channel, we represent a healthy part of the Drupal community.

Come see a brief overview of Commerce history, current capabilities, and future plans. Learn how we are tackling headless, open source business models, Drupal 9. See how you can help.

Drupal 7 has been there so long, and it offered us unprecedented flexibility to build some pretty huge projects -- special kind of beasts that have nothing to do with the original "Drupal-as-a-CMS" paradigm. Think about Drupal sites that behave as OAuth2 servers; or sell content access, or prorate prices and bill them monthly; or news portals that are also exposing the API's for popular mobile apps; or membership databases of really big organizations. Sometimes, these projects would be so big and so crucial to our businesses that there would simply be too much disruption if they went offline. 

But Drupal 7 is getting closer to its end of life. We have good migration scenarios for most of the use cases. However, the above giants are marginal cases which cannot simply be migrated to Drupal 8. And even if they could — that may result in building a new giant which would have to be killed once again at Drupal 8's end of life. Sometimes, a transition to something service-oriented may make more sense.

This session is going to suggest and describe a strangler application pattern in a Drupal 7 project. Martin Fowler describes the strangler application as “…a new system around the edges of the old, letting it grow slowly over several years until the old system is strangled”. In our PHP/Drupal realm, that means:

1. decoupling the frontend of a Drupal 7 project;
2. placing a middleware API proxy between the frontend and Drupal;
3. finally replacing individual parts of the old system with the newly developed ones

This approach promises zero downtime and makes no assumptions on what will be the resulting tech stack. The decoupled frontend can be a GatsbyJS project, or a React app, or even a static HTML served from the middleware. And the middleware itself can be a NodeJS/Express app, or a Golang API proxy, or something third. The backend can be replaced with a Drupal 8 monolith, or multiple Drupal 8 projects, or with a full-blown microservice architecture.

The sweetest part of the pattern is that even if you make an error in the architecture of your backend, which will require serious refactoring, you will be able to correct it without the downtime.

What is this session about?

To decouple or not to decouple Drupal? When? Why? How? Almost every Drupal developer has sooner or later come up with these kinds of questions. If you are one of them, you will most likely want to join our session.
During our presentation, we will explore various aspects of building progressively decoupled Drupal websites. We will discuss in detail both the advantages and disadvantages of this approach by describing the issues we have met and the benefits we gained while building different kinds of websites with Drupal and Vue.js. In order to be as thorough as possible, we will cover both back-end and front-end development.

What will I learn from this session?

The goal of this session is to provide the audience with enough information on the pluses and minuses of using progressively decoupled Drupal. To accomplish this, we will share our own experience and give examples from real projects. At the end of this presentation, the participants will have a solid understanding of the topic and will be able to decide on their own when to use progressively decoupled Drupal and when monolithic Drupal may be the better choice.

Who is this session for?

No matter whether you are just starting with progressively decoupled Drupal, or already have some experience in the field, we would love to share with you our lessons learned and hear your opinion, tips & advice. We enjoy lively discussions and are looking for your questions at the end of our session!

In this session a currently Provisional member of Drupal Security Team gives a broad overview about how security bugs are present and could be prevented on Drupal projects.

He's going to go through the 4 stages of a bug's life:
* The Eggs - Planning and Security by Design
* The Caterpillar - Development iterations until the first release
* The Chrysalis - First releases of the application
* The Butterfly - Maintenance releases and activities

Attendees can take many conceptual best practices away that suppose to raise security awareness from the beginning of projects until reaching the maintenance phases.
We'll check tools and processes regarding Application Security and also understand the basics of Vulnerability Management - how they increase the quality of web applications and why mitigation and remediation plans are crucial to managing projects on a large scale.

The session is meant to be a Project Management one, but Technical staff also can benefit to understand needs and implementations of secure application development.

One of the ways Drupal Commerce stands out from the crowd is the way it builds on top of a Content Management System. Not an Invoice system. Not a Point of sale system. A system that can build any type of content powered website, in any scale, with any form of editorial workflow.

The content and marketing driven approach give a more satisfied client and webshop manager. But it also creates an opportunity for agencies to tap into the bigger marketing budget instead of the fixed IT budget.

We will look at how we can create a unique symbiosis of content and ecommerce, not to mention editorial experience, with Drupal Commerce. There will be pitfalls, case studies and an optimistic view on the future of Drupal Commerce.

Slides: https://eiriksm.github.io/content-driver-ecommerce-ddd19/#/

Drupal 9 is planned to be released June 3, 2020, in a little less than a year! Also, Drupal 8 and Drupal 7 both go unsupported by November 2021. This session covers the timeline getting there as well as where are we and what kind of changes can you expect. It will be most valuable for developers but businesses can also get a summary on status details and tools to help with the transition.

For slides, checkout http://hojtsy.hu/blog/2019-may-03/present-your-own-state-drupal-9-session-get-slides-here

Drupal is a free software product that many people rely on to develop their custom solutions.
But is it really all that "custom"?
As the years passed we see how more and more parts of project requirements are already covered by features included in Drupal core or in mature contributed modules. With all that in place, we can focus more on the specific problems of the domain we are dealing with. These problems should actually be the "custom" part of your project.
The increase of use cases that are already covered by Drupal happened organically as part of the ecosystem but I feel it is important to highlight how you can also be part of this improvements and make it happen in your day to day work.

In this session, I will talk about a particular approach to development so we can identify the parts that can benefit from being developed out in the open and what to do when having fixes and improvements for projects that already exist. I will also cover some steps that can be followed so this process happens more naturally.

Since Drupal sailed away from its island years ago I will also cover situations in which the code we need or want to develop is not specific to Drupal so we can share the joy with the whole PHP/JS/CSS/You-name-it community. Some composer specific examples will be presented.

Slides: https://rodrigoaguilera.gitlab.io/talk-upstreamable/

How do you build a great culture? What kind of company/community will help people flourish? What can we learn from the Open Source community to do so? How can we use these insights to help the Drupal community or our companies to be at their best?

How can you separate great cultural patterns, from accidental cultural artifacts that could even be detrimental to an organization, but that seems relevant because of survivor bias? One of the ways to do so is to try to get an as complete as possible understanding of the principles behind open source culture.

During my 13 years in the Drupal community, I’ve been reading and thinking about these underlying principles. In this talk, I want to introduce 7 mental models and surprising insights that I have adopted along te way that has transformed the way I think about business. I will present the insights together with references to the books that gave me these insights, and explain why I believe they can help an organization to build an open source-like culture.

The insights are the following:
1) Motivation is not about carrots or sticks
2) Collaboration at scale does not have to be transactional
3) We aggravate conflicts through our own behavior and language
4) Language is an indicator of cultural maturity
5) Hierarchical systems fail in fast-changing environments
6) Digital businesses are value networks rather than value streams
7) Constraints and autonomy are not mutually exclusive

Drupal is historically a successful CMS in the web where it comes down to complex content models, proper revisions and multi-language with a fine-tuned access control.

This lead to a lot of prominent solutions, in the corporate world that can compete with adobe and sitecore, as well as smb Swiss army-knife solutions for hobbyists and SME.

Now with decoupled and hipster frontend frameworks we seriously have a popularity problem.

In Drupal Europe, at the local associations round table, we’ve seen the importance to use the knowledge of local association to make the Drupal marketing initiative work, with other initiatives and sharing knowledge. A lot of quick wins as well as long term visions where explored and initiated. This session won’t deep dive into all of those but highlight a few and some pointers to get you engaged.

We already have Rocket.chat livechat integration for drupal projects to engage visitors to become contributors or clients.

So the next logical step would be used marketing automation, something that could raise some eyebrows within certain parts of our community, although drupal.org uses third party proprietary solutions in order to engage “clicking individuals” to become happy contributors.

So our next challenge is to embrace Open Source marketing automation, where Mautic comes into play, it already has a Drupal module and is the only fully integrated alternative available and really good :)

Slides: https://040lab.com/cluj2019/index.html#/

With the powerful web APIs it has become relatively easy to create decoupled applications with Drupal 8 as a backend. A number of lighthouse applications have been created and powerful demo systems and starter kits such as 'Reservoir' und 'Contenta' have emerged.

Usually decoupled applications are used to display content, but the editing of content still takes place in the backend.

However, technologies like React can perfectly be used to create a great editorial experience. Given the powerful REST APIs of Drupal, a decoupled editing system can easily be integrated.

In a recent project, we have created a decoupled application with React, that allows for editing content directly in the frontend. Using the possibilities of React to the fullest, we have created a modern editorial experience with 'in-place' editing, 'context-sensitive' editing, 'drag-n-drop' content placement and creation, and much more.

In this session, we will present the application and our vision of what an enterprise level editorial experience should look like.

Besides the niceness of the application, we also discuss the challenges we encountered and our planned future development.

The main takeaways of this session will be, what to expect when going fully decoupled with an editorial experience and how this approach fits into the development of Drupal.

Slides: https://speakerdeck.com/rteijeiro/creating-an-enterprise-level-editorial-experience-for-drupal-8-using-react

When we say FrontEnd, we mainly think of the glue that sticks, the Designer's vision and the BackEnd's implementation, together.

We make things look pretty for the final user, we make it easier for people to surface our page in style, we make everything flashy.

Thinking about security you might be tempted to correlate it with Backend development. But I am here to try and show that FrontEnders have the same level of responsibility when it comes to securing our web pages. We will go through the main issues that make up the FrontEnd Security Checklist.

No previous knowledge is required as this will be a beginners session.

In this session I'll give you a summary of what machine learning is but more importantly how can you use it for a very common problem, namely the relevancy of your internal site search.

Recently, a client of ours shared with us their frustration that their website’s internal site search results didn’t display the most relevant items when searching for certain keywords. They had done their homework and provided us with a list of over 150 keywords and the expected corresponding search result performance. I'll take you on a roadshow how complex Search is and why we all came to rely on Google and came to expect similar quality from our other searches online. You can expect to learn new concepts. 

You'll leave the session with a general understanding of not only machine learning in function of search/relevancy but also how search works and how you can use the toolkit of Solr/Lucene to improve your site search with minimal impact for your Drupal site. I'll try to keep it understandable for all audiences but do expect a high level of technical content and concepts.

More detailed information can already be found at https://dropsolid.com/en/blog/machine-learning-optimizing-search-results-drupal-apache-solr

I will be talking about the work we do at the Drupal Association to help with marketing and communications aimed at growing our community but that, really, the greatest asset we have are the people who exemplify what is great about our project every day. I’ll lead into many of the items of feedback we have received about how we can coordinate activities to give people new to our community the best possible onboarding experience and how we look to grow their involvement into the future.

Most of you have tried out Paragraphs, Panels, Display Suite or other tools for fancy and complex pages. I've worked the most with Panels on D7 and Paragraphs on D8. We're shipping Drupal sites on a monthly/bimonthly basis to customers, and all solutions so far had a couple of drawbacks in common:

- Clients are concerned about contrib modules and their security
- These modules have additional dependencies (like page_manager and entity_reference_revisions)
- The administrative UI is hard to learn and use

Layout Builder is in the core, it's stable with the release of Drupal 8.7, the administrative UI is simpler than anything so far and it doesn't have additional dependencies. It's also highly customisable, you can create your own templates and also apply your favourite framework's layout solution.

Let's delve into how powerful Layout Builder is!

Knowledge level recommended:

- Site building: intermediate
- Theming: advanced
- Module development: intermediate

What you'll learn:

- How to give freedom to the site builders to build complex layouts
- Strategies on building different layouts with Layout Builder
- How to apply your favorite framework to the built layout

In this session, we are going to explore a really powerful capability of the Drupal 8 migration system, namely dynamic migrations based on templates.

Sometimes you can define your migrations in a single file, run them, close your laptop and go grab a beer. But let's face it, most other times things are a bit more complicated. The use case we will explore in this session has to do with building migrations based on criteria that exist in the system. A very common example of this is migrating entity translations in each of the languages that you have on the site. 

A general run-down of what we will cover in the session is as follows:

   -The basics of setting up migration and how it actually works under the hood

   - (Migration) plugins and plugin derivatives

   - Migration templates

   - Use case: migrate nodes with translations

Drupal critics used to say it turns developers in a sort of click-monkeys.
In fact, most of the things in Drupal are configurable, but we need a solid way to deal with all that configuration.
On the other hand, Drupal has installation profiles and this let us have a good start point for our new websites, and also let us have a sites galaxy (related or not between them) with similar functionalities.

Since Drupal 8, we are able to export the configuration to code, and the YAML representation of the configuration also made easier the development of installation profiles. Drupal supports natively this way of representing any configuration.

From Drupal 8.6 had born a new way of installation, called "installing site from existing configuration".
This new installation way is described as being for development purpose but, What happens if we move it to production?
It opens the doors to a new way of understanding installation profiles, based on a shared existing configuration, allowing several differences between sites by context. With this approach is possible to have tens (hundreds?) of sites sharing the configuration on a single central point where a single configuration change can be easily applied (or not) to all of them simultaneity, being also available immediately to the future created sites.

This includes:
- Installation profiles based on existing configuration.
- Installation profile inheritance.
- Multi-site installations with shared configuration.
- Multiple installation profiles with shared configuration and codebase.
- Usage of config_split by the environment, site, installation profile or installed module.
- Override configuration for specific sites.
- Practical code examples to do that.
- Good and bad things about this approach.
- CMI 2.0 and future.

Admin UI & JavaScript Modernisation initiative is planning to provide a re-imagined content authoring experience and site administration experience in Drupal, built on top of modern JavaScript foundations.
This session will provide an update, and discussion around the following topics we are currently working on. We are especially looking for feedback on everything we are currently working on!

Design a new UI

     - User research overview, like the comparative study of authoring tools across - different CMS to find the best solution for the default authoring experience and first  wireframes.

      - General UX improvements planned

     - Design System creation with components and design patterns

New admin theme Claro with the new design system to provide an updated admin experience.
Developing and finalizing plans for modernization efforts,

      - Describe the (limited) extension mechanism we built into the application.

      - What features should be present in a new JavaScript-based UI.

      - Update on creating a component library for Drupal-specific UI patterns.

Renderkit provides a range of components that can be used to match complex front-end requirements in a clean way.

You want a tab label to display the accumulated price of products referenced from the current node and child nodes?
You want to display a different icon depending on a taxonomy term?
You want a picture and text wrapped in a link tag, with a nice shadow effect?
You want to use a different field formatter depending on the node creation date?
You want to embed a view with related content, where the choice of style plugin depends on the author's user role?
You want all of this on one big node page, with different components nested within one another?
You want 

Render kit (in combination with other modules) provides a lot of this out of the box, and a lot more by using the API.

In the session, we will:
- Have a quick look at how to install.
- Explore and demonstrate what is possible out of the box.
- Write a custom module with custom HTML/CSS components, custom theme hooks and render element types, and custom renderkit components.
- Integrate the components into views and entity view modes.
- Create a feature to export the settings.

The session will mostly consist of live demonstrations, inspired by real-world-examples from websites I worked on (actual real-world examples will only be shown if the project owner(s) approve).
Based on previous experience, there will be only few slides, to maximize the time for demonstrations.

Drupal 8?
I have started with a Drupal 8 version 2 years ago, but I cannot promise anything yet. So for the sake of this session, we have to assume this will be about Drupal 7 only.

Slides: https://docs.google.com/presentation/d/e/2PACX-1vQriw3E4u4TgHGPx4Ubm0TGhSVfSfzSV3RwpHqiMZz71foLNLaLNRjPpRac7hykYnd_tkAgt071mca2/pub?start=false&loop=false&delayms=3000

Configuration management has been one of the signature improvements that Drupal 8 brought us.
However, initially, Drupal 8 core only supported a very narrow use case and left the rest to contrib to figure out. In the second iteration of the configuration management initiative, we take the lessons learned from contrib and implement them in the core. But we have only a narrow window of time left to get things done for Drupal 8.

Now is the time to get involved, the deadline for 8.8 is very soon!

Participants of this session do not need to be experts on configuration management, having used the core config module and maybe config_split is enough.
You will walk away with good sense of what we are trying to bring to Drupal 8.8 and why it is important to get involved at the sprints during this event.

In this talk, I will present to you a personal project called Drupal Debug. Does it aim? Help you develop better and faster by increasing the quality of your developer experience when you're working with Drupal! I will explain the problems it solves as well as how it works internally.

If you’re not sure exactly what the developer experience is yet, no problem! I will introduce the subject with some great examples and with a quick return of experience of my discovery of Drupal.

If you're tired of doing "drush cr", come see my talk!

Web push notifications, also known as browser push notifications are messages that are sent from a website to the browser. 
Subscribers will get your notifications even when they are not on your website. 
By combining the Notification and Push APIs with Service Workers we now have another alternative to third-party services (i.e. PushCrew, OneSignal).
With a live practical demo you will learn:
- How to use service workers
- How to integrate Drupal with PHP web push libraries
- How to practically connect web push notifications to a content type
- How to perform metrics on sent notifications (i.e. number of opened/closed notifications by the end user)

Contributing to Drupal does not always need to take the form of writing code. There are many ways you can apply your skills that can be helpful to this community. Organizing an event is one such way, though it is arguably not one of the easiest.

Between planning the program, getting people to attend, contacting sponsors, balancing a budget, working on the website, handling unexpected circumstances, and myriad other activities, putting a Drupal Camp together can be challenging. It also seems like we're constantly reinventing the wheel, which, as programmers, strikes us as quite sinful.

This session will tell the tale of the 2017 Drupal Camp in Quito, Ecuador; how the team approached each of these issues, and how we failed at some of them (but succeeded in others), in an effort to document and share this enriching experience with other potential organizers. We will also talk about a couple of unusual elements that made this event extra special.

Slides: https://noti.st/cambraca/UxGA8t/lessons-from-a-first-time-drupal-camp-organizer

Every time we develop functionality for our Drupal sites we compromise their integrity: Does the entire site still work or have we inadvertently introduced a bug?

New features can be developed in a separate branch. This branch can be tested separately by running local tests or by deploying the code into an environment. If we want to automate these tests we can use Jenkins' multi-branch jobs, which is the purpose of this talk.

This session may interest you if you want:
- Try each new feature of your Drupal separately before integrating with all the others.
- Establish a workflow to develop in Drupal that guarantees the integrity of the project - with a system that tests every branch of git it would be possible!
- Know alternatives to the currently known systems such as Travis CI or Circle CI.

In this session we will see the following:
- Jenkins plugins needed for multibranch testing.
- Infrastructure with Docker4Drupal to run tests on each branch (but you could use any docker stack!).
- What components we can test and how.
- Demo with a real project to show its potential.

Slides: https://mistermoper.github.io/2019-drupaldevdays-multibranch-tests/#/

The popularity of static site generators is taking off in the Drupal world. Any site builder can take advantage of the features provided by Drupal to build and manage the site and rely on the benefits of a static version once it is generated to share it with the rest of the world.

A static website requires a significantly smaller maintenance effort, hosting infrastructure is simpler, pages are served quite fast and the security risks are dramatically reduced.

However, there is a dark side too. Some of the nice features provided by Drupal can be lost or degraded. At the same time, if the site complexity grows, the downsides of this approach could be bigger than the benefits.

Tome is a static site generator built within Drupal. Unlike other generic tools that can be integrated with Drupal, it is a native tool for this purpose. The static version of the site is generated directly from the Drupal UI or using Drush in a completely transparent way.

The aim of this session is to introduce the audience into the world of static site generators for Drupal and showcase Tome and its ecosystem of related modules. Some roadblocks will be revealed, including some different ways to mitigate them.

By the conclusion of this talk, attendees will have a better idea about whether a project is a good candidate or not for this approach and will, have a better knowledge of the Tome module and the different workflows to handle Drupal static sites using it.

Slides: https://plopesc.github.io/tome-slides/

The three core aspects of computer technology are: hardware, software and we should not forget the most important one Peopleware. 

Peopleware refers to anything that has to do with the role of people including such issues as developer productivity, teamwork, group dynamics, the psychology of programming, project management, organizational factors, human interface design, and human-machine interaction.

In this session, we will reinforce how important is to focus on the people and their needs, helping them to grow personally and as a team creating a suitable environment. 

"The major issues of software development are human, not technical".
(Demarco and Lister, 1999) 

- Introduction
- Management 3.0
- Motivation: intrinsic vs extrinsic
- Self-organized teams
- Multifunctional teams
- Productivity & waste
- Conclusions


Drupal is a registered trademark of Dries Buytaert.