Upgrade Your Drupal Skills

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

See Advanced Courses NAH, I know Enough
Apr 14 2021
Apr 14

Watch part 2 of Skvare's training series on the CiviCRM Entity Drupal module.

[embedded content]

CiviCRM Entity is a Drupal module that provides enhanced integration with Drupal, allowing developers, site builders, and content creators to utilize powerful Drupal modules including Views, Layout Builder, Media, and Rules. Drupal fields can be added to CiviCRM entity types. It provides Drupal pages and edit forms for all CiviCRM data such as contacts, allowing usage of familiar Drupal content creation tools and workflows.

During this training we cover:

  • Entity view modes
  • Using Drupal fields and form displays
  • Drupal-based view & edit pages for CiviCRM data
  • Entity Reference and Inline Entity Form
  • Entity browser
  • Layout Builder

Filed under

Apr 14 2021
Apr 14

Watch Part 2 of our CiviCRM Entity 3.0 training series.

CiviCRM Entity is a Drupal module that provides enhanced integration with Drupal, allowing developers, site builders, and content creators to utilize powerful Drupal modules including Views, Layout Builder, Media, and Rules. Drupal fields can be added to CiviCRM entity types. It provides Drupal pages and edit forms for all CiviCRM data such as contacts, allowing usage of familiar Drupal content creation tools and workflows.

During this training we cover:

  • Entity view modes
  • Using Drupal fields and form displays
  • Drupal-based view & edit pages for CiviCRM data
  • Entity Reference and Inline Entity Form
  • Entity browser
  • Layout Builder

Valuable Tools for Better Site Building

  • Entity Browser Module: Provides extremely configurable selection, entity creation, edit form display field widget for referencing/creating entities with entity reference fields
  • Bootstrap Layout Builder: Enhances Drupal Core's layout builder module, including boostrap column layouts, integration with Bootstrap Styles so that site builders can control typography, borders, padding, margin, background color, background video, and much more
  • Bootstrap Styles Module: Provides configurable styles to be used with Bootstrap Layout Builder
  • Bootstrap Library Module: Provides any version of Bootstrap css/js framework for themes that are not bootstrap based
  • Layout Builder Restrictions Module: Allows site builders to limit what blocks are available to add to layouts
  • Inline Entity Form Module: Another module entity creation, edit form display field widget for referencing/creating entities with entity reference fields. Can be used in conjunction with Entity Browser
  • Drupal Console: A command line tool to generate boilerplate code for many Drupal features, including Field formatters and Field widgets
  • Field Group Module: Enables grouping fields into fieldsets, collapsible "Details" element, vertical and horizonal tabs
  • Chaos Tools Module: Chaos Tools: Many "goodies" that haven't been included into Drupal Core. In our demo it allows us to place entity view mode renderings, that use field groups

Additional Resources:

Apr 14 2021
Apr 14

Companies are breaking free of restrictive proprietary platforms in favour of custom open source solutions. Find out why in this comprehensive article.

Advantages of Open Source Commerce

Download the PDF version of this article | Acro Media

Ownership of data & technology

If you use an open source commerce platform, you own the code.

You need to look at your website the same way you would view a brick-and-mortar storefront. Paying a monthly licensing fee for a hosted platform is like having a leased property -- you’re only adding to your overhead costs and you have no control over your future. Hosted solutions don’t allow you to own the code, which business owners often don’t think of as a problem until something bad happens. If a hosted solution goes under, they take you down with them. You lose your online presence and have to rebuild from the beginning. That’s a long and expensive process.

If you use an open source commerce platform you own the code. If you work with an agency and choose to move to an in-house development team or a different agency, you can do so at no cost or risk to your business.

Integration with virtually any business system

The code is completely exposed for you to use.

If you judge ecommerce solutions solely on their feature set, hosted solutions like Magento, Shopify, and Volusion will always look good up front. But your ecommerce platform is more than just window dressing. Open source frameworks can have an impressive feature set, but the biggest advantage is the expansive list of back-end systems they can integrate with.

Proprietary platforms can offer standard integrations with customer relationship management (CRM) systems and fulfillment solutions, but if you’re a big retailer, you may find you need a higher degree of integration for your sales process.

Open source platforms are exactly that. Open. The code is completely exposed for your use. Combine this with the modular architecture and you have a platform with the ability to integrate with virtually any business system that allows access, from CRMs and shipping vendors to payment gateways and accounting software. Your ecommerce site can become an automated business rather than just a storefront.

A custom user experience

A custom user experience gives more power to the marketer.

When it comes to user experience, hosted platforms give you a best-practice, industry-standard, cookie-cutter execution of a shopping cart. It’s a templated design that is sold as a finished product, so you know you’ll have a catalogue, a simple check-out, account pages, etc. Outside of choosing a theme, there is very little room for customization. Open source allows for all the same functionality plus a powerful theme system that allows you to add unique and advanced features very easily.

A custom user experience gives more power to the marketer, allowing them to create custom conversion paths for different user types and integrate those paths within the content experience. You can generate personalized content based on customer data and/or provide different content to users based on their geographic location.

Open source commerce is also ideal for omnichannel selling. The consumer path is seamless across all sales channels, devices, websites and retail tools throughout the entire customer experience. You can set up content, layout and functionality to respond to the device being used, such as smartphones and tablets.

The omnichannel experience & a single source of data

Open source platforms use a single data source which makes it optimal for creating omnichannel strategies.

Today’s ecommerce landscape is rapidly evolving. It’s no longer just about selling products online. Companies are expected to create immersive shopping experiences for users. The advances in mobile technology have given consumers constant and instant access to information. They expect their favourite brands to be able to deliver an integrated shopping experience across all channels and devices complete with personalized content, consistent product information, and simple conversion paths. This is not an easy task. For retailers that sell through both online and in-store channels, the challenge is even greater.

Open source platforms use a single data source which makes it optimal for creating omnichannel strategies. Rather than having to force together multiple platforms that pull data from various systems, open source allows for one centralized data centre that can be accessed by any of the systems you need.

What does this mean exactly?

Customer data, product details, promotions & sales information, inventory numbers and more can all be easily defined and streamlined across multiple channels. For example:

  • Your customers can start a purchase online and then pick up where they left off in your store. 
  • Customer data can be accessed easily for automated marketing; loyalty programs, birthday “gifts”, personalized recommendations.
  • If your products are sold on your ecommerce store as well as third party marketplaces, your product info is always consistent without having to apply multiple updates on various backends.
  • Easily define and promote location-based pricing and offers.
  • Real-time inventory numbers can be shown online to ensure product availability and minimize the risk of back-orders.
  • Tax & shipping rules can be defined per city, state, country to ensure all customers are shown the correct cost of items at checkout.

A flexible platform that aligns with your needs

Exceed the boundaries of a traditional sales platform.

Any ecommerce platform today needs the ability to adapt. If your platform is locked down, you risk losing to your competitors. Hosted ecommerce solutions are just shopping carts with conventional catalogue management and the ability to sell physical and/or digital products.

Open source commerce releases you from these industry-standard restraints. Organize your products using virtually any attribute. Display your products in any style, from lists, grids, or tables to a customized look that can make you stand out from your in-the-box competition. Integrate features that go beyond commerce, such as custom applications, web services, and customer portals. Exceed the boundaries of a traditional sales platform.

Don’t be tied to someone else’s development path. By leveraging an open source platform, you allow yourself to be the frontrunner in your market.

No licensing fees, revenue sharing or mandatory support contracts.

Open source commerce is free to use.

Anyone with the appropriate development skills can pick up an open source framework and begin working with it immediately at no charge. If you require development help you will need to pay a contractor or agency and depending on your needs these upfront costs can seem like a lofty investment. However, after the upfront development, there are no mandatory ongoing costs associated with open source.

If you are utilizing a SAAS or proprietary platform start-up costs are minimal but the majority of them have various ongoing costs.

  • Monthly contracts — SAAS platforms will charge you a monthly fee to use their platform, in addition to this fee you may have to pay for additional functionality, integrations, and/or support.
  • Licensing fees — The big enterprise platforms (Demandware, Hybris, Magento) charge a yearly license fee to use their software platforms. These fees can range from $50,000 - $700,000 per year.
  • Revenue sharing — SAAS and proprietary platforms will often require a revenue share contract to supplement their low monthly fee. A typical revenue share agreement is a 2% transaction fee. Depending on your yearly gross revenue this can be a major blow.

1000’s of supporters and continued development

Open source platforms are pushed forward by thousands of developers and supporters worldwide; agencies, contractors, & enthusiasts all have a shared goal of bettering their software and creating an accessible and stable platform. Proprietary systems simply can’t compete with a workforce this large or this focused. Open source evolves at the pace of the web. By leveraging this type of platform, you can be a front-runner in your market. Often before a retailer even knows it needs a specific new integration or piece of functionality, someone is already building it.

Drupal Commerce & Acro Media

Drupal Commerce is the powerful ecommerce software that extends from the open source Drupal platform. Drupal Commerce was built onto the content management system using the same architecture, allowing for a true marriage of content and commerce. It is a truly unrestricted platform that provides both structure and flexibility.

Acro Media is the leading Drupal Commerce agency in North America. We work exclusively with Drupal and Drupal Commerce, and currently, develop and support one of the biggest Drupal Commerce websites in the world. Our Drupal services include:

  • Drupal Commerce
  • Drupal consultation and architecture
  • Drupal visualizations and modelling
  • Drupal integrations to replace or work with existing platforms
  • Drupal website migrations (rescues) from other web platforms
  • Custom Drupal modules

Are you ready to escape?

Break free from the proprietary platforms and legacy software you’re handcuffed to and create the commerce experience you want. Open source commerce gives the power to the business owner to create a commerce experience that meets the ever-changing conditions of your marketplace as well as the complexities of your inner company workings.

Next steps

Want to learn more about open source, Drupal Commerce, or Acro Media? Book some time with one of our business developers for an open conversation to answer any questions and provide additional insight. Our team members are here to help provide you with the best possible solution, no sales tricks. We just want to help, if we can.

Consulting Services | Acro Media

Apr 14 2021
Apr 14

Working with multimedia is one of the areas that large websites have to deal with. When multiple editors upload a large number of files, keeping your photos and videos in order can become difficult and time-consuming. Drupal has several proven recipes for managing the media library, which I'll present in this article.

Drupal modules for managing multimedia

Drupal offers great flexibility when working with files on a website. In the simplest terms, you can use fields like "File upload". A more complicated option is to use one of the modules to work with multimedia. Let's take a look at three interesting modules worth knowing about.

IMCE module

IMCE is a file viewer available to administrators and editors that also allows you to add, copy, and delete files and directories. It’s fast and convenient, it offers a preview of photos (including creating thumbnails), allows you to sort them and limit the disk space for individual users.

There was a time when the IMCE module was an absolute must-have for any Drupal website. To this day, over 340 thousand websites use it, but its popularity is steadily declining. The reason for this is that with more editors it's difficult to keep your file directories in order. Searching for a specific item is problematic, because the files have only a name and type. It's also impossible to filter them according to selected criteria. Despite the existence of the IMCE version for Drupal 8, new websites usually use other solutions.

IMCE module - Drupal file viewer

 

SCALD project

SCALD is a module designed for Drupal 7, with a very rich base of add-ons (over 50 additional modules). It allows you to add photos, videos, and other types of files as entities called atoms. Each atom can have any field list based on which the media list is filtered. There is no module version for Drupal 8, but there is a migration path for atoms to the Media module entity.

I mention the SCALD module due to its significant contribution to building the concept of media management. With the premières of Drupal 6 and 7, the era of entities and fields was slowly approaching. The first ideas began to emerge to present files as entities that could be described in any way. This is how the SCALD project was created – quite niche, although used over the years on large and popular sites with millions of multimedia, such as Radio France, ARTE TV and Le Figaro.

Media module

This is by far the most important of the modules presented here. It follows an idea similar to SCALD, because it turns files into entities. It’s currently used by over 180 thousand Drupal 7-based websites, as well as all the websites based on Drupal 8 and 9. That's because since version 8.4 it’s in the core.

Media is a mature module, prepared for years by a team of experienced programmers. I can confidently say that it's one of the best multimedia management solutions available on the Internet. What makes the Media module so special? I'd point out its four main advantages:

  1. Effective embedding of a file library in the Drupal's entity/field/view model. This solution gives virtually endless possibilities for web developers. The files can have different view modes and form view modes, they can be used in many independent contexts. A photo sent via the Media module can be used multiple times, both as a thumbnail in the content of the article and, for example, as a background of a large banner.
  2. Leaving the directory/file model. When uploading a photo or video, the editor no longer decides about the order in the directory structure. It’s done automatically. Ordering is done using the fields defined in the media. You can, for example, add a category to the files, and then use it to search through the list of multimedia.
  3. Independence from media sources. On a well-designed website, videos will work the same way whether they are uploaded directly or via YouTube or Vimeo. Photos can also be loaded from multiple sources (such as Pixabay or Google Drive). Such an approach makes the work of editors easier and allows quickly adding subsequent sources as needed.
  4. Media isn't only multimedia anymore. You can put documents, Facebook posts or excerpts from Google Maps in the media library. Your only limit is your imagination.

When it comes to migration, remember that the Media module comes in three forms:

In each of these cases, a migration path to the core version is available, so you can easily transfer the multimedia library to a newer Drupal.

Why isn't the Media module used on every website?

This begs the question – since the Media module is so great and also available in the core, why isn't it enabled by default and used in every Drupal development project? This is because many Media elements need to be set up by a programmer first. Therefore, this module is a tailor-made solution that is strongly adapted to the needs of a specific website.

It's particularly problematic to correctly display videos from external sources (due to the limited capabilities of external players) and to design appropriate display modes for the media. Getting through these issues can take a long time. Due to this fact, at Droptica we use a ready-made solution included in Droopler, the Drupal distribution.

Media module in Droopler

Since version 2.0, Droopler has built-in support for the Media module. All photos, graphics, icons and videos on the website are stored in the file library.

Usage of the Drupal Media module in the Droopler distribution

 

It's fine if you have a website based on Droopler 1.x. When upgrading to Droopler 2.x all "File upload" fields will be automatically converted to the new format.

The files put in the library can be used in many places on the website - as a paragraph background, an icon, a photo in a gallery or a cover for a blog post. In each of these contexts, the multimedia will be trimmed and adjusted accordingly. Here are examples of using the same photo in a completely different capacity:

As a tile

An example of using a photo as a tile on a website based on Droopler, thanks to the Drupal Media module

 

As a form background

An example of using a photo as a form background in Droopler

 

As a blog cover

An example of using a photo as a blog cover

 

Once you start using Droopler, you'll be amazed at the ease with which you can use YouTube and Vimeo videos. For example, try putting your video in a paragraph with a banner. In the paragraph edit options add the media in the "Background" field:

Adding a video in a paragraph with a banner in Droopler, the Drupal distribution

 

Then go to the "Video" tab, enter the video address, click ADD and choose a title for the newly added item. Finally, put the video in a paragraph.

Adding a video in a paragraph with a banner in Droopler

 

The effect of this action will be a moving background that stretches across the entire screen and is played in a loop. The YouTube controls will be hidden, and the video will have a transparent black overlay, improving the readability of the text.

Video as a moving background, played in a loop, on a website based on Droopler

 

You can add a video to a gallery in the same way, and e.g. next to the text, in the "Sidebar Image" paragraph. There are practically no restrictions here, all the elements fit together well.

Summary

The multimedia library included in the latest Drupal works great with even with a large number of subpages and blog posts. You will quickly notice that reusing the existing photos and videos saves time and effort. Even though the Media module requires a lot of coding for every new project, you can use "prepackages" such as Droopler to start working on the content right away.

Apr 14 2021
Apr 14

This month I gave a talk at South Carolina Drupal User Group on Getting Started with Electron. Electron allows you to use your web developer skills to create desktop applications. I based this talk on some of my recent side projects and the Electron Project Starter I posted the end of last year.

[embedded content]

If you would like to join us please check out our up coming events on MeetUp for meeting times, locations, and remote connection information.

We frequently use these presentations to practice new presentations, try out heavily revised versions, and test out new ideas with a friendly audience. So if some of the content of these videos seems a bit rough please understand we are all learning all the time and we are open to constructive feedback. If you want to see a polished version checkout our group members’ talks at camps and cons.

If you are interested in giving a practice talk, leave me a comment here, contact me through Drupal.org, or find me on Drupal Slack. We’re excited to hear new voices and ideas. We want to support the community, and that means you.

Apr 14 2021
hw
Apr 14

It’s spring and I decided to come out to a park to work and write today’s post. I sat on a bench and logged in to my WordPress site to start writing the post when I noticed that one of the plugins had updates available. I didn’t have to think about this and straightaway hit the update button. Less than 30 seconds later, the plugin was updated, the red bubble had disappeared, and I had my idea of today’s post. That is why I want to talk about automatic updates on Drupal today.

Now, automatic updates have been in WordPress for quite some time. In fact, I don’t remember when I last updated a WordPress site manually even though I am running this site for years. The closest thing to this we have in Drupal is the “Install new module” functionality. As the name says, it can only be used for installing a new module and not updating existing ones. There is an initiative for Drupal 10 to bring automatic updates to Drupal core (only security releases and patch upgrades for now).

No automatic updates in 2021?!

It may seem strange that we don’t have automatic updates in a product aspiring to be consumer-grade in this age. The reason is that this problem is hard to get right and notoriously dangerous if it goes wrong. Also, Drupal is used on some of the largest and most sensitive websites in the industry. The environments where these websites are hosted do not support any regular means of applying updates. Finally, Drupal tends to be used by medium to large teams who use automation in their development workflow. The teams would rightly prefer the automation in their toolchain to keep their software updated.

For example, at Axelerant we use Renovate for setting up our automatic updates for all dependencies (even npm and more). In fact, our quick-start tool comes with a configuration file for Renovate. With our CI and automation culture, we would not like Drupal to update itself without going through our tests.

This is not applicable for most users of Drupal and having some support for automatic updates is important. But considering the challenges in getting it right and lack of incentives for heavy users of Drupal, this feature was not prioritized. It’s about time that there is community focus on it now.

What’s coming in automatic updates?

