Drupal News

Drupal Association blog: PreviousNext: Our ongoing support for the Drupal Association

Main Drupal Feed - Mon, 04/20/2020 - 18:41

Today's guest post by Owen Lansbury, Co-Founder & Chair of PreviousNext, is the next installment in our #DrupalCares series. My thanks to Owen for sharing why the Drupal Association is so important to his business.

_________________________________

As an Australian based company, we’re often asked why we support the Drupal Association when their direct involvement in our region is relatively limited. To paraphrase Monty Python, “What has the Drupal Association ever done for us???”.

Like most of you, our first exposure to Drupal was visiting Drupal.org, downloading Drupal core and a few modules and seeing what we could do with the software. In our case, we quickly saw its potential with our Australian clients, and within a year had a thriving little company building Drupal websites. During this time, we'd also created our first personal and company Drupal.org profiles, started engaging with the local Drupal community via groups.drupal.org and attended our first meetups.

PreviousNext had officially started business in February 2009, so we felt it would be a bit extravagant to attend DrupalCon D.C. the following month before we'd even billed our first client. This meant waiting a whole year until the opportunity presented itself again at DrupalCon San Francisco in April 2010. Drupal was well outside the mainstream in Australia at that time, so attending DrupalCon meant our first taste of how big it was becoming internationally, and most importantly, who the community were that we were now a part of.

That first DrupalCon was the catalyst for us to ingrain code contribution as a core business policy at PreviousNext, providing our team with the opportunity to spend up to 20% of their working hours on non-billable Drupal code. We also viewed attending DrupalCon as an important part of our team's professional development, and implemented a policy of full funding for accepted speakers and partial funding for people that wanted to attend as part of a longer overseas vacation. This saw PreviousNext have at least a couple of attendees at most DrupalCons in North America and Europe throughout the 2010s.

Our engagement at DrupalCons meant the PreviousNext team developed personal relationships with other Drupal contributors around the world, which they then continued online once they returned home and kept contributing code. This contribution along with our financial support of the Drupal Association as a Supporting Partner has helped keep PreviousNext consistently in the Top 10 firms listed on the Drupal.org marketplace, providing us with a profile as a trusted Drupal services company despite our relatively small size and remote location.

At a broader level, the Drupal Association helped drive the local Australian and New Zealand Drupal community forward by staging DrupalCon Sydney in 2013. This played a key role in positioning Drupal as a viable platform for the Australian Government to adopt on a large scale in 2014. Since then, our locally organised DrupalSouth events have benefited from having a Code of Conduct for our attendees to adhere to and a Community Working Group to escalate incidents to that require a formal mediation process.

I recently told a group of Australian Drupal agency executives that the Drupal Association is often invisible when things are running smoothly. Drupal.org is handling its 10 million plus yearly visits, well managed DrupalCons are running on multiple continents every few months, collaboration between community members being facilitated and governance processes for when things get complicated.

As a company that has built its business on Drupal, PreviousNext considers the stable operation of the Drupal Association to be crucial to our continued success. Now that they need our financial help, we've been more than happy to increase our Supporting Partner commitment and paid for our entire team to maintain their individual memberships. We hope you can help too!

Join #DrupalCares

Microserve: 5 Benefits to Drupal's Layout Builder - from an editor’s perspective

Main Drupal Feed - Mon, 04/20/2020 - 14:03
5 Benefits to Drupal's Layout Builder - from an editor’s perspective Hannah Bryson Mon, 04/20/2020 - 14:03

Late last year I was lucky enough to attend DrupalCon. At the conference, I heard about Layout Builder, a new tool developed within Drupal 8 that allows editors to configure content more efficiently and easily. 

Having worked with Drupal for several years, I was excited to hear that they were building on an already great foundation and improving the user interface by making it more flexible and sophisticated for editors. 

Microserve: 5 Benefits to Drupal's Layout Builder - from an editor’s perspective

Main Drupal Feed - Mon, 04/20/2020 - 14:03
5 Benefits to Drupal's Layout Builder - from an editor’s perspective Hannah Bryson Mon, 04/20/2020 - 14:03

Late last year I was lucky enough to attend DrupalCon. At the conference, I heard about Layout Builder, a new tool developed within Drupal 8 that allows editors to configure content more efficiently and easily. 

Having worked with Drupal for several years, I was excited to hear that they were building on an already great foundation and improving the user interface by making it more flexible and sophisticated for editors. 

Microserve: 5 Benefits to Drupal's Layout Builder - from an editor’s perspective

Main Drupal Feed - Mon, 04/20/2020 - 14:03
5 Benefits to Drupal's Layout Builder - from an editor’s perspective Hannah Bryson Mon, 04/20/2020 - 14:03

Late last year I was lucky enough to attend DrupalCon. At the conference, I heard about Layout Builder, a new tool developed within Drupal 8 that allows editors to configure content more efficiently and easily. 

Having worked with Drupal for several years, I was excited to hear that they were building on an already great foundation and improving the user interface by making it more flexible and sophisticated for editors. 

Jacob Rockowitz: Individual users can now customize a webform's results table

Main Drupal Feed - Mon, 04/20/2020 - 13:18

Background

The Webform module for Drupal 8 provides a customizable table of submission results. The table of submission results does not use Drupal's Views module but does extend Drupal's EntityListBuilder, which "defines a generic implementation to build a listing of entities." The WebformEntityListBuilder allows users to filter, sort, and add/remove columns from the submission results table.

The below screencast shows how the submission results table can be customized.

The goal of this user experience is to provide a quick and easy way to review submissions without requiring or expecting someone to use a View. Of course, developers and advanced site builders can replace the Webform module's submission results table with a custom view. Here is a video showing how to customize and improve the Webform module's Views Integration.

Every instance of a webform and webform node submission results table can be customized by anyone that can update the webform. Every submission reviewer will see that same customized table of submission results, which is fine for basic forms with a few reviewers. A problem arises for complex forms with very different reviewers. For example, in an application review process, evaluators might want to see certain table columns while an administrator might want to see completely different table columns.

Approach

Luke Leber recognized this problem and created Issue #3108433: Allow users to personalize the submission list in the Webform module's issue queue. Luke suggested using Drupal's Read More

Jacob Rockowitz: Individual users can now customize a webform's results table

Main Drupal Feed - Mon, 04/20/2020 - 13:18

Background

The Webform module for Drupal 8 provides a customizable table of submission results. The table of submission results does not use Drupal's Views module but does extend Drupal's EntityListBuilder, which "defines a generic implementation to build a listing of entities." The WebformEntityListBuilder allows users to filter, sort, and add/remove columns from the submission results table.

The below screencast shows how the submission results table can be customized.

The goal of this user experience is to provide a quick and easy way to review submissions without requiring or expecting someone to use a View. Of course, developers and advanced site builders can replace the Webform module's submission results table with a custom view. Here is a video showing how to customize and improve the Webform module's Views Integration.

Every instance of a webform and webform node submission results table can be customized by anyone that can update the webform. Every submission reviewer will see that same customized table of submission results, which is fine for basic forms with a few reviewers. A problem arises for complex forms with very different reviewers. For example, in an application review process, evaluators might want to see certain table columns while an administrator might want to see completely different table columns.

Approach

