Specbee: Drupal Paragraphs Module in Drupal 9 - A Complete Tutorial

Paragraphs is a new way of content creation. It allows the site builders to make things cleaner and can give more editing power to the end-users.“Drupal Paragraphs” is a very popular module in Drupal, used for handling content. It is similar to content fields and provides a wide range of options for designs, layout, and grouping of content as per the requirements. Types of Drupal Paragraphs & Its Usage? Drupal Paragraphs can be of different types. They can be anything from an image to a video, or a simple text to a configurable slideshow. Instead of putting all the data in one body field, we can create multiple Paragraphs Types with different structures. This allows the end user to choose between pre-defined Paragraphs Types. By using Drupal Paragraphs, we can create multiple featured Paragraphs, allowing the end users to pick the one most suitable for their needs. The Drupal Paragraphs module is easily manageable for non-technical users, while also offering Drupal developers the ability to control the appearance of the elements at the theme level. How to use the Paragraphs module in Drupal 9 1. Install and Enable Drupal Paragraphs module You can find the information about the module and the current version of the module in the paragraph Drupal page.Run this command to install the paragraph module via composer:composer require drupal/paragraphs After installing the module. Got to extend and enable the paragraph module. The Paragraph module has a dependency on the Entity reference revisions module. We have to enable the Entity reference revisions module along with the paragraph module. We have submodules under paragraphs that can be enabled as per the requirement. Paragraphs demo, Paragraphs library, Paragraphs report, and Paragraphs type permissions. The description will give you a brief of the use case of the module. 2. Create a Paragraphs Type To add a paragraph type go to Structure > Paragraph types (/admin/structure/paragraphs_type) and click on Add paragraph types. Fill in the fields required to create a paragraph type. Here Label field is a required field, and icons, and descriptions are optional fields. We can change the machine name of the paragraph type by clicking on the edit button. After filling in the fields click on Save and manage fields. 3. Add fields to the paragraph type Adding fields in a paragraph type is the same as adding fields in a content type.Clicking on Save and manage fields will take you to the manage fields tab. In manage fields click on Add field. Here we can create a new field or reuse the existing field. Select the type of the field, add a label, and change the field settings as per requirement. This is the same as how we add the fields in the content type. We can add any number of fields as per requirement. After adding the field we can see the list of fields added in the manage display form. We can change the order and the configurations of the field in the form display in the manage form display tab. To change the order of the field click and drag the fields and to change the configuration click on the settings icon on the right end of the respective field. On displaying the paragraph, we have the option to change the order and the format of the field value in the manage display tab. To change the order of the field click and drag the fields, to change the format click on the dropdown under the format and change the format as required for the respective field. We can align the label of the field and also make it hidden from the display. We have these options under Label. We can translate the paragraph type if the site is multilingual in the Translate paragraphs type tab and clone the paragraph type from the clone tab where we have to give a new label for the cloned paragraph. 4. Add paragraphs to the content type To add paragraphs to a content type we have to create a field of type entity reference revision which helps to refer paragraph types in the content type. To add the field go to Structure > Content types. Click on the manage fields of the content type to which paragraph type should be added. Click on Add fields. Select the paragraph under Reference Revisions and add a name for the field.   Click on Save and continue. Here we have the option to set the limit for the field. If we want to add only one set of values for the paragraph change the Allowed number of values to limited and select the number that appears after selecting the limited option. After selecting the limit click on save field settings. Clicking on save field settings will take us to a page where we can select the paragraph type that needs to be added to the content type selected. All the paragraph types created will be listed under Paragraph types. Here we have 2 options, select the paragraph types and select the option exclude the selected below, this will enable the paragraph types which are not selected. The other one is to Include the selected below which will enable the paragraph types which are selected in the list. After selecting the paragraph types click on save settings in the end. There are different field widgets available for the entity reference revisions field which can be selected in the manage form display of the content type to which the field is added. 5. Add content to the paragraphs To add the content go to Content > Add content. Select the content type to which the paragraph is added. We will see the paragraph type added with all the fields added to the paragraph. To add multiple paragraphs click on add button with the paragraph name (Add Blog in the above screenshot) which will add a new paragraph of the same type. To remove the paragraph, click on the 3 dot option button next to the collapse and click on remove. And to duplicate the paragraph click on the duplicate. Save the node after adding content to the paragraph. Features of Drupal 9 Paragraphs module Allows the editor to create different structures on each page.If there are different structures on the same page or different pages, Drupal paragraphs can be used. For ex. There is an image with text on the top and slideshow on the bottom. We can use Drupal Paragraphs to make this less complicated. Allows the editor to change the order of the paragraphs.If there is a change in display, like there is an image on the top followed by title and description, and you want to change it to title to the top followed by image and description. Such changes can be done using Drupal paragraphs easily. Go to “manage display” of the paragraphs used and change the order, which will change the display order of all the content wherever the paragraph is used. Paragraphs can be nestedOne Drupal paragraph field can be referred to in another paragraph field. While selecting field to paragraphs, select “Paragraph” under “Reference revisions” and select which drupal paragraphs type you want to add. Final Thoughts The Drupal paragraph module is a very popular module which is used in most of the websites created using Drupal. By using paragraphs, end users are asked only to add content as per their requirement and the developers can write the stylings using CSS for displaying the content. The styling and settings are done before adding the content. This makes the content creation easier for both the technical and non-technical users, allowing the content to appear in a consistent manner.  If you are looking to develop a custom module for Drupal or any other Drupal development services, contact us.

