Upgrade Your Drupal Skills

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

See Advanced Courses NAH, I know Enough
Sep 26 2020
Sep 26

Websites have overpowered the world of businesses today. There aren’t many business people left who do not have or want an online presence for their business. And websites are just the way to accomplish that. Now, building a website is not complicated at all, with just one youtube tutorial, you can do that. The tricky part is ensuring that it meets all the standards that the end user will desire. Websites built using Drupal and all its accompaniments are often considered to be up to the user standards. 

A blue background with the words layout builder vs paragraphs.


From world renowned privately owned enterprises to governmental organisations, Drupal has successfully served everyone. Drupal’s success is primarily attributed to the versatility and functionality it can provide to the web designers and content creators throughout the process of website development.

Continuing on the same lines, today we will discuss two such features in great detail to make you understand their importance, use and workings. We are going to talk about Layout Builder module, one of the most sought after modules in recent times, and Paragraphs module. Let’s dive right in.

The Seasoned Paragraphs 

A green background with different segments to depict the paragraphs module.This is how the paragraphs module will segregate your content into different paragraph types.

If you are reading this article, you must be familiar with the various modules of Drupal. You must also be familiar with the needs of websites and how complicated they can become. To satiate those needs, I will be telling you about one of the most convenient and user-friendly modules, which is Paragraphs.

Paragraphs module is a great tool that gives a high degree of editing power to the end users of a website. It does so by letting the end users choose predefined paragraph types that are independent from one another. This allows the web builder to avoid putting all the information in one WYSIWYG body type.

With this module, you can add a hero image that would be the banner of your webpage, you can add images and you can add grids as well. All of this can be done by simply selecting the types with the same name. Can website design become any more easy?

Although there are no default Paragraph types, you can easily create as many as you want. 

It is up to you to decide how many columns you want and where you want them. On top of that you also get to decide how much leeway you want to give to your end-users in terms of future edits.

The Modern Layout Builder

A green background with pink sections to depict the flexibility of the layout builder module.With Layout builder, you can add sections with each having a set of regions for the content to be placed thereby resulting in more flexibility than Paragraphs

The other convenient and user-friendly module is Layout Builder. Layout builder is a multi-functional tool that allows the content creators the ability to make content appear on their website as they wish to. 

Layout Builder has multiple settings that can be used to build pages from the ground up. Its highlighting feature is the visual layouts. When a layout is selected, if the web builder wants, he can implement the same throughout his website for consistency and brand image. If that is not what is desired by the web builder, he can also create customised templates for individual pages. This kind of ease in design is unfound in other options. 

Layout builder has become increasingly popular amongst designers and writers, and the reason is the power of customisation it provides. The below video by Dries Buytaert will give you a glimpse of what that really looks like, all you have to do is drag and drop.

How Advantageous Can Paragraphs and Layout Builder Modules Be?

I have already mentioned that Paragraphs and Layout Builders are two most popular modules in Drupal. So, how can I say this? I have reasons, validations and explanations for my claim, and all of them can be characterised as their advantages. People only make things popular because they like, and likability and advantageousness go hand-in-hand. So, let us delve right into them.

Paragraphs  Layout Builder 
  • No limits for Paragraph types
  • Grouping and reusing of Paragraph types
  • Flexible content model 
  • Simple and clean structure
  • Multilingual support for content 
  • Build from scratch 
  • Control over the layouts you want
  • Use of block types
  • Better structures for content 
  • Minimal coding required 
  • Enhanced authoring experience 

Paragraphs and Its Merits 

Paragraphs come with an array of features that only enhance its beneficial aspects. This may seem like a simple tool, but it has the ability to make your website design as appealing as it can get. 

Forget limits 

Let us start with the most helpful merit and that is Paragraph’s limitlessness. There is no limit as to the number of configurations you can create using Paragraphs. You want 20 different paragraph types scattered throughout your webpage, go for it!

Group and reuse 

Not only can you group various fields of your content into new complex elements, you can also reuse the components you have already created.  Can you possibly tell me that this does not fascinate you?

Flexible to the core 

Moving on, a website is constantly under construction, there is always going to be something or the other that needs to be updated, corrected or added. Most of the time these changes are not necessarily huge, and you do not need to change the entire layout. The advantage of Paragraphs is that it provides a great deal of flexibility in the content model, so that minor changes can easily be made by the content authors with ease.

Simple, yet impactful 

Paragraphs are often considered to be too plain and bland. Many regard this as a disadvantage, however I tend to disagree here. Yes, paragraphs are simple, but that is a benefit because simplicity means few clicks. The result; you do not need to be an expert to use this module, a content editor with minimal experience in Drupal can also use it with the least amount of effort. 

Its intuitiveness helps the web authors and builders to add pop-ups and quotes and easily rearrange them. On top of this, the simplicity of Paragraphs also means that your design will not seem cluttered, resultantly, your site will not slow down in its performance. Now, you tell me how can simple be bad for you, when it is actually avoiding a mess? 

Multilingual Setup 

Websites are becoming more multilingual in the present, so the setup of multiple languages in the content becomes somewhat of a necessity. Here, the paragraph module comes quite handy as it works within a multilanguage setup. 

Layout Builder and Its Merits

So far, you must have been impressed with the advantages of paragraphs, now prepare to be dazzled by the umpteen merits of the layout builder.

Builds from scratch 

The best feature of a layout builder is that it gives the developer the potential and resources to build something from the ground up. All you have to do is make custom block types, arrange them as you want and fill them up with content, pictures or videos and you are done.

Lets you be in control

With a layout builder, you will always be in control. I say this because customisation is ingrained in its formula. You can use it to make configuration of your liking, and if you want, you can implement your created template and use it throughout your website. The layout builder also allows you to build customised landing pages that will have your creative stamp all over it.

Blocks all the way

Blocks can be termed as the foundation of the layout builder, without them, it would be hard to imagine. Blocks are what help you get an idea of how your content would be displayed on the actual page. From globally available blocks suitable for all pages to uniquely build custom inline blocks made for specific pages, layout builder has your needs covered.

Structures your information 

Have you ever been to a website that had no structure at all? The information was all over the place and you couldn't tell where it began and where it ended? If you have, then you know how important structure is for a website. Layout builder helps you build a particular structure for your website that would organise your content appropriately. If you want e-form, customer testimonials and other such content information on one page, layout builder will provide a template that will segregate the information in a way that it does not look haphazard. 

Less custom code 

Layout Builder is popular because it mandates less custom code. This means that the module is less time-consuming and less complicated, once you become familiar with it. The use, maintenance and creation of content becomes easy with less code involved.

Better authoring experience

A website’s content can easily make or break it, so it has to be pitch perfect and in accordance to the needs of the site’s target audience. With a layout builder, you can be at ease with this aspect. It has proven to enhance the authoring experience of content creators by providing an improved interface to effectively communicate data about everything the author wants to.

Are Any Limitations Holding Them Back?

With the number of benefits you have read above for both paragraphs and layout builder, you might be inclined to think that they could not possibly have any demerits. Unfortunately, they do lack in some aspects. 
 

Paragraphs Layout Builder 
  • Not a core module
  • Becomes messy with intricate layouts
  • Dependency on developers.
  • Cannot simply drag and drop sections
  • May not connect nodes
  • Template combinations may become problematic 
  • May be difficult to achieve consistency with the customised layouts
  • Needs time to learn and adapt 
  • Needs to be customised with the use of other modules 

Challenges of Paragraphs module

Starting with paragraphs, its drawbacks are not necessarily drawbacks, they are more like functional mismatches to your needs as a web developer. Let us find out how.

Not part of Drupal core

Unlike Layout Builder, which was made a part of Drupal core ecosystem in Drupal 8.7, the paragraphs module is not part of the Drupal core. Although it does not come as default in Drupal, it is still quite popular. Being a contributed module, you would have to separately install it.

Can only handle simplicity 

Paragraphs were intended to make website design simpler for the non-technical folks. The problem with simplicity is that it cannot handle intricacy. So, when your content is anything but simple, paragraphs become messy and the output is just not upto the mark. With more nested paragraphs, the editing experience may slow down. Also, to ensure that the paragraphs are being displayed as preview, you have to always customise the Form display. If you do not do that, you will end up with a mega-form. 

Dependence on web developer  

Paragraphs also do not provide free reins to the content author. He would have to be heavily reliant on the developer for setting up even the tiniest of changes.

No drag and drop 

The ease of picking up a section from one part of the layout and dropping it in a different part is unfound here.

Challenges of Layout builder module

While the problem for paragraphs was its simplicity, the problems for layout builder stem out of its complexities. Let us understand how.

Challenges with nodes

Every blog, article, forum topic and even pages are stored as nodes in Drupal. Now, when a web builder makes new content, most often, he or she would relate it with an old piece of information. With layout builder, you may notice that block content is not entirely connected to nodes.

Challenges with combinations 

The templates in a layout builder can be used any way the designer wants to. He or she can make a number of combinations with the templates. However, when a custom-made layout is used with a template-based one, it becomes quite tricky to get right.

Challenges with consistency 

With layout builder, you can implement one layout throughout your website with ease. Although it is true, when customised layouts are the centre of attention for the entire website, it may be difficult to enforce sitewide consistency.

Challenges with control 

This is going to a little sound paradoxical, the layout builder provides more control to the content editors as opposed to paragraphs. When you do not trust your content creators’ judgement implicitly, this can become problematic.

Challenges with learning 

The switch to layout builder comes with a learning curve for the content writers, which can take some time. This module does not operate with form-filling like others, so a change in the way the work is done becomes mandatory and time consuming. 

Challenges with dependency on additional modules 

The layout builder may need customisation and that can be achieved through the help of other Drupal modules. Block Blacklist and Layout Builder Restrictions aid in limiting the block type and layouts, while Layout Builder Modal aids in enhancing the user experience.

Which Would Win the Race?

Before I answer this, it is important to know that the selection of a module depends on the developer’s needs. So, the winner in this module race would vary in accordance to the needs and wants of the site and its developers, both the designer and the content author. Let us have a look at these needs.

Paragraphs is suitable when Layout Builder is suitable when
  • You need to process content again;
  • You need to accommodate nodes;
  • You need nested paragraphs.
  • You need landing pages;
  • You need a customised web page;
  • You need to tweak the existing templates. 

Paragraphs and reuse 

The paragraphs module is ideal for situations that mandate simple solutions, with reuse being the primary answer. By reuse, I mean using the existing content again, while making changes in the website. With paragraphs you can use the earlier content in an entirely new webpage with ease. You can also use the same content in accordance to the nodes.

Apart from this, when nested paragraphs are of the essence for your content, paragraphs are bound to become your best friend. 

Layout Builder and customisation 

The suitability of layout builder varies a great deal from paragraphs primarily because reuse is not a term this module uses much. It is all about the new energy.

Whether you want to create new landing pages with a variety of blocks, views and fielded content structured like grids or you want to customise a page with a layout that you created yourself and is one of a kind, layout builder will help you. 

Apart from creating completely new pages from the ground up, layout builder is also perfect for tweaking the existing pages with templated layouts. 

You have to remember that both of these modules are configurations, they will not make the content for you, they would simply arrange it. So, when you make your choice ensure that you have a pre-formed vision and awareness of the layout you want for your pages. Once you have that the choice would become very easy for you. If the choice is still difficult for you, know that you can use the combination of both of these in your content configuration, so you do not really have to decide.

The Bottom Line 

Both these modules are quite amazing at the work they do for your websites, so choosing the better one out of the two is somewhat tricky. Of course, like I have told you that your need plays a pivotal role in this decision. However, ending this article without a clear winner would make it seem somewhat incomplete and I do not want that. 

So, for me layout builder is the better choice and I will tell you why. The kind of intricacy layout builder offers and the control I would get for layouts for each page, that too with consistency, makes the layout builder the one for me. 

Apart from these two, Gutenberg is also gaining some traction as a flexible module. However, it stores the content in a large body field and this often compromises the structure of the content.

I also want to mention one more fact and it is that flexibility often comes with a price. Having a really flexible content can often impede with the accessibility of  your website as your content may lose its semantic markup. Also make sure to add metadata to your content in addition to flexible content components..

All in all, Drupal allows you to create websites and their content in a well-structured manner and despite what module you choose, the end result is always going to be satisfactory. Contact us at [email protected] to get the best of both the worlds in your next Drupal project.

Sep 25 2020
Sep 25

I don't know about you, but as a site builder when I add a date field to a content type in Drupal, and I tell it I do NOT want the time just the date and then I go to a node, and I enter the date, and it shows me both the date AND the time... it kind of drives me crazy!

How do we fix it? In this video, I'm going to show you how to create new date & time formats in Drupal sites, so you don't have to worry about getting a time and a date when you only want the date.  And, as a bonus, you'll get it in the format that you want.

Let's get started!

"Welcome to OSTips from OSTraining. My name is Rod Martin.

I've just added a date field to my article content type, and you'll note I've set it to date only.

Well, you know the problem.  When I have a node that uses this field, it's automatically going to show the time even though I did not ask for it, and I did not enter a time.   

If I go ahead and manage display for that field, you'll note that the format has the time. Click on the gear.   I'm really limited here as to what kind of format I can choose.  Let's say I want the long date so: Tuesday June 23rd 2020, but without the time.  There's no format for that!

Let's take a look at how to change that.

  • head over to configuration / regional / language / date and time formats

You can either edit one of the top three, but I don't want to choose that, or you can create a new format. There's two ways to do this:

  1. I can start from scratch 
  2. I can click Edit and copy an existing one

I am choosing option #2.

  • copy one that is almost what I need
  • create a new one: long date with no time 
  • paste that string in

Now what's giving me the time is H : I.  It's worth looking at the PHP manual here, so you can see all of the different options. You can create a date and time stamp to reflect pretty much anything you want. For example:

  1. 12 hour format
  2. 24 hour format
  3. day /month /week
  4. ordinal suffix for a day

I'm gonna change this. I'm going to remove the dash and the time. 

  • L is going to be the day
  • F is going to give me the month
  • j is going to give me the days of the month without the leading zeros
  • S after the J
  • Y is for the four-digit year

Let's take a look. Your format is going to be:  Tuesday June 23rd 2020

Now all I have to do is update my display to structure content types article and manage display.

  • head over to my date (and my new date format with no time is there)
  • click update
  • click Save
  • look at the node

And there it is: Tuesday June 23rd 2020

Well that's it! It was pretty simple. With just a little bit of PHP and some help from PHP net, you can build whatever date and time formats you need for your Drupal website. 

Thanks for watching. This has been OStips from OS Training, and I'm Rod Martin."

 

[embedded content]


About the author

Rod holds two masters degrees and has been training people how to do "things" for over 25 years. Originally from Australia, he grew up in Canada and now resides just outside Cincinnati, Ohio.
Sep 25 2020
Sep 25

Sometimes the Road of Life Takes an Unexpected Turn and You have No Choice but, to Follow it to End Up in the Place You are Supposed to Be.
- Anonymous

A thought that’s crossing my mind while I type this is I never expected myself to be here as a writer. For me, since childhood, I have always been told that I’d end up being a doctor. And I always thought I would. But as I grew up, I realized that it wasn’t what I actually wanted at all. Life did take an unexpected turn and I am where I should be today. Something like this hits each one of us at a point in life. 

At OpenSense Labs, we have Lakshay, who started off working as an Electrical engineer and went on to become an Acquia-certified front end developer. Let’s look at his experience with OSL and Drupal! 

on the left side of the circle is an electrcial engineer and on the right is a person in front of the screen


Tuba: So Lakshay, I heard you pursued electrical engineering. Tell me about your education.

Lakshay: I switched to three different schools in the last 3 years of my school life. I wanted to start something of my own while I was in high school but my parents always told me I lacked experience. Although I studied electrical engineering, I have had a lot of interest in developing websites for a very long time.

Tuba: How the shift to web development finally happened and how did it all begin at OpenSense Labs?

Lakshay: A very old friend of mine was already working with OpenSense Labs. He told me that he was working with a web development company and asked me to come and join them. So, I gave it a shot and joined OSL. When I reached there, I had no idea what I had to do, because everybody there was a professional developer. So I joined them as an intern and started watching tutorial videos and studying how to build a website and then tried coding it and showing my work to senior pros like Vinit and Pritam at the end of the day. After 3 months of the internship, I was hired as a full-time front end developer. A year later, I was an Acquia-certified front end specialist. I was promoted to the position of a senior frontend developer. Since then a lot of interns have worked under me and I’ve trained them sharing whatever I learned during my early days as an intern.

Tuba: That’s amazing! How is your experience with Drupal?

Lakshay: It’s been 3 years now and the experience so far has really been great. The Drupal community is really amazing. I’ve attended many camps where I got a chance to interact with people working across the globe.

I got to learn about different emerging technologies and how Drupal is rising with these technologies thereby embracing innovation always. I’ve presented sessions in DrupalCamp Delhi 2019 and DrupalCon Amsterdam 2019

Tuba: Do you think you made the right decision?

Lakshay: I definitely think I made the right decision. While I was working in the electrical industry for 6 months, it felt like a job, but working here felt like something that I willingly wanted to do. I’m following my passion, working with Drupal.

Tuba: That’s great! Thank you for your time Lakshay. It’s been great talking to you. I hope people are inspired to make decisions and accept the turns that life takes as you did. 

These turns can be the most challenging thing to experience, but it is the starting point of something great in your life. There is always light at the end of the tunnel, take your time to find it! The journey, I promise, will be way better than the destination. Good luck!

Sep 24 2020
Sep 24

Drupal 8 has lot of inbuilt functionality within it, one of the main important features is Configuration Synchronization. It will help us to migrate full setup properly on site deployment. But the main problem is that, According to the Drupal 8 CMI documentation,

