Are you a proud Drupal website owner who dreams of a smooth and seamless upgrade process? Migrating your website to a newer version of Drupal can seem like a daunting task, but with the right techniques, it can be done in a snap. In this blog post, we'll discuss a different approach to Drupal migration that will save you time, hassle, and potential headaches.

Welcome to the third edition of the Pitchburgh Diaries, a regular update on progress as we work on our plan for a decoupled Layout Builder with React.

Sprints 5 and 6 were our final sprints in the project. Keep an eye out for a final wrap-up and summary of the next steps, which we’ll publish in the coming weeks.

Bundling and extending

In this sprint, we focused on the nuts and bolts of how contrib and custom code will extend decoupled Layout Builder functionality.

We began by creating a new Drupal 10-compatible version of the React module. Thanks to @corbacho for adding us as co-maintainers for the project! 

When we bundle the decoupled Layout Builder code for use in the browser, we don't include React. Instead, we rely on the React module to load it. This allows other modules that need React (e.g. Gutenberg) to use a shared version of React. React doesn't work if two versions are loaded on the same page.

The new version of the React module makes use of a relatively new browser API called import maps. Import maps allow you to write ECMAScript modules (ESM) with naked imports and have the browser resolve the dependency for you.

So, for example, our bundled code still has import React from 'react' in it. With an import map, the browser can resolve that to a Javascript file and load it for you.

To support this functionality, we wrote and released an import maps module which both the Decoupled Layout Builder API and React module make use of. We believe this functionality belongs in core because you can only have one import map on a page. So we opened a core feature request for that too.

With this module in place, bundling for contrib and custom code that wants to add additional components to the decoupled Layout Builder becomes much simpler. Essentially the build configuration needs to mark imports of React, React DOM, the JSX runtime and the decoupled layout builder components as 'external'. This ensures the bundled code retains the original import statements. Both Vite and Webpack support this feature. 

For those who recall how we built ES6 code in Drupal 9, you would know we had scripts in core's package.json and webpack configuration to transpile it into code that worked in older browsers like Internet Explorer. With Drupal 10, we removed that step as all of our supported browsers have native support for ES6 code. Similarly, if you've built a CKEditor 5 plugin, you would know it also uses Webpack for bundling.

As a result, Webpack felt like the natural choice for bundling here too. WordPress uses it to bundle block components for their Gutenberg editor. However, the web landscape moves quickly. The tool we chose N years ago may no longer be the best choice. With all modern browsers supporting ESM, the bundling landscape has changed. 

Those who follow front-end web development would know that many projects are actively moving away from Webpack towards Vite. Storybook added support for Vite in v7, and just last week, Remix had a major announcement about Vite support. CKEditor5 has also added Vite support. For this reason, we evaluated both Vite and Webpack for use in our utility Drupal scripts package. Thispackage is designed to make writing and bundling code for use with the decoupled Layout Builder simpler. Based on our evaluation and the broader front-end landscape moving towards Vite, we chose it for our bundling.

As a result, we have an npm package @drupal/scripts that we will release in the coming weeks with the following features:

• A simple build step. No need to manage your own bundling configuration - just add a dependency on @drupal/scripts (more on that below) and add this to your package.json for building - drupal-scripts build -o js/dist js/src 
• A simple setup process - if you install the package globally, you can run drupal-scripts init to have it automatically update your package.json with the required changes
• Support for scaffolding components for use with decoupled Layout Builder - just run drupal-scripts generate and follow the steps.

Feature development

In our first four sprints, we focused on building the Layout Editor in a decoupled application. We were mocking APIs so development could occur without a Drupal site.

In these two sprints, we switched to instantiating the Layout Editor in an actual Drupal site.

The Layout Editor uses React components that mirror Blocks, Formatters, Widgets and Layout plugins from Drupal. We have always intended for these to be the extension points for the application. If you need to change how any of those work in a project, you should be able to swap in your own custom React component.

