Drupal Planet

Drupal Association Journey: Pedro Cambra: DrupalCon is coming up!

9 hours 4 minutes ago

DrupalCon NorthAmerica starts tomorrow, but it is still not too late to register! There will be quite interesting content and networking activities and there’s a Drupal Association Q&A session where the floor is going to be open for the community to reach out the DA board and staff.

I’ve requested to be on the line up and I’ll be participating, so if you have any questions, please take your chance!

I don’t have a massive amount of updates from this last weeks regarding my board participation. I’ve been attending the Community and Finance committee meetings and there are some outcomes from there that I’ll be publishing about soon.

I’ve requested that the board minutes page is updated more often, and I’ll remind this to the person in charge of doing so.

I am preparing some proposals that hopefully will be addressed to the board regarding some considerations and process on the disenfranchisement non Drupal association in the elections issue. I hope to have updates on that too.

Note: This blog has the comments disabled, please feel free to send me a message through my contact page if you need to discuss anything related to the community and the Drupal Association. You can also tweet at me or find me in Drupal Slack or the distributed matrix network as pcambra.

#Drupal

hussainweb.me: Thriving on Chaos in Drupal

15 hours 56 minutes ago
Today, I want to share my thoughts from a book passage related to Drupal. The book, Everyday Chaos by David Weinberger, is largely about how chaos is the new reality in today's machine-learning-driven world. In this book, Drupal is discussed in the chapter on strategy and possibility where it is contrasted with more traditional methods of product development and organizational vision. The book is amazing and insightful, and the section on Drupal was a welcome surprise.

hussainweb.me: Drupal Podcasts (and some PHP ones)

1 day 15 hours ago
Today's DrupalFest post is on the lighter side. I am just going to talk about some of the podcasts I listen to related to Drupal, PHP, and software development in general. I'll try to cover all the Drupal podcasts I know about. Let me know in the comments if I have missed something. As for others, I am just listing those I listen to.

Matt Glaman: Watch: Nightwatch testing training to help get Olivero stable for Drupal 9.2!

1 day 17 hours ago

I am a little late getting this blog published. The end of March and early part of April just blew right past. However, I wanted to share the recordings from the Nightwatch.js training I gave at MidCamp on March 25th. I showed folks how to run Drupal's Nightwatch.js test suite locally, with DDEV and Lando.

The workshop code is available on the Bluehorn Digital GitHub organization, with documentation. I plan to develop this for all future testing workshops and keep it open for folks to learn from outside of paid workshops. In fact, the repo runs GitHub Actions to test the various setups and executes Drupal tests – the tests run tests to test that the tests can be tested! 😵

Community Working Group posts: 2020 Year-in-review for the Drupal Community Working Group

2 days 3 hours ago

The past year has been a busy one for the Drupal Community Working Group (CWG), as we created a new "Community Health Team" and saw the stepping down of the last original member of the Conflict Resolution Team, George DeMet. As the CWG enters its 8th year, we feel it is our duty to continue to pursue our mission to "foster a friendly and welcoming community for the Drupal project and to uphold the Drupal Code of Conduct". With this guiding principle, we have been focusing on both proactive and reactive tasks to help us achieve this goal. 

This annual report will serve as a summary of what we've accomplished over the past year, as well as a discussion of some of our goals for the near future.

Community Health Team

The Community Working Group was expanded during the first half of 2020 with the creation of the Community Health Team. The mission of this new team is to focus on proactive community health tasks including workshops and knowledge transfer. With the help of Tara King, the CWG membership coordinator, we structured the team into several groups. Although team members may do work across multiple groups, each of these groups is designed to, but not limited to, focus on a specific area:

  • Community Event Support - provide resources and support related to the Code of Conduct for Drupal events.
  • Community Health - provide opportunities to educate and train community members to be more effective contributors.
  • Membership - to help identify and recruit community members for the CWG. 
  • Ambassadors - provide expertise and advice related to geographic, cultural, and other differences both inside and outside the Drupal community.

Community Health Team members are not privy to Code of Conduct incident reports; however they must adhere to the CWG Code of Ethics.

Once the team was created and volunteers were found for the majority of the roles, we began having monthly meetings during the second half of 2020. The team has already completed a number of tasks including:

  • Initial work on a Drupal Code of Conduct update.
  • Documentation of CWG roles.
  • Development of a group of community health representatives from other open source communities.
  • Ongoing Code of Conduct contact workshops.
  • Updates to the Drupal event Code of Conduct templates and playbook.
  • Ongoing Mental Health First Aid workshops for community members.
  • Blog posts related to community health.
  • "Nudges" for Drupal Slack Workspace and issue queues.