The current scope of the automatic updates initiative is listed on its landing page. The current scope is limited to supporting only patch releases and security updates only for Drupal core, not even contrib modules. While this is far from making Drupal site maintenance hands-off, it is a step in the right direction. Of course, once this works well for Drupal core, it would be easy to bring it to contrib projects as well. More importantly, it would be safer as any problems would be easier to find with a smaller impact surface area.

In my mind, these are the things that the automatic updates will have to consider or deal with. It’s important for me to note that I am not involved in the effort. I am sure the contributors to this initiative have already considered and planned for these issues and maybe a lot more. My intention is to portray the complexity of getting this right.

Security

This is one of the most critical factors in an automatic update system. Internet is a scary place and you can’t trust anyone. So, how can a website trust a file that it downloads from the Internet and then replace itself with its contents? This is the less tricky part and it can be solved reasonably well with a combination of certificates and file checksums.

The website software runs as a user on the server, ideally, with a user with just enough privileges. In most cases, such users don’t have permissions to write to their own directory. This is needed because if somebody is able to perform a remote code exploit, they could write to the location where the software is installed and install backdoors. But in such a configuration, the website cannot write to its own location either. I don’t think such setups are in the scope of automatic updates anyway, as such teams would have their own automation toolchain for keeping software updated.

Developer workflows

As I mentioned before, Drupal websites are typically built by large teams who have automation set up. Such teams typically have their own conventions as to how upgrades are committed and tested. This is why tools such as Renovate can get so complicated. There are a lot of conventions for automatic updates system to deal with and as far as I know, most just ignore it. For example, I don’t know if WordPress really cares about the git repository at all.

Integrity

Once the updates are downloaded, they still have to be extracted and placed in their correct locations. What if, due to a permission error, a certain file cannot be overwritten? Such issues can leave the website in an unusable state entirely. The automatic updates code should be able to check for such issues before beginning the operation. There’s still a chance that there would be an error and the code should be able to recover from that. I’m sure there are a lot more scenarios here than what I am imagining.

The initiative

This is a wider problem than just Drupal and we don’t have to come up with all the answers. There is an ongoing effort to address these problems generally in a framework called The Update Framework. More about this is being discussed in the contrib module automatic_updates and the plan is to bring this into the core when ready. Follow the module’s issue queue or the #autoupdates channel on Drupal Slack.

Apr 13 2021
Apr 13
easy drupal install and configuration

https://www.drupal.org/project/coffee

Credits & Thanks

Thank you to:

About the Coffee Module

The Coffee module is the fastest way to get to any admin screen in Drupal. As you SEO your Drupal site, you will spend a lot of time jumping into admin to change a setting or check on updates. You’ll have to go through menu navigation if you don’t have the Coffee module. That’s fine, but sometimes it’s hard to remember where every single setting is in the Admin Menu.

With the Coffee module installed, you can type ALT-D on your keyboard (Option-D for macOS) to have a text field pop up. Start typing into this field and the Coffee module will show you the admin menu items that match. Press the Enter key to select the first item or use the arrow keys to select a different item and press the Enter key to go directly to the admin page that you want.

Tip: Throughout this guide, you’ll see us present Coffee shortcuts when appropriate. For example, when we mention Coffee: "extend", then you’ll hit your Coffee shortcut keystroke (typically Alt-D or Option-D) and type "extend".

Install and Enable the Coffee Module

  1. Install the Coffee module on your server. (See this section for more instructions on installing modules.)
     
  2. Go to the Extend page: Click Manage > Extend (Coffee: "extend") or visit https:///admin/modules.

    drupal coffee module installation screenshot

  3. Select the checkbox next to "Coffee" and click the Install button at the bottom of the page.

Permissions for the Coffee Module

If necessary, give yourself permissions to use the Coffee module.

  1. Click Manage > People (Coffee: "people") and click on the Permissions tab. https:///admin/people/permissions.

    drupal coffee module permissions screenswhot
     

  2. Select the appropriate checkboxes for:
    • "Access Coffee"
    • "Administer Coffee"
       
  3. Click the Save permissions button at the bottom of the page.

Configure the Coffee module

  1. Go to the Coffee admin page: Click Manage > Configuration > User Interface > Coffee (Coffee: "coffee") or visit https:///admin/config/user- interface/coffee.

    drupal coffee module configuration screenshot

  2. Select the checkbox next to any additional menus that you want to include in the Coffee interface. We typically include them all, but if it starts getting cluttered, then you can take them out later.
     
  3. Click the Save configuration button at the bottom of the page.

Using the Coffee Module

  1. To access the Coffee interface, click the following key combination based upon your computer type:

         PC: alt+D (or alt+K)
         Mac: opt+D
     

  2. Start typing the name of the Drupal admin section you are looking for. For example, if you are trying to get to the Metatag settings interface, you would start typing "metatags" -- entering the first few letters will normally bring up what you're looking for, but can also provide other related settings as well.

    Drupal coffee module interface
     

  3. Click the appropriate result item to take you where you want to go. In our example, you could click on the entry titled "Metatag".
     

Once you are familiar with the different admin sections, the Coffee module can get you where you need to go far faster than by using the administrative menu.

Apr 13 2021
Apr 13

Drupal has been in the content management game for over two decades. That is a long period of time and in that time span the CMS has accomplished a lot. It’s community of over a million Drupalists is just one part of it. With 20 years gone, Drupal is still running strong and its latest update is proof of that. 

Yes, in the June of 2020, amidst the pandemic, Drupal 9 was launched and it was my only sunshine at that time and I am sure many of my Drupal friends would agree with me. Drupal 9 can be deemed as one of the best offerings of Drupal, not there were many that were anything but great.

Job done easy: Drupal 9 upgrade

The latest version meant we had to take it on, why be comfortable with the past when the present can offer more comfort, right? However, the mammoth task that was the Drupal 8 upgrade, you must remember that, made many of us apprehensive and rightfully so. And that is where we were surprised, pleasantly might I add, by Drupal. 

“Easiest upgrade in a decade.”

This is how the Drupal 9 upgrade is being described and it is because you won’t have to replatform your site, you’d only be updating. It's like taking a connecting flight from London to Paris rather than leaving the airport and taking a train from the station. Connecting flights are easy.

The timeline of Drupal releases in shown. Timeline of Drupal 9 future releases | Source: Drupal.org

Considering the fact that Drupal 9 is not a migration, the upgrade is a breeze. With the addition of new features like Olivero and Claro, being built and stabilised respectively, the new versions of Drupal 9 will become all the more appealing and a release can be expected half yearly much like Drupal 8. So, can we afford to sit back and not take the step towards upgrading our Drupal sites. The fact the Drupal 7 and Drupal 8’s end-of-life has been decided has given us all the more reason to make the upgrade. Read our complete guide on Drupal 9, Drupal 9 FAQs, must-have modules to start your Drupal 9 website, configuration management strategies in Drupal 9 and web development strategies for Drupal 9 website to know more about Drupal 9 and its usage.

To help you in finding the answer to the popular question of “How to upgrade Drupal 9?”, here I am with an all inclusive checklist for this massive step you are about to take. So, let’s begin.

Is the upgrade different for Drupal 7 and Drupal 8?

This is one of the most commonly asked questions for Drupal 9 upgrade. There are still a lot of Drupal sites that are still operating on the 7th version, so it is understandable to want to know whether ‘the easiest upgrade of the decade' is applicable to them or is it different. 

Drupal 9 upgrade is different for Drupal 7 and 8 sites. This is mainly because Drupal 8 was a whole other ballgame than Drupal 7, while Drupal 9 is just a new and improved version of Drupal 8 with no deprecated APIs. Therefore, the upgrading process was bound to be different.

Let’s see how. 

Drupal 8 to Drupal 9 

Support for Drupal 8 will end on 2nd November, 2021, it will receive patch releases, but there won’t be any major updates in its feature simply because we have Drupal 9. Therefore, upgrading to the newer version is the better option. 

To upgrade from Drupal 8 to Drupal 9, 

  • You would have to see that all your projects are Drupal 9 compatible; 
  • You would have to see that your codebase is free of deprecated APIs; 
  • And then all you would have to do is run update.php. 

It sounds simple enough, right? That is because it is. Of course, you would have to perform some more steps than these three and there would be a number of tools that you would have to use for them. However, it is these three steps that are essentially the crux of upgrading from Drupal 8 onto 9.

Drupal 7 to Drupal 9

Drupal 7’s support is said to end on 28th November, 2022. Although your D7 site has quite some time ahead of it, you still have to start thinking about the upgrade as the process is not as easy as the D8 to D9 upgrade. 

You can take two routes here; 

  • You can first update to Drupal 8, avail functionality from all the modules that are yet to come in Drupal 9 and then take the easy route of upgrading to Drupal 9; 
  • Or you can directly upgrade to Drupal 9 and skip the 8th version. This would be ideal because your upgrade would have a much longer lifespan.

For the upgrade from Drupal 7, you would need three modules; 

These three do everything from data and content migrations and checking the availability of modules to scanning them and updating them for the upgrade. 

So yes, the Drupal 9 upgrade from Drupal 7 and 8 is different, simply because they are very different versions of the CMS. 

Now that we have this notion clarified, let’s move on to all the nitty-gritty details of the upgrade.  

What tools would you need for the Drupal 9 upgrade?

Can you cook without the right ingredients? Can you make the perfect lasagna without the melt-in-the-mouth pasta? I know you know the answer to these two questions and that’s a big fat no. 

Therefore, the incredible journey towards the Drupal 9 experience has to start by talking about the tool you would need for it, the ingredients that’ll make the upgrade all the more appetising. I’ll stop with the cooking analogy now and come to the point. There are two mandatory tools that you will be needing.

Upgrade Status 

Upgrade Status is a module that prepares your site for the upcoming upgrade you are planning to execute. It is a pretty versatile module that does all the grunt work required before making the leap to D9. 

  • Your site has to be the latest version of Drupal, that is Drupal 8.8 or 8.9, so the first thing this module does is inspects whether you are on that version, if not, it’ll tell you to update.
  • Your system needs to meet Drupal 9’s set requirements for the upgrade to go on smoothly, so the next thing it does is check if you meet them.
  • Your contributed projects also need to be updated and be compatible with Drupal 9. If they are Drupal 8 compatible, there is a high chance they’ll be for Drupal 9. So, Upgrade Status works with Update Status to ensure every project is in sync.
  • Your site needs to be compatible with Drupal 9 in other ways as well, so that is also checked and verified through phpstan.
  • Your system’s integration drush is also taken care of here.
  • Your system might have deprecated APIs, Upgrade Status finds, although there are any fixes provided; for that you'll need another tool.

Upgrade Status’ enchantment doesn’t end here, there is more to this module yet. 

  • I’ve told you that it prepares your Drupal 8 site, but it also gives you the leeway for downloading it with and without the Composer. 
  • It is also available in Drupal 7 and this version would help you in preparation for the Drupal 9 as well as Drupal 8 upgrade, if that is what you want. 
  • Now, the most alluring part, once you’ll upgrade to Drupal 9, it’ll start preparing you for the Drupal 10 upgrade! Yes, you read it right, Drupal 10 launch is in the works and you can be ready for that when it happens with this module.

Deprecation Check

Remember I mentioned deprecated APIs above, well, there are more than APIs that can be deprecated and that needs your attention before you start creating the upgrade environment for your site. That is why, Deprecation Checking and Correction Tools become a necessity.  

All in all, there are five tools for your help. 

  • The first one is an IDE or code editor, which comprehends deprecation to kickstart the process. 
  • Then there is the Drupal-check, this one performs a PHP run and let’s you know whether deprecated code is used and where.
  • Third is the Upgrade Status I talked about above, which essentially scans your entire system and finds deprecated code for you. 
  • The Drupal.org Testing System also supports deprecation inspection.
  • Finally, the Upgrade Rector Contributed Project provides a solution for all of the checking done above and that too in an automated manner.

What are the environment requirements for Drupal 9?

When you are roasting the perfect chicken, the temperature in the oven has to be just right, the timing has to be just right and the flavours have to be just right to make it come out all juicy and succulent. I know I have started with the cooking analogy again, but this is the best comparison I could think of. 

Like that perfect roast chicken, Drupal 9 also needs just the right environment from you and your system to make it work. And this involves; 

Web Servers

Drupal 9 can be run using two different web servers and you need to have the latest versions of these two.

  • For nginx, you have to have the version 0.7.x or above; 
  • And for Apache, it has to be at least 2.4.7.

PHP 

PHP is the language Drupal is built on, of course you must know that. What you may not know is that you need PHP 7.3 for operating Drupal 9. The latest version 9.1.0 supports PHP 8.

Database and Hosting Structures 

Drupal 9 has specific requirements for its backend database as well as its hosts. These are; 

  • Version 5.7.8+ for MuSQL or Percona; 
  • Version 10.3.7+ for MariaDB;
  • Version 3.26+ for SQLite; 
  • Version 10 for PostgreSQL; 

And if you are planning to use Drush to build your interfaces, go for version 10, since only that is compatible with Drupal 9.

Have you prioritised the update of the core codebase?

Drupal 8 was the last major release before Drupal 9. Like any Drupal version, there are a number of minor releases being launched and you must keep up with them. If you have done so, your core codebase would be up-to-date and you’d be all set for the upgrade. 

One of the Drupal 9 upgrade requirements is that your site be updated to Drupal 8.8 or 8.9 for you to be prepared for the easiest upgrade of the decade. 

What happens if you are on a version older than 8.8?

What’ll happen is the upgrade won’t go through. Now you might ask why? I’ll give you an analogy, can you skip a few grades and land from 6th grade directly to high school? Even if you could, would you say that getting the hang of the classes you’ll have be quite arduous? It most definitely will be. So, like you can’t skip grades and you can’t skip the minor releases of Drupal 8 before going on to Drupal. Because Drupal 8.9 and Drupal 9 are somewhat similar the upgrade is a breeze, however, Drupal 8.4 and 9 do not share that kind of similarity and you might need to upgrade fast. 

From upgrades in PHP to core modules, from themes to contributed modules and from path aliases and database, almost every aspect requires updating to be compatible with Drupal 9. And only Drupal 8.8 and 8.9 have that level of API compatibility. 

How to upgrade if you have a Drupal version that precedes 8.7? 

For a version older than Drupal 8.7, you would have to perform some small code changes and database updates that are not very complex. An update to the latest version of the core would be required, and this would make the database and contributed modules ready for the 9 upgrade.

You can use Upgrade Status to ensure that all of what you just did is compatible with Drupal 9 or not. 

Then you’ll have to check for deprecated code, like we discussed two sections above. Thereafter, you become ready to update your core codebase to Drupal.

How to upgrade if you have a Drupal version that succeeds 8.8?

If you are already on Drupal 8.8, there isn’t much you have to do in order to prepare yourself. The only task to perform is running the Upgrade Status and checking compatibility. 

There is one more thing that you will have to do. And that is what your existing site is based upon because that will decide how the actual upgrade will flow. 

Your site could be based on Composer or it could be based on Tarball. Make sure you keep that in mind before starting the upgrade, as both work on different upgrade mechanisms. While the former has its own list of steps to follow, the latter is upgraded using Drush.

What about updating the custom code?

After upgrading the core codebase, you would have to pay close attention to your custom code. There is a high chance that your project will have custom modules and themes, these mean a custom code would also there and it is your responsibility to update it. 

You wouldn’t need new tools and techniques to help you here. 

  • Upgrade Status will scan all the projects for custom code deprecations; 
  • Upgrade Rector will fix any minor deprecations by itself. 

Updating the custom code is not that big a task, so it is often neglected and overlooked. However, it is important enough to hamper the entire upgrade. So, don’t skip it.

Can the contributed projects be neglected?

If you have taken care of the core and custom projects, you can’t think about leaving the contributed project without any attention. So, updating them is the next agenda on the Drupal 9 upgrade checklist. 

The reason for updating the contributed projects is the same as the core and custom projects, to check the compatibility of the projects with Drupal 9. And you must know by now, since I am repeating it for what feels like the 100th time, Upgrade Status will help you in the compatibility check.

You must know that even though a module is Drupal 9 compatible, there is the off chance that it can be a version of a major release that’ll bring API changes along with it. You have to be mindful of these modules because they can be detrimental to your site’s health. API changes that you are not prepared for can’t be efficacious by any means.

But what if a module is not Drupal 9 compatible?

There are, of course, not many of them, however there are some and you must know how to handle them. You can do any of these two things in this scenario.

  • Creating, you can create a custom code to update it;  
  • Or waiting, you can wait to see if it gets updated by the time you are ready for the final upgrade;  

What about the contributed modules with patches, do they need attention?

There are situations where you may want to update a contributed module, but an update is not in the picture, rather you have patches available and sometimes, not even that. What would you do? Pay attention to the patches, that is what.

Usually if a patch is available for a module, Upgrade Status would inform you about that and you can implement it. 

Then there is the scenario, when a contributed module has neither an update and nor a patch. For such an instance, the combination of Upgrade Status and Upgrade Rector will have you sorted. You can also check Drupal’s Contributed Modules Guidelines to help you further. 

Have you examined your content and field types thoroughly?

Auditing for site building is a must. Adding fields and customisations in Drupal is quite easy, anyone can do it. This is both good and bad. Good because anyone can do it leading to less dependence on developers, bad because anyone can do it meaning there might be redundant field types and outdated content. And in this step, you check for just that. 

  • Check and eliminate fields that were created for a once-in-a-lifetime event; don’t let them sit and waste away.
  • Remember those content types you created to add content later, well, you haven’t done that yet, so they have to go as well.
  • Update the help text; this might seem trivial to you, but being someone who relied on that piece of text to perform all my initial duties instead of pinging my manager every minute, trust me, it is important. If it is outdated, it is useless and why would you want something useless on your upgraded Drupal 9 site?

Customisations are only great until they don’t start bloating your site causing regression. You do not want that, so don’t just keep all your focus on the code, modules and themes, give some time to the content as well.

How do you become sure that your upgrade is successful?

You will execute the upgrade to make your site better than it already is, that should be the aim, right? However, despite you doing everything to the T, there is a chance that you may go in regression. Your upgrade may be doing everything that it is supposed to, but still your site’s performance can be slower than it was. 

No one wants that scenario to become their reality, so how do you avoid that? How do you ensure that the upgrade is successful? There is certainly a way to ensure that and that’s through testing.

When you perform tests, you get to know what is truly happening with your site. Where you went wrong and what you did right won’t be hidden under a veil. For instance, performing a test to check the administrative and editorial working of the site is ideal. On paper, everything may appear sound, but in reality your editors could be struggling to make even the smallest of edits. And it is only through testing that you’ll be able to find that out. 

