Upgrade Your Drupal Skills

We trained 1,000+ Drupal Developers over the last decade.

See Advanced Courses NAH, I know Enough
Nov 30 2021
Nov 30

As of November 17, 2021, the Drupal core version 8 series has reached end-of-life. This means that all releases of Drupal 8 core (with 8.y.x version numbers) and Drupal contributed project releases that are compatible with only Drupal 8 will be marked unsupported as they no longer have security team support.

Drupal 8.0.0 was first released on November 9, 2015. The last version was released on November 17, 2021.

All Drupal 8 site owners must upgrade to Drupal 9 to receive security updates and bug fixes. The Drupal Association will also disable testing with unsupported versions of Drupal.

Security issues that only affect Drupal 8 (and not Drupal 9 or Drupal 7) will be made public and sites are at risk of having these issues exploited if they do not upgrade.

What about Drupal 7 and Drupal 9?

Contributed projects like themes and modules will still receive security advisories if they are compatible with either Drupal 7 or 9 and have opted in to security coverage.

Drupal 7's end-of-life is currently scheduled for November of 2022, and it will receive security updates until then. Drupal 9's end-of-life is scheduled for November of 2023. For more information on release schedules, see the core release cycle overview.

Nov 30 2021
Nov 30

Today organizations are seen focusing on creating very interactive and omnichannel user-experiences via their websites that consequently let them to depend on Drupal’s decoupled architecture. Such a facility of Drupal’s decoupled architecture offers the organizations the flexibility to innovate, provide countless options on what they want to create, and enables them the capacity to build multiple-websites and applications. Additionally, it also allows the developer to work with Drupal in three different modes such as fully decoupled Drupal approach, progressively decoupled Drupal (hybrid) approach and traditional Drupal. So, today we will discuss the fully decoupled Drupal approach and make you familiar with its features and functionalities. 

Understanding Fully Decoupled Drupal and its categories
 

Illustration diagram of Fully Decoupled Drupal and its categoriesSource: Dries Buytaert's blog


There are commonly three approaches to go about Drupal architecture such as traditional (or coupled), progressively decoupled, and fully decoupled. You can read more on this: How to decouple Drupal and the different options of doing it. In accordance with the need of various preferences and requirements, all the three approaches are important in their own ways. Let us now briefly look at the first two approaches and focus more on the third approach i.e., fully decoupled Drupal as it is the main topic that we are diving into today. 

When it comes to traditional Drupal, all of the Drupal’s general responsibilities remain intact, since Drupal can be considered as a monolithic system and moreover efficiently maintains full control over the presentation and data layers. Traditional Drupal proves to be a great choice for editors who require complete control over the visual elements on the page, with access to features like in-place editing and layout management.

At times JavaScript is needed to deliver a highly interactive end-user experience. In cases like this, a decoupled approach becomes a necessity. So, a JavaScript framework is layered on top of the existing Drupal front end in progressively decoupled Drupal. This JavaScript is responsible for rendering a single block or component on a page, or it might even render everything within the page body. This approach pattern lies on a spectrum i.e., while the less of the page is dedicated to JavaScript, the editors are even more able to control the page with the help of Drupal's administrative capabilities. 

Fully decoupled Drupal involves a full separation of concerns between the presentation layer and all other aspects of the CMS. Within this approach, the CMS happens to become a data provider, and a JavaScript application, or a static site generator, communicating with Drupal through web service APIs. Read more on CMS and static site generators’ use cases here. In spite of the unavailability of key functionality such as in-place editing and layout management, fully decoupled Drupal can be captivating for developers who look for greater control across the front end and who are already well experienced with building applications in frameworks such as Angular, React, Gatsby, etc. 

Learn more on decoupled Drupal here:

Fully decoupled Drupal can be executed in two different ways, namely Fully decoupled app and Fully decoupled static site. We will now closely take a look at the ways below. 

Fully decoupled app

Fully decoupled applications are written in JavaScript and use frameworks such as Angular, React, Vue.js during the decoupling process. 

Illustration diagram describing the frameworks used to make Fully decoupled applicationsSource: W3Techs

                             

React

Illustration diagram describing the usage of framework named React which is used in making Fully decoupled applicationsSource: W3Techs


React is a JavaScript library which was started in 2013 and is used to create interactive user interfaces (UIs). It can be considered as one of the most powerful and highly used front-end technologies, maintained and supported by the tech giant Facebook. The React has the ability to split the codes into components to further allow developers with code reusability and fast debugging. Due to its declarative style and lack of assumptions about technology stack, it has earned immense popularity. Within the last few years, a large ecosystem can be seen growing around React. It also includes high quality libraries, conferences, and growing demand for developers with React skills.

Some of the leading websites and web applications which use React as front-end technology include Facebook, BBC, Airbnb, Reddit and New York Times, etc. 

React and Drupal

When it comes to React and Drupal, no matter if you are improving some of the elements on a current page, or even creating a fully decoupled single-page app (SPA), React and Drupal tend to work together in a great way. Also as part of an existing Drupal theme, React is used to provide a better user experience. 

More on the combination of Drupal and react here.

Angular

Illustration diagram describing the usage of framework named Angular which is used in making Fully decoupled applicationsSource: W3Techs


AngularJS is a lightweight and concise framework which is extremely extensible and allows you to try some interesting things with your website. It extends HTML to define user interfaces, therefore allowing you to build interactive web applications which are highly functional and tough to break. Reusable components can also be created with AngularJS, and due to its client-side nature, all kinds of cyber-attacks can be well prevented. It implements the MVC (Model-View-Controller) framework allowing faster development process, multiple views, asynchronous technique, SEO friendly development and much more useful features. AngularJS has an exciting functionality like a two-way data binding that allows user actions to immediately trigger application objects and vice-versa, also providing an extremely interactive framework. 

This framework is well supported by a large community and maintained by the tech giant Google. Gmail, Paypal and The Guardian use Angular as the front end technology.

Angular and Drupal

  • The strong combination of Drupal with Angular will allow you to move display logic to the client-side and streamline your backend, hence resulting in a speedy website.
  • Due to simplicity and clarity in the code structure, HTML happens to always stay on demand, and Angular can be seen making use of HTML to define user interfaces, therefore enabling organizations to build interactive web applications which are highly functional. 

More on the combination of Drupal and Angular here.

Vue

Illustration diagram describing the usage of framework named Vue which is used in making Fully decoupled applicationsSource: W3Techs


Vue.js is a JavaScript framework which is quite popular for developing interactive applications. This framework provides data-reactive components with a simple and flexible API. Additionally, it can be used as a library to add interactive elements/blocks to the existing sites. You can deliver a significant boost to user experiences with the help of this exceptional framework. 

Vue and Drupal

  • The combination of Vue and Drupal enables developers to easily request and store Drupal content as data objects through the official Vue-Resource plugin.
  • While combining with Vue, Drupal is able to show its magic at the back-end while the captivating features of the Vue handles the client-side. Also, Vue’s component system is one of the strongest features that enables large-scale application building, including small and self-contained reusable components.

More on the combination of Drupal and Vue here.

Fully decoupled static site

Fully decoupled static sites help in enhancing performance, security, and reduce the complexity for developers. A static site generator such as Gatsby or Metalsmith helps in retrieving content from Drupal, generating a static website, and deploying that static site to a CDN, generally via a particular cloud provider like Netlify.

Gatsby

Illustration diagram describing the usage of a static site generator such as Gatsby Source: W3Techs


Gatsby is an open-source and modern website framework which improves the site's performance by leveraging the latest web technologies like React and GraphQL. It is used in building blazing-fast applications and websites. This framework uses powerful pre-configuration in order to build a site which only uses static files for incredibly fast page loads, service workers, code splitting, etc.

Gatsby and Drupal

  • Using Drupal with Gatsby can be a great way in building an enterprise-quality CMS for free, paired with great modern development experience. It provides all the benefits of the JAMstack, such as performance, scalability, and security.
  • Gatsby can also do fireworks by pre-generating all the pages of the site, unlike dynamic sites which render pages on-demand, thus decreasing the need for live database querying. Consequently, performance is improved and overheads happen to decrease leading to lesser maintenance cost.

More on the combination of Drupal and Gatsby here.

Metalsmith

Metalsmith is a simple, pluggable static site generator that supports a broad array of templates and data format options. It provides a simple plug-in architecture and very easily can get started. Also, it uses a modular structure and its lightweight nature and lesser dependencies tend to make it an excellent solution. 

Metalsmith and Drupal

  • The combination of both Metalsmith and Drupal can be very beneficial due to Drupal’s magnificent backend which can be utilized to feed data to all types of clients and Metalsmith’s extraordinary capabilities as a static site generator.
  • Along with Drupal’s great expertise in content governance, Metalsmith proves to be an excellent solution for building static sites.

More on the combination of Drupal and Metalsmith here.

Conclusion

I would like to conclude by saying that with fully decoupled Drupal, you can deliver fast and flexible content with no particular delivery environment. You can even have complete control upon how and where your content appears. Isn’t that great? Well, I am quite sure that this article helped you in familiarizing with the very significant fully decoupled Drupal approach. Hope, now you can take the right decision for your organization in terms of decoupling Drupal. 
 

Nov 30 2021
Nov 30

The content editor is basically the most crucial function of a CMS. And with a powerhouse like CKEditor as its default rich text editing tool, Drupal has upped its content management game considerably with several new features for Drupal 8/9 like the CKEditor widget system and the Advanced Content Filter (ACF). So, yeah, it’s pretty powerful even with the default features… But you can really up your CKEditor game with the help of some contributed modules and plug-ins. Read on to get our take on the best and most interesting add-ons to extend CKEditor's features and usability.

The Drupal 9 CKEditor

First, for those new to Drupal, CKEditor 4.5 is the default WYSIWYG (What you see is what you get) rich editor in Drupal 8/9. It’s a text editor which helps website admins write and edit content directly in web pages. Like Drupal, CKEditor is an open source project and has recently been upgraded with many powerful new features that will continue to be improved. As part of the Drupal 10 readiness initiative, Drupal contributors are working toward implementing the latest and most modern version - CKEditor 5 - in Drupal 10.

Now that we have the basics out of the way, let’s get into the upgrades!

Drupa 9 CKEditor

Extending CKEditor with these fantastic Drupal 9 modules

1. CKEditor Read More 

You know those times when you want to give the reader a choice to see the rest of a large amount of text? That's your cue to use the CKEditor Read More feature, which invites your users to “read on” while still giving your page a compact layout. To add it, Drupal 9 provides a simple and easy way to enable the Read More / Show Less functionality once you install the contributor module.

CK

Implementing the module:

Once you install this module, you will need to configure a few settings:

  1. Edit preferred Text format and enable “Limit allowed HTML tags”.
  2. Add

    in “Allowed HTML tags”. Disable the “Limit allowed HTML tags” and hit save.

  3. Now drag and drop the “Read more” icon from Available buttons to Active toolbar (as shown in the image above) and hit save.
  4. After clearing the cache you will find the “Read More” icon in the text editor when you choose the “Preferred Text format”.

How to use it:

Within the content area, click on the “Text format” icon. Now you will get a rectangular box. Add the rest of the content that you want to show after your user clicks on Read More.

    
FAQ : Can I modify the Read More text?

Absolutely! Simply click on the “Read more button” tab in “CKEditor plugin settings” and change the text.

2. CKEditor Color Button 

By default, CKEditor does not offer you a choice to change the text color from within the editor. But if you did want to change the color of specific text or even highlight the text with different colors, the Drupal 9 CKEditor Color Button module should be on your list. Note that this module requires the Panel button module to be installed as well and both of these modules require the libraries, Color Button Library and Panel Button library to be installed. After installing the modules and adding libraries in the libraries folder of the theme, we can move the colors button from Available buttons to Active toolbar in the preferred text format. 

FAQ: Can I add a custom color?

Yes! If you don't want to use any of the default colors already available, you can set a custom color too. You can do this in the “Text editors format” section where you activated the color options from. Find the “CKEditor Color button” in the “CKEditor plugins setting” section of “Text editors format” and add color in the “Text colors” text area comma separated and without a # sign.

3. CKEditor Youtube 

The Drupal 9 CKEditor Youtube module helps you add Youtube videos into your content without a long embed code. After installing and moving the Youtube icon form from Available buttons to Active toolbar, you can find Youtube icons in the text editor in preferred text format. This module depends on the library.

CKEditor youtube

One of the best things about this module is the flexibility. As shown in the above screenshot, you can “Paste embed code” or paste a Youtube URL while specifying the width and height. Also you have handy options like “Autoplay”, “Start at (specific time)” and “Show player controls”.

4. CKEditor Templates & CKEditor Templates User Interface

Have a lot of the same content structure for your website pages or posts? The CKEditor Templates and CKEditor Templates User Interface modules are your ticket to easy duplication. Both modules depend on libraries which can be downloaded and installed as instructed in the module pages. After installing these libraries, you can move the template icon from Available buttons to Active toolbar as shown in the below image.

The CKEditor Templates module provides a dialog popup with predefined templates. When you click on the template icon (as shown in the above screenshot) you will see a popup open you will choose any of your predefined templates. The template will then be inserted with “text format and styles” which are included. 

The CKEditor Templates User Interface module is what you use to create the templates that you choose from in the CKEditor Templates module. After enabling the module, you will find an option in the Config > Content Authoring > CKEditor Templates section.

When you click on CKEditor Templates from the configuration, you will be redirected to the CKEditor configuration templates page. Now you can add or edit templates.

5. CKEditor CodeSnippet

Using the CKEditor CodeSnippet module, you can add your "code content" within the content so it is highlighted and well formatted. This module uses the highlight-js library and all available styles for it. Installing this module using composer will install the library automatically. After installing this module, you can move the “code snippet” icon from the Available button to Active toolbar. 

Now you will find the Code Snippet tab in the CKEditor plugin settings of text format. Here you can check/uncheck supported programming languages. 

Code Snippet

FAQ: How to use it?

Once you install the module, you can insert the CodeSnippet feature in your content from CKEditor. When you click on the Code Snippet icon, you will get a popup. Here, you can paste your code and select the code language.

6. CKEditor Wordcount

So you’re working with a word/character limit… This is a common situation in highly stylized sites with dynamic layouts. And those can get especially messy with multiple hands working on the same content. In these cases it’s helpful to see the number of characters and words right in your CKEditor in the footer of the editor itself (just like you would in MS Word). That's when you would install the CKEditor Wordcount module. After installing the module and library, you can find “word count and character count” in CKEditor plugin settings of text format. Here, you can check/uncheck features according to your requirement. You will also find a counter in CKEditor at the bottom-right part of it.

Word Count

 

7. CKEditor Tweetable Text

Trying to score some internet points? Using the CKEditor Tweetable Text module, you can give the option for your users to tweet a particular piece of text by clicking on a word or syntax. Just install the module and library as instructed in the module page and move the tweetable text icon from the Available button to the Active toolbar. You will then find a tweet icon in the text editor. When you click on this icon, a popup will open up. Here, you can add a Display Text (for which word(s) you want to add the tweet icon) and Tweetable Text (the text that will appear in the Tweet).  When a user clicks on Display Text then it will redirect to Twitter and Tweetable Text will be displayed.

CKEditor Tweetable Text
Nov 29 2021
Nov 29

As you may know, we are planning to release Drupal 10 in 2022 (as early as June), because Drupal 9's Symfony 4 and CKEditor 4 are both end of life the year after, around the end of 2023. So we plan go give enough time for people to update to Drupal 10 before Drupal 9 goes end of life. A similar situation happened with Drupal 8 to 9 driven by Symfony 3 to 4. However, moving Drupal 10 from Symfony 4 to 5 would again only give us a couple years of time to move on to Symfony 6 next, so the current plan is to move to Symfony 6 straight.

How is it possible to move Drupal 10 from Symfony 4 to 6? Symfony 6.0 was just released a few hours ago and is stable, so by the time Drupal 10 would be released, it will already be at least on Symfony 6.1.

However, the exact same thing happened with Drupal 8, and we did not do a double Symfony version jump update from Drupal 8 to 9 for two reasons: (a) even though Drupal core minor versions are supported for 12 months, Symfony minor versions are only supported for 8 months other than the last LTS minor version and (b) jumping two versions would mean that scanning for and acting on minor version to minor version all deprecations is challenging. Those two did not resolve themselves so to speak, however we have plans to mitigate them.

Symfony security extension for Drupal-used packages

First of all, Symfony normally supports minor releases for 8 months starting with Symfony 5. On the other hand Drupal minor releases are supported for 12 months, so if there are security fixes to be made, this would not be possible on a non-LTS version of Symfony. However we made arrangements with the Symfony team to have two of the Drupal core committers be part of the Symfony security process and be able to backport security fixes as needed for components used by Drupal even if the given Symfony minor version would be normally out of support. The two Drupal core committers involved are Alex Pott and Lee Rowlands! I don't believe there was an official announcement of this agreement yet, however it was in place since September 2019. Special thanks for the open minded collaboration of the Symfony leads as well!

Bridging the deprecations jump with Symfony 5.4

Second is bridging API deprecations. Nathaniel Catchpole outlined the plan for this recently. The problem is that Symfony 4 deprecated some APIs for removal/changes in Symfony 5 and them Symfony 5 deprecated some APIs for removal/changes in Symfony 6. Jumping through two versions gives Drupal 10 a potentially longer lifetime but with a need to solve identifying all deprecated API uses for both. Now that both Symfony 5.4 and 6.0 are out, the plan is to open the Drupal 10.x-dev branch for development very soon and update to Symfony 5.4 as well as other big dependency updates. Then release a Drupal 10.0.0-alpha1 that is based off of Symfony 5.4, which would allow contributed projects and custom code to check against deprecated APIs towards Symfony 6. And only later update to Symfony 6. This way there is a middle-point that allows to make the necessary updates and check deprecated APIs against.

As jumping two major Symfony versions is not something we did before, let us know in the Drupal 10 issue if you can poke holes at the grand plan. While it looks like this will be entirely possible, it would be best to find any potential pain points ahead of Drupal implementers hitting them.

A proposal with overlapping LTS release versions of Drupal core

Lee Rowlands went even further and presented the potential benefits of this plan down the line with Drupal 11 and Drupal 12. Releasing Drupal 10 on Symfony 6 would allow us to support it longer, up to November 2027. However it does not mean that we cannot release Drupal 11 earlier than 2026 let's say. Releasing earlier would allow us to jump faster to Symfony 7 while it would still give Drupal 10 users a more comfortable, longer support timeline. Then we could take advantage of the full Symfony 7 support timeline.

That would result in Drupal users not needing to update every 12 months to keep security support but needing to update every 2.5 years instead, which would lower cost of ownership of Drupal considerably.

Check out this video where Lee explains the details and discuss in the issue titled Adopt a 2 year major release cadence and a 6 month LTS-to-LTS overlap period for Drupal 10 and beyond. (This is not yet a firm policy, it is under discussion).

[embedded content]
Nov 29 2021
Nov 29

Welcome to Talking Drupal. Today we are talking about Pantheon Autopilot with Nathan Tyler.

TalkingDrupal.com/323

Topics

  • Nic - Firefly iii
  • Kevin - Visiting Asheville
  • Nathan - Working on 227 open source repos, soccer league
  • John - Drupal Providence
  • Pantheon Autopilot
  • Visual regression tests
  • How it works
  • Comparison with backstop js
  • Deployment workflow
  • Composer integration
  • Compatible Drupal versions
  • Other platforms
  • Pantheon upstreams
  • Development process
  • Acquisition
  • Automatic updates initiative in Drupal core
  • Developer reactions
  • Need for autopilot once automatic updates are supported
  • Roadmap
  • Adding it to your account
  • Most surprising project from pantheon

Resources

Guests

Nathan Tyler - @getpantheon

Hosts

Nic Laflin - www.nLighteneddevelopment.com @nicxvan
John Picozzi - www.epam.com @johnpicozzi
Kevin Thull - @kevinjthull