Other, long term goals for the Community Health Team include providing an on-ramp for the Conflict Resolution Team and identifying and presenting additional community-health-related workshops for the community, 

Conflict Resolution Team

After six years on the Conflict Resolution team, including several years as its chair, George DeMet retired from the team at the end of 2020. We cannot understate how much of an impact George has had on the CWG and the Drupal community, often working behind the scenes. We are fortunate that George has agreed to stay on as a member of the Community Health Team where he will be focusing on updating the Drupal Code of Conduct. 

During 2020, in addition to the creation of the Community Health Team, the Conflict Resolution Team continued to work on on-going and new Code of Conduct related issues. During our weekly meetings, we generally work on three types of tasks:

  • Internal business - examples include recruitment, public blog posts and presentations, Aaron Winborn Award, event organizer requests.
  • External, old business - ongoing conflict resolution tasks normally brought to us from community members.
  • External, new business - new conflict resolution tasks, normally brought to us from community members.

While some conflict resolution tasks can be resolved quickly (a few days), we normally have several long-term, on-going issues that can take anywhere from weeks to months to resolve. Most of the long-term issues include ongoing personality conflicts within the community, but we also routinely work with community members who had previously had their community privileges limited on plans and tasks to have those privileges restored (see our Balancing Accountability and Compassion in the Drupal Community blog post).

What types of conflict resolution issues do we work on?

We decided to perform a quantitative analysis of the number and types of conflict resolution issues we work on, comparing data from 2019 with 2020. Our methodology allowed us to assign one or two of the following categories to each new issue we received during 2019 and 2020:

  • Social media conflict
  • Issue queue conflict
  • Drupal Slack workspace conflict
  • In-person Drupal event conflict
  • Virtual Drupal event conflict
  • Not CWG domain
  • Other - examples include content issues on Drupal.org, issues related to local Drupal communities (but not directly related to an event), interpersonal issues occurring in areas not covered by any of the other categories.

In terms of overall number of incidents, while 2019 had 35 total new reported incidents to the CWG, 2020 has slightly less than half of that, with 17 new reported incidents. 

  • While the number of incidents occurring at in-person Drupal events dropped from six in 2019 to none in 2020, this doesn't account for the entire reduction of total incidents between 2019 and 2020. We also saw fewer social media and Drupal Slack workspace conflicts, but the biggest drop was in the "Other" category, which saw a decrease from ten incidents in 2019 to just two in 2020. 
  • Obviously, the drop in in-person incident reports is directly related to the pandemic.
  • What else can we attribute the dramatic drop in incident reports to? We hope that the formation of the Community Health Team is having some effect, but we're not so naive to attribute the entire decrease to its creation and actions during 2020. 

2019

2020

Total number of new reported issues

35

17

Social media conflict

7

1

Issue queue conflict

9

9

Drupal Slack workspace conflict

5

1

In-person Drupal event conflict

6

0

Virtual Drupal event conflict

0

2

Not CWG domain

4

3

Other

10

2

Looking forward Conflict resolution team membership

One of the primary goals of the conflict resolution team in the first part of 2020 was expanding the size of the team. With the recent departure of George DeMet and the decrease in our workload (thanks to fewer incident reports and the amazing work of the Community Health Team), we decided this was a good time to recruit new team members. 

We had six amazing community members approach us about joining the team, and will be inviting a new member(s) to the team in the next few weeks. One of the main goals of the Community Health team was to provide an on-ramp to the Conflict Resolution Team. Those community members who were not extended an offer to join the Conflict Resolution Team will be asked to join the Community Health Team in a capacity of their choosing, if they haven’t joined already.

As part of the process of having new members join the team, we implemented (and are in the process of documenting) a new on-boarding process, where new team members are considered "trial members" for a maximum of 5 months. During this period, new members will mainly shadow the team and have limited access to historical conflict resolution reports. At the conclusion of the trial period new members will either become regular members or be asked to leave the team. As is prescribed by our charter, all trial members must be approved by the CWG Review Panel

Community Health Team