qtatech.com blog: Mastering Multisite Development with Drupal 10

Mastering Multisite Development with Drupal 10 kanapatrick Mon, 07/31/2023 - 09:21

If you find yourself seeking to establish and oversee multiple websites with Drupal 10, your search ends here! Our all-encompassing guide is meticulously crafted to lead you through the intricate process of harnessing Drupal 10's true capabilities in crafting and efficiently managing multisite environments.

Image removed.

Ryan Szrama: Innovating within Drupal’s Core Competency

The dominant theme of DrupalCon Pittsburgh was innovation. It featured heavily in our Drupal Association Board retreat as we considered how the non-profit might better support and contribute to continuous innovation in Drupal. Project lead Dries Buytaert discussed the topic at length in his keynote presentation, which ended with the audience selection of proposals that would receive “Pitch-Burgh” innovation grants. It echoed in myriad discussions that generated buzz around initiatives like Single Directory Components that makes theming Drupal easier.

Read more

Peoples Blog: API Docs, Drupal contributed module for your Developer Portal

This module will provide API Docs to your Developer Portal, It is powered by Drupal content type, custom field formatters & views. Here's a step-by-step guide to help you to download, enable, configure and use the module for your developer portal. Download & Enable the Module: Visit the Drupal.org website and navigate to the API Docs module's page that you want to download, her

DrupalEasy: Using the ECA module to replace a not-Drupal-10-ready contrib module (Termcase)

I've been a big fan of the Termcase module for a long time - it is my go-to module for sites that employ free-tagging taxonomies. Termcase allows site-builders to force consistency on tag names (all lowercase, all uppercase, first-letter uppercase, etc…) It's one of those modules that I was surprised that not everyone used (or had even heard of.) While working to update a Drupal 9 site that uses Termcase to Drupal 10, I became curious if free-tagging was still a commonly-used technique on modern Drupal sites.

In an effort to satisfy my curiosity, I performed a 100% not scientific poll recently on various social media platforms to see how prevalent the use of free-tagging vocabularies are; the results weren't very enlightening; of the 60 responses I received, the vote was about split.

Poll: do you have any free-tagging term reference fields on a modern Drupal (8/9/10) site you own/manage/built?

Image removed.

This didn't really satisfy my curiosity about why not everyone is/was using the Termcase module. Surely, I'm not the only person who is adamant about their free-tagging terms all having the same capitalization scheme… 🤨

Motivation

Officially, there's no Drupal 8 or 9 version of Termcase, but it has been limping along with a two patches that allowed me (and a few others) to keep using it in Drupal 8 and 9. While there is a Drupal 10 compatibility patch available, it seems pretty clear that the listed maintainers have no interest/bandwidth in updating the module, so I figured it was time to consider an alternative that would provide a solid solution in Drupal 9, 10, and beyond. 🚀