MOTW

Webform
The Webform module allows you to build any type of form to collect any type of data, which can be submitted to any application or system. Every single behavior and aspect of your forms and their inputs are customizable. Whether you need a multi-page form containing a multi-column input layout with conditional logic or a simple contact form that pushes data to a SalesForce/CRM, it is all possible using the Webform module for Drupal 8/9.

Nov 29 2021
Nov 29

No doubt that by now you are familiar with the Drupal display and form modes. The former existed in previous versions of Drupal while the latter came in Drupal 8. As a matter of fact, you can check out this older article of mine in which I talk about custom form modes and how we can define and make entity types use them. If, of course, you are unfamiliar with the topic.

Today, however, I am going to tell you about a new hook introduced in Drupal 9.2 which allows us to swap out the form mode dynamically when the entity form is being rendered. Which, I have to admit, is something pretty cool. Many times in the past I had to alter forms and hide fields based various criteria such as access or context.

Let me paint you a picture with my imagination brush. Just to get an idea when this hook would shine. Imagine you have users on your site with a role called Customer. Admins can create/edit these users and they should be able to control all the fields on the user account. Which can include even things like remote_id. However, the users themselves, when they edit their own account, should not see all these fields but only a subset. For example, just the email and password. Maybe the timezone. Whatever. What you need in this case is to have a different form mode for when the user edits their own account and the default one can stay for when the admin edits the account.

We can now easily achieve this with hook_entity_form_mode_alter(). Before this new hook, a workaround for this kind of use case could be achieved with the more verbose hook_entity_form_display_alter(). This allows to hide or show various components (fields) from the form display depending on various conditions. But now, we can simply configure our form mode and switch it out entirely.

And it’s all very simple. Assuming you have created your User role called Customer and a form mode for the User account also called customer, we can implement the hook simply like this:

function module_name_entity_form_mode_alter(&$form_mode, Drupal\Core\Entity\EntityInterface $entity) {
  if ($entity instanceof \Drupal\user\UserInterface && $entity->hasRole('customer') && \Drupal::currentUser()->id() === $entity->id()) {
    $form_mode = 'customer';
  }
}

The hook receives the current form mode by reference so we can change it and the entity whose form is being built. All we have to do is check if we are looking at a User form and that the current user is the same as the user being edited. And we’re done. Customer users will now only see the intended subset of fields when editing their accounts. And when you add a new field, adjusting who gets to see it will be a matter of configuration instead of actual development work.

Hope this helps.

Nov 29 2021
Nov 29

Drupal is written by volunteers and by employees of companies who sponsor them. Writing code is usually the main way to contribute to open source, but reviewing others code is important as well.

I’m one of the ones who reviews others’ code, after five years of doing this I would like to reflect on the exercise of being a maintainer.

How it started

I started working with Drupal around June of 2007. After ten years of learning and contributing to random projects and modules, I decided to try something new. So I searched for some projects in the MAINTAINERS.txt file without anyone in charge, and started doing issue triage.

I picked dblog at first, a simple module easy to understand. Nobody was actively maintaining it after the Drupal 8 development started.

As a software developer, one big lesson open source gives you is, complex software needs managers. So that was what I did, I left my programmer hat aside and started doing triage of existing issues.

  • Issues with patches state Active, change status to Need Review.

  • Issues marked as Needs Review that require changes, mentioned by someone from the community, set as Needs Work.

  • Nothing else required, patch looks good? Try the patch locally and if it works, move it to Reviewed and Tested by the Community.

  • If an issue is already reported somewhere else, close it as a Duplicate.

  • At the same time, since I had some experience working with views in the past, I contributed to using a view to list log entries.

Eventually, after six months of doing this I applied to be a formal maintainer of the dblog module. The community agreed, and I became a formal subsystem maintainer.

What I do

Managing a core module requires keeping an eye on the issue queue. I have some specific advanced search filters that I check at least two times per week.

My main goal is not to have Ready For Review issues waiting for more than one week. I also try to give assistance on new Feature Requests, but deliberately try not to code them so I can review it later.

Since I check the code of dblog quite often, I also create Novice bug reports that new developers can use to start their contribution journey.

In my opinion, one of the most interesting part of this role is doing some code archaeology. Take for example this issue

The original solution proposed to solve this bug was to prefix the classes of the watchdog views table because they are colliding with other classes of themes. I saw the bug report, it made sense at first glance, and indeed was something inconsistent with the non views UI of the dblog module. But then I started digging why this class was there in the first place.

After some git work, switching branches way back to D7, then D8, I concluded those classes were not used for 9 years! Hence we can remove them.

So, I rewrote the issue summary so others know what to do, and moved the issue to Needs Work.

As Drupal evolves, sometimes it is not easy to just remove code, you need to update the current configuration of existing sites. And you need tests. No issue should be fixed without touching or adding new tests.

Once some other contributors fixed the issue, I did a final review and left the ticket ready to be committed by the core maintainers.

Benefits

Now you have a better idea of what I do, let me reflect on the benefits of doing this.

  • You learn a lot. I don’t have all the knowledge in my head, and reading others’ points of view always helps to understand the problem and existing APIs.

  • You have the chance to interact with other members of the community. Take the issue mentioned above. Devs from Russia, Canada, New Zealand, Italy, United Kingdom and Argentina collaborated to fix a small bug.

  • You keep up to date with what is going on in the rest of the Drupal ecosystem. Sometimes running git log --oneline core/modules/dblog/ gives me an idea of what’s going on elsewhere in core.

  • You get a great user profile. I remember my first interview with Amitai saying, “look Mariano, I know you know Drupal, so we will not speak about that”.

Pain points

Not all is beautiful in this role. Sometimes you have more issues than you can handle. Sometimes nobody contributes to fix bugs and they sit there forever. Sometimes you think you did everything ok, but then someone else, usually someone smarter than me, marks a trivial error in your review that requires more work from the original contributor. This often frustrates me because I could have done a better job to reduce the friction and keep devs motivated to fix the problem. But at the same time, I learn a lot.

Also, sometimes nobody reviews your code. Because you are the one who should review it. Take for example the effort to convert db logs entries into entities. This would fix so many long open issues, but it has been there for two months and no real reviews. As a maintainer you must learn to live with that and understand that your issue is one of the 23K currently open issues. Patience is the key.

The bus factor in my case is not ideal either, there is nobody else to discuss architectural decisions specifically for the modules I maintain. Of course there are a ton of capable devs that contribute to core, but there are also a lot of issues out there. This is not the case in other modules like Jsonapi, Layout Builder, or Migrate where you see a team maintaining the subsystem.

Looking back

In retrospect, the last five years have been a great way to learn for me. I had some big milestones during this time, like having cleaned at least for some months all the issues of the syslog module issue queue, which I also maintain.

I have the luck of being supported by Gizra to do this. But I have contributed a lot of my free time as well to this task.

If you are in the same situation as me, or simply think you are a good fit for this task, go ahead and search for orphan modules in core. You know what it takes, the pains but also the benefits. Good luck!

Nov 28 2021
Nov 28

Drupal happily hides the chaos when it comes to timezones. We have UNIX timestamps, which are timezone-agnostic, and other forms of dates that are always in UTC, which it converts for you on-the-fly before displaying them to the users. This way, you do not need to worry about the pain of converting dates between timezones, a magic database in the background resolves it. Obviously it won’t work for anonymous visitors as the timezone information is missing, also the pages are often cached for them. One solution would be to render the dates for the frontend entirely on the client side, but it means throwing away all that Drupal does for us already - a well tested and designed handling for the dates with formatters, etc. But what about the backend side? Let us introduce the Anonymous Timezone contrib module.

Caching

Serving timezone-aware data from the backend means that the traditional page cache is not usable anymore, however with Dynamic Page Cache and BigPipe present, it seems to be an acceptable trade-off to be able to implement this functionality. All we need to do is to invoke the kill switch and page cache is eliminated. Some pages do not contain dates, so it’s possible to maintain a whitelist where the kill switch isn’t triggered, so for example the homepage can load pretty fast, even fully from a nearby CDN endpoint. Then for a specific node view, we can render it properly with timezone information. For our specific use case, performance was acceptable and scalability wasn’t the main concern, but beware, this module definitely deteriorates performance and needs careful fine tuning. Also the pages where dates are present, become timezone-dependent, it means adding timezone cache context is needed. This isn’t automatic, that’s part of the integration.

Timezone Information

On the backend, it’s impossible to get perfectly accurate timezone information, but an approximate solution exists based on the IP address of the client. The free database that’s available turned out to be precise enough, as we do not need city-level accuracy, merely timezone-level, in simple cases, it provided good results for us. The upside of this solution is that we do not need to query an external service, the downside is that the static GeoDB file needs to be updated from time to time to preserve the accuracy.

Altering Core - Easier Than You Imagine

Veteran Drupal developers might tend to think that altering core is a bit hard or complicated; but usually it’s far from the truth. With services architecture, it’s possible to just redefine any service in a custom module and that’s all, for instance the anonymous_timezone.services.yml:

services:
  current_user:
    class: Drupal\anonymous_timezone\AnonymousTimezoneAccountProxy
    arguments: ['@event_dispatcher', '@page_cache_kill_switch', '@request_stack', '@config.factory']

Devel module similarly does its sophisticated profiling, by overriding many core services. It’s likely wise to check with a profiler what changes in terms of CPU time and DB usage when Anonymous Timezone disables the classical page cache.

In Action

If you’d like to test the accuracy of this approach, try it out yourself using GitPod, upload the city-level MMDB database from MaxMind at /admin/config/anonymous_timezone, then try the accuracy using anonymous user and let us know :)

Trying out Anonymous Timezone is 1-click away
Nov 27 2021
Nov 27

What is no code?

Basically it comes down to building a complex website using a Graphical User Interface instead of typing code using a programming language such as PHP.

Personal experience

I’ve been designing and building Drupal websites for over 10+ years now and I didn’t have to write any code once. I might have tweaked some files here and there but the number of times I had to dive into some PHP code can be counted on one hand. 

What I have built with Drupal are not just simple websites with a few pages. I’ve built:

  • A video sharing sites for a University
  • An intranet where employees can share news and files. Including an overview of upcoming birthdays and an extensive search option where employees can easily find each other's information, such as an e-mail or telephone number
  • A community where users can sign up and privately share information. Even creating (private) groups within the community

Drupal is flexible

Out of the box Drupal is already very flexible. You can create content types, such as Articles, and add fields to them. These fields can be anything such as a simple text field or an image, video, file, mp3. You can also reference any entity within a field making it possible to set up relations between different content items (called nodes in Drupal). But you can even reference users or taxonomy terms.

Because Drupal is built with this flexibility in mind almost anything is an entity. Making it possible to connect different parts and ensuring all Drupal modules play nicely together.

Nov 25 2021
Nov 25

If you're a seasoned Drupal module developer, or even a relatively new one, it's hard not to like the fact that, starting with Drupal 8.7.7, it's possible for a single version of a module to be compatible with multiple versions of Drupal core. Suddenly, maintaining your module became way easier. It's noteworthy enough that the process of making a module work with the Drupal 9 release was incomparably easier than any previous major version upgrade. But beyond that, you could actually maintain a single version for both Drupal 8 and 9, or both Drupal 9 and 10. How great is that?

But - and there always is a but, isn't there? - it's not quite so straightforward. There are some significant tradeoffs to sticking with a single release branch for two major versions of core. I'll look at a couple here - deferred refactoring and missed improvements - and ways to mitigate them.

Pitfall #1: deferred refactoring

One of the modules I've maintained for Drupal 8+ is Features. While not nearly as widely used as in Drupal 7, Features still has a reported install base of around 29,000 in Drupal 8 and 9, placing it somewhere in the top 100 or so modules by usage.

To get Features working in Drupal 9, I did what a lot of Drupal module maintainers did--the minimum.

I focused on what was strictly necessary to make the module work in the new version. Even that was a fair bit of work, spread over many issues and several releases. We had to upgrade the automated tests, fix up the way we generate new feature modules, and lots more.

Sure, at the same time I also took a pass or two through the issue queue and applied fixes where I could, addressing a few outstanding bugs not explicitly required for Drupal 9.

The combined result was a lot of improvements to the module, some of them addressing longstanding issues. What I didn't even begin to do, however, was ask: how would we do it now?

When we started work on the Drupal 8 version, keeping the same code and approaches we had in Drupal 7 wasn't remotely an option. Drupal had been rewritten from the ground up, and contributed modules had to keep pace.

Now, though, sticking with what we did in Drupal 8 definitely is an option, and it's an alluring one.

The bulk of work on the current Features version was completed early in the Drupal 8 cycle. At the risk of understatement, a lot has changed in the meantime. In Drupal core, there was a whole Configuration Management 2.0 initiative that introduced various improvements during the Drupal 8 cycle. In contrib there are some great modules now that hadn't so much as been imagined when we started in on Features.

Then there's what we've learned through using and developing Features itself.

How would I approach Features if I was writing it from scratch today? Very differently.

For starters, I'd make it a lot more modular. There are pieces of Features that duplicate what other modules do, sometimes better than Features does.

But I don't have to do any of that--and so I won't.

Don't get me wrong, I still think Features is a fine module for many uses. It just won't get the attention it might have if stasis wasn't an option.

Pitfall #2: missed improvements going forward

There's a flip side to the fact that a Drupal 8 module could run on Drupal 9. It's that a Drupal 9 module had to still run on Drupal 8.

There are workarounds that in some cases make it possible to take advantage of newer functionality while maintaining backward compatibility. But short of such additional work, a release that's compatible with both Drupal 8 and 9 is stuck in some version of the past. Module developers can't add anything that comes with Drupal 9--any of the improvements in Drupal 9.1 or later minor releases.

At the same time, they can't remove anything that's deprecated in the Drupal 9 cycle and slated to be removed in Drupal 10, because doing so would mean their code wouldn't work in Drupal 8.

And here's the clincher--by the time a lot of developers began making their modules compatible with both Drupal 8 and 9, Drupal 8 was already on its way out. Drupal 8 reached end of life this month. At this point, the ability for a module to work in both Drupal 8 and 9 is kinda academic.

Worse--all these still-maintained Drupal 8 compatible modules may contribute to a mistaken sense that it's safe to stay on Drupal 8. Compatibility with an obsolete core version looks less like a feature than a bug.

Conclusions?

It might sound like I'm tilting against multi-version releases. Calling for discipline--resist the temptation! Cut a new branch as soon as a new major version is available! Refactor to use the best of what's added throughout the new cycle! Remove deprecated code in each Drupal 9 minor release, so the code is already compatible with Drupal 10 when it's released!

But that's not really my point. Instead, I'm thinking there's probably a middle ground. Maybe, for some site and module maintainers, that looks like:

  • After the work of the a new version upgrade, ride for awhile the relative ease of multi-version compatibility.
  • But don't leave it forever. When you're ready, cut a new branch and see what improvements the new core version brings.
  • At the latest, cut the new release branch when the old major version of core is no longer supported. For Drupal 8, that time is now.

In sum? Multi-version compatibility makes the work of maintaining code more manageable. It gives Drupal users quicker access to the modules they know and rely on from past versions. We can appreciate it for what it is, while not losing sight of what it isn't: a magic cure to the problem of keeping software current.

Nov 25 2021
Nov 25

Advantages of decoupled websites

1. They’re secure

When we create a decoupled website the storage of the data and the servers are in one place and the actual website is somewhere else. For example, my personal website is hosted on Github Pages but the CMS is behind a firewall, somewhere where nobody else can get to it. There’s no database, no server, and no forms that might make it hackable. And that right there is a very enticing proposition for local councils: to have a very secure website.

Another benefit of this can be seen when it comes to updates. For example, when there is a security update for Drupal there is a rush to get applied (because it is open source anyone can see the source code at all times).

When it comes to a decoupled site, since the Drupal backend is stored off-site and locked away and not available on the open internet you can take your time about doing your updates. The updates definitely need to be applied, but the urgency is removed.

2. They’re fast

Aside from the security, there’s the idea of speed. Performance is one of Google’s metrics for search engine ranking, and one of Google's core web vitals metrics is the user's experience when loading a webpage.

These metrics include how quickly a page loads, how quickly a browser can respond to a user's input, and how unstable the content is as it loads in the browser. As an SEO metric, having a fast website is as important as having good content.

Decoupled sites are fast because they do not interact with the database and do not gather all the parts of a page before putting the page together for you. Rather, they deliver the whole page, fully-formed, in one go.

3. Scalable solution for microsites and campaign sites

Decoupled sites are a good choice for local governments because many councils have a large number of websites. For example, in addition to a main council website there might be numerous small microsites for events such as a Christmas campaign, a local food fair or a St Patrick's Day festival.

Each microsite has its own hosting platform, database and developers who maintain it. The costs start to snowball when it comes to this many sites. If there’s a security update for a CMS then multiple different websites need to be updated and tested – and when it comes to a council website there could be 30 or 40 different websites that need to be updated.

Within a decoupled situation, we'd suggest just one CMS – so when there's an update, only one platform needs to be updated; when there's a new feature request, it needs to be applied to only one site.

This simplifies things beautifully. Decoupling would mean that all the council’s content could be stored in one place, so content editors just need to get used to use one system. They could, for example, create the news for all the different websites on one website and then tag that news as, say "Christmas" or "food festival". After that, the decoupling system will pull those content items into the individual websites.

The situation can be tailored to specific needs. The main council website could be decoupled – lighting fast, un-hackable and future-proofed. And then additional microsites could be added as they’re needed.

Microsites can retain the branding of the main site or they can have a completely independent look and feel. But the idea is that all content is stored and managed in one place.

It should homogenise your content and make it much easier to keep track of it. So as we've said, it means content designers and editors only need to learn one system, and if they want to update any system – a website, an app, a microsite, etc – they just have to log in to the one shared CMS.

4. Costs and time

Many councils prefer to pay for one website rather than for 50 websites. A decoupled site allows for this.

For example, when working with the Irish Centre for High-End Computing we created a system in which all microsites are created in the current Drupal CMS, but not displayed there. To create a microsite, it's a matter of simply tagging each post or page with the name of that microsite. There can be as many microsites as needed, either following a set design or with a custom design.

If ICHEC wants a new microsite for, say, Science Week 2022 and Science Week 2023 and so on, this can happen with very little development time. We’ve built a system where the content creators can create all the news posts and the home page by adding a category on the website called Science Week 2022 and tagging each page they want to appear in the microsite with this.

It will take us an hour or two to get the infrastructure set up for each website with the website live straightaway, rather than taking us a number of weeks to build a new website.

5. Redesigns and migrations

Redesigns and migrations are a double-edged sword. You have to do them, and things usually look and run better once they’re done. But they take time and cost money.

When it comes to a decoupled site, because the backend and frontend are decoupled from each other either of them can be updated at leisure without affecting the other part.

So let’s say someone wants move their website from Wordpress to Drupal. They can afford a new look for the website but can’t afford to update the whole database and migrate all the content to a new system.

We can redo the decoupled frontend – and it would look brilliant – and then in a year’s time when they have the budget to update the backend we can get on the backend and the frontend remains the same. There can be different stages of development, so they can move at the pace they want.

Please see the video below that I presented at DrupalCon Amsterdam on GatsbyJS and decoupled websites.

Nov 25 2021
Nov 25

With improved performance, a cleaner code, and security improvements, there is a lot to love about Drupal 9. Here are a few benefits you will get from Drupal 9 migration services:

drupal 9 benefits

Empowers us to use intuitive tools. One of the major improvements considered in Drupal 9 is the ease of use. Drupal 9 comes up with various tools to ease the use of Drupal 9. Starting from automatic updates and decoupled menus to Drupal 10 readiness, there are a lot of tools available to use to simplify your work.

Smoother upgrades. Drupal 9 focuses more on smoother upgrades as you don’t have to reinvent the wheel all over again, and any need to re-platform new versions gets released.