The Configuration Manager module in Drupal 8 provides a user interface for importing and exporting configuration changes between a Drupal installation in different environments, such as Development, Staging and Production, so you can make and verify your changes with a comfortable distance from your live environment.

The same idea appears in this article,

Perhaps the most important concept to understand is that the configuration system is designed to optimize the process of moving configuration between instances of the same site. It is not intended to allow exporting the configuration from one site to another. In order to move configuration data, the site and import files must have matching values for UUID in the system.site configuration item. In other words, additional environments should initially be set up as clones of the site. We did not, for instance, hope to facilitate exporting configuration from whitehouse.gov and importing it into harvard.edu.

So Still we hardly depends on the Features module, But we can use the CMI (Configuration management Interface between two different sites with simple hacking solution.

The CMI works with based on the site UUID, If the sites have different UUID then, it won’t work, So changing destination site’s UUID with Source site’s UUID would solve the problem.

Just follow the below steps to use CMI between two different sites,

1. Export Configuration from your source site (Site A)

2. Extract the file, Open the system.site.yml file and get the Source site (Site A) UUID

3. Run the drush command in your destination site (Site B)

drush config-set "system.site" uuid "Your Source Site UUID here"

4. After that, try as usual Import Process in destination site (Site B)

It will accept the Site A configuration in Site B. So we can migrate all datas into our another site.

FYI : I am not sure, It is a effective / Proper way to do it.. If there is any problem with this method please mentioned in the comment.

Sep 24 2020
Sep 24

In such a time, i want to place blocks in sidebar region with the dynamic weight. It means the blocks should render in different position for each page request. I have searched and tried lots of method but unfortunately i can’t find proper method to do that. So i have decided to do that with some hacky way.

Drupal 8 is providing a hook to alter the region template_preprocess_region, it would prepares values to the theme_region. I have planned to use the hook to alter the block's position to be rendered in the region.

Adding the following codes in THEMENAME.theme file would solve the problems,

function themename_preprocess_region(&$variables) {
  if ($variables['region'] == 'sidebar_second') {
    $variables['elements'] = shuffle_assoc($variables['elements']);
    $content = '';
    foreach ($variables['elements'] as $key => $value) {
      if (is_array($variables['elements'][$key])) {
        $content .= \Drupal::service ('renderer')->render($value);
      }
    }
    $variables['content'] = array(
      '#markup' => $content,
    );
  }
}

function shuffle_assoc($list) {
  if (!is_array($list)) {
    return $list;
  }

  $keys = array_keys($list);
  shuffle($keys);
  $random = array();
  foreach ($keys as $key) {
    $random[$key] = $list[$key];
  }
  return $random;
}

It is working well in my site but i know it is the hacky way, not sure about the proper way to do that. If anyone of you know about this kindly share it in the comments :)

Sep 24 2020
Sep 24

Twig can be extended in many ways; you can add extra tags, filters, tests, operators, global variables, and functions. You can even extend the parser itself with node visitors. In this blog,

I am going to show you how to create new custom twig filters in drupal. For example we are going to create a filter to remove numbers from string, will explain with hello_world module.

Create hello_world folder in modules/custom/ folder with the following files,

1. hello_world.info.yml // It would contains normal module .info.yml file values, Check here for more details

2. hello_world.services.yml // It would contain following lines,

services:
  hello_world.twig_extension:
    arguments: ['@renderer']
    class: Drupal\hello_world\TwigExtension\RemoveNumbers
    tags:
      - { name: twig.extension }

3. src/TwigExtension/RemoveNumbers.php It would contain followings in that,

namespace Drupal\hello_world\TwigExtension;


class RemoveNumbers extends \Twig_Extension {    

  /**
   * Generates a list of all Twig filters that this extension defines.
   */
  public function getFilters() {
    return [
      new \Twig_SimpleFilter('removenum', array($this, 'removeNumbers')),
    ];
  }

  /**
   * Gets a unique identifier for this Twig extension.
   */
  public function getName() {
    return 'hello_world.twig_extension';
  }

  /**
   * Replaces all numbers from the string.
   */
  public static function removeNumbers($string) {
    return preg_replace('#[0-9]*#', '', $string);
  }

}

Enable the hello_world module and clear the cache, then you could use the “ removenum “ filters in your twig file,

{{ twig-value-with-numbers | removenum }}

It would remove the all numbers from the string, enjoy with your custom filters !

Download the hello_world module here

Sep 24 2020
Sep 24

One of the most favourite and  valuable features in drupal is multisite configuration, Drupal 8 provide simple way to create multisite it reduced lots of works. The following steps shows to configure multisite in drupal 8,

  • Should have more than one domain and databases, I am going to use the domain (www.domain1.com, www.domain2.com) and databases (domain1, domain2).
  • Create two folders in drupal-8/sites/ folder with domain1, domain2 name, the folder path would be like this drupal-8/sites/domain1/ and drupal-8/sites/domain2/
  • Create files/ folder in both the folder (drupal-8/sites/domain1/files)
  • Copy the default.settings.php file and paste it into the both folder then rename it as settings.php ( drupal-8/sites/domain1/settings.php, drupal-8/sites/domain1/settings.php)
  • Edit the settings.php file for domain1 to adding the database,
$databases['default']['default'] = array (
  'database' => 'domain1', // Change value to domain1 for www.domain.com and domain2 for www.domain2.com.
  'username' => 'root',
  'password' => 'root',
  'prefix' => '',
  'host' => 'localhost',
  'port' => '3306',
  'namespace' => 'Drupal\\Core\\Database\\Driver\\mysql',
  'driver' => 'mysql',
);
  • Copy the drupal-8/sites/example.sites.php file and paste in on the same location then change the file name to sites.php (drupal-8/sites/sites.php)
  • Add the following line in the bottom of the drupal-8/sites/sites.php file
$sites = array(
 'domain1' => 'domain1.com', // Folder name => Domain name.
 'domain2' => 'domain2.com',
);

Thats all, both domain would works well with the different db with a single instance.

Sep 24 2020
Sep 24

I needed a way to check the currect user has permission to view the currect/particular page, Searched lot finally got the exact way, going to show the tricks to you in this blog.

Drupal has an api called " drupal_valid_path " , Normally it used to test the url is valid or not. but the trick is that, It also check the user has permission to view the currect/particular page.

It will return TRUE If path is valid and user has permission to view the page, otherwise it will return FALSE,

For example,

$path = current_path();
if (drupal_valid_path($path)) {
  // Your code here.
}
Sep 24 2020
Sep 24

Most of the times developers don't like the GUI, It makes feel lazy. Drupal has a tool (Drush) to do some management work from command line.

And also the installing the drupal site makes very lazy while doing with browser, The Drush has an option to install the full site with a single command.

The Following command will install the drupal in standard method,

drush site-install standard --account-name=admin --account-pass=[useruser_pass] --db-url=mysql://[db_user]:[db_pass]@localhost/[db_name]
Sep 24 2020
Sep 24

What is a views display extender

The display extender plugin allow to add additional options or configuration to a views regardless of the type of display (e.g. page, block, ..).

For example, if you wanted to allow site users to add certain metadata to the rendered output of every view display regardless of display type, you could provide this option as a display extender.

What we can do with it

We will see how we implement such a plugin, for the example, we will add some metadata (useless metatags as example) to the document head when the views is displayed.

We will call the display extender plugin HeadMetadata (id: head_metadata) and we will implement it in a module called views_head_metadata.

The implementation

Make our plugin discoverable

Views do not discover display extender plugins with a hook info as usual, for this particular type of plugin, views has a variable in his views.settings configuration object.

You need to add your plugin ID to the variable views.settings.display_extenders (that is a list).

To do so, I will recommend you to implement the hook_install (as well uninstall) in the module install file. To manipulate config object you can look at my previous notes on CMI.

Make the plugin class

As seen in the previous post on Drupal 8 plugins, you need to implement the class in the plugin type namespace, extend the base class for this type of plugin, and add the metadata annotation.

In the case of the display extender plugin, the namespace is Drupal\views_head_metadata\Plugin\views\display_extender, the base class is DisplayExtenderPluginBase, and the metadata annotation are defined in \Drupal\views\Annotation\ViewsDisplayExtender.

The display extender plugins methods are nearly the same that the display plugins, you can think of its like a set of methods to alter the display plugin.

The important methods to understand are :

  • defineOptionsAlter(&$options) : Define an array of options your plugins will define and save. Sort of schema of your plugin.
  • optionsSummary(&$categories, &$options) : To add a category (the section of the views admin interface) if you want to add one, and define your options settings (in wich category there are, and the value to display as the summary).
  • buildOptionsForm(&$form, FormStateInterface $form_state) : Where you construct the form(s) for your plugin, of course linked with a validate and submit method.

Generate the metadata tags in the document head

Now that we have our settings added to every views display, we need to use those to generate the tags in the document head as promised.

To work on the views render we will use the hook for that : hook_views_pre_render($view) and the render array property #attached.

Implement that hook in the .module of our module views_head_metadata, let's see :

Sep 24 2020
Sep 24

For the example we are going to implement an area that will present some links and text in a custom way, not sure if it's really usefull, but that not the point of this article.

The Plugin system

For the first post on the plugins I will introduce briefly on the concept. For those that already been using Ctools plugins system, you already now about the plugin system purposes.

For those who doesn't know about it, the plugin system is a way to let other module implements her own use case for an existing features, think of Field formatter : provide your own render array for a particular field display, or Widget : provide your own form element for a particular field type, etc...

The plugin system has three base elements :

Plugin Types

The plugin type is the central controlling class that defines how the plugins of this type will be discovered and instantiated. The type will describe the central purpose of all plugins of that type; e.g. cache backends, image actions, blocks, etc.

Plugin Discovery

Plugin Discovery is the process of finding plugins within the available code base that qualify for use within this particular plugin type's use case.

Plugin Factory

The Factory is responsible for instantiating the specific plugin(s) chosen for a given use case.

Detailled informations : https://www.drupal.org/node/1637730

In our case Views is responsible of that implementations so we are not going further on that, let see now how to implement a plugin definition.

The Plugin definitions