Again, I went to social media for answers (ChatGPT wasn't much help) and one of the maintainers of the ECA module, Jürgen Haas, quickly responded that ECA could help (I'm pretty sure that is Jürgen's default answer to most Drupal questions these days 😀). He pointed me toward the Convert case action of the ECA Tamper module. Excellent, now all I needed to do is learn how to use the ECA module 👍🏼

ECA module 101

The ECA module is the modern-day successor to the formerly widely-used Rules module that was a popular solution for pre-Drupal 8 sites.

Disclaimer: I did have a little bit of prior experience in experimenting with ECA, but this would be my first real implementation for a client using the module.

I'm not going to go into all the details of the basics of installing and using ECA, as the existing documentation is quite robust, if not yet completely geared toward beginners (more on that later.)

To get started, I used Composer and Drush to install ECA and the necessary modules:

$ composer require drupal/eca drupal/eca_tamper drupal/bpmn_io $ drush en bpmn_io eca_tamper eca_content

This results in the following modules being enabled: bpmn_io, eca_modeller_bpmn, eca_ui, eca_tamper, eca, and tamper.

Next, I had to create a new ECA model (for those of you familiar with the Rules module, an ECA model is similar to a rule).

One counter-intuitive aspect about the ECA module is its name and the nouns it uses in its interface. ECA is an acronym for the nouns Events, Conditions, and Actions. But, when using the BPMN.iO (Business Process Model and Notation standard) interface module, the nouns used are StartEvent, Sequence flow, Gateway, and Task. For folks new to this type of module, this can be confusing. I am confident that this is due to the design of the BPMN.iO interface, and not a purposeful decision by the ECA maintainers just to confuse us. StartEvent and Task map pretty cleanly to Event and Action. A Sequence flow is a connector between StartEvents, Gateways, and Actions. A Sequence flow can optionally have a condition. A Gateway can be added after a Sequence flow to allow for one or more Sequence flows with conditions to be evaluted. 

  • Event = StartEvent
  • Condition = Optionally attached to a SequenceFlow
  • Action = Task

For example, consider the model where a "Batman message" is displayed if an article node has a "Batman" term associated with it. 

Image removed.

In this model, the Gateway just provides a point where the two potential Sequence flows ("Batman?" and "No Batman") can be evaluated. The Gateway doesn't usually have any non-trivial properties - it is usually a branch point.

Replacing Termcase with an ECA model

For this model, in non-ECA speak, the goal is to lower-case all terms of the Tag vocabulary prior to each being saved. Therefore, our Event/StartEvent will be Presave content entity. Then we will need to perform the Convert Case action (from the ECA Tamper module) on the term name, and finally we will need to update the name value of the about-to-be-saved term to the updated (lowercased) term name. For good measure, when developing a new model (as well as a new rule back in the day) I generally also add a temporary Drupal message action (task) to confirm that things are working.

I'll get into the details of each of the aforementioned steps, but here's a quick preview of what the completed model looks like:

Image removed.

lowercase terms model details

Taking a not-quite comprehensive look at each aspect of the model:

Presave tag

After dragging a new StartEvent to the layout area, the first step is generally to select a Template. Now, this is not a theming template, but rather the event for which this model will be triggered on. In this case, the Presave content entity template was used (which is provided by the eca_content module.) Each StartEvent, Gateway and Task has both an ID and a Name - both customizable by the model author. I generally leave the ID at the default value, but populate the non-required Name field with something descriptive. In this case, I used Presave tag. Each template generally has a set of Custom properties. Not surprisingly, different templates generally have different Custom properties. In this case, it was pretty obvious that I needed to set the Type (and bundle) Custom property to Taxonomy term: Tags.

Image removed.

Lowercase

Next, I dragged a new Task to the layout area, named it Lowercase, and selected the Tamper: Convert case template. The list of available templates is quite impressive (IMHO), these are provided by the various installed ECA-related modules. Since the ECA Tamper module is installed, we have access to all of its templates.

Image removed.

Setting the Custom properties of the template (again, think of this like the configuration of the task/action) is a bit more tricky - especially for folks new to the ECA module. The ECA module utilizes Drupal's Token system extensively. In many cases, it also relies a bit on the model author's knowledge of Drupal data structures.

In this case, I used the following Custom properties (configuration):

  • Data: [term:name]
  • Token name: my-tag
  • How to convert case: Convert to lowercase

This is where I think the ECA module needs some DX (developer experience) tweaks. For the uninitiated, knowing that Data is the input and Token name is the output is not obvious, but that is exactly what is going on here. The Presave tag StartEvent provides the term to be saved as a Drupal token. Since we want to lowercase the term name, we need to set Data (incoming) to the [term:name] token.

The result of the Task (action) is then saved to a new custom token whose name we specify in the Token name field. The lowercased term name is not automatically saved back to the term name field which is why we need to save the result of this task as a new custom token. We will save the updated term name back to the Term entity in the next Task.  

Based on an online discussion with Jürgen regarding how this would probably be difficult for beginners to pick-up on quickly, he opened (and acted on) an issue

Set updated tag name

The final Task (action) is then to set the new (lowercased) value of the term name back to the about-to-be-saved term entity. This is done with the Entity: Set field value template. There are quite a few Custom properties for this template, but in this case, the only ones I set to non-default values were:

  • Field name: name
  • Field value: [my-tag]
  • Entity: taxonomy_term

This is where the DX of the ECA module could again be much improved (IMHO.) The Field name value requires a bit of knowledge that not all Drupal site-builders have - that is the machine name of the taxonomy term entity's Name/Label field. Granted, it is a pretty obvious value (name,) but it easily could also be label or title - it would be amazeballs if the user was presented with a select list of potential values instead of a text field in the UI, but I do appreciate the amount of effort that would entail.

The Field value field is a bit better, but again, not entirely intuitive. This is the input to the task - that is - the value to which the field will be set to. It is a bit tricky to know that in the Lowercase action only the token name is needed (my-tag), but in this task the full token (including square brackets) is required ([my-tag]).

The Entity field also requires knowledge that not all Drupal site-builders may have - the machine name of the entity type to which the field value is being set for. In this case, the proper value is taxonomy_term, but I'll admit I was a bit surprised that this isn't something that the Task can figure out on its own - or at least provide a select list for. Again, I suspect (and appreciate) that it has to do with how each Task is written completely independently (and without dependencies) on other aspects of the ECA model.

I've opened up a new issue in the ECA module's queue with these thoughts.

For me, one of the more significant challenges of using the ECA module is understanding what each Custom property is actually asking for and determining if it is input or output of the task. I think there is some room for improvement.

Something else that originally tripped me up in this task was the Save entity setting. It defaults to no, and I mistakenly thought to myself, "of course I want to save the entity" and set it to yes; which led to a fatal PHP error. Again, Jürgen was very responsive and set me straight by explaining that since the StartEvent is Presave content entity, there is no need to set Save entity to yes, the term is already on its way to being saved. By selecting yes, the model will effectively try to save the same term twice; leading to the fatal error. 

Temporary confirmation message

As mentioned previously, I often include a temporary task/action to output something that tells me that the model is actually running and achieving its goal. Once I am confident in the model, I often remove this task.

In this case, the Display a message to the user task template was used with the following Custom property:

  • Message: Tag updated: [my-tag]

Final "gotcha"

Maybe it is just me, but there's one thing that I keep doing in ECA's BPMN.iO's interface that can be very confusing at first - I often find myself not paying attention to what is selected in the layout area when looking at the "inspector" (I'm not really sure what else to call it) so that I get a bit confused with the configuration options. Somehow, I frequently have an arrow connector selected (a Sequence flow in BPMN.iO parlance) when I think I have a task selected (Sequence flows have properties as well!) So, my advice is to be methodical and pay attention to what is selected in the layout area when looking at configuration options.