Now that our Community Health Team is a year old and has some experience under its belt, we have high hopes that they will continue to be a force for good in the community. Our plans for the next year include finding and presenting additional workshops, completing the aforementioned Drupal Code of Conduct update, and assisting with the expansion of the yet-to-have-a-good-name group of community health volunteers from various open source communities.

Jacob Rockowitz: To Drupal or not to Drupal…The Webform module’s pickle of a sustainability problem

2 days 10 hours ago

My pickle of a problem

Previously, I have discussed my current work situation, which revolves around the fact that my organization is moving away from Drupal. This situation has led me to ask the question to Drupal or not to Drupal. To date, I’m committed to helping them migrate from Drupal to Sitecore.

I’ve also decided to remain committed to the sustainability of the Webform module. The “sustainability” of the Webform module has different meanings to different people and organizations within the Drupal community. Individuals want to know that there are resources available to provide guidance, review patches, and commit code to a project. An organization using Drupal and the Webform module wants to know that the code is stable, maintained, and secure. For me, I’d like to see compensation for my time in return for my continued commitment to the sustainability of the Webform module.

Being compensated to contribute and maintain code within an open source project can take on many forms. An organization could sponsor my work on the Webform module. At the same time, these opportunities are rare within our community. Frankly, assuming that a single organization could take on the responsibility of something like the Webform module might not be financially feasible.

Stepping back from my problem, there might be a more general solution for improving the Webform module’s sustainability. Still, sustainability is a pickle of a problem for an open source project like the Webform module.

The Webform module’s pickle of a problem

The pickle of a problem around the Webform module, Drupal, and Open Source is that people assume that everything is free. Open source code is free to use and distribute. The ecosystem built around the Webform module reinforces the notion that everything is free because we rarely put a “price tag” next to our...Read More

hussainweb.me: Why you shouldn’t decouple Drupal and why you should

2 days 16 hours ago
Today's post is going to be a quick one; not because it is an easy topic but because a lot has been said about it already. Today, I want to share my thoughts on decoupling Drupal; thoughts that are mainly a mix of borrowed thoughts from several places. I will try to link where I can but I can't separate my thoughts from borrowed ones now. Anyway, by the end of the post, you might have read a lot of things you already knew and hopefully, one or two new things about Decoupling Drupal.

hussainweb.me: The magic of Drupal events

3 days 15 hours ago
I missed joining the DrupalNYC meetup today. Well, I almost missed it but I was able to catch the last 10 minutes or so. That got me thinking about events and that's the topic for today–Drupal events and their impact on my life. I travelled extensively for 4-5 years before the pandemic restrictions were put in place and since then, I have attended events around the world while sitting in my chair. These travels and events are responsible for my learnings and my professional (and personal) growth. And these are the perspectives that have given me the privilege that I enjoy.

Kristen Pol: Celebrate 20 Years of Drupal with DrupalFest and DrupalCon!

3 days 19 hours ago


Image credit: Aaron Deutsch

If you use Drupal at all, you've probably already heard that 2021 is Drupal's 20th anniversary! Pretty cool. :) Check out wikipedia to see Drupal's initial release by Dries Buytaert was January 15, 2001.

In honor of Drupal's 20th year, DrupalFest is this month which is built around the popular DrupalCon North America event. Due to the pandemic, DrupalCon NA is online again this year, but this allows for a more unique content and contribution event model. The events are spread out throughout the month of April to allow for more participation and better integration into everyone's schedule. Hope to "see you" next week at DrupalCon or at one of the Drupal summits!

read more

Tag1 Consulting: Financially Supporting Your Open Source Development Work - with Dries Buytaert - Pt. 2

4 days 3 hours ago

While there are many companies based in open source software that are successfully funding themselves based on consultancy and other services, that’s not necessarily true of individual contributors. As part of our series of talks with Open Source Leaders, Tag1 Consulting’s Managing Director Michael Meyers, VP of Software Engineering Fabian Franz, and Yjs founder Kevin Jahns talk with Dries Buytaert about open source projects and communities. This talk focuses on open source project sustainability and funding. Dries talks about some of the key points that made Drupal successful, and how the project and the Drupal Association have changed and pivoted based on challenges like the coronavirus pandemic. Dries also gives some pointers on how he started to sell his project to others, and how that started to change his role in the project over time, from the primary developer, to a project head focused on visibility. - Part 1 ### Additional resources - Elinor Ostrom: Governing the Commons: https://www.amazon.com/Governing-Commons-Evolution-Institutions-Collective/dp/0521405998 - Featured Essay: Elinor Ostrom’s work on Governing The Commons: An Appreciation --- _For a transcript of this video, see [Transcript: Open...