The existing documentation on the plugin definitions are a little abstract for now to understand how it really works (https://www.drupal.org/node/1653532).

You have to understand simply that a Plugin in most case is a Class implementation, namespaced within the namespace of the plugin type, in our example this is : \Drupal\module_name\Plugin\views\area

So if I implement a custom views area Plugin in my module the class will be located under the location module_name/src/Plugin/views/area/MyAreaHandler.php

To know where to implement a plugin definition for a plugin type, you can in most case look at module docs, or directly in the source code of the module (looking at an example of a definition will be enough)

In most cases, the modules that implement a Plugin type will provide a base class for the plugins definitions, in our example views area provide a base class : \Drupal\views\Plugin\views\area\AreaPluginBase

Drupal provide also a base class, if you implement a custom Plugin type, for the Plugin definition : \Drupal\Component\Plugin\PluginBase

Your custom plugin definition class must also have annotation metadata, that is defined by the module that implement the plugin type, in our example : \Drupal\views\Annotation\ViewsArea

In the case of views you will also need to implement the hook_views_data() into module_name.views.inc file, there you will inform views about the name and metadata of your Area handler.

Hands on implementation

So we have a custom module let's call it module_name for the example :)

We will create the class that implements our plugin definition and we are gonna give it this Plugin ID : my_custom_site_area.

We save this file into module_name/src/Plugin/views/area/MyCustomSiteArea.php

Now we just have to implements the hook_views_data() and yes this is the end, you can use your awesome views area handler into any view and any area.

Define this hook into the file : module_name/module_name.views.inc

Sep 24 2020
Sep 24

There is three types of configuration data :

The Simple Configuration API

  • Used to store unique configuration object.

  • Are namespaced by the module_name.

  • Can contain a list of structured variables (string, int, array, ..)

  • Default values can be found in Yaml : config/install/module_name.config_object_name.yml

  • Have a schema defined in config/schema/module_name.schema.yml

Code example :

The States

  • Not exportable, simple value that hardly depend of the environment.

  • Value can differ between environment (e.g. last_cron, maintenance_mode have different value on your local and on the production site)

The Entity Configuration API

  • Configuration object that can be multiple (e.g. views, image style, ckeditor profile, ...).

  • New Configuration type can be defined in custom module.

  • Have a defined schema in Yaml.

  • Not fieldable.

  • Values can be exported and stored as Yaml, can be stored by modules in config/install

Code example :

  https://www.drupal.org/node/1809494

Store configuration object in the module :

Config object (not states) can be stored in a module and imported during the install process of the modules.

To export a config object in a module you can use the configuration synchronisation UI at /admin/config/development/configuration/single/export

Select the configuration object type, then the object, copy the content and store it in your custom module config/install directory following the name convention that is provided below the textarea.

You can also use the features module that is now a simple configuration packager.

If after the install of the module, you want to update the config object, you can use the following drush command :

Configuration override system

Remember the variable $conf in settings.php in D6/D7 for overriding variables.

In D8, you can also override variable from the configuration API:

You can also do overrides at runtime.

Example: getting a value in a specific languages :

Drupal provide a storage for override an module can specify her own way of override, for deeper informations look at :

https://www.drupal.org/node/1928898

Configuration schema

The config object of Config API and of the configuration entity API have attached schema defined in module_name/config/install/module_name.schema.yml

These schema are not mandatory, but if you want to have translatable strings, nor form configuration / consistent export, you must take the time to implement the schema for your configuration object. However if you don't want to, you can just implement the toArray() method in your entity config object class.

Example, docs and informations : https://www.drupal.org/node/1905070

Configuration dependencies calculation

Default is in the .info of the module that define the config object like in D6/D7

But config entity can implements calculateDependencies() method to provide dynamic dependencies depending on config entity values.

Think of Config entity that store field display information for content entities specific view modes, there a need to have the module that hold the fields / formatters in dependencies but these are dynamic depending on the content entity display.

More information : https://www.drupal.org/node/2235409

Sep 24 2020
Sep 24

Ressources

Migrate in Drupal 8

Migrate is now included in the Drupal core for making the upgrade path from 6.x and 7.x versions to Drupal 8.

Drupal 8 has two new modules :
Migrate: « Handles migrations »
Migrate Drupal : « Contains migrations from older Drupal versions. »

None of these module have a User Interface.

« Migrate » contains the core framework classes, the destination, source and process plugins schemas and definitions, and at last the migration config entity schema and definition.

« Migrate Drupal » contains implementations of destination, sources and process plugins for Drupal 6 and 7 you can use it or extend it, it's ready to use. But this module doesn't contain the configuration to migrate all you datas from your older Drupal site to Drupal 8.

The core provides templates of migration configuration entity that are located under each module of the core that needs one, under a folder named 'migration_templates' to find all the templates you can use this command in your Drupal 8 site:

To make a Drupal core to core migration, you will find all the infos here : https://www.Drupal.org/node/2257723 there is an UI in progress for upgrading.

A migration framework

Let have a look at each big piece of the migration framework :

Source plugins

Drupal provides an interface and base classes for the migration source plugin :

  • SqlBase : Base class for SQL source, you need to extend this class to use it in your migration.
  • SourcePluginBase : Base class for every custom source plugin.
  • MenuLink: For D6/D7 menu links.
  • EmptySource (id:empty): Plugin source that returns an empty row.
  • ...

Process plugins

There is the equivalent of the D7 MigrateFieldHandler but this is not reduced to fields or to a particular field type.
Its purpose is to transform a raw value into something acceptable by your new site schema.

The method transform() of the plugin is in charge of transforming your $value or skipping the entire row if needed.
If the source property has multiple values, the transform() will happen on each one.

Drupal provides migration process plugin into each module of the core that needs it (for the core upgrade),
To find out which one and where it is located you can use this command :

Destination plugins

Destination plugins are the classes that handle where your data are saved in the new Drupal 8 sites schemas.

Drupal provides a lot of useful destination classes :

  • DestinationBase : Base class for migrate destination classes.
  • Entity (id: entity) : Base class for entity destinations.
  • Config (id: config) : Class for importing configuration entities.
  • EntityBaseFieldOverride (id: entity:base_field_override): Class for importing base field.
  • EntityConfigBase : Base class for importing configuration entities.
  • EntityImageStyle (id: entity:image_style): Class for importing image_style.
  • EntityContentBase (id: entity:%entity_type): The destination class for all content entities lacking a specific class.
  • EntityNodeType: (id: entity:node_type): A class for migrate node type.
  • EntityFile (id: entity:file): Class for migrate files.
  • EntityFieldInstance: Class for migrate field instance.
  • EntityFieldStorageConfig: Class for migrate field storage.
  • EntityRevision, EntityViewMode, EntityUser, Book...
  • And so more…

Builder plugins:

"Builder plugins implement custom logic to generate migration entities from migration templates. For example, a migration may need to be customized based on the data that is present in the source database; such customization is implemented by builders." - doc API

This is used in the user module, the builder create a migration configuration entity based on a migration template and then add fields mapping to the process, based on the data in the source database. (@see /Drupal/user/Plugin/migrate/builder/d7/User)

Id map plugins:

"It creates one map and one message table per migration entity to store the relevant information." - doc API
This is where rollback, update and the map creation are handled.
Drupal provides the Sql plugin (@see /Drupal/migrate/Plugin/migrate/id_map/Sql) based on the core base class PluginBase.

And we are talking only about core from the beginning.
All the examples (That means docs for devs) are in core !

About now :

While there *almost* a simple UI to use migration in Drupal 8 for Drupal to Drupal, Migrate can be used for every kind of data input. The work is in progess for http://Drupal.org/project/migrate_plus to bring an UI and more source plugins, process plugins and examples. There already is the CSV source plugin and a pending patch for the code example. The primary goal of « migrate plus » is to have all the features (UI, Sources, Destinations.. ) of the Drupal 7 version.

Concrete migration

(migration with Drupal 8 are made easy)

I need to migrate some content with image, attached files and categories from custom tables in an external SQL database to Drupal.

To begin shortly :

  • Drush 8 (dev master) and console installed.
  • Create the custom module (in the code, I assume the module name is “example_migrate”):
    $ Drupal generate:module
    or create the module by yourself, you only need the info.yml file.
  • Activate migrate and migrate_plus tools
    $ Drupal module:install migrate_tools
    or
    $ drush en migrate_tools
  • What we have in Drupal for the code example :
    • a taxonomy vocabulary : ‘example_content_category’
    • a content type ‘article’
    • some fields: body, field_image, field_attached_files, field_category
  • Define in settings.php, the connexion to your external database:

We are going to tell migrate source to use this database target. It happens in each migration configuration file, it’s a configuration property used by the SqlBase source plugin:

This is one of the reasons SqlBase has a wrapper for select query and you need to call it in your source plugin, like $this->select(), instead of building the query with bare hands.

N.B. Each time you add a custom yml file in your custom module you need to uninstall/reinstall the module for the config/install files to imports. In order to avoid that, you can import a single migration config file by copy/paste in the admin/config configuration synchronisation section.

The File migration

The content has images and files to migrate, I suppose in this example that the source database has a unique id for each file in a specific table that hold the file path to migrate.

We need a migration for the file to a Drupal 8 file entity, we write the source plugin for the file migration:

File: src/Plugin/migrate/source/ExampleFile.php

We have the source class and our source fields and each row generate a path to the file on my local disk.

But we need to transform our external file path to a local Drupal public file system URI, for that we need a process plugin. In our case the process plugin will take the external filepath and filename as arguments and return the new Drupal URI.

File: src/Plugin/migrate/process/ExampleFileUri.php

We need another process plugin to transform our source date values to timestamp (created, changed), as the date format is the same across the source database, this plugin will be reused in the content migration for the same purpose:

File: src/Plugin/migrate/process/ExampleDate.php

For the destination we use the core plugin: entity:file.

Now we have to define our migration config entity file, this is where the source, destination and process (field mappings) are defined:

File: config/install/migrate.migration.example_file.yml

We are done for the file migration, you can execute it with the migrate_tools (of the migrate_plus project) drush command:

The Term migration

The content has categories to migrate.
We need to import them as taxonomy term, in this example I suppose the categories didn't have unique ids, it is just a column of the article table with the category name…

First we create the source :

File: src/Plugin/migrate/source/ExampleCategory.php

And we can now create the migration config entity file :

File: config/install/migrate.migration.example_category.yml

This is done, to execute it :

The Content migration

The content from the source has an html content, raw excerpt, image, attached files, categories and the creation/updated date in the format Y-m-d H:i:s

We create the source plugin:

File: src/Plugin/migrate/source/ExampleContent.php

Now we can create the content migration config entity file :

File: config/install/migrate.migration.example_content.yml

Finally, execute it :

Group the migration

Thanks to migrate_plus, you can specify a migration group for your migration.
You need a to create a config entity for that :

File: config/install/migrate_plus.migration_group.example.yml

Then in your migration config yaml file, be sure to have the line migration_group next to the label:

So you can use the command to run the migration together, and the order of execution will depend on the migration dependencies:

I hope that you enjoyed our article.

Best regards,

Delta https://www.drupal.org/u/delta

Sep 24 2020
Sep 24

At Studio.gd we love the Drupal ecosystem and it became very important to us to give back and participate.
Today we're proud to announce a new module that we hope will help you !

Inline Entity Display module will help you handle the display of referenced entity fields directly in the parent entity.
For exemple if you reference a taxomony "Tags" to an Article node, you will be able directly in the manage display of the article to display tags' fields. It can become very usefull with more complex referenced entity like field collection for exemple.

VOIR LE MODULE : https://www.drupal.org/project/inline_entity_display


Features

- You can control, for each compatible reference field instances, if the fields from the referenced entities would be available as extra fields. Disabled by default.

- You can manage the visibility of the referenced entities fields on the manage display form. Hidden by default.

- View modes are added to represent this context and manage custom display settings for the referenced entities fields in this context {entity_type}_{view_mode} Example: "Node: Teaser" is used to render referenced entities fields, when you reference an entity into a node, and you view this node as a teaser if there are no custom settings for this view mode, fields are rendered using the default view mode settings.

- Extra data attributes are added on the default fields markup, so the field of the same entity can be identified.

Compatible with Field group on manage display form.

Compatible with Display Suite layouts on manage display form.

Requirements

- Entity API
- One of the compatible reference fields module.

Tutorials

simplytest.me/project/inline_entity_display/7.x-1.x
The simplytest.me install of this module will come automatically with these modules: entity_reference, field_collection, field_group, display suite.

VOIR LE MODULE : https://www.drupal.org/project/inline_entity_display

We are currently developping a similar module for Drupal 8 but more powerful and more flexible, Stay tuned !

Sep 24 2020
Sep 24

The much-awaited Drupal 9 has been out and about for over a month now. Introduced amid a global pandemic, it wasn’t as big a launch as Drupal 8 in 2015.

Like Dries said, “The big deal about Drupal 9 is that... it shouldn’t be a big deal.”

So far, we don’t have much to dissect in the Drupal 9 update, so we’ll take a peek into Drupal 8’s transition over the years, and how it gave way to Drupal 9. Considering how every minor update in Drupal 8 has improved the CMS, we‘ll try to foresee the trajectory of Drupal 9.

Drupal 8 So Far

Drupal 8.0.0 was the first fully supported release of Drupal 8, released in 2015 as the biggest update ever to the Open Source CMS, Drupal. 

Note on semantic versioning

  • A MAJOR version is when incompatible API changes are made, e.g. the launch of Drupal 9 and complete removal of the deprecated code.
  • A MINOR version is when functionality is added in a backward-compatible manner. e.g. Drupal 8.2 to Drupal 8.3. 
  • A PATCH version is when backward-compatible bug fixes are done.

Drupal 8.1 - Drupal 8.4

20 April 2016 to 4 Oct 2017

The BigPipe module was included in Drupal 8 core with the Drupal 8.1 update, and it became stable in Drupal 8.3. We also saw Drupal 8.2.0 adopting coding standards changes.

Drupal 8.4 included major version updates for Symfony, jQuery and jQuery UI, and was no longer compatible with older versions of Drush. Drupal 8.4 also introduced media in the core.

Drupal 8.5 - Drupal 8.7

7 Mar 2018- 1 May 2019

Drupal 8.5 and 8.6 provided new improvements and functionality without breaking backward compatibility (BC) for public APIs.

The in-demand layout builder was launched with Drupal 8.7 and it changed the structure for Drupal editors significantly. 

Note: If you are still on version 8.6.x or older, you can skip directly to 8.8.x and have the upgrade path bug fixes applied.  

Drupal 8.8 and Drupal 8.9

Drupal8.8 launched on 4 Dec 2019

These last two updates paved the way for Drupal 9 to be built within Drupal 8. Drupal 8.8.0 declared a conflict with modules like Pathauto 8.x-1.5 or lower.

Drupal 8.8.0 ends the PHP 5.5 and 5.6 support and updates will now fail if servers are not updated to at least PHP 7.0.8.

Thus, Drupal 8.9, as the final minor release of the 8.x series, is a long-term support (LTS) version and will be supported until November 2021. Though Drupal 8.9 runs on all PHP 7 versions, it is recommended to update to at least PHP 7.3. 

Introducing Drupal 9

A cleaned-up version of Drupal 8, we saw the launch of Drupal 9 with updated dependencies and the removal of deprecated code. Though the vast majority of Drupal 8 migration tutorials will apply to your Drupal 9 sites, there's no one-size-fits-all process for upgrading/migrating. 

Initiatives We Look Forward to in the Drupal 9 Release Cycle

We can expect the theme Olivero, being built in the contributed project for inclusion in Drupal core, to be added as an experimental theme in the impending Drupal 9.1 update. Similarly, the theme Claro could be marked stable as it is already experimental in Drupal 8.8.

Apart from this, we expect to see automated updates in the core, CMI 2.0, and JavaScript modernization.

Here’s a list of various other strategic initiatives:

  1. API-First
  2. Automatic Updates
  3. Composer support in Core
  4. Configuration Management
  5. Documentation and Help
  6. Drupal 10 Readiness
  7. Media 
  8. New frontend theme
  9. Workflow

Migration Pre-requisites

Check out the tasks to be completed before you begin the migration process: 

  • Ensure your hosting environment matches the platform requirements of Drupal 9.
  • Update to the latest release, i.e. Drupal 8.8.x or 8.9.x 
  • Ensure Drupal 9 compatibility by updating contributed projects.
  • Make your custom code Drupal 9 compatible too.
  • Update core codebase to the major version, Drupal 9.
  • Lastly, run update.php.

Should You Migrate Your Drupal 8 Site? 

Migrating to Drupal 9 requires fully updating the Drupal 8 site to the most recent version of both the core and contributed modules and themes. This will ensure your database is Drupal 9-ready and only the code will change with some smaller database updates.

If your site is at any version below Drupal 8.8, then it’s a good time to start investing in upgrading. 

In case you are at either the Drupal 8.8 or Drupal 8.9 versions, then upgrading to Drupal 9 shouldn’t be that big a hassle for your team. Ensure your contributed modules are compatible with the latest release and your site is good to go. 

Conclusion

As a significant introduction, Drupal 8 embarked on a long and exciting journey with the Drupal community. Each minor update brought newer experiences, power-packed features, greater flexibility, and improved the overall outlook of the Open Source CMS. Today, the Drupal 9 version is entirely based on the workings of Drupal 8 itself. And it is only the hard work of the community and all their contributions that have helped Drupal reach this level of scalability and efficiency. 

Sep 24 2020
Sep 24

At the time of this writing, it’s over a month since Drupal 9 was released. While the Drupal community has grown over the last decade, thanks to the innovative release cycle and building bridges to other communities, Drupal 9 release festivities were not as grand as I remember for Drupal 8. A significant reason for this is the COVID-19 pandemic that we all are facing right now (I hope you’re okay reading this in the future). But there’s a bigger point here. Drupal upgrades are not exciting anymore. 

Stay with me for a minute. Drupal 8 will remain the most exciting Drupal release for the foreseeable future. It was an interesting time while we rewrote Drupal (almost) from the ground up. We did that using years of learned best practices and PHP community support. As a result, Drupal is more reliable and dependable now than ever before in its two decades of existence. On the other hand, Drupal 9 release was almost boring. The only thing we did was remove the deprecated code.

Understanding the Drupal release cycle

That’s a big deal here. As a community, we are approaching our tweens and deciding how best to lay our foundations for the long haul ahead. This is reflected in how we release Drupal. Drupal 1 through 4 were the only supported major versions throughout their lifetime. Drupal 5 support lasted well into the Drupal 6 lifecycle and this repeated for Drupal 7, 8, and 9. Due to an interesting combination of circumstances, Drupal 7’s support exceeds even Drupal 8.
Image Source


We are innovating by introducing new features on a schedule. Read more about the release cycle here. At the same time, we are keeping Drupal maintainable for the long-term. It’s of little consequence that not all Drupal 8 code will run on Drupal 9. The important thing is that most of the code will. In fact, with the predictable release schedule of deprecations and new features, a well-maintained site might have had nothing to do when upgrading to Drupal 9. We saw this with a flurry of tweets and other social media updates announcing that people have upgraded their sites to Drupal 9 within hours of release.
Image Source

Understanding major releases

Starting with Drupal 9, all major releases will be the same as the last minor release in the previous version, except for the absence of deprecated code. This means Drupal 9 is identical to Drupal 8.9 to everyone–editors, site builders, and developers (as long as they don’t use deprecated functionality). That will also be the case for Drupal 10 and Drupal 11. And this will go on until we see a significant shift in the PHP programming paradigm that warrants another Drupal 8 style rewrite (will it be generics or async programming or something else we haven’t yet imagined?)

Enough theory, what does this mean for you?

Based on everything we talked about above, let’s get down to business.

  • Are you running Drupal 6 or earlier?
    • Migrate right now.
  • Are you running Drupal 7?
    • You have until Nov 28, 2022, to migrate to Drupal 9. Yes, it would be best if you don’t plan to migrate to Drupal 8 right now*.
  • Are you running Drupal 8.8 or earlier?
    • Upgrade to Drupal 8.9 right now.
  • Are you running Drupal 8.9?
    • You’re good until November 2021. Evaluate your site’s contrib and custom code to plan for Drupal 9 upgrade when possible.
  • Are you running Drupal 9?
    • You have reached your destination.

* There are caveats to every situation. I always try to make sure that I never generalize.

Planning the upgrade to Drupal 9

You are on Drupal 8 and want to upgrade to Drupal 9? There are lots of resources to help, but I suggest you start by installing the Upgrade Status and Upgrade Rector modules. Chances are you won’t need to look elsewhere.

Upgrade Status module can check for Drupal 9 compatibility information for each of the modules you use (including custom modules) and, along with Upgrade Rector, generate patches that you can use on Contrib and custom modules. As we see here, many Contrib modules already have Drupal 9 compatible releases. Most of the remaining modules only need minimal changes to become compatible.

Personally, I have only upgraded one site to Drupal 9 so far. There are a few more sites I can upgrade to Drupal 9 right now if I switched to dev releases of certain modules I use. But there’s no good reason for me to hurry. My Drupal 8.9 site is as good as Drupal 9 in every way, except the amount of code, PHP has to load (and that’s not a major problem thanks to Opcache). We will only see new features in Drupal 9.1 in December 2020, and I can wait until then for the Contrib modules to have proper releases.

Understanding Drupal versioning

If you have used Drupal for some time, you might know that you recognize compatible Contrib modules by their version. For example, Pathauto 7.x-1.0 is for Drupal 7 only. It won’t work on Drupal 6, nor Drupal 8. Similarly, token 8.x-1.2 would not work on Drupal 7.

With Drupal 8, the community adopted semantic versioning for the core. This has now rolled out to even Contrib modules. This means that we would be dropping the familiar versioning system that we have used for over a decade in favor of semantic versioning. Don’t worry, existing major releases are fine. That means you would still see new releases coming out for Pathauto 8.x-1.x branch, but if it were ever to create a new major release, we would probably see Pathauto 2.0. Actually, we might see Pathauto in Core (I hope), but that’s a different story.

Some of the modules have adopted this and see new releases in semantic versioning style (devel comes to mind). Other modules are still on their existing 8.x-y.z release scheme because they don’t need to change anything. And that’s another sign of maturity in how we write code for Drupal.

Conclusion

Drupal has long since moved from being adventurous and made efforts to become more reliable and robust in serving the people, as it should. The Drupal community has long stood by its slogan: Come for the code, stay for the community. This shift in thinking about Drupal’s release cycle is a testament to that fact: Drupal is not built in a vacuum. It is built, foremost, to serve the people who would use it.

Sep 23 2020
Sep 23

Working in digital design and development, you grow accustomed to the rapid pace of technology. For example: After much anticipation, the latest version of Drupal was released this summer. Just months later, the next major version is in progress.

At July’s all-virtual DrupalCon Global, the open-source digital experience conference, platform founder Dries Buytaert announced Drupal 10 is aiming for a June 2022 release. Assuming those plans hold, Drupal 9 would have the shortest release lifetime of any recent major version.

For IT managers, platform changes generate stress and uncertainty. Considering the time-intensive migration process from Drupal 7 to 8, updating your organization’s website can be costly and complicated. Consequently, despite a longtime absence of new features, Drupal 7 still powers more websites than Drupal 8 and 9 combined. And, as technology marches on, the end of its life as a supported platform is approaching.

Fortunately, whatever version your website is running, Drupal is not running away from you. Drupal’s users and site builders may be accustomed to expending significant resources to update their website platform, but the plan for more frequent major releases alleviates the stress of the typical upgrade. And, for those whose websites are still on Drupal 7, Drupal 10 will continue offering a way forward.

The news that Drupal 10 is coming sooner rather than later might have been unexpected, but you still have no reason to panic just yet. However, your organization shouldn’t stand still, either.

Image via Dri.es

The End for Drupal 7 Is Still Coming, but Future Upgrades Will Be Easier

Considering upgrading to Drupal 8 involves the investment of building a new site and migrating its content, it’s no wonder so many organizations have been slow to update their platform. Drupal 7 is solid and has existed for nearly 10 years. And, fortunately, it’s not reaching its end of life just yet.

At the time of Drupal 9’s release, Drupal 7’s planned end of life was set to arrive late next year. This meant the community would no longer release security advisories or bug fixes for that version of the platform. Affected organizations would need to contact third-party vendors for their support needs. With the COVID-19 pandemic upending businesses and their budgets, the platform’s lifespan has been extended to November 28, 2022.

Drupal’s development team has retained its internal migration system through versions 8 and 9, and it remains part of the plan for the upcoming Drupal 10 as well. And the community continues to maintain and improve the system in an effort to make the transition easier. If your organization is still on Drupal 7 now, you can use the migration system to jump directly to version 9, or version 10 upon its release. Drupal has no plans to eliminate that system until Drupal 7 usage numbers drop significantly.

Once Drupal 10 is ready for release, Drupal 7 will finally reach its end of life. However, paid vendors will still offer support options that will allow your organization to maintain a secure website until you’re ready for an upgrade. But make a plan for that migration sooner rather than later. The longer you wait for this migration, the more new platform features you’ll have to integrate into your rebuilt website.

Initiatives for Drupal 10 Focus on Faster Updates, Third-Party Software

In delivering his opening keynote for DrupalCon Global, Dries Buytaert outlined five strategic goals for the next iteration of the platform. Like the work for Drupal 9 that began within the Drupal 8 platform, development of Drupal 10 has begun under the hood of version 9.

A Drupal 10 Readiness initiative focuses on upgrading third-party components that count as technological dependencies. One crucial component is Symfony, which is the PHP framework Drupal is based upon. Symfony operates on a major release schedule every two years, which requires that Drupal is also updated to stay current. The transition from Symfony 2 to Symfony 3 created challenges for core developers in creating the 8.4 release, which introduced changes that impacted many parts of Drupal’s software.

To avoid a repeat of those difficulties, it was determined that the breaking changes involved in a new Symfony major release warranted a new Drupal major release as well. While Drupal 9 is on Symfony 4, the Drupal team hopes to launch 10 on Symfony 6, which is a considerable technical challenge for the platform’s team of contributors. However, once complete, this initiative will extend the lifespan of Drupal 10 to as long as three or four years.

Other announced initiatives included greater ease of use through more out-of-the-box features, a new front-end theme, creating a decoupled menu component written in JavaScript, and, in accordance with its most requested feature, automated security updates that will make it as easy as possible to upgrade from 9 to 10 when the time comes. For those already on Drupal 9, these are some of the new features to anticipate in versions 9.1 through 9.4.

Less Time Between Drupal Versions Means an Easier Upgrade Path

The shift from Drupal 8 to this summer’s release of Drupal 9 was close to five years in the making. Fortunately for website managers, that update was a far cry from the full migration required from version 7. While there are challenges such as ensuring your custom code is updated to use the most recent APIs, the transition was doable with a good tech team at your side.

Still, the work that update required could generate a little anxiety given how comparatively fast another upgrade will arrive. But the shorter time frame will make the move to Drupal 10 easier for everybody. Less time between updates also translates to less deprecated code, especially if you’re already using version 9. But if you’re not there yet, the time to make a plan is now.

Sep 23 2020
Sep 23

Google Summer of Code (GSoC) is a global program focused on bringing more student developers into open source software development. Students work with an open source organization on a 3 month programming project during their break from school or college. In the 16th year of the program, 1106 students from 65 countries have successfully completed Google Summer of Code in 2020, including Drupal!

The Drupal Association’s Community Liaison, Rachel Lawson, caught up with those taking part in GSoC on Drupal related projects this year, to find out how things went, what they learned along the way, and what their future may hold.

You are invited to watch our “Community Chat”, with Vishal Chaudhary, Shawn McCabe, and Ryan Szrama.

Sep 23 2020
Sep 23

The main reason for the global arg() function to be deprecated in Drupal 8 and onwards is that it no longer served any specific need. Besides that, using the arg() function needed some extra care to avoid getting unexpected results. Say that you wanted to load a node on the path 'article/123', executing arg(1) would return '123' with which you could load the node. Using the '123' returned by arg(1) did not in any way guarantee that the path was valid or even that a node with ID 123 existed.

In Drupal 8 and onwards things are done differently. Consider the following:

$node = \Drupal::routeMatch()->getParameter('node');
if ($node instanceof \Drupal\node\NodeInterface) {
  $nid = $node->id();
  // Do whatever you need to do with the node ID here...
}

Getting the node ID this way is far more robust than doing so the old way using the arg() function. We know for sure the node exists and the path is valid because routeMatch() would not return a node object otherwise. As a bonus you can easily do some extra validation because you already have the node object loaded. You could, for instance, check that the node is of type 'article' by adding:

if ($node->bundle() == 'article') {

Getting the node ID this way may seem like a lot more work than using the deprecated arg() function, but it certainly guarantees a way more robust way of working which in turn will make your code better and more stable.

___

Need help developing your Drupal website? Our team of expert Drupal developers would be more than happy to help you out!

Sep 23 2020
Sep 23

Drupal keeps evolving in order to give you even more advanced digital capabilities.

We love to share useful content about upgrades with you — like the blog post about Drupal 7 to Drupal 8/9 Module Upgrader.

Time flies fast, and there is already a Drupal 10 release planned. What does all this mean for your website? Let’s take a closer look.

When will Drupal 10 be released?

Drupal creator Dries Buytaert wrote an article, and also gave a State-of-Drupal presentation, announcing the expected Drupal 10 release date should be two years from now — around June 2022. The next year, in 2023, D9 will be end-of-life. This means that website owners will need to upgrade to the 10th version before 2023.

“Hey, what do you mean by upgrading to Drupal 10? I am not even on the 8th version yet,” many of our readers might think at this moment. We are moving on to the answer right now.

Drupal 10 targeted release

Why is the Drupal 10 release planned so soon?

Indeed, the new pace of Drupal releases looks very fast compared to previous years. Both D9 and D10 fly out just two years after their predecessors, while D7 and D8 had a 4-5 year waiting time.

According to Dries, one of the key goals of the Drupal team is to keep the CMS secure. Drupal depends on third-party components that have their own release cycles and end-of-life dates. When they get unsupported, security bugs in them will no longer be fixed, so no one can guarantee website security.

In the case with Drupal, these components include Symfony 4, CKEditor 4, PHP7, and more. Special attention is paid to the Symfony components. Drupal will need to have adopted Symfony 5 (or an even higher version) by November 2023 — Symfony 4 end-of-life.

Updating third-party components for Drupal 10

What does Drupal 10 release mean for Drupal 7/8/9 website owners?

As stated above, everyone will need to upgrade to Drupal 10 by 2023 in order to provide website security and rich functionality according to the latest trends.

Why upgrade Drupal so often?

However, Drupal 10 release certainly does not mean any more cumbersome upgrades. The CMS is quickening its path and at the same time is getting extremely easy to upgrade. Beginning with a D8 to D9 upgrade and further, upgrades are almost instant, with just a few preparations websites should make. Making Drupal upgrades super easy is a big priority for its creators’ team, and they have achieved great success and will continue to work on it.

Drupal upgrades easy

This sounds nice, so let’s sum up what Drupal 7/8/9 owners should do about the future 10th release:

  • D7 website owners will need to make a big leap to the 8th version and then upgrade further very easily. They really need this move because the 7th version is getting technologically outdated. Review your website’s goals and reach out to our Drupal development team to plan your upgrade.
  • D8 and D9 website owners just need to keep their websites updated between the minor releases and clean from deprecated code. This guarantees quick upgrades to D9/10 and further in the future. Ask our Drupal developers to quickly check your website’s state and refresh it so it is ready to upgrade in a few clicks.

Be ready for the Drupal 10 release!

Although you have two years before the D10 release, you can start preparing your website now, especially if it is on D7. The future is around the corner and reaching it is very easy if you work with professionals. Contact our Drupal maintenance and support team and make your website modern, protected, and efficient!

Sep 23 2020
Sep 23

Here at Ny Media we are specialists in developing highly customized Drupal Commerce solutions. One of the recurring themes of a tailor-made e-commerce solution is to integrate some sort of order export towards the ERP solution that the client in question uses. And a very common way for us to do that is to hook into commerce order state transitions.

Typically a subscriber would make sure the actual export is queued through Drupal's queue system (or through Advanced Queue). This makes it possible to have exports that can retry, delay execution and generally be reliable and fault-tolerant.

However, this also involves integration towards third parties. No matter how fault-tolerant your integration is, you can not guard against all kinds of error in a third party application. Which is why from time to time I find myself needing to trigger these transitions again, for example to re-queue the order export. So here is an annotated code example how I achieved this:

<?php

// Replace this with the order id in question.
$order_id = 123456;
// If you want to do this within a class, probably use dependency injection
// instead of the Order class directly. The same goes for the services we are
// about to load statically from the service container.
/** @var \Drupal\commerce_order\Entity\OrderInterface $order */
$order = Order::load($order_id);
// This service is the event subscriber. We want to trigger the event
// subscriber only, and not dispatch the event from the event emitter so all
// subscribers can react to it.
/** @var \Drupal\nymedia_order_export\EventSubscriber\NymediaOrderExportSubscriber $order_export_event_subscriber */
$order_export_event_subscriber = \Drupal::service('nymedia_order_export.event_subscriber');
/** @var \Drupal\state_machine\WorkflowManager $workflow_plugin_manager */
$workflow_plugin_manager = \Drupal::service('plugin.manager.workflow');
// The type of order workflow you are using might vary from your site. See
// below for a note on how to find out.
/** @var \Drupal\state_machine\Plugin\Workflow\WorkflowInterface $workflow */
$workflow = $workflow_plugin_manager->createInstance('order_fulfillment');
// The transition in question will also vary based on your site. For a note on
// how to find out, read below.
$transition = $workflow->findTransition('draft', 'fulfillment');
$event = new WorkflowTransitionEvent($transition, $workflow, $order, 'state');
// Now trigger the event. The method here will be the one you have indicated
// will respond to the event. For example, if your event subscriber service
// has this in its public static function getSubscribedEvents:
// 'commerce_order.place.post_transition' => ['onPlace'],
// (the example is taken from this class itself), then you probably want to
// invoke the method ::onPlace, like we are doing here. If you are looking for
// another transition, or your class has a different method as a responder for
// the place transition event, then you probably want to adjust this
// accordingly.
$order_export_event_subscriber->onPlace($event);

As stated in the code above, there are some things that might not be obvious how you find out. Let's start with the order workflow ID.

How to find the workflow ID of an order type

To find out what kind of workflow you are using, you take a look at the order type for the order in question. On this particular site, there are 2 order types. The one that I had to re-queue is of the type "default". So I edit that order type, which can be found at mysite.com/admin/commerce/config/order-types/default/edit.

In there we can see that you can select the workflow for the order. And in the select dropdown, I can see that the ID for the chosen one is "order_fulfillment":

<option value="order_fulfillment" selected="selected">Fulfillment</option>

Another way to see this is to look at the configuration YML file for the default order type. It will look something like this, and in my case is called "commerce_order.commerce_order_type.default.yml":

uuid: 2a999511-7dbb-4a44-9599-6bad702ff032
# ... Content edited out for clarity.
label: Standard
id: default
# Here is the id of the workflow again:
workflow: order_fulfillment
# ... rest of the file.

How to find state IDs for the workflow transition

In my example, I wanted to get the transition where an order goes from "draft" to "placed". How did I know these IDs, and how did I know which ones to use?

To answer that, we should look up the definition of the workflow we have chosen. A workflow will most often be defined in a file called modulename.workflows.yml. In our case, we are actually using one of the workflows provided out of the box with Drupal Commerce, so the file to look at is commerce_order.workflows.yml. In here our workflow is defined as follows:

order_fulfillment:
  id: order_fulfillment
  group: commerce_order
  label: 'Fulfillment'
  states:
    draft:
      label: Draft
    fulfillment:
      label: Fulfillment
    completed:
      label: Completed
    canceled:
      label: Canceled
  transitions:
    place:
      label: 'Place order'
      from: [draft]
      to:   fulfillment
    fulfill:
      label: 'Fulfill order'
      from: [fulfillment]
      to: completed
    cancel:
      label: 'Cancel order'
      from: [draft, fulfillment]
      to:   canceled

We can see it has 4 states, and 3 transitions. The one we want is the one that is triggered when the user completes their purchase, and this is the transition with the ID "place". To find it, I used the state it was supposed to transition from and the state is was supposed to transition to, which you can see is "draft" and "fulfillment".

As you can see, the framework of Drupal Commerce makes it possible for us to create advanced types of integrations, which are fault-tolerant, flexible and scalable. If you are looking for a partner to develop a Drupal Commerce site with customized integrations, contact our team of experts, ready to create solutions for you, regardless of integration types, order types or workflow types.

Sep 23 2020
Sep 23

'History is important, but what we do today matters the most, and we realize that.'

At OpenSense Labs, we make sure you move on from the old glitches you've faced with your website and its performance and give it better and smoother user experience. We use decoupled Drupal to give your website versatile and structured content that the web experiences need. 

Brands these days communicate with their customers, not only through the websites but also through multiple touchpoints. Decoupled Drupal serves content through an API to be consumed by other mediums like mobile applications, kiosk displays, IoT, wearables, etc. Headless Drupal is not a new phenomenon, but with the rising digital era, it is getting more and more important. You can either go for a progressively decoupled approach or fully decoupled approach based on your project requirements and we have successfully launched websites using both the approaches.

Let me take you through the websites created and revamped by us using decoupled Drupal. 

Paramount software solution

Home page of Paramount software solution


Paramount software solutions, being one of the leading IT Service providers in infrastructure management, application, blockchain, architecture, etc, protects your investments and enhances your productivity. It provides dependable and integrated business solutions for small and large enterprises. 

Paramount Software Solutions wanted to build a portfolio website that would act as the gateway to its impeccable services. We built the site using Drupal’s powerful capabilities keeping in mind, rich user experience, and streamlined content management.

The need for a headless web application for Paramount software solutions was why Drupal was chosen in the first place.

Simplified content workflow, high web performance, high-level security, and SEO were taken into consideration for building the website. After doing a detailed analysis and taking a lot of feedback from the clients, OpenSense Labs decided to develop this website as a fully decoupled application.

With Drupal, we made sure that the security of the website remains top-notch.
JSON:API and JSON:API Extras modules were used to gain a full rest API for the Drupal application and it was ensured that the resource properties like alias fields, API path, etc could be altered easily. 

The RESTful Web services module was used to provide customizable and extensible RESTful API of data governed by Drupal. 

HTTP basic authentication was used to offer the functionality of authenticating username and password.

The full case study of Paramount Software Solutions is available on Drupal.org

AgWeb

Home page of AgWeb


AgWeb is the most influential web-property of Farm journal, which is one of the leading business information and media companies. AgWeb is an online platform for farmers to stay informed about the news of crop and livestock farming, live future trading data, market assessment, ag policy, weather forecast, and more.

AgWeb wanted to enhance its website and needed a solution to keep up with the changing landscape of web technologies. This required a complete migration of their old .NET based legacy website into the state-of-the-art CMS of Drupal and then retain the wonderful search engine rankings gathered by it over the years.

The main objective here was to enhance user engagement and brand identity. In this process, a lot of feature upgrades had to be done to make it simpler for future development.

By choosing Drupal 8, AgWeb could tailor its media solutions. It became easy to create a listing with the assistance of views and enhance speed, scale, and stability. 

We planned the project in sprint-based development cycles and for the successful migration of content from the old .NET website to Drupal 8, the Scrum process was applied. 

Progressively decoupled blocks were used to build features like search and crop comments. We were able to improve the on-site search with the help of React and Elasticsearch

Drupal 8 gave the website a modernized look which resulted in higher user management. Drupal's support assured that the page load time of the website is much lesser than the old one. The website's Google rankings accelerated with the help of SEO enhancements.

The full case study of AgWeb is available on Drupal.org

Produce Market Guide

Home page of Produce Market guide


The PMG is also a product of Farm Journal. It is a resource that produces commodity information, data analysis, and trends. This platform shared information on fresh fruits and vegetables and is also the industry's leading source of information and news.

There were not many features required in the architecture, as the PMG website was already based on Drupal. So, the joint client-vendor system decided to progressively decouple the search functionality. This new search feature was built using React and elastic.

Drupal was chosen because of its flexibility. The customer already had prior experience with Drupal. And the built-in API-first support and easy third-party integration added to the many reasons why Drupal should be used again.

They wanted us to build search applications with facets and track user activities for personalized and smooth user experience.

Elastic backend architecture was developed using the ElasticSearch Connector module. Then, the biggest challenge was to add the SearchKit and React in the same search. SearchKit was used to design and develop the front end, the logic, and the project structure.

The new PMG website now takes less time to load than before. The project did not even take a month to complete. We followed the principles of Scrum and Agile by arranging themselves according to their needs.

The full case study of Produce Market guide is available on Drupal.org

Conclusion

Decoupled Drupal has helped websites in many ways and we love creating and revamping websites using it. It gives a content-rich experience, with a great presentation layer. 

If you love what we have done to these websites, and wish to have the same experience for yours, contact us at [email protected]

Sep 23 2020
Sep 23

Last week, 12 folks (including one brand new face) joined our first MidCamp 2021 planning meeting. The intent of our meeting was to begin discussions for a format for 2021, but almost like clockwork, our discussion quickly came back to the classic existential question: “What are we doing here?”

You might be thinking: “Uh, what? Why is a reliably delivered event now in its seventh year and with a sizable incumbent organizing team questioning their existence?” 

Well, we’d pose to you: “Why not?”

I’ve played various roles on the MidCamp team since our inception at Drupal Camp Fox Valley 2013 and from the beginning our team has been dissatisfied with the status quo. From early efforts—like blind session selection and walking lanes, to early iterations of the Drupal Recording Initiative, to live captions as a service—the MidCamp team is always trying to be one step ahead… “trailblazing” if you will, which was my old Boy Scout troop’s motto.

So after we, hand-in-hand with NERD Summit, set the early standard for virtual Drupal events in March of 2020, of course our team wouldn’t be satisfied with “just another Zoom conference.”

There are lots of interesting ideas floating around in this space now: all new sessions, all BoFs, un-conferences, substituting monthly meetups for a yearly event, virtual sightseeing. This all leads back to: Why should MidCamp exist in 2021? What do we add to the conversation?

Here’s what we know:

  • We will not be hosting a physical event in March of 2021.
  • We are known for the care we take in crafting Drupal events for humans.
  • We are not satisfied with the status quo and seek to continue being pioneers in the events space.
  • Contribution beyond the Drupal space is essential for Drupal’s vitality, now more than ever.
  • While we welcome all, MidCamp’s goal is to serve Chicago-area Drupalists first.

Here’s what we don’t know:

  • Does the world need another virtual conference?
  • What does being a “regional camp” mean when events are globally available?
  • Is it better to have more speaking opportunities or more focused content?
  • How can we (or can we at all) recreate the human-centric experience that we all look forward to each year without being together IRL. 

If you’ve got this far, we’d love for you to share your answers and help shape MidCamp 2021.

Many thanks,

Avi Schwab
MidCamp 2021-2022 Lead

Sep 22 2020
Sep 22

Bay Area Drupal Camp has gone — wait for it — 100% virtual! BADCamp is a community run celebration of open-source software with a keen focus on learning and inclusivity. Every year this event brings Drupal users, developers, marketers, and content specialists together from all over the country for high value talks, summits and trainings.

While you’ll have to forego the trip to beautiful Berkeley, California this year, the good news is that registration is free and the 2020 session lineup is as packed as ever. Mark your calendar for this October 14th - 17th, and get ready to join Aten, the Bay Area Community, and your colleagues and peers from across the country in three major session tracks: Drupal for Beginners, Advanced Drupal, and Marketing & Communications.

Aten is excited to sponsor this year’s Higher Education Summit, and for our team to contribute a few sessions of their own, detailed below. Register for BADCamp 2020 today!

Friday, October 16th

Managing People: The Art & The Science, 1 PM PST

Project Managers are tasked with organizing client schedules, timelines, meetings, internal resources and much, much more. Every one of a PM’s tasks overlap in a central — and often complex — practice: managing people. Join Janice Camacho, Project Manager, as she explores the art of meeting each individual where they’re most comfortable, and the science of why they’re comfortable there. In this session you’ll learn how to get out of your own way and build the healthy, confident project teams that support strong, long-term client relationships.

True Life: I’m an introvert in an extrovert’s world, 2 PM PST

Do you shy away from speaking up in a crowded room? Do you prefer to maintain a carefully guarded bubble of personal space? Does the prospect of addressing an audience make you perspire and/or shake? Introverts exist in the world of Digital Project Management, too. Gasp! And — perhaps contrary to intuition — they bring a unique set of strengths and abilities to the table, much like their extraverted counterparts. Join Kacie Miner, Digital Project Manager, as she shares her experience of being an introvert in the DPM space. In this session you’ll learn:

  • Strengths, abilities, and positive attributes that introverts bring to the table
  • Ways to adapt your personality to the job at hand without changing who you are
  • Strategies that will set you up for success instead of causing you to overthink
  • Tips and tools to know where you lie on the extrovert scale, and knowing how to recover
  • How to develop your own toolkit for being fully prepared when put on the spot

Layout Building in Drupal, 3 PM PST

The Layout Discovery API has dramatically changed the way Drupal 8 websites are designed, built and maintained. Solutions like Layout Builder, Entity Reference with Layout, and Layout Paragraphs have added a new dimension of content presentation on top of traditional content management. With these tools content editors have more control over their online presence than ever before — but this newfound flexibility isn’t without its own challenges. Join James Nettik, Front-end Developer, as he covers the essentials of layout building in Drupal 8. This session will cover:

  • An overview of the tools available today and their pros and cons
  • How to begin working with the new Layout Discovery API
  • Tips to keep the authoring experience as intuitive as possible
  • Solutions to common questions and pitfalls while designing and building

Don’t miss your opportunity to learn the latest in Drupal, network with fellow professionals, and attend in-depth technical and management training. Register for BADCamp 2020 today. We’ll see you there!

Sep 22 2020
Sep 22

At DrupalCon Global 2020, Tag 1 Consulting CEO Jeremy Andrews and Managing Director Michael Meyers talked about the upcoming Drupal 7 and Drupal 8 end of life. In their talk, they discussed:

  • What Drupal “End of Life” (EOL) means
  • When it happens, and how D7 and D8 differ
  • Why widely used versions are retired
  • Practical implications and your options
  • What Drupal vendor Extended Support (ES) Is
  • Why ES only covers D7, and not D8
  • How ES operates, and what it covers

[embedded content]

What Drupal “End of Life” (EOL) means

When a version of Drupal reaches EOL, the Drupal community will no longer work on it or provide free support. Core development stops entirely - no new features are added, no bugs will be fixed. The core issue queues will be locked, you will be prevented from adding anything to Drupal 7 & 8 Core on Drupal.org.

While Drupal 6 Core is locked, contrib is still open. Drupal 7 & 8 will likely do the same, so you can update your modules. Very few 6.x modules were updated after the Drupal 6 EOL, and many maintainers closed their branches as well. Expect that most contrib module owners will close their 7 and 8 branches.

In addition to the issues queue, the testing infrastructure will most likely be decommissioned. The PHP versions supported by these versions of Drupal are also EOL. Each D7ES vendor has a member on the security team, but the Drupal security team will no longer be proactively involved in reviews. This may mean less secure code unless you participate in a D7ES program, or manually track patches as they become available.

When is the EOL date?

Drupal 7 reaches end of life in November of 2022.It was originally scheduled for November of 2021. The date was extended due to the large user base, and the difficulties stemming from the global coronavirus pandemic.

Drupal 8 reaches end of life on November 2, 2021. While it may be confusing that Drupal 8 reaches EOL before Drupal 7, Drupal 8 is dependent on Symfony 3, which reaches the Symfony community’s EOL at that time.

Why widely used versions are retired

There are many reasons to retire older software.

  • Legacy: Drupal 7 is 10 years old, and will be ~12 by EOL in Nov. 2022
  • Bandwidth: Developers can’t support Drupal 7 and 8 while building Drupal 9 and 10
  • Interest: Developers don’t want to focus on 10 year old technology
  • Innovation: Improvement through innovation is the best for Drupal as software

Drupal 7 and 8’s end of life is a challenge. Rebuilding your website on new technologies (which also have their own EOL schedules), can be expensive and time consuming. Drupal 8 to Drupal 9 is an easier upgrade, making its EOL less problematic for users.

Practical implications and your options

Drupal 7 users have several options. The higher cost options are:

  • Don’t migrate. This is a bad choice, because it leaves your website vulnerable to attack, potentially losing data.
  • Migrate to Drupal 9. This is a good choice, keeping your site up to date with a similar ecosystem.
  • Move to a new CMS. Similar in cost to a Drupal 9 migration, with the added cost of training your teams on new technologies.

Lower cost options are:

  • End of life your website.
  • Turn your website into a static website.
  • Keep running Drupal 7, and work with a Drupal 7 vendor in the Extended Support (D7ES) program.

What Drupal vendor Extended Support (ES) is

D7ES ensures Drupal 7 remains secure and safe to run. Companies approved to offer D7ES must provide at least the following services:

  • Security patches for D7 core, including vulnerabilities that are reported for supported versions of Drupal
  • A specific list of contributed modules will be identified, and security patches will be provided for them
  • Vendors must make a commitment to offer these services for at least 3 years; at a minimum, you should receive D7ES through 2025
  • All patches created by D7ES vendors must be open source - if a D7ES vendor fixes any problem with D7, they are obligated to release the fix
  • Vendors must have an active member on the Drupal Security Team

The more the community supports this effort, the more vendors will offer it, and the more fixes they’ll be able to provide. Official vendors are vetted by the Drupal Association and listed on the D7 Vendor Extended Support page. Drupal 7 ES does not follow a formal release schedule, and your website must be on the final EOL version of Drupal 7 in order to participate in the vendor programs.

To learn more about Tag1’s extended support program, see Tag1 Quo - the enterprise security monitoring service.

Photo by Ankhesenamun on Unsplash

Sep 22 2020
Sep 22

A seasoned web developer would call this a match made in heaven. Drupal and AngularJS together can create rich and dynamic web experiences that might want you to reconsider your web development strategy altogether.

We have already spoken about how Drupal has proven to be one of the best CMS frameworks out there.But what is AngularJS really and how does the combination of Drupal Angular Js work wonders for your website? Read on to also understand headless architecture better with a case study.

Why go the Headless way?

“Each man is capable of doing one thing well. If he attempts several, he will fail to achieve distinction in any” – Plato.

This quote is so relevant today when we talk about CMSs and Headless architectures. Content management systems like Drupal are fantastic at managing content and data. However, with the increasing number of channels, API access points, front-end interactions and many more modern user experience demands that it is required to support, traditional CMS structures often seem inadequate. For more ambitious digital experiences, traditional architectures are now often being replaced with headless architectures. Headless or decoupled websites leverage a JavaScript framework for front-end interactions while maintaining a CMS like Drupal to manage the content. 

CASE STUDY: In one of our recent projects for our client, a leading casual dining restaurant chain, we had implemented Angular to enable API-based communication built on top of Drupal 8. The application required to interact with the web, mobile app, POS front end and other restaurant and customer management modules. Combining Drupal 8 with Angular worked out great because not only did it enable us to support their multiple channels and access points, we also saw a huge improvement in the performance of the application. 

Headless Drupal or Decoupled Drupal

With headless Drupal, the browser does not directly connect to Drupal. Instead of seeing Drupal’s presentation layer/ theme, the user will see pages that have been created by front-end frameworks such as AngularJS. Data is provided in JSON format to the front-end framework. With JSON:API module now in core and moving Drupal 8’s API-First initiative forward, things are even easier now. The idea of implementing a headless Drupal with AngularJS is to use Drupal’s flexible and powerful back-end capabilities to the fullest while letting a more interactive front-end framework do the talking to the browser. It is believed that client-side front-end frameworks like AngularJS are the future of the web, and if you are looking to build a rich and dynamic website with little to no latency, Drupal Angular JS is the answer.

drupal-angularjs

The Super-heroic AngularJS

To put it simply, AngularJS is a JavaScript framework backed up by our very own glorious Google that can let you do really cool things on your user’s browser without having to fetch data from your server. HTML lets you create static pages and is not designed for dynamic views. JavaScript was created to make those static pages more interactive. Here’s some more good-to-know info about AngularJS -

Why The AngularJS And Drupal Combination Will Make You Rethink Your Web Strategy
•    AngularJS is an extremely lightweight and concise framework that is profoundly extensible and lets you do some seriously fascinating things with your website.
•    Web developers and designers love HTML for its simplicity, clarity and intuitivism in its code structure. AngularJS extends HTML to define user interfaces, hence letting you build interactive web applications that are highly functional and hard to break.
•    You can create reusable components with AngularJS code.
•    Its client-side nature keeps those cyber-attacks at bay as any injected data cannot go close to your server.
•    AngularJS implements the MVC (Model-View-Controller) framework which allows for faster development process, multiple views, asynchronous technique, SEO friendly development and many more valuable features.
•    Unit testing is a breeze with AngularJS as it comes setup with it making it fast and easy for developers to test their code.
•    With a mind-blowing functionality like two-way data binding, user actions can immediately trigger application objects and vice-versa, thereby proving to be an extremely interactive framework.

Drupal Meets AngularJS

When an impressive front-end framework meets a super-powerful backend content management framework, there ought to be fireworks! Drupal is a flexible and scalable enterprise-class CMS which can be used to develop powerful web applications that can be designed for small to large scale businesses. Being an open-source CMS, it is highly customizable and can be tailored to fit any business requirements. You can only imagine the extensibility and customizability the combination of the two open- source frameworks, Drupal and AngularJS, can provide. Two is better than one, they say. When put together, let’s look at the goodness Drupal AngularJS can provide.

Power Packed Performance

Drupal on its own can perform effectively even when dumped with heaps of functionality. However, when you offload some of the business logic to the client-side AngularJS, you are remarkably unburdening your Drupal backend. Using AngularJS for theming or presentation and Drupal as the backend data source can substantially boost the performance of your Drupal website. The powerful combination of headless Drupal with Angular Js will allow you to move display logic to the client-side and streamline your backend, thus resulting in a super speedy site.

Reduced Coding for developers

Creating a basic working Drupal website does not take a lot of coding or development work. AngularJS can make these basic Drupal websites more interactive, rich and dynamic without a lot of complex coding. AngularJS uses directives, HTML to define user interfaces, plain objects for data models, etc. which sums up to writing much lesser code. Since it uses HTML to define user interface codes, it makes it takes lesser efforts by the developers to build interactive pages when compared to writing complete Javascript codes.

Isolation of logic

AngularJS implements the MVC framework which lets you separate business, controller and model logic in your web application. Isolating application logic from user interface will result in a cleaner, clearer and non-redundant code structure. Should your most crucial developer leave you mid-way, with this architecture, it won’t be hard for a new one to catch up. This also helps remove a lot of backend logic from Drupal, thereby making it more light-weight and efficient.

Security – Raise the bar

With Drupal you can be assured of your website’s security if you have followed the security protocols diligently. In the huge Drupal community, it is hard to have a security flaw go un-noticed and un-patched thereafter. Headless Drupal with AngularJS adds that extra layer of security to Drupal websites. Since the browser communicates with AngularJS, there’s no direct server-side interaction. This makes it difficult for hackers to inject malicious code into databases.

Sep 21 2020
Sep 21

There are two kinds of instances that we never forget in our lives; one is when we hysterically cry, and the other is when we hysterically laugh. The other moments in our lives are bound to lose their place in our memories, but not these. Have you ever forgotten a time when you laughed like crazy or cried like a baby? You know I am right. 

These moments are not necessarily associated with your personal lives, these can be related to the professional and commercial experiences you witness at any point. Now, I would not be talking about the upsetting consumer encounters you might have had, since I do not want to dampen your day. Instead, I will be talking about the kind of experiences that make you go all smiles.

We smile because we are happy or smile because someone has cracked a funny joke. Jokes do not have to be limited to social gatherings and Whatsapp messages; they can transcend to the world of web design. Yes, you read it right. Today, jokes, or shall I say humour has become an integral part of web design. Humour has the potential of taking an ordinary website and making it extraordinary. 

If you don’t believe me, continue reading, and by the time you will finish, I am sure your opinion would have changed.

The Importance of Humour 

Humour is an element of our lives that makes it brighter and livelier. People look forward to reading jokes, making jokes and laughing at their hilarity. You know you like those PJs as well, they might not make any sense, but they can be funny. Stepping a little up from the PJs, and moving on to web design. Humour has become extremely important in the world of web designers. It can make or break their designs, it is that powerful. Let us understand why.

If someone is funny and quirky, you will instantly like him or may even be drawn to his or her funniness. Am I right? The same is true for web designs. A user experience that is instilled with enlightening as well as humorous elements is going to be a hit. Humour has the potential of contributing to sales by highlighting a product or service’s attractiveness and making you drawn to them. It does so by giving them a genuine personality. Don Norman believes the same and has vocalised his beliefs in his book, Emotional Design - Why We Love (or Hate) Everyday Things.

After a customer is lured in, you have to keep in mind his needs in order to gain his loyalty. These needs start with the functionality of a product, then move onto its reliability, after becoming satiated with the usability of the same, these needs are finally placated with the pleasure factor. If a product is pleasurable to the user, only then can it be deemed as a success. And you must know that pleasure and humour are the best of friends.

The image shows a pyramid with four segments, pleasure, usable, reliable and functional, describing the hierarchy of needs.Aaron Walter's pyramid of emotional design | Source: Treehouse

Humour is bound to create positive emotional stimuli in all of us. When a user experiences such a response from a web design, there is a high likelihood that he will develop a sense of trust in the same. And that is the reason why humour is important in web designs and should be implemented, but with caution. Read more about the link between decision science and web design to understand how to make design decisions. 

The Subjectivity of Humour 

Humour is a kind of quality that is possessed by everyone, yet everyone has a different notion of it. What may be funny to me, can be offensive for you and nobody can say that our notions about it are wrong. We just have a different perspective.

So, the web designers have to keep this in mind, you have to understand your audience before committing to any humorous elements you want in your designs. 

A web developer has to first comprehend the subjectivity of humour. Yes, every joke is not going to be funny for everyone, but it can be funny for the majority of the people and that should be the ultimate aim. Your jokes need to be understood by most people visiting your site, even if you are using innuendos, they should not be indecipherable. 

The image shows a cartoon with a confused expression, to symbolise the subjectivity of humour in web design.The confused expression is not the reaction that the web developer aims for.

Zeroing in on your target audience will help a great deal in this feat. To help you catch my drift, I will tell you something that you must already know. And that is the fact that the eastern and western cultures are vastly different. So, the kind of jokes these two people find funny are also different. You can joke about celibacy in the west and people would laugh, but if you joke about celibacy in the east, where the Buddhist Monks preach it, you will not get the same reaction.

So, identifying your target audience is crucial, as it would decide whether your humour would hold a punch or not. The subjectivity, the cultural intonation and the contextual meaning of a joke are to be mastered before using it into your designs. 

The image shows a stick figure with a sombre expression, depicting the importance of contextualisation in humour.Source: 9GAG

Here the second phrase, when used in different contexts has very different meanings, and this kind of contextual differences cannot happen in your web design.

The Categories of Humour 

Humour is something that is funny, something that makes us smile, laugh and roll on the floor laughing or ROFL, if you please. I like to believe that I have a great sense of humour, I laugh at things that are not even worth laughing at and a person with that kind of humour must know everything about it, right? But that isn’t the case with me, I did not know that there were seven categories of humour. Did you? For me funniness, satire and irony all fall into the same category, being one and only one. 

So, getting to know the seven varying diversifications of humour in web designs was quite enlightening for me. I hope it is the same way for you.

Comparing with comedy 

Humour by comparison is the most commonly used way of making boring elements on a website become interesting and refreshing. Going through a product’s specifications becomes a chore, if you do not find something funny in the never ending description. Making comparisons that are not only funny, but also serve the purpose of highlighting what the web designer wants is a tactic that could never go wrong.

Personifying with cartoons 

Do you remember the early 2000s? Did you use Microsoft Office then? If you did, you must remember Clippit or Clippy. It was a cartoon paper clip that served as an office assistant. I thought it was cute, funny and somewhat useful; however my belief was not very popular. The point I am trying to make here is that the addition of an animated personification can add character to your web content, giving the customer a break from the monotony of the content. A mascot is a great way to do just that.

The image shows an animated paperclip used in web design as humour.Source: Wikipedia 

Exaggerating with hilarity 

With exaggeration, we take a normal incident, magnify it in our minds, and relay the same with a lot of more severeness than it actually had. It is like saying that you were attacked by a mammoth sized dog, when in actuality a pug barked at you. If you know something is being exaggerated, then it becomes quite hilarious. 

Pun with fun 

Pun is something we are all familiar with, and enjoy a great deal. So, why not use it to make your website all the more interesting. The thing about the usage of pun is that it is quite tricky. It can very easily go into the territory of offensive, if it is not used properly. So, tread lightly when using it in your web design.

Silliness with funniness

Have you ever watched the American TV show Friends? If you have, what do you think of Phoebe? Do you find her funny? I personally do, she is the kind of funny that is silly, yet hilarious. You would never be offended by her character. So, taking inspiration from Phoebe’s hilarity and silliness and implementing it into your website could be a genius stroke. 

Surprise with laughs

Getting pranked is the best kind of surprise, at least to me it is. Being ambushed by a horrifying ghost in a funny video is bound to make you laugh until you cry with your heart racing at 100 km an hour. You must have experienced it sometime. Now, you tell me would an unexpected element of humour not be appreciated in a webpage that could otherwise be boring?

Jesting over the Easter Egg

As finding the easter egg amidst bunnies is no easy task, the same way the humour denoting with the same name is also not easy to find. This one is hidden and that is why it is a gem, when you finally get it. Web developers have been increasingly making use of easter eggs as an element of humour in their web designs and the users have been appreciating the hunt. Have you ever searched the meaning of the word askew on Google? Before you get on to the meaning, you would find something that would give you a clue as to the literal meaning of the word. Your beloved Google would become skewed itself. Is this not clever?

The image shows Google's skewed search page.The skewed screen on your computer when searching the term askew.

An amalgamation of all of these with subtly can make your website’s experience a memorable one for every user to come.

The Implementation of Humour in Web Design 

The thing to remember about humour is that if you have to force it, it is bound to lose its intensity over the audience and your joke would fall flat. Under no circumstances, do we want that. Humour has to seem spontaneous and natural, only then can we enjoy its full magnitude. 

To help you do the same, I will tell you some of the insider secrets of web developers and the way they make humour work for them.

Introducing yourself with a flair

Every website is going to have an About Us page, this is one area in a website that the content creator can create any way he wants to. So, if you want the customer to remember everything about you, you have to make yourself interesting enough to be remembered and humour helps in that. You can talk about history with light heartedness, you can talk about your struggles with humour rather than seriousness, and you can present your team in a fun and refreshing way. See the following example from Lessfilms website:

The image shows funny pictures of a company's team on their webpage.This one hit the mark with the introduction of its employees. The red guitar stole the show. | Source: Less Films

Making boring, yet crucial information interesting 

Webpages are supposed to have a lot of information and a lot of information can become quite boring to peruse through. Since the information has to be given to the user, what can be the solution here? The answer is simple, humour. Adding humour, in all of its categories can make your website content speak through and serve its intended purpose.

A web design with a green backdrop is shown with an ongoing chat on the side.A customised chatbot message. | Source: Lazy Gardener 

Covering up your mistakes

There are often times when your users face problems while surfing through the website. More times than not these problems are frustrating and annoying to the point that they think about going back and looking for something else entirely. Can this annoyance be overcome with humour? Let us see if it works for two of the most annoying things.

The 404 error 

When you get to know a page you were looking for does not exist anymore, you will become frustrated. Here a joke is bound to alleviate some of that. Look at the picture below, did it not make you smile just a tad bit?

A crying cartoon is depicted in the image with the 404 error often seen on websites.

Slow loading 

Apart from the page not found error, when a web page takes ages to load, that also becomes quite a nuisance for the user. There might be a genuine reason for the slow loading, but the problem would still be there, so what does the web developer do? You would use humour in a very subtle way to make the user wait a little longer and see what he had intended to.

A snail is shown in the picture to represent the slow loading process.

Narrating a story 

Sometimes storytelling becomes a necessary part of the web design. It is important to make your point come across in a simple, yet comprehensive manner at the same time making it relatable to the audience. Now, when you add a dose of funniness in your story, it would accentuate your point even more.

Creating a mascot 

A mascot is any object, human or otherwise that is bound to bring you luck. And web developers need all the luck they can get, like most of us. So, creating a website with a funny mascot that keeps popping up in regular intervals to let the users know whatever they want is a great way to make your website’s experience a little more eccentric than dull.

An animated boy is shown eating a burger as an innovative and funny web design..The cute kid with that appetising burger is enough to start a craving.

Baiting with humour 

You must be familiar with the term bait, it basically means to lure people in by enticing them with what you have. Have you ever read something like, “If your dog does this, here is what it means.” You might not even have a dog, but you will be inclined to know what the dog actually does. This is what bait means and it can increase the traffic on many websites.

An instruction is written in white on a blue background, often seen in webpages..If it were me hovering over the click button, I would certainly press it and find out what is inside.

The Avoidance of Humour 

Just knowing where and when to use humour is not sufficient, you should also know when to avoid it. Humour can only work its charm when it is used appropriately, incongruous use of humour can lead to devastating effects. You can’t be cracking jokes at a funeral, right? Right!

Here are three ways to avoid humour taking a toll on your website’s traffic.

Unnecessary implementation

You have to assess the right place and time of using comical aspects in your web design. Using comedy in a serious situation can have serious repercussions, one of which is a brutally harsh feedback from a customer and we do not want that. 

A lady can be seen covering a mouth in an oops reaction.


Seeing something like this on a retail website when your transaction failed and money got deducted from your account is bound to make the customer livid. So, to all web designers, do not go this route.

Confirmshaming 

This one is as insulting as it is inappropriate, if you want your website to be user friendly, I would advise to stay away from confirmshaming. This is a form of humour that uses guilt to make the customer do its bidding and that is just wrong. Telling someone that they are fat and should join your 15-day detox program is not the right approach from any perspective. 

There is a white background with information and instructions for a task to be down by the user.This image is a prime example of insulting and goading a customer in clicking, since nobody would want to be unhealthy.

Making it a distraction 

Using humour in a way that it distracts the customer from what you and your website is all about is probably not the aim. So, when you use comedic elements in your design, try to ensure that it is clearly understood by all the audiences or at least your target audience and it aligns with your website’s purpose. You do not want to leave any room for misinterpretation. This is because if a product is misinterpreted and the consumer does not get what he thought he would, he is definitely going to regard you as a liar.

The Backlash of Humour 

After telling you the ways to avoid humour getting in the way of your success, I want to tell you a story about the negative repercussions of the wrong kind of humour.

Pepsi is a world renowned beverage company, second most successful in the world in its arena. Pepsi is also famous for creating inspiring and unique ad campaigns. They are usually a hit, but their 2019 campaign missed its mark by a long shot. The only reason was the fact that they had taken a serious situation and made light of it. 

[embedded content]


As you can see in the video, a bottle of Pepsi was all it took to restore peace in the world. Do you also see the bizarreness in this idea? On top of this, the stark resemblance to the Black Lives Matter campaign did all the more damage to the company, the tweets are proof that. Pepsi had to retract the ad and issue a public apology. 

Therefore, it is advisable to avoid making humorous content on serious topics than making it and apologise later. Although it was a video commercial, the implication will be the same for website design as well. Nobody will tolerate humour on a subject they are sensitive about. The fine between humour and offensiveness has to be made very clear before implementing humour in your designs. Otherwise the backlash is going to be too brutal to bear. Take a look at how diverse design teams can help make better design decisions.

The Bottom Line 

Using humour to make your website’s experience more enjoyable has indeed become a trend; however, content creators and web developers have to understand that humour can just as easily turn deleterious as easily it can turn meritorious. 

Humour in web design is like a flaming ball of fire, the appropriate usage can make it as powerful as Goku’s dragon balls, and inappropriately used humour can turn your design into ashes; metaphorically speaking of course. You have to have a balance, do not go overboard and do not use it so little so that it becomes non-existent. When you attain that balance, your web design would become one to watch out for, trust me.

Sep 21 2020
Sep 21

Currently, in Drupal’s admin toolbar, the Webform module is listed under ‘Structure’.

Webform module is listed under ‘Structure’

If you have installed the contributed Admin Toolbar module, which adds drop-down menus to Drupal’s admin toolbar, it’s relatively easy to access Webforms from any page on your website.

Someone recently asked me why ‘Webforms’ is listed under ‘Structure’ and not ‘Content.’

There are two immediate explanations as to why I chose to list ‘Webforms’ under ‘Structure.’

First, it’s much easier to add links to Drupal’s ‘Structure’ section because it provides a dedicated overview page. Drupal’s ‘Content’ section, on the other hand, displays a tabbed user interface to manage content, comments, files, and media. This tabbed interface does not easily support multiple levels of administrative pages.

Secondly, webforms are configuration entities that create webform submissions, which are content entities. This pattern aligns with how ‘Taxonomy’ and ‘Content types’ work, and they are listed in Drupal’s ‘Structure’ section. Generally, the ‘Structure’ section includes things that a site builder configures yet does not frequently update. The ‘Content’ section is where content editors continually create and update content. For a more in-depth explanation about Drupal’s admin tool, you can learn more about working with the toolbar.

For small websites with just a few webforms, like a contact or registration form, it makes sense to list ‘Webforms’ under ‘Structure’ because a site builder would configure these types of webforms once and not frequently update them. As organizations have started leveraging the Webform module to build applications and event registration systems, having ‘Webforms’ nested under ‘Structure’ makes less sense. For example, content editors that are only allowed to manage content and webforms would have the ‘Structure’ section visible with only the ‘Webforms’ sub-menu item.

the ‘Structure’ section visible with only the ‘Webforms’ sub-menu item

The above screenshot is awkward and confusing. Yes, one immediate solution is to move the ‘Webforms’ into the ‘Content.’ But the fact that the tabbed user interface in the ‘Content’ section is not able to support the Webform module’s multi-level tabbed interface remains. Let’s also not forget the question, ‘Are Webforms content, configuration, or both?’.

The problem is that some organizations are building more than just a few webforms, and there are instances where webforms are as crucial as content. The solution is to make ‘Webforms’ a top-level menu item with a dedicated icon under the ‘Manage’ section within Drupal’s admin toolbar. To further improve the user experience, I have also added sub-level menu items to ‘Webforms’ section, making it even easier to manage any aspect of the Webform module via the Admin Toolbar module’s drop-down menus. Finally, when ‘Webforms’ is moved out of the ‘Structure’ section, all administrative paths will begin with /admin/webform instead of /admin/structure/webform.

Moving the 'Webforms' menu item out of the 'Structure' section

This is a significant UI/UX change that may be appropriate for an organization’s Drupal site. Like many advanced features in the Webform module, I decided to make this a configurable setting via /admin/structure/webform/config/advanced. By default, the Webform module will still place the ‘Webforms’ menu item under ‘Structure’. For websites that are doing a lot with webforms, they can now easily move the ‘Webforms’ menu item next to ‘Content.’

For advanced Drupal site builders and developers, you can also move the ‘Webforms’ anywhere you want, including under ‘Content’ using Drupal’s menu system. My solution makes it easier for people to check a box and promote ‘Webforms’ in Drupal’s admin toolbar.

I like this new feature because it acknowledges that organizations can use the Webform module to build simple content forms or rich applications. In some cases, the Webform module is a key part of an organization’s Drupal installation, with lots of users collaborating to build webforms and manage submissions. This feature allows organizations to decide where the 'Webforms' section should live within their organization Drupal administrative interface.

In short, this feature represents the power and flexibility of the Webform module - small or large Drupal sites can create simple or complex webforms, and they can decide precisely how they want to integrate the Webform module into their websites.

Lately, there has been a lot of cool things. happening with the Webform module and you can learn more by following my blog at jrockowitz.com and watch videos on my YouTube channel.

Almost done…

We just sent you an email. Please click the link in the email to confirm your subscription!

OK

Sep 21 2020
Sep 21

In his Drupal4Gov webinar Using tools and Git workflow best practices to simplify your local development, Greg Lund-Chaix, Senior Infrastructure Engineer at Tag1, talks about some of the ways that teams struggle when they become successful and need to learn to scale. He recommends using some basic tools to make your workflow easier. The right tools in your environment can prevent big problems down the line with merge conflicts, code committed to the wrong branch, or other mistakes.

Git is one of the most common version control systems in use today. With a few tools, and a few best practices, you and your team can make your local environments easier and safer to use.

[embedded content]

Rebasing

Learn to rebase. When you’re working on a feature it might take you a few hours, to several days or weeks. The longer you take working on a branch, the more chances your branch is out of sync with the rest of the code base. The cleanest way to prevent problems is to rebase. Rebasing checks where your branch diverged from main, pulls in all the changes, and replays your changes on top of them. Rebasing prevents cluttering up your commit history, too.

Here’s an example of how Greg works:

[laptop] ~ $ git checkout feature123-amazing-stuff
[laptop] ~ $ git pull --rebase origin main
[laptop] ~ $ git add my_amazing_module.module
[laptop] ~ $ git commit
[laptop] ~ $ git pull --rebase origin main
[laptop] ~ $ git push -u origin feature_branch

Greg starts his day by checking out his feature branch. Greg always works in feature branches, as one of his core four rules. He can’t be sure if anyone has committed code since he last checked this branch, so he rebases his branch against the main branch on his codebase’s origin. Everyone else’s changes are pulled in, and Greg’s changes are added back on top of them. Now, if someone has made changes to the same files Greg has, he’s able to see the conflicts before they go into the main branch. A pull --rebase does not add a merge commit, and keeps your commit history cleaner.

Now, Greg knows his changes are clean. During the day, he adds and commits more changes. Just before the end of the day, he rebases again, ensuring his code is as clean and safe as possible before he finally pushes it at the end of the session.

Git prompts for sanity

Anyone who has ever worked on a command line has felt the pain of doing something in the wrong directory, deleting the wrong file, or moving something to the wrong place. Your command line prompt can be a helpful indicator for where you are, what you’re doing, and the status of your local repository.

Git includes a script for showing your repository status in your command prompt. Download the git-prompt.sh file or look for it in your git source, and customize it to your needs. This prompt file does several helpful things:

  • Tells you what branch you’re on
  • Adds a red percent (%) sign when there are untracked files in the repository
  • Adds a red asterisk (*) when there's a changed file in the repository
  • Adds a green plus sign (+) when a file has been added using git add

These indicators flag that there is some change that has not been committed. This may be expected, but it may also be a sign that something has gone wrong - for example, if your indicators show up when you’re on the main branch.

Greg made a secondary script available for prompts, which indicates where you’re making the changes: locally, or on a server. If this might help you, download the servertype-prompt.sh script for yourself. This script depends on git-prompt.sh. Whether or not that prompt displays is an indicator for where you’re working.

Sniff your code

Unlike the more traditional network sniffer, which analyzes your packet traffic on the wire, a code sniffer reviews your code and checks it against a predefined standard. PHP_CodeSniffer “tokenizes PHP files and detects violations of a defined set of coding standards.”

Drupal developers are often familiar with the Coder module, written by Tag1 Senior Architect Doug Green, checks your Drupal code against coding standards and other best practices.

To include these in your codebase, add the following lines to your composer.json file.

composer require --dev drupal/coder
composer require --dev dealerdirect/phpcodesniffer-composer-installer

For a full tutorial on installing Coder and PHP Codesniffer, see Installing Coder Sniffer on drupal.org.

Coder module is designed to work with PHP CodeSniffer, making it easy to integrate with your continuous integration platform. Setting your team up with this kind of integration enables automated coding standard reviews on every pull request.

Other useful tools

Pre-commit hooks can run checks for you before you make a commit locally. You can set up a hook to run codesniffer before you commit - if your codesniffer fails, your commit fails, too! This can prevent some of the more obvious mistakes from even making into your local code. See an example Drupal pre-commit hook by Marco Marctino (mecmartini), or full documentation at pre-commit.

Tig is a visual command line tool that lets you see commit and log information for your repository. It has an interface that enables you to walk the list of commits, and see the details more easily.

Users who are less comfortable or familiar with the command line may find a graphical interface to be friendlier. Many GUIs are available for Git. If you’re struggling with the command line, check out a GUI and make your life easier.

About Drupal 4 Gov

Drupal 4 gov is an open source community for developers and IT professionals with an interest in making the government more open to open source.

It encompasses many open source projects but we have our beginnings in the Drupal project.

Drupal4gov offers:

Photo by Grant Ritchie on Unsplash

Sep 21 2020
Sep 21

This week brought a new, stable release for Smart Date 3.0.0. You're welcome to dig through the various Smart Date release notes to read up on all the changes from the previous, 8.x-2.x branch but I thought I would use this space to talk about some of the key themes.

Support for Drupal core Date Range fields

One piece of feedback I've heard a number of times is that people wanted the Admin Experience (AX) improvements of Smart Date and its more natural formatting for date and time ranges, but were hesitant to depend on a contrib module for custom storage of their date values. Knowing that this was a barrier to adoption, I started to think about how Smart Date was started as effectively a fork of the core Date Range field. Given this common ancestry, it wouldn't be too hard to make at least some of Smart Date's functionality available to Date Range fields.

This is now possible in Smart Date 3. You can use the Smart Date widget, meant to draw best practices from popular calendar software from Google, Apple, and others, and leverage Smart Date Formats for formatting output. In fact, the latter is also available for core date and time fields, to make it easier to keep the output consistent across your site.

This means you can hedge your bets by continuing to use core fields for storage, but Smart Date to enhance your forms and output. It also makes Smart Date easier to drop into an existing site.

Unfortunately, there are some limitations to this mixed approach. For one, the setup for allowed duration values is moved to the widget configuration for core date range fields, which means they can't be enforced for content created programmatically, as an example. Also, you lose the performance benefits of storing your time values as timestamps. There are a variety of other minor concessions, but perhaps the most significant functionality you forego in this approach are the biggest features introduced in the 8.x-2.x branch: the ability to manually set time zones per event and Smart Date's practical and easy-to-use integration for recurring dates.

An easier Admin Experience out of the box

The primary goal for Smart Date when it was first created was to make life better for content authors. The new release continues to build on that effort, though in more subtle ways.

When using a Smart Date field that allows unlimited values (recommended in case you want to enable recurring events at any point), Smart Date now allows you to suppress the additional, empty field set Drupal creates in addition to the one for the default values. An author can still add more field sets as needed, but it's another change meant to make Drupal work a little more like the calendar software authors are using every day.

For sites where the timezone widget is used, the default set of timezones can be daunting to choose from. The Chosen module can help, but in a recent talk about Smart Date, an attendee asked if it was possible to choose which time zones would be shown in the dropdown. It was a great idea and not difficult to implement. If you need to have time zones associated with your events but don't need support for the long, global set of timezones, using this new configuration for Smart Date's timezone widget can make life significantly easier.

When formatting dates and times with time zones, Smart Date formats now do a better job of determining when there’s value in also showing the time in the site’s default time zone. You now also have the option to force your format to never append the site time.

Support for Drupal’s next-generation themes

There’s significant work underway to get Drupal’s gorgeous new Olivero theme into Drupal 9.1 as experimental and to move Claro towards being stable -- and eventually Drupal’s default admin theme. Meanwhile, during DrupalCon Global we kept hearing the buzz about Gin, the customizable, contrib cousin to Claro. We’ve grown to love Gin and have made it our default for new sites, especially as we transition to building sites in Drupal 9.

It only makes sense, then, for Smart Date to look great and function as expected in Olivero, Claro, and Gin. SmartDate 3.0 has made a variety of changes to make sure that whichever one of these your site uses, Smart Date will be a seamless addition.

Feedback is always welcome

There have been a number of other, smaller changes: better support for formatting German-language dates, improved Fullcalendar View integration, additional views options for recurring dates, and many more. 

As always, the best way to learn about the power and potential of Smart Date is to test it out yourself. I encourage you to try out the Smart Date module and I’d love to hear your feedback. After all, much of what makes Smart Date as feature-rich as it is today came from the Drupal community, either directly as patches, or as feature requests. 

Please feel free to open issues for ways you think the module could be even better, or reach to @mandclu on Twitter, or in the #datetime channel in Drupal’s slack.

Sep 20 2020
Sep 20

I am no longer a Drupal Association board member nor was I involved in or privy to the discussions around the changes that the Drupal Association Board made to voting eligibility made this spring.  I’ve been reflecting on what I’ve heard from all sides and find that I may have some context that might prove helpful in understanding how we got here and some ideas on moving forward. Ultimately, the vestigial linguistic mapping that we used to ease the transition from Drupal VZW to DrupalCon, Inc. may instead be creating tension and misaligned expectations. The more the DA can clarify and create aligned expectations between itself and its contributors the stronger the Drupal’s future can be.

Drupal VZW - The Original Drupal Association

The Drupal Association has actually been two separate legal entities during its short lifespan. The current US-based 501(c)3 organization, DrupalCon, Inc. (DCI) that does business as (DBA) the Drupal Association is the successor organization to Drupal VZW, a Belgian organization originally founded in 2006. 

Drupal VZW was structured as an “association with non-profit purpose” (Vereniging zonder winstoogmerk in Dutch, abbreviated VZW or in French, Association sans but lucratif, or ABSL). A VZW has a defined structure which may be unfamiliar to non-Europeans: an association has a General Assembly (GA) of permanent “members” who nominate new people to become members of the GA at their discretion and then select the board of directors from among that GA membership; the membership rights and obligations are also quite defined and standardized. The original Drupal Association began as a GA of members selected by Dries with other members added annually by nomination of existing members based on their contributions to Drupal. 

While establishing the DA as a VZW initially was the most expedient option, by 2009 when I joined the GA and the board, the structure was under strain. At its peak, Drupal VZW was an international organization with a General Assembly of about four dozen and a board of ~8 people, most of whom did the work of unpaid staff. 

There were many reasons why we decided to deprecate the Belgian organization in 2010 and transfer the primary governance and assets to a US-based 501(c)3. The top three from my perspective were fiscal and tax considerations from the increasingly successful US-based educational conferences (North American DrupalCon), governance challenges with the GA/board structure (quorum was incredibly difficult to obtain to even consider structural changes) and difficulties operating the organization internationally especially during a period of Belgian political instability. Things may have been different had it been structured as an internationale vereniging zonder winstoogmerk (IVZW) from the start, but that is neither here nor there at this point.

The Transition to DrupalCon, Inc.

This context of VZW is important to understand how the bylaws for DrupalCon Inc., the US-based 501(c)3 were drafted. Largely, they are standard non-profit bylaws, but there were some key questions that we considered that informed the ways in which they were different (at least initially):

  1. What might the role be for former General Assembly permanent members?

    In VZW, the GA served as the accountability check for the board, which in turn functioned as staff. For example, the VZW board brought the budget to the General Assembly for review and approval once per year in the annual meeting. However, in the US, boards typically have a mix of those involved with the organization as well as outside perspectives that serve as the directors who are legally accountable for the actions of organizations.  

    As a transition, we created opportunities for interested former GA members to retain involvement and oversight. Initially, the bylaws created an Advisory Board committee for former GA members to serve on, but within the first few years, it was defunct through neglect. The board itself was advisory only and didn’t need another advisory board to advise it. In addition, GA members were invited to serve on the permanent committees of the board such as the Nominating Committee. Over time, that too has fallen off. Now the board committees are entirely composed of board members, which is typical of US-based non-profits.

    Many former GA members have moved on from the project; some remain involved in leadership roles: George DeMet is the chair of the Community Working Group. Neill Drumm is a Senior Technologist at the Drupal Association, and  Angie Byron is a Drupal Product Manager. Others remain contributors at various levels. None, aside from Dries, is currently serving on the Board.

  2. As we professionalized the board (e.g., became a strategic board that supported staff rather than a board of hands-on doers or managers or staff), how might we ensure a continued voice for hands-on contributors in the community?

    The strength of the Drupal community has always been in and derived from its contributor base. There was a lot of anxiety and care in our bylaw drafting process given to how we could preserve that connection and culture on the board even as we knew we would need to adapt the composition of the board to suit the needs of a strategic board. This is where the concept of the At-Large Director came in.

    The idea was that having two At-Large Directors would guarantee that at a minimum there would always be at least two representatives of the contributor community on the board to give voice, connection and insight to Drupal’s core strength. That, combined with Dries’s permanent seat as founder, created the three-person backbone of the organization that offsets the three rotating classes of self-selected Director slates, more typical of professional not-for-profit boards.

    The shorter term length was to keep this voice fresh and increase the accountability to the contributor community through frequent opportunity for the community to weigh in. After a few years it became clear that the one-year term was too short. It truly does take a year to get your bearings on any board. To enable an At-Large Director to make a meaningful contribution to the board, a two-year term was necessary and the director openings were staggered to keep elections annual.

  3. How to map the European structures and concepts to a US-based 501(c)3?

    Despite all the hours spent redesigning the organization, its structure, and its bylaws, there was never any consideration given to changing the name “The Drupal Association.” The US-based entity DrupalCon, Inc. (DCI) that had been created for DrupalCon DC as a Co-op was converted into the 501(c)3 and all of the assets from Drupal VZW were transferred to it. “The Drupal Association” was overlaid as a DBA (doing business as) due to the equity in the name and to minimize confusion. 

    For the US organization, the General Assembly (GA)’s oversight responsibilities (budget oversight, statutes, legal status, adding/removing members, etc.) moved to the Board of Directors with operational responsibilities transitioned to staff. We recognized that the elimination of the GA and the shift to a strategic board with a professional staff represented a necessary maturation of the organization and also had the potential to impact our culture unless deliberately preserved. Looking for opportunities for broader and more inclusive participation and to ensure that the voices of contributors remained strong, we created the At-Large Directors “elected by the community and ratified by the rest of the Board.”

The Challenge and Impact of Not Defining “Community”

The bylaws are silent on the definition of “community” even though it bestows a pretty important right to it. That lack of clarity has been the root cause of frustrations for both the community and the DA staff over the years and, it seems to me, underlies these current concerns. Without a clear alignment, it has been difficult to establish mutual expectations, to know what to expect and what might be expected in return.

This ambiguity becomes especially confusing in an organization that refers to itself an “Association.” The name itself implies there would be (or should be) members. In an association, the most common right bestowed upon a member of the association is voting eligibility.

Because “community” is not defined it falls to the Board to define. For expediency prior to those first At-Large elections, the DA used logging into Drupal.org in the year prior to the opening of the election to define the “community” as it was easy to quantify and provided some safeguards against fraud. While I recall discussing it as a board, the discussion was about technical feasibility rather than strategic value or engagement. I recall it as a case of measuring what was easy/feasible. We knew it was ridiculously overbroad, but it had worked well enough and better to be more inclusive than less. I don’t recall discussing or validating a definition of “community” with respect to election eligibility again during my tenure, which ended in December 2017.

The problem with this definition is that it sets the bar too low. It is not unreasonable that an organization ask that those who vote in its election be restricted to those who engage with and contribute to the organization. Failure to revisit this definition earlier has ossified an expedient definition into an expectant right. To change a privilege that had been in place that long (albeit one that was very underused) needed more communication with those impacted than was provided.

I fully support the Board in revisiting this neglected portion of its governance process. However, restricting voting eligibility to those with purchased memberships (while again expedient/easy) seems a flawed approach as it both perpetuates the “association” confusion and is overly restrictive. The DA bylaws explicitly state: “DrupalCon, Inc. (the "Corporation") is a Washington, D.C., nonprofit, public benefit corporation, and it has no members.” The fact that the DA offers individual “memberships” and is now extending voting rights only to those with membership is confusing. To be clear, these individual recurring donations are an essential form of support for the organization (as with any non-profit), but they do not constitute memberships of the non-profit corporation in a traditional association sense. Further, financial donations are not the only support upon which the DA relies. To bestow voting rights in exchange for primarily financial considerations (absent individual appeals) feels restrictive and like an alarming usurpation especially for an open source community.

What now?

Over the last ten years, the DA has gradually evolved and matured. The unique characteristics designed to ease the transition from VZW to DCI have increasingly been deprecated or brought into alignment with standard practice for a US-based 501(c)3. The changes have been gradual; to those actively involved in the DA, they might feel like a steady natural progression or for those who are newer to the organization, might feel completely non-controversial. It’s important to keep in mind that the 2019-2020 Drupal Association Board marked the first time when no former member of the Drupal VZW General Assembly (aside from Dries) served on the DA (DCI) Board. 

It seems to me that it is time to further evolve and here are my unsolicited recommendations:

  1. Clarify what the DA is: drop the legacy language inherited from our VZW days that is confusing and distracting. 
    • The organization is not an “Association”. It is a Foundation. Consider renaming it.
    • There are no “members”. There never have been. There are and always have been “contributors”. Discontinue calling financial supporters “members”. Orient services and benefits provided for contributors, both individual and organizational, comprehensively recognizing all forms of contribution.
    • Update the wording around the At-Large Director: “elected by the Contributors to the DA and ratified by the Board of Directors.”
  2. Clarify what the DA does: it is the clearinghouse for resources that support Drupal and its contributors. While the DA (and Drupal project itself) may provide benefit to those who are not contributors, the sustainability of the organization depends on optimizing benefit for those who are contributors.

    Adopting this lens provides the opportunity to clarify the ambiguous “community” in the bylaws with a much more objective definition of “contributors” particularly following implementation of the forthcoming recommendations from the Contribution Committee that recognizes all types of contribution (individual and organizational). 

  3. Consider expanding the number of At-Large Directors. As I left the Board, I advocated that the number of At-Large board positions be increased to 4, two elected each year. The switch to two-year terms for each At-Large Director was important. However, an unintended consequence of that change has been that those elected have been less globally representative than the representatives with two people elected at once. In fact, to date, all have been North American, with the exception of the remarkable Shyamala Rajaram from India in 2016 (the year of DrupalCon Asia, which saw increased eligibility and turnout).

    At-Large Directors bring tremendous value and perspective to the board. Ranked voting from a single pool for two positions gives candidates from smaller emergent contributor communities greater statistical odds of success. I encourage the board to consider expanding the number of At-Large Directors for that reason.

My hope is that by addressing some of these legacy semantic issues, the Drupal Association will be able to provide greater clarity, move forward into its next decade and build the kind of strong relationships that allow us all to focus on our shared goals.
 

Sep 19 2020
Sep 19

In the evolving world of web design and development, component-based design systems represent a revolutionary leap -- a previously missing link that replaces an environment of siloed functions and time-consuming complexities with high velocity capabilities that fuel flexibility, consistency, and collaboration.

Component-based design systems produce inherent efficiencies for designers and developers, and solve the challenges associated with duplication and inconsistency in applying themes, while driving the development of better quality, reusable components.  Clients gain the benefit of better brand management resulting from a simplified content editor experience that allows for bending as necessary, without breaking brand guidelines or page structures. 

As a thought leader on how humans interact with technology, Promet Source has enthusiastically pursued component-based design systems from the standpoint of both: 

  • innovative design patterns that optimize UX and spark engagement, and 
  • streamlined and simplified content editor experiences that allow for a wide range of page possibilities.

Powerful Partnership

As dedicated open source advocates, Promet has adopted Emulsify® as a tool to help us better organize, share, and reuse our custom design systems. Promet serves as both a user and contributor to its support and success. 

Emulsify is an open-source tool for creating design systems as a series of components that can be duplicated and easily manipulated within a set of clear guidelines for designers and developers. Promet is currently leveraging Emulsify on complex web development projects for government, healthcare, and higher education clients.
 

Advantages of Emulsify for Web Design Systems:

  • Integration with a starter library of Drupal-ready components with Storybook,
  • Portability across other CMS platforms and applications,
  • Open source, and
  • Compatibility with both WordPress and Drupal.

As Aaron Couch, director of technology solutions for Promet Source, recently pointed out: 


Emulsify has provided Promet with an optimal starting point to incorporate a component-driven approach into both Drupal and WordPress development. It has changed the way we deliver front-end experiences making our work higher quality, more efficient to deliver, and more accessible, while creating a better user experience for our clients.

Join Promet’s Aaron Couch along with Emulsify contributors Brian Lewis and Evan Willhite on Fri., Sept. 25, 2020, at 3:30 p.m. EDT, during this year’s virtual Drupal GovCon, for “Component-Driven Theming with Storybook.” 

During this session, presenters from Promet and Emulsify will explain how a component-based approach offers greater consistency, flexibility, re-usability, and velocity for front-end development. 

AKA "Atomic Design" 

While metaphors for helping to explain component-based design systems abound, “Atomic Design” (and a book with the same title) authored by Brad Frost) is the one that has gained the most traction and has entered into the lexicon of component-based web design. 

Atomic design looks at a website’s user interface as the collection of five factors that roll up into each other:

  • Atoms,
  • Molecules,
  • Organisms,
  • Templates, and 
  • Pages.
     

Exponential Impact

Component-based design makes front-end web development up to four times faster. This translates into happier clients and the freeing up of resources to focus on fine tuning and providing greater functionality. 

For the content creator and editor, component-based web design provides the ability to edit and revise pages to fit evolving needs and new priorities. 

The new world of “drag and drop” content management is soon to set a new standard in which previous limitations will quickly come to be viewed as  unacceptable. Low code/no code web design is the future.

The four key advantages of Promet’s adoption of the open based tool for creating web design systems powered by Emulsify®:

  • Design systems that can flex, bend, and scale within and among complex web designs,
  • Powerful new possibilities resulting from enhanced consistency, flexibility, re-usability and velocity for front-end development,
  • Elimination of painstaking QA processes in favor of proven patterns and high-quality built-ins that get designers, developers on the same page, and
  • Assurance that non-technical content editors can make multiple changes to a web page without breaking layouts or straying from brand guidelines. 

Need help creating a Drupal design system for your complex website? Contact us today.

Sep 18 2020
Sep 18

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 UpdatesGit Merge Request

GitLab Merge Request beta

Back in July we kicked off the GitLab merge request beta, and over the course of August more and more project maintainers opted-in. The merge request workflow is available on more than 150 projects, and in several core issues. This is a *dramatic* improvement in the contribution workflow, especially for newer contributors or contributors making 'drive-by' contribution - and makes the lives of our existing long-term contributors much easier.

We're getting ever closer to enabling this workflow on every project across Drupal.org - but we still need your help! You can try out the contribution workflow on any of the projects that have opted in, opt-in your own projects, or check out the workflow in the core issues trying the beta.

Check out these issues to opt-in your project or core issue.  We anticipate general availability across all projects within just a few more weeks as we gather the final feedback from our beta contributors.

Auto Updates contribution week(s)!

During the week of August 3rd, 2020, representatives from three of the most successful open source content management systems came together to collaborate on a mechanism for securing software updates. Each of these open source projects is based on PHP, with similar use-cases, users, and update delivery architecture. By teaming up across these three projects, and any others who choose to join, we hope to standardize on a secure update delivery and validation mechanism. With this mechanism in place, each project can then build on top of it for additional features for our respective communities, such as providing secure automatic updates in Drupal.

Drupal    Typo 3   Joomla

Drupal, Typo3, and Joomla spent the week evaluating The Update Framework (aka TUF), an initiative of the Cloud Native Computing Foundation to provide a standardized framework or managing secure updates, minimize the impact of any potential compromises, and to be flexible enough to be used across different software systems.

Over the course of the week we made significant progress by replicating the reference implementation and its test fixtures in php, hosting the work in a shared repository: https://github.com/php-tuf/php-tuf. As we left the contribution we agreed to regroup in September for an additional collaboration. (That second contribution week has now happened, so look for an update in our September blog post!)

How can you get involved?

If you're interested in contributing to the PHP-TUF effort, you can take a look at the GitHub repository for the project: https://github.com/php-tuf/php-tuf

If you're connected to the Drupal community and are interested in PHP-TUF, or the larger initiative to work towards automatic updates, you can join us in Drupal Slack in the #autoupdates channel.

Per-project issue summary templates

Contributing to Drupal can be intimidating for a newcomer. One of the first barriers is just knowing 'how do I file a bug or feature request?'

Drupal core has a project issue summary template that is predefined to ask the right questions to help build a useful, actionable issue report.

And now, thanks to community contributors, each project hosted on Drupal.org can now define its own issue summary template - extending this great contributor onboarding feature to all projects in the Drupal ecosystem.

Launched the Lazy Load initiative

An increasing goal of the Drupal Association is to foster and onboard more major contributors to the Drupal project. One of the organizations we've been talking to recently is Google. Google has a vested interest in the performance of the open web, and over the course of the past several years has begun hosting a CMS leadership summit, to bring representatives from many CMS projects together.

As part of this growing collaboration, the Drupal Association has helped to coordinate the Lazy-Load initiative, which seeks to load all images lazily in Drupal core by default. Google has generously sponsored this work, and we hope to see it included in Drupal 9.1.

DrupalCon Europe

Supporting DrupalCon Europe - now virtual!

DrupalCon Europe has gone virtual! Early in the year, many of us hoped that we might be able to come together in person in Barcelona this fall. Unfortunately, this was not to be. But the European community is not letting that stop them from having a great event - online!

The Drupal Association spent some time in August working with the DrupalCon Europe team to integrate their chosen virtual event platform with the events.drupal.org schedule!

Registration is open now: https://events.drupal.org/europe2020 

And you can browse the program here: https://events.drupal.org/europe2020/schedule/2020-12-08

———

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

Sep 18 2020
Sep 18

Accessibility isn’t just a concern for web developers. With content being dynamically created, there are a few points content editors can keep in mind to make sure their content is accessible to everyone. Following accessibility standards helps non-visual users, but can also help all users find and understand the information they’re looking for.

Creating Emphasis

One of the most common times accessibility issues pop up is when content editors are trying to emphasize sections of text. It is important to keep in mind that screen readers do not recognize details like different colors or bolded text, but will intonate exclamation points. If it is vital to the understanding of the content that a certain sentence be highlighted, consider using an exclamation point. If it is not vital but may help visual users to better understand the message, your best bet is making use of bold. 

From a usability standpoint, be wary of using color for emphasis. Colors can have unintended implications, such as causing the user to think the text is a warning, or even a link. Text also has to pass a certain color contrast ratio with its background to maintain accessibility, so unless a designer or developer with a knowledge of accessibility has picked out new colors for you, it’s best not to introduce more.

Another common mistake when emphasizing content is using all uppercase letters. A screen reader will read this out like an acronym, which could be particularly painful for a full sentence. Aside from screen readers, it is also shown to be less readable for all users when there are more than one or two words in a row in all-caps. Sometimes you’ll see all-caps used on buttons or labels, but the crucial difference is that these are (or should be) made into all-caps with code. A screen reader will usually ignore the css and see the text as it is originally written.

Is bold not enough variation for your content? Talk to your designer or developer about coming up with additional text styles for you to use. You may think to yourself, “I already have a dropdown with five different text styles I can use!” What you’re probably referring to is the heading selector.

Heading selector in a WYSIWYG field in Drupal.

Headings should never be used for emphasis or a stylistic choice. They are a tool to add structure to a page.

Heading Structure

Headings are pieces of HTML that are used to give structure to a page. They make it possible for non-visual users to navigate and understand a page without needing to see visual indicators. There is a specific way headings need to be arranged on a page. 

Headings are nested, just like you would see in an outline of a paper where subsections are indented and have a different bullet point or character. Heading 1 is the topmost level, functioning as the title of the page. There should only ever be one H1 on a page, and if you’re using Drupal or any other content management system, the H1 is probably already generated for you as the page title. If you’re working in a body field, for example, you’ll most likely start with H2 to title a section of content. Anything else at this same section level will also be an H2. If you need to label sections within this section, you can start to use H3’s. If you need to go any deeper than this, you can start to use H4’s, H5’s, and H6’s, but if you are going this deep into the structure, it may become difficult to follow for your average user. Here’s an example of heading structure:

(H1) The Most Amazing Chocolate Cake

          (H2) My Grandmother’s History

          (H2) Ingredients

                    (H3) Types of flour you can use

                    (H3)  Alternative ingredients

                              (H4) Vegan alternatives

                              (H4) Gluten free alternatives

          (H2) Instructions

                    (H3) The cake

                    (H3) The frosting

An important thing to watch out for is that heading levels don’t skip. You don’t want to go from an H2 right to an H4. That makes it more difficult for non-visual users to understand the structure of the page, and creates inconsistencies for all users. If you keep finding yourself tempted to do this for visual reasons, think about why it feels like the heading style available doesn’t fit, and work with your designer to figure out how best to fix it.

As mentioned before, don’t use headings simply to emphasize text. If you’re making a whole sentence into a heading, it’s probably not the right use. Headings are also not designed to be used for long sections of text. Bigger and bolder does not always mean easier to read. Sometimes a pull quote or a custom text style is an option that will accomplish what you’re looking for, without creating accessibility and usability issues, as well as design inconsistencies between different content editors.

Foreign Languages

Sometimes on your site you’ll need to add text in a different language. Visual users can identify when they won’t be able to read something, but screen readers need a hint that a sentence is in a different language. There’s a simple way to add this hint to your text: the language button. When you add content to a text field, usually you will have a toolbar at the top that allows you to make things bold, add a link, etc. One button that you may see if you’re using Drupal looks like this:

Language button on a WYSIWYG field in Drupal.

If you see this button, you can highlight your text and select from the dropdown. If you don’t see this button, or any buttons, ask your developer to make it available for that field.

Another thing to note with foreign languages is that users can use external tools to translate the content into a language they understand. For this reason, it is best to stay away from made up words that would only make sense in the language you’re writing, but not others (i.e. “hangry”).

Special Characters

One more content writing trend to avoid is replacing letters with characters, for example “$ave ₵ash” or “see u l8r.” This causes predictable issues for translation and screen readers, but it also can show up incorrectly for anyone. If you have an article titled “$ave ₵ash” it will show up in the url as something like this: yoursite.com/news/ave-ash, which could lead to some confusion when sharing links. The “u” in “see u l8r” would most likely be understood by a non-visual user, but would be impossible to translate.

Writing Accessible Links

Writing good link titles is important, and once you understand how non-visual users navigate a page, it’s easier to accomplish. These links could be inline links, such as a word in a sentence, or could stand alone, such as a button. Regardless, what you want is for link titles to be able to stand on their own. This is because one navigational tool that assistive technology provides users with is a list of links that appear on the page. Imagine a list of links that says “click here,” “learn more,” and “download.” These links don’t give the user any context or information about where the links will go. Instead, create links with text that gives users an understanding of what exactly that link will be doing. No user wants to waste time clicking on a link gives them an unexpected result.

W3.org gives these as examples of successful links (URI refers to the link destination):

A link contains text that gives a description of the information at that URI

A page contains the sentence "There was much bloodshed during the Medieval period of history." Where "Medieval period of history" is a link.

A link is preceded by a text description of the information at that URI

A page contains the sentence "Learn more about the Government of Ireland's Commission on Electronic Voting at Go Vote!" where "Go Vote!" is a link.

Meaningful link text also helps users tabbing through a page from link to link. Users can more easily navigate and determine where to go next without spending more time than wanted on an intermediary page.

Learn more about link accessibility at w3.org.

Writing Good Alternative (Alt) Text

Images that you add to your page need good alt text. When using a content management system, you’ll see a field show up when you add an image, asking for alt text. Alt text allows non-visual users to get the same basic information that the image is giving to a visual user. It is what shows if an image doesn’t load, whether because of a broken image link(?) or a user’s limited internet access. It also provides information to search engines.

Writing good alt text can feel a bit tricky at first. What you want is for your alt text to communicate the content and function of the image. Think of alt text as what you would want to appear in the place of the image if you couldn’t use it. You’ll want to be succinct in describing the image, and avoid any redundancy with the text around it. Screen readers will know that it’s an image, so don’t add text like “image of…” Think about what information is and isn’t helpful, and why you’re adding an image in the first place. Is it just to take up space next to text, or is there something important being conveyed through that image? An image of students on a quad conveys information about student life at the university, whereas a cartoon image of a backpack likely doesn’t add any information.

Example of an alt text field in Drupal8.

Sometimes the alt attribute of an image should be empty. The alt attribute is the piece of HTML that is holding the alt text you enter when you first add an image. You may instead have a label below your image that is visible to all and acts as alt text. You wouldn’t want a screen reader to read out what would ultimately be the same text twice, so you’ll want an empty alt attribute on the image. The only instance where you want no alt text at all is when an image is only decorative, such as a swirling line between text sections or a generic image added only to break up the text (like the previous backpack example). Alternative text may be a required field when you add an image, in which case adding empty alt text by typing a single space in the field might work for you. If this doesn’t work, you may want to talk to a developer about making alt text optional. Consider how many content editors your site has, and if they all have accessibility training. If it is possible that a lot of images that need alt text could end up without it, it may be best to keep it required and minimize using images that don’t add meaning to a page. If the image has alt text in a caption already and you need to add something into the alt text field to be able to save it, try to add context that isn’t already clear from the caption. In most cases you will want alt text anyway, but ask yourself if the alt text you’re adding will be a help or an unnecessary hindrance to a non-visual user.

Wikipedia shows the alt text below the image and the alt attribute stays empty.

When an image is linked, and is the only thing in the link, the alt text needs to describe the function of the link. This is because the link doesn’t have any other text in it, so any clue as to where the link is going to go is taken from the alt text. In this case, you can write alt text as if you were writing link text.

For some great examples of how to write alt text, take a look at the list provided by webaim.org.

Conclusion

Once you understand how different users are experiencing your content, writing with accessibility in mind starts to get easier. It’s not always the most exciting and creative part of writing content, but it can be a rewarding experience to continually remind yourself to think about users that often can be overlooked. Putting yourself in someone else’s shoes can help build empathy and make the web, and particularly your piece of it, a more positive space for all.

Sep 18 2020
Sep 18

BADCamp is understanding that there are many different ways that folks can contribute back to Drupal. Not a coder!? Not a problem! We have plenty of opportunities for people to earn contribution credits while working on their professional development. 

  • Already planning on attending sessions? Volunteer to be a Session monitor.
  • Love Drupal Trivia? Submit trivia questions unique to BADCamp.
  • Love to meet with new folks? Chatt with attendees at the BADCamp booth.

Fill out this volunteer survey to discover the many ways you can give back to the Bay Area Drupal Community.


We are 100% volunteer driven and invite the wider community to help make our camp the most rad camp it can possibly be.

BADCamp is dedicated to providing a safe, inclusive, welcoming, professional, and harassment-free conference experience for everyone regardless of gender, gender identity and expression, sexual orientation, disability, physical appearance, body size, race, age, religion and any other status protected by laws in which the conference or program is being held.


 

Sep 18 2020
Sep 18

Often, the most effective means of managing complexity is a laser-sharp focus on simplification -- breaking down a project into its smallest component parts and visualizing incremental  steps toward completion beginning with the smallest building blocks. 
 
That’s exactly what Brad Frost has achieved in coining the concept of Atomic Design, and authoring a book by the same name.  In clarifying the new capabilities of component-based web design systems, the vocabulary of Atomic Design has gained traction, and entered into the working lexicon of web designers and developers.  
 
As Frost explains:

Atomic design is not a linear process, but rather a mental model to help us think of our user interfaces as both a cohesive whole and a collection of parts at the same time. 

From Atoms to Pages

Atomic design considers a website’s user interface as the collection of five factors that roll up into each other:

  • Atoms,
  • Molecules,
  • Organisms,
  • Templates, and 
  • Pages.

1. Atoms

The basic building blocks such as HTML tags, form labels, and buttons, as well as color palettes and fonts -- essentially all of the factors that designers typically define as a reference point for developers when creating a website’s style guide. 
 

2. Molecules

Chemically speaking, molecules consist of atoms bonded together. Within Atomic Design a molecule make up distinct building blocks and refer to design specifications for functional, reusable combinations of atoms, such as a keyword search bar with a search button. 
 

3. Organisms

Combinations of molecular building blocks form organisms that form distinct sections of a user interface. This is where the design begins to take shape with the creation of reusable components such as a footer consisting of a logo, social media icons, a call to action link, and other branding elements.

4.  Templates

Groups of organisms arranged together form a template. The game-changing factor within component-based design is the inherent flexibility of the templated layout, allowing for a wide range of options such as switching out an image for a text block, and previewing responsive layouts for various devices. 

5. Pages

Pages refer to specific representations of templates that take shape beyond a theoretical example and come to life as a real-world view of what the user will see and experience on the site. It is at the page stage where texting and review concerning the totality of the design system tends to occur and adjustments are made.

To learn more about the powerful potential of component-based web design systems, join Promet’s Aaron Couch along with Emulsify’s Brian Lewis and Evan Willhitel on Fri., Sept. 25, 2020, at 3:30 p.m. EDT, during the virtual Drupal GovCon, for “Component-Driven Theming with Storybook.” 

Stay tuned for further announcements concerning Promet and Emulsify® and in the meantime, Contact Us for help or consultation concerning the creation of a complex Drupal website. 

Sep 18 2020
Sep 18

Often, the most effective means of managing complexity is a laser-sharp focus on simplification -- breaking down a project into its smallest component parts and visualizing incremental  steps toward completion beginning with the smallest building blocks. 
 
That’s exactly what Brad Frost has achieved in coining the concept of Atomic Design, and authoring a book by the same name.  In clarifying the new capabilities of component-based web design systems, the vocabulary of Atomic Design has gained traction, and entered into the working lexicon of web designers and developers.  
 
As Frost explains:

Atomic design is not a linear process, but rather a mental model to help us think of our user interfaces as both a cohesive whole and a collection of parts at the same time. 

From Atoms to Pages

Atomic design considers a website’s user interface as the collection of five factors that roll up into each other:

  • Atoms,
  • Molecules,
  • Organisms,
  • Templates, and 
  • Pages.

1. Atoms

The basic building blocks such as HTML tags, form labels, and buttons, as well as color palettes and fonts -- essentially all of the factors that designers typically define as a reference point for developers when creating a website’s style guide. 
 

2. Molecules

Chemically speaking, molecules consist of atoms bonded together. Within Atomic Design a molecule make up distinct building blocks and refer to design specifications for functional, reusable combinations of atoms, such as a keyword search bar with a search button. 
 

3. Organisms

Combinations of molecular building blocks form organisms that form distinct sections of a user interface. This is where the design begins to take shape with the creation of reusable components such as a footer consisting of a logo, social media icons, a call to action link, and other branding elements.

4.  Templates

Groups of organisms arranged together form a template. The game-changing factor within component-based design is the inherent flexibility of the templated layout, allowing for a wide range of options such as switching out an image for a text block, and previewing responsive layouts for various devices. 

5. Pages

Pages refer to specific representations of templates that take shape beyond a theoretical example and come to life as a real-world view of what the user will see and experience on the site. It is at the page stage where texting and review concerning the totality of the design system tends to occur and adjustments are made.

Need help creating an Atomic Design system for your organization’s website that allows for greater flexibility that maintains brand consistency? Get in touch!

Sep 16 2020
Sep 16

Gatsby Image, along with gatsby-transformer-sharp and gatsby-plugin-sharp, is a common way to handle images in a Gatsby project.  It gives us the power to process source images at build time to create a 'srcSet' for  '' or '' tags, or create versions in grayscale, duotone, cropped, rotated, etc.

When Gatsby builds from a Drupal source, it downloads the source images and processes them to create these image variations which are stored in the public directory. The ability to optimize and art-direct images at build time is great, but build performance suffers while these assets are generated. As a site grows in images, the time it takes to build grows as well. Image processing can take hours, while the rest of the build takes mere minutes.

Sep 16 2020
Sep 16

by David Snopek on September 16, 2020 - 1:27pm

As you may know, Drupal 6 has reached End-of-Life (EOL) which means the Drupal Security Team is no longer doing Security Advisories or working on security patches for Drupal 6 core or contrib modules - but the Drupal 6 LTS vendors are and we're one of them!

Today, there is a Moderately Critical security release for Drupal core and CTools to fix a Cross-Site Scripting (XSS) vulnerability. You can learn more in the security advisory:

Drupal core - Moderately critical - Cross-site scripting - SA-CORE-2020-007

Here you can download:

If you have a Drupal 6 site, we recommend you update immediately! We have already deployed the patch for all of our Drupal 6 Long-Term Support clients. :-)

FYI, there were other Drupal core security advisories made today, but those don't affect Drupal 6.

If you'd like all your Drupal 6 modules to receive security updates and have the fixes deployed the same day they're released, please check out our D6LTS plans.

Note: if you use the myDropWizard module (totally free!), you'll be alerted to these and any future security updates, and will be able to use drush to install them (even though they won't necessarily have a release on Drupal.org).

Sep 16 2020
Sep 16

Our normally scheduled call to chat about all things Drupal and nonprofits will happen TOMORROW, Thursday, September 17, at 1pm ET / 10am PT. (Convert to your local time zone.)

Alberto Rojas from Manati will be giving an update about Layout Builder. We will also discuss whatever Drupal related thoughts are on your mind. If you would like to contribute to the conversation, please join us.  

All nonprofit Drupal devs and users, regardless of experience level, are always welcome on this call.

Feel free to share your thoughts and discussion points ahead of time in our collaborative Google doc: https://nten.org/drupal/notes

This free call is sponsored by NTEN.org and open to everyone.

View notes of previous months' calls.

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