To facilitate this, the entry point for the decoupled Layout Builder is the Layout Editor component. It takes a map of components for each of the Blocks, Formatters, Widgets and Layout plugins. This map is keyed by the plugin ID (same IDs as in Drupal). The values of the map are a function that return a promise, that will resolve the components. What each component comprises depends on the type. 

For example, a Block component needs an Edit and Preview component but might also need a Settings component. You can read more about what each component comprises in the storybook documentation.

In order to boot the Layout Editor, Drupal needs to construct these maps. To do this, we make use of existing plugin definitions and extend them to add an entry for the decoupled Layout Builder. 

Here's an example of nominating the path to a React component for a layout plugin:

In this example, the file MyLayout.js would be scaffolded with the drush-scripts generate command and updated according to the documentation for a Layout component.

In the Decoupled Layout Builder API module, we replace the default LayoutBuilder render element with a decoupled one. When this component is rendered, it loops over all of the block, formatter, widget and layout plugin definitions and builds up a mapping from ID to component path. This is then stored in drupalSettings. The element also attaches some Javascript to boot the React application that reads this value back and turns the file paths into promises using the browser's native import operator.

With all this in place, we were able to boot the new Layout Builder in Drupal 🎉. Here's a screenshot of that for the Recipe content-type in the Umami demo profile:

Other key highlights

So, while we've focussed mainly on the big ticket items, we were also able to complete a fair few of our other wish list items in these final sprints, including:

• Fallback rendering when no React component exists - as seen above, we're able to fallback to Drupal rendering where no React component exists yet
• Support for layout builder restrictions so that you can only drag and drop components into supported regions
• Support for saving changes in Drupal - including autosaving
• General improvements to Drag and drop so that it was easier to drag new components into existing regions
• General normalisation improvements so that section and region UUIDs are generated Drupal side and stored in third-party settings.
• GitLab CI integration so that Storybook builds on every push.
• Additional documentation and tests.
• Layout settings pane

Where to next

We've reached the end of our sprints for Pitchburgh. But that doesn't mean the work stops. We plan to continue working on the project and have quite a backlog of new features we'd like to add.

In our next post, we'll recap each of the completed stories for our Pitchburgh grant statement of work, go into more detail about our future plans and let you know where you can help.

Tagged

Recognize the problem that your Drupal website is not sending emails? For example, when there's a (security) update or when someone has filled out a Webform. In this blog, I'll show you in a few simple steps how to ensure that the emails your Drupal website sends always get delivered.

Our community is better because you’re in it.

The news lately, both close to home and around the world can be a lot to manage for many people. This feeling of overwhelm and heartbreak is echoed throughout many professional communities, including Drupal. The Drupal community is a group that fosters connection and inclusion and as members of the Community Working Group, our mission is to support you, our community.

To that end, we’re releasing an updated list of mental health resources that are available to you and your peers. The majority of these sources are US-based but we’ve tried to include a few international resources as well. If you are looking for support networks in your country please reach out to any member of the Drupal Community Working Group and we will confidentially search our network to find resources that fit your needs.

American Psychological Association (APA) - Psychologist Locator:
Website: locator.apa.org

Crisis Text Line:
Text HOME to 741741 to connect with a crisis counselor
Website: crisistextline.org

Employee Assistance Programs (EAPs):
If you're employed, inquire about EAP services provided by your workplace.

Local Support Groups and Nonprofits:
Search for local mental health support groups or nonprofits in your area that may provide resources and support.

MentalHealth.gov:
Website: mentalhealth.gov

National Alliance on Mental Illness (NAMI):
Phone: 1-800-950-NAMI (6264)
Website: nami.org

National Institute of Mental Health (NIMH):
Website: nimh.nih.gov

National Suicide Prevention Lifeline:
Phone: 1-800-273-TALK (1-800-273-8255)
Website: suicidepreventionlifeline.org

Online Therapy Platforms:
Consider using online therapy platforms like BetterHelp, Talkspace, or 7 Cups for remote mental health support.

Open Sourcing Mental Health:
Website: OSMIHelp.org
A non-profit focused on mental health in the tech community with forums and resources available on the website.