Luke Leber recognized this problem and created Issue #3108433: Allow users to personalize the submission list in the Webform module's issue queue. Luke suggested using Drupal's Read More

Web LMS Theme

Drupal Themes - Mon, 04/20/2020 - 12:02

Description is coming soon.

Ny Media: E-commerce after the corona crisis; a lasting change

Main Drupal Feed - Mon, 04/20/2020 - 10:36
E-commerce after the corona crisis; a lasting change thomas April 21, 2020

Over the course of a few months, the Corona crisis has changed the way we live, work and spend money. In recent months, consumers' trade patterns have changed drastically. While the physical stores have been closed or affected by sales failure, most serious and well-established online stores have done very well. The grocery and construction industries in particular have seen a huge upswing in the nordic markets. But also in other industries such as the interior-, books-, shoe and clothing industries, our customers experience a significant increase in sales.

Turnover in e-commerce in the Nordic countries has been steadily increasing in recent years. The corona crisis has probably only accelerated a growth that would have come anyway. One thing that often follow a crisis like this, is a rapid change of society. The e-commerce explosion is a good example of this.

We have reviewed the figures from 5 of our well-established online stores in 5 different industries to look at the trends through the corona crisis. In terms of sales, all the stores have had a formidable increase. On average, the increase has been 50% in the period from the 15th of february to the 21st of april when comparing 2020 to 2019.

Turnover in MNOK in the period 15th of february to the 21st of april, 2019 and 2020.

 