Read more [email protected]… Wed, 04/07/2021 - 09:20

Drupal Association blog: What's new on Drupal.org? - Q1 2021

4 days 3 hours ago

Read our roadmap to understand how this work falls into priorities set by the Drupal Association with direction and collaboration from the Board and community. You can also review the Drupal project roadmap.

Drupal.org Updates Drupal's 20th Birthday Year

As we close out the first quarter of 2021, we continue the celebration of 20 years of Drupal with #DrupalFest and #DrupalCon!

#DrupalFest is a month-long celebration of all things Drupal, taking place online all around the world. DrupalFest lasts throughout the month of April. Most events are free, and we encourage everyone to attend, and even submit your own!

DrupalCon is right around the corner from April 12-16, happening online. This year's DrupalCon reflects a renewed focus on the strategic initiatives that drive innovation in Drupal. Each day has a half day of live programming for and then a half day of contribution, and all personas are welcome! Join us!

Increased focus on Strategic Initiatives

Speaking of strategic initiatives, the current primary initiatives being highlighted at DrupalCon and beyond are: 

  • Decoupled Menus - This initiative focuses on creating standardized tools and libraries for decoupled Drupal, starting with the menu system. This is the first step in making JavaScript front-ends a central part of the Drupal project. 
  • Easy out of the Box - This mega-initiative combines the efforts of Layout Builder, Media, and Claro to help empower content editors in Drupal to take advantage of the best that Drupal can offer.
  • Automatic Updates - This initiative is focused on the #1 most requested feature in Drupal: automatic updates. The initiative is building a robust and secure system for automatically updating Drupal, starting with security and patch releases.
  • Drupal 10 Readiness - The Drupal innovation train keeps rolling! The Drupal 10 Readiness initiative is rallying the community around what we need to reach our Drupal 10 release date, and helping site owners ensure they're ready for the upgrade when the time comes.

In addition to the content at DrupalCon, you can find ways to get involved in any of these initiatives by checking out the Drupal Strategic Initiative section on Drupal.org.

Decoupled Menu Initiative Support

General projects are a new content type on Drupal.org for code that does not fall into the neat categories of module, theme, or distribution. Instead, these can cover things like JavaScript Components, Drush Extensions, Install Profiles, Libraries, etc.

This is the first step in making Drupal a project greater than just PHP. This capability leans into Drupal's future in Decoupled applications, and in digital experiences beyond the web browser. 

Since the launch of general projects as a new content type on Drupal.org the Decoupled Menu Initiative has made great progress on creating standardized endpoints/libraries for decoupled Drupal solutions.

At DrupalCon North America the Decoupled Menus initiative leads invite you to a hackathon to begin to create applications for this work.

The rapid movement on this initiative shows how quickly the Drupal community can pivot into more robust and standardized Decoupled implementations, and furthers Drupal's lead in the marketplace.

Easy Out of the Box Support

For the Easy Out of the Box team, the Drupal Association has been focused on connecting the initiative leads to the Drupal Contribution Mentoring team, so that at DrupalCon there will be a variety of onramps to help new contributors support this work.

Easy Out of the Box is effectively three initiatives in one, focused on Layouts, Media, and the Claro administrative theme, so people with interest in any of those areas are more than welcome.

AutoUpdates Initiative Cross-Project Collaboration

The Drupal Association Engineering team continues its close collaboration with the AutoUpdates initiative team. Because AutoUpdates requires a server side component that will live on Drupal.org infrastructure, the engineering team needs to be closely involved.

This initiative has also had a heavy focus on cross-project collaboration - with three CMS partners in the PHP ecosystem collaborating together on the basic principles of supporting securely signed update packages.

      

We're also collaborating with other partners, such as the Cloud Native Computing Foundations 'TUF'(The Update Framework) team, and the team behind Composer. 

        

At DrupalCon North America the TUF team will be presenting about securing software package delivery - a topic that is sure to be interesting for all.

Drupal 10 Readiness Support

Drupal 10 is slated for release in June of 2022, which is only a little bit more than a year away. Fortunately, Drupal 10 follows the continuous innovation model of Drupal development that was so successful in the transition from Drupal 8 to Drupal 9. In essence, so long as site owners are up to date with the latest version of Drupal 9 they should be able to make the jump very easily. The only area of concern is deprecated code.