Helps you innovate more often. You never get restricted when it comes to using advanced features. You can easily access the latest features to innovate in your business site.

Brings flexibility when it comes to front-end facilities. Drupal 9 has adopted an API-first approach, which helps you make your site more versatile. This allows better integrations, which aids flexibility in the front-end.

Ease of managing richer media. You can easily embed remote content like YouTube and Vimeo on your website. Moreover, with a richer media library module, Drupal development agencies can easily add existing media assets.

Enhanced layout builder. It is possible to use visual design tools to design layouts for template content, customize layout templates, or even add custom pages to the website.

Nov 24 2021
Nov 24

After six months of work I'm delighted to tag the first stable release of the 4.x branch of the (Not-so-) Simple XML Sitemap module.

The project is in a really good place right now. At the moment of writing, drupal.org reports it being actively used on around 90k of Drupal 8/9 websites while having 0 open bug reports. This either means you people are lousy bug reporters, or we are doing a descent job at responding. :)

Module rewrite with developers/integrators in mind

4.x makes much greater use of Drupal's entity API dropping some of its very specific chaining API. Feel free to take a look at the roadmap ticket for specifics.

New UI

We now have a much nicer UI for creating, editing and sorting sitemaps as well as sitemap types.

Sitemap list UI

API usage

In a nutshell, sitemap variants are now sitemap entities. These are of a sitemap type (sitemap type entity) that is defined by URL generator plugins as well as sitemap generator plugins.

  1. // Create a new sitemap of the default_hreflang sitemap type.

  2. \Drupal\simple_sitemap\Entity\SimpleSitemap::create(['id' => 'test', 'type' => 'default_hreflang', 'label' => 'Test'])->save();

  3. /** @var \Drupal\simple_sitemap\Manager\Generator $generator */

  4. $generator = \Drupal::service('simple_sitemap.generator');

  5. // Set some random settings.

  6. if ($generator->getSetting('cron_generate')) {

  7. $generator

  8. ->saveSetting('generate_duration', 20000)

  9. ->saveSetting('base_url', 'https://test');

  10. }

  11. // Set an entity type to be indexed.

  12. $generator

  13. ->entityManager()

  14. ->enableEntityType('node')

  15. ->setVariants(['default', 'test']) // All following operations will concern these variants.

  16. ->setBundleSettings('node', 'page', ['index' => TRUE, 'priority' => 0.5]);

  17. // Set a custom link to be indexed.

  18. $generator

  19. ->customLinkManager()

  20. ->remove() // Remove all custom links from all variants.

  21. ->setVariants(['test']) // All following operations will concern these variants.

  22. ->add('/some/view/page', ['priority' => 0.5]);

  23. // Generate the sitemap, but rebuild the queue first in case an old generation is in

  24. // progress.

  25. $generator

  26. ->rebuildQueue()

  27. ->generate();

See code documentation and readme for instruction on how to create URL generator and sitemap generator plugins and check out what other things can be done with the API. You are welcome to submit support requests in the matter as well as help improving the documentation.

Should you use this over 3.x?

Yes, read on though.

While the changes of this release are catered towards developers and site builders, I strongly encourage everyone to use the new version, as 3.x will be considered deprecated from now on. All new features and improvements will be coming to 4.x only. Do not panic however, I will be fixing bugs in 3.x for a while.

An update path is provided from previous module versions. Two reasons you might want to postpone upgrading is:

  • You depend on the old module's API and need some time to adjust it
  • You depend on 3rd party contributed simple_sitemap submodules that are yet to be made compatible with Simple XML Sitemap 4.x. In this case, please open up issues in the respective queues.

Thanks for everyone who has been involved in the development of this tool. Enjoy!

Nov 24 2021
Nov 24

For laying out content on a website, Drupal standardly uses a single body field that takes advantage of the WYSIWYG capabilities and is available immediately after installation of the CKEditor. This solution is easy to use but not flexible enough to be suitable in every case. For more advanced layouts, we can use the functionality prepared by the community in the Paragraphs module.

Drupal paragraph - characteristics

Paragraphs in Drupal are a useful solution with many possibilities. Thanks to them, we aren’t dependent on one WYSIWYG field where we place all the images and videos one under another. Paragraphs can be considered as some kind of sections on a given page. Each of these sections can have different configuration options, affecting the paragraph's appearance and its performance. This may be, for example, a color scheme, the size of images or a completely different layout of fields. With just a few paragraphs added to a page, editing them becomes time-consuming because Drupal standard UI doesn't allow for responsive editing. Is there any way to improve the UX? The answer to this question is Droopler, a Drupal distribution for building websites that uses the Geysir and Field Group modules.

Editing paragraphs in Drupal

As I pointed out above, editing paragraphs in pure Drupal is a time-consuming task. Let us analyze an example:

A sample list with paragraphs in Drupal

 

On the given page, we see several paragraphs that have many configuration options. Here is the configuration form for one of them:

The configuration form of a Drupal paragraph

 

As we can see in this example, the configuration options aren’t grouped, although the structure of the paragraph allows for separating at least two sections. The Field Group module - described further on in this article - is responsible for this functionality.

We finished the presentation of the configuration options. Below you can see how the paragraph looks like on the frontend:

The appearance of the Drupal paragraph on frontend

 

The standard editing path in Drupal firstly requires going to edit entities and then editing the selected paragraph. If a paragraph has references to other paragraphs in it, and our goal is to edit one of the referenced paragraphs, then the whole process starts to get complicated. Usually, the paragraphs aren’t very well described, and it’s easy to enter the edition of the wrong paragraph. After editing, you need to save the changes and then switch to the entity view to see if you are satisfied with the modifications. Note that each time the page must be reloaded, as we don’t see the changes "live". This makes the editing process time-consuming and not very pleasant. How does it look like in Droopler?

Editing a Drupal paragraph in Droopler

Droopler is an installation profile that allows you to create websites in Drupal in a very simple and fast way. It’s great for both building business web pages and microservices, and from version 2.2 also for online stores. Starting from this version, Droopler has an integration with the Commerce module.

The frontend of this installation profile is based on Bootstrap 4, so it isn’t complicated to make any modifications to the website’s appearance. Droopler also uses Geysir and Field Group modules, which will help us improve and speed up paragraph editing.

In Droopler, there is no reason why we would want to go into editing an entire entity if we only want to make a change to a paragraph. We use the Geysir module to make changes to a paragraph, which we can launch by clicking on the Paragraph overlay button at the top right of the screen.

The Droopler's website screen with the Paragraph overlay button visible

 

After entering the paragraph edit mode, point the cursor to the paragraph you are interested in and click on the edit button.

Paragraph edit buttons visible on the web page in Droopler

 

When clicked, you’ll see an overlay menu containing the same settings as in the standard view. However, this time they are grouped using the Field Group module.

View with Drupal paragraphs grouped after using the Field Group module

 

Once you've made your changes, all you have to do is save them, and the page asynchronously reloads only the paragraph that was edited. This means that we just got rid of the need to reload the whole website, and we can see the changes almost immediately!

It’s worth noting that the paragraph presented in Droopler uses the Field Group module, which allows you to divide the fields available in an entity into tabs. They are configured in the edit options of the entity view form.

Configuring entity fields in the edit options of the entity view form

 

Among other options, we can choose here between horizontal and vertical tabs, close or open our selected tab when entering the edition, or add custom classes to sections that allow us to manipulate only selected elements using CSS or JavaScript.

Editing a Drupal paragraph - summary

Paragraphs offer many possibilities, but configuring, editing and maintaining them on a standard Drupal instance isn’t the most convenient. The approach presented in Droopler will certainly make the process of creating, editing and managing paragraphs easier and faster. We recommend taking a closer look at how Droopler manages them. If your website also uses these components, we recommend using a similar method or the Droopler installation profile.

Nov 24 2021
Nov 24

As of November 2021, there are +2040 registered Drupal themes.​ The sheer number of options makes the selection of a good theme as exciting as it is tiring too! Especially for newcomers who have little to no expertise with Drupal themes. Of course, not all these themes are of equal quality. And while some Drupal themes are free, the rest are known as being premium, i.e. They are available for a fee.

This article will list the top 1-0 free Drupal themes, each of them in our opinion is a great choice for a beginning site builder. But if you don’t mind investing a small part of your overall budget, we recommend our article of the best 20 Drupal themes to use in 2022.

Are you a Drupal newcomer? Use our learning guide to become a guru!

Best Free Drupal Themes: Selection Criteria

To prepare this list, it was inevitable to make the comparison fair and objective to all the tested free Drupal themes. So, after much discussion, we decided that for a theme to make it to our list, it must satisfy the following set of strict and fairly objective criteria: 

  1. It must be free.
  2. It must run on either Drupal 7 or Drupal 8 (or better, both).
  3. It must be actively maintained and developed.
  4. It must be covered by the Drupal security advisory policy. Coverage under the policy does not guarantee that a theme is free of vulnerabilities. Rather, it means that the theme has been reviewed for any publicly known vulnerabilities by the Drupal security team.
  5. It must be a general-purpose theme. Some Drupal themes are designed for specific industries, e.g., restaurants. For the purpose of this list, only general-purpose themes are considered.
  6.  It must be responsive. A responsive theme adjusts its layout to accommodate different screen sizes and resolutions. This is a basic requirement for today's mobile platforms.
  7. It must run out-of-the-box

Don’t Confuse a Fully Featured Drupal Theme With a Base Theme

Not knowing the difference between a base theme (or a Framework) and a fully-featured one may result in picking the wrong theme. In a nutshell, a base theme is like a blank canvas with some advanced tools used by a themer (a theme developer) to build a custom theme. An example of a great base theme is Vardot’s Vartheme BS4 (soon to Vartheme BS5).

The top 10 list is limited to the fully-featured but free Drupal themes which one can use out-of-the-box as feature-complete themes. No theming and no coding is needed with our list!

While conducting this study, we noticed that few organizations produced a relatively large number of themes; Although good, they barely differed marginally. If an organization makes multiple but similar quality Drupal themes, only representative themes may be selected for inclusion in the following theme set. The individual or organization responsible for a theme is identified below in brackets.

Anyway, we have kept you in suspense for too long already. But here sing the Sirens!

Based on the aforementioned criteria, the top 10 free Drupal themes are:

Below, we discuss each theme in more detail with attached previews!

BlueMasters

It’s developed and being continuously improved by More Than (just) Themes; a solid well-reputed organization in the Drupal community. The theme was first built for WordPress. But thanks to its immense popularity, the community was elated to receive the Drupal version of the BlueMaster theme for free in 2010. The latest theme update was dated 18 November 2021! This means that the developing theme still works on improving this free theme.

The theme supports a maximum layout of 12 regions. A region is the primary layout unit to which a component block can be placed. Therefore, the more regions a theme supports, the more customizable it is. With this Drupal theme, you can display a slideshow on the front page, and partition information into either 2 or 3 columns on a web page. In addition, you can organize and access your content via multi-level drop-down menus.

BlueMasters, however, is only available on D7 and D8. If your website is running on Drupal 9, we recommend you check one of the free options we mentioned in our pick of the best 20 Drupal 9 articles.

Corporate Clean

Like BlueMasters, Corporate Clean is a theme ported to Drupal by the well-rounded MORE THAN Just THEMES. This theme offers an outstanding feature that is missing in many other free Drupal themes, namely, a color scheme selector. Most free themes have a fixed color scheme which means that you cannot change the color of a button or the page background. With Corporate Clean, you can easily adjust the color of some screen elements.

This theme supports 1-column, 2-column as well as 3-column layouts. Multi-level drop-down menus and slideshows are also supported. The Corporate Clean theme only runs on Drupal 7 and 8.

Danland

We recommend Danland because, among the Drupal themes on this top 10 list, it gives you the most flexibility to fine-tune the layout of your web page. Specifically, it supports a maximum of 26 regions, the second-highest number on the list. The layout can have 1, 2, or 3 columns. The standard installation features an image/photo slideshow feature. But its subtheme Danblog doesn’t support this feature. The latter is more convenient if your website is meant to be less dynamic or distractive.

Danland runs on Drupal 6, 7, and 8. It functions safely on all browsers and it’s pretty optimized for small screens such as phones and tablets. 

Business

When it comes to the major features, the Business theme is at par with other themes on the list. It’s highly recommended because of the finer feature details. For instance, the slideshow feature allows the display of up to 5 different images. Note that some free Drupal themes only allow a maximum of 3.

Also, the Business theme has a color module, which -as we mentioned earlier- is missing in most free themes. Still, you can only specify one of the 6 fixed colors for web components. The Business theme is available for Drupal 7 and 8. And more than 5000 websites are reported to be using this free Drupal theme.

However, the Drupal 7 version was not as responsive as required, but major updates were conducted as of 27 August 2021. But since no official reports were issued so far by the theme users, we recommend you only use it with D8 or look for a different theme for your D7 website. 

Business can have a max of 12 regions, slightly below the average of this list. Yet, we believe it’s enough for small to intermediate websites. This free Drupal theme has a configurable layout in which the slide bar can be right or left, and it features all the Google fonts. 

Nexus

Nexus is arguably the most visually appealing theme on the top 10 list. The clean design combined with the solid support by Devsaran, its maintainer organization, grants Nexus a safe spot on the list. The theme runs on both Drupal 7 and 8 with the Drupal 8 version being a pre-release version only.

The layout can have a maximum of 15 regions, which is average on the top 10 list. You can specify a 1-column or 2-column design on the layout. The slideshow feature supports only a maximum of 3 images, which is lower than what Business theme can support (5 images).

Although the theme was relatively updated recently (November 2019), the Drupal Organization makes it pretty clear that they have lifted their support due to unfixed security issues. Still, more than 8000 websites are reported to be using this theme!

Zircon

If your Drupal website is imagery-rich, then you should definitely consider using Zircon as your theme. You will be delighted by its slideshow, slider, as well as carousel features. You can run Zircon on both Drupal 7 and 8. However, the current Drupal 8 version has remained as a release candidate since November 2015.

The Zircon theme was updated in October 2021, which is pretty recent. Its layout supports 18 regions in 3 columns, and no less than 2000 websites are currently using it.

Business Responsive 

If you’re looking for a stable Drupal 8 theme, then it’s safe to say that the Business Responsive theme is a strong candidate This theme supports 16 regions in 1-column, 2-column, or 3-column layouts. It also has a slider feature, but installing the feature requires some manual steps after installing the theme.

This theme supports the use of social media icons for popular platforms such as Facebook, Twitter, LinkedIn, Vimeo, and Pinterest. The theme is also staying up to date by improving the integrated UX/UI features, to help website owners build a seamless digital customer experience.

You can install this theme on both Drupal 7 and 8 safely as more than 5000 websites use it as of the date of publishing this article. A worth noting fact, this theme is the only one whose users chart has been increasing during the past few years, rather than decreasing.

Drupal8 Zymphonies

This one is a really stable Drupal 8 theme that offers more bells and whistles than the Business Responsive theme. Drupal8 Zymphonies comes highly recommended for Drupal 8 sites, because, as you may guess, it’s D8!

This very phone responsive theme shares many features with other themes on the top 10 list, such as multi-level menus and 1/2/3-column layout. But it distinguishes itself by offering 22 regions for placing blocks! The second-highest on the theme list.

Also, you can customize the Zymphonies credit link, all supported social media links, and the title and description fields in the main banner. The theme is used by +4000 websites, and it’s not losing its audience according to the chart. In other words, its users are pretty happy with its performance!

Showcase Lite

Though developed by Skounis, the Showcase Lite theme is supported by the amazing MORE THAN Just THEMES organization. This theme is built to perform perfectly well on the mobile phone; especially since ⅔ of the users perform research on their phones. Still, the developer didn’t compromise its performance on bigger computers’ screens; the theme performs perfectly well on any device you can think of!

Another powerful feature of this theme is its ability to support almost any font or typography style. It supports all Google’s fonts, in addition to the Font-Your-Face module that helps you make effects on your typography style.

Showcase Light features 1, 2, and 3 columns with 36 regions! Which is the highest number by far on the list.

The theme was first launched in 2017, and its chart has been hitting a peak ever since. More than 2130 sites are apparently happy to use it as of November 2021.

Integrity

If you want a simple no-frills theme that just works out of the box, Integrity may be your choice. It is a Drupal 8 only theme. Its feature set is, in general, equal to the rest of the themes. Integrity supports multi-level menus and slideshows that display up to 5 images. The layout includes a 3-column design. The theme has defined 17 regions into which Drupal blocks can be placed. 

Identify the Right Multisite Solution Architecture for Your Enterprise

Summary & Conclusion

Drupal has a wealth of good free themes. Each of them is ideal for Drupal users who have relatively simple requirements and want to try something other than the default theme. If a free theme cannot fully satisfy your requirements, then you may want to use its premium alternative or even hire a professional Drupal agency that can assist you with your needs.

Which theme do you like the most among our top 10 choices? Perhaps, you have your own favorite theme that is not on our list. What are the goals of your project and what kind of theme are you looking for? Share with us your thoughts in the comments section below!

Read more: How to Choose the Right Open Source CMS for Your Website (Infographic)

 

Nov 24 2021
Nov 24

If a page load time goes from one second to ten seconds, the probability of a visitor bouncing, increases by 123% - Google
 
A user visiting your website has the patience level of a 5-year-old. Nothing against 5-year-olds (Specbee has a strict nothing against 5-year-olds policy), but as a site owner, you can’t expect anyone to wait more than 5 seconds for a page to load. Not when there’s infinite internet to explore. Even the best content will lose the audience if your pages don’t load quickly. But that’s just the human nature aspect of it. Your site speed plays a part in so much more…

Page Speed

A little bit of History

Google has always been on a mission to make the web faster. This goes back to 2009, when Google announced plans to “make the web faster”. The first step to those plans was to publish guidelines on website speed to persuade website owners to take a hard look at their load times.

Acting further on this, Google announced in 2010 that site speed would become one of the factors for their desktop SERP algorithms! If you were a site owner back then who was reading the not-so-subtle signs on the wall, this was a great opportunity for those already making faster loading sites in that they suddenly had a huge SEO advantage.

A few years later, by 2015, when Google announced that the number of searches performed on mobile devices exceeded those performed on desktop, it was time for site owners to adapt to a mobile first age. Google developed Accelerated Mobile Pages (AMP) and three years later, page speed for mobile was introduced as one of the ranking factors as well.

And, as if you couldn’t guess, things continue to progress (they always do) and in the summer of 2021, Google rolled out the latest addition, Page experience update to throw another critical factor affecting the current algorithm!

Usage Statistics AMP

Data, and what you need to know!

While page speed is a complex factor, people often get confused between site speed and page speed. Though they seem similar, site speed is an average of various sample pages of the website while page speed defines how long a page takes to load. Both of these play a vital role in the page experience of a website. In addition, Core Web Vitals are an important set of metrics that the site owner should look at to provide a seamless experience for users.

While we still spend a lot of time on keywords, desktop and mobile experience, backlink, content marketing, etc, we now must also pay attention to the on-page experience. And Core Web Vitals are the new set of metrics to let you know if you provide a quality page experience.

Let’s dig in a bit more on core signals.

Largest Contentful Paint [LCP]

Referring to the page loading performance, this Google experience metric indicates the time taken for the largest chunk of information on the page to load. For example, if the page has a video (often the largest piece of information on a page), the time taken for that video to completely load so that the user can play it, refers to LCP.

This is an important metric - Google does use LCP as a ranking factor for the pages in SERP.

First Input Delay [FIP]

The First Input Delay measures the responsiveness of the page/website. This Google metric indicates the response time to a user’s first interaction on the page/site.

Example: Your page has video and after the page is loaded the user clicks on “play”.  The time taken to play the video after the click is FID.

Cumulative Layout Shift [CLS]