Image removed.

I'm not sure there's anything that the ECA maintainers can do about this. I liken it to a similar habit I have of moving too quickly when configuring multi-display Views and overriding/not-overriding values incorrectly. My advice: Move slowly and methodically in the interface.

Summary

This was a good exercise and excuse for me to take a (slightly) deeper dive into the ECA module. Based on its documentation and videos about the module that I've seen, this article barely scratches the surface of what ECA can do. I look forward to finding more reasons to use it!

It is pretty clear that the maintainers are super-active and super-responsive to feedback and requests for support; take advantage of them. 😃

Oomph Insights: DrupalCon 2023: Recapping the Biggest Week in Web Dev

For digital ecosystem builders like us, DrupalCon is kind of like our Super Bowl: best-in-class web devs coming together to level up our Drupal prowess. Earlier this summer, we joined 1,800 other Drupal users in Pittsburgh, turning the David L. Lawrence Convention Center into a four-day meeting of the minds for anyone who builds with Drupal. Why DrupalCon? Well, we’re huge fans of the platform. We’ve been developing Drupal projects since 2008 and have served the Drupal community by sponsoring the annual New England Drupal Camp; hosting the monthly Providence Drupal Meetup; developing new…

Drupal.org blog: Ensuring a Fair Drupal Contribution Credit System

Drupal's contribution credit system plays an important role in fostering contribution. It is crucial that we protect the integrity of that system.

Because contribution credit can impact an organization's marketplace position, there is a financial incentive for contribution. This is by design, and helps promote sustainable contribution in Drupal. Unfortunately, whenever a financial incentive is created, there is a risk that some organizations will try to game the system by making superficial contributions in bulk, or using automation or AI to try and boost contribution numbers.

This gaming behavior undermines the true goal of the credit system, which is to grow meaningful and authentic contributions to the Drupal project and community.

What steps are we taking?