To that end, the Drupal Association engineering team collaborated with Gábor Hotjsy to set up automate code deprecation checking using the DrupalCI infrastructure. This allows the team to understand the most used instances of deprecated code, so that contributed module maintainers can be made aware of the need to update, and so that the Drupal Rector team(supported by Palantir.net) can begin creating automatic deprecation patches.

GitLab Merge Request Updates

Last year, Drupal.org migrated our community contribution tools to GitLab, by integrating the existing Drupal.org issue queues with GitLab's merge request functionality.

Thanks to these improvements, the complete contribution lifecycle can be completed entirely in the browser. As a contributor to Drupal you no longer need to use command line git, install a local development environment, or use a local IDE in order to make your contributions.

Since the initial launch, we've received feedback from many people in the community about improvements to usability with the Drupal.org issue queue integration. Looking at the child issues of this issue, we can see rapid usability improvements that have sped the pace of contribution.

More recently, we worked with our partners at Tugboat.qa to release live deployment previews of your code changes - first for Drupal Core, but now available for contributed projects on Drupal.org as well. This means that even reviewing visual changes or seeing your code deployed to a site can all be done without leaving your browser. This is a huge boon to all contributors, but especially to usability and accessibility experts who can much more easily view the impact of changes across issues.

Major improvements to Community events

In collaboration with the Events Organizers Working Group, the Drupal Association has updated the Drupal.org Community Events section. This new section represents a central repository for all of the events taking place across the Drupal Community, and will ultimately be the replacement for Groups.Drupal.org.

This section allows anyone in the community to submit their events, whether online or in-person, and provides a variety of views to help people find events they'd like to attend. Events can be filtered by type(con, camp, meetup, training, etc); proposed events can be submitted to help avoid scheduling conflicts; and calls for content/speakers can be promoted.

A feed of these events is made available for 3rd party tools built by the community, which is already being used to feed Drupical.com.

Local events are the heart of our community, so we hope that you'll help us by submitting your local events to this new tool!

Documentation updates

Led by community volunteer u/jhodgdon, Drupal.org's documentation tools have seen a variety of updates. In particular, the Drupal contributor guide is now much more complete, helping folks who are new to contribution in Drupal find a place to fit in and get started.

We've also deployed improvements that make it easier to understand whether the documentation you're reading is up-to-date, and how to report problems if you find them.

If you're looking for somewhere to contribute - helping to update documentation is a wonderful place to start!

Coming soon: Discover Drupal Portal

Coming up at DrupalCon is the announcement of a new program: Discover Drupal. This program is part of the Drupal Association's talent and education initiatives, and represents the Drupal Association's commitment to growing the Drupal talent pool and increasing diversity in our community.

With the official announcement just around the corner we won't spoil the details here, but very soon you'll be able to check out the new web portal for the Discover Drupal program and find out what it's all about.

Infrastructure Updates

Over the course of the last quarter the Drupal Association engineering team has provided a variety of feature updates for the Drupal project in terms of testing infrastructure: 

  • PHP8 Testing support - The Drupal Association provided PHP8 testing environments in DrupalCI, and so Drupal versions 9.1 and beyond are all fully PHP 8 compatible.Staying on the leading edge of compatibility gives Drupal the advantage of improved performance and security, and sets us up for success when it's time for Drupal 10.

  • Code Standards test for Drupal Core - Drupal Core tests now provide code standards testing results, saving a laborious manual step when reviewing core contributions.
  • GitLabCI/Pipelines - The Drupal Association has also enabled GitLabCI/Pipelines for these new general projects. This is a precursor to moving to GitLabCI for all Drupal CI uses. With direct maintainer control of the CI configuration for these projects, we can see automated workflows to support a wider variety of projects - allowing for more innovation. However, we need to be cognizant of cost controls as we open up this capability.

The year is off to a fast-paced, productive start and as always it is humbling and gratifying to see the great work that the community accomplishes with the tools the Drupal Association provides.

———

As always, we’d like to say thanks to all the volunteers who work with us, and to the Drupal Association Supporters, who make it possible for us to work on these projects. In particular, we want to thank: 

If you would like to support our work as an individual or an organization, consider becoming a member of the Drupal Association.
Follow us on Twitter for regular updates: @drupal_org, @drupal_infra

Acro Media: Decoupling AcroMedia.com with Drupal 9 & React | Acro Media

4 days 5 hours ago