You can start at a smaller level with a hello world test and gradually scale up to examine the major aspects of the upgrade. 

Another thing that’ll help you in making the upgrade a success is going slow. Yes, upgrading to Drupal 9 is deemed as the easiest update of the decade, but it is still a huge task to take on. Just the sheer number of modules that wild require updating can become overwhelming, so go slow, update a few modules at one time. This is the chances of errors would be slim and the chances of success would be quite high. 

The Bottom Line 

Drupalists from across the globe had been awaiting the release of Drupal 9 for a long time, now that it is here, there is nothing holding us back from taking the upgrade leap. If I am to be honest, I’d say that I was fearful of the upgrade process. However, when Dries Buytaert say that one of the fundamental issues to address in the Drupal 9 release was the ease of installation, you cannot do anything but believe him. That’s what we should do. 

Apr 13 2021
Apr 13

The success of open source projects is largely carried by the pillars of the community and group collaborations. Without putting a stake in the ground to achieve strategic initiatives, an open source project can lose focus. Open source strategic initiatives should aim at solving impactful problems through collaboration involving the project's stakeholders.

The why and how of Drupal's strategic initiatives

As one of the leading open source projects, Drupal's success largely thrives on implementing its various proposed strategic initiatives. Drupal's focus on strategic initiatives and continuous innovation since Drupal 7 brought huge architectural changes in Drupal 8, 9, and beyond that offer a platform for continuous innovation on the web and an easy upgrade path for end users.

The vision for Drupal's core strategic initiatives is determined by Dries Buytaert, Drupal project lead. These initiatives are backed by community collaboration and lead to significant developments driven by forces like:

  • Collaboration with the core maintainers
  • Survey data and usability studies
  • A vision to build a leading open source digital experience platform
  • Relevancy in the market by improving editorial, developer, and customer experiences
  • Validation by broader community discussions and collaborations
Once initiatives are proposed, they move ahead to the planned initiatives stage, where each initiative is nurtured with detailed plans and goals by a strong team of contributors. When an initiative passes through this stage, it moves to the active initiatives stage. Here's where the initiatives take structure and come alive.

Some of the most successful Drupal 8 initiatives, like Twig and Bigpipe, did not follow the traditional process. However, following a thoughtfully planned process will avoid a lot of bike-shedding.

In 2011, at DrupalCon Chicago, Dries announced that Drupal 8 would feature core initiatives that would cause big changes to Drupal's architecture. To support the transition, each initiative would have a few leads involved in decision-making and coordination with Dries. Some popular initiatives included:

  • Configuration Management Initiative (CMI): This was the first key initiative announced at the 2011 DrupalCon. The idea was to offer site builders more powerful, flexible, and traceable configuration handling in Drupal 8 core. As planned, the Configuration Manager module is now a Drupal 8 core module that allows deploying configurations between different environments easily.
  • Web Services and Context Core Initiative: This initiative aimed at embracing a modern web and turned Drupal into a first-class REST server with a first-class content management system (CMS) on top of it. The result? Drupal is now a competent REST server providing the ability to manage content entities through HTTP requests. This is part of why Drupal has been the leading CMS for decoupled experiences for several years.
  • Layout Initiative: This initiative's focus was on improving and simplifying the site-building experience by non-technical users, like site builders and content authors. This initiative came alive in Drupal 8 by introducing the Layout Discovery API (a Layout plugin API) in v.8.4 and the Layout Builder module (a complete layout management solution) in v.8.5 core.
  • Media Initiative: The Media Initiative was proposed to launch a rich, intuitive, easy-to-use, API-based media solution with extensible media functionalities in the core. This resulted in bringing in the Media API (which manages various operations on media entities) and Media Library (a rich digital asset management tool) to Drupal 8 core.
  • Drupal 9 Readiness Initiative: The focus of this initiative was to get Drupal 9 ready by June 3, 2020, so that Drupal 7 and 8 users had at least 18 months to upgrade. Since Drupal 9 is just a cleaned-up version of the last version of Drupal 8 (8.9), the idea was to update dependencies and remove any deprecated code. And as planned, Drupal 9 was successfully released on June 3, 2020. Drupal 8-compatible modules were ported to Drupal 9 faster than any major version upgrade in Drupal's history, with more than 90% of the top 1,000 modules already ported (and many of the remaining now obsolete).

The new strategic initiatives

Fast-forward to 2021, where everything is virtual. DrupalCon North America will witness a first-of-its-kind "Initiative Days" event added to the traditional DrupalCon content. Previously, initiatives were proposed during the Driesnote session, but this time, initiatives are more interactive and detailed. DrupalCon North America 2021 participants can learn about an initiative and participate in building components and contributing back to the project.

Dries proposed the Decoupled Menus Initiative in his keynote speech during DrupalCon Global 2020. While this initiative's broader intent is to make Drupal the best decoupled CMS, to accomplish the larger goal, the project chose to work on decoupled menus as a first step because menus are used on every project and are not easy to implement in decoupled architectures.

The goals of this initiative are to build APIs, documentation, and examples that can:

  • Give JavaScript front-end developers the best way to integrate Drupal-managed menus into their front ends.
  • Provide site builders and content editors with an easy-to-use experience to build and update menus independently.

This is because, without web services for decoupled menus in Drupal core, JavaScript developers are often compelled to hard-code menu items. This makes it really hard for a non-developer to edit or remove a menu item without getting a developer involved. The developer needs to make the change, build the JavaScript code, and then deploy it to production. With the Decoupled Menus Initiative, the developer can easily eliminate all these steps and many lines of code by using Drupal's HTTP APIs and using JavaScript-focused resources.

The bigger idea is to establish patterns and a roadmap that can be adapted to solve other decoupled problems. At DrupalCon 2021, on the Decoupled Menus Initiative day, April 13, you can both learn about where it stands and get involved by building custom menu components and contributing them back to the project.

The Easy Out-Of-The-Box Initiative

During DrupalCon 2019 in Amsterdam, CMS users were asked about their perceptions of their CMS. The research found that beginners did not favor Drupal as much as intermediate- and expert-level users. However, it was the opposite for other CMS users; they seemed to like their CMS less over time.

Hence, the Easy Out-Of-The-Box Initiative's goal is to make Drupal easy to use, especially for non-technical users and beginners. It is an extension of the great work that has been done for Layouts, Media, and Claro. Layout Builder's low-code design flexibility, Media's robust management of audio-visual content, and Claro's modern and accessible administrative UI combine to empower less-technical users with the power Drupal has under the hood.

This initiative bundles all three of these features into one initiative and aims to provide a delightful user experience. The ease of use can help attract new and novice users to Drupal. On April 14, DrupalCon North America's Easy Out-Of-The-Box Initiative day, the initiative leads will discuss the initiative and its current progress. Learn about how you can contribute to the project by building a better editorial experience.

Automated Updates Initiative

The results of a Drupal survey in 2020 revealed that automated updating was the most frequently requested feature. Updating a Drupal site manually can be tedious, expensive, and time-consuming. Luckily, the initiative team has been on this task since 2019, when the first prototype for the Automated Update System was developed as a contributed module. The focus of the initiative now is to bring this feature into Drupal core. As easy as it may sound, there's a lot more work that needs to go in to:

  • Ensure site readiness for a safe update
  • Integrate composer
  • Verify updates with package signing
  • Safely apply updates in a way that can be rolled back in case of errors

In its first incarnation, the focus is on Drupal Core patch releases and security updates, but the intent is to support the contributed module ecosystem as well.

The initiative intends to make it easier for small to midsized businesses that sometimes overlook the importance of updating their Drupal site or struggle with the manual process. The Automated Updates Initiative day is happening on April 15 at DrupalCon North America. You will get an opportunity to know more about this initiative and get involved in the project.

Drupal 10 Readiness Initiative

With the release of Drupal 10 not too far away (as early as June 2022), the community is gearing up to welcome a more modern version of Drupal. Drupal now integrates more third-party technologies than ever. Dependencies such as Symfony, jQuery, Guzzle, Composer, CKEditor, and more have their own release cycles that Drupal needs to align with.

The goal of the initiative is to get Drupal 10 ready, and this involves:

  • Releasing Drupal 10 on time
  • Getting compatible with the latest versions of the dependencies for security
  • Deprecating the dependencies, libraries, modules, and themes that are no longer needed and removing them from Drupal 10 core.

At the Drupal 10 Readiness Initiative day, April 16, you can learn about the tools you'll use to update your websites and modules from Drupal 9 to Drupal 10 efficiently. There are various things you can do to help make Drupal better. Content authors will get an opportunity to peek into the new CKEditor 5, its new features, and improved editing experience.

Learn more at DrupalCon

Drupal is celebrating its 20th year and its evolution to a more relevant, easier to adopt open source software. Leading an evolution is close to impossible without taking up strategic initiatives. Although the initial initiatives did not focus on offering great user experiences, today, ease of use and out-of-the-box experience are Drupal's most significant goals.

Our ambition is to create software that works for everyone. At every DrupalCon, the intent is to connect with the community that fosters the same belief, learn from each other, and ultimately, build a better Drupal.

DrupalCon North America, hosted by the Drupal Association, is the largest Drupal event of the year. Drupal experts, enthusiasts, and users will unite online April 12–16, 2021, share lessons learned and best practices, and collaborate on creating better, more engaging digital experiences. PHP and JavaScript developers, designers, marketers, and anyone interested in a career in open source will be able to learn, connect, and build by attending DrupalCon.

The Drupal Association is the nonprofit organization focused on accelerating Drupal, fostering the Drupal community's growth, and supporting the project's vision to create a safe, secure, and open web for everyone. DrupalCon is the primary source of funding for the Drupal Association. Your support and attendance at DrupalCon make our work possible.

Apr 13 2021
hw
Apr 13

I have been setting up computers and configuring web servers for a long time now. I started my computing journey by building computers and setting up operating systems for others. Soon, I started configuring servers first using shared hosting and then dedicated servers. As virtualization became mainstream, I started configuring cloud instances to run websites. At a certain point, I was maintaining several projects (some seasonal), it became harder to remember how exactly I had configured a particular server when I needed to upgrade or set it up again. That is why I have been interested in Infrastructure as Code (IaC) for a long time.

You might say that it is easier to do this by just documenting the server details and all the configuration for each project. Sure, it is great if you can manage to keep the documentation updated as the software evolves and requirements change. Realistically, that doesn’t happen. Instead, if you start with the perspective that you are going to only configure servers with code, never manually, you are forced to code all the changes you want to make.

Infrastructure as Code

So, what does IaC look like? There are several tools out there and each has its own conventions. Broadly speaking, there are two types of code you would write for IaC: declarative or imperative. If you are a programmer, you are already familiar with the imperative style of programming. This is essentially the style of almost all programming languages out there. In these languages, you would write line-by-line instructions to tell the computer exactly what to do and how to do it. Consider this shell script used for creating an instance on DigitalOcean.

#!/usr/bin/env bash
 
read -p "Are you sure you want to create a new droplet? " -n 1 -r
if [[ $REPLY =~ ^[Yy]$ ]]
then
    doctl compute droplet create --image ubuntu-20-04-x64 --size s-1vcpu-1gb --region tor1 ps5-stock-checker --context personal
    echo "Waiting to create..."
    sleep 5
    doctl compute droplet list --context personal
fi

Here, we are running a sequential set of instructions to create a droplet and verify that it got created. We are also confirming this with the user before actually creating the droplet. This is a very simple example but you could expand it to create whatever style of infrastructure you need, albeit not easily.

The declarative style of programming

Most IaC tools support some form of declarative syntax which lets you define what infrastructure you need rather than how to create it. The above example in Terraform, for example, would look like this.

resource "digitalocean_droplet" "web" {
  image  = "ubuntu-20-04-x64"
  name   = "ps5-stock-checker"
  region = "tor1"
  size   = "s-1vcpu-1gb"
}

As you can see, this example is easier to read. Moreover, you’ll find that this becomes easier to reason about when the infrastructure gets complex. My personal preference is to use Terraform but whatever you use would have a similar structure. It is the tools job to how exactly implement this infrastructure. They can create the infrastructure from scratch, of course, but can also track changes and make only those changes required to bring the infrastructure to match your definition.

Where is the simple in this?

You might think this is overkill and I can understand that sentiment. After all, I thought the same but I have found it useful for projects both large and small. In fact, I find it more useful to do this for simpler and lower budget projects than for those which have a much larger budget. At least as far as Drupal is concerned, projects with larger budgets use one of the PaaS providers. There are several providers such as Acquia, Pantheon, platform.sh, or others that do a great job at Drupal specific hosting. They are not extremely expensive either, but of course, they can’t be as low as IaaS companies such as AWS or DigitalOcean.

So, it may not be simple but we can get there. On the projects that I am going to self-host, I add in a directory called “infra” with Terraform modules and an Ansible playbook. To make it findable, I have put it up on Github at hussainweb/lamp-ansible-terraform. There’s no documentation, unfortunately, but I hope to put up something soon. Meanwhile, this blog can be an informal introduction to the repository.

My workflow

When I want to start a new project that I know won’t be on one of the PaaS providers, I copy the repository above into my project and start editing the config files I need. Broadly, the repository contains Terraform modules to provision a server (or two) to run Drupal and the actual configuration of the server happens through Ansible. As of right now, there are modules for AWS and Azure to provision the servers. The one for AWS supports setting up instances with security groups configured. You can optionally set up a separate instance for a Database server as well. You can find all the options that the module supports in the variables.tf file.

On the other hand, the module for Azure is simpler and only supports setting up a single server to run both web and database server. You can take a look at its variables.tf file to see what is exposed (TL;DR, just the instance size). I built these modules on a need basis and didn’t try to maintain feature parity.

Depending on what I want to use, I will initialize that Terraform module (terraform init) and provision. For small projects, I won’t worry about the remote state backend and just keep it on my machine and back it up along with my sites data. It’s a long process but it works and I haven’t needed to simplify that yet. At the end of this, I get the IP address(es) of the instance(s).

Sometimes, I need to set up different servers for a staging environment, for example. For this, I just provision another server in a different Terraform workspace. The module itself does not support multiple environments and does not need to.

Configuring the instance

Now that I have the IP address(es), I can set up Ansible. I edit the relevant inventory files (for dev or for production) and set up relevant variables in various yml files. Out of these, I absolutely have to change the app.yml file to set my project’s repository URL. I can optionally also change the PHP version, configure Redis, set up SSH keys (edit this one if you want to use the repo), etc. Once all this is done, I can run ansible-playbook to execute the playbook.

I realize this repo is hardly usable without documentation. So far, it’s just a bunch of scripts I have cobbled together to help me with some of my projects. In time, I do want to improve the documentation and add in more resources. This also intersects with my efforts in another direction to set up remote development instances (not for hosting, but for live development). It’s called Yakht (after yacht as I wanted an ocean related metaphor). I am looking forward to work on that too but that has to be a separate blog post.

Apr 13 2021
Apr 13

In May 2021, Google will begin to recognize Page Experience as a ranking factor, prioritizing user experience in the particular and overall ranking score.

Page Experience signals include two signals: 

  • Core Web Vitals
  • Search Signals

While Search Signals focus on mobile-friendliness, security, and safe browsing, Core Web Vitals measure user experience for loading performance, interactivity, and visual stability of the page.

Core Web Vitals consist of three metrics that measure how long a site visitor has to wait until they can see the page and begin to make use of it. These are:

  • Largest Contentful Paint (LCP) – Measures when the main content is downloaded, visible, and useful to the site visitor.
  • First Input Delay – Measures how long a user has to wait for the site to react when they interact with a web page element like a link.
  • Cumulative Layout Shift – Measures how much time it takes for the content to stop shifting around and be stable enough for users to successfully interact with it.

Ranking higher on search engines means you have to optimize your website based on Core Web Vital metrics performance reports. If you’re using Drupal, the CMS has some strengths and weaknesses regarding these scores.
 

Drupal and Core Web Vitals
HTTP Archive published research on which content management system (CMS) achieved the best Core Web Vitals scores. The HTTP Archive challenge examined WordPress versus Drupal, Joomla, Squarespace, and Wix.

The top-ranked CMS for LCP is Drupal. The lowest-ranked CMS is Wix. While Drupal was the winner, the Drupal mobile LCP score was only 47%. Drupal is the winner, but only because the other CMS scores were so low.

The scores for FID were very high. Squarespace was the champion—91% of its sites passed the FID test. Drupal came in third, behind Squarespace and WordPress.

In terms of Cumulative Layout Shift (CLS),  Drupal came in first again, this time with a solid 70% of Drupal sites providing a quality CLS experience. Wix came in third place, beating WordPress.

Improving the LCP Core Web Vital in Drupal
The precursor to LCP was First Contentful Paint (FCP), which measured how long it took a website to load the first feature on any web page. The focus shifted to LCP because Google determined that the largest feature on any webpage is the most relevant.

According to Google's best practices, your website must load the most pieces of content on each webpage within the first 2.5 seconds.

What causes poor LCP?

  • Render-blocking JavaScript and CSS
  • Slow resource load time
  • Client-side rendering
  • Slow service response times

Audit your site to identify the Largest Contentful Paint (LCP) element. In your Drupal Audit, use reports like Lighthouse and PageSpeed Insights to track Core Web Vitals. The most common methods that will help you improve your LCP score are:

  • Removing any unnecessarily third-party scripts: Studies show that each third-party script slowed a page down by 34 milliseconds.
  • Upgrading your web host: Better hosting = faster load times overall (including LCP).
  • Setting up lazy loading: Lazy loading makes possible for images to load only when someone scrolls down your page.
  • Removing large page elements: Google PageSpeed Insights will tell you if your page has an element that’s slowing down your page’s LCP.
  • Minifying your CSS: Bulky CSS can significantly delay LCP times.

Improving the FID Core Web Vital in Drupal
FID focuses only on input events from discrete actions like clicks, taps, and key presses. Scrolling and zooming don't count toward the measurement of your webpage FID score. FID only measures the delay in event processing.

What causes poor FID? 

  • Long tasks
  • Long JavaScript execution time
  • Large JavaScript bundles
  • Render-blocking JavaScript