To help discourage the temptation of superficial contribution, we've implemented additional updates to our systems and policies:

  • The credit checkbox on issues is no longer 'pre-checked' for certain kinds of issue activity.
  • We have published a draft policy on the use of artificial intelligence on Drupal.org. AI is not banned, but must be used carefully:

    • Contributors must acknowledge that AI was used to assist the creation of the work in the same post or issue comment.
    • Any work that was created with the assistance of AI must be relevant to resolving the issue.
    • Work created with the assistance of AI must be edited and corrected as needed before being posted to any issue.
    • This policy is subject to significant revisions as the legal status of AI generated work and copyright evolves.
  • We have also updated our standards of conduct for the Drupal.org marketplace, including a warning and escalation policy for abuse of the credit system.
    • Consistent abuse despite repeated warnings can result in loss of marketplace position, partner status, or delisting.
  • Individual users engaging in this activity may receive temporary account suspensions, so that we can reach out with educational materials. Repeated infractions may result in a permanent account ban.

Why is this important?

Drupal remains unique in the open source world for the power of our contribution credit system. All kinds of contribution activity on Drupal.org can be attributed to individuals and organizations, giving us unprecedented insight into the ecosystem that drives contribution.

This system also plays an important role in promoting individuals, companies and organizations who give back to the project and community. We use an organization's contribution history to rank them in the Drupal.org marketplace, and an individual's contribution history is a powerful tool for organizations to find talent, and for Drupal contributors to find work.

Our credit system is designed so that only project maintainers can ultimately grant credit. This means that there is always an element of human review, but relying exclusively on human intervention to monitor large numbers of superficial contributions can lead to burn out.

Education first

Our first goal when we see contribution activity that isn't meaningful or authentic is always education. With the help of Drupal mentors, site moderators, and other community members, we focus on gentle intervention, education, and support wherever we can.

We've collected a series of resources to support this educational effort:

With these systems and policies in place, we can reduce the burden on maintainers and help ensure that the credit system serves its higher purpose: Growing meaningful contributions to Drupal, and providing recognition for those who give back to our project and community.

LN Webworks: Upgrading Your Drupal Site: 5 Key Challenges and How to Conquer Them?

Image removed.

Navigating the intricate process of Drupal migration poses a myriad of challenges for organizations. This complex endeavor demands meticulous planning and execution. However, unexpected issues can emerge, potentially leading to delays or complete migration disruptions.

In this blog, we will discuss the top five challenges in Drupal migration and provide practical solutions to overcome them. But before we discuss that, let’s understand in a snippet why migration is even needed. 

Why Drupal Migration Is Important? 

Drupal migration is the process of upgrading a website from an older version of Drupal to the latest version. It involves transferring data, content, functionalities, and design elements to the new version. Drupal migration is of paramount importance for organizations seeking to keep their digital presence relevant and robust. 

Drupal Association blog: Open Source Unity: Joint Concerns Over the Proposed Cyber Resilience Act in the EU

It should not come as a surprise that open source projects would act collaboratively.  But it’s somewhat of a first, in my understanding, that Open Source Matters, Inc. (Joomla), Typo3, WordPress, and the Drupal Association have issued a joint letter to the legislators of the European Union raising concerns with the proposed Cyber Resilience Act. And the concerns raised by our four organizations, whose communities collectively serve over 50% of the European websites, are significant enough to warrant such a first.

The impact of the regulation as proposed would undermine effective software practices in its ban on “unfinished software”, chill the contributions of tens of thousands of developers who make free contributions to open source software due to an expansive definition of “commercial activity”, and would impose one-size fits all compliance costs likely causing development to gravitate to large, for-profit firms that can absorb the costs.

Read the letter here

While the rule’s impact would be extremely negative, the opportunity we have before us is positive. This rule provides an opportunity for open source communities across Europe (and the globe!) to explain the unique role that FOSS plays in the software that underpins much of the web and to develop a model for how regulation should be applied to it. It is an opportunity for our communities to learn how to best work together in making this case, as the four signatories on this letter have begun to do. Finally, it’s an opportunity to educate legislators and policy-makers as to the shared values that open source communities have with the European Union.

The Drupal Association engaged in this issue because we recognized that the Cyber Resilience Act is the current issue at hand, but not the only one. The European Union’s parliament is considering proposed changes to the Product Liability Directive this Fall that could impose a strict liability standard. And beyond that lies A.I. and patent rules.

So we embrace this opportunity to collaborate with Joomla, Typo3, WordPress, and hopefully other open source initiatives to credential FOSS’ role in the E.U. regulatory landscape. As experts in the field, we embrace the responsibility to educate and provide support for our online ecosystem. We also look forward to engaging with and serving our Drupal community members in Europe.