Psychology Today - Find a Therapist:
Website: Psychologytoday.com

Substance Abuse and Mental Health Services Administration (SAMHSA) Helpline:
Phone: 1-800-662-HELP (1-800-662-4357)
Website: samhsa.gov

Therapist Directories (GoodTherapy, TherapyRoute, etc.):
GoodTherapy: goodtherapy.org
TherapyRoute: therapyroute.com

University Counseling Centers:
If you're a student, check if your university or college offers counseling services.

UK MIND:
Phone: 0300 304 7000
There is a list of other UK helplines available at
https://www.mind.org.uk
https://www.spuk.org.uk/national-suicide-prevention-helpline-uk/
 

Veterans Crisis Line:
Phone: 1-800-273-8255 (Press 1)
Text: 838255
Website: veteranscrisisline.net

Your Local Community Mental Health Centers and Hospitals:
Check your local directory or government health websites for nearby mental health clinics and hospitals.

We also want to encourage those impacted by the mental health struggles of others to reach out for help. You’ve been impacted - we see you and want to support you. 

None of us are alone - we are a community of peers, friends, and colleagues. 

No matter your relationship with mental health challenges or your role in the Drupal community - we’re all better because you’re on this journey with us. Please take care of yourselves. 

Sincerely, 
The Drupal Community Working Group
 

The Drupal Association is here to update you on all of the exciting things you may have missed that happened at the conference! From a focus on marketing to updates on innovation, there was much to see and do at DrupalCon. Lille, France, was the perfect city for the Drupal community to unite. Easily accessible from major cities such as London and Paris, it was a bustling city of fantastic cuisine (did you try Le Welsh?!), shopping, museums, and culture. Continue reading to learn more about the latest updates from Europe’s largest Drupal gathering.

Day One

On Day One of DrupalCon Lille, things kicked off with the Driesnote, a colorful presentation that took us through a fairytale story fitting for such a historic city. This fairytale took attendees through the Drupal village, learning about the main character Drupal, and other unique villages that Drupal visits along the way: Reactopia, Contentville, Squarix, and Edoby Heights. Drupal stopped along the way to meet with the Drupal Marketing Wizards. A key initiative for the Drupal Association Board’s Strategic Plan is to amp up the marketing of Drupal as a product, and the Driesnote introduced us to Suzanne Dergacheva, Lynne Capozzi, and Nikhil Deshpande. As leaders of the new Drupal Association Marketing Committee, these three marketing wizards are working with a core group of community members to create a product marketing plan to boost Drupal marketing.

Other critical topics from the Driesnote included Drupal’s impact on creating a safe and secure web for everyone and the Open Web Manifesto, as well as Drupal’s latest updates and innovations. You can read more about the DrupalCon Lille Driesnote in Dries’ blog post.

During the opening ceremony, three well-deserving nominees received the Women in Drupal Award! The Define award went to Tiffany Farriss, the Build award went to Marine Gandy, and the Scale award went to Lenny Moskalyk. Congratulations to all three recipients, and thank you for all your work for Drupal and the community!

Continuing with Day One, we saw an update on the Project Browser Initiative with Leslie Glynn and Chris Wells. They discussed the current state of the initiative, including the usability testing they have been conducting, the plan for the UI and Markup, as well as their roadmap for the initiative, and various opportunities to contribute. Learn more about how you can help with the Project Browser Initiative.

Day One also included many other insightful sessions, Birds of a Feather discussions, and the First-Time Contributor Workshop. Alan Burke’s session, Having your cake and eating it too: Using Varnish to serve content from your new Drupal site alongside your Legacy platform - keeping 2 platforms live at the same time, walked audience members through running your own Varnish instance vs using a third party provider such as Fastly, what is achievable 'out of the box' using Fastly, and tricks to make sure Drupal works well in such a configuration.

Bringing Mautic and Drupal closer together in an open DXP with Dropsolid CEO Dominique de Cooman highlighted how Drupal and Mautic can form the backbone of an open DXP, specifically how a DXP can create value for the end user over using Drupal alone or Mautic alone.

Day Two