The usual suspects impacting FID in any website are:

  • Minimizing (or deferring) JavaScript: It’s almost impossible for users to interact with a page while the browser is loading up JS. So minimizing or deferring JS on your page is key for FID.
  • Removing any non-critical third-party scripts: Like with FCP and LCP, third-party scripts can negatively impact FID.
  • Using a browser cache: This helps load content on your page faster, helping your user’s browser blast through JS loading tasks even faster.

Improving the CLS Core Web Vital in Drupal
CLS measures all individual layout shift scores for every unexpected layout shift during the page experience. A layout shift occurs whenever a visible element, such as an image or CTA button, changes its position from one rendered frame to the next.

What causes poor CLS?

  • Images without dimensions
  • Ads, embeds, and iFrames without dimensions
  • Dynamically-injected content
  • Web fonts causing Flash of invisible text (FOIT) and Flash of Unstyled Text (FOUT)

Conduct a Drupal Audit of your website to identify how to improve your CLS score for each webpage.

  • Use fixed-size attribute dimensions for any media. That way, the user’s browser knows exactly how much space that element will take up on that page. And won’t change it on the fly as the page fully loads.
  • Ensure ad elements have a reserved space. Otherwise, they can suddenly appear on the page, pushing content down, up, or to the side.
  • Add new UI elements below the fold; that way, they don’t push content down that the user expects to stay where it is.

Testing Core Web Vitals in Drupal 
There are many areas to test core web vitals on your live Drupal site. The PageSpeed Insights tool, the Chrome UX Report, and Google Search Console will generate LCP, FID, and CLS metrics based on field and lab data. These tools will come in handy when you audit your Drupal build.  

If you are in development, it might be good to keep an eye on these metrics as you build a new site. This Drupal module helps track these vitals across pages as you’re in development, so your team can address site speed issues before the site even goes live. They will come in handy during development and building. 

Core Web Vitals and SEO in 2021
When indexing search results, Google is prioritizing user experience first, so Core Web Vitals and Page Experience are going to be significantly moving forward. Website development and design agencies will need to rethink their project delivery to become user-centric. You should begin optimizing your website's Core Web Vitals sooner rather than later to avoid being hit with penalties related to poor user experience factors.
 

Apr 12 2021
Apr 12

At Morpht, we have been busy experimenting and building proof-of-concept personalisation features on Drupal 8. We started off with content recommendations as one of the cogs in a personalisation machine. Recombee stood out as a great AI-powered content recommendations engine and we decided to develop some contributed modules to integrate it with Drupal.

We have implemented three modules which work together:

  • Search API Recombee indexes content and pushes it across to Recombee.
  • Recombee module tracks users and displays recommendations.
  • JSON Template module defines a plugin system for transformers and templates and controls how JSON can be transformed client side.

The video below is a demonstration of these three modules and how they combine to deliver a power recommendations system capable of providing content to anonymous and logged in users alike. 

[embedded content]

Download the slides from the presentation
(PDF 785KB)

Let's talk

Find out how personalisation can help you increase audience engagement and lift user experience.

Contact us

Apr 12 2021
Apr 12

The last 18 months have been difficult for many in our global community. The global COVID-19 pandemic has taken loved ones from us too soon. Social and political upheaval around the world have fractured civil discourse, and set back the cause of civil rights. Economic uncertainty has affected our jobs and our prospects for the future. For some, the present crises have brought up memories of more distant loss.

In a year in which we have all experienced loss, remembrance and reflection helps us heal.

We encourage the Drupal community to share memories of lost friends, colleagues, family, and loved ones- whether that loss was recent or many years past. We encourage you to share and remember the good they brought to our lives.

We encourage you to share your words of hope for civil and societal change.

Whatever your words of hope and remembrance we encourage you to lift each other up.

How to share your words of remembrance:
The comments on this post have been opened, or you can use the hashtag #drupalmemorial on social media to tag your posts to the embedded memorial wall below

Apr 12 2021
Apr 12

We’re bringing you our latest recap of top Drupal blog posts from last month. Get ready for some really great posts this time!

Creating a New Self-Help Portal for the California Courts

The first post we’re including this month is written by Mike Madison of Chapter Three and describes a project they did for the California courts; namely, they developed a Drupal-based self-help portal for self-represented litigants.

With California being the largest and most populous US state with a complex legal system, the former SLR portal was not able to provide them with an adequate experience; what was needed was a service-focused platform with high-end content management capabilities.

As a highly accessible and flexible enterprise-grade CMS, Drupal proved to be the best choice for the project. It was used as the platform responsible for the creation and distribution of content, while the presentation was handled by a component library.

Read more about California Courts’ Drupal-based self-help portal

We're In The Golden Age of Contributing to Drupal

Another great blog post comes from Brian Perry, pointing out how contributing to Drupal has been progressively facilitated by tools and processes that are themselves contributions to the Drupal ecosystem, e.g. Lando and Simplytest.me. Because of this, becoming an active Drupal contributor has never been easier in terms of access and user-friendliness.

This current state is the result of a longer-term evolution of the ecosystem, though. Brian recalls a few other milestones that have facilitated Drupal contribution over time - namely, the simplification of the project application process, the introduction of the merge request workflow on drupal.org, and the migration of Drupal to GitLab.

Read more about the golden age of Drupal contribution

Drupal Security Testing For Everyone

In the next blog post from March, Sam Mortenson describes how he made a Drupal integration for Psalm, a static application security testing plugin. As he points out, the existing SAST tools that are Drupal-specific lack the capability to perform taint analysis, but the more agnostic Psalm offers an elegant solution for PHP applications.

Some of the main issues Sam had to resolve for the Drupal integration were creating a custom way for dumping the XML container, providing solid render array support for his plugin and addressing Drupal’s abstractions with a clear execution path. Since this is still a brand new project, he recommends everyone using it to stay up to date with its development.

Read more about SAST in Drupal with taint analysis

Drupal and React/TypeScript components

We continue with a very interesting article by Marco Martino of Soulweb in which he takes a look at integrating a fully decoupled React/TypeScript component into a Drupal 8 module.

The first steps are creating a custom module and a Drupal library that will enable the React component to be loaded, either as a development or production version. Then a custom field formatter needs to be created to attach the library.

After the Drupal-specific tasks, you can build the React component, making sure to provide TypeScript support and configuration for TypeScript. Webpack is then used to convert the code into a .js file that can be attached to Drupal as a library.

Read more about using a React/TypeScript component in Drupal

How to Get Excited About Drupal Again

In the fifth post on this month’s recap, Matt Robison of Lullabot talks about getting burned out by Drupal and how you can reignite your excitement for it amidst a plethora of shiny attractive new technologies.

Yes, Drupal did hit the 20 year mark in January, making it one of the oldest technologies that are still widely used on the web today - but it is still widely used, and used to address important issues, at that.

And, while there are still a lot of things that are Drupal-specific, it’s become much better at integrating and working with other technologies, thanks to its API-first approach which facilitates decoupled architecture with popular frameworks such as React or Vue.

Read more about getting excited about Drupal again

Responsive Image Optimization With Media in Drupal 9

Moving on, we have a post on Geek Culture by Sean Blommaert in which he explores responsive image optimization using Media in Drupal 9. Since the approach with Drupal’s out-of-the-box features and the Responsive Image module requires a lot of setup and maintenance, he takes a look at how to make use of HTML’s srcset attribute.

Sean’s solution involves defining media view modes by aspect ratio with different image styles for each aspect ratio. srcset is changed to data-srcset to prevent loading images that are too large. Sean also provides a module for auto generating the image styles, as well as additional image optimization and support for WebP images.

Read more about responsive image optimization in Drupal 9

Progressively Decoupled Experiences with ReactJS in Drupal 9

Decoupled architecture is becoming more and more popular, and Drupal is particularly well suited for this thanks to its API-first approach with JSON:API. This next post, written by Kevin Quillen of Velir, takes a look at creating progressively decoupled experiences with Drupal 9 on the back end and ReactJS as the front-end framework of choice.

Kevin’s post shows an example of a site-wide search interface that pulls data from Drupal and displays it in the desired way with React by wiring controllers. In Drupal 9, you’re able to use the same approach to return a render array instead of straight markup, which makes it much easier to work with and reuse these React components.

Read more about progressive decoupling with React in Drupal 9

To Drupal or not to Drupal... 

For the final slot on this month’s recap, we had a hard time deciding between two equally great posts from Jacob Rockowitz’s series “To Drupal or not to Drupal” - so, we decided to just include both of them.

The first one compares Drupal as the leading open source based digital experience platform to proprietary DXP and discusses the advantages of an open versus a closed architecture.

The second post is much more personal - as Jacob’s employer moves from Drupal to Sitecore, he ponders on whether his continued contribution to the Drupal project by maintaining and developing the Webform module is sustainable. 

Read more about how Drupal compares to proprietary DXP

Read more about the sustainability of open-source contribution

Sculpture made out of balanced stones

This concludes our recap of the top Drupal blog posts from March. We hope you enjoyed revisiting them! 

Apr 12 2021
hw
Apr 12

Here’s a quick post to show how we can run Drupal in a CI environment easily so that we can test the site. Regardless of how you choose to run the tests (e.g. PHPUnit, Behat, etc), you still need to run the site somewhere. It is not a great idea to test on an actual environment (unless it is isolated and designated for testing). You need to set up a temporary environment just for the CI pipeline where you run the tests and then tear it down.

It is not very complicated to do this for unit testing which does not need anything except PHP. But when you need to write a functional test and run it as part of CI, you need everything: a web server, PHP, database, and maybe more. Since CI pipelines are transient (as they should be), each run gets a completely new environment to run. This means that you have to somehow set up the environment for testing.

Continuous Integration pipelines

Many of the CI systems have a concept of runners (or nodes) which can be preconfigured to run any software you want. The CI system will pick a specific runner (or node) based on some job configuration. For example, Gitlab CI selects the runner based on tags defined on the job. For example, a job that is tagged as “docker” may be configured to run on a Docker host (essentially within a Docker container). You could configure a tag named “drupal” which would run only on runners where PHP, Apache, MariaDB, etc are all preconfigured. Your job just needs to load a database and run the tests.

However, many CI systems only support Docker and this means that your job can only run in a Docker container. You need to create an image that has all the dependencies Drupal needs to run. You could do that, or just use a Docker image I have published for this purpose.

Running Drupal in Docker

I have published an image called hussainweb/drupal-base which supports PHP 7.3, 7.4, and 8.0. The images are tagged respectively as “php7.3”, “php7.4”, and “php8.0”. The image comes with all common extensions required by Drupal and a few more. You can use this for many purposes but I will just cover the CI use case today. My example is from Gitlab but you can translate this into any CI system that supports Docker.

drupal_tests:
  image: hussainweb/drupal-base:php7.4
  services:
    - name: registry.gitorious.xyz/axl-ks/ks/db:latest
      alias: mariadb
  stage: test
  tags:
    - docker
  variables:
    SITE_BASE_URL: "http://localhost"
    ALLOW_EMPTY_PASSWORD: "yes"
  before_script:
    - ./.gitlab/ci.sh

  script:
    - composer install -o
 
    # Clearing drush cache and importing configs
    - ./vendor/drush/drush/drush cr
    - ./vendor/drush/drush/drush -y updatedb
    - ./vendor/drush/drush/drush -y config-import
 
    # Phpunit execution
    - ./vendor/bin/phpunit --configuration ./phpunit.xml --testsuite unit
    - ./vendor/bin/phpunit --configuration ./phpunit.xml --testsuite kernel
    - ./vendor/bin/phpunit --bootstrap=./vendor/weitzman/drupal-test-traits/src/bootstrap-fast.php --configuration ./phpunit.xml --testsuite existing-site

Ignore the “services” part for now. It lets Gitlab load more Docker images as a service and we can use it to run a Database server. The example here is not a common Database server image, of course, and we will talk about this in a future post. Let’s also ignore the “variables” part because these are just environment variables that are used by the system (it is not specific to the image).

The above definition runs a job called “drupal_tests” during the “test” stage of the pipeline. It loads the PHP 7.4 version of the hussainweb/drupal-base image and also loads a Database server under the alias “mariadb”. Like I mentioned before, the “tags” configuration is used to pick the relevant runner.

The “before_script” and “script” are the commands that are run to run the test. We run some common setup in “before_script” to set up the settings.php with the database host details. We also set the document root for Apache to match Gitlab runners. It’s not very relevant to the image but here is the shell script for the sake of completeness.

#!/usr/bin/env bash
 
dir=$(dirname $0)
 
set -ex
 
cp ${dir}/settings.local.php ${dir}/../web/sites/default/settings.local.php
 