CLS is a Google metrics which indicates the frequency of unexpected layout shifts/changes, affecting the website’s overall appearance.
I’m sure you have seen a website where you saw something interesting and you went on to click it, but at the last moment the screen jumps and a new button loads, which you end up clicking? That a big indication of poor coding or, in some cases, a hidden motive to make users click on ads or other links!

Core Web Vitals

Core Web Vital Report

The details and the reporting of Core Web Vitals can be handled through Search Console which offers detailed information of any errors and tips for improvement.

What can be done to improve speed?

When it comes to Google metrics and how website owners try to do their best to optimize their websites, it’s a bit of a race in the dark. While many website owners have an idea of how things work and what needs optimization, some owners blindly make drastic changes just hoping something works.

Without throwing things against the wall and seeing what sticks, here’s a few things that could improve the speed of your site/page.

Light, fast and furious!

Modern websites are often referred to as mini buses or limousines. They’re huge, filled with animations/graphics and have all sorts of code-heavy integrations - which makes them heavy & slow! When making a beautiful website, owners often deprioritize functionality.

Timeseries

Image Credits: Pingdom

To win the SEO race, it’s important that the site is light and is not loaded with unnecessary animations, fancy backgrounds, huge images, additional plugins and more. In addition to the reduced extravagance, excessive weight can also be shed by optimizing images, reducing the third-party scripts (make use of GTM), Implementing AMP, compressing the code (CSS & JS) and more.

In a CMS like Drupal, there are quite a few easy to use modules that help improve page speed.

Number of Scripts

Image Credits: Almanac

Now that your website is clean and decluttered, it’s time to give it more power! And the best way to do that is by using a proper hosting environment. Your website on a properly tuned hosting environment can work wonders when it comes to the performance. Additionally, you can also use a CDN to load your website resources faster.

Tools are your best friends!

Now that you know how important page speed is, the next thing to remember is the equal importance of monitoring. There are various tools that give you a great amount of information about your website’s speed performance (amongst a lot of other important metrics) that will also suggest the next optimizations to make. Here’s Specbee’s picks for the top 5 tools to measure your website performance:

  • Chrome Lighthouse
  • Web.dev
  • Google Page Insights
  • GTMetrix
  • Website Speed Test
Nov 23 2021
Nov 23

Drupal Event Platform Survey

To help ensure we are meeting the needs of other Drupal community events, we are have created this survey to help us prioritize the feature sets for our development roadmap. Whether you are a new or veteran Drupal event organizer please complete this short survey to tell us how a Drupal Event Platform could help you. Fill Out Our Survey

The Drupal Event Platform (DEP) is a committee within the Drupal Event Organizers Working Group. Our goal is to create a Drupal application MVP that helps event organizers build and maintain the entire event production process, from collecting session submissions to assigning presentations to the schedule.

Nov 23 2021
Nov 23

Many Drupal insiders recognize that data on Drupal usage that's collected and displayed on Drupal.org have their limitations. Since 2018 there's been a proposed Drupal core telemetry initiative to expand and improve the data collected. Meantime, though, the usage stats are widely referred to and cited. So it's worth spending a bit of time with them. What do they actually capture?

Before digging in, a disclaimer. Circa early 2007 I wrote the first rough prototypes of what became - with a lot of great work from Earl Miles, Derek Wright, and others - the client and server components of the Drupal core Update module. But I had little or nothing to do with any of that further work and I haven't done more than glance over the current Update module code, let alone the various pieces that run on Drupal.org to receive, log, and tally the data. So my notes here are more inference than studied conclusions.

To start off, a brief step back to look at where the stats come from.

How the stats are calculated

The Drupal.org data on project usage look simple enough at first glance, but like many statistics they have some non-obvious complexity and nuance.

Take the figures for Drupal core. There are date-specific tallies for how many sites report using Drupal core, broken down by major and minor release version and - if you scroll down the page - by individual release. The explanatory text states, "the figures show the number of sites that reported they are using a given version of the project."

Where to the data come from? A Drupal install using the "standard" install profile default installs a core module, Update, that checks periodically - by default, once daily - for available updates. When it does so, the instance sends data about itself to the Drupal servers, including data on all the projects it has installed. A "project" here is in the Drupal.org sense of something that's downloaded and installed as a package. It could be Drupal core, including all the core modules and themes, or a contributed project like Admin Toolbar, including submodules like Admin Toolbar Search.

To complicate things, the mechanism that triggers sending data to drupal.org - cron - relies by default on page visits, so installs with very low traffic may be missing from the data if they receive no page views at all in a given week. This fact may account for periodic dips in usage stats over periods that include holiday seasons, when certain kinds of sites receive fewer visits. Similarly, some Drupal sites won't have the Update module installed and so won't show up either.

On the flip side, it's always possible that some of what show up in the stats aren't Drupal installs at all but result from some attempt to game the system. Glancing over the graphs of Drupal core usage, it's hard not to notice some questionable spikes in the data, maybe most notably two in March and April of 2018 that showed supposed Drupal 7 usage jumps of nearly twenty percent from one week to the next, followed immediately by equally steep declines. So, yeah, some oddities, and over the years there have been discussions about spikes in the data and how to address them.

Once the installs have "called home," code on Drupal.org analyzes the logged data returned by all those Drupal installs in a given week, tallies it up, and presents the results in those handy tabular lists.

So does that mean for example that as of October 24, 2021 there were (doing some quick sums of the 9.0.x, 9.1.x, 9.2.x, 9.3.x, and 9.4.x numbers) at least 155,449 Drupal 9 sites?

The answer is, that depends on what you mean by "sites."

Installs vs. sites

A key thing to keep in mind when looking at the Drupal.org usage data is that they report Drupal installs--and these can be spun up for many different reasons. Some for sure are production websites. But other uses include:

  • Development environments. It's common for Drupal developers to spin up many installs they use purely for development purposes. Various dev tools have this kind of workflow baked in. For example, if you're using Pantheon to manage a Drupal site, you might spin up a different "multidev" environment for each new feature or bug you work on. If you have dozens of issues in a release, this might mean dozens of installs for each production website.
  • Code and configuration staging. Aside from one-off environments created for a particular issue, it's also common practice to use several permanent environments for staging code or configuration stages. Looking again to Pantheon, their platform features built-in support for Dev, Test, and Live environments. In other words, you might have two (or more) additional installs used for staging code and configuration changes on a single Drupal "site."
  • Evaluation. Some installs are created just to evaluate or try out Drupal or one or more of its extensions. For example, the simplytest.me service can be used to spin up short-lived Drupal installs for demo or testing purposes.
  • Continuous integration and automated testing. Drupal core and many Drupal extensions feature continuous integration including automated tests that are run on each proposed change to the software. There are many thousands of these issues open at any given time. Since tests are run for every new iteration of a proposed change classed as needing review, a given active issue can trigger multiple automated test runs in a given week, each involving a new Drupal install.

The main point: production websites are only a subset of Drupal installs.

Development installs

A sign that many reported installs are probably driven by automated testing is a data quirk that shows up whenever a new core minor version branch is opened up. For example, here's a chronological excerpt of the usage data from the weeks around the 9.2.x dev release.

Week 9.0.x 9.1.x 9.2.x September 27, 2020 24,405 29,493 0 October 4, 2020 23,753 26,411 0 October 11, 2020 25,506 28,148 345 October 18, 2020 24,558 10,723 19,926 October 25, 2020 26,288 16,150 18,461

What immediately stands out is the leap in usage numbers for 9.2.x. By the end of the week starting October 18, 2020 - just eight days after the 9.2.x dev release was cut - there were suddenly close to 20,000 installs reportedly running the release. Meanwhile, the usage of 9.1.x dropped by nearly as much.

Really? Did tens of thousands of site developers decide to switch their sites to the newest dev branch, practically overnight?

Less immediately obvious but equally striking are the high numbers for the two development Drupal 9 release branches compared to the stable one. During this period, combined usage numbers for the then-unsupported 9.1.x and 9.2.x development releases were around twenty percent higher than usage numbers for the stable 9.0 branch.

Huh? Were the majority of Drupal 9 sites really running the completely unsupported cutting edge releases? Where did these "sites" come from?

The answer is probably in the October 6, 2020 pre-announcement of the 9.1.0-alpha1 release, which noted that "all outstanding issues filed against 9.1.x" were to be "automatically migrated to 9.2.x"--meaning they'd now be tested against the 9.2.x version rather than 9.1.x.

And voila, all those 9.2.x installs appeared.

After shooting up to nearly 20,000 installs in eight days, the 9.2.x usage figures remained relatively static in the subsequent months, settling in for the most part at from 20,000-25,000. This pattern is consistent with usage driven mostly by automated tests.

Many higher-end Drupal sites feature their own flavour of continuous integration, with their own rules about which version or versions of core to test against--and their own potential footprint of test installs.

In short, many or most of these reported development-version installs are probably ephemeral software instances installed and then taken down by infrastructure scripts. "Sites" only in the most abstract sense. This probability means we should take care when basing conclusions on raw usage data, particularly early in a major version cycle.

Drupal 7 vs. 8+

Automated test installs, development environments, and the rest aren't new, but several of these types of install are likely to be on the increase in Drupal 8+.

In previous versions it was possible to stage configuration between multiple versions of the same site, but Drupal 8 was the first version to include explicit support for this workflow. "Reliable configuration management for safe and straightforward deployment of changes between environments" was a key selling point when Drupal 8 was announced. All things equal, we can expect a lot more usage of staging in Drupal 8+ than in earlier versions--and therefore a lot more installs per production site.

Automated testing too may have a bigger footprint in Drupal 8+ than it did in Drupal 7. It's widely accepted that Drupal 8+ has proportionally more high end, enterprise level sites, where dedicated development teams and continuous integration and automated testing are much more likely. Further, in Drupal 8+ the introduction of minor release cycles (for example, 9.0, 9.1) means at any given time there are more current or upcoming versions to test against and hence more potential test installs.

All of these factors mean among other things that the falling graph of Drupal core usage data probably understates the case if we're looking for data on production websites as opposed to installs.

Core vs. contrib

For core usage, there are other data sources available, like those from W3Techs, that for some questions may be a good corollary or alternative to drupal.org stats.

For contributed projects, there don't tend to be other sources. But Drupal site builders often want to know which are the most-used projects for a certain area of functionality and there, sinc the interest is in relative rank, whether the data do or don't include non-production sites is mostly irrelevant.

Refining the data

Is there anything we can do to exclude non-production install types from the core usage data and so more closely model numbers of production websites?

There is one easy adjustment we can make: filter out reported installs running development releases for future versions. These releases are, by definition, not suitable for production sites. For example, since at time of writing the latest stable release branch is 9.2.x, this would mean excluding data for the 9.3.x and 9.4.x development releases.

As of the October 31 data for Drupal 9, that adjustment brings us down from a gross figure of 155,449 reported installs to 130,772, a 16% reduction.

But that's probably as far as we can go without resorting to conjecture.

Could we reliably filter out installs done for the purpose of developing a module or theme? There are some relevant data sets, like the drupal.org commit log that lists all commits pushed to drupal.org core and contrib repositories, and shows up to hundreds of commits per day, but even with easy access to those data extrapolating from them to assume a number of development installs used in a given week would be mostly guesswork.

Similarly, it would be useful to be able to filter out duplicate environments of a given site. Every Drupal 8 or 9 site has a unique setting - system.site.uuid - that's shared across all environments and if it was possible to filter Drupal usage stats by unique site ID, doing so would remove the duplicate environments from the data. But the site's UUID doesn't figure in the key sent to Drupal.org to identify the particular install. Without that identifier, it's hard to see how we could distinguish duplicate environments--except, again, by making some fairly arbitrary assumptions. For example, as well as guessing how many additional environments exist per site, we'd also have to assume how likely it is that each environment is used or visited in a given week--which gets us solidly into the realm of speculation.

Conversely, is there anything we can do to include data for sites that didn't "call home" in a given week? Because data are tracked per install, drupal.org servers probably do have the needed data. For example, that could look like:

  • For sites that (a) haven't sent data in a given week, (b) have reported in non-consecutive weeks at least once in the past year, and (c) did report in one of the prior three weeks, use the most recent data for that site.

That approach would include a few sites past the date they go offline and could report non-current data for some sites, but overall could be useful for filling in missing data.

Summing up

  • Drupal usage data reflect the number of reporting installs, not production sites.
  • Though it still leaves various types of non-production installs such as additional site environments, the best adjustment that can be easily made is removing stats for development releases for future versions.
  • Some sites are missing from the data because they don't have the Update module installed or haven't "called home" in a given week.
  • The ratio of production sites to reported installs is likely lower for Drupal 8+ than for Drupal 7, meaning the falling graph of total core usage would likely be steeper if it captured production sites rather than all installs.

All of the above doesn't in any way mean the usage figures on drupal.org are without value. Just that they're like most statistics--best used with an eye to limitations and context.

Nov 23 2021
Nov 23

At Redfin Solutions, we strive to offer our clients holistic guidance to help them achieve strategic goals and create a long-term vision for their web presence. We also know that sometimes priorities change quickly. A website’s flexibility is as important as scalability, and the stability of centralized web operations shouldn’t come at the expense of limiting stakeholder decisions.

With these ideals in mind, we developed our Delta Site System (DSS) to help clients who have a need to quickly launch and maintain new Drupal websites. DSS gives Redfin’s clients the ability to define a “template” website from which others can quickly be deployed. These new sites can use the same themes (look and feel), modules (enhanced functionality), and configuration (content types and taxonomies), while also allowing for customization at the individual website level.

For large organizations with decentralized governance or a large volume of websites to manage, our Delta Site System is a gamechanger. Let’s take a closer look at how it works and the value it provides.

How the Delta Site System works

To build Delta Sites, we leverage Pantheon’s Custom Upstream technology. In the Pantheon website management platform, an Upstream is a repository that acts as a parent for another repository. When changes are made to code or configuration, updates are pushed downstream, meaning from parent to child. A Custom Upstream is the parent repository for an organization or set of sites. For Redfin’s Delta Sites, it holds an all-inclusive Drupal package custom-built to the needs of each client from which additional websites can be created.

Since each individual website still has its own independent “container” with a development, test, and production environment of its own, additional customizations can be made on the site level without affecting other sites. However, when important updates need to be made across the board, changes can be pushed to all sites without causing conflicts.

The diagram below helps explain the workflow.

Redfin Solutions Delta Site System custom toolkit: Drupal Core CMS, content management paradigm, common components and content types, and styles and brand identyRedfin Solutions Delta Site System custom toolkit: Drupal Core CMS, content management paradigm, common components and content types, and styles and brand identy

Reaping the benefits of the Delta Site System

So, how is this a game changer? Redfin’s Delta Site System fills the gap between flexibility and scalability that’s been historically hard to bridge by embracing the push and pull of cohesion and agility. 

Every Delta Site System we build for a client is customized for their specific needs and defined in Redfin’s discovery process with the client—so there’s no cookie cutter site cloning. However, our DSS clients will reap some of the benefits across the board.

Maintain standards across multiple websites

With a Delta Site System in place, it’s easy for a client to determine which standards need to be maintained between their multiple sites and to ensure these standards are adhered to. For instance, it might be important that certain taxonomies are consistent from site to site so that content is organized in a similar fashion. Or maybe the standards are more stylistic, with items like menus, color palettes, and visual components remaining consistent across each site. Of course, security and technical standards are always maintained across every web property.

Provide flexibility to individual website stakeholders

At the same time, a custom-built Delta Site System allows for greater flexibility on individual websites because new functionality and features can be added without impacting other sites in the system. For instance, Redfin built a front-end paradigm using Bootstrap Paragraphs for a client with in-house knowledge of CSS, giving them near-infinite flexible layouts to use on dozens of distinct websites in their purview. For other clients using DSS, the flexibility to use custom features on certain websites helps prevent content editors on other sites from getting bogged down in irrelevant options, leading to streamlined publishing.

Reduce time spent managing web properties

Some of our clients have the bandwidth and desire to build new sites entirely on their own. Others rely on Redfin to help implement each Delta site. Either way, the Delta Site System reduces time and resources spent on managing feature and security updates on disconnected web properties and frees up developer time for building new features and components.

Re-use favorite components and features

Speaking of time savers, once an element is added to a website in a Delta Site System, Redfin can add it to a client’s custom upstream to apply it to any and all sites in the system. That means there’s no need to reinvent the wheel for every custom site request. For example, one of our clients has a Delta site with a content carousel feature enabled. If the feature becomes relevant for another one of their sites later on, DSS allows them to easily add it in, without spending extra money to develop the feature.

Content carousel exampleContent carousel exampleThis content carousel is an example of a custom-built element for one of our clients. It is one of a large collection of elements they can use to build layouts.

Make website management more accessible

Because launching a Delta Site doesn’t require advanced technical knowledge and making a mistake on one website doesn’t affect another, the Delta Site System expands the scope of who can administer websites. Rather than relying on one person or department for all website changes, more team members can be involved in the process, which can simplify workflows, give more folks access to web publishing, and reduce red tape for large organizations.

Use case: Dartmouth College

When Redfin began working with Dartmouth College’s Advancement Division in 2019, the Dartmouth team was facing a challenge. In addition to their main web property the Alumni Relations website, they’d collected several other websites over the years, and each one was built using an entirely different paradigm. Moreover, the need for new websites—for campaigns, conferences, and events—was now increasing.


Redfin created a custom Delta Site System for Dartmouth that hosts their current websites and allows for the easy creation of new ones. Redfin built a custom collection of Paragraphs (or components) with elements such as accordions, carousels, and hero images. Then, using Bootstrap Paragraphs, Dartmouth site editors can apply Bootstrap classes to their Paragraphs to further customize the layout of a page.

Four similar, but separate examples of Dartmouth College Delta SitesFour similar, but separate examples of Dartmouth College Delta SitesWith the Delta Site System, Dartmouth is quickly able to spin up sites for events, conferences, and new initiatives.

Redfin’s Delta Site System has helped Dartmouth cut down on the time spent managing and standardizing ad-hoc websites while simultaneously giving more freedom to site administrators and editors.

Get started with the Delta Site System

The first step to getting started with the Delta Site System—or to see if it’s the right fit for your organization—is a consultation with a member of our team. Reach out today to speak with Redfin Solutions about how we can help you define your web goals and make them a reality.

Nov 23 2021
Nov 23

Good Drupal leadership begins with a good plan. A good plan requires a vision specific to its particular business. Drupal, like any software, is a tool that empowers an organization to build its vision and address its business requirements. The fact that a Drupal website/application consists of Drupal core, with contributed modules and themes, that are glued together using custom code, creates a unique set of challenges to ensure each aspect is done right.

Nov 23 2021
Nov 23

The power of Drupal lies with its modules. With thousands of core and contributed Drupal modules to choose from, Drupal developers can easily implement ones that meet their needs. But what if the requirements are very specific and you don’t have a module available for it? How can you customize a Drupal website for a client who has unique needs that just cannot be accomplished with core or contributed modules? Enter Custom modules.

Custom modules in Drupal 9 give you the flexibility to create new features and/or tweak existing features to accommodate a business’ unique and growing aspirations. Drupal custom modules propels innovation and enhancements to help enterprises expand their horizons. This article should help you get started with creating your very own Drupal 9 module

Drupal 8 has now reached EOL. Now is the time to migrate to Drupal 9. However, if you're still trying your hands out at creating a custom module in Drupal 8, these steps will work for a Drupal 8 setup too. 

Drupal9 Custom Module

Getting started with Module development in Drupal 9

Let’s now get started with creating a custom module in Drupal 9 in a few easy steps:

Step 1: Name the Drupal 9 Module

First, we need to create a custom module under ‘web/modules/custom’ folder. We will name the folder as welcome_module.

module development


Some things that you should keep in mind before giving a machine name to your module are:

  • It should not start with uppercase letters.
  • There should not be any spaces between the words.

Step 2: Get noticed with the info.yml file

We have to create a yaml file with the machine name of our module for Drupal to be able recognize the module. I’ll create a yaml file like this welcome_module.info.yml.
Here is our welcome_module.info.yml file created under "welcome" directory we created in Step 1.