Day Two of the conference held two impressive keynotes, starting with KitKat and Jägermeister. These two powerhouse brands shared how they use Drupal to market their products, notably sharing that web traffic increased after KitKat implemented Drupal. Jägermeister showcased their solution for customized, collaborative, and transparent communication across borders with Drupal.

The second Keynote of the day, Fly Higher - How to Lead Fearlessly, brought Sarah Furness, a former combat helicopter pilot and Squadron leader, to the stage to give thoughtful and relatable tips on being the best leader you can be.

In Decoupling your search solution with Drupal Search API with speakers Jose Nieves and Christoph Breidert, we learned about how to use Drupal Search API with decoupled Javascript applications. We also saw an overview of the advantages and considerations when building a decoupled search application.

Other highlights from Day Two included Design in Figma, marketing automation, and a Drupal Association Public Board Meeting where new board members Piyush Poddar, Fei Lauren, Imre Gmelig Meijling, and Lenny Moskalyk were announced. Fei Lauren won the community-elected seat by securing the most votes during the At-Large Board Election!

Day Three

Finally, Day Three of DrupalCon Lille held the last keynote of the conference, where Drupal core initiative leads updated the audience on new improvements to the base system, event organization, diversity practices, and an update from Promote Drupal. This was the fifth installment of this keynote, and it allowed the audience to learn from key leaders in the community about what they are working on, their challenges, and how folks can get involved.

Innovation and the Future of Drupal was another topic on Day Three, hosted by the Drupal Association’s own Alex Moreno. Innovation in Drupal is a critical component of the Drupal Association and the Drupal Association Board regarding the vision for the future of Drupal. In this session, Alex led the conversation about the past, present, and most importantly, the future of Drupal. He was joined by a group of experienced tech leads in different areas in the Drupal industry: Scott Massey (Morpht), Cristina Chumillas (Lullabot), AmyJune Hineline (The Linux Foundation), and Nick Veenhof (Gitlab). During the discussion, Alex Moreno shared some numbers and graphs, the result of the work that he is doing on innovation. He shared that Drupal has still been growing strong in some areas of the industry, in particular in the top most popular 10k and 100k sites. We may simply need a little push to replicate the same for the rest:

At the end of the conversation, there was a positive message about the future of Drupal. In Alex's words, “We have the means, the experience, the opportunity, but most importantly, the community, to continue making Drupal a huge success for another 20 years. Let’s do it. There is nothing we cannot achieve together”.

ICT Greenhouse Gas Emissions Are Exploding – How Drupal Community Should Engage and Contribute Their Part with Janne Kalliola took us through why green coding is important, energy consumption in modern software, and how to reduce waste. Janne explained how information and communication technology accounts for 4-10% of the world’s energy consumption and 2.1-3.9% of greenhouse gas emissions. In this session, we learned that a sustainability team is being formed to help remedy this issue. Learn more here.

Finally, to wrap up three days of insightful sessions, the Closing Ceremony had everyone awaiting the much-anticipated announcement of the DrupalCon Europe location for 2024 … it will be held in Barcelona, Spain! We can’t wait to see everyone there.

Thank you for a successful DrupalCon Lille 2023!

Overall, DrupalCon Lille was a massive success with many informative and innovative sessions – too many to name in just one blog post! From the Birds of a Feather roundtables to Trivia Night, the community was able to learn and grow not only through all of the presentations and sessions but also through social events that helped connect our community. Thank you to everyone who made DrupalCon Lille a huge success, especially the Kuoni Kumlare team for organizing the event, and to our many sponsors and volunteers for making it possible!

See you all at the next DrupalCon in May 2024 in Portland, Oregon. 

We added Drupal's default pink background to LocalGov Drupal's unpublished pages recently. It didn't go down as well as we might have hoped!

This is a short video for how to use the LocalGov Content Access Control Module, based on Drupal's Workbench Access module.