How we jumped head-first into decoupling Drupal with a React-based design system built for performance and brand consistency.

Our latest corporate initiative is decoupling our website, upgrading to Drupal 9 and achieving the holy grail of web development — a CMS-driven back end, with a modern, decoupled javascript front end using a component-based design system.

Here is a breakdown of the project so far:

It’s funny how things go. As a company, we’re constantly working in Drupal: building, planning, and helping to maintain various modules and websites for both our clients and the Drupal community. While the large majority of our clients and work is in the latest version of Drupal, our site is still running Drupal 7. Shame on us, right! Like many businesses out there, it’s easy to push aside the upgrade when our internal systems and staff are comfortably using the existing platform and everything is working like a well-oiled machine. Well, we finally got the buy-in we needed from our internal stakeholders and we were off to the races. But, we didn’t want just another Drupal website. We wanted to explore the “bleeding edge” and see if we can achieve the holy grail of web development — a CMS-driven back end, with a modern, decoupled javascript front end using a component-based design system. Go big or go home!

Our approach to the back end

After a solid planning phase, we settled on an approach for the new site build and it was time to get going. We decided on Drupal (of course) for the back end since it’s our CMS of choice for many reasons and we could leverage all of the great work that has already been done with the JSON:API. However, not all of our needs were covered out-of-the-box.

Exploring API-first distributions

When we were first getting started, we spent some time looking at using ContentaCMS for our back end. It’s an API-first Drupal distribution that already contains most, if not all, of the modules we needed. Ultimately, we decided against it due to the number of extra modules that were unnecessary for our build. We also knew we wanted to use Paragraphs and Layout Builder, but found some display width issues that didn’t line up with our vision. We ditched ContentaCMS and went back to a fresh Drupal 9 install with just the modules we needed.

Decoupled menus

Another complication we came across focused around decoupled menus. Obviously, to build out a menu on the front end we needed to be able to get menu items. JSON:API Menu Items was installed and gave us a good starting point by exposing the menus in JSON:API. Next, we needed to get around the fact that JSON:API relies on UUID for content but menus use paths. Content also likes to have pretty URLs to use for navigation via path aliases. To display these path aliases from the front end and be able to retrieve the correct node, we need some way to resolve the path alias to its correct content. In comes the Decoupled Router module to solve the problem for us! This module provided the endpoints we needed.

Simplifying the JSON output

When you first install JSON:API, you get all of the data. While this is great, it negatively affects the developer experience by making it harder to find the data you need. JSON:API Extras was critical in improving this experience. With this module, we can easily remove unnecessary fields and customize our API path exactly how we want it. We also used the OpenAPI module to give developers a better high-level look at the available endpoints and their structure, opposed to looking at gross JSON output.

Our approach to the front end

With our back end sorted out, it’s time to get to the front end. When going decoupled, the front end suddenly becomes a whole lot more interesting than just a standard Drupal theme with Twig templates, SASS stylesheets and jQuery. We’re in a whole different realm now with new possibilities. We were 100% on board with having better integration between design and development, where the end result of the design was more than static assets and a 1-hour handoff. Here’s a breakdown of our front end approach.

A new strategy for consistency between design in development

In the past, creative exercises would provide static assets such as style guides to try and capture the design principles of a web property or brand. While this concept is rooted in good intentions, in practice, it never really worked well as a project evolved. It’s simply too difficult to keep design and development in sync in this way. For web development, it’s now understood that the code is a better source of truth, not a style guide, but we still need ways to involve our designers and have them contribute their knowledge of design and UX into the code that is being developed. After all, if you leave these decisions up to developers, you’re not going to end up in a good place (and most developers will readily agree with that sentiment). Luckily for us, applications like Figma, Sketch, and Adobe XD, are leading the way to bridge this gap. While this is still very new territory, there is a lot of exciting progress happening that is enabling the creation of robust design systems that act as a rulebook and single source of truth that is both easily updated, modular, and readily available for product application development.

After an internal study of available technologies for design, we settled on Figma for our design system creative work. Figma runs in either web or desktop applications and is a vector graphic editor and prototyping tool. The team developing it has done an incredible job pushing the envelope on how creative and development can work together. With Figma, we found it was possible to accomplish the following:

Extracting design tokens into our application