name: Welcome Module
type: module
description: 'First Custom Drupal 9 Module.'
package: Custom
version: 1.0
core_version_requirement: ^8 || ^9

name: Welcome Module (The name displayed on the modules list in Drupal) 
type: module - (Declaring that this is a module or theme) 
description: Custom Example Drupal 9 Module (Description of the module) 
package: Custom - (Mentioning that this is a custom module) 
version: 1.0 - (Module version) 
core_version_requirement: ^8 || ^9 - (Drupal version)

Step 3: Creating the routing file with routing.yml

Next step is to add a welcome_module.routing.yml file under the "welcome" directory:

welcome_module.welcome:
  path: '/welcome/page'
  defaults:
    _controller: '\Drupal\welcome_module\Controller
\WelcomeController::welcome'
    _title: 'Welcome to My Module in Drupal 9'
  requirements: 
    _permission: 'access content'

The first line is the route name [welcome_module.my_welcome].
Under path, we specify the URL path we want this route to register. This is the URL to the route.
Under defaults, we have two things: the _controller which references a method on the WelcomeController class and the default page title (_title).
Under requirements, we specify the permission of the accessing. User needs to have to be able to view the page.

Step 4: Adding a Controller 

Create a folder "modules/custom/welcome_module/src/Controller". In this folder, create a file named "WelcomeController.php" with the following content:

 'Welcome to our Website.'
    );
  }
}


Now Login to your Drupal site and enable your module. To check if it functions properly, visit the path you specified in your routing file, that is /welcome/page. If you get the ‘Page Not Found’ error, then clear the cache by navigating to admin->configuration->performance. Check again and it should function properly this time.

Welcome to Drupal 9 module pageController page

That’s it! You’ve successfully created your very first custom module in Drupal 9.
Finally, when you go to /welcome/page URL, you'll see Title “Welcome to My Module in Drupal 9" and markup “Welcome to our Website." text printed from your module.

Nov 22 2021
Nov 22

When designing, developing, and migrating a large county site that incorporates more than 40 separate sites into one Drupal codebase using core muti-site features, it can be expected that some individual site owners will have particular requirements that pose distinct challenges.

One such condition emerged for us at Promet Source earlier this year during a Drupal migration project for the Orange County, Calif., website

The OC Animal Care site needed to use the new Drupal multisite platform for their main site, but they managed an external non-Drupal site as well, that they heavily link to for pet adoptions in Orange County. This site needed to remain on its existing server, and not migrate over to the Drupal CMS platform that Orange County’s other sites were moving onto. 

A consistent aesthetic and user experience was an essential objective for all of the Orange County properties. Promet had designed a coherent style and navigation menus for the Orange County websites, and allowing one of the sites to appear as an outlier with different navigation and an unrelated look and feel was far from optimal. 

On the other hand, requiring the owners of the external pet adoption site to redo their site to mimic the headers, footers, navigation and design style of the new Orange County site, would have required dozens of costly developer hours for another firm, without a guarantee that the this external site would have would ended up with a user experience that effectively aligned with the OC Animal Care main site or the other 40 Orange County sites.

The Tome module proved to be the solution. 
 

How We Used the Tome Module

Leveraging the Tome module, we were able to deliver a package of CSS, Javascript, image assets and static HTML markup, in a Zip file that grabbed the new OC Animal Care theme and its current menu. From this Zip file, OC Animal Care was able to easily load content into a new template for the pet adoption site that was in complete alignment with ocpetinfo.com and ensured a consistent user experience.

Orange County animal care home pageOC Animal Care site (https://www.ocpetinfo.com)

 

OC Adopt a pet screen shotDespite remaining as a static site on a separate server, the OC Animal Care Pet Adoption site (http://petadoption.ocpetinfo.com) closely aligns with the OC Animal Care site, allowing for a consistent user experience with a familiar navigation and menu structure.
 


Tome at Work

In addition to vastly simplifying development, use of the Tome module has established a framework that will streamline management of this static site template moving forward. Any time that OC Animal Care site owners need to get the latest menu from the OC Animal Care site and reload it over to the OC Animal Care Pet Adoption site, a few clicks are all that will be needed to create an updated Zip file. The users simply login to the OC Animal Care site, go to a menu item available to admins and click a button to have the site build out this new Zip file. 

Effectively using the Tome module for our purposes developmentally was simply a matter of:

  • Creating a new route that would display an empty page;
  • Creating a new custom Tome download and export command that extended the default commands to only save this one new custom empty page to the static directory;
  • Altering the export process a bit to fix a few small issues we had with making sure the links and images and css were all relative to our static file structure and displaying correctly.


Screenshot from the Tome module

Innovative Workaround

Most often, the Tome module is leveraged to migrate an entire dynamic site onto a static site. The Orange County migration posed a slightly different challenge with the need to seamlessly incorporate one static site into a dynamic, 41-site Drupal CMS, without any disruption to the user experience or design language. 

Looking to leverage the vast array of Drupal capabilities to meet a complex objective for your website? That’s what we do! Let us know how we can help. 
 

Nov 22 2021
Nov 22

There is a common misconception that large open source projects are well-funded. In practice, many rely on a small group of maintainers.

The PHP programming language is one of them. Despite being used by 75%+ of the web, PHP only has a few full-time contributors.

That is why the PHP Foundation is launching. Its mission: The PHP Foundation will be a non-profit organization whose mission is to ensure the long life and prosperity of the PHP language..

Acquia is proud to support the PHP Foundation by contributing $25,000 to the foundation, alongside Automattic, JetBrains, Laravel and others. Our donations will help fund the development of PHP.

PHP is vital to the functioning of governments, schools, non-profits, private companies, public companies, and much more. If your organization relies on PHP, I'd encourage you to make a contribution.

Large open source projects like PHP need meaningful, long-term support. I remain very passionate about how to make Open Source production more sustainable, more fair, more egalitarian, and more cooperative. It will be interesting to see how the PHP Foundation develops.

Nov 22 2021
Nov 22

Today we are talking about Camp Planning with April Sides.

TalkingDrupal.com/322

Topics

  • Can you tell us about Drupal Camp Asheville?
  • Why is camp planning “Your Jam”?
  • How do you think virtual events have impacted camps?
  • Do you think we will get back to In-person camps in 2022?
  • What are your thoughts on hybrid camp formats in the future?
  • What is neurodiverse inclusion?
  • Why is it important for events and the Drupal community?
  • What is your favorite aspect of camp planning?
  • Biggest challenge
  • Biggest Success
  • Tips for starting a new camp
  • How to help with an existing camp

Resources

Drive by Daniel Pink
Notist - John
Notiat - April
Event Organizers Working Group
Event Accessibility Playbook
Drupal Camp Asheville
Drupal Camp Asheville Project
Asheville Twitter

Hosts

Nic Laflin - www.nLighteneddevelopment.com @nicxvan
John Picozzi - www.epam.com @johnpicozzi
April Sides - @weekbeforenext

Module of the Week

DropzoneJS
Drupal integration for DropzoneJS - an open source library that provides drag’n’drop file uploads with image previews.

Nov 22 2021
Nov 22

Today, there are a bazillion options available for us to choose from, be it restaurants, clothing brands, gadgets or software. We, as users, may have difficulty in choosing the best, but never in finding the options. The options may confuse us, but we are going to be bombarded with them nonetheless. 

This brings me to the question of choosing the right option amongst the lot; how is it selected? For me, one of the most important criteria is usability, if I am not able to understand the usage of a product, I’d rather choose the next one. I am sure usability must be an important factor in your decision as well. 

Now, coming onto the product that I would be talking about today, Drupal. It is one of the most renowned open source content management systems out there. If you are reading this blog, you would definitely be aware of Drupal and all of its brilliance. Despite its eminence and versatility, it is still marred by a slightly unjustified rumour based on its use. Yes, as the title suggests, Drupal is often considered difficult to use and as a result many shy away from using it. 

Today, we will try to understand all the aspects of Drupal that could account for this claim and see if it is really true. Can a software that is meant to be free for anyone to use be so difficult that it become inaccessible to a major lot of its audience? What would be the point of it then? You think about that while I begin with the individual of Drupal’s so-called complexities. 

A Glimpse at Drupal’s Market Share 

Drupal is one of the leading CMSs in the market. Its ability to build powerful web experiences is the paramount reason for the same. So before I get into the nitty gritty details of Drupal's ease of use, I wanted to highlight its popularity. 

A line graph is showing Drupal usage statistics. Source: BuiltWithA table is showing the number of sites using Drupal at different points of time.Source: Drupal.org 

These numbers clearly show that Drupal is being used by a considerable number of sites worldwide with as many as a million Drupal sites operational at one time. This proves the answer to the question ‘Is Drupal in demand’ is going to be an affirmative.

A graph shows how many sites use Drupal in comparison with other CMSs.Source: W3TechThere is a list of the most high traffic sites using Drupal.Source: SimilarTech

Is Drupal still relevant? I’d say it is primarily because it isn’t just the numbers that make Drupal impressive, but its performance as well. The above images depicts Drupal’s competency at handling high-traffic sites. Drupal is a software for which millions of visitors aren't daunting as proven by its clientele.

Two pie charts are showing various changes in business and projects handles by it.Source: Drupal.org 

Moreover, in a survey to understand 2021’s business outlook, Drupal found out that the majority of its users felt that the new year would mark a growth in their prospects. With Drupal’s presence in a wide range of industries, the profitability of the CMS is impressive too. Sectors like education, charities and nonprofits, government, IT and even media have experienced more profits with Drupal as per the findings of Drupal Business Survey 2020

Drupal has proven its worth in every aspect, be it the number or the performance. The only thing that mars its impeccable record is that it is difficult to use, which isn’t technically the case. I’ll start answering the why with the next section.

Let’s move on to the programming language 

PHP or Hypertext Preprocessor is the programming language Drupal is built on. And PHP is a language that is often considered to be part of its complexity. I would say that it is not accurate. 

PHP is one of the best programming languages and has landed itself in the top 10 best languages to learn in 2021 by many surveys; Simplilearn and Hackr.io are two of these reports. With that kind of efficacy, the language cannot be considered to be problematic.  

Further proof of PHP’s popularity is in the number of websites and applications that use it, which isn’t a lowly figure. Look at the graph below for proof. 

A graph is showing the popularity of various programming languages.Source: W3techs

And these reports and figures aren’t antiquated, rather are as new as the year itself. So, PHP must be a worthwhile language, even if it isn’t the easiest of them all. 

However, PHP isn’t the only language Drupal works with. It has other dependencies as well. These include; 

Symfony; 
Twig; 
CKEditor; 
jQuery and jQuery UI. 

All of these only mean that Drupal is versatile, it isn’t a software with one side. Its multifaceted programming aspects only add to its appeal. It may seem like a lot at first, but it is necessary and doesn’t add up to Drupal’s difficulties, rather it eases the task of web development.

Moving on to the beginner’s conundrum 

When we start something, more often than not, we feel overwhelmed with it. Since we are not accustomed to the newness and it’s nuances, that is understandable. And Drupal ensures that it takes into consideration the novice developers. 

Until Drupal 8, beginners have reported difficulties with the installation and evaluation of Drupal. But after the release of the eighth version, things are more streamlined with the beginner’s needs and expertise. 

Drupal has also brought on new themes to make its experience more flattering for the beginners. For example:

Umami in Drupal 8.6 
Claro in Drupal 8.8 
And Olivero as an experiment in Drupal 9.1

All three themes have made Drupal more accessible, responsive and simple for its users, if we are to rely on user feedback. If I talk about Olivero specifically, it is the new beta experimental frontend theme, which is both modern and concise, and will take over Bartik as Drupal default theme. Its simplicity and professional look make it a perfect pair for beginners.  

With Drupal 9, there isn’t much that has changed. If you are comfortable with Drupal 8, you would be able to ease into the 9th version with a breeze. Although there are indeed differences between Drupal 8 and 9, these are not as stark and have made development not seem like a daunting task. 

And there is more. 

The Drupal Community, always helping out!

Drupal has a community of over 1 million people and 100,000+ stories to tell. From putting your skills at work to acquiring new skills to work, the Drupal community is known for upliftment of the software and the people using it. 

Any questions a beginner may have will be rightfully answered. You can easily find mentors, who are Drupal veterans and will gleefully help you become an expert like them. You can practise, practise and practise some more to get to the level you want to be at. Being part of the Drupal community, you will be able to hone your skills unlike anywhere else. 

You would not feel like an outsider, meet people with similar interests and similar geography as you at Drupal Groups. Since the best way to learn Drupal or anything really is to be immersed in it, the Drupal community is just the place for learning and mastering.

And, there is a constant endeavour to help underrepresented groups from the Drupal Community. Diversity, inclusion and equity is at the heart of the community.

So, there isn’t much room for the beginner’s conundrum at Drupal.

Then there are the notorious Drupal upgrades

Upgrades are necessary, but they don’t necessarily have to be an insurmountable task, which frankly speaking was the case for Drupal. Upgrading till Drupal 8 could not be described as being easy and quick. They required a lot of work and it was difficult, as there were major fundamental changes in the software. However, there was no other way to go about it. If you wanted the added functionality and support that new version would have, upgrading was the only choice.

However, that isn’t the case now and thank goodness for that. 

With the launch of Drupal 9, upgrades have become less notorious and more accommodating. The Drupal 9 switch has been deemed as the easiest upgrade of the decade and that is saying something. This is because unlike previous upgrades, Drupal 9 does not change the entire CMS on a fundamental level, there is no reinvention, but it is still unique. It is a new and improved version of Drupal 8, with deprecated APIs and updated dependencies.

Here is an illustration that will help you understand what I have been saying about fundamental changes.

Different train tracks are used to describe the difference between various Drupal versions.Source: Drupal.org 

With a four step process, you can make your Drupal 8 sites ready and waiting to be upgraded into Drupal 9, if that is difficult, I wonder which adjective would be appropriate for the previous ones. You can also directly upgrade from Drupal 7, if you wish to. Access this complete guide to Drupal 9 to know everything about Drupal 9 upgrade and migration.

Yes, Drupal upgrades were difficult, but they aren’t now. So, does this fact make this pointer for Drupal moot? I think it does.

Coming on to the workflow 

For content management systems, content is the integral. The way it is created and managed essentially decides whether the life of developers and content creators is going to be easy or not. If you are using Drupal correctly, I can assure you life is going to be a breeze.

I say this because in terms of editorial workflow, Drupal has a lot to offer and not much is complicated, with structured tools equipped to define the same.

Here is an overview of some of them.

Workspaces is one tool that helps in defining the staging environments, previewing content changes, all the while deploying these to a live environment.

Transitions is another tool that makes it easy to control content States, which have their own attributes. It allows state changes to become restricted by roles and permissions along with allowing users what content to be put through them.

Then, there is the eminent Views module. This is one unique to Drupal and its highlighting feature in terms of content. It gives the power of creating, managing and displaying lists of content to administrators and site designers. It is these lists that are called views, while what the portray in the form of blocks or pages is the display, it can be one or many.

A screenshot of Drupal's Views module can be seen.Source: Drupal.org 

One of Drupal’s most fulfilling editorial tools is the Layout Builder. It allows editors to create a publishing piece that is more than flexible to their needs. Any kind of layout is possible with this module.  
 
All of these support the editorial needs of the many content authors who will be populating a platform and the better part is they would not need the guidance of the developers every of the way or any at all.

The new-age of Headless CMSs 

As times change, the things that satiated our needs no longer do so. The same is true for CMSs. Looking back, it is evident that site builders and developers were quite satisfied with nestling an entire project inside one CMS, which would have acted as the provider of the frontend and the backend needs. However, with the advent of multitudinous frontend technologies, that satiation is no longer achievable. 

Hence, the new-age of CMSs emerged, which is essentially without a head, that is the presentation. Unlike the monolithic architecture, the headless approach separates the frontend development from the backend, making the developers happy by leveraging other technologies.

Drupal is a pro at the headless approach. Its monolithic architecture is also used by sites with simpler needs, however, it does give them the option to decouple or go headless, if they wanted to. 

  • You could choose to decouple partially, this would be the progressively decoupled approach
  • You could choose to go all the way, with the fully decoupled approach with JavaScript framework of your preference taking care of the frontend or you could choose static site generators as your frontend.

Be it React, Angular, VueGatsby or Metalsmith, Drupal can work with all of the major frontend technologies and make the project a success with it acting as the content repository.

Drupal’s work isn’t finished yet, it also provides robust APIs to streamline the connection between the presentation and the content layer. Built on the API-first approach, Drupal offers all of its application functions as APIs. This is done through its web services including RESTful web services and JSON:API along with API extensions with GraphQL

Drupal can create its own flexible and structured presentation layer, there isn’t a doubt in it. Regardless of this, when it is decoupled, it performs with equal efficiency to create API endpoints, which basically make room for content consumption and display in the headless application.

And this new-age of CMSs is gaining ground each day, and Drupal, with its own web services at play, is making the transition quite easy.

Fusion with Emerging technologies

I mentioned in the previous section that with time things change and so does their to us. Today, technology is a major part of that change. I remember a time not long ago, when a single camera setup on our smartphones was enough for us. Now, my phone has three, still I envy my husband, whose smartphone has a quad camera setup. Who could have imagined that? 

The same is true for CMSs, when we look at them, we don’t just want a simple site building tool. We want innovations, enhancements and upgrades that will stun us in the most positive way. And CMSs have started providing that. 

Taking Drupal into focus, it has had a revolutionary impact on the market by integrating itself with futuristic technologies.

Drupal has proven to be both reliable and reaching in its fusion with emerging technologies and that has led to an improved digital experience, both for the developers and the users. Read our blog Unleashing macro trends in technology with Drupal to find more about this topic.

It all comes down to continuous improvement in focus

A horizontal bar graph shows the various reasons people opted for Drupal.Reasons for people choosing Drupal. Source: Drupal Business Survey 2020 

The most common reason for people using Drupal is because they have already used it and because of that familiarity, it becomes easy to use. However, ease of use is not amongst the top reasons for taking up Drupal. 

Probably that is why, when Drupal 10’s 2022 release was announced during DrupalCon Global in 2020 by Dries Buytaert, its ease-of-use was addressed as one of the most impactful aspects. And Drupal 10’s development is proof of that.

In Dries speech, he emphasised the ease of use quite a lot. He talked about five crucial steps that were taken to simplify Drupal even more. 

  • Improving third party components even after their EOL to enhance Drupal 10 readiness; 
  • Improving Drupal’s ease-of-use further, Drupal 9 was a great step in this direction;
  • Improving frontend themes; 
  • Improving updates by making them automates, this would work best for security upgrades; 
  • Improving on Drupal technology by implementing JavaScript components in the UI. 

For all of these, the efforts are being made by the entire community. 

Yes, it would be faster, better and more innovative, but it would not be difficult. Like I mentioned before in this blog, we should not expect many overhauls to the software that would make our eyes pop and heads hurt. 

There are going to be improvements, there would at least by four versions of Drupal 9 before the arrival of 10. However, this continuity in advancements does not have to affect the way Drupal is seen by its users. It needn’t be the forbidden fruit that everybody wants to taste, but scared to do so. Drupal is an open source software, it is meant for everyone and that means it isn't too difficult. I wouldn’t deny that wasn’t complex at one point, but that point of time is long gone. What lies in the future is a version of Drupal that is as easy to use for a beginner as it is for an expert developer.

The Bottom Line 

I’d like to answer the question ‘How hard is it to use Drupal?’ with a direct from one of our developers.

“Being from a technical background and having PHP development experience before diving into Drupal gives me an upper edge during the journey. Being into Drupal development for around 3 years, I can say it’s all about learning the architecture of Drupal (such as entities, configs and forms) and how the code executes (sequence of functions calls). The earlier you understand these, the easier the Drupal journey would be for you and it would help you to debug faster and select the best approach for the requirements. Plus having a great community and open contribution platform helps you learn better and faster. Drupal is like a Lego, you can build it to your liking but, at a certain point of customisation, it is like a box with thousands of pieces and not all of them fit together.” - Anmol Goel, Senior Software developer at OpenSense Labs

For Anmol, Drupal experience made the journey easier. It requires you to get a hang of things, once you do that, there isn’t much that you’d find difficult, and your Drupal development experience would be a walk in the park; at least most of the time. And like he put it so eloquently, who could find a game of Lego difficult? All it is about is building something new every time, be it today or tomorrow and that’s Drupal for you.

Nov 22 2021
Nov 22

The Drupal commerce ecosystem, and especially architecture, is both rich and flexible enough to allow us to create some really powerful things. Much comes out of the box that, with a few bits of tweaking here and there, makes our web-shop ready for shipping. Boy…do I love a good pun.

But even more, the architecture that heavily relies on plugins makes it so that when that is not enough, we can quickly write our own bits of integrating code to deliver those missing pieces. So, about such an example I want to talk about today, namely, how we can create a promotion that, when buyers are eligible, will ensure the shipping price does not go over a specific amount. Imagine the following use cases:

  • you have a shipping service with a flat rate in your country but varying rates in other countries, or
  • you have a temporary offer by which you want to knock down all shipping costs to a certain amount, or
  • you have coupons that entitle some users to a given shipping rate.

Of course, the main premise here is that your shipping costs are variable and depend on the things people buy (such as weight and stuff). Because otherwise I can immediately refer you back up to all the things Drupal commerce can do out of the box. Namely, creating an offer type that reduces the shipping rate by either a percentage amount or by a fixed amount:

Today, however, what we are interested in is an offer type that ensures that the shipping cost doesn’t go higher than a certain value. Something like this:

So, if you check in your current Drupal commerce installation, the offer type from the screenshot above doesn’t exist yet. But, it’s easy to create. So let’s get to it.

First, a little bit of theory.

The promotion offer plugins implement PromotionOfferInterface with its most important method: apply(). The latter is responsible for taking an entity and applying the offer onto it. Shocker. I highly recommend you check out the code for all the existing ones and find inspiration from there. Always the best source to learn from.

Typically, promotion offers are applied to something. For example, shipment costs, the order total as a whole, individual order item prices, etc. So for this reason, we also have interfaces and base classes for the plugins that deal specifically with a type of offer “target”. For example, we have OrderPromotionOfferInterface and it’s corresponding OrderPromotionOfferBase that deal with orders. We also have similar for order items, some others, but finally, what we care about is the ShipmentPromotionOfferInterface and ShipmentPromotionOfferBase, which we will be using.

The reason for these base classes is to provide some specific logic that deals with the type of offer “target”. For instance, when dealing with shipping, we can condition the plugin to a given shipping method. So the base class takes care of the form and that logic already for us. All the plugin has to do is handle the actual offer application and potentially the configuration form for it (as needed).

OK, now that we have a bit of background on where in the code we need to look for inspiration, let’s create our own plugin called ShipmentFixedAmount, which will extend from ShipmentPromotionOfferBase. And we start with the plugin annotation:

/**
 * Sets the shipment amount to a fixed value.
 *
 * @CommercePromotionOffer(
 *   id = "shipment_fixed_amount",
 *   label = @Translation("Maximum amount on the shipment"),
 *   entity_type = "commerce_order"
 * )
 */
class ShipmentFixedAmount extends ShipmentPromotionOfferBase {

Nothing major here, except maybe the confusing entity_type key where we specify the type of entity we want passed to the apply() method of our plugin. We won’t actually deal with the latter because the parent class will do so. But we do want the commerce_order entity there. Instead, we have an applyToShipment() method called by the parent class and which gives us the shipment entity to apply the offer onto. Check out the ShipmentPromotionOfferBase::apply() method to better understand how this works.

Next up, we need a configuration form whereby the user can specify what is the amount to max out the shipping cost at. Drupal commerce comes with some traits that could help with this, but in our case don’t. But you should check out some of them for future reference, as you may be able to use them directly: FixedAmountOffTrait, PercentageOffTrait and the like. But alas, our form will have some different wording so we need to recreate it. Not a biggie, and here are the first few methods of our plugin, specifically that deal with this configuration of the amount by the site manager:

  /**
   * {@inheritdoc}
   */
  public function defaultConfiguration() {
    return [
        'amount' => NULL,
      ] + parent::defaultConfiguration();
  }

  /**
   * {@inheritdoc}
   */
  public function buildConfigurationForm(array $form, FormStateInterface $form_state) {
    $form = parent::buildConfigurationForm($form, $form_state);

    $amount = $this->configuration['amount'];
    // A bug in the plugin_select form element causes $amount to be incomplete.
    if (isset($amount) && !isset($amount['number'], $amount['currency_code'])) {
      $amount = NULL;
    }

    $form['amount'] = [
      '#type' => 'commerce_price',
      '#title' => $this->t('Maximum amount'),
      '#default_value' => $amount,
      '#required' => TRUE,
      '#weight' => -1,
    ];

    return $form;
  }

  /**
   * {@inheritdoc}
   */
  public function submitConfigurationForm(array &$form, FormStateInterface $form_state) {
    parent::submitConfigurationForm($form, $form_state);

    if (!$form_state->getErrors()) {
      $values = $form_state->getValue($form['#parents']);
      $this->configuration['amount'] = $values['amount'];
    }
  }

  /**
   * Gets the offer amount.
   *
   * @return \Drupal\commerce_price\Price|null
   *   The amount, or NULL if unknown.
   */
  protected function getAmount() {
    if (!empty($this->configuration['amount'])) {
      $amount = $this->configuration['amount'];
      return new Price($amount['number'], $amount['currency_code']);
    }
  }

Apart from getAmount() which is a simple helper, the rest are implementations of the configurable plugin interface with which we should be a bit familiar already. And you can see that it’s very similar to FixedAmountOffTrait.

Finally, for the actual business logic, we need to implement the applyToShipment() method to apply our offer to the shipment found in the order:

  /**
   * {@inheritdoc}
   */
  public function applyToShipment(ShipmentInterface $shipment, PromotionInterface $promotion) {
    $amount = $this->getAmount();
    if ($amount->getCurrencyCode() != $shipment->getAmount()->getCurrencyCode()) {
      return;
    }

    $current_amount = $shipment->getAdjustedAmount();
    if ($current_amount->lessThanOrEqual($amount)) {
      // If it's already the same amount, do nothing.
      return;
    }

    // Calculate the amount that needs to be subtracted.
    $to_subtract = $current_amount->subtract($amount);

    $shipment->addAdjustment(new Adjustment([
      'type' => 'shipping_promotion',
      'label' => $promotion->getDisplayName() ?: $this->t('Discount'),
      'amount' => $to_subtract->multiply('-1'),
      'source_id' => $promotion->id(),
      'included' => $this->isDisplayInclusive(),
    ]));
  }

So what is going on here?

As you can see we get an instance of the $shipment object onto which we need to set an Adjustment. This is the Commerce way of applying changes to amounts so that they can then be calculated together later (and broken back out if needed).

First we check that the currency is the same as the one on the shipment. We don’t want to deal with currency conversions here. We return if not. Then we quickly check if the actual shipment amount is not already smaller or the same as the one we configured. If it is, again, we return without doing anything. Nothing left to do right?

And finally, we perform the big operation: we determine the difference between the shipping amount and the configured one, so that we know how much we need to subtract. And we do so by adding an adjustment to the shipping (in the negative, hence the $to_subtract->multiply('-1')). And that’s it.

After a good ol’ fashion cache clear, you can create a Promotion using this new offer type, just like in the screenshot above. And when users are eligible to this promotion, they will see a discount on their order equal to the difference between the real shipping amount of their order and the maximum we want to limit this amount to via the promotion. So if the shipping normally costs 10 EUR, but you configured the offer to max out the cost at 7 EUR, users will see a discount of 3 EUR on their order checkout. Which effectively gives them a total cost of 7 EUR on their order.

Phew, long story, but I bet you’ll write this code up in 5 minutes now that you know how and understand where to look.

Hope this helps.

Nov 21 2021
Nov 21

I'm not a fan of the summary option on body fields in Drupal. I've never really got on with how users interact with it or the content is produces.

The field type I'm talking about is called "Text (formatted, long, with summary)" and it appears as an add-on summary field to a normal content editor area. It comes as standard on Drupal installs and appears on all body fields. The field type has it's uses, but I often find that the content it produces is unpredictable and doesn't have a great editing experience. I have even written articles in the past about swapping the summary field to a fully fledged wysiwyg area for Drupal 7, which worked on the project I implemented it on.

Let's look at the body summary field in Drupal and see why I have a few problems with it.

The Body Summary

If you create a new content type in Drupal you will automatically get a body field. This field will always be a "Text (formatted, long, with summary) and will have a machine name of "body". This is unlike most other fields in Drupal which get a prefix of "field_" to the field machine name. You can also create your own fields with of the same type as the default body field.

The field footprint looks like this in the field management page of the content type.

Drupal node body field, showing the description of the body field.

When editing or creating a page of content the body field is shown like this.

Drupal node body field, showing the collapsed summary field.

Clicking on "Edit summary" will show the summary of the field, allowing users to enter text into it.

Drupal node body field, showing the expanded summary field.

The problem is that if you enter content into the summary it doesn't get treated as markup because the summary isn't a markup field. Users with the ability to do so can enter raw HTML into the summary, but it will just be stripped out as the field is passed through the standard twig output filters. You can allow users to bypass this, but that poses a security risk as no input filter is applied to the output at all.

If you don't enter content into the summary field it then the beginning of the body field is used as the summary, with the markup intact. This can be controlled through the break element, but that feature isn't commonly used on most Drupal sites I have seen in the last few years.

This mix of content makes the summary unpredictable and difficult to work with. You can get around some of these inconsistencies by simply wrapping the summary field in paragraph tags when it is rendered on the front end, but this creates a unique situation where the summary doesn't act in the same way as normal fields. Users will often want to add markup to the summary since the body field contains that markup and they will expect to be able to add links or bold tags to it. The body summary field will quite often be the focus of support requests to allow it to produce HTML output or even be a normal wysiwyg area.

A much better way of capturing the summary is to create a secondary field called Summary that is a "Text (formatted, long)" field type. This allows users to enter rich content into both the body field and the summary field and is a standard formatted text field (without any summary option). The same field (with the same machine name) can be found in the Umami demo install profile.

Drupal node summary field, showing the description of the field.

With this new Summary field in place we also need to setup the content display so that the summary field is displayed in full on the teaser display mode. Since we don't want the summary field to be too long we can also include the Drupal Maxlength module that will restrict the amount of characters that can be entered into the content. We now have much better control over what is considered the summary of the page and it is much more predictable.

We also need to prevent users from entering copy into the body summary, since that copy will never be presented anywhere. Let's look at a couple of ways to remove the summary from the body field.

Solution 1: Turn Off The Summary

The simple solution here is to just turn off the summary input. This is easily achieved in Drupal via a checkbox on the field configuration screen, found by clicking the 'edit' button next to the field description on the field management page of the content type.

This is what that option looks like.

Drupal node body, showing the option to remove the summary.

Turning this Summary input setting off prevents users from seeing the summary field and entering content into it as the option to show the summary is no longer present. The database table for the body will still contain the summary field and any data already entered into it is now locked since users can't access the summary input.

The edit page of the content type we changed now looks like this. The body and summary fields are separate fields and we have now turned off the body summary entry.

Drupal node body field, showing the summary and body fields.

Solution 2: Completely Remove The Body Summary

Whilst turning that setting off is fine, I wanted to take this to another level and completely remove the summary from the body field. This essentially means changing the type of field that the body field is defined as, therefore removing the summary option from the field and database table. Finding out how to do this took me down a bit of a rabbit hole in the Drupal field and configuration API, but it turns out that it is perfectly possible.

What I also wanted to do was to take any content that was already in the body summary and copy it into the new Summary field.

I should warn you before going any further that this code can be dangerous! In other words, here be dragons! Running this code without fully understanding it can potentially butcher your site configuration and cause your site to crash and be rendered useless. If you do want to run this code then make sure you have database backups before entering into this process in case anything goes wrong. Changing the type of field is not something to be done lightly, but I was sure that this is something that was needed in order to have the body and summary fields as separate, fully controllable, fields with no option of adding in a summary from the body field.

Let's go through each step one at a time. There is a little bit of code to do through here and the idea is that this is run in an update hook, which I will detail in full at the end.

1) Remove the summary field from the body field storage definition. This setting is tells Drupal what shape the database table for the body field is so by removing the summary field we are effectively changing the shape of the table that Drupal can see. It is kept in the Drupal key/value store so we just fetch it out of there, remove the summary from the table definition, and add the setting back into the key/value storage.

# Load the field schema definition and remove the summary.
$bodyStorageDefinition = \Drupal::keyValue('entity.storage_schema.sql')->get('node.field_schema_data.body');
unset($bodyStorageDefinition['node__body']['fields']['body_summary']);
unset($bodyStorageDefinition['node_revision__body']['fields']['body_summary']);
\Drupal::keyValue('entity.storage_schema.sql')->set('node.field_schema_data.body', $bodyStorageDefinition);

2) Next we need to update the field storage definition to have a type of "text_long" instead of "text_long_summary". This setting is used to tell Drupal what the field looks like when creating new content types so without changing this setting you would end up creating new content types with the summary field. This setting is also kept in the Drupal key/value store, but there is a dedicated API that allows access to change and update this setting.

If you use the key/value API to get this setting it is unserialised into an array of objects and it is not possible to change the type property of the FieldConfig object that stores the body field definition. Using the entity definition update manager perhaps the only way to do this, but is also considered the best practice approach to changing field storage definitions.

# Update the field storage definition.
$manager = \Drupal::entityDefinitionUpdateManager();
$body_storage = $manager->getFieldStorageDefinition('body', 'node');
$new_body_storage = $body_storage->toArray();
$new_body_storage['type'] = 'text_long';

$new_body_storage = \Drupal\field\Entity\FieldStorageConfig::create($new_body_storage);
$new_body_storage->original = $new_body_storage;
$new_body_storage->enforceIsNew(FALSE);
$new_body_storage->save();

3) Set the body field to storage configuration to have a field type of "text_long". This setting is used to connect the body field to the storage system and is closely linked with the entity.storage_schema.sql setting above.