Drupal Commerce is an ecommerce platform that has become the talk of the town. Ecommerce giants including Puma, Timex, and Lush rely on it to ensure top-notch operation of their online stores. Such immense popularity of this ecommerce software piques the curiosity of many. If you are also one of them, this blog will satiate your curiosity by exploring multiple facets of Drupal ecommerce development that make it unmatchable. So, are you ready to dive in?

First of all, let’s delve into what Drupal Commerce is.

The last two weeks the dust settled after an energetic and productive Drupalcon. Now there is a new stable release for all of the three most popular contrib modules Nuvole maintains: Config Filter, Config Split and Config Ignore.

Config Filter

This is the most stable module, its new releases just switch over to Gitlab CI and fix a small inconsistency in how config storages are expected to behave. The first iteration introduced a bug which the second release fixed. Thank you to the early adopters who spotted the bug. Config Filter will remain supported but its relevance is probably going to decrease with the release of stable versions of the modules which used to depend on it but no longer do. For example Config Split 2.x and Config Ignore 3.x do not depend on Config FIlter and both now have a stable release. Modules are encouraged to switch to the Config Storage Transformation API added to Drupal 8.8. Both branches remain supported and recommended on drupal.org since most commits can be cherry picked between the branches. But for performance I would recommend the original 1.x branch. Both branches have exactly the same API, just the behaviour is different when importing or exporting. Other config modules can use either branch for the test traits which facilitate writing tests that pass before and after refactoring from Config Filters API to the core API.

If your site indirectly depends on Config Filter because you use a module which depends on it, you need to explicitly require Config Filter when you upgrade the modules. Drupal can not uninstall a module that is no longer in the codebase. So explicitly require Config Filter, uninstall it and then in a subsequent deployment remove Config Filter.

Config Split

Our oldest Drupal 8 config module has a new stable 2.0.0 release. In it, bugs and edge cases discovered in last year's release were fixed. It also contains a "new" feature which brings back the functionality of the 1.x branch. This should help sites holding back on upgrading because the functionality changed. With that out of the way the plan is to deprecate the 1.x branch and end support with the end of Drupal 10 support. There will not be any features added to 1.x.

Config Ignore

Previous releases of the 3.x branch have not been feature compatible with 2.x. But the stable 3.0 release has been re-written from previous 3.x beta versions. It is configurable so that most use cases can be catered for with enough creativity. One can configure the configuration to ignore for create, update and delete for both import and export. But one can also just keep it simple and then it will be as all the versions before. In particular, however, it can be configured easily to behave like: the last 2.x release, the last 2.x release with the popular patch to allow filtering on export and the previous 3.x release. Because of that the 2.x branch is deprecated as of now and it will be marked as unsupported by the end of the year on Drupal.org. There is a new hook replacing the one which existed in 2.x and which addresses the new capabilities (the old hook is still invoked and will be removed in 4.0.0). With the end of Drupal 9 being supported, PHP 8.1 is now the minimum required version, but 3.0 does not yet take advantage of the new PHP language features. So the plan for 4.0.0 is to switch the string constants to enums and switch to semantic versioning and remove the old hook.

How the pizza is made

Our Drupal 8 modules have always been maintained "like a php library". The development of UI Patterns was initially hosted on Github among other things for that reason. Config Split and Config Filter shipped with their docker compose files and scripts to symlink the module into the Drupal site. Later the custom scripts were replaced by drupal-spoons. Since the now generally available drupal-gitlab-ci is inspired by spoons and DDEV is likely becoming the recommended development environment for contributing to Drupal, I switched my local environment for maintaining the contrib modules to DDEV with the ddev-drupal-contrib plugin, the spiritual successor of drupal-spoons. For contributing to Drupal core I can only recommend the ddev-drupal-core-dev plugin created by justafish during Drupalcon. I helped beta test it and it works like a charm. That said my PhpStorm configuration had to be updated a bit even though I installed the ddev plugin for it. In particular I had to add a second server mapping for Xdebug to work as described in a comment on the issue. The release notes for the contrib modules were generated with drupal-mrn.dev.

Many thanks to everyone who contributed with feedback, code, ideas or even just listened to my ramblings as I discovered untested edge cases.