With our tokens living in Figma, we still needed a way to bring those static design token values into our development process. This is where Figmagic comes in. Figmagic is a nice tool for extracting design tokens and graphic assets out of Figma and into our application. Once set up, all we need to do in our local development environment is to run yarn figmagic. This connects to Figma and pulls down all of our defined tokens into an organized set of ready-to-use files. From there, we then simply import the file we need into our component and use the values as required. If a value needs to change, this is done in Figma. Re-running Figmagic brings in any updated value which updates any component using it. It works like... magic.

Building reusable front end components

Going decoupled meant breaking away from Drupal’s Twig templating and theming layer. For our front end application, we decided on React for our replacement. React continues to be very popular and well-liked, so we didn’t see any technical advantage to picking anything else. This change brought on some additional challenges in that, as a Drupal development company, our focus has not been React. We undertook some initial training exercises to get our development team on this project up-to-speed with the basics. Between this team, our CTO, our CXO, and a senior technical lead, we quickly trained up and settled on a suite of tools to achieve our desired outcomes of a component-driven React frontend.

Component UI frameworks to increase velocity

For us, the approach to developing the many React components that we needed was to first settle on an established framework. Like Bootstrap is to HTML/CSS development, several React-based frameworks are available to use as a foundation for development. It’s always debatable whether this is necessary or not, but we felt this was the best way for us to get started as it greatly increases the development velocity of our project while also providing good reference and documentation for the developers creating our components. We researched several and tried a few, but eventually found ourselves leaning towards Material UI. There were several reasons for this decision, but mainly we like the fact that it is an established, proven, framework that is flexible, well documented, and well supported. With Material UI (MUI), adjusting the base theme using our design tokens from Figma already gave us a good start. Its framework of pre-built components allowed us to make minimal changes to achieve our design goals while freeing up time to focus on our more unique components that were a bit more custom. This framework will continue to be of great benefit in the future as new requirements come up.

Previewing design system component without Drupal

Without a standard Drupal theme available, we needed somewhere to be able to preview our React components for both development and UX review. A decoupled front end, and the whole point of the design system, is that the front end should be as back end agnostic as possible. Each component should stand alone. The front end is the front end and the back end could be anything. Since we haven’t yet connected the front end components to Drupal’s JSON:API, we still needed an easy way to view our design system and the components within it. For this, we used Storybook. Storybook was made for developing and previewing UI components quickly. As a developer working locally, I install and spin up an instance of Storybook with a single command within our project repo. Storybook then looks at our project folder structure, finds any story files that we include as part of all of the components we develop, and generates a nice previewer where we can interactively test out our component props and create examples that developers in the future may need when implementing a component. Storybook is our design system library and previewer as well as our developer documentation. When we are done developing locally and push code to our repository, our deployment pipeline builds and deploys an updated Storybook preview online.

Bringing it all together

At this point, we have our back end and API established. We also have our front end component library created. Now we need to bring it all together and actually connect the two.

Matching the Drupal UI to our React components

React components are standalone UI elements and are made up of props that determine their functionality. So, for instance, a Button component could have many variants for how it looks. A button could include an icon before or after the text, or it could be used to open a link or a dialogue window, etc. A simple component like this might have a whole bunch of different props that can be used in different ways. To be able to control those props through the Drupal UI, we decided to use the Paragraphs module. A paragraph in Drupal is essentially a mini content type for a specific use. In Drupal, we created paragraphs that matched the functionality we needed from our React components so that the Drupal UI would be, in the end, setting the component props. This is a bit confusing to set up at first and something that will probably not be nailed down first try, but, in the process of setting up the Drupal UI in the context of the React components, you can really start to see how the connection between the two is made. At this point, it’s pretty easy to see if a component is missing any props or needs to be refactored in some way.

We also went with Paragraphs because we wanted to give our content creators a more flexible way of creating content. A standard Drupal content type is pretty rigid in structure, but with Paragraphs, we can give content creators a set of building blocks that can be grouped and combined in many different ways to create a wide variety of pages and layouts in a single content type. If you’re not familiar with this style of creating content in Drupal, I suggest you take a look at this post I wrote a while back. Look at that and imagine React components rendering on the page instead of Drupal templates. That’s essentially what we’re aiming to do here.

An argument against Paragraphs is that it could potentially make page building more time-consuming given that you don’t have that typical rigid structure of a content type. This is especially true if pages on a site being built typically all follow a similar format. In this case, we still like to use Paragraphs anyway but we will typically build out unpublished pages that act as templates. We then install the Replicate module which lets content creators clone the template and use it as a starting point. This makes creating pages easy and consistent while still allowing flexibility when needed. Win-win.