# Set the body field to have a field type of 'text_long', without the summary field.
$config = \Drupal::service('config.factory')->getEditable('field.storage.node.body');
$config->set('type', 'text_long');
$config->save();

4) It is also quite important is to change the field instance setting for every content type that contains a body field. This setting tells Drupal to load the body field as a "text_long" field when creating or editing content. We change this setting by loading the field instance configuration out of Drupal, changing the field type and then saving it. This could be further automated by loading in a list of all of the content types, but I have instead just hard coded the standard Article and Page content types.

# Set the body field instance on the content types that contain the body field to have a type of 'text_long'.
foreach (['article', 'page'] as $content_type) {
  $config = \Drupal::service('config.factory')->getEditable('field.field.node.' . $content_type . '.body');
  $config->set('field_type', 'text_long')->save();
}

5) With the field definition sorted out we now need to copy the content from the body field into the new summary field. This will populate the summary field in the site with content from the body field and mean that there are no gaps in the content. The simplest (and quickest) way to do this is to pull the available data out of the body field using a the database and simply insert it into the relevant data storage tables. There is some logic here to look at the value of the body field and either use the current summary or generate a new one on the fly from the existing markup.

# Load all of the data from the body field.
$database = \Drupal::database();
$result = $database->query("SELECT * FROM {node__body};");