So how can we assume that this change will be permanent and that not all sales will go back to the physical stores after the crisis is over?
  • Several larger surveys (such as DIBS's annual e-commerce survey) show that as sales increase, new and larger groups of people are becoming aware of the benefits of ecommerce. A large and important part of the annual increase in turnover is that a larger part of the population adopts e-commerce in everyday life.

We have reviewed the figures from the same 5 stores to look at the trend of new users registering av customers during the Corona crisis:

Comparison of the number of registered users in the period 1 February to 20 April for the last 3 years.

 

The result shows a formidable increase in the number of newly registered customers from 2019 to 2020 in the same time period. In fact, the increase is over 300%. Not only do the existing users shop more online during the period, but new customers are now flowing to the online stores. If these stores manage to give these new customers a good trading experience, there is reason to believe that a large proportion of these will become regular customers even after the corona crisis is over.

A switch to digital commerce and a unified shopping experience across channels and platforms is imperative in the time to come. Focusing on e-commerce has never been more important than now.

Where should you start if you have a physical store and are one of those who has not yet established an online store?

Don't panic and make hasty decisions. Many are now settling on simple solutions that are virtually "free", in order to be able to start selling online as quickly as possible. Remember, however, that having an item and a payment solution online does not mean your're going to sell your products. It is also such that nothing is free. All the time you spend on learning platforms, integrating systems and entering all product data also represents a significant cost for your business. It is important that the choices you make now are something that you can build on in the years to come.
Ecommerce is complex and customers' demands for product information, editorial information and shopping experience are very high, compared to the situation just a few years ago.
We therefore think it's a good time to take a deep breath and set up a digital strategy before you get started. It will determine what kind of solution you should go for, what product range you should prioritize, how to work and what channels to promote in.

Start by asking yourself the following questions:

  • What shopping experience and product range do I want to offer my customers online? How should the online store work together with your physical store?
  • Who are my competitors and what do they offer online? How can I distinguish myself from these with the same goods, without competing on price alone?
  • Where and how will my customers find me online? And how do I ensure that I take best care of the visits I receive?
  • How much time and resources do I have available to work on this? What can I do for myself and what services do I need to buy from others?
  • What features does my technical solution have to offer and what do I need to tailor to differentiate myself from my competitors?
  • How do I keep track of logistics and customer communications when I get more sales channels than I'm used to?
  • How do I make sure the online store is profitable? What do I earn from my goods after marketing, payment solutions fees, etc. have been paid? 

 

What does all this mean for those of you who have been running an online store for a while? 

This is both a great opportunity and a potential challenge. On one side, the total net sales in the future will increase and your potential increases accordingly. At the same time, competition is naturally intensified as well.

  • You've probably got more competitors in the last few months who have many of the same products at the same prices as you. There are probably also more people competing for the same keywords and coming up with similar messages.
  • This means that you have to work on making the shopping experience better, separate yourself from the rest with better / more editorial content and become even better at digital marketing!

 

We would love to hear from you!

Get in touch if you are thinking of either establishing an online store or improving your existing concept. Chances are that one of our consultants has worked on the same or similar problem as you are facing right now. That means there is also a chance that we can assist you with a faster, more efficient and more profitable solution. Please contact us for an informal chat!

Phone: +47 920 28 082
Email: post@nymedia.no

Tag1 Consulting: How a virtual DOM could bring Drupal to a reactive front-end future - part 2

Main Drupal Feed - Mon, 04/20/2020 - 04:52

A debate has been ongoing for several years about how Drupal's front end can compete against the primacy of JavaScript frameworks that are rapidly gaining steam in the wider web development community. In this multi-part blog series, we review the most important concepts behind this potential future for Drupal's front end, including Web Components, virtual DOMs, and what Drupal can learn from other ecosystems. In this second installment in the series, we examine how Drupal's render tree bears striking similarities to virtual DOMs in other frameworks and what future Drupal versions could look like under the hood.

Read more preston Sun, 04/19/2020 - 21:52

Tag1 Consulting: How a virtual DOM could bring Drupal to a reactive front-end future - part 2

Main Drupal Feed - Mon, 04/20/2020 - 04:52

A debate has been ongoing for several years about how Drupal's front end can compete against the primacy of JavaScript frameworks that are rapidly gaining steam in the wider web development community. In this multi-part blog series, we review the most important concepts behind this potential future for Drupal's front end, including Web Components, virtual DOMs, and what Drupal can learn from other ecosystems. In this second installment in the series, we examine how Drupal's render tree bears striking similarities to virtual DOMs in other frameworks and what future Drupal versions could look like under the hood.

Read more preston Sun, 04/19/2020 - 21:52

Tag1 Consulting: How a virtual DOM could bring Drupal to a reactive front-end future - part 2

Main Drupal Feed - Mon, 04/20/2020 - 04:52

A debate has been ongoing for several years about how Drupal's front end can compete against the primacy of JavaScript frameworks that are rapidly gaining steam in the wider web development community. In this multi-part blog series, we review the most important concepts behind this potential future for Drupal's front end, including Web Components, virtual DOMs, and what Drupal can learn from other ecosystems. In this second installment in the series, we examine how Drupal's render tree bears striking similarities to virtual DOMs in other frameworks and what future Drupal versions could look like under the hood.

Read more preston Sun, 04/19/2020 - 21:52

Evolving Web: Designing a Flexible Content Model with Drupal: Layout Builder & Paragraphs

Main Drupal Feed - Mon, 04/20/2020 - 00:58

Since I started building websites in 2007, two things that I constantly hear are: “How do we make it easier for non-technical users to update our website?” And “How can we give content editors more flexibility?"

In 2008, when I first used Drupal, it seemed like the first problem was already solved. Drupal is designed for managing consistent, structured content. So creating content with a predictable set of fields, like events, news, courses, or publications, has always been easy to do. You don’t need to know HTML and CSS to fill in a set of predefined fields, and the theme system allows you to display those fields how you want on the page.

But combining that with the requirement for really flexible marketing content was always tricky. For example, if you asked me 10 years ago, “How do I build a homepage where I can feature a set of curated news items, display a couple clear calls to action and supporting images and videos that I can customize when I need to?” it seems like it should be a simple question. But you could get 5 different answers, and none of them would be described as “a great experience for content editors”.

In the meantime, responsive design, content portability, and accessibility concerns are increasingly important. Now more than ever, we need to make sure that by adding flexibility, we’re not sacrificing semantic markup and data.

Enters Layout Builder

When I first tried out the Drupal Layout Builder a couple years ago, I got really excited. Finally, the drag-and-drop page builder we’ve all been waiting for that will make creation of flexible pages without code possible. Since that first release, the Layout Builder has become a stable solution that we can start to use on real-world projects.

Last year, my colleague Annika and I ran a comparative usability study, to see how Layout Builder could be used by content editors for creating flexible landing pages. There are definitely some usability issues when you use Layout Builder for this use-case out-of-the-box. But a suite of helper modules has emerged that make it easier to use for content editors.

Paragraphs Everywhere

In the meantime, over the last 4-5 years, a module called Paragraphs has garnered wide-spread adoption in the Drupal community. It was originally designed to create collections of fields within a larger piece of content. Although it wasn't designed to manage layout specifically, it is often used to build flexible, landing-page style content where the content author can mix-and-match content components (Paragraphs) to assemble a page. Fields can be added that act as settings for the style of each Paragraph, to add more flexibility.

So, Paragraphs or Layout Builder?

So which is the best approach to creating this flexible content. As usual, it depends. And the answer might be both.

(Note that the Layout Builder can also be used to create a layout for more predictable content types as well. I’m not going to cover that use case here, and will focus on the flexible page use case only.)

Paragraphs

Paragraphs is great for building structured content that is consistently formatted. With Paragraphs, you get to create Paragraph Types, each of which has its own set of fields, that live within the parent content. The content editor can pick from a list of options (which the site builder can control), deciding which content components to add to the page. With Paragraphs, the content editor is building a form, and then filling the content into that form. For example, they can add a call to action and then a video, and then a side-by-side text. And then they can fill in the content for all those elements. Later, they could reorder them.

Paragraphs provides a lot of control and more streamlined options for content editors. It requires fewer clicks to add a new piece of content. It’s great for situations where you want to keep things simple. Many situations don’t actually require variations in layout, but just to need to allow for a flexible content model.

With Paragraphs, you can combine components to create a flexible page.

Caveats: With Paragraphs, it’s important to customize the Form display, so that paragraphs are collapsed or displayed as a preview, instead of always displaying the mega-form that can result from constructing a page this way. Nesting a lot of paragraphs within each other can slow down the editing experience. Also, Paragraphs is a contributed module, although a very popular one. It's not part of Drupal core.

Downsides: Paragraphs was not designed to manage your layout. Building nested paragraphs with field labels like “Two-Column Layout” with sub-fields like “First Column” and “Second Column” creates confusion for content editors. You don’t get the ease of dragging and dropping elements from one part of the layout to the other. And behind the scenes, your content model will get messy very quickly if you use a lot of nesting.

Layout Builder

The Layout Builder is ideal for giving your content editors a visual way to manage how content and layout fit together. You do this by configuring Block Types (similar to how you would configure Paragraph Types) and then giving editors access to edit the layout of a page. They can add Sections, each of which has a layout, and then place blocks into those regions.

Layout Builder provides an open palette of options to the content editor or marketer who will be managing the page, although you can restrict some of the options using the modules below. The biggest difference with the Layout Builder is the ability to add “Sections” for each page, which display a set of serve as containers for the content that makes up the page. The fact that each Section can have its own layout brings a whole other dimension of flexibility that Paragraphs lacks. This is the key to your decision of which approach to take. Is that extra flexibility desirable or not?

The layout is visually represented in the back-end of the site, so you can see what your layout will look like as you edit, a feature that delights content editors once they've figured out how it works.

Layout Builder provides much more flexibility in how content components are displayed on the page. You start by assembling Sections, each of which has a set of regions, in which you can place your content.

Caveats: the layout builder requires customization to be usable by content editors. I recommend that you:

Downsides: There will be a learning curve for content editors used to the approach of filling in a form. They’ll need to change their workflow, and it will take time for them to learn. More clicks are required to get your content onto the page. Regardless of how much you trust the editors’ judgement, you’re giving up more control to content editors when you use the Layout Builder.

Another thing to note is that there are currently no migration tools for getting your content into a layout (although there's an issue for adding a Destination Plugin that would make this easier).

Other Ways to Build Flexible Pages What about Gutenberg?

Gutenberg for Drupal doesn't store your content as structured content, it gets stored as markup. You can use the Gutenberg interface to create things that appear like content components, but the data essentially gets stored in a large body field.

What about Cohesion?

Over the past few years, the folks at Cohesion (now part of Acquia) have been busy creating their own flexible page-building framework in which you use Components to assemble pages. Cohesion goes beyond the functionality of Layout Builder and Paragraphs, providing tools for changing the look and feel (using CSS and JavasSript) of Components and Templates through the admin UI. It also has features like “Helpers” providing default sets of content components that can be dropped into a page, and the ability to share a library of Components between sites.

Cohesion is optimized for marketing teams that need additional flexibility and control across pages and sites, and need to be able to create new types of Components without a developer stepping in. And by offering the ability to change the look-and-feel without touching a single Drupal file, its ambitions go beyond solving the problems of content editors. Its goal is the ultimate no-code solution for not just one, but many websites. Note that Cohesion is a paid service that Acquia offers as part of its Digital Experience suite.

What about Metadata? What about Accessibility?

I’m so glad you asked! One problem with really flexible content is that it’s inherently less consistent than predictable content types And that means you can easily lose the semantic markup you need for your page to show up correctly in search results and social media, and makes your content easily available to screen readers. Whatever approach you take, it’s important to add meta data to your content along with all the flexible content components, and to make sure that value of this meta data is clear to content editors. You're using Drupal because it's great at managing structured content and outputing semantic markup. Don't get in the way of that!

Takeaways

Remember that you’re configuring a system, not building a page. Whatever solution you pick should be the way you’re planning to manage a whole set of content and pages. When you're staring at the diagrams above, look at your whole range of design patterns, or wireframes and mockups, and think about which model would work best.

We’re currently working with the University of Waterloo on their migration to Drupal 8, and they took the step of prototyping both options and running it by their content editors to get their feedback before making a decision. This is a great way to test out the pros and cons of each option and to get buy-in from them in advance.

Keep in mind that it’s possible to combine both approaches. You can use Paragraphs for structured content elements, and use Layout Builder to put the pieces together in a Layout. Just try not to over-engineer your solution. Think again about the experience you're building for content editors.

Whichever option you pick to build your flexible pages, try and make a decision at the outset of the project, as you’re designing your content components and creating your Pattern Library or UI Kit. It will have an impact on how components are combined on the page, and the layout options you provide.

 

+ more awesome articles by Evolving Web

Evolving Web: Designing a Flexible Content Model with Drupal: Layout Builder & Paragraphs

Main Drupal Feed - Mon, 04/20/2020 - 00:58

Since I started building websites in 2007, two things that I constantly hear are: “How do we make it easier for non-technical users to update our website?” And “How can we give content editors more flexibility?"

In 2008, when I first used Drupal, it seemed like the first problem was already solved. Drupal is designed for managing consistent, structured content. So creating content with a predictable set of fields, like events, news, courses, or publications, has always been easy to do. You don’t need to know HTML and CSS to fill in a set of predefined fields, and the theme system allows you to display those fields how you want on the page.

But combining that with the requirement for really flexible marketing content was always tricky. For example, if you asked me 10 years ago, “How do I build a homepage where I can feature a set of curated news items, display a couple clear calls to action and supporting images and videos that I can customize when I need to?” it seems like it should be a simple question. But you could get 5 different answers, and none of them would be described as “a great experience for content editors”.

In the meantime, responsive design, content portability, and accessibility concerns are increasingly important. Now more than ever, we need to make sure that by adding flexibility, we’re not sacrificing semantic markup and data.

Enters Layout Builder

When I first tried out the Drupal Layout Builder a couple years ago, I got really excited. Finally, the drag-and-drop page builder we’ve all been waiting for that will make creation of flexible pages without code possible. Since that first release, the Layout Builder has become a stable solution that we can start to use on real-world projects.

Last year, my colleague Annika and I ran a comparative usability study, to see how Layout Builder could be used by content editors for creating flexible landing pages. There are definitely some usability issues when you use Layout Builder for this use-case out-of-the-box. But a suite of helper modules has emerged that make it easier to use for content editors.

Paragraphs Everywhere

In the meantime, over the last 4-5 years, a module called Paragraphs has garnered wide-spread adoption in the Drupal community. It was originally designed to create collections of fields within a larger piece of content. Although it wasn't designed to manage layout specifically, it is often used to build flexible, landing-page style content where the content author can mix-and-match content components (Paragraphs) to assemble a page. Fields can be added that act as settings for the style of each Paragraph, to add more flexibility.

So, Paragraphs or Layout Builder?

So which is the best approach to creating this flexible content. As usual, it depends. And the answer might be both.

(Note that the Layout Builder can also be used to create a layout for more predictable content types as well. I’m not going to cover that use case here, and will focus on the flexible page use case only.)

Paragraphs

Paragraphs is great for building structured content that is consistently formatted. With Paragraphs, you get to create Paragraph Types, each of which has its own set of fields, that live within the parent content. The content editor can pick from a list of options (which the site builder can control), deciding which content components to add to the page. With Paragraphs, the content editor is building a form, and then filling the content into that form. For example, they can add a call to action and then a video, and then a side-by-side text. And then they can fill in the content for all those elements. Later, they could reorder them.

Paragraphs provides a lot of control and more streamlined options for content editors. It requires fewer clicks to add a new piece of content. It’s great for situations where you want to keep things simple. Many situations don’t actually require variations in layout, but just to need to allow for a flexible content model.

With Paragraphs, you can combine components to create a flexible page.

Caveats: With Paragraphs, it’s important to customize the Form display, so that paragraphs are collapsed or displayed as a preview, instead of always displaying the mega-form that can result from constructing a page this way. Nesting a lot of paragraphs within each other can slow down the editing experience. Also, Paragraphs is a contributed module, although a very popular one. It's not part of Drupal core.

Downsides: Paragraphs was not designed to manage your layout. Building nested paragraphs with field labels like “Two-Column Layout” with sub-fields like “First Column” and “Second Column” creates confusion for content editors. You don’t get the ease of dragging and dropping elements from one part of the layout to the other. And behind the scenes, your content model will get messy very quickly if you use a lot of nesting.

Layout Builder

The Layout Builder is ideal for giving your content editors a visual way to manage how content and layout fit together. You do this by configuring Block Types (similar to how you would configure Paragraph Types) and then giving editors access to edit the layout of a page. They can add Sections, each of which has a layout, and then place blocks into those regions.

Layout Builder provides an open palette of options to the content editor or marketer who will be managing the page, although you can restrict some of the options using the modules below. The biggest difference with the Layout Builder is the ability to add “Sections” for each page, which display a set of serve as containers for the content that makes up the page. The fact that each Section can have its own layout brings a whole other dimension of flexibility that Paragraphs lacks. This is the key to your decision of which approach to take. Is that extra flexibility desirable or not?

The layout is visually represented in the back-end of the site, so you can see what your layout will look like as you edit, a feature that delights content editors once they've figured out how it works.

Layout Builder provides much more flexibility in how content components are displayed on the page. You start by assembling Sections, each of which has a set of regions, in which you can place your content.

Caveats: the layout builder requires customization to be usable by content editors. I recommend that you:

Downsides: There will be a learning curve for content editors used to the approach of filling in a form. They’ll need to change their workflow, and it will take time for them to learn. More clicks are required to get your content onto the page. Regardless of how much you trust the editors’ judgement, you’re giving up more control to content editors when you use the Layout Builder.

Another thing to note is that there are currently no migration tools for getting your content into a layout (although there's an issue for adding a Destination Plugin that would make this easier).

Other Ways to Build Flexible Pages What about Gutenberg?

Gutenberg for Drupal doesn't store your content as structured content, it gets stored as markup. You can use the Gutenberg interface to create things that appear like content components, but the data essentially gets stored in a large body field.

What about Cohesion?

Over the past few years, the folks at Cohesion (now part of Acquia) have been busy creating their own flexible page-building framework in which you use Components to assemble pages. Cohesion goes beyond the functionality of Layout Builder and Paragraphs, providing tools for changing the look and feel (using CSS and JavasSript) of Components and Templates through the admin UI. It also has features like “Helpers” providing default sets of content components that can be dropped into a page, and the ability to share a library of Components between sites.

Cohesion is optimized for marketing teams that need additional flexibility and control across pages and sites, and need to be able to create new types of Components without a developer stepping in. And by offering the ability to change the look-and-feel without touching a single Drupal file, its ambitions go beyond solving the problems of content editors. Its goal is the ultimate no-code solution for not just one, but many websites. Note that Cohesion is a paid service that Acquia offers as part of its Digital Experience suite.

What about Metadata? What about Accessibility?

I’m so glad you asked! One problem with really flexible content is that it’s inherently less consistent than predictable content types And that means you can easily lose the semantic markup you need for your page to show up correctly in search results and social media, and makes your content easily available to screen readers. Whatever approach you take, it’s important to add meta data to your content along with all the flexible content components, and to make sure that value of this meta data is clear to content editors. You're using Drupal because it's great at managing structured content and outputing semantic markup. Don't get in the way of that!

Takeaways

Remember that you’re configuring a system, not building a page. Whatever solution you pick should be the way you’re planning to manage a whole set of content and pages. When you're staring at the diagrams above, look at your whole range of design patterns, or wireframes and mockups, and think about which model would work best.

We’re currently working with the University of Waterloo on their migration to Drupal 8, and they took the step of prototyping both options and running it by their content editors to get their feedback before making a decision. This is a great way to test out the pros and cons of each option and to get buy-in from them in advance.

Keep in mind that it’s possible to combine both approaches. You can use Paragraphs for structured content elements, and use Layout Builder to put the pieces together in a Layout. Just try not to over-engineer your solution. Think again about the experience you're building for content editors.

Whichever option you pick to build your flexible pages, try and make a decision at the outset of the project, as you’re designing your content components and creating your Pattern Library or UI Kit. It will have an impact on how components are combined on the page, and the layout options you provide.

 

+ more awesome articles by Evolving Web

Evolving Web: Designing a Flexible Content Model with Drupal: Layout Builder & Paragraphs

Main Drupal Feed - Mon, 04/20/2020 - 00:58

Since I started building websites in 2007, two things that I constantly hear are: “How do we make it easier for non-technical users to update our website?” And “How can we give content editors more flexibility?"

In 2008, when I first used Drupal, it seemed like the first problem was already solved. Drupal is designed for managing consistent, structured content. So creating content with a predictable set of fields, like events, news, courses, or publications, has always been easy to do. You don’t need to know HTML and CSS to fill in a set of predefined fields, and the theme system allows you to display those fields how you want on the page.

But combining that with the requirement for really flexible marketing content was always tricky. For example, if you asked me 10 years ago, “How do I build a homepage where I can feature a set of curated news items, display a couple clear calls to action and supporting images and videos that I can customize when I need to?” it seems like it should be a simple question. But you could get 5 different answers, and none of them would be described as “a great experience for content editors”.

In the meantime, responsive design, content portability, and accessibility concerns are increasingly important. Now more than ever, we need to make sure that by adding flexibility, we’re not sacrificing semantic markup and data.

Enters Layout Builder

When I first tried out the Drupal Layout Builder a couple years ago, I got really excited. Finally, the drag-and-drop page builder we’ve all been waiting for that will make creation of flexible pages without code possible. Since that first release, the Layout Builder has become a stable solution that we can start to use on real-world projects.

Last year, my colleague Annika and I ran a comparative usability study, to see how Layout Builder could be used by content editors for creating flexible landing pages. There are definitely some usability issues when you use Layout Builder for this use-case out-of-the-box. But a suite of helper modules has emerged that make it easier to use for content editors.

Paragraphs Everywhere

In the meantime, over the last 4-5 years, a module called Paragraphs has garnered wide-spread adoption in the Drupal community. It was originally designed to create collections of fields within a larger piece of content. Although it wasn't designed to manage layout specifically, it is often used to build flexible, landing-page style content where the content author can mix-and-match content components (Paragraphs) to assemble a page. Fields can be added that act as settings for the style of each Paragraph, to add more flexibility.

So, Paragraphs or Layout Builder?

So which is the best approach to creating this flexible content. As usual, it depends. And the answer might be both.

(Note that the Layout Builder can also be used to create a layout for more predictable content types as well. I’m not going to cover that use case here, and will focus on the flexible page use case only.)

Paragraphs

Paragraphs is great for building structured content that is consistently formatted. With Paragraphs, you get to create Paragraph Types, each of which has its own set of fields, that live within the parent content. The content editor can pick from a list of options (which the site builder can control), deciding which content components to add to the page. With Paragraphs, the content editor is building a form, and then filling the content into that form. For example, they can add a call to action and then a video, and then a side-by-side text. And then they can fill in the content for all those elements. Later, they could reorder them.

Paragraphs provides a lot of control and more streamlined options for content editors. It requires fewer clicks to add a new piece of content. It’s great for situations where you want to keep things simple. Many situations don’t actually require variations in layout, but just to need to allow for a flexible content model.

With Paragraphs, you can combine components to create a flexible page.

Caveats: With Paragraphs, it’s important to customize the Form display, so that paragraphs are collapsed or displayed as a preview, instead of always displaying the mega-form that can result from constructing a page this way. Nesting a lot of paragraphs within each other can slow down the editing experience. Also, Paragraphs is a contributed module, although a very popular one. It's not part of Drupal core.

Downsides: Paragraphs was not designed to manage your layout. Building nested paragraphs with field labels like “Two-Column Layout” with sub-fields like “First Column” and “Second Column” creates confusion for content editors. You don’t get the ease of dragging and dropping elements from one part of the layout to the other. And behind the scenes, your content model will get messy very quickly if you use a lot of nesting.

Layout Builder

The Layout Builder is ideal for giving your content editors a visual way to manage how content and layout fit together. You do this by configuring Block Types (similar to how you would configure Paragraph Types) and then giving editors access to edit the layout of a page. They can add Sections, each of which has a layout, and then place blocks into those regions.

Layout Builder provides an open palette of options to the content editor or marketer who will be managing the page, although you can restrict some of the options using the modules below. The biggest difference with the Layout Builder is the ability to add “Sections” for each page, which display a set of serve as containers for the content that makes up the page. The fact that each Section can have its own layout brings a whole other dimension of flexibility that Paragraphs lacks. This is the key to your decision of which approach to take. Is that extra flexibility desirable or not?

The layout is visually represented in the back-end of the site, so you can see what your layout will look like as you edit, a feature that delights content editors once they've figured out how it works.

Layout Builder provides much more flexibility in how content components are displayed on the page. You start by assembling Sections, each of which has a set of regions, in which you can place your content.

Caveats: the layout builder requires customization to be usable by content editors. I recommend that you:

Downsides: There will be a learning curve for content editors used to the approach of filling in a form. They’ll need to change their workflow, and it will take time for them to learn. More clicks are required to get your content onto the page. Regardless of how much you trust the editors’ judgement, you’re giving up more control to content editors when you use the Layout Builder.

Another thing to note is that there are currently no migration tools for getting your content into a layout (although there's an issue for adding a Destination Plugin that would make this easier).

Other Ways to Build Flexible Pages What about Gutenberg?

Gutenberg for Drupal doesn't store your content as structured content, it gets stored as markup. You can use the Gutenberg interface to create things that appear like content components, but the data essentially gets stored in a large body field.

What about Cohesion?

Over the past few years, the folks at Cohesion (now part of Acquia) have been busy creating their own flexible page-building framework in which you use Components to assemble pages. Cohesion goes beyond the functionality of Layout Builder and Paragraphs, providing tools for changing the look and feel (using CSS and JavasSript) of Components and Templates through the admin UI. It also has features like “Helpers” providing default sets of content components that can be dropped into a page, and the ability to share a library of Components between sites.

Cohesion is optimized for marketing teams that need additional flexibility and control across pages and sites, and need to be able to create new types of Components without a developer stepping in. And by offering the ability to change the look-and-feel without touching a single Drupal file, its ambitions go beyond solving the problems of content editors. Its goal is the ultimate no-code solution for not just one, but many websites. Note that Cohesion is a paid service that Acquia offers as part of its Digital Experience suite.

What about Metadata? What about Accessibility?

I’m so glad you asked! One problem with really flexible content is that it’s inherently less consistent than predictable content types And that means you can easily lose the semantic markup you need for your page to show up correctly in search results and social media, and makes your content easily available to screen readers. Whatever approach you take, it’s important to add meta data to your content along with all the flexible content components, and to make sure that value of this meta data is clear to content editors. You're using Drupal because it's great at managing structured content and outputing semantic markup. Don't get in the way of that!

Takeaways

Remember that you’re configuring a system, not building a page. Whatever solution you pick should be the way you’re planning to manage a whole set of content and pages. When you're staring at the diagrams above, look at your whole range of design patterns, or wireframes and mockups, and think about which model would work best.

We’re currently working with the University of Waterloo on their migration to Drupal 8, and they took the step of prototyping both options and running it by their content editors to get their feedback before making a decision. This is a great way to test out the pros and cons of each option and to get buy-in from them in advance.

Keep in mind that it’s possible to combine both approaches. You can use Paragraphs for structured content elements, and use Layout Builder to put the pieces together in a Layout. Just try not to over-engineer your solution. Think again about the experience you're building for content editors.

Whichever option you pick to build your flexible pages, try and make a decision at the outset of the project, as you’re designing your content components and creating your Pattern Library or UI Kit. It will have an impact on how components are combined on the page, and the layout options you provide.

 

+ more awesome articles by Evolving Web

PreviousNext: Fast and fuzzy client-side search with Lunr.js and Drupal

Main Drupal Feed - Mon, 04/20/2020 - 00:51

For a recent project a client asked us to investigate an "instant search" feature, where as the user begins to type, suggestions for matching pages appear immediately. The following post introduces the Search API Lunr module and how it solved this problem for us.

by Sam Becker / 20 April 2020

Lunr.js is an implementation of a search index written entirely in JavaScript. Using the library, you can generate an index of content and then query the index with search terms. The library supports a powerful ranking system, per-field boosting, partial and fuzzy matches as well as a plugin system for processing keywords during indexing and querying. This library turned out to be a good choice for the instant search feature, as well as the primary search interface for the site. The quality of search results returned from Lunr seems to stack up well against other solutions like Solr, when configured in similar fashion.

Lunr.js search results with misspellings and partial matches.

In order to integrate Lunr with Drupal, the existing Lunr search module was evaluated, however the architecture was based around pre-building a Lunr index and distributing that index to clients. While this has the advantage of speeding up searches and is more performant for users of static sites, it requires a long build process to take place when content is updated, either by the site editors in a browser or via Node.js running on the server. Additionally, as search results are matched by the index, the associated document is downloaded separately during rendering, which wasn't going to cut it for an instant search that is expected to provide immediate feedback.

Given the target site for this feature was an integrated Drupal back-end, the design goals were:

  1. Unaffected content authoring workflow for content editors, with no latency between content changing and results appearing in search.
  2. No additional Node.js dependency on the server.
  3. No additional dependency on a build process (ie, unattended content changes such as scheduled updates would continue to work).
  4. Indexing across multiple entity types and bundles.

To address these points, an alternative implementation based on a custom Search API back-end was created in the Search API Lunr module. The module manages to overcome some of the difficulty in creating a pre-built index by pushing the collection of documents to users, then allowing the browser of each user to build their own index. After indexing, the results are cached locally until such time as it needs to be rebuilt.

The standard Search API interface building a series of JSON documents to be downloaded and indexed by clients.

To build the collection of documents that are sent to the client, Search API can be used by developers in the same way as other back-ends are configured. Tasks such as the following can be performed as expected:

  • Configuring which entity types and bundles appear in the index.
  • Configuring which fields are indexed and the process pipeline applied to each.
  • Administrative tasks such as flushing and rebuilding the index.

While requiring clients to generate a relatively expensive search index carries with it some practical limits, I've found it to perform with up to around 2000 or so large content pages generated with devel_generate. Putting it into action, the results of the instant search are relatively snappy and provide high quality results, even when given misspellings and partial words.

The JavaScript API shipped with the module is designed to give developers easy access to query and access documents from the index (which both the search page and block each consume for their functionality). To run a query against the Lunr index on any page or to gain direct access to the underlying hydrated Lunr.js object, developers only need the ID of the Search API server and index that was configured in Drupal. Here is a minimal example of the API in action, fetching a list of blog posts matching "foo", then firing an alert and redirecting to the first result:

(function(api) {   const blogIndex = api.getServer('lunr').getIndex('blog_content');   blogIndex.search('foo').then((results) => {   const firstResult = results.shift();   alert(`Found a blog post! ${firstResult.getLabel()}`); window.location = firstResult.getUrl();   }); })(window.searchApiJs);

It's worth noting that any number of indexes can be configured and that downloading and indexing the documents only occurs when a query is actually executed. In the out of the box use case, no cost is incurred for any sessions that don't actually make use of search. For optimisation purposes, a light index (perhaps including only the titles of documents) could be built for the autocomplete feature, with a larger index only used once a search form is actually submitted.

The module is still in an early alpha state however feedback is always welcome. For sites with a small to medium number of pages, perhaps the module could be a useful tool for providing high quality search results, without the overhead of provisioning and maintaining additional infrastructure like Solr.

Tagged Search API, Lunr

PreviousNext: Fast and fuzzy client-side search with Lunr.js and Drupal

Main Drupal Feed - Mon, 04/20/2020 - 00:51

For a recent project a client asked us to investigate an "instant search" feature, where as the user begins to type, suggestions for matching pages appear immediately. The following post introduces the Search API Lunr module and how it solved this problem for us.

by Sam Becker / 20 April 2020

Lunr.js is an implementation of a search index written entirely in JavaScript. Using the library, you can generate an index of content and then query the index with search terms. The library supports a powerful ranking system, per-field boosting, partial and fuzzy matches as well as a plugin system for processing keywords during indexing and querying. This library turned out to be a good choice for the instant search feature, as well as the primary search interface for the site. The quality of search results returned from Lunr seems to stack up well against other solutions like Solr, when configured in similar fashion.

Lunr.js search results with misspellings and partial matches.

In order to integrate Lunr with Drupal, the existing Lunr search module was evaluated, however the architecture was based around pre-building a Lunr index and distributing that index to clients. While this has the advantage of speeding up searches and is more performant for users of static sites, it requires a long build process to take place when content is updated, either by the site editors in a browser or via Node.js running on the server. Additionally, as search results are matched by the index, the associated document is downloaded separately during rendering, which wasn't going to cut it for an instant search that is expected to provide immediate feedback.

Given the target site for this feature was an integrated Drupal back-end, the design goals were:

  1. Unaffected content authoring workflow for content editors, with no latency between content changing and results appearing in search.
  2. No additional Node.js dependency on the server.
  3. No additional dependency on a build process (ie, unattended content changes such as scheduled updates would continue to work).
  4. Indexing across multiple entity types and bundles.

To address these points, an alternative implementation based on a custom Search API back-end was created in the Search API Lunr module. The module manages to overcome some of the difficulty in creating a pre-built index by pushing the collection of documents to users, then allowing the browser of each user to build their own index. After indexing, the results are cached locally until such time as it needs to be rebuilt.

The standard Search API interface building a series of JSON documents to be downloaded and indexed by clients.

To build the collection of documents that are sent to the client, Search API can be used by developers in the same way as other back-ends are configured. Tasks such as the following can be performed as expected:

  • Configuring which entity types and bundles appear in the index.
  • Configuring which fields are indexed and the process pipeline applied to each.
  • Administrative tasks such as flushing and rebuilding the index.

While requiring clients to generate a relatively expensive search index carries with it some practical limits, I've found it to perform with up to around 2000 or so large content pages generated with devel_generate. Putting it into action, the results of the instant search are relatively snappy and provide high quality results, even when given misspellings and partial words.

The JavaScript API shipped with the module is designed to give developers easy access to query and access documents from the index (which both the search page and block each consume for their functionality). To run a query against the Lunr index on any page or to gain direct access to the underlying hydrated Lunr.js object, developers only need the ID of the Search API server and index that was configured in Drupal. Here is a minimal example of the API in action, fetching a list of blog posts matching "foo", then firing an alert and redirecting to the first result:

(function(api) {   const blogIndex = api.getServer('lunr').getIndex('blog_content');   blogIndex.search('foo').then((results) => {   const firstResult = results.shift();   alert(`Found a blog post! ${firstResult.getLabel()}`); window.location = firstResult.getUrl();   }); })(window.searchApiJs);

It's worth noting that any number of indexes can be configured and that downloading and indexing the documents only occurs when a query is actually executed. In the out of the box use case, no cost is incurred for any sessions that don't actually make use of search. For optimisation purposes, a light index (perhaps including only the titles of documents) could be built for the autocomplete feature, with a larger index only used once a search form is actually submitted.

The module is still in an early alpha state however feedback is always welcome. For sites with a small to medium number of pages, perhaps the module could be a useful tool for providing high quality search results, without the overhead of provisioning and maintaining additional infrastructure like Solr.

Tagged Search API, Lunr

PreviousNext: Fast and fuzzy client-side search with Lunr.js and Drupal

Main Drupal Feed - Mon, 04/20/2020 - 00:51

For a recent project a client asked us to investigate an "instant search" feature, where as the user begins to type, suggestions for matching pages appear immediately. The following post introduces the Search API Lunr module and how it solved this problem for us.

by Sam Becker / 20 April 2020

Lunr.js is an implementation of a search index written entirely in JavaScript. Using the library, you can generate an index of content and then query the index with search terms. The library supports a powerful ranking system, per-field boosting, partial and fuzzy matches as well as a plugin system for processing keywords during indexing and querying. This library turned out to be a good choice for the instant search feature, as well as the primary search interface for the site. The quality of search results returned from Lunr seems to stack up well against other solutions like Solr, when configured in similar fashion.

Lunr.js search results with misspellings and partial matches.

In order to integrate Lunr with Drupal, the existing Lunr search module was evaluated, however the architecture was based around pre-building a Lunr index and distributing that index to clients. While this has the advantage of speeding up searches and is more performant for users of static sites, it requires a long build process to take place when content is updated, either by the site editors in a browser or via Node.js running on the server. Additionally, as search results are matched by the index, the associated document is downloaded separately during rendering, which wasn't going to cut it for an instant search that is expected to provide immediate feedback.

Given the target site for this feature was an integrated Drupal back-end, the design goals were:

  1. Unaffected content authoring workflow for content editors, with no latency between content changing and results appearing in search.
  2. No additional Node.js dependency on the server.
  3. No additional dependency on a build process (ie, unattended content changes such as scheduled updates would continue to work).
  4. Indexing across multiple entity types and bundles.

To address these points, an alternative implementation based on a custom Search API back-end was created in the Search API Lunr module. The module manages to overcome some of the difficulty in creating a pre-built index by pushing the collection of documents to users, then allowing the browser of each user to build their own index. After indexing, the results are cached locally until such time as it needs to be rebuilt.

The standard Search API interface building a series of JSON documents to be downloaded and indexed by clients.

To build the collection of documents that are sent to the client, Search API can be used by developers in the same way as other back-ends are configured. Tasks such as the following can be performed as expected:

  • Configuring which entity types and bundles appear in the index.
  • Configuring which fields are indexed and the process pipeline applied to each.
  • Administrative tasks such as flushing and rebuilding the index.

While requiring clients to generate a relatively expensive search index carries with it some practical limits, I've found it to perform with up to around 2000 or so large content pages generated with devel_generate. Putting it into action, the results of the instant search are relatively snappy and provide high quality results, even when given misspellings and partial words.

The JavaScript API shipped with the module is designed to give developers easy access to query and access documents from the index (which both the search page and block each consume for their functionality). To run a query against the Lunr index on any page or to gain direct access to the underlying hydrated Lunr.js object, developers only need the ID of the Search API server and index that was configured in Drupal. Here is a minimal example of the API in action, fetching a list of blog posts matching "foo", then firing an alert and redirecting to the first result:

(function(api) {   const blogIndex = api.getServer('lunr').getIndex('blog_content');   blogIndex.search('foo').then((results) => {   const firstResult = results.shift();   alert(`Found a blog post! ${firstResult.getLabel()}`); window.location = firstResult.getUrl();   }); })(window.searchApiJs);

It's worth noting that any number of indexes can be configured and that downloading and indexing the documents only occurs when a query is actually executed. In the out of the box use case, no cost is incurred for any sessions that don't actually make use of search. For optimisation purposes, a light index (perhaps including only the titles of documents) could be built for the autocomplete feature, with a larger index only used once a search form is actually submitted.

The module is still in an early alpha state however feedback is always welcome. For sites with a small to medium number of pages, perhaps the module could be a useful tool for providing high quality search results, without the overhead of provisioning and maintaining additional infrastructure like Solr.

Tagged Search API, Lunr

Web CRM Theme

Drupal Themes - Sun, 04/19/2020 - 20:28

Description is coming soon.

DrupalEasy: DrupalEasy Podcast 229 - Yuriy Gerasimov (Diffy), Ryan Price (Drupal news)

Main Drupal Feed - Sun, 04/19/2020 - 14:11

Direct .mp3 file download.

Mike speaks with Yuriy Gerasimov, one of the principles of Diffy, a cloud visual regression testing platform as well as Ryan Price to discuss all sorts of things including #DrupalCares, Drupal 9 launch parties, and an interesting Composer/Git workflow model. In addition, Chris Weber also has some new change records for us.

URLs mentioned Yuriy Gerasimov interview #DrupalCares Drupal 9 launch parties Composer 2.x The Change Notice DrupalEasy News Sponsors Subscribe

Subscribe to our podcast on iTunes, Google Play or Miro. Listen to our podcast on Stitcher.

If you'd like to leave us a voicemail, call 321-396-2340. Please keep in mind that we might play your voicemail during one of our future podcasts. Feel free to call in with suggestions, rants, questions, or corrections. If you'd rather just send us an email, please use our contact page.

qed42.com: DIA Contribution Weekend, April 2020

Main Drupal Feed - Sat, 04/18/2020 - 11:12
DIA Contribution Weekend, April 2020 Body

What divides us pales in comparison to what unites us.

– Ted Kennedy

That especially rings true in the time we're living in now.

Because of a much needed country-wide lockdown here in India to prevent the spread of COVID-19 disease, everyone has been locked-out in their homes and have socially distanced themselves form their communities. This, of course, includes the Drupal India community as well. And what better way to bring this community together than an online pan-India contribution weekend organized by Drupal India Association.

First-ever fully-remote pan-India contribution event

Today, on 18th April 2020, Drupal India Association (DIA) conducted it's first online 'Contribution Weekend'. It's the first event of its kind in that it was completely remote and saw participation from Drupalers across India.

We had 116 RSVPs, 22 Mentors, 96 Issues on Contribkanban board.

Thank you, organizers!

Before I talk more about the event, I would like to give a huge shout-out to everyone who was involved in the planning of this amazing event and a special shout-out to Rakhi Mandhania, Surabhi Gokte & Sharmila Kumaran (#WomenInDrupal FTW) for managing this so well. The planning team worked super hard to make this a success. They took time out of their personal and professional lives to have various meetings for issue triaging, communication and marketing for the event, arranging for speakers and much more. Thank you, everyone, who contributed to planning this.

Introductory hour for new/first-time contributors

We started the event at 8:45 in the morning,(Yes, That's 8:45 in the morning!) with a special session for new and first-time contributors. A big shout-out to all the newcomers and especially the mentors who took time out this early in the morning to volunteer for mentoring them. And boy did we have a lot of mentors! We had a mentor-to-mentee ratio of 5:1! Don't you feel special now mentees!

Main event

The main event started at 10:00 pm with more than 40 people joining in. And more people kept pouring in as the event went by. At a time we had around 70 people in the call!

Drupal India Association

Rakhi, our host, got us started and handed over the call to Mukesh Agarwal. Mukesh is CEO of Innoraft, one of the member organizations of DIA, and introduced us to DIA, its goals and purposes and the role it is going to play in representing the Indian Drupal community to the world. Major goals of DIA can be summarised as:

  1. Becoming an exemplary community leadership organization to the rest of the Drupal world
  2. Developing thought leaders in Drupal who will enhance India’s image in the Drupal world
  3. Becoming a major influencer and enabler in the adoption of Drupal in the Gulf & ASEAN region
  4. Making India an innovation hub for Drupal
  5. Making Impactful Contribution to community & the extended stakeholders of Drupal
DA needs our help!

Mukesh's introduction was followed by Tanisha Kalia, a representative from the Drupal Association, and she talked about DA and the financial effects of COVID-19 on DA and the larger Drupal community. DA is a very important entity for the whole Drupal community. Among the numerous things they do for the community, a few are:

  • Managing, hosting and conducting DrupalCons
  • Managing the infrastructure of drupal.org

Tanisha mentioned that the majority of DA's funding comes from the revenues of DrupalCon events and the almost inevitable possibility of cancellation/postponement of DrupalCon NA has put DA in a big financial hole. DA needs the community's support. 
Tanisha encouraged community members to either donate to DA directly via #DrupalCares initiative or support DA by purchasing/subscribing to be a member of DA, the cost of which starts from just 15 USD.

As of this moment, DA has reached 25% of its USD 500,000 goal:

As an individual member or an organization, you can help DA sustain the COVID-19 Impact and help reach its goal. Read more here: https://bit.ly/2VyKbmM

Tanisha also talked about the initiative taken by prominent members in the community to encourage donations and financial contributions. Some of these are:

  • From now until April 30, Vanessa and Dries are offering a dollar-for-dollar match for new, individual contributions to the Drupal Association - up to a total match of $100K! More details: https://bit.ly/2KefaPJ
  • Gábor Hojtsy, Acquia, will be donating 9EUR for every module ported to Drupal 9 for a total of up to 900EUR. More details: https://bit.ly/2wS5uaE
  • Jeff Geerling, @geerlingguy, will be donating 2$ for every like on his recent Youtube video for a total of up to 1000USD. Video link: https://youtu.be/fdk7zUwDQdM

A big thanks to all of you! 

Thanks to an amazing community, we had 6 new individual memberships registered before the introduction call finished.

Code-of-Conduct and Tips for the day

Next up Rakhi communicated the Code-of-Conduct to all the contributors and shared the various channels for communication that people could use throughout the day.
We were using channels on DIA slack. There were various channels set up for clear and effective communication:

  1. #new-contributors: For first-timers and newcomers.
  2. #regular-contributors: For experienced contributors.
  3. #issue-reviews-contribution day: For issues ready for review.

This setup was really efficient and was instrumental in keeping people engaged and active throughout the day.

Hussain kicking off the day 

Rakhi then handed over to Hussain Abbas from Axelerant who joined us as guest speaker for the sprint. He started by talking about the power of open source and how open source has in past sustained and in fact grown in face of financial crises. Truly, Open Source is here to stay!
Hussain then proceeded with talking about the path for Drupal core and contributes projects to Drupal 9 and how we can make sure that projects we frequently use and maintain can be made ready for Drupal 9. The Drupal community has created various tools to help us with these:

  1. drupal-check: A PHP CLI tool to get a report of any deprecated code used. This can be integrated into build processes and continuous integration systems.
  2. drupal-rector: A tool for automated deprecation fixes for some common cases.
  3. Upgrade status module: A wrapper module around drupal-check internals that generates a full site report of contributed and custom modules used in the site. This report can be used to assess the overall Drupal 9 compatibility of the modules.
  4. Upgrade rector: A user interface on top of drupal-rector, which also integrated with Upgrade Status.

Read more about these tools in the official Drupal documentation: https://bit.ly/3apZhAA

After Hussain finished his session and just before we were about to wrap up the call, we realized that Rachel Lawson, Community Liason - Drupal Association, has joined us in the call. The presence of the Community Liason from DA also inspired & motivated us to give our best to this contribution weekend.

Let's code:

After all the sessions, it was time for the code contribution now. From the start, one could tell that it was going to be a productive day. Just under an hour we made significant progress and moved a lot of issues to RTBC or Fixed.

Start of the day:

An hour into contribution:

 

Come for the code, Stay for the community!

Highlights of the day were the appreciation that the mentors received from the newcomers and first-time contributors for their help and support. We had a first-time contributor who had been contributing back to Wordpress community in the past as well trying their hands-on Drupal contribution for the first time. They really loved the experience and appreciated the welcome and support they received from the community. In their own words: "You all (Drupal community) are awesome and doing great work!"

 

 

With our spirits high we continued the rest of the day with the contribution. And to have the feeling of togetherness in this endeavor, we had the zoom bridge open throughout the day so that people could freely reach out to each other. We even had regular check-ins every couple of hours so that everyone feels connected.

We ended the even at 3:30 pm with a call where everyone shared their experience and appreciation for the community. It turned out to be a very fruitful day of contribution. By the end of it, we were able to move around 50 issues from needs work/active to RTBC/Fixed.

Thanks to all amazing mentors for their support to make this happen @azeets@JayKandari@piyuesh23@yogeshmpawar@AshishVDalvi@subson@ankushgautam76@meenakshig489@sonvir249
@abhisekmajumdar@forhemant@dipakmdhrm@malavya88@nitesh624@durgesh29@joshua1234511@iampratik_dk@vaibhavjain_in
@heykarthikwithu

In the end this would never have been possible without all you contributors who supported the event with writing patches, reviewing/testing them,  showing up to the event motivating all organizers. We hope for your continued participation over the coming Sprints.

My experience

Overall, it was a very productive day! I really enjoyed this new experience of contributing from the comfort of my home and it was also a much-welcomed distraction from the grim time we all have been having because of the current pandemic. I appreciate the opportunity to work with everyone from the community and would love to do it again soon.

Oh yes! That reminds me of something! Guess what? We already have another contribution weekend planned for next month! It's planned for May 16th and I would love to see and work with the community again. Read more about the event here: https://groups.drupal.org/node/535887.

See you all again on 16th next month.

Until then, stay safe!

dipak.yadav Sat, 04/18/2020 - 16:42

Pages