Taking the Next.js step

Since we settled on React, we started our front end project as a standard react build using the built-in create-react-app command. But, after some additional investigation, we decided that a better option for our use case would be to use the Next.js framework. Given that the corporate site is, at its core, is a marketing and blogging website, Next.js allows us to still build the frontend using React but gives us some extra capabilities this type of website needs.

One of these capabilities is incoming server-side rendering which we found increases the performance of our application. This also has SEO benefits due to pages being rendered serverside and sent to the client, as opposed to the standard client-side rendering most React applications use where the client machine handles processing and rendering.

Component factories are key to interpreting the API data

We were also attracted to the structure and organization of the project when using a framework like Next.js, as well as the dynamic routing capabilities. This significantly simplified the code required to implement our decoupled menu and page routing. Using the dynamic routes provided by Next.js, we could create “catch-all” routes to handle the ever-growing content in the CMS. By querying the Drupal API, we can get all the available path aliases for our content and feed it to Next.js so it can pre-build our pages. It can use the path aliases to resolve the content specific to the page through the Decouple Router module, which will then feed that data to a component factory to handle the decision as to what high-level React page component is necessary to build a page. For example, if the data is for a basic page content type, the page factory component returns our Page component, if it’s a blog post content type, it returns the Blog Page component, etc. Each of these components knows how to handle the specific data fed to it, but the factory component is what connects the data to the right page.

The way Paragraphs can be added to a page for composing a piece of content also created a challenge on its own in reading that data and returning the right component. We decided to create another factory component for this. Similar to the page factory component, this one takes in the paragraph data and determines which React components it needs to render the content.

What’s next in our decoupled adventure

Believe it or not, what we’re building is still a work in progress. While we have most of the tech requirements figured out, we’re still actively putting all of the final pieces in place and fine-tuning the backend UI and modules requirements. All in all, we’re feeling really good about this progress and can see the value of what we’re building both for ourselves and the clients we serve. In our opinion that is based on experience and research, decoupled is the future, and we’re excited to walk this path.

With that said, even once our own decoupled site has launched, we still have a lot of work left to do. For one, we still need to get a method in place for managing Drupal blocks and regions. More factory components will be critical here to interpret that data. Given that our clients are primarily ecommerce retailers in one form or another, we still have the whole ecommerce side of web development to sort out, including product catalogues, add-to-cart forms, carts, wish lists, checkout flows, etc. The list is long. However, what we have is a framework that can be repurposed and added on to. It finally helps tie together many disciplines of web development, both creative and technical, that are traditionally siloed. It’s also blazing fast and just plain cool. This is an investment not only in our own online business front but in something greater that we hope to share with others through work, community and general knowledge.

Thanks for taking the time to read this. If you want to chat about this initiative further, drop us a line.

undpaul: Please choose your view mode... Now!

4 days 9 hours ago
Switch view modes for all entity types editorially with our new Drupal module! In our projects we lacked versatility and flexibility for site builders as well as editors in layout output. So we developed a new module that provides editors with several predefined view modes with different layouts to choose from, while still maintaining site layout consistency.

hussainweb.me: Accessing Drupal.org API

4 days 17 hours ago
I am going to keep today's DrupalFest post simple and talk about the API to access content on drupal.org. The Drupal.org API is a public API that allows you to access content such as projects (modules, themes, etc), issues, pages, and more. The API returns data as a simple JSON structure and has only limited features with regards to filtering and gathering nested data. In this post, I will describe more about this API and various ways to access it.

Brian Perry: Help Build a Decoupled Menu Web Component at DrupalCon

4 days 21 hours ago

Next week at DrupalCon North America as part of the Decoupled Menus Initiative I'll be participating in the Decoupled Menu Hackathon. Members of the community will be coming together to build a variety of menu components using different approaches and frameworks as a way to exercise a new menu endpoint provided by the Decoupled Menus module, along with the infrastructure supporting the new general project type on Drupal.org.

Leading up to DrupalCon I've also begun work on the Generic Drupal Web Components project. Starting with a menu component, it aims to create a library of generic web components that are accessible, framework agnostic, possible to style, and easy to use with data provided by Drupal. Here's a quick video overview:

Checked
1 hour 55 minutes ago
Drupal.org - aggregated feeds in category Planet Drupal
Subscribe to Drupal Planet feed