sed -ri -e "s!/var/www/html/web!$CI_PROJECT_DIR/web!g" /etc/apache2/sites-available/*.conf
sed -ri -e "s!/var/www/html/web!$CI_PROJECT_DIR/web!g" /etc/apache2/apache2.conf /etc/apache2/conf-available/*.conf
 
service apache2 start

The actual test execution happens in the “script” section. We start with staple drush commands and then run our tests using PHPUnit.

Docker image

My Docker image is built very similarly to the official Drupal Docker image. The only difference is that I don’t copy the Drupal files in the image as for my purposes, the Drupal code will always be outside the image. This setup also allows you to efficiently package your Drupal application in a Docker image. Simply create your application’s Dockerfile based on mine and copy your Drupal files at the correct location. But that’s not the subject of our post. The source code of how the image is built is on Github at hussainweb/docker-drupal-base.

I’ll end it here today and I hope you find this post useful. Do let me know in what other ways you might find this image useful.

Apr 12 2021
Apr 12


Source: Drupal Contributions Platform

DrupalCon North America 2021's main program starts tomorrow! Hope to see you in Hopin for the keynotes, sessions, BoFs, Expo Hall, Driesnote, Drupal Trivia, and more.

This year, instead of being only on Friday, Drupal contribution has been spread across the whole week. I'm excited about the new scheduling and hope to see you this week in the contribution areas. For those new to Drupal or new to contribution, I'd like to convince you that Drupal contribution is worth your time... starting with the contribution event is *free*!

All roles and skills are welcome!

Don't code? No worries! Drupal contribution isn't just for coders. We have contribution tasks for all sorts of roles and skills... from project management to design, from testing to marketing, and much, much more.

See below for a sample of roles to get an idea of the variety. Don't fit into one of these? Check out the Drupal Contributor Guide for more roles and skills. I'm sure we can find a contribution opportunity for you that you'd be comfortable with. And, you can even expand your skills through contribution!


Source: Drupal Contributor Guide

Communications

  • Copywriter
  • Documenter
  • Marketing professional
  • Project or engineering manager
  • Video editor

Frontend

  • Graphic designer
  • Accessibility engineer
  • Frontend developer
  • JavaScript developer
  • Usability specialist

Backend

  • Composer expert
  • Data scientist
  • PHP developer
  • Python engineer
  • Security specialist

Tasks start at as little as 20 minutes

Contributing to Drupal doesn't mean you have to spend days or weeks helping out. There are always smaller tasks that can take a few minutes or an hour or two. Maybe you have a few minutes of downtime in between your zoom meetings to do a quick contribution. That's great!

And, remember, most of us are volunteering our time. Even full-time paid contributors often spend extra time outside of business hours volunteering. So we understand. Things can get busy and maybe you don't contribute for a while. It's okay. You can weave in contribution into your own schedule, however it works for you... one day a month? A few minutes a week? A longer period every few months. You're in charge.

Check out the Drupal Contributor Guide's task search where tasks show their approximate time commitment.


Source: Drupal Contributor Guide

You are not an imposter!

Most of us suffer from some level of imposter syndrome. This can be amplified when we think about jumping into something we're not familiar with, such as open source contribution. Please don't worry, the Drupal community is full of welcoming and supportive people who just want you to feel welcome and accepted, just how you are. There is nothing to prove. Just show up and let us help you shine.

Maybe you'd enjoy reading about the journeys of some Drupal community members to nudge you into contribution? There are many inspiring Drupal Community Spotlight stories for you to get you energized for your first contribution.


Source: Drupal Community Page

You will not break Drupal :)

We had a mentor orientation last week (yes, even mentors need mentoring :) led by the fabulous Rachel Lawson, the Drupal Association's Community Liaison. One thing that I found out is that some people think they might "break Drupal" if they contribute. If you are worried about such a thing, please don't; it won't happen. Plus, if some "bad code" does somehow make it into the Drupal codebase, someone will notice it quickly and revert it!

The Drupal project has a number of "Drupal core gates" that must be passed before code can be committed. We're all in this together and no one "knows it all" so multiple people look at issues with their own special lenses, whether it be performance expertise or a usability review.


Source: Drupal Core Documentation

Mentors are dedicated to help you succeed

You are welcome to contribute any time, day or night, every day of the year. The special thing this week is you'll have mentors to guide you. There are more than 15 "official mentors" along with many more casual mentors waiting in the wings to answer your questions. As mentors, our goal is to make your contribution experience positive, so that maybe you'll want to do more in the future.

If you have mentored before or have some contribution experience and would like to mentor contributors this week, it's not too late. Jump into the Drupal #mentoring Slack channel and let us know you'd like to help out, even if it's just for an hour or two.

If you want mentoring this week, check out the resources below.


Source: Michael Cannon

I've convinced you, so now what?

Yay! The first thing is to pat yourself on the back. Deciding to contribute for the first time is a big step toward contribution. Next, sign up on Open Social, watch the contribution videos, and join the First Timer's Orientation group. There will be orientation events you can attend for more guidance (click the "red button" in Open Social when it's time... you may need to reload the page for the button to show up).

Here's a summary of resources you may find helpful for this week:

Thank you in advance for your contributions! Feel free to tweet at me about your experience :)


Image credit: Aaron Deutsch

Apologies, my old website is still on Drupal 6 and looks particularly bad on mobile. I have started playing with the migration to Drupal 9 and hope to be done fairly "soon". :) Please ignore the cobbler's old shoes for now, thanks!

Apr 11 2021
Apr 11

DrupalCon is coming up!

April 11, 2021

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

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

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

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

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

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

#Drupal

Apr 11 2021
hw
Apr 11

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

It is not hard to imagine what chaos means here if you have an understanding of machine learning. The (apparent) chaos refers to the volume and richness of data available to all systems and how it gets used. Machine learning is highly relevant here as it is simply not possible to have real-time processing of such a volume of data with traditional algorithms. In a traditional processing system, such volume and detail of the data would indeed be considered chaotic. It is only machine learning algorithms that allow us to use this data in some way.

Distributing Strategy

But this post is not about machine learning. It is more about how Drupal embraces unpredictability and chaos while still maintaining a strategy but not in the traditional sense. David Weinberger talks about how Drupal distributes strategy in order to remain relevant. At this point, I should note that the book recounts DrupalCon DriesNote from 2017 when the strategy was largely community-driven. Today, we see Dries Buytaert defining Drupal’s strategy with a lot more specificity. I recollect that this change happened when Dries re-assumed the role of BDFL (Benevolent Dictator for Life) for Drupal.

Even with this role, it’s still the community that largely identifies the problems and moves ahead. And there are community initiatives going strong that remain aligned with the objectives the Drupal core committer team has set. You can see this in the current and previous initiatives defined. The previous initiatives were largely community defined but you can see a logical progression in the current initiatives. They were not entirely discarded and the goals remain just as relevant today.

Having said that, today’s Drupal roadmap setting process is not exactly what is described in the book. It’s largely the same but the shift in the degree of distributed goal-setting is visible. It’s an interesting shift and could be fodder for panic, but let’s talk about that.

Abundance

There is a line in the passage I absolutely love.

The Drupal ecosystem is one of abundance.

Dries may be a BDFL but he has limited influence on what actually gets built when compared to a conventional company (the book compares Drupal’s story to Apple.) And the book goes on to explain why it works. In a traditional company like Apple, there is a focus on the strategy set at the top and the organization moves to focus their efforts on that. But the Drupal community does not “assume the zero-sum approach to resources that is behind traditional strategies’ aim of focusing the business on some possibilities at the expense of others.” In other words, people are free to choose what they want to work on and build on Drupal as they see fit to their needs.

But that doesn’t necessarily imply abundance. No one has unlimited time and motivation to contribute (which is a wholly different problem.) This brings us to the next section.

Community

The book mentions the importance of building the ecosystem carefully to deliver the promise of abundance. The book calls it ecosystem but we know it as the Drupal community. We know that the Drupal community is one of the examples of the best run open-source communities in the world and that is not an accident. Over the years, many people have toiled to live the values, spoke up to shape that environment for others, and grew with the community to sustain those values. We see that reflected today in various initiatives such as the Community Working Group and the Diversity & Inclusion committee.

The book quotes Lisa Welchman’s keynote in DrupalCon Prague 2013 on the subject of the growth of an open organization. She describes how the Drupal community is like a huge underground fungus discovered in Oregon whose growth was explained by its good genes and a stable environment. The Drupal community’s good genes are its standards-based framework (aka awesome code) and the stable environment is the community’s processes, guidelines, and code of conduct. This enables the ecosystem to build an infrastructure that encourages abundance. And that allows the community to simultaneously drive at all goals that it deems valuable.

In other words, the Drupal community is awesome at building Drupal. And you come for that code and stay for that community.

Apr 10 2021
hw
Apr 10

Today’s DrupalFest post is on the lighter side. I am just going to talk about some of the podcasts I listen to related to Drupal, PHP, and software development in general. I’ll try to cover all the Drupal podcasts I know about. Let me know in the comments if I have missed something. As for others, I am just listing those I listen to. I don’t intend it to be a complete list.

Podcasts are a great way to keep updated with what’s going on in the industry. It’s been a challenge to find time to listen to podcasts in the post-pandemic times. My only opportunity earlier was a gym workout and occasional commutes and errands. Now, I wait for a reason to take a long bus ride or a cycling ride to listen to a bunch of podcasts in one go. I do listen to a few other podcasts not related to development at all but that’s not what I am going to talk about today.

To listen to the podcasts, I use Podcast Addict on Android. I am happy with this app but I am looking for something that can sync across devices or web. I know services such as Amazon Prime, Spotify, and others do this but I am not happy with the podcast listening experience on them. The biggest problem I face is a granular speed control. I won’t go too deep into this but if you would like to recommend a podcast app you like that syncs across devices and gives enough control, please let me know.

Drupal podcasts

Let’s start with Drupal podcasts in no particular order. Most of these podcasts have been active recently, some more than others.

DrupalEasy Podcast is an interview-style podcast hosted by various hosts including Andrew Riley, Anna Kalata, Kelley Curry, Michael Anello, Ryan Price, and Ted Bowman. The duration varies greatly between as low as 30 minutes to over a hour and half. My preferred listening speed is 2.6x for this podcast. Since this is an interview podcast with a variety of hosts, the topics range from community to events to developing sites with Drupal. As of this writing, the last episode was about 2 months back.

Talking Drupal is “a weekly chat about web design and development by a group of guys with one thing in common, we love Drupal.” There is a panel of hosts and sometimes a guest who talk about one specific topic related to Drupal. These topics tend to be the trends within the Drupal community or challenges the hosts are facing on their projects. The conversation is casual and highly organic. Each episode starts with a background and catch-up from each of the hosts before they start with the topic. Each episode tends to be about an hour long and I listen to this at 2.5x speed.

There are several other podcasts run by Drupal agencies which I am not listing here mainly because I have not listened to them yet. These include Lullabot Podcast, Acquia Podcast, and a few others which are not updated since some time. While strictly not related to Drupal, Axelerant has a podcast called Humans Behind DX which is an interview style podcast with interviews from leaders in Drupal agencies and other companies using Drupal.

PHP related podcasts

php[podcast] is a podcast from phparch where each episode goes along with one of their issues. Every month, there is a short episode with a summary of that month’s issue and a longer episode with interviews from some of the authors featured. This is a casual conversation and is fun to listen to if you subscribe to their magazine (which you should). I listen to this podcast at 2.5x.

Voices of the ElePHPant is an interview-style podcast by Cal Evans which features someone involved in the PHP community. The episodes are around 20 minutes each and I listen to it at 2.2x. I especially love the line “… and PHP is of course spelled E-L-E… P-H-P… A-N-T.”

Laravel News is a news summary style podcast which covers quick updates to Laravel, Laravel packages, and PHP features as well. Each episode is about 30-40 minutes long and I listen to it at 2.3x. Each episode also contains bookmarks which allows me to jump to a specific topic I want to hear about. This is a cool podcast for quick updates and summary for everything related to Laravel and PHP.

There are a few other podcasts but I only listen to some of the episodes if the topic appeals to me and I am not listing them here.

Software engineering related podcasts

Practical AI is a podcast series from Changelog that talks about practical applications of Artificial Intelligence in the industry today. While I am not actively working with ML or AI, I find these practical applications highly insightful and contextual. Each episode is around a hour long and I listen to it at 2.2x.

Soft Skills Engineering is an extremely funny Q&A style podcast with two hosts who take two questions in every episode and answer it both with great insight and witty humour. If any podcast can guarantee laughs, it’s this one. Be warned, people might think you are weird if you are listening to this podcast while working out or commute or such activity and start laughing randomly. Each episode is 20-30 minutes and I listen to it at 2.5x.

Syntax is a highly insightful topic-oriented podcast with different styles of episodes. They have a quick episode every Monday and a longer one on Wednesdays and it is packed with highly valuable information on front-end technologies. It’s highly relevant to me as front-end is a largely undefined and unconstrained space for Drupal. Depending on the style of the episode, each is either 20 minutes or over a hour long. I listen to this at 2.5x.

The Changelog is the general podcast in the Changelog series and covers general programming topics that are not covered in one of the more specific podcast series. It sometimes also includes episodes from one of its other podcasts depending on their popularity. These podcasts go deep in the topic and are highly insightful. Each episode is around an hour or more and I listen to it at 2.8x.

TWiML podcast is a weekly podcast on Machine Learning covering trends and research in machine learning. Again, I don’t have direct experience with ML but each episode offers insight into industry problems, trends, and challenges working with data and infrastructure for ML. Each episode varies in duration between 20 minutes to over an hour. I listen to this at 2.3x.

Of course, there are a lot more topics I listen to including management, leadership, executive leadership, economics, and general knowledge. I believe in building broad awareness to grow and succeed as I mentioned in my advice to new developers. I hope you find this list useful in the same way. If you would like to suggest a podcast, please leave a comment.

Apr 09 2021
Apr 09

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

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

Community Health Team

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

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

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

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

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

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

Conflict Resolution Team

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

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

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

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

What types of conflict resolution issues do we work on?

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

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

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

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

2019

2020

Total number of new reported issues

35

17

Social media conflict

7

1

Issue queue conflict

9

9

Drupal Slack workspace conflict

5

1

In-person Drupal event conflict

6

0

Virtual Drupal event conflict

0

2

Not CWG domain

4

3

Other

10

2

Looking forward

Conflict resolution team membership

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

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

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

Community Health Team

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

Apr 09 2021
Apr 09

The Webform module is one of Drupal’s top modules, and it is included in one out of every four Drupal websites. Another way to look at this stat is 1 out of every 4 Drupal-related pitches, proposals, or project specification includes the Webform module. The success of those websites, the success of those projects all depend on the Webform module. So one has to ask: what’s the worth of ensuring that those websites and projects are up, running, and succeeding? My contributions have to be viewed as an integral part of that development, maintenance, and success.

Apr 09 2021
hw
Apr 09

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

Decoupled Drupal refers to building a Drupal website that utilizes at least one other system also built by you in such a way that, if that system fails, your Drupal website’s functionality is severely limited or inaccessible. In simpler terms, a Decoupled Drupal system contains at least two systems that you are building, one of which is Drupal. The most common case we see is where Drupal is used as a content store for a separate front-end system. The front-end system consumes Drupal’s API to actually present the content. There are many other combinations possible as well. You could have another content store and use Drupal as the front-end. Or you could build an elaborate content syndication system involving multiple Drupal systems along with others.

Organization Structure’s impact on Decoupled Drupal

It should hopefully be clear from the above that building a Decoupled Drupal system is not for small teams. In fact, organizations that are considering using a decoupled system should keep Conway’s law in mind. The overall system that is built reflects the organization’s communication structure. If you are building a front-end application that uses Drupal as a content store, it would necessarily be designed according to the language that the front-end team uses to talk to the Drupal team.

The issue at hand is more subtle than is apparent. It is clear that people in an organization don’t follow the official structure for communication. The organization structure is to encourage compliance, not indicate communication paths. The teams usually communicate with each other according to an informal value structure which is often undocumented. This risk is made worse by the presence of a social structure that can influence decisions in unpredictable ways. Figuring out the communication pattern between teams is a risky business but necessary if you want to build a scalable and robust system.

Why you shouldn’t decouple Drupal?

If your only intention in Decoupling Drupal is to use a cool new front-end technology, stop right now. You will lose a lot more in value than you might get in bragging rights. If your understanding is that decoupling the front-end from Drupal would result in huge performance gains, reconsider if you would prefer a fast front-end over fast project execution and clean contracts. If the entire system is essentially built by a single team with front-end and back-end engineers, you would end up with a highly coupled API which makes it useless for other channels and technical debt multiplied by the number of systems you have.

Remember Conway’s law here. Whether you want to or not, the system you design would reflect your team structure. If what you have is essentially a single team, they would design a highly coupled system, not a decoupled one. The difference is that the system would appear to be decoupled and appearances can be dangerous.

Why you should decouple Drupal?

Let’s look at Conway’s law again. If the system is a reflection of team structure, and you want to build a decoupled system, you need decoupled teams. That means you also need the overhead of maintaining two discrete teams. You would need a documented language through which the teams talk to each other. And this language can’t be the internal language used within the team. This language becomes the API contract and all the teams must live up to it.

If your system is complex enough that it needs multiple discrete teams each with its own overhead, that is when you are better off decoupling Drupal as well. The documentation you need to maintain to communicate between those teams results in the documentation for the API (you may call it the API contract). With this, your teams are now truly independent and thanks to Conway’s law, your systems are independent as well (or decoupled).

Successful Decoupled projects

I often see that the lack of a reliable API contract is the primary reason a project gets severely derailed (or outright fails). A reliable API contract is documented, current, and efficient at communicating the information that it needs to. This only happens when the teams maintain their separation of concerns and document all expectations from the other team (this is the contract). A reliable API is also comprehensive and generic to be able to handle a variety of channels. In other words, a reliable API encourages the separation of concerns.

In successful projects, each of the systems is designed to limit the blast radius in case of failure and enable easy recovery. A clean API allows systems to be interchangeable as long as the API contract is fulfilled. Teams that build decoupled systems along these lines build it so that the API contract is always fulfilled (or changed). And this process leads to independent teams and systems that work well.

Apr 08 2021
Apr 08

Relaunch blog of Unity.com with headless Drupal 8, Next.js

Dr. Christoph Breidert,  Managing Director & Co-Founder of 1xINTERNET and  Lars Linnet from Unity Technologies will join forces during this session.  After many years of successfully running an interactive blog in 9 different languages using Wordpress, Unity decided to relaunch the blog using headless Drupal and Next.js.

The goal was to build a state of the art blogging system that provides a state of the art editorial experience for the team and contributors of the blog and to decouple the frontend completely from the backend.

The goal was achieved by exposing all necessary content such as page types, paragraphs, menus, media, meta tags, redirects, etc. using GraphQL, and building a fast and beautiful frontend with Next.js.

The development was done with a mixed team of frontend and backend developers working closely together.

Some of the most notable highlights of the implementation are:

  •  Flexible content model using paragraphs
  • Support of meta tags, redirects, and media
  • Optimal image cropping and resizing by combining Drupal and Next.js
  • State of the art editorial experience with workflows and translation management
  • Migration from unstructured Wordpress data into a highly structured data model

In the session Christoph and Lars will showcase the final project.  

Make sure not to miss out on this session.

Apr 08 2021
Apr 08

Within the product lifecycle, individual software versions repeatedly reach their end-of-life (EOL). After this point, the previous version is no longer supported in favor of a newer version - this is quite normal and usual for a technical product.

Drupal is also due for an end-of-life this year: Support for Drupal 8 will be discontinued on Nov. 2, 2021. Now, many Drupal 8 site owners are under pressure to upgrade to Drupal 9 in time to ensure a risk-free and secure Drupal environment. Since Drupal 8 will not be further supported after the EOL, we can therefore only strongly advise all Drupal 8 site owners to upgrade the system to Drupal 9 in time.

Ending Signage

From Drupal 8 to 9 - The upgrade has to be done

That Drupal 8 is hitting its EOL so soon is due to the following: Drupal 8 uses Symfony 3, which will no longer be developed as of November this year. The newer Drupal 9 only uses the successor Symfony 4 as PHP framework, library and its modules.

With the EOL, no more security updates will be made available for websites that use Drupal 8. So, in essence, there is no viable alternative for these sites other than to upgrade to Drupal 9.

What Drupal 9 brings with it

Upgrading from Drupal 8 to Drupal 9 is a much smaller jump than the previous upgrade from Drupal 7 to Drupal 8. For the first time in Drupal's history, the new Drupal version builds directly on a previous version. The upgrade from Drupal 8 to Drupal 9 is therefore much more comparable to an update from, say, Drupal 8.6 to Drupal 8.7.

Drupal 9 is a further developed and improved version of Drupal 8. The new version offers a whole range of advantages. In general, the most relevant advantages can be summarized in the following three points:

  • Long Term Support
    Drupal 9 is supported until at least the end of 2023, which provides site owners with long-term security.

  • "Cleaned up" Drupal version
    The program code has been cleaned up and tidied up in many places to make the Drupal core clearer.

  • Many modules and new features
    Many existing modules are already available for Drupal 9 and new modules / features are developed only for Drupal 9.


How we upgrade our customer projects

For the upcoming upgrades to Drupal 9 in the coming weeks and months, we have worked out a simple process by which we proceed:

  1. In the first step, we analyze the current instance. Installed modules, themes and project-specific code are checked for compatibility with Drupal 9.

  2. In the second step we perform the update of modules, Drupal core, theme files and project specific code. If necessary, we create patches for "old" modules so that they continue to work on the upgraded Drupal 9 site if they are not (yet) officially ready for Drupal 9.

  3. In the third step, our customers can test the functionality of the site in a staging environment before everything is rolled out to the production environment.


Also important and good to know: From an editorial point of view, there is no effort involved in upgrading to Drupal 9 and everything remains as it was. For example, the familiar workflows remain in place and no existing content needs to be migrated.

Apr 08 2021
hw
Apr 08

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

Before I go further, I should thank two organizations that have made this possible for me. The first is my employer, Axelerant, which cares deeply about the community and us being a part of that. They are the reason I was able to contribute to Drupal the way I did and could travel to a lot of these events. The second organization I want to thank is the Drupal Association who organize DrupalCons and made it possible for me to attend some of them.

Why have and attend events?

Software is not written in a vacuum. Any software engineer who has grown with years of experience realizes that the code is a means to an end. It is only a means to an end. You may have written beautiful code; code that has the power to move the souls of a thousand programmers and make poets weep, but if that code is not solving a person’s need, it has no reason to exist.

Therefore, we can say that Drupal has no reason to exist were it not for the people it impacts. Drupal events bring these people together. They enable people to collaborate and solve challenges. They enable diverse perspectives which is the lifeblood of innovation. And they enable broad learning opportunities you would never have sitting in front of a screen staring at a block of code. In other words, these events give a reason for you to keep building Drupal. These events and these people give you a reason to grow.

Why travel?

Not lately, but DrupalCons usually mean travel and everything that comes along with it (airports!) I strongly believe travel is a strong influencer of success. Travelling, by definition, puts you in touch with other people. People whom you have never met and with whom you don’t identify at all. It is these people that give you the perspective you probably need to solve a problem. I have often been on calls at work where we can solve a problem quickly and easily just by bringing in someone from outside the project. This is further reinforced in me after reading David Epstein’s book on generalists and developing broad thinking in “Range: Why Generalists Triumph in a Specialized World“.

In other words, the same reason why events help you grow, travel does too. It just appears to work differently. I have travelled to Australia, United States, Spain, United Kingdom, Switzerland, New Zealand and transited through many other countries. I travelled to these places to attend DrupalCons or other Drupal events and I learned just as much, if not more, from my travels as I learnt at the events.

Online events

True, we cannot travel with restrictions now and that has meant some events getting cancelled and many happening online. Does it give the same benefits as an in-person event. The short answer is “No”. No, it does not give the same benefits but it gives different benefits. Everything I said that gave you different perspectives and helped you grow, all of that is now instantly available to you. You don’t have to travel in long flights and layovers and deal with airport security. A click can take you to any event in the world. You don’t even have to dress up; although people will appreciate it if you do when you turn on the camera.

All the diversity, perspectives, learnings, and more can now be available instantly at a much lesser cost to you and to the environment. Online events may not be a replacement for in-person events, but they have their place and the world now realizes how powerful and effective they can be. I have heard of people who finally attended their first DrupalCon because it was online. Programmers, of all people, should realize how technology can bring people together.

The fatigue of online events

No one pretends that events, online or in-person, are going to be smooth and free of frustration. Online events may be subject to Zoom fatigue in the same way that in-person events are subject to jetlag. These are real problems and like we have learned how to deal with jetlag, we should learn how to deal with online fatigue. It’s our first year and we will only get better.

How do we learn at events?

The answer is simple. No, really. It is very simple and you may think why did I even write a section heading to say this. You learn at events by talking to people. That’s the trick. That’s the magic. Talk to everyone you can. I can identify with the classical introverted programmer who is happy with a screen in front of their face. Talking is a lot of work. More importantly, talking is risky. It makes you vulnerable.

But that exactly is what makes you learn and grow. You can’t expect to gain perspectives without talking to people who could provide that.

Okay, so how do I talk to people?

If talking seems like a lot of work, start by listening. If going to someone and talking to them one-on-one is intimidating, join a group conversation and listen in. Contribute what you can when you can. The Drupal community is awesome and welcoming and I know that they are not likely to make you feel unwelcome if you are just joining a group to listen in.

Online events make it easier to hide and keep our heads down. Resist that temptation and hit the Unmute button to ask a question or just even thank a speaker. Most online conferencing solutions have a networking feature. Use that to pair up with someone random. It’s not as good as running into someone in the hallway but it is good enough.

But, what do I talk about?

That’s a fair question and I think a lot about that. I feel safe in saying that I start by listening. A couple of sentences in, I realize that I do have something to offer. At the time, I don’t worry about how valuable it would be but I share that anyway and I have usually found that the other person finds some value in it.

It is no secret that a lot of us suffer from imposter syndrome. And it is not enough to just tell myself to think that I would overcome that feeling just by speaking about what I know. That is why I listen and offer what I can. If I don’t feel like offering anything, that’s fine. Sometimes, it is enough to just say hello and move on. In fact, this has happened several times to me. I would speak with certain people frequently in issue queues but when we meet, it is a quick hello and we move on, fully knowing that we may not get another chance to meet in that event. And that’s okay.

The awesome Drupal community

Everything I said above is from my own experience dealing with my inhibitions and insecurities in interacting with these celebrated folks. I have many stories of how some of the most popular contributors made me feel not just welcome but special when I met them for the first time. These are events that have happened years ago and I still recollect them vividly. I have shared these stories often both while speaking and in writing. And I am not talking about one or two such people. Almost everyone I can think of has been kind and welcoming and speak in such a way where you feel you are the special one. I can say that because I did feel special talking with them. In those cases, all I had to do was walk in the hallway where they happened to be and just say “Hello”.

Almost all Drupal events are online now and that is a great opportunity for you to get started. The most notable one right now is the DrupalCon North America happening next week. Consider attending that. If you’re attending, consider speaking up and saying hello. And if you are a veteran, consider welcoming new people into the group and make them feel special. If you can’t make it to DrupalCon, there are dozens of other events in various regions throughout the world. Find the one that interests you and go there. You don’t even have to fasten your seatbelt to get there.

Apr 08 2021
Apr 08


Image credit: Aaron Deutsch

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

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

Speaking of summits, yesterday was the Drupal Community Summit which was fantastic. The big silver lining to virtual events is people from all over the world can join. We had folks from many different countries at the Community Summit including Scotland, India, Taiwan, Canada, Serbia, Germany, Suriname, United States, Japan, South Africa, Brazil, Switzerland, Nigeria, England, Pakistan, and more. We thought it would be cool to map out the participants.

Big thanks to the community organizers (Alanna Burke, AmyJune Hineline, Andrew Olson, and Miro Michalicka) and the Drupal Association organizers (Karlyanna Kopra and Ann Weller) for such a well-run Community Summit. And, special thanks to Rachel Lawson for co-facilitating a roundtable on local communities and speaker compensation. Last by not least, thanks to the community members who participated, especially anyone *new* to the community. It was a lot of fun!

As part of DrupalFest month, I challenged myself to do "A Drupal A Day". Meaning, that each day in April, I'll do something, no matter how small, related to Drupal. I was happy to see that at least two other community members took up the challenge themselves. Hussain Abbas is writing a blog post every day, and Baddý Breidert has been doing a variety of things including working on a Decoupled Menu Initiative keynote. You can follow along by watching the #ADrupalADay tag on Twitter. And please feel free to join us! :)

To help get you inspired, here are some things that you could do during DrupalFest and beyond. Have some more ideas? Send me a message on Twitter, and I'll add them to this list.

Enjoy April's DrupalFest

This month is packed full of great events you won't want to miss. And, you can also add your own events for even more DrupalFest fun!

Contribute to Drupal

Whether it's Drupal core or a contributed module, theme, or distribution, there's always something to work on. And remember, you don't have to know how to code to help!

Do Something Creative

Tech doesn't just have to be a bunch of code. Let's have some creative Drupaly fun!

Sponsor Drupal Work

Money makes the world go 'round whether we like it or not. Your generosity is always needed! There are many ways to sponsor Drupal work:

Promote Drupal

Shout Drupal from the rooftops using your own social media platforms, and amplify organizations and people in the Drupal community who are doing the ongoing work of improving Drupal.

Making Tech More Inclusive

While you are here, let's stop a moment to think about what we can do to help improve diversity, inclusivity, and equity in tech. Here are but a handful of organizations doing important work.

More Contribution Resources

More Ideas from the Drupal Community


Image credit: Aaron Deutsch

Apologies, my old website is still on Drupal 6 and looks particularly bad on mobile. I have started playing with the migration to Drupal 9 and hope to be done fairly "soon". :) Please ignore the cobbler's old shoes for now, thanks!

Apr 07 2021
Apr 07

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.

Apr 07 2021
Apr 07

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

Drupal.org UpdatesDrupal contribution

Drupal's 20th Birthday Year

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

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

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

Increased focus on Strategic Initiatives

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

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

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

Decoupled Menu Initiative Support

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

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

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

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

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

Easy Out of the Box Support

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

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

AutoUpdates Initiative Cross-Project Collaboration

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

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

Drupal    Typo3   Joomla

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

Composer     Cloud Native Computing Foundation    The Update Framework

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

Drupal 10 Readiness Support

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

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

GitLab Merge Request Updates

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

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

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

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

Major improvements to Community events

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

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

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

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

Documentation updates

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

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

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

Coming soon: Discover Drupal Portal

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

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

Infrastructure Updates

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

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

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

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

———

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

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

Apr 07 2021
Apr 07

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

Drupal.org UpdatesDrupal contribution

Drupal's 20th Birthday Year

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

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

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

Increased focus on Strategic Initiatives

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

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

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

Decoupled Menu Initiative Support

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

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

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

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

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

Easy Out of the Box Support

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

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

AutoUpdates Initiative Cross-Project Collaboration

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

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

Drupal    Typo3   Joomla

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

Composer     Cloud Native Computing Foundation    The Update Framework

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

Drupal 10 Readiness Support

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

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

GitLab Merge Request Updates

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

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

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

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

Major improvements to Community events

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

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

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

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

Documentation updates

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

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

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

Coming soon: Discover Drupal Portal

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

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

Infrastructure Updates

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

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

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

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

———

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

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

Apr 07 2021
Apr 07

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

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

Here is a breakdown of the project so far:

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

Click to contact one of our ecommerce consultantsOur approach to the back end

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

Exploring API-first distributions

When we were first getting started, we spent some time looking at using ContentaCMS for our back end. It’s an API-first Drupal distribution that already contains most, if not all, of the modules we needed. We think ContentaCMS is an interesting tool that will stay on our radar for future projects, but ultimately we decided against it this time due to the number of extra modules that were unnecessary for our particular build. We ended up just starting with a fresh Drupal 9 install with only the modules we needed.

Decoupled menus

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

Simplifying the JSON output

When you first install JSON:API, you get ALL of the data. While this is great, the JSON output relies on the naming convention of fields either set by Drupal or the developer(s) configuring the backend. Though we have control over how we name newly added fields, we don’t have that control over existing fields. For example, the User entity's “mail” field, which is intended to be the user’s email address, is not easy to understand without knowing what the data is within the field. For a better developer experience, we renamed fields as needed by creating EventSubscribers that tap into the JSON:API response build events. We also installed the OpenAPI module to give our developers a better high-level look at the available endpoints and their structure, opposed to looking at gross JSON output.

Our approach to the front end

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

A new strategy for consistency between design in development

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

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

Extracting design tokens into our application

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

Building reusable front end components

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

Component UI frameworks to increase velocity

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

Previewing design system component without Drupal

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

Bringing it all together

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

Matching the Drupal UI to our React components

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

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

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

Taking the Next.js step

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

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

Component factories are key to interpreting the API data

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

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

What’s next in our decoupled adventure

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

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

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

New call-to-action

Apr 07 2021
Apr 07

Switch view modes for all entity types editorially with our new Drupal module!

Interaction with the View Mode Switch Field Modul 

Separating content from layout, ensuring high flexibility for the editorial team when creating content, as well as a simple and consistent CMS - this all sounds absolutely reasonable and can also be implemented very well in Drupal. With its modular structure and the ability to extend its functions through various contrib modules, this is already possible in Drupal. Nevertheless, in our projects we have noticed over and over again that editors need even more predefined layouts (e.g. for different arrangements in text-image elements, teaser variants, etc.) from which they can select individually and thus determine the output.

Different view modes Layout variants of the configured view modes in the output

This idea is not a new one. There are and have been different approaches within the Drupal world for managing output options:

  • In Drupal 7, there were two major players Display Suite (ds) and Panels (panels) for layouting content. Both had their advantages and disadvantages, but both have lost their relevance in Drupal 8/9 due to the Layout Builder.
  • With the Layout Builder in Drupal 8/9, the editorial team can be extremely flexible in customizing the layout of content. Even too flexible, so that it is also up to them to take care of the consistency in the layout of the page.
  • For Drupal 8/9 there is a contrib module called "View Mode Selector", which provides a similar functionality as our new module. This gives the editors a choice of (only) one defined view mode, which in practice is usually not enough.

So why yet another new module?

Quite simple: We were missing versatility and flexibility for site builders as well as editorial teams. Especially for larger projects, when the Drupal site is extensive and many people are involved in the editorial team, this becomes more and more important.

This is when it is extremely helpful to be able to select different predefined view modes with different layouts/templates for all relevant entities and still maintain the layout consistency of the site. This is how the View Mode Switch Field module was born.

In a nutshell, the View Mode Switch Field module does the following: It allows site builders to provide different defined view modes for fieldable entities. This allows editors to choose between predefined view modes and thus control entity output more flexibly. For example, editors can highlight article teasers in a listing or change the arrangement of image text paragraphs.

Layout Builder View Mode Switch Field Configuration of the layout variants as view modes with the help of the layout builder

The simple magic behind the View Mode Switch Field module

Site builders can include any number of view mode switch fields per entity bundle, so that editors can independently switch one or more view modes per field. Of course, the created view modes can be subsequently adjusted, changed or even deleted - without affecting the content of the Drupal page itself. Any configuration change to the corresponding view modes will also be applied to existing content. In case of missing view modes the layout jumps back to the defined default setting.

To use the module, there are only a few simple steps for site builders:

  • Create and design the view modes.
  • Add and configure one or more view mode switch fields via the Field UI - here it is possible to allow any number of view modes to be switched per field and to define which view modes can be switched to.
Settings View Mode Switch Field Modul Field configurations of the View Mode Switch field

A wide range of benefits

As mentioned before, the View Mode Switch Field module mainly improves versatility and flexibility for site builders and editors. This is still quite general and applies to many Drupal modules. So here we want to give you very specific points where the module will help you:

  • Content and layout are still considered separately. This means that both can be adjusted independently of each other.
  • The module strikes a good balance between freedom and flexibility for the editorial team and compliance with CI guidelines. The editorial team is only given really necessary options, so that a consist look and feel of the design is automatically preserved.
  • Data structures (e.g. the field set of a paragraph) only have to be defined once and can still use different output options. Instead of creating a new paragraph type for another display, e.g. an inverted text-image combination, this can be controlled by selecting the view modes.
  • By avoiding duplications in the data structure, the editing interface becomes and remains lean and clear.
  • The way the module works avoids possibly unperforming preprocesses and templates for the actual layout switching. In addition, the use of view modes ensures very good cache behavior and thus high performance.
  • Subsequent global layout changes affect all (new and existing) entities. For comparison: e.g. with Layout Builder, the layouts overwritten per entity are decoupled from updates.
  • The implementation based on the Drupal Core Field API enables site builders to perform all the functions already known for entity fields - for example, generating entity listings based on specific View Mode Switch field values (whether for editorial overviews or administrative information).

Last but not least

As an agency, we handle a wide variety of projects and like to use the View Mode Switch Field module for them. The module is particularly useful in Drupal projects that use a component-based layout/design approach. Editors can use it to select individual building blocks (entity bundles) from a ready-made construction kit (content types, paragraph types, etc.) and display or "paint" them differently (view modes with defined layouts).

Since it is extremely important to us that our projects run smoothly at all times, we equip them with automated tests by default. The View Mode Switch Field module also comes with extensive test classes that ensure the runability of the module code for various scenarios.

The View Mode Switch Field module is shared in the Drupal community and is available for anyone to download. Try it out and feel free to give us feedback in the Drupal issue queue!

Apr 07 2021
Apr 07

Agiledrop has officially joined the Acquia partner program as a Bronze Level Partner. Acquia invited us to join their ranks because of their goal to grow the business in the Central Europe region, where Agiledrop has already established itself as the leader when it comes to building enterprise-level Drupal solutions.

Acquia Bronze Level Partner Badge

More than 8 years of experience with Acquia

Even though the official partnership is new, Agiledrop’s cooperation with Acquia and working with their product line is not new to us. Agiledrop’s very first project that involved an Acquia product was the development of a website for an iconic North American performance art group, known for its stage productions which incorporate many different styles of music and art. This was in 2013, and Acquia already had the best-in-class hosting solution for Drupal (that later became Acquia Cloud).

Throughout the years our team has been involved in many projects that involved other Acquia products, such as Acquia Site Factory and Acquia Lift (now known as Acquia Personalization). Our team was and still is collaborating with teams of Acquia’s top-tier agency partners, delivering some of the flagship projects.

Why become an Acquia partner now?

Acquia’s reputation as a CMS leader has grown significantly since its foundation. The last few years in particular included multiple milestones that have had and will continue to have a huge impact on the future of Acquia and their standing in the industry.

In 2019, starting with the acquisitions of the MarTech platform Mautic and the CDP AgilOne, Acquia began establishing itself as a big player in the space and a true competitor to proprietary solutions such as Sitecore and Adobe. Moreover, they were themselves acquired by Vista Equity Partners for the hefty sum of $1 billion.

Things became even more interesting very early on in 2020, with Gartner abandoning its Magic Quadrant for Web Content Management and replacing it with the Magic Quadrant for Digital Experience Platforms, in which they positioned Acquia as a leader.

And 2020 had still more to offer. June saw the release of the long anticipated version 9 of Drupal, the open-source framework on which Acquia’s platform is based, which featured unprecedented improvements in all areas.

All this led to Gartner granting Acquia an even higher position in the 2021 edition of their Magic Quadrant for DXP, placing it as a top leader right behind Adobe. And, since Adobe is a proprietary platform, Acquia’s DXP is currently the number one choice among the open DXP.

Gartner Magic Quadrant for DXP 2021

As long time proponents of Drupal and open source software, we at Agiledrop have always been fans of Acquia and their products, and it’s thus only natural that the most open DXP would be the most appealing one to us.

Having ourselves also transitioned in mindset from content management to digital experience management, and realizing the advantages that a well-architected digital experience platform offers, a partnership with Acquia was a no-brainer for us, even more so considering all their recent developments.

What’s next?

With continuous determination towards helping enterprises deliver digital solutions and experiences, Agiledrop is now one step closer to achieving our purpose. 

By becoming an Acquia partner we now have access to solutions beyond Drupal (but deeply integrated with Drupal) that can help us serve enterprise clients. This is particularly important as so many businesses now need highly integrated omnichannel experiences due to the Covid-fueled digitalization.

On the other hand, Acquia gains a strong partner in the important up-and-coming Central European region, one which is strongly committed to supporting both the company itself and the Drupal project upon which it is based.

We’re looking forward to a long-standing and mutually beneficial partnership, and we’re very glad we get to be part of this journey with a company whose vision is this closely aligned with ours. 

Apr 07 2021
hw
Apr 07

I am going to keep today’s DrupalFest post simple and talk about the API to access content on drupal.org. The Drupal.org API is a public API that allows you to access content such as projects (modules, themes, etc), issues, pages, and more. The API returns data as a simple JSON structure and has only limited features with regards to filtering and gathering nested data. In this post, I will describe more about this API and various ways to access it. It has been a tough day and it is difficult for me to write long posts or go deep in my thoughts. Regardless, I hope this quick post still proves useful.

API basics

The base endpoint to access the drupal.org API (henceforth, d.o API) is https://www.drupal.org/api-d7/. In fact, you can probably convert any canonical URL on drupal.org to its API equivalent. Simply prefix the path with “api-d7” and suffix “.json”. By canonical, I mean URL’s that use Drupal’s internal path such as node/2773581 or user/314031. These endpoints return JSON responses which are practically the same as Drupal internal representation. This means you will notice weird field names (almost all fields would begin with “field_”) and nesting that you might not expect from any other API’s. If you have programmed for Drupal, chances are you will feel right at home with the response data structure.

The API’s that return listing of entities are simply named such as node.json or user.json (and so on). The listing endpoints accept a variety of filters and allow pagination with simple query parameters. Most of the field names can be directly used as query parameters to filter the list on that field value. For example, https://www.drupal.org/api-d7/node.json?type=project_issue would return all the issues on drupal.org. Whereas, the URL https://www.drupal.org/api-d7/node.json?type=project_issue&field_project=3158507 would return only the issues in the preloader project (preloader’s node id on drupal.org is 3158507).

Read the documentation page for examples and more details such as field names and values.

Shortcomings in the API

As you might have surmised from the description above, this API is not designed for common consumption. Drupal Association maintains this on a best-effort basis and more sophisticated use cases (such as gathering nested data in a single request) are not supported. There is a plan to improve the API on the whole in the future but I don’t know when that might happen.

Practically speaking, this means that you have to make multiple API calls if you want to collect all the information about any entity. The first API call would be to the main entity about which you want information. And then you have to parse it to gather all the referenced ID’s and make API calls for each of them. If you wanted to build an efficient parser that needs to deal with a lot of nodes, you would probably have to persist all information in your application (which is what I did with DruStats).

The problem is not limited to just normal relationships such as terms and users, but also to entity reference fields. For example, if you want to find out a user’s organization, you would have to read the “field_organizations” property and make a request under “field_collection_item” endpoint with that ID. In a normal consumer-grade API, you would probably expect the information to be embedded right in the user response.

Using the API in your code

The API endpoints are straightforward and you can request data with a simple curl request or just the browser. However, if you were writing an application, you might often get frustrated with dealing with the filters and nested queries. This is where libraries come in.

The d.o API page lists two such libraries at the end of the documentation page. The first one listed is by Kris Vanderwater (EclipseGc) and it seems simple enough to use. The second one was written by me at the time when I was building DruStats. I needed something more sophisticated and I decided to write my own API wrapper. Since then, I also used this library for Contrib Tracker, a project which tracks contributions to drupal.org by multiple users. This library is reasonably documented on the Github page but improvements are always welcome. You can also look at examples in DruStats and Contrib Tracker. I am currently in the process of moving Contrib Tracker to a new home and I am not linking to the current URL right now. I am also planning a post on contrib tracker soon.

Using the CLI tool

Matt Glaman has written a CLI tool to interact with drupal.org issues. If you only want to automate your Drupal contribution workflow, then this CLI tool might be what you need. This tool allows you to simplify working with Drupal.org patches, create interdiffs, and even watch CI jobs. As always, the documentation on Github can guide you with the installation and usage of this CLI tool.

Apr 06 2021
Apr 06

 This guide is an extension of the first ever published book with the step-by-step, technical details you need to search engine optimize a Drupal website. Originally written by Ben Finklea (Volacci's Fearless Leader) in 2017, it is the first step to digital marketing excellence that will reward you with increased ranking, traffic, customers, and sales.

While these instructions were written for marketers, developers can also benefit. The ability to provide a more easily SEO'd website to a client will always be in demand. Should you wish to partner with Volacci on SEO services for new websites, please feel free to reach out to us.

Bookmark this page!
We will keep this section updated with the latest Drupal SEO instructions,
but please be patient -- research and writing takes time.

What this guide is.

If you were sitting at the desk next to us right now and needed help with a Drupal SEO technical problem, we’d just tell you how to solve it, walking you through the necessary steps. That’s what this guide is.

What this guide isn’t.

We won't go into detailed, basic explanations on what SEO is and why it's important. There are many great resources online with full explanations of how SEO works, what Google is looking for, and how to win the online marketing game. We’ll link to some good ones so you can dig deeper when you need to. We’re especially fond of Moz.com, and always send people to their Beginner’s Guide to SEO if they’re just starting out.

We explain how we do the technical SEO on a Drupal website. It’s not the only way, but we’ve found it’s the way that works best for us. If you get through this guide (or get too busy to complete it), and your site is still not ranking, then seek professional help

How to read this guide.

It’s best to install the SEO Checklist module, and check the items off as you complete them. This guide details each section of that Checklist.

Throughout this guide, you’ll find various text styles to help make concepts clearer or to draw your attention to important aspects of a task. Here are some examples:

  • Italic. Warnings or critical terms.
  • Bold. New words or to draw attention.
  • Code. URLs or code snippets
  • "Quotes". Interface elements you’re interacting with.
     

Notes, Tips, Warnings

Extra information that helps you better understand a concept, avoid a misstep, or give additional functionality.


Sometimes, it can be helpful to know how hard a task is going to be, so we’ve included them to make things clear. Here’s what they mean:

normal and hard rating system

  • Easy: Straightforward and quick.
  • Normal: A bit more involved, maybe 2 or 3 separate steps but no heavy lifting.
  • Hard: It’s going to take some thought and time to do this. Still, most marketers should be able to knock it out with some effort.
  • Expert: This task is time-consuming, technical, or difficult. You may need to get some help from a Drupal developer to get it done.
Apr 06 2021
Apr 06

Do these numbers seem shocking to you? They certainly were for me. And the more unfortunate fact is that these numbers will only grow in the future. So, what should be done? We cannot stop people from getting a disability, that is in no one's hand. However, we can ensure that that disability should not hold them back. We should endeavour for inclusion, wherein every person on this planet gets an equal opportunity, disability not being a criteria impeding on their life experiences. 

To that accord, accessibility was designed, for inclusion, for equality and for making the differently abled feel that their voices and their feelings value. Accessibility has expanded as a concept since its inception and now, it is also being rigorously practised on the web.

The web or the internet is for everyone, you cannot say that it was designed with a particular demographic in mind because it simply wasn’t. From 5-year-olds watching YouTube videos that are making them prepared for school to 70-year-olds watching a YouTube tutorial on how to update their WhatsApp status, the internet is for everyone and web accessibility ensures that it can be accessed by everyone without difficulty. 

This brings us to the meaning of web accessibility, which is to design something on the web that includes the needs of the differently abled. People with auditory, cognitive, visual and speech disabilities amongst others should be able to perceive, understand, navigate and interact with the web with ease. You should remember that accessibility is not just limited to people with disabilities, it also transcends to other aspects of life that may affect one’s ability to perceive what is right in front of them. Old-age, bright sunlight, the size of the device being used and the person’s mental and physical state at one point, all are included when we talk about accessible design on the web. Therefore, when businesses and organisations are able to build such experiences that cater to all of what I just mentioned, only then would they be truly accessible. 

With Tim’s words at the back of our minds, let’s find out what the fuss about accessibility is for. Here are three reasons that sum up the crux of accessibility and why it ought to be practiced down to the very of the web business.

The paramount reason for practising accessibility lies in the numbers we talked about in the introduction. The close to one billion differently-abled people in the world would be able to access your web project with ease. They won’t feel frustrated or undervalued by your business model, if it is accessible. And can you guess what that means? Yes, you’ll be able to target a market that your competitors might have overlooked. And that is enough to get you the revenue you endeavour for.

You know the United Nations? I’m sure you do. And when the UN says something is important and needs to be followed, you follow it. The United Nations Convention on the Rights of Persons with Disabilities clearly states that access to information and communications technologies is a basic human right. And when you make websites that are inaccessible to persons with disabilities, you are going against the UN and you won’t want that.

Even in the US, the Americans with Disabilities Act also establishes grounds for web accessibility and adherence to those guidelines is important to stay on the good side of the law, don’t you agree?

Then, there is the concern about brand image. If I had to describe accessibility’s essence, the only thing that would do it justice would be social inclusion. Including every section of the society and every scenario that may hamper their web experience, and building a web project that takes into account all of that would most definitely get positive feedback from the audience using it. And that is how you build a positive brand image. 
 
Now, tell me are you not on the side of accessibility? Are you not craving to make the entirety of your website truly accessible to the users, whoever they may be, whatever their physical or mental condition be, and wherever they may be? 
 
If that is the case, continue reading because I am going to be talking about accessibility tools that are found in Drupal, a leading CMS, so that you can use those tools and modules to make your site the epitome of accessibility.

Drupal has certain checklists that are used to evaluate the competence of a particular aspect of your project, these are called Drupal Core Gates. There are six in total, ranging from Content to Frontend and testing. And you would be glad to know that accessibility is one of these six parameters, this alone is explanatory enough to let you know how much Drupal prioritises this part of web designing. 

All of these are proof of Drupal’s compliance with accessibility, meaning that Drupal is incomplete without it. With the additional WAI-ARIA support, Drupal is becoming all the more proficient in building projects that are accessible and rich internet applications. 

With that said, let us look at the accessibility-centric features found in Drupal. 

The addition of WAI-ARIA landmarks, live regions, roles and properties has equipped Drupal to provide more semantic HTML5 elements that can be leveraged by assistive technology.

Let’s try to understand this, when an assistive device scans a web page for information, it extracts the data about the Document Object Model (DOM), or the HTML structure of the page. No further information is read by the screen reader.

Often these assistive devices only allow a user to select to read the headings on the page or only the links. It prioritizes according to the hierarchy in which the headings and links are presented making browsing easier for users of assistive devices. So, HTML and WAI-ARIA help in achieving screen-friendliness and making the UIs more interactive.

Aural users play a major role where accessible design is concerned. To that accord, Drupal.announce() has been made a part of Drupal core so that timely messages can be delivered to these users relying on a screen reader with different tones as well; you can be assertive or polite, it is up to you. This is the Aural Alerts feature.

Users that are visually impaired and the ones who cannot operate a mouse can opt for the Tabbing Manager. This is a feature that would essentially become a guide for these users, so that they are able to access all the salient features and that too in a logical order. 

Your content can be displayed in multifarious ways; it is up to you to decide how you want it. With Drupal’s CSS classes, you can control the way your content is hidden or not. Would certain screen readers can view it or all of them, would hidden, visually hidden or focusable or entirely invisible, you would get to decide every single nuance.   

This is due to the centralised alternative to CSS display:none; and the standardisation of the HTML5 Boilerplate naming convention. 

It is important to provide the necessary feedback to users about the results of their form submission. Both the times when successful and when not.  This incorporates an in-line feedback that is typically provided after form submission.

Notifications have to be concise and clear. The error message, in particular, should be easy to understand and provide simple instructions on how the situation can be resolved. And in case of successful submission, a message to confirm would do. 

Drupal forms have turned out to be impressively more open to the expansion of available inline form errors. It is now easier for everyone to identify what errors they might have made when filling in a web form.

Fieldset labels are utilized as systems for gathering related segments of forms. Effectively implemented

label gives a visual diagram around the shape field gathering. This can, to a great degree, be valuable for individuals with cognitive disabilities as it viably breaks the form into subsections, making it easier to understand.

Drupal presently uses fieldsets for radios and checkboxes in the Form API. This helps towards additionally upgrading forms in Drupal. This feature is also being used in the advanced search option. 

The Alternative Text 

People with good eyesight can see the images, but what about the visually impaired? They won’t be able to see the images. And images are important in context to what you want to portray in your content. So, what is the solution?

It is an alternative text, this text describes everything going on in the picture, so that the people without sight are able to understand what the picture is about. 

Drupal has alternative text as default to make the content accessible to everyone and content creators understand its importance. However, the default can be overridden through CKEditor or Image Fields, if that is what you might prefer. 

The Bartik 

If you think about it, a link is like any other piece of content on a webpage, yet it is different because it has the power to take you to a different page for more information. This power should be highlighted properly. And Bartik is here to help in that. A Bartik underlines a link, which basically highlights it and makes it easily identifiable, aiding to enhance accessibility further. 

The jQuery UI 

Drupal’s autocomplete feature is quite useful and jQuery UI is helping in elevating its usefulness. Being implemented in Views UI and in other places, it is improving Drupal’s accessibility standards. With the involvement of jQuery UI community, the benefits are being experienced by both the projects in leaps.

Drupal Accessibility Also Transcends to Developers: D7AX

When we hear accessibility, we always go to the users. Accessibility has to be about them, right? We must ensure that everything on the site is totally accessible to every user, regardless of their physical condition. 

This notion is true, yet it is only half true. Yes, the majority of the accessibility guidelines focus on the users, however, the developers, the people who actually build a project from the ground up also need to prioritise in terms of accessibility. So, the development process has to be accessible for them to build something great that they are fully capable of doing.

And Drupal provides this as well. Drupal has focused on accessibility for developers and that is what makes me as a Drupalists proud of this platform. Developers can depend on Drupal for support when they are creating accessible sites and projects. 

The D7AX is shining glory of Drupal in this accord. It makes it extremely convenient for developers to find contributed modules and themes that support the development of accessible websites. 

So, what is D7AX? 

It is a kind of platform that lets other developers know that a module has been designed after following all the resources for developing accessible modules. When you see a hashtag saying D7AX on a module page, know that it is accessibility friendly. 

Whenever you use a D7AX module, you are contributing in making that module a success. Using it would mean any issues that were overseen before might be caught by you and resolved, making you a D7AX developer as well and a contributor in Drupal accessibility, 

What about themes? 

D7AX is not just limited to modules, it also works to resolve the accessibility challenges found in the theme layers. It works in similar fashion to that of modules and the hashtag lets the users know that a theme is compliant to the accessibility guidelines. The Accessibility handbook will help you further in this regard. 

Is there an accessibility group?

Yes, there is and it is the Drupal Accessibility Group. It would answer all your questions about Drupal accessibility and make accessibility come alive on your fingertips. With regular sessions and talks, you’ll get to know all the hints, tips and tricks about it. 

Your feedback is always going to be valued at Drupal, the accessibility group is no different. Even if you have concerns about Drupal lacking in an aspect of accessibility, you should raise it. Who knows maybe you end up making Drupal even better. 

This is the kind of indulgence by developers as part of one community that makes Drupal an ideal place for developers to build something that is universally accessible because they have access to the ideas and work of other developers and that gives Drupal an unparalleled edge. 

Modules Making Drupal Sites Universally Accessible

Knowing that Drupal caters to accessibility for the administrators and developers as well as the visitors does give a sense of relief that we are going on the right track with Drupal. However, is that enough? I don’t think so. 

Until you know how to effectively implement the aforementioned accessibility features into your project, you can’t sit back and relax. To help you in executing accessibility to the T, here is a list of the modules that will enable you to deploy a universally accessible project. 

#1 The CKEditor Family 

You cannot talk about Drupal accessibility modules without talking about the CKEditor. It is a WYSIWYG module that provides umpteen features like structured content and clean markup and convenient drag and drop features based on its UI along with pretty secure safety guidelines for your content creators.

The CKEditor in itself is pretty powerful when it comes to accessibility, however, when you bring five of its variants into the mix, it has the potential of making Drupal even more accessible. Let’s have a look at them now.

CKEditor Accessibility Auditor 

The HTML_CodeSniffer Accessibility Auditor comes in the package of CKEditor Accessibility Auditor with a button for the same that audits the source code of your current content. 

If you have a specific error; 
If you want a success criteria and suggestions of techniques; 
If you want to know what triggered the error; 

Everything would be found by these modules and the results will be in front of you almost as soon as you run the auditor.

CKEditor Accessibility Checker 

The CKEditor Accessibility Checker provides a plugin with a creativeness for accessibility inspection of your WYSIWYG body created in the CKEditor itself. Of course, the inspection would lead on to immediate solutions of any problems found. You should know that this innovation plugin is the Accessibility Checker, hence the name of the module.

CKEditor Balloon Panel 

This module is used in relation to the previous one to create floating panels that have accessibility tips. These floating panels are a courtesy of Balloon Panel plugin that make it possible for you to present as content at whichever specific position you want to, 

CKEditor Abbreviation 

The CKEditor Abbreviation’s purpose is quite simple. If you want to add a button to the CKEditor to help you insert and edit abbreviations, it will do that for you. The addition of a link to edit the abbreviation is an added bonus.

USWDS CKEditor Integration

Like the name says, the USWDS CKEditor Integration module integrates the US Web Design System to the CKEditor, which has become a requirement for government websites. You can use the USWDS classes and components and inject them into the CKEditor, all without opening the source even once.

#2 Automatic Alternate Text 

Did you know that there is an API that can actually process images through its state-of-the-art algorithms and return with an output that is quite on point? It can sense the content of the image, its maturity levels and even the prominent colours in it. 

The Microsoft Azure Cognitive Services API is able to do this with ease. Drupal’s Automatic Alternative Text module utilises the competence of this API and provides alt text to images your users did not. 

However, you must be aware of the fact that the way we perceive images and the technology would perceive it may not be similar, so the produced alt text can be different to what you may have expected. 

#3 A11Y:Form Helpers 

Remember the accessible forms I mentioned as a Drupal feature, the A11Y: Form Helpers helps in achieving that. It aims to fix the accessibility issues found in Drupal forms. 

This module’s features are quite impressive. 

  • You do not require any HTML validation; 
  • You can include readable inline error messages for screen readers; 
  • You can even put in pre-filled attributes to certain form elements, which is always a winner.

#4 Block ARIA Landmarks Role

People usually prefer when you come straight to the point and skip all the small talk. And ARIA landmarks are just the means for that; it allows users to skip the unnecessary and switch to the main content. 

With the Block ARIA Landmarks Role, you can add extra elements to the block configuration forms and users can allocate an ARIA landmark role or label to a specific block. Having been created with inspiration from the Block Class, this module does cater to accessibility.

#5 Editoria11y

Editoria11y is a module that caters to the accessibility needs of the content creators and editors. Being a user-friendly checker, it focuses on the accessibility concerns of content authors and rectifies them. 

  • It ensures that speckcheck is always on and corrects the content mistakes as and when they happen.
  • It ensures that errors never happen in relation to Views, Layout Builder, Media and similar modules. This is because it runs in context with them and its checkers are always running.
  • Lastly, it ensures that content issues get fixed by prioritising them. Its exclusive focus on them ensures page editors don’t miss anything that is easily fixable by them.

#6 Fluidproject UI Options 

A web page has a lot of different elements that might need modifications to make them aligned with the accessibility standards set by Drupal and W3C. The Fluidproject UI Options tends to make these modifications easy for you. 

Be it; 

  • the page’s font size;
  • the page’s font style; 
  • the page’s height; 
  • the page’s contrast ratios; 
  • the page’s link style; 

everything can be sorted and the changes can be retained using cookies. However, it does come with certain limitations, using CSS gradients for contrast settings is one of them. 

#7 High Contrast 

You will have a theme that you are currently using, then there will be a theme that would be a high contrast version of the same. Reading this along with the name of the module, you must be able to guess what this module is all about. 

With High Contrast, you will be able to switch between your theme and a high contrast version of the same. All you would need to do is press tab on the keyboard after installing the module and you’ll get the high contrast pop-up link on your screen and the work is done.

#8 Siteimprove

Aiming for high quality content along with higher traffic and a higher level of digital performance is not unreasonable. And doing all of this by adhering to the regulatory compliance is what Siteimprove is known for. 

Being a comprehensive cloud-based Digital Presence Optimisation software, it offers a smooth integration through its Drupal module, wherein  you can capitalise Siteimprove efficiency in content creation and editing process.

Be it testing the content; 
Be it fixing what was found; 
Be it optimising the perpetual work; 

You will have the analytics and content insights at your disposal to make this happen. Siteimprove’s plugins ability to lessen the gap between Drupal and the software’s Intelligence Platform is the sole reason for these amazing benefits. 

#9 Style Switcher 

Have you ever found yourself in a conundrum wherein creating themes and building sites seems like a mammoth task? If you have, you most likely would have been facing issues with the alternate stylesheets. 

The Style Switcher module makes all of this a breeze by focusing on the themer as well as the site builder. It provides an alternate stylesheet for both in the admin section. These styles are presented in a list of links in a block to your site visitors. 

And there is more, with the module making use of cookies, these styles are always remembered and when someone returns to a page, he is welcomed by the same style he chose in his previous visit. Pretty amazing, right?

#10 Text Resize 

Have you ever squinted your eyes to read a piece of text that is too small? Did you get frustrated by it? Now, imagine you have a weak eyesight and focusing is always an issue. Would you be able to read a small font size? I don’t think you will and now you know how the visually impaired feel.

The Text Resize module helps in making the visually impaired feel less frustrated. Using jQuery and jQuery Cookie, it creates a Drupal block that allows users to change the font size of the text, making your pages more accessible. You would be glad to know that it can also resize images. However, you have to remember to enable the Text Resize block of your theme, only then would the block appear. 

#11 Civic Accessibility Toolbar  

Civic Accessibility Toolbar has a pretty similar principle to the previous module. Unlike the Text Resize module, it not only aids changes in the font size of the text, but it also helps users in switching to a theme version that has a higher contrast. 

Now, much like Text Resize, this module also operates on the creation of blocks for the utilities being implemented for accessibility with the visually impaired in mind. 

Bartik, Garland, Zen Starterkit, Stark and Oliveiro are all the themes in which the Civic Accessibility Toolbar has been trialed and tested.

#12 HTML Purifier

Auditing your site with a thorough and secure whitelist as well as ensuring that your documents are compliant to the standards of W3C’s specification will keep you on the good side of accessibility. Drupal’s HTML Purifier module does just that through the HTML filter library of the standard stringent HTML Purifier

With this module you can say goodbye to all malicious code.

Custom fonts; 
Inline styles; 
Images and tables; 
Restricted tags; 

All of these are possible when you combine the HTML Purifier with your WYSIWYG editors. You will hit the standard compliant ball out of the park with a home run through this module. 

Now that we have discussed all the necessary modules that aid in making your Drupal site universally accessible, let’s listen to what one of our frontend developers at OpenSense Labs has to say about Drupal and its part in accessibility.

“Drupal Core on its own takes care of the accessibility in the site. Since many accessibility challenges are confined to Frontend (Theme) Layer, it is better to have good practices in place for frontend development to ensure accessibility compatible sites.” 

I personally feel that he is right. There are hundreds of modules in Drupal and you can use as many of them when building your site. With so many modules at work, your site is bound to be extremely functional and impressive. However, it still might not be accessible, if you don’t keep accessibility as an imperative parameter during the building process. 

I’ll explain this with a few modules for better understanding. 

If you look at all of these modules, they are not blatantly related to accessibility, but all of them are somehow adding to your site’s accessibility appeal. Now, if you developers are constantly building with accessibility at the back of their minds, they would use these modules without any hesitation. 

Therefore, like our frontend developer said, Drupal accessibility is all about good practices throughout the building process and throughout the life of the web project. 

Are You Certain Your Project is Accessible, Let’s Review!

Up until now we have discussed the accessibility features found in Drupal and the modules that support the implementation of those features. Do you think that is enough? Do you think the installing and running a bunch of modules makes all your accessibility work done and now you can sit back and relax? If you think so my friend, you are utterly wrong. 

By running modules, you cannot be certain that your site is truly accessible, that it checks all the accessibility boxes. You have to run a thorough review on all the parameters that can affect your site’s accessibility and after reviewing the results and rectifying them, you can sit back and chill as much as you want. 

So, let’s start the review.

Review through Automation 

You need to start your reviewing process with Drupal’s automated tools that are designed to assess your project’s accessibility levels and issues arising out of it and consequently resolving them. 

Some of these tools are; 

WAVE;
Tenon;
Accessibility Insights;
Google Lighthouse;
Siteimprove;
And Siteimprove Accessibility Checker.

With axe-core, you can automate some of them and sit back while they do their work.

Review the Keyboard

Keyboard navigation is of great significance when it comes to web accessibility, so you cannot afford to go wrong with it. Everything and every element on your screen must be accessible through a keyboard and with a tab order that makes sense.

When making your assessment, look for things like these; 

  • The tab should work forwards and backwards; 
  • The interactive elements should be highlighted from others; 
  • The document object model should be followed in the tabbing progression, making it natural; 
  • The skip option is available for content that is repeated; 
  • The user should be able to skip overlays, modals and autocomplete widgets; 
  • The hovering mouse content should be accessible through the keyboard as well. 

Pointers like these amongst others would make your project keyboard friendly. One more thing, you should remember to review this on mobile and tablets as well to avoid any responsive breakpoints.

Review the Colour and Contrast 

Next comes the colour and the contrast, which should be prioritised too. The foreground and the background need to be quite distinguished from each other. 4.5:1 is the ideal ratio of text to the background. Anything lesser than that would be in direct contradiction to the accessibility guidelines. 

You also need to remember that colour cannot be the only way to relay information. Think of your audience, who might be colour blind; would they be able to gather what you are trying to say?

There are two boxes with the same kind of figures differentiated with colour, but the second has the addition of numbers as a desciption


The second demonstration in this image is what you should always go for. 

Review the Content 

You also need to review your content. By content, I don’t exactly mean the words you use, although the language should be easy to understand. 

Apart from that, there is also the changing content such as the list of search results, which keeps updating all the time. This is called the dynamic content and you must announce these changes through assistive technology; ARIA Live Regions help in this regard.

Headings are a part of the content as well. In this regard, you have to make sure that your headings are not only prominent enough, but also descriptive enough to ensure that something reading it understands its entire context. 

Then there are the icons, which cannot just be the icons because the users would not be able to know their functionality without a proper description. Give labels to all your icons, if you haven’t already. 

Review the Sound and Video 

This one is for the deaf community and people who have hard hearing problems. The elements on your site that are relaying information through sounds and videos should have accompanying textual transcripts and captions so that people who cannot hear what is being said and read it. This would automatically make your site more accessible. 

I used both captions and textual transcripts because this review also focuses on the users with visual impairments. This is because for a complex video, captions alone may not be enough. There may be a need to textually describe the scene to people who cannot see what is happening and captions would only provide context to some degree. 

Review the Animations and Autoplay 

There is a high chance that your project might have animations, audios and videos. Obviously, there would be a purpose for their presence on your site, but you have to consider the user as well and that means avoid autoplay. 

Videos that autoplay and don’t pause by themselves are a nuisance to me, frankly, if I want to watch, I’ll press play myself. So, you should also turn the autoplay option off and even if it is on, the animations, audios and videos should stop playing after a couple of seconds. 

You should also think about adding easy controls to play and pause these media items. 

Review the Screen Reader 

You are going to have users that would completely rely on a screen reader, so ensuring that there are no issues with that has to be on your review checklist. 

For this, 

  • You should assess that the same information is being relayed to users using assistive technology and the sighted users. 
  • You should check the flow of information, ensuring that it is logical much like the tabbing order in keyboard accessibility. 
  • You should see that all your links make sense; something like ‘click here’ won’t really help the screen reader user. 
  • Finally, you should ensure that all the images have alternative text describing them in a clear and concise way. 

Conclusion 

Web accessibility has become quite popular today. If you adhere to the W3C’s guidelines on accessibility, you could achieve wonders for your brand image and enhance your consumer base to a great deal. However, if you do not, your image would downgrade and so would your revenue. The aim of accessibility should be to create a web project that is accessible to someone without any disability, someone with a physical disability and someone with cognitive disabilities on an equal without a shadow of bias.

Accessibility features in Drupal are so comprehensive and whole that they would not let the latter outcome be even an option. I have tried covering all of Drupal’s accessibility modules and tools and I really hope that you will take a note of them and build a project that gets universal attention. Good luck!

Apr 06 2021
Apr 06

It seems that with each passing year there is a new paradigm for how content can be arranged and organised in Drupal. Over the years a number of approaches have moved in and out of being in vogue: Panels, Displya Suite, IPE, Bricks and Paragraphs to name a few. Some change has been positive, providing leaps forward in flexibility or control. Other developments have not lived up to their promise.

In February 2021 I presented a new module, Layout Paragraphs, to the Sydney Meetup. The slides and video have been provided below. This presentation demonstrates Layout Paragraphs in action and how offers some advanced layout options for Paragraphs. Conceptually it is similar to Layout Builder in many respects, however, it performs its magic on the Node Edit page, integrating with the natural content editing environment for site editors.

Layout Paragraphs offers a new way forward for the following reasons:

  • Editing happens on node edit, rather than the layouts page. Better for editors.
  • Paragraphs can be placed into Layout regions to bring more flexibility to Paragraphs. This is similar to what Bricks was doing.
  • Nicer UI for Paragraph selection.
  • Nicer UI for Paragraph display - no need for Preview view mode any more.

A bit of history

It is worth reviewing a little history to see where Layout Paragraphs fits in. The presentation takes a look at some of the popular combinations over the years and gives them over all scores, weighted by functionality and editor experience. Here is a spoiler of what is covered in the video:

Recipe Year Score Pure template 2010 65 Display Suite 2010 58 Panelizer 2012 69 Panelizer and Paragraphs 2014 73 Panelizer and IPE 2016 39 Panelizer, Bricks and Paragraphs 2017 63 Layout Builder and Blocks 2018 70 Layout Builder and Paragraphs 2019 78 Layout Builder, Layout Paragraphs, Paragraphs 2021 81

The scores were calculated from a weighted average of various aspects of the techniques: flexibility, control, editor experience, etc. Watch the video for the details.

Conclusion

You can see that Layout Paragraphs is the latest in the line of approaches and that it is scoring quite well. A recioe based around Lout Builder, Layout Paragraphs and Paragraphs seems to work quite will. Layout Builder remains the domain of the sitebuilder, using it to define the basic layouts for the page. With Layout Paragraphs, a new set of simpler layouts can be used by the editor for their paragraphs.

I think that the approach holds a lot of promise moving forward and it is good enough for Morpht to be considering it as a standard part of our editor toolkit. All up we have found the module to be usable and a definite improvement on editor experience. We are adopting it into projects where we can.

Watch the video and let us know what you think in the comments below.

Watch the video

Apr 06 2021
Apr 06

How does it stack up

Those of you who work with Drupal, you are probably familiar with the combination of using Search API with a search backend such as MySQL or Solr. A pluggable architecture makes Search API a good choice for indexing content in Drupal.

For a long time MySQL and Solr were the popular choices. MySQL was an easy choice as performance was good and results were OK. For those working with large datasets and many concurrent facets, Solr made more sense. Most Drupal hosting companies provide it as a service for this reason. As the search market has matured, other backends have become available, including one for Sajari.

The table below compares these three options and highlights the strengths and weaknesses of each.

Feature Database Solr Sajari

Separate service

No

Built into Drupal.

Yes

Drupal hosting companies provide a Solr as SaaS.

Yes

Sajari is available as a SaaS.

Full text search

Yes

Yes

Yes

Facets

Yes

Yes

Yes

More like this

No

Yes

A useful feature for providing item recommendations based on similarity.

No

Result quality

OK

Good

Very good

Performant

Partial

Slow with many filters over large datasets with facets.

Yes

Yes

Easy install

No

Requires a module such as Search API Database to push data across to Solr.

No

Requires a module such as Search API Solr to push data across to Solr.

Yes

We can configure Sajari in the Sajari UI to run from metadata on the page. Sajari provides an embeddable widget.

We recommend the Search API Sajari module approach.

Search API Integration

Yes

Search API Database module

Yes

Search API Solr module

Yes

Search API Sajari module

Federation

No

No

Yes

A site parameter can be passed into the index for easy filtering.

ReactJS components

No

No

Yes

Interface is faster than Search API as server round trips are not needed.

Result tracking

No

No

Yes

Built-in metrics understand page trends and poorly performing keywords to help you see what searches led your users to individual pages, or which content visitors are searching for but can’t find.

Reporting

No

Reports can be set up in analytics software.

No

Reports can be set up in analytics software.

Yes

Sajari provides logs and charts of search requests.

Autocomplete - suggestions

Yes

Extra module can be installed.

Yes

Extra module can be installed.

Yes

Synonyms

No

No

Yes

Libraries of synonyms can be uploaded via Sajari UI.

Typos

No

No

Yes

Support for misspelled words.

Boosting

Limited

Limited

Yes

Advanced rules can be defined on certain plans.

Machine learning

No

No

Yes

Sajari will learn which results are more or less relevant, promoting the best results to the top.

Pricing

Free

Database comes with Drupal hosting.

Included

Solr server comes built in with typical Drupal hosting.

Free and up

Starts free for smaller sites and then increases.

https://www.sajari.com/pricing

Summary

An easy, low cost search solution.

A more scalable solution with handy features such as “more like this”.

A fast system with smart results helpful for those looking for synonyms, results boosting, tracking and reporting.

Sajari is a viable alternative for clients who are looking for more insights into how their audience use the search on their site and more control over the delivery of the results. This is the case for content driven sites as well as for ecommerce configurations where preferences play a big role.

Integrating Sajari with Drupal

The Sajari Widgets

It is possible to implement Sajari search into any website without the need for the addition of modules or custom code in the backend. Sajari provides a set of widgets which will allow search to operate without the need for much technical knowledge.

Firstly, a Javascript tracking code will allow for “instant indexing”. When a user visits a page, the code fires up and tells Sajari about the page. Sajari can then visit and index the page to update its index. This approach is simple to set up but has its downsides - freshly updated or deleted content will not make it into the index immediately. If this is a concern, then using Search API Sajari, below, would be an alternative.

Secondly, Sajari offers a tool in the admin UI to define a search form and results. It covers things such as the search query, filters, tabs, result counts and result display. It is very easy to configure. The result is a snippet we can embed onto your search page. A set of ReactJS components drive the search and return results in lightning speed, leading to a good experience for users.

Drupal Module: Search API Sajari

For those looking for a tighter integration between their Drupal site and Sajari, it is possible to use their API to push updated content across. The Search API Sajari module , authored by the developers at Morpht, provides a backend to the venerable Search API module  This will update Sajari when content is updated on your Drupal site.

The main advantages of this approach are:

  • Content is indexed instantly, even when no one views it;
  • Deleted content is removed from the index immediately;
  • The tools within Search API allow for the fine tuning of the various fields;
  • There is support for sending a site name across in the result, allowing for federation of results.

Drupal Module: Sajari

The widgets provided by Sajari offer a quick way to get up and running with a search page. However, there are some limitations in the way they work. At the time of writing (early 2021) the widgets did not support the definition of facets.

In order to overcome this shortcoming, Morpht developed a ReactJS library which sits on top of the components provided by Sajari. It has quite a number of configuration options for queries, result counts, filters, tabs and facets. It even has the ability to customise the results through the provision of a callback function which can convert the JSON result to HTML. This code is available at Sajari Configuartor.

The Sajari module makes use of Sajari Configuartor to power the way search is implemented. The module provides a block for defining how the search will operate. The configuration is then passed through to the Sajari Configurator and the UI and results are then shown.

The Sajari module also makes use of the JSON Template module which allows for different handlebars templates to be defined by the themer. These templates can then be selected by an editor during the block creation process. The select template then forms the basis for the callback which is passed into the Sajari Configuartor. The result is that editors can select how to show results. There is no need to alter the ReactJS templates which are in the library.

A recipe

If you are looking to get up and running with Sajari, we recommend this process:

  • Sign up for a free account at Sajari;
  • Set up an initial collection in Sajari, but add no fields;
  • Install JSON Template, Sajari and Search API Sajari;
  • Configure Search API Sajari with your collection details in a new Server;
  • Define your Node Index and assign it to the Sajari server you have just created. The schema will be updated automatically in Sajari with the changes you make in Drupal;
  • Confirm that content is being indexed properly;
  • Add a Sajari search block to your search page and configure it. Be sure to use the correct pipeline and get the field names right;
  • Test the search and confirm it is working.

Conclusion

Sajari is an up-and-coming search provider offering a new breed of search which can utilise human behaviour to improve the results it shows. It's useful for content heavy and ecommerce sites which have a strong need for good search results. There are now integration modules for Drupal to get you up and running with Sajari easily.

Is Sajari right for you?

If you currently have a Drupal site based on a different engine and are interested in what Sajari can offer you, please get in touch with us to discuss it further.

Apr 06 2021
Apr 06

A case study on how we configured GovCMS8 SaaS platform to handle bulk uploads and the assignment of metadata. 

The Attorney-General’s Department supports the technical and content management for several Royal Commissions. A common request is for the timely publishing and management of numerous documents tendered before or at public hearings - 200 documents or more in some instances. With a series of hearings taking place all around Australia, the pressure on the publishing team to manage these loads presents challenges.

The Bulk Upload solution addresses some key requirements:
    

  • Classify and sort documents in one bulk upload process,
  • Manage different file formats of the same document,
  • Run a publishing workflow to gain legal sign off before publishing,
  • Handle the versioning of files when a legal update is required,
  • Display those documents in different views on different pages: hearings, document library, and
  • Make the complex simple and work around limitations.
     
Apr 06 2021
Apr 06

Morpht is located on the traditional lands of the Gadigal people of the Eora Nation as the traditional custodians of this place we now call Sydney. We pay our respects to Elders both past and present and recognise Aboriginal and Torres Strait Islander people as the Traditional Custodians of the land.

Apr 06 2021
Apr 06

Drupal 8 is built on PHP, but using new architecture paradigms that can be difficult to grasp for developers coming from a Drupal 7 background. The Typed Data API lies at the core of Drupal 8, and provides building blocks used throughout the Drupal 8 architecture. In this presentation, Jay Friendly, Morpht's Technical Director, dives into the Typed Data API, what it is, how it works, and why it is so awesome!

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