if ($result) {
  # Copy the body_summary field data into the new field_summary value.
  while ($row = $result->fetchAssoc()) {
    if (is_null($row['body_summary']) || trim($row['body_summary']) == '') {
      # There is no summary so create one fom the body copy.
      $summary = text_summary($row['body_value'], $row['body_format'], 1000);
    } else {
      # A summary has been set, so surround it with usable markup.
      $summary = '

' . $row['body_summary'] . '

'; } $placeholders = [ ':bundle' => $row['bundle'], ':deleted' => $row['deleted'], ':entity_id' => $row['entity_id'], ':revision_id' => $row['revision_id'], ':langcode' => $row['langcode'], ':delta' => $row['delta'], ':field_summary_value' => $summary, ':field_summary_format' => $row['body_format'], ]; $database->query('INSERT INTO {node__field_summary} VALUES (:bundle, :deleted, :entity_id, :revision_id, :langcode, :delta, :field_summary_value, :field_summary_format)', $placeholders); $database->query('INSERT INTO {node_revision__field_summary} VALUES (:bundle, :deleted, :entity_id, :revision_id, :langcode, :delta, :field_summary_value, :field_summary_format)', $placeholders); } }

If you have a lot of content on your site then you might want to run this as a batch process as doing so will prevent the code from timing out if there are lots of data to process. This process only took a few seconds on an existing Drupal site with around 800 items of content so it is quite quick.

After running all that code we are left with a field definition that looks like this (without the summary field).

Drupal node body field, showing the field without a summary.

Any new content types that we create will automatically get the same field definition of a body field without the summary option.

The final piece in all of this is the deployment. There's a sort of chicken and egg situation between the new configuration of the site and the update hook we are trying to run. We can't write data to a summary field table that doesn't exist, so we can't run the update hook before importing config. We also can't import the config and create the new Summary field table correctly as it the new body field definition causes a configuration import error. It isn't possible to change the field storage type in the configuration so Drupal will just error when it sees that change.

My normal deployment process runs the update hooks first before importing config, so the update hook therefore needs to create the summary field tables before we can put data into it. I have written about adding config to Drupal in an update hook before, but this is slightly different since it's a field that we need to import from configuration. If we just import it using the \Drupal::service('config.storage') service then the tables are not created so we need an alternative method that will set up the fields correctly.

We can use the entity type manager service from Drupal to create the field storage and instance configuration (and by extension the tables needed for the field) on the fly. The following code will read the new Summary field configuration from the configuration files and write it into Drupal. Doing it this way ensures that the correct tables and configuration is setup for the rest of the code to run.

$config_path = realpath('../config/sync');
$source = new FileStorage($config_path);

// Import the field_summary storage config.
\Drupal::entityTypeManager()->getStorage('field_storage_config')
  ->create($source->read('field.storage.node.field_summary'))
  ->save();

// Import the instance config for the field_summary field.
\Drupal::entityTypeManager()->getStorage('field_config')
  ->create($source->read('field.field.node.article.field_summary'))
  ->save();

Here is the full update hook with all of the needed code added together. This will create the new Summary field, delete the summary option from the body field and populate the new field with content from the body.

/**
 * Transfer body field into body without summary option.
 */
function mymodule_update_9001()
{
  $config_path = realpath('../config/sync');
  $source = new FileStorage($config_path);

  // Import the field_summary storage config.
  \Drupal::entityTypeManager()->getStorage('field_storage_config')
    ->create($source->read('field.storage.node.field_summary'))
    ->save();

  // Import the instance config for the field_summary field.
  \Drupal::entityTypeManager()->getStorage('field_config')
    ->create($source->read('field.field.node.article.field_summary'))
    ->save();

  # Load the field schema definition and remove the summary.
  $bodyStorageDefinition = \Drupal::keyValue('entity.storage_schema.sql')->get('node.field_schema_data.body');
  unset($bodyStorageDefinition['node__body']['fields']['body_summary']);
  unset($bodyStorageDefinition['node_revision__body']['fields']['body_summary']);
  \Drupal::keyValue('entity.storage_schema.sql')->set('node.field_schema_data.body', $bodyStorageDefinition);

  # Update the field storage definition.
  $manager = \Drupal::entityDefinitionUpdateManager();
  $body_storage = $manager->getFieldStorageDefinition('body', 'node');
  $new_body_storage = $body_storage->toArray();
  $new_body_storage['type'] = 'text_long';

  $new_body_storage = \Drupal\field\Entity\FieldStorageConfig::create($new_body_storage);
  $new_body_storage->original = $new_body_storage;
  $new_body_storage->enforceIsNew(FALSE);
  $new_body_storage->save();

  # Set the body field to have a field type of 'text_long', without the summary field.
  $config = \Drupal::service('config.factory')->getEditable('field.storage.node.body');
  $config->set('type', 'text_long');
  $config->save();

  # Set the body field instance on the content types that contain the body field to have a type of 'text_long'.
  foreach (['article', 'page'] as $content_type) {
    $config = \Drupal::service('config.factory')->getEditable('field.field.node.' . $content_type . '.body');
    $config->set('field_type', 'text_long')->save();
  }

  # Load all of the data from the body field.
  $database = \Drupal::database();
  $result = $database->query("SELECT * FROM {node__body};");

  if ($result) {
    # Copy the body_summary field data into the new field_summary value.
    while ($row = $result->fetchAssoc()) {
      if (is_null($row['body_summary']) || trim($row['body_summary']) == '') {
        # There is no summary so create one fom the body copy.
        $summary = text_summary($row['body_value'], $row['body_format'], 1000);
      } else {
        # A summary has been set, so surround it with usable markup.
        $summary = '

' . $row['body_summary'] . '

'; } $placeholders = [ ':bundle' => $row['bundle'], ':deleted' => $row['deleted'], ':entity_id' => $row['entity_id'], ':revision_id' => $row['revision_id'], ':langcode' => $row['langcode'], ':delta' => $row['delta'], ':field_summary_value' => $summary, ':field_summary_format' => $row['body_format'], ]; $database->query('INSERT INTO {node__field_summary} VALUES (:bundle, :deleted, :entity_id, :revision_id, :langcode, :delta, :field_summary_value, :field_summary_format)', $placeholders); $database->query('INSERT INTO {node_revision__field_summary} VALUES (:bundle, :deleted, :entity_id, :revision_id, :langcode, :delta, :field_summary_value, :field_summary_format)', $placeholders); } } }

Finally, since all the data has been moved around we can now delete the original summary field. I've created this as a separate update as the database still contains all of the needed data to get back to the old field type (if needed). As Drupal doesn't know about this field it won't have any problems writing new records to the tables, so leaving it in won't have any negative side effects. By removing the field from the table we essentially have no way to get back so this is more of a destructive action.

function mymodule_update_9002() {
  // Drop the body_summary field from the body and revision tables.
  $database = \Drupal::database();
  $database->query('ALTER TABLE `node__body` DROP `body_summary`');
  $database->query('ALTER TABLE `node_revision__body` DROP `body_summary`');
}

That is essentially it. Through a couple of update hooks the site now has no record of the old body summary and the users are now able to enjoy a rich content area for the summary field. The final touches to this would be to add some descriptive help text to the two fields to help users know where that content will appear and to use the Maxlength module to prevent the new summary field from being too long.

How do you feel about the body summary field? Have you encountered any issues with it in the past? Let us know in the comments.

Nov 17 2021
Nov 17

The Drupal project uses the CKEditor library for WYSIWYG editing. CKEditor has released a security update that impacts Drupal, along with a hotfix for that update.

Vulnerabilities are possible if Drupal is configured to allow use of the CKEditor library for WYSIWYG editing. An attacker that can create or edit content (even without access to CKEditor themselves) may be able to exploit one or more Cross-Site Scripting (XSS) vulnerabilities to target users with access to the WYSIWYG CKEditor, including site admins with privileged access.

For more information, see CKEditor's security advisories:

This advisory is not covered by Drupal Steward.

Nov 17 2021
Nov 17

Lynette has been part of the Drupal community since Drupalcon Brussels in 2006. She comes from a technical support background, from front-line to developer liaison, giving her a strong understanding of the user experience. She took the next step by writing the majority of Drupal's Building Blocks, focused on some of the most popular Drupal modules at the time. From there, she moved on to working as a professional technical writer, spending seven years at Acquia, working with nearly every product offering. As a writer, her mantra is "Make your documentation so good your users never need to call you."

Lynette lives in San Jose, California where she is a knitter, occasionally a brewer, a newly-minted 3D printing enthusiast, and has too many other hobbies. She also homeschools her two children, and has three house cats, two porch cats, and two rabbits.

Nov 17 2021
Nov 17

The Drupal Association welcomes its newly appointed board members to help advance its mission to unite a global open source community to build, secure, and promote Drupal. The Association’s Board of Directors ratified the appointment of four new board members in October, including: Nikhil Deshpande, Rahul Dewan, Nick Veenhof, and Mike Herchel, who was elected for the community-at-large seat. The new board members began their term on 1 November.

“It’s exciting to welcome our four new directors – Nikhil Deshpande, Rahul Dewan, Mike Herchel and Nick Veenhof – who together bring such varied experience and expertise to our strategic work to drive Drupal innovation, foster diverse talent, and support Drupal Makers,” said Audra Martin Merrick, Drupal Association Board Chair. “Governments around the world are utilizing Drupal to serve their communities in amazing ways, and having Nikhil’s voice as a government CTO and open source leader will be invaluable in expanding awareness on what is possible. Rahul brings a terrific entrepreneurial spirit to our board. I know his varied strategy and finance experience, as well as his organizing work in the vibrant Drupal India community will help us continue to drive our strategy forward. Mike’s respected experience on initiatives like Olivero and as a camp organizer is an inspiring model of the different ways of how to be a Drupal Maker, driving innovation and community. We are so lucky to have Nick’s wide experience as a technologist, mentor, and Drupal proponent, as well as his passionate voice and organizer in the European community joining the board at this crucial time in Drupal’s evolution.”

Nick Veenhof photoNick Veenhof is CTO at Dropsolid and is leading the technical and product team. Nick has been involved in the Drupal community for almost 15 years now, but has touched a lot more technologies. He's no stranger to cloud infrastructure and DevOps philosophies. Aside from technology, he tries to be a good coach and mentor by embracing change and to lead by example. He is also advocating Open Source and especially the Open Source project Drupal. Recently, Apache Unomi and Mautic became new Open Source pet peeves for him in order to create the most ambitious Open Digital Experience Platform that ever has existed.

“After all those years trying to fill many roles in the Drupal Community, from contributor, to maintainer, from event organizer to speaking at those events and from being a small sponsor at Drupalcamps to Diamond sponsor at Drupalcon, I was offered this opportunity to give more meaning to my learnings so far,” said Veenhof. “I always very strongly felt that the European Drupal community needed a more vocal voice and a strong need to get these companies united and to start talking to each other and learn from each other. I am hoping to make this a mission to make sure the European market & Drupal community feels connected to the Drupal Association. Openness here is key and that's basically what I've been passionate about ever since I know how much I loved computers and the web. Time will tell how this passion will translate in actionables in the board!

Rahul Dewan photoRahul Dewan is an entrepreneur, open source and agile evangelist, blogger, green activist and yoga/meditation practitioner. Rahul completed his B.Tech in Computer Sciences and worked for a few years in various companies before founding Srijan Technologies in 2002. Srijan is a global Digital Transformation consulting and engineering company that employs ~500 people and does business in 6-8 countries around the world. 

He continues to be the Global CEO (Founder & Managing Director) of Srijan, building a ‘great’ company that is loved by customers as well as its employees and shareholders. 

Dewan said, “Drupal has played a critical role in helping me get to where I am today as an entrepreneur and founder of a successful mid-sized global software services firm. While I have been at the forefront of building the Drupal community in India (specifically in Delhi and north India) since 2011, being part of the Drupal Association board I thought would give me another opportunity to give back to Drupal in many more meaningful ways.”

Nikhil Deshpande photoNikhil J. Deshpande is Chief Digital Officer for the state of Georgia. He heads the Office of Digital Services (DSGa) under the Georgia Technology Authority. Nikhil envisioned and led Georgia’s user-centric digital transition to an enterprise open-source web publishing system, GovHub. Under his direction, Georgia became the first state in the United States to use enterprise Drupal and meet the special needs of constituents with a range of disabilities affecting vision, hearing, motion, and cognition, making GovHub Section 508 and WCAG compliant. 

Nikhil strongly advocated and set the framework for the use of social media for Georgia, back when using social media for the government was not common. He established a presence for the state on Facebook, LinkedIn, and Twitter to quickly address constituents’ questions and concerns. Prior to his career in digital government, Nikhil worked in advertising and digital media. 

“As a Drupal Association board member, I hope to reach out to more state and local governments to educate about Drupal and its advantages,” said Deshpande. “As a large organization partnering with Drupal agencies, I am excited to consult, assist, and help other organizations strategize from procurement to maintenance.”

The newly-elected members will join the following Association board members, continuing their service in the upcoming term: 

  • Dries Buytaert, Founding Director
  • Audra Martin-Merrick, Chair
  • Baddý Sonja Breidert, Treasurer
  • Ryan Szrama, Secretary
  • Grace Francisco
  • Owen Lansbury
  • Lo Li
  • Pedro Cambra Fernandez, At-Large
  • Tiffany Farriss

Finally, the Drupal Association extends a thank you to the board members completing their terms this year – Luma Dahlbacka, Michel van Velde, Leslie Glynn, and Vishal Mehrotra. These leaders have made such an impact during their time on the board, and the Drupal Association could not be more thankful for their service and diverse talents! 

About Drupal and the Drupal Association

Drupal is the open source digital experience platform utilized by millions of people and organizations around the world, made possible by a community of 100,000-plus contributors and enabling more than 1.3 million users on Drupal.org. The Drupal Association is the non-profit organization focused on accelerating Drupal, fostering the growth of the Drupal community, and supporting the Project’s vision to create a safe, secure, and open web for everyone.

Nov 17 2021
Nov 17

After our traditional 6-month hiatus, the MidCamp organizers met in October to discuss our plans for 2022. Here's the tl;dr:

  • we're burnt-out on virtual events, AND
  • we're not ready to go back to the way things were, BUT
  • we still want to do... something in March 2022.

Where we are

We had a good honest conversation with 9 members of our organizing team. Here are some of the recurring themes:

  • We've done one year of virtual in the traditional conference format and one year of experimentation with new formats. We feel like we've been successful with both, but despite trying to scale down our workloads last year, we've still left each year drained instead of reenergized.
  • There is no lack of Drupal content in the world. Between volunteer events, DrupalCon, and professional content producers churning out tons of great content and the relatively quiet Drupal "Super Cycle" as Dries termed it.
  • "Proof of vaccination or negative test" procedures are still in the process of being standardized. We deemed the risks to our volunteer-led team as high. There are companies that offer these services that could reduce some of that burden but we don't yet have information about availability or costs.

What's next?

More virtual, more work, more risk... once we determined we DID NOT want those things, we started discussing possibilities of what we DID want.

  • We believe there is value in the MidCamp brand we've built over the past 7 years. We want to keep it in the conversation—continuing to foster the Midwest Drupal Community and contribute to the Drupal project.
  • We crave some return to in-person events. Dedicating time to networking, recharging, learning, and contributing instead of struggling to attend a conference and work simultaneously.
  • We want to have fun and see friends that we will have not seen IRL for two years or more by March.

So... what now?

The organizing team will be checking in every 4-6 weeks instead of our usual every other week schedule. We'll stay appraised on the state of the world and Chicago. We'll keep brainstorming ideas.

You can keep March 16-19, 2022 on your calendar, subscribe to our mailing list, follow @midwestcamp, and join us on Slack.

Be safe, and Happy Holidays from all of us at MidCamp.

Nov 17 2021
Nov 17

Post Covid-19, finding an IT job has become more challenging for freshly graduated software engineers as different organisations have different priorities in terms of required technical skill sets. In times like these, insights on which risk-free skill set to pursue becomes all the more critical.

Drupal for the Aspiring

Drupal is one of the most significant Open Source Web Application projects in the world. Started as an open-source tool for building community websites, Drupal has now evolved to be a platform that supports large and complex use cases/applications. A varied spectrum of site owners from individuals to small start-ups, universities, museums, enterprises, non-profits, and governments use Drupal. 

Dries Buytaert, the founder of Drupal, likes to define the use case of Drupal as the platform best used for great digital experiences 1. It encompasses the use of Drupal to power mobile applications, create digital business units, digital kiosks, community engagement portals or even enhance digital user experiences. Drupal is flexible, scalable, and provides the creative freedom and speed that site owners value most.

Some of the Drupal projects that truly showcase its capacity are The Weather Channel2 (in terms of scale), The White House website3 (in terms of security requirement), and Johnson & Johnson4 (with thousands of Drupal sites).

Organisations prefer Drupal because of its greater flexibility, better usability, deeper integrations, and faster innovation. While clients’ requirements vary depending on their business needs, having features that they can integrate if needed even later is another plus as far as Drupal clients are concerned.

Keeping Up With Drupal and Other Technologies

One very positive aspect about Drupal and its community is the regular upgrade keeping pace with advancements in technology. Whether responsive, web services, social media integrations, IoT, AI, the community of contributors keep Drupal up to date and ready to deploy with the latest digital market.

Site owners who prefer Drupal are usually the ones at the cutting edge of innovation, using the power of Drupal to transform their businesses in the digital world. So are the developers who work in the back end and front end of Drupal projects. They are constantly learning from their peers in the Drupal community.

Drupal community is close-knit, where community members are ready to have their back in your learning and contributing. By contributing to the various Drupal projects, you can constantly learn and be recognised for it.

The mentorship program in the Drupal community is also solid. Drupal camps local to specific geographic locations are pretty common, especially across the main cities of India. Regular hackathons and code sprints are conducted, which help accelerate your progress through the Drupal learning curve.

Lack of Contributions Affecting Drupal Currently

Dries Buytaert, in his report5 on Who sponsors Drupal Development, 2021 highlighted a few points:

  1. Contributions to module development have been noticeably reduced compared to 2020.
  2. This reduction in contributors and contributions was not specific to any particular area, but he observed it to be consistent across organisations, countries, and project types in general.

Dries attributed it to the downturn caused by the Covid-19 pandemic and also to the general slowdown that happens after a major Drupal release, or as Dries calls it, “the Drupal Super Cycle”.

Source: Drupal Super Cycle5

Dries also attributed the slow down in contributions to the natural busyness that Drupal Service Providers have while scaling up in size. A proof of this scaling up is evidenced by the fact that 7000 contributors have been newly welcomed to Drupal.

1,100 new corporates have joined the Drupal Association as contributors to the Drupal project.

Despite this increase in new members, there was a 10% decrease in contributions from individuals and a 2% decrease from organisational contributors.

Source: Drupal Contributions5

Dries tried to analyse the slow down in contribution statistics. He found that the top 1000 individual contributors are responsible for 65% of all the contributions and the rest of the individuals together account for the remaining 35%. Of the 1000 top contributors, 252 contributed more, 671 contributed less, and 77 stopped contributing to Drupal. While the attrition rate was low, he felt the chief contributors were less active but still loyal for July 1st, 2020 to June 30th 2021.

The attrition rate of 7.7% for the annual period he considered negligible compared to industry standards (15%).

Developer Friendly Environment

Dries Buytaert wants to expand the number of web service endpoints Drupal offers and build an extensive repository of web components and JavaScript framework integrations. So if you are familiar with any technology, learning Drupal will only enhance your work experience to cater to future client requirements.

The development of Drupal as a headless CMS is gathering momentum, primarily driven by the growth of JavaScript frameworks. Along with it, another trend is the use of independent, API-first micro-services. Dries is confident that this will make Drupal one of the most influential and flexible tools for developers.

Also, to make it easier for those new in the Drupal career field, Drupal has started adopting GitLab development tools as opposed to the previous in-house tool. It accommodates and encourages contributions from developers who are new to the Drupal ecosystem but are familiar with tools like GitLab.

Need for Drupal Talent

With companies adopting digital transformation like never before, Drupal is the most popular enterprise-level CMS that drives this transformation. New software and platforms are being developed constantly, but Drupal alone has stood the test of time.

India as the 2nd largest contributor to Drupal, stands to benefit the most by building a Drupal workforce that can help fresh graduates build future-proof careers.

Multinational Corporations (MNCs) like Google, Amazon are investing heavily into Free and Open Source Software development, knowing Free and Open Source Software in the future, especially Drupal Web Content Management System.

Source: Drupal Contributions Countrywise5

India’s Potential as the Largest Digital Workforce

Businesswire7 reported that the estimated global market for Web Content Management Systems (Web CMS) even amidst the Covid 19 pandemic at USD 5.7 Trillion for 2020. As quoted in the news story, a report published by ResearchAndMarkets.com8 projected that it would triple in the next seven years, growing at a CAGR (Compounded Annual Growth Rate) of 16.5% over 2020-2027. Solutions, one of the segments in the report, has a projected CAGR of 15.5%, reaching USD 9.1 Trillion at the end of the same period. The Services segment projection has been revised to 17.9% CAGR for the same seven-year period owing to the Covid -19 pandemic.

Business wire estimated the Web CMS market in the U.S at USD 1.5 Trillion in 2020.

With the second-largest economy, China is projected to reach a market size of USD 3.8 Trillion by the year 2027.

India comes 15th in the Market analysis, right behind Australia, followed by South Korea.

Zyxware’s Initiative with ICFOSS

Zyxware Technologies9, a Drupal Service Provider and a Signature Supporting Partner of the Drupal Association, has been closely associated with Drupal for the last 15 years. As champions of the FOSS philosophy, we realise the need of developing technological for the modern workforce.

It's an ever evolving digital landscape out there - one for which ICFOSS (International Centre for Free and Open Source Software) regularly upskills people through their digital courses. The ICFOSS-Zyxware Drupal Certification Course has thus been designed to contribute to the growth of expertise in the most widely used free & open software - Drupal. 

Drupal is celebrating its 20th Birth Anniversary this year. There are over a million Drupal developers and other contributors to the Drupal project, making it one of the largest open source communities in the world. Take a look at https://jobs.drupal.org/ to find the possibilities for Drupal developers around the world and come and join the Drupal workforce.

References

  1. Dries Buytaert, blog, Drupal is for ambitious digital experiences, Accessed on 17 November 2021. 
  2. The Weather Channel (webportal), Accessed on 17 November 2021. 
  3. The White House (official website), Accessed on 17 November 2021.
  4. Johnson & Johnson (country specified webportal, US), Accessed on 17 November 2021.
  5. Dries Buytaert, blog, Who sponsors Drupal development? (2020-2021 edition), An in-depth analysis of how Drupal's development was sponsored between July 1, 2020 and June 30, 2021. Accessed on 17 November 2021. 
  6. Dries Buytaert, blog, State of Drupal presentation (October 2021), Brief Summary of Driesnote Presentation in DrupalCon Europe 2021, Accessed on 17 November 2021
  7. Insights on the Web Content Management Global Systems to 2027 - Featuring Adobe, Althea Group and Drupal Among Others, Businesswire.com (online),  News Story Link accessed on 17 November 2021.
  8. Web Content Management Systems - Global Market Trajectory & Analytics (online), Report published by ResearchAndMarkets.com, Accessed on 17 November 2021.
  9. Zyxware.com, Company website. 
  10. ICFOSS-Zyxware Drupal Certification Course, Event Announcement (online), Link accessed on 17 November 2021.
Nov 16 2021
Nov 16

As Drupal 8 entered its last months of life, I found myself reflecting. What did version 8 mean for the project? What was lost? What was gained? What were the roads not taken? To try to puzzle out at least some preliminary answers, I read up on what others had shared and spent some time with various sources--Drupal core and contrib code bases, usage statistics, old conference presentations, release announcements and more. I started the exercise motivated by personal interest but now that I've wrapped it up I figure I may as well share my observations in case they're of interest to others.

There've been insightful one-off posts addressing such questions. Often these are reflections on problems with Drupal 8, sometimes coming from people partly or completely moving on from the project. One such was "Lessons Learned From The Stall of Drupal" by Matt Farina, which reads like an exit survey turned in by an exceptionally perceptive and frank respondent.

I wanted to take a deeper pass.

Version 8 of Drupal brought with it by far the most sweeping changes in the twenty year history of the software project. The broad outlines of the shift were discernible as early as 2011 when, in his DrupalCon Chicago keynote address, project lead/"Benevolent Dictator for Life" Dries Buytaert said that, based on consulting some twenty of the largest companies and organizations using Drupal about their pain points, he'd derived core "initiatives" for Drupal 8 - among them the Configuration Management Initiative (CMI) - designed to fix "the pains of large organizations adopting Drupal." Drupal would be fundamentally rewritten to suit the priorities and requirements of enterprise-level users.

Now Drupal 8 has reached end of life (EOL). Not only that, but unlike for prior versions there are no plans to offer commercial security support for Drupal 8. The contrast with Drupal 7, the previous major version, couldn't be more striking. Drupal 7 will be officially supported for a full year after Drupal 8's EOL, while "Vendor Extended Support" for Drupal 7 will be available for an additional three years beyond that, if not longer. When Drupal 8 reached EOL, there were still many more sites out there running Drupal 7 than Drupal 8 and 9 put together. For added symbolic weight, one of those sites still on Drupal 7 is drupal.org itself.

For all the announcements and initiatives that went into Drupal 8, there's been notably little in the way of qualitative or quantitative evaluation, at least in public. Various aims were announced and strategies pursued. Were the objectives achieved? If so, did they have the desired effects?

I was one of several people who raised concerns and flagged issues early on in the Drupal 8 cycle. One motivation in a retrospective was to see: to what extent were our various concerns validated by the process as it played out? To what extent, conversely, was the project able to avoid such issues, or to successfully address them when they arose?

But I had more immediate concerns as well. I've been "doing Drupal" for over 18 years. In many ways I've loved being part of the project. It's shaped my career, enabled me to work part time at home while my kids were young, allowed me to collaborate with organizations whose missions I deeply believe in, and brought me into contact with many interesting people. Early on I made contributions to core systems, some of which - the theme region system, the JavaScript behaviours system - are still around in some form. Over the years I've written or contributed to an embarrassingly long list of modules--embarrassing because the sheer number suggests a tendency to dabble with a problem before moving on to a new interest. But from the start there have been aspects of the project that didn't sit well with me. Now I'm in my fifties. Like many others before me, I'm taking a long look at whether this is still a project I want to be part of. Debriefing Drupal 8 is part of asking, is it time at last to move on? And if not, what exactly do I still want to do in and with the project?

As well as all that, I believe in the value of critique. A project is stronger for having members asking questions and pursuing diverse, even - or especially - unorthodox directions.

Beyond esoteric concerns of a particular software project, the story of Drupal 8 brings in issues of wider concern: voluntarism, conditions of employment, authority, technology and society, corporate influence, the potentials and pitfalls of collective endeavour.

A final motivation was pure curiosity. I found myself following up arcane tangents, exploring puzzling quirks I'd long meant to look into but had never found the time, pursuing answers that brought only further questions, surfacing results that at times felt novel and intriguing, even startling.

In a series of upcoming posts I'll share what I found. These are, of course, just my own reflections. Others will have different experiences, observations, questions, perspectives, insights.

You can't say very much, critical or otherwise, about a project without mentioning at least some initiatives, participants, or groups and things they've done or said. Just in case, I'll say in advance that my interest is the project as a whole; none of what I'm sharing is intended as personal criticism of any participant or contributor. If anyone has concerns or other feedback I'm very open to hearing about it and people may contact me via my drupal.org contact form (requires being logged in to drupal.org).

As a starting place, I'll look at some curious quirks in Drupal usage stats and implications for understanding Drupal 8+ adoption.

Nov 16 2021
Nov 16

If you have a git.drupalcode.org account, the place to update your SSH keys is now https://git.drupalcode.org/-/profile/keys. (If you are redirected back to Drupal.org, clear your browser cache.)

Screenshot showing adding an SSH key on git.drupalcode.org

This is part of the GitLab Acceleration Initiative and simplifies Drupal.org’s codebase ahead of updating to Drupal 9. This SSH key management change allows us to remove the sshkey module, syncing those keys to git.drupalcode.org, integrity checking to catch when they didn’t sync, and a little custom code which modified how the module worked. In the coming weeks, we’ll be identifying and replacing more www.drupal.org functionality that our GitLab instance can do. Follow #3248795: Reduce Drupal.org coupling to GitLab on git.drupalcode.org to track other changes.

Nov 16 2021
Nov 16

After six months of work I'm delighted to tag the first stable release of the 4.x branch of the (Not-so-) Simple XML Sitemap module.

The project is in a really good place right now. At the moment of writing, drupal.org reports it being actively used on around 90k of Drupal 8/9 websites while having 0 open bug reports. This either means you people are lousy bug reporters, or we are doing a descent job at responding. :)

Module rewrite with developers/integrators in mind

4.x makes much greater use of Drupal's entity API dropping some of its very specific chaining API. Feel free to take a look at the roadmap ticket for specifics.

New UI

We now have a much nicer UI for creating, editing and sorting sitemaps as well as sitemap types.

Sitemap list UI

API usage

In a nutshell, sitemap variants are now sitemap entities. These are of a sitemap type (sitemap type entity) that is defined by URL generator plugins as well as sitemap generator plugins.

  1. // Create a new sitemap of the default_hreflang sitemap type.

  2. \Drupal\simple_sitemap\Entity\SimpleSitemap::create(['id' => 'test', 'type' => 'default_hreflang', 'label' => 'Test'])->save();

  3. /** @var \Drupal\simple_sitemap\Manager\Generator $generator */

  4. $generator = \Drupal::service('simple_sitemap.generator');

  5. // Set some random settings.

  6. if ($generator->getSetting('cron_generate')) {

  7. $generator

  8. ->saveSetting('generate_duration', 20000)

  9. ->saveSetting('base_url', 'https://test');

  10. }

  11. // Set an entity type to be indexed.

  12. $generator

  13. ->entityManager()

  14. ->enableEntityType('node')

  15. ->setVariants(['default', 'test']) // All following operations will concern these variants.

  16. ->setBundleSettings('node', 'page', ['index' => TRUE, 'priority' => 0.5]);

  17. // Set a custom link to be indexed.

  18. $generator

  19. ->customLinkManager()

  20. ->remove() // Remove all custom links from all variants.

  21. ->setVariants(['test']) // All following operations will concern these variants.

  22. ->add('/some/view/page', ['priority' => 0.5]);

  23. // Generate the sitemap, but rebuild the queue first in case an old generation is in

  24. // progress.

  25. $generator

  26. ->rebuildQueue()

  27. ->generate();

See code documentation and readme for instruction on how to create URL generator and sitemap generator plugins and check out what other things can be done with the API. You are welcome to submit support requests in the matter as well as help improving the documentation.

Should you use this over 3.x?

Yes, read on though.

While the changes of this release are catered towards developers and site builders, I strongly encourage everyone to use the new version, as 3.x will be considered deprecated from now on. All new features and improvements will be coming to 4.x only. Do not panic however, I will be fixing bugs in 3.x for a while.

An update path is provided from previous module versions. Two reasons you might want to postpone upgrading is:

  • You depend on the old module's API and need some time to adjust it
  • You depend on 3rd party contributed simple_sitemap submodules that are yet to be made compatible with Simple XML Sitemap 4.x. In this case, please open up issues in the respective queues.

Thanks for everyone who has been involved in the development of this tool. Enjoy!

Nov 16 2021
Nov 16

Editorial process and workflow is critical regardless of your content marketing strategy - is an easy thing to type. Sure, it can give your team better clarity and enable them to work in sync… Yes, a strategic editorial workflow can save you from deciphering email strings and searching Slack messages for who is handling what… Of course we all know that multiple hands working on it from different locations, things can get pretty complex… Yet, how many organizations, years deep into content marketing, still have a non-existent workflow? Way more than need to. Especially with Drupal 9 offering a fantastic module - the Content Moderation module - that allows editorial teams to manage and build workflows for specific types of content. 

By default, as most people are accustomed to in basic setups, Drupal content can be either published or unpublished. If your content marketing team needs something a little more nuanced than this, enable the Workflows and Content moderation modules for Drupal 9. (Note that the content moderation module became a core module after Drupal 8.5) That makes it easier than ever to create an editorial workflow that works for your team. In this article we’ll illustrate how these modules work.

Drupal 8 has now reached EOL. If you’re still on Drupal 8, now is the time to migrate to Drupal 9.

Content Moderation

Content Moderation and Workflow Modules for Drupal 9

The Drupal 9 Content moderation module works in conjunction with the Workflows module to easily create and manage an editorial workflow using different states and transitions. The Content moderation module allows you to:

  1. Create a Draft (The first state is not published)
  2. Have different states than just published and unpublished.
  3. Change the states.
  4. Have granular permission control for every transition and state.
  5. Select the content types that you want to apply the workflow to

The Workflows module defines a set of states and transitions that are then attached to content by the Content moderation module. A “state” is the current condition that your content is in (Draft, Unpublished, Review, Published, Archive). A “transition” is the process of moving content from a state to another (Needs work, Needs review, Publish).

Configuring Content Moderation

First, let’s get your Content moderation module enabled. Content moderation module ships with Drupal core, but is disabled by default. You will need to manually enable the module to start working with it. 

To enable the module, go to Extent -> Content Moderation module and Click on Install. 
Once the module has been enabled,
go to Configuration -> Workflow -> Workflows

Here, you can see a default workflow called “Editorial” that gets created when you enable the module. You can edit the existing “Editorial” workflow or create a new workflow by clicking on Add Workflow.

Add new workflow

Creating a new workflow

Once you have created a new workflow, you will see various states and transitions that you can configure and edit. You can also create your own state or transition if your team requires more flexibility or steps. There’s also the option for you to choose the content type that you want to apply this workflow to.

Editorial Workflow

Defining a new Workflow

Label: The name of the Workflow.

States: You can add a new state by clicking on the  “Add a new state” button like “Ready for Review” or “Approved”. You can also edit an existing state.

Transitions: You can add a new transition by clicking on the “Add a new transition” button. For Example: Transition from Ready For Review -> Approved

This workflow applies to: You can choose to which entity types the workflow should apply. For example, Block types, Content, etc.

Default Moderation State: Here you can choose the default moderation state when we create a new content.

Users and Permissions

Now, let’s say you are working in a team of 3 :

  1. Blog Author: The person who creates and edits the Blog but does not publish the Blog.
  2. Blog Reviewer: The person who reviews the Blog created by the Blog Author.
  3. Blog Publisher: The person who publishes the blog approved by the Blog Reviewer

Assuming that you have created user profiles for these three users, let’s move on to what each one of them can do (or not do).

The site admin controls what each user can access and sets permissions for them. For this example, we have chosen Blog post as our content type and named the workflow “Blog”. The site admin can give access to each user to control each transition created for this workflow. You can see that here (see below) we have given the Blog Author the permission to only Create New Draft, while the Blog Publisher has permissions for almost everything (Approve, Archive, Create New, Needs work, Publish). The Blog Reviewer can control the Approve, Create new draft and move to Needs work transitions.

Permission Control

Permission control example for a Blog post content type

The Workflow Example

Here is an example of the content moderation workflow for a Blog post content type.

1. Blog Author creates a new blog post.

New blog post

2. The Blog Author saves the content in Draft because the article is not ready to be published yet.

Draft

3. Once the Blog Author completes writing the blog, they will change the state from Draft to Ready For Review.

Ready for Review

4. The Blog Reviewer reviews the content and if everything is ok, they will change the state from Ready for Review to Approved.

Approved

5. If the Blog needs work and is not ready to be Approved, he  will change the state from Ready for Review to Needs Work.

Needs Work

6. The Blog Publisher publishes the Blog post. They change the moderation state of the content from Approved to Published.

Published

This example shows a simple editorial workflow of a blog post content type. You can also have a more complex and rich workflow based on your business requirements.

To check and edit the status of all your content - moderation state, content revisions, author, content type, etc., you can do this in your Moderated content view. You will only find this view when the Content moderation module is enabled. To find it, go to Content -> Moderated Content tab.

Moderated content dashboard
Nov 16 2021
Nov 16

The penetration of smartphones and mobile internet has led to a change in consumer behaviour. More users are interacting with businesses using their handheld devices. Latest studies show that around 52.94% (Source: Search Engine Journal) of all searches are carried out using mobile phones. Hence, it becomes necessary that you optimize your website for mobile devices.

Search engines like Google also plan to split the mobile and desktop into separate indices with more stress on mobile searches and responsiveness. Mobile searches play a significant role in the taking decision that requires you to optimise website for mobile and enhance conversions. This article discusses in detail why you must optimize the website for mobile search.

What is an Effective Mobile Optimized Website?

We have learnt that you can expect more than half of the website visitors would be from handheld devices. Users should discover the website through an organic search over mobile devices. You must also adjust content on the website to allow mobile users to have a customized experience through different devices. Optimized content will flow seamlessly across mobile as well as desktops.

It would be best if you also kept in mind that mobile-optimized websites ensure more robust user engagement. Search engines like Google are on a mission to provide users with a better surfing experience. They are using mobile responsiveness as a critical parameter while ranking websites for keyword search. Businesses must also keep this in mind when they are trying to have a mobile optimized website.

mobile optimized website

Benefits of Optimizing Website for Mobile Search

Enhancing user experience

Since most website visitors will be from mobile devices, do you think shrinking content to fit mobile screens is enough? Ideally, the users must have a seamless experience when using mobile devices. It becomes difficult for them to adjust the screen size by zooming and pinching their screens.

The content on the website must be such that the visitors can easily find the information they are searching for. It must also be easy for them to click on the CTA buttons easily. Therefore, have a simple design and comprehensive navigation capabilities.

Optimizing for Voice Search

As the user dynamics change towards mobile devices, it becomes necessary to consider how they search for information. It is easier for these users to use search capabilities to access the information they will need. There are several devices too that allow voice search that is convenient for such users.

When you try to cater to these users, you must optimise the content and use the right keywords for voice search. It can help you with additional traffic that you can readily convert towards more sales. Good voice search optimization can help uplift the brand and assure extra dwell time on the site.

Have More Conversions

You must keep in mind that 74% of users prefer to return to a mobile-friendly website. (Source: WebFX) A positive search experience on your website can help in ensuring more conversions through the website. Web admins can make use of mobile optimizations and engage with users better.

It is apt for e-commerce websites to quickly embark on the buyer's journey and culminate in a sale. The website can have user-specific directions that can readily enhance the chances of conversions. Moreover, developers can readily integrate Google Maps and other personalization features on the mobile website.

Address Visual Search Requirements

Traditional search parameters are getting replaced by newer ones. As a result, businesses are increasingly looking for visual supremacy. For example, visual search increases usage, with studies showing that visual search can increase revenues by around 30% (Source: Tech Funnel).

You must also optimize your website for visual search as mobile users are increasingly using it. It can improve user experience and boost website traffic. When done correctly, it can readily lead to more conversions and revenue. It is more relevant for e-commerce websites and other search channels.

Assures Optimal Loading Speeds

Are you aware that you must compress the images before being shown to the users? Therefore, it would take additional time and requires the website to have optimal loading speed.

loading speed impact on user experience

Loading the web pages within the optimal time will prevent users from moving away from the website. Moreover, search engines use the page loading speed as an essential ranking parameter too.

Different Ways to Optimize your Website for Mobile Search

If you optimize your website for mobile, you must also consider several aspects other than having a responsive website. We will discuss them in further detail.

Focus on Improving User Experience

Websites must focus on enhancing the user experience when they are trying to have a mobile optimized website. Having a responsive design that allows seamless viewing across all terminals and devices is a part of it. In addition, scrolling through the website must be hassle-free, and a thumb-friendly design can make the website more interactive.

The CTA buttons must be optimized for mobile devices and must be easy to find and stand out. They must be big enough for users and easy to click. The screen sizes will also be different, and using small fonts will make it uncomfortable for these users. Moreover, adjust the font and ensure they are legible on all devices.

Optimize the Title Tags and Descriptions

You will face a space crunch while catering to mobile users, but you must ensure that the users can access the website readily. It is possible if you readily optimize the title tag and meta description that makes it easy for them to decide whether to visit your website.

title tags for mobile seometa description for mobile seo

The title tags act as the page preview, and it helps if you optimise it for mobile users. It would be best to use the relevant keywords that allow the users to understand the relevance of visiting your website. The meta description provides additional information to help ascertain the need to visit the site.

Creating Mobile Optimized Content

Mobile-friendly content can induce visitors to stay more on the website. Use standard fonts that users can view readily on all device screens. Also, have large touchable areas and icons that can help visitors more. Avoid flashy components as rendering them can be difficult on several devices. Also, use structured data that can help users find answers to their queries quickly.

Keep the paragraphs short as it could be difficult for mobile users to read longer ones. The content must be enriching and add value to the user. Incorporating social sharing buttons are also encouraged for better user interaction. Also, add relevant images but ensure they are optimized too.

Use Accelerated Mobile Pages

When you are optimizing the website for mobile devices, you must take advantage of Accelerated Mobile Pages. It will help them to create mobile-friendly web pages and removes advanced layouts and unnecessary media files. Also, keep in mind that you must redesign the pop-ups or get penalized by Google. You can use the plugins available that can automatically generate these mobile-optimized pages.

amp pages

Conclusion

There has been a steady growth in mobile search, and it requires businesses to address this aspect. In addition, as more users use mobiles for their online activities, mobile-specific searches are increasing. Hence, the search patterns are changing, and you must optimise the website to address this traffic.

Optimized websites can respond to mobile queries, and it will help you have a sustainable online presence. You can be in touch with a reputed mobile web development company to help you to address this aspect of your marketing activities. 

We have helped several large enterprises in optimizing their website for mobile search. We are just a phone call away!

Nov 15 2021
Nov 15

Today we are talking about Drupal Diversity & Inclusion with Tearyne Almendariz.

TalkingDrupal.com/321

Topics

  • Nic - Split keyboard
  • April - Daylight saving pet time adventures
  • Tearyne - Summer sabbatical coming to an end - working for Pantheon now!
  • John - NEDCamp!
  • Brief background for DDI
  • Talking Drupal #217 - Tara, Marc, Alanna
  • Talking Drupal #297 - with Fatima & Tara
  • First involvement in DDI
  • What’s new with DDI
    • Regional leads
    • Focus on Restoration and rejuvination
  • Changes over the years
  • Support from community
  • How to expand diveristy and equity in tech
  • How to elevate women in tech
  • React community
  • New members
  • Getting involved
  • First online camp
  • Biggest issue in Drupal right now for Diversity
  • Neurodiversity
  • How to be an ally and an advocate

Resources

Guests

Tearyne Almendariz - @TearyneG

Hosts

Nic Laflin - www.nLighteneddevelopment.com @nicxvan
John Picozzi - www.epam.com @johnpicozzi
April Sides - @weekbeforenext

MOTW

Entity Usage

Nov 15 2021
Nov 15

Everyone at my organization knows that for over ten years, I have been invested in the growth and development of Drupal as well as the growth and success of my organization's website - the two go hand in hand. As of the writing of this blog post, the organization has been, and is, committing additional projects and resources to Drupal, which means that more people now frequently ask me Drupal-related questions. Just the other day, I rattled off a quick list of what it takes to implement a Drupal website on a recent planning call.

Pages

About Drupal Sun

Drupal Sun is an Evolving Web project. It allows you to:

  • Do full-text search on all the articles in Drupal Planet (thanks to Apache Solr)
  • Facet based on tags, author, or feed
  • Flip through articles quickly (with j/k or arrow keys) to find what you're interested in
  • View the entire article text inline, or in the context of the site where it was created

See the blog post at Evolving Web

Evolving Web