Upgrade Your Drupal Skills

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

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

Guzzle makes HTTP requests easy. When they work, it's like magic. However, as with all coding, getting something to work requires debugging, and this is where the Drupal implementation of Guzzle has a major usability problem - any returned messages are truncated, meaning that with the default settings, error messages that can help debug an issue are not accessible to the developer. This article will show developers how they can re-structure their Guzzle queries to log the full error to the Drupal log, instead of a truncated error that does not help fix the issue.

Standard Methodology

Generally, when making a Guzzle request, it is made using a try/catch paradigm, so that the site does not crash in the case of an error. When not using try/catch, a Guzzle error will result in a WSOD, which is as bad as it gets for usability. So let's take a look at an example of how Guzzle would request a page using a standard try/catch:

try {
  $client = \Drupal::httpClient();
  $result = $client->request('GET', 'https://www.google.com');
}
catch (\Exception $error) {
  $logger = \Drupal::logger('HTTP Client error');
  $logger->error($error->getMessage());
}

This code will request the results of www.google.com, and place them in the $result variable. In the case that the request failed for some reason, the system logs the result of $error->getMessage() to the Drupal log.

The problem, as mentioned in the intro, is that the value returned from $error->getMessage() contains a truncated version of the response returned from the remote website. If the developer is lucky, the text shown will contain enough information to debug the problem, but rarely is that the case. Often the error message will look something along the lines of:

Client error: `POST https://exaxmple.com/3.0/users` resulted in a `400 Bad Request` response: {"type":"http://developer.example.com/documentation/guides/error-glossary/","title":"Invalid Resource","stat (truncated...)

As can be seen, the full response is not shown. The actual details of the problem, and any suggestions as to a solution are not able to be seen. What we want to happen is that the full response details are logged, so we can get some accurate information as to what happened with the request.

Debugging Guzzle Errors

In the code shown above, we used the catch statement to catch \Exception. Generally developers will create a class that extends \Exception, allowing users to catch specific errors, finally catching \Exception as a generic default fallback.

When Guzzle hits an error, it throws the exception GuzzleHttp\Exception\GuzzleException. This allows us to catch this exception first to create our own log that contains the full response from the remote server.

We can do this, because GuzzleException provides the response object from the original request, which we can use to get the actual response body the remote server sent with the error. We then log that response body to the Drupal log.

use Drupal\Component\Render\FormattableMarkup;
use GuzzleHttp\Exception\GuzzleException;
try {
  $response = $client->request($method, $endpoint, $options);
}
// First try to catch the GuzzleException. This indicates a failed response from the remote API.
catch (GuzzleException $error) {
  // Get the original response
  $response = $error->getResponse();
  // Get the info returned from the remote server.
  $response_info = $response->getBody()->getContents();
  // Using FormattableMarkup allows for the use of

 tags, giving a more readable log item.
  $message = new FormattableMarkup('API connection error. Error details are as follows:
@response
', ['@response' => print_r(json_decode($response_info), TRUE)]);
  // Log the error
  watchdog_exception('Remote API Connection', $error, $message);
}
// A non-Guzzle error occurred. The type of exception is unknown, so a generic log item is created. catch (\Exception $error) {
  // Log the error.
  watchdog_exception('Remote API Connection', $error, t('An unknown error occurred while trying to connect to the remote API. This is not a Guzzle error, nor an error in the remote API, rather a generic local error ocurred. The reported error was @error', ['@error' => $error->getMessage()));
}

With this code, we have caught the Guzzle exception, and logged the actual content of the response from the remote server to the Drupal log. If the exception thrown was any other kind of exception than GuzzleException, we are catching the generic \Exception class, and logging the given error message.

By logging the response details, our log entry will now look something like this:

Remote API connection error. Error details are as follows:

stdClass Object (
  [title] => Invalid Resource
  [status] => 400
  [detail] => The resource submitted could not be validated. For field-specific details, see the 'errors' array.
  [errors] => Array (
    [0] => stdClass Object (
      [field] => some_field
      [message] => Data presented is not one of the accepted values: 'Something', 'something else', or another thing'
    )
  )
)

* Note that this is just an example, and that each API will give its own response structure.

This is a much more valuable debug message than the original truncated message, which left us understanding that there had been an error, but without the information required to fix it.

Summary

Drupal 8 ships with Guzzle, an excellent HTTP client for making requests to other servers. However, the standard debugging method doesn't provide a helpful log message from Guzzle. This article shows how to catch Guzzle errors, so that the full response can be logged, making debugging of connection to remote servers and APIs much easier.

Happy Drupaling!

Apr 06 2021
Apr 06

Background

We live in an age of Drupal complexity. In the early days of Drupal, many developers would have a single Drupal instance/environment (aka copy) that was their production site, where they would test out new modules and develop new functionality. Developing on the live website however sometimes met with disastrous consequences when things went wrong! Over time, technology on the web grew, and nowadays it's fairly standard to have a Drupal project running on multiple environments to allow site development to be run in parallel to a live website without causing disruptions. New functionality is developed first in isolated private copies of the website, put into a testing environment where it is approved by clients, and eventually merged into the live production site.

While multiple environments allow for site development without causing disruptions on the live production website, it introduces a new problem; how to ensure consistency between site copies so that they are all working with the correct code.

This series of articles will explore the Configuration API, how it enables functionality to be migrated between multiple environments (sites), and ways of using the Configuration API with contributed modules to effectively manage the configuration of a project. This series will consist of the following posts:

This article will focus specifically on how developers can manage, declare, and debug configuration in their custom modules.

Configuration Schema

Configuration schema describes the type of configuration a module introduces into the system. Schema definitions are used for things like translating configuration and its values, for typecasting configuration values into their correct data types, and for migrating configuration between systems. Having configuration in the system is not as helpful without metadata that describes what the configuration is. Configuration schemas define the configuration items.

Any module that introduces any configuration into the system MUST define the schema for the configuration the module introduces.

Configuration schema definitions are declared in [MODULE ROOT]/config/schema/[MODULE NAME].schema.yml, where [MODULE NAME] is the machine name of the module. Schema definitions may define one or multiple configuration objects. Let's look at the configuration schema for the Restrict IP module for an example. This module defines a single configuration object, restrict_ip.settings:

restrict_ip.settings:
  type: config_object
  label: 'Restrict IP settings'
  mapping:
    enable:
      type: boolean
      label: 'Enable module'
    mail_address:
      type: string
      label: 'Contact mail address to show to blocked users'
    dblog:
      type: boolean
      label: 'Log blocked access attempts'
    allow_role_bypass:
      type: boolean
      label: 'Allow IP blocking to be bypassed by roles'
    bypass_action:
      type: string
      label: 'Action to perform for blocked users when bypassing by role is enabled'
    white_black_list:
      type: integer
      label: 'Whether to use a path whitelist, blacklist, or check all pages'
    country_white_black_list:
      type: integer
      label: 'Whether to use a whitelist, blacklist, or neither for countries'
    country_list:
      type: string
      label: 'A colon separated list of countries that should be white/black listed'

The above schema defines the config object restrict_ip.settings which is of type config_object (defined in core.data_types.schema.yml).

When this module is enabled, and the configuration is exported, the filename of the configuration will be restrict_ip.settings.yml. This object has the keys enable, mail_address, dblog etc. The schema tells what type of value is to be stored for each of these keys, as well as the label of each key. Note that this label is automatically provided to Drupal for translation.

The values can be retrieved from the restrict_ip.settings object as follows:

$enable_module = \Drupal::config('restrict_ip.settings')->get('enable');
$mail_address = \Drupal::config('restrict_ip.settings')->get('mail_address');
$log = \Drupal::config('restrict_ip.settings')->get('dblog');

Note that modules defining custom fields, widgets, and/or formatters must define the schema for those plugins. See this page to understand how the schema definitions for these various plugins should be defined.

Default configuration values

If configuration needs to have default values, the default values can be defined in [MODULE ROOT]/config/install/[CONFIG KEY].yml where [CONFIG KEY] is the configuration object name. Each item of configuration defined in the module schema requires its own YML file to set defaults. In the case of the Restrict IP module, there is only one config key, restrict_ip.settings, so there can only be one file to define the default configuration, restrict_ip/config/install/restrict_ip.settings.yml. This file will then list the keys of the configuration object, and the default values. In the case of the Restrict IP module, the default values look like this:

enable: false
mail_address: ''
dblog: false
allow_role_bypass: false
bypass_action: 'provide_link_login_page'
white_black_list: 0
country_white_black_list: 0
country_list: ''

 

As can be seen, each of the mapped keys of the restrict_ip.settings config_object in the schema definition are added to this file, with the default values provided for each key. If a key does not have a default value, it can be left out of this file. When the module is enabled, these are the values that will be imported into active configuration as defaults.

Debugging Configuration

When developing a module, it is important to ensure that the configuration schema accurately describes the configuration used in the module. Configuration can be inspected using the Configuration Inspector module. After enabling your custom module, visit the reports page for the Configuration Inspector at /admin/reports/config-inspector, and it will list any errors in configuration.

The Configuration Inspector module errors in configuration schema definitions

Clicking on 'List' for items with errors will give more details as to the error.

The 'enable' key has an error in schema. The stored value is a boolean, but the configuration definition defines a string

Using the Configuration Inspector module, you can find where you have errors in your configuration schema definitions. Cleaning up these errors will correctly integrate your module with the Configuration API. In the above screenshot, then type of data in the active schema is a boolean, yet the configuration schema defines it as a string. The solution is to change the schema definition to be a boolean.

Summary

In this final article of this series on the Drupal 8 Configuration API, we looked at configuration schema, how developers can define this schema in their modules and provide defaults, as well as how to debug configuration schema errors. Hopefully this series will give you a fuller understanding of what the Configuration API is, how it can be managed, and how you can use it effectively in your Drupal projects. Happy Drupaling!

Apr 06 2021
Apr 06

Background

We live in an age of Drupal complexity. In the early days of Drupal, many developers would have a single Drupal instance/environment (aka copy) that was their production site, where they would test out new modules and develop new functionality. Developing on the live website however sometimes met with disastrous consequences when things went wrong! Over time, technology on the web grew, and nowadays it's fairly standard to have a Drupal project running on multiple environments to allow site development to be run in parallel to a live website without causing disruptions. New functionality is developed first in isolated private copies of the website, put into a testing environment where it is approved by clients, and eventually merged into the live production site.

While multiple environments allow for site development without causing disruptions on the live production website, it introduces a new problem; how to ensure consistency between site copies so that they are all working with the correct code.

This series of articles will explore the Configuration API, how it enables functionality to be migrated between multiple environments (sites), and ways of using the Configuration API with contributed modules to effectively manage the configuration of a project. This series will consist of the following posts:

Part 1 gives the background of the Configuration API, as well as discusses some terminology used within this article, and Part 2 describes how the API works, and Part 3 explains how to use functionality provided by core, so they are worth a read before beginning this article. 

Read-only configuration

In some situations, site builders may want to prevent any configuration changes from being made on the production environment, preventing changes that may cause unexpected issues. For example, clients with admin access could log into the production server, and make what they think is an innocent configuration change, that results in unexpected and drastic consequences. Some site builders consider it to be a best practice to prevent configuration changes on the production server altogether, under the idea that only content should be editable on the production server, and configuration changes should only be made in development and/or staging environments before being tested and pushed to production.

The Config Readonly module, allows for configuration changes through the UI to be disabled on a given environment. It does this by disabling the submit buttons on configuration pages. The module also disables configuration changes using Drush and Drupal console.

A configuration form that has been disabled with the Configuration Readonly module

Note: some configuration forms may still be enabled when using this  module. Module developers must build their forms by extending ConfigFormBase for the Configuration Readonly module to do its magic. If the developer has built the form using other means, the form will not be disabled, and the configuration for that form can be changed through the admin UI.

To set up an environment as read-only, add the following line to settings.php, then enable the module:

$settings['config_readonly'] = TRUE;

After an environment is set as read-only, changes to configuration can only be made on other environments, then migrated and imported into the active configuration on the read-only environment.

Complete split (blacklist) configuration

Sometimes configuration needs to exist on some environments, but not exist in other environments. For example, development modules, like the Devel module, or UI modules like Views UI (Drupal core) and Menu UI (Drupal core) should not be enabled on production environments, as they add overhead to the server while being unnecessary since the production server should not be used for development.

A problem arises when configuration is exported from one environment, and imported into the production environment. All the configuration from the source environment is now the active configuration on the production environment. So any development modules that were enabled on the source environment are now enabled on the production environment. In the case of development modules like Devel, this may only add some overhead to the server, but imagine a module like the Shield module, which sets up environments to require a username and password before even accessing the site. If this module is accidentally enabled upon import on production, it will block the site from public access - a disaster!

The solution to this situation is to blacklist configuration. Blacklisted configuration is blacklisted (removed) from configuration upon export. This functionality is provided by the Configuration Split module. This module allows for black-listing configuration either by module, by individual configuration key(s), and/or by wildcard.

Note that more detailed directions for creating blacklists can be found on the documentation page. The following is meant to give an overview of how black lists work.

Blacklists are created as part of a configuration profile. Configuration profiles allow for 'splitting' (a divergence in) configuration between environments. Profiles may be created for environment types such development, staging and production allowing for configuration specific to those types of environments. Or profiles could be set up for public non-production environments, that would have the Shield module enabled and configured. While a development profile may apply to all development environments, not all development environments are on publicly accessible URLs, and therefore may not need the Shield module enabled.

When setting up a configuration profile, note that the folder name must be the same as the machine_name of the profile.

Configuration split profile settings

Note that you must manually create the folder specified above, and that folder can and should be tracked using Git, so it can be use on any environment that enables the profile.

Configuration can then be set up to be blacklisted either by module, by configuration key, or by wildcard:

Complete split (blacklist) can be set by module, configuration key, or by wildcard

Finally, environments need to be set up to use a given profile. This is handled by adding the following line to settings.php on the environment:

$config['config_split.config_split.PROFILEMACHINENAME']['status'] = TRUE;

Where PROFILEMACHINENAME is the machine_name from the profile you created.

Although blacklisted configuration does not become part of the exported archive, it is not ignored altogether. When an environment has the profile enabled, upon export, blacklisted configuration is extracted, then written to the folder specified in the profile. The remaining configuration is written to the default configuration directory. When importing configuration, environments with the profile enabled will first retrieve the configuration from the default configuration directory, then apply any configuration from the folder specified in the profile. Environments not set up to use the profile ignore the configuration in the blacklisted directory altogether on both import and export.

This means that a developer can enable the Devel module on their local environment, blacklist it, then export their configuration. The blacklisted configuration never becomes part of the default configuration, and therefore the module will not accidentally be installed on environments with the configuration profile enabled.

Conditional split (grey list) configuration

Grey lists, also provided by the Configuration Split module, allow for configuration to differ by environment. With a blacklist (previous section), the configuration only exists in the active database configuration for environments that are set up to use the configuration profile containing the blacklisted configuration. With a grey list, the configuration exists in the active configuration in all environments, but the configuration profiles can be set up to allow environments to use differing values for the configuration.

Imagine an integration with a remote API requiring a username, password, and endpoint URL. The production server needs integrate with the remote API's production instance, while other environments will integrate with the remote API's sandbox instance. As such, the values to be used will differ by environment:

Production Environment:

remoteapi.username: ProductionUsername
remoteapi.password: ProductionPassword
remoteapi.endpoint: https://example.com/api

Other Environments:

remoteapi.username: SandboxUsername
remoteapi.password: SandboxPassword
remoteapi.endpoint: https://sandbox.example.com/api

A grey list allows for the setup of these values by configuration profile.

You may be remembering that Part 3 of this series of articles discussed overriding configuration in settings.php, and thinking that a grey list sounds like the same thing. After all, the default values for the sandbox instance of the API could be set up as the configuration values, and the production values could be overridden in settings.php on the production environment, with the same end-result.

The difference is that with a grey list, the remote API values are saved to the configuration profile folder, which is tracked by Git, and therefore can be tracked and migrated between environments. When grey listed configuration is exported, the grey listed configuration is written to the configuration profile folder, in the same manner as blacklisted configuration. When configuration is imported, the default values are retrieved, and the grey list values are used to override the default values, after which the configuration is imported into active configuration.

With the configuration override method using settings.php, site builders need to store the various configuration values somewhere outside the project, communicating environment-specific configuration values to each other through some means, to be manually entered on the relevant environment(s). With a grey list, the configuration values are managed with Git, meaning site builders do not need to record them outside the project, nor communicate them to each other through some other means. Site builders simply need to enable the relevant configuration profile in settings.php, and the environment-specific values can then be imported into active configuration from the configuration profile directory. This means that the sandbox API values can be set up as the values used by default on all environments, and a production configuration profile can be enabled on the production environment using the values to connect to the production instance of the remote API.

Conditional split items can be selected either from a list, or by manually entering them into the configuration profile:

Conditional split (grey list) settings can be selected or manually entered

Finally, note that grey lists can actually be used in conjunction with configuration overrides in settings.php. Grey lists are applied during import and export of configuration from the database. Values in settings.php are used at runtime, overriding any active configuration. So a developer could choose to set up their local instance of the system to connect to an entirely different instance of the remote API altogether by overriding the values in settings.php.

Ignoring configuration (overwrite protection)

Sometimes developers will want to protect certain configuration items in the database from ever being overwritten. For example imagine a site named Awesome Site, with a module that supplies the core of the site, named awesome_core. Since this module provides the core functionality of the site, it should never be disabled under any circumstances, as that would disable the core functionality of the site. In this case, the configuration for this module can be set to be 'ignored'. Any attempts to import ignored configuration from the file system to the active configuration in database will be skipped, and not imported.

Configuration can be ignored using the Config Ignore module. The functionality this module provides is similar to the functionality provided by the Config Readonly module discussed earlier, however the Config Readonly module covers the entire configuration of an environment, while the Config Ignore module allows for choosing configuration that should be protected. This configuration is protected by ignoring it altogether on import.

Configuration can be ignored as follows:

  1. Enable Config Ignore module on all environments.
  2. Navigate to the config ignore UI page, and set the configuration item to be ignored. In the case of preventing the awesome_core module from being disabled, the following would be added:
    core.extension:module.awesome_core Configuration to be ignore is entered one item per line. Wildcards can be used.

This setting will ensure that any attempts to change or remove core.extension:module.awesome_core upon configuration import will be ignored. So if the module is enabled on production, and a developer pushes configuration changes that would uninstall this module, those changes will be ignored, and the module will still be set as enabled after import.

Summary

In this article, we looked at various modules that extend the Configuration API, use cases behind these modules, and how the modules worked. We looked at the Config Readonly module, the Configuration Split module, and the Config Ignore module, and how to use these modules to manage configuration differences between environments. In the next, final fifth part of this series, we will look at configuration management for module developers, and how developers can define the schema for the configuration in modules they develop.

Apr 06 2021
Apr 06

Background

We live in an age of Drupal complexity. In the early days of Drupal, many developers would have a single Drupal instance/environment (aka copy) that was their production site, where they would test out new modules and develop new functionality. Developing on the live website however sometimes met with disastrous consequences when things went wrong! Over time, technology on the web grew, and nowadays it's fairly standard to have a Drupal project running on multiple environments to allow site development to be run in parallel to a live website without causing disruptions. New functionality is developed first in isolated private copies of the website, put into a testing environment where it is approved by clients, and eventually merged into the live production site.

While multiple environments allow for site development without causing disruptions on the live production website, it introduces a new problem; how to ensure consistency between site copies so that they are all working with the correct code.

This series of articles will explore the Configuration API, how it enables functionality to be migrated between multiple environments (sites), and ways of using the Configuration API with contributed modules to effectively manage the configuration of a project. This series will consist of the following posts:

Part 1 gives the background of the Configuration API, as well as discusses some terminology used within this article, so it's worth a read before beginning this article.

Active configuration is in the database

In Drupal 8, configuration used at runtime is stored in the database. The values in the database are known as active configuration. In Drupal 7, configuration was known as settings, and stored in the {variable} table. In Drupal 8, configuration is stored in the {config} table. The active configuration is used at runtime by Drupal when preparing responses.

Configuration is backed up to files

The Configuration API enables the ability to export the active database configuration into a series of YML files. These files can also be imported into the database. This means that a developer can create a new Field API field on their local development environment, export the configuration for the new field to files, push those files to to the production environment, then import the configuration into the production environment's active configuration in the database.

The configuration values in the database are the live/active values, used by Drupal when responding to requests. The YMLfiles that represent configuration are not required, and are not used at run-time. In fact, in a new system the configuration files don't even exist until/unless someone exports the active configuration from the database. The configuration files are a means to be able to back up and/or migrate configuration between environments. Configuration files are never used in runtime on a site.

Configuration architecture

Let's look at the Configuration API on a more technical level, using a real-world example. The Restrict IP module allows users to set a list of rules that whitelist or blacklist users based on their IP address. Upon visiting the module settings page, users are presented with a checkbox that allows them to enable/disable the module functionality.

From a data standpoint, checkboxes are booleans; they represent either a true or false value. When exporting the configuration of a site with the Restrict IP module enabled, the relevant configuration key will be saved with a value of either true or false to a .yml file. Modules are required to define the schema for any configuration the module creates. Developers can look at the configuration schema declarations to understand what file(s) will be created, and what values are accepted.

Modules declare the schema for their configuration in the [MODULE ROOT]/config/schema directory. In the case of the Restrict IP module, the schema file is restrict_ip/config/schema/restrict_ip.schema.yml. This file contains the following declaration:

restrict_ip.settings:
  type: config_object
  label: 'Restrict IP settings'
  mapping:
    enable:
      type: boolean
      label: 'Enable module'

Schema declarations tell the system what the configuration looks like. In this case, the base configuration object is restrict_ip.settings, from the first line. When this configuration is exported to file, the file name will be restrict_ip.settings.yml. In that file will be a declaration of either:

enable: true

Or:

enable: false

When the file restrict_ip.settings.yml is imported into the active configuration in another environment's database, the value for the enable key will be imported as defined in the file.

On top of this, enabled modules are listed in core.extension.yml, which is the configuration that tracks which modules are enabled in a given environment. When the Restrict IP module is enabled in one environment, and configuration files exported from that environment are imported into a different Drupal environment, the Restrict IP module will be enabled due to its existence in core.extension.yml, and the setting enable will have a value of either true or false, depending on what the value was exported from the original environment.

Note that if you were to try to import the configuration without having the Restrict IP module in the codebase, an error will be thrown and the configuration import will fail with an error about the Restrict IP module not existing.

Summary

In this article, we looked at how the Drupal 8 Configuration API works on a technical level. We looked at how active configuration lives in the database, and can be exported to files which can then be imported back into the database, or migrated and imported to other Drupal environments. In part 3 of the series, Using the API, we will look at how to actually use the Configuration API, as well as some contributed modules that extend the functionality of the Configuration API, allowing for more effective management of Drupal 8 projects.

Apr 06 2021
Apr 06

Many major cities or regions in Europe, have their own Drupal user group. Everybody can join and participate in their regular physical meetings. Often, there are talks, sometimes, there are workshops, were you’ll always witness a lot of Drupal expertise. You can grab a beer or a cup of coffee and sit together with some old and new friends.

The global Corona pandemic changed this a lot. Physical meetings are not possible anymore. Most user groups skipped their late March,  and April 2020 meetings and discussions started on how to proceed. It was then the initiative of some Drupalistas in the German Drupal Association suggesting a regular Germany-wide online meeting. In May 2020 the initial meeting took place. All German Drupal user groups were invited to join and it worked out extremely well.

Apr 06 2021
Apr 06

If you are a Drupal website owner, developer, admin or a user, you should already know that Drupal 10 is coming soon - June 2022. And that’s just over a year to go! The advantages of migrating to the most updated version of a software are priceless. More so when you have a community of open-source enthusiasts working towards a single goal of improving Drupal every single day, you must trust that migrating to the latest version of Drupal is going to be one of the best decisions you will make.

If you’re still on Drupal 7, it’s about time to migrate to Drupal 8 (or 9). There are many ways of migrating your website from Drupal 7 to Drupal 8 (or Drupal 9). Here’s a no-frills guide to migrating your Drupal 7 website from a database source.

Migration from Database Source

What is a Drupal Migration?

Migration is a movement of content from Drupal 7 to Drupal 8 (or Drupal 9). This includes configuration (content types, vocabularies, user roles, file types, image styles, etc.) and contents (users, nodes, paragraphs, taxonomy terms etc.)

Drupal 7 to Drupal 9

The ETL Process

No matter what your source or destination is for a migration, a Drupal migration will follow the ETL process or the Extract – Transform – Load process. The first step is the Extraction step where the data is extracted from the source plugin. The next step is the Transformation step where the extracted data is processed according to the requirements by the process plugin. And lastly, the Loading step where the data is loaded into the storage by the destination plugin.

Process Plugin

Migration Plugins and Modules

    1. Source plugin

A set of data, called row from the source. They help fetch data from the source like a database, CSV, XML or JSON.

    2. Process plugin

Row data will be processed and transformed as required. It describes how the destination is to be built from the source data.

    3. Destination plugin

Once processed, the transformed row is saved to the destination in the Drupal site.

Modules Required

  • Migrate Module – Contains APIs to migrate content and configuration to Drupal 8.
  • Migrate Drupal Module – Helps in migrating content and configuration from a Drupal source site to Drupal 8.
  • Migrate Drupal UI Module – A user interface to perform the migration.
  • Migrate plus Module – Provides capabilities to transform source data and APIs for grouping migrations.
  • Migrate tools Module – A contributed module that offers extended drush commands to manage Drupal 8 migrations. 
  • Drupal upgrade – A contributed module used to create the migration YML scripts.

Groundwork Before Diving In

Now that we have a fairly good understanding of some of the basic migration concepts and have installed the basic modules needed for the migration (as discussed above), let’s look at a few simple steps to follow before actually commencing a Drupal 7 to Drupal 8 migration:

  • Audit the Drupal 7 site for contributed modules. Many of the fields in the Drupal 7 content types will depend on contributed modules. So, we will need to check for those modules and install the same in Drupal 8 or Drupal 9.
  • Install the contributed modules if it is not incorporated in Drupal 9 core.
  • Install the supportive core modules like revisions, translations, etc. if needed.
  • Have the Drupal 7 database and files accessible by the Drupal 9 instance.
  • Select the method of migration Bulk or Individual carefully based on the complexity of the site.

Connecting to the Drupal 7 Database

Now we will need to connect to the source database of the Drupal 7 website. For that, we will need to add the source database information in the Drupal 8 or Drupal 9 settings file.

Go to settings.php file of your Drupal 8(or 9) site and add the database with migrate key and run this command:

  
drush migrate-upgrade --configure-only --legacy-db-key=migrate --
legacy-root=https://www.drupal7.com/

Or you could also directly configure using this URL:

  
drush migrate-upgrade --configure-only 
--legacy-db-url=mysqli://[email protected]:33067/drupal7_db --
legacy-root=https://drupal7.com/

The above commands will generate migration YMLs based on the Drupal 7 configuration and contents. It will not start the migration as we added the option “--configure-only”.

Drupal 7 to Drupal 8 Migration - Bulk import

To perform a bulk migration on all configurations and contents to Drupal 8 or 9, you will need to execute these commands :

  
drush migrate:import --tag=Configuration --execute-dependencies

This will run all the configuration migrations by running the dependencies at first.

  
drush migrate:import --tag=Content --execute-dependencies

This command will run all the content migrations by running the dependencies at first. Please Note: The migration order is important.

Please Note: The migration order is important.

Drupal 7 to Drupal 8 Migration - Individual import

Sometimes, you might not want to migrate ALL of your content of configurations at one shot. You can then opt to migrate them individually. However, you will need to keep in mind to migrate them in order.

  1. Configuration: User roles, vocabularies, content types, image styles, fields, field instances etc.
  2. Content: Files, paragraphs, Users, terms, nodes, etc.

Migration Tools drush Commands

The Migration Tools module (as discussed previously) is a contributed module that gives you some tools and commands that will help you during a migration. Some of the commands include:

  • drush ms - Migration status
  • drush mim - Migration import

                      Imports the data from Drupal. We can also run the import with a limit. For example: drush mim --limit=10

  • drush mr - Migration rollback
  • drush mmsg - Migration message

                     Shows the captured message (error or notice) after the migration import.

Apr 06 2021
Apr 06

SEO is the process of optimising a website's content with the use of certain keywords with the goal of ranking better in the search results of a search engine, for example, Google. SEO is independent of PPC (pay-per-click) results, and focuses on organic rankings. If a business wants to make the most of the web to reach its targeted audience, Search Engine Optimisation is one aspect that cannot be ignored. According to Backlinko, less than 1% of users care to explore beyond the first page of Google.

black and green graph showing the number of people who go to the second page of Google while searchingSource : Backlinko

Website content still relies heavily on SEO for traction, legitimised by a recent survey stating that several bloggers found that SEO was the second most important driver of traffic for their websites.

white and green bar graph tracking the importance of SEO in driving trafficSource : Backlinko

Owing to these parameters, Drupal has taken into account to include several modules to facilitate SEO in Drupal. Not only are there multiple intent SEO friendly features, Drupal also provides several customizations to fit into the trajectories of various kinds of businesses online.

The Drupal SEO Checklist 

Here are some must have SEO modules in Drupal.

For the overall framework

  • Real Time SEO for Drupal acts as a constant alarm clock to remind you of things that you might have missed. Since there are a number of technicalities involved in SEO, one might skip one or two if left unassisted. Real time SEO keeps a track of things like post length, meta description, consistency of the focus keyword and its placement in the appropriate places etc.
  • Drupal’s SEO checklist module makes use of best practices to check your website for proper optimisation.. It automates most of the on page optimisation making use of the latest techniques that are updated in the module regularly. The way it functions is by breaking down the tasks into functionalities like Title Tags, Paths, Content etc. Links to the associated modules are attached against the task. It also keeps a track of the entire SEO history by placing a time stamp next to each saved item. The SEO checklist module, however, is not for newbies as it requires the user to know the basics of SEO to make optimum use of it. 
  • The Require on Publish module is best to use in cases where the content has fields such as tags or SEO data that one doesn't really need to fill in until the content is going to be published. Hence, it marks required only when the fields are actually required in the process, and not before that. 
  • One of the most popular ways of trapping and practicing SEO is to use Google Analytics to look for the trending keywords and then incorporating those in your content. The Google Analytics module allows a number of statistical features to be added to your website like domain tracking, AdSense support, Modal dialog tracking, enhanced link attribution support etc. thus forming an extensive web statistics tracking system for the site. Additionally, you could also use the Googalytics module that provides for integration of Google Analytics in Drupal.

Linking it Right

  • Linkit provides a simple interface for internal and external linking with WYSIWYG (What You See Is What You Get) editors with the help of an autocomplete field. This module has, by default, support for all types of entities that define a link template, for example, taxonomy, nodes, files, comments etc. Linkit, however, does not have support for link attributes like title, class or target and one would have to use the Editor Advanced Link for the purpose.
  • The Link checker module does exactly what its name suggests. It extracts links from one's content and then at regular intervals, tries to detect broken hypertext links by checking the sites and evaluating the HTTP response codes. If a link check fails, it shows it in the separate section on the content page, hands making it extremely simple to rectify any errors.
  • The Footnotes module creates automatically numbered footnote references in the content, making the article look better structured.
  • The Redirect module provides the user the ability to create manually redirects for all the content, while also maintaining a canonical URL for it - hence redirecting all other requests to that path.
  • Pathauto could also be used in such a case to automatically generate the URL aliases and path redirects, to ensure that the changes in the URL alias do not break the existing links. 

For Navigation

  • The Easy Breadcrumb module is a navigation tracker, which when embedded in your pages, utilises data from the work you have already done to generate your paths' alias. It is a plug and play module that auto generates the breadcrumb by using the current URL. 
  • On the other hand the Menu Breadcrumb module allows the user to use the menu that the current page belongs to for the breadcrumb. It uses the titles of the parent menus to generate the breadcrumbs.

Sitemap

  • Sitemap module helps  make navigation user friendly by providing the visitors a sitemap that gives them an overview of the entire site. It also has provisions for displaying the RSS (Really Simple Syndication) feeds for all the blogs and also for the various categories to explore within the site.
  • To generate a sitemap a Simple XML Sitemap can also be used. The sitemaps generated by this module are compliant to Google's standard regarding multilingual content and are also good with respect to SEO in Drupal.
  • The XML Sitemap module takes into account the sitemaps.org specifications, while creating sitemaps, helping search engines like Google, Ask and Yahoo! to better understand and place the website.
  • Using Menu Attributes, one can specify additional attributes for items in a menu such as ID, name, class etc. The user wants to give the menu and ID so that it is easily detectable using jQuery or when you want to customise the menu. 

For tags

  • Metatag module is quite useful for a methodical Search Engine Optimisation. It auto generates structured metadata like meta tags, meta description and meta keywords that help improve the overall ranking of the website in the search engine results.
  • Hreflang tags are used by search engines to serve the correct language or regional URLs in the search results. Once these tags are generated, the Hreflang module automatically adds these tags to the respective pages. 
  • The Schema.org Metatag module could be used to further extend the Metatag module to display data in a structured format in the head of web pages.
  • The Power Tagging module is used to extract the content of your entity, like node or user, and offer you the concepts and existing free terms that fit best in the context. It has the provision of tagging the entire content automatically via bulk tagging, and also supports multilingual tagging.
  • Similar By Terms brings out the similarities in content items based out of taxonomy terms and links assigned to the content, making the site easily navigable.

Combat Error 404

Instead of displaying '404 page not found', the Search 404 module performs a search on the existing keywords in the URL. This helps retain visitors who might happen upon outdated links.

These are some of the major search engine optimisation modules that help Drupal websites achieve optimum SEO, whether directly or indirectly. While the software is constantly evolving to adapt to the changing norms, SEO remains too dynamic of a subject. And with constant parallel innovation in the terms of technology, SEO also keeps undergoing significant changes owing to these trends. Some Optimisation trends that are projected to stay afloat in 2021 are listed below.

SEO trends in 2021

Looking for user’s search intent 

As User experience expands and seeps into different arenas, its effect is bound to be seen in SEO as well. Google has been pretty mindful about making search intent a top priority, ie, the search engine aims to display results regarding the search intent of the user. To figure out the search intent, it is imperative to examine the keyword. The intent might be informational, transactional, commercial or navigational. For example, a person that searches for 'buy protein bars' has a transactional intent, and tracking this, the search engine is likely to redirect the person to an online shopping site or a grocery store nearby. But if the person searches for 'best protein bars', the search results will greatly vary, leading him to a blog or an informational website.

blue, green and yellow boxes talking about user intent while searching for somethingSource : Search Engine Land

Customer Retention

Not just customer acquisition, but retention also needs to be considered while planning out the SEO of a website. When a visitor turns up, you should be interacting with them, answering their questions, and every need that they are searching for. Each keyword that has been used in optimisation of the site should be justified, and there should be appropriate information about it.

Brand SERP Optimisation

SERP (Search Engine Result Page) tracking is projected to become the norm in 2021. This means that brands will go the extra mile to define who they are and what they offer in accordance with Google's Passage Ranking. The SERP layout is projected to undergo change as well, with businesses switching from creating several verticals within the website for different topics to creating long pages for the entire content, for better ranking in the search results. 

For this to formulate, we may see more personalized research on consumer behaviour in 2021.

Core Web Vitals

Core Web Vitals include features like page speed, multiple device friendliness, image optimisation in  different devices, compliance to security protocols etc. Google introduced core web vitals as a ranking factor in 2021. Hence, it is another aspect that needs to be considered while optimising a website. SEO now is not just about whether it answers your users' queries but also about how satisfied the user is with that information and also whether the environment in which it is being presented seems trustworthy. 

Importance of mobile SEO

About 56% of global internet traffic in 2021 has been attributed to be coming from mobile devices, hence while planning out optimisation strategies, the primary area of concern should be the performance of your website when accessed from a smartphone. Hence, a bare minimum mobile experience isn’t going to suffice if you want Google to consider your website setting out the ranking.

Web Automation

The quality as well as quantity of AI (Artificial Intelligence) generated content cannot be beaten, and hence it is expected to increase monumentally in the following year. Jesse Mcdonald, Optimisation Lead at IBM, believes that it is going to be one of the biggest SEO trends in 2021 to roll out automated functionalities with respect to optimisation, cutting down manual SEO wherever possible. 

Content is still the king

It has been witnessed that blogs of over 2000 words outperform blogs of 1000 words or less, the former perform better with respect to Google's E-A-T (Expertise, Authoritativeness, Trustworthiness) guidelines. Hence, the long form content trend is to continue in 2021 as well, as most websites try to expand their content to said length.

Content also has immense potential when it comes to expanding the audience base of the article. One sure shot way of getting yourself some subtle marketing is to include some statistics, survey or study that constitutes research related to the topic, as others writing on the same topic will keep linking you in their document while using your research data.

Graphics do the job of grabbing attention really quick, hence visual content should be added at regular intervals for sustaining the reader’s attention. Concept visuals, i.e., visuals that explain tricky concepts are especially helpful and are more likely to be shared and referred to. 

Lastly, all the constant research that is done over topics from time to time can be brought to good use by presenting a bunch of content on a specific topic as a ‘hub’. These work exponentially well for SEO, and also are a form of value rich content that is likely to grab attention in a good way and be shared widely.

Visual Search

With the popularity of Google lens soaring, visual search has been trending throughout the year and will continue to occupy space in 2021 trends as well. Therefore, optimising images on your website has become as essential, as according to Backlinko, as 32.5% pages that ranked in Google Lens had a keyword in their Title tag that matched Google's Vision Label.

Conversational UI: Voice and Video interfaces

Google Home and Alexa how become the new members of most internet connected households today, simply because the added convenience these devices bring with themselves. This is the reason why Search Engine Optimisation for voice search is not an option to consider anymore - it is quite a necessity. With Google and Alexa constantly referring to sites that consist of the user's question and answer both, FAQ lists are becoming more and more important. According to Google, 4 out of 10 US adults perform at least one voice search in a day. 

Videos are a significant element that are driving significant traffic to websites, as demonstrated by the following graph.

white graph with blue bars tracking the kind of media bloggers use for the SEO of their siteSource : Orbit Media Studios 

With a dedicated social media platform just for videos (YouTube), the change is quite inevitable and was bound to happen. Video Optimisation is the future of SEO today, hence keyword optimisation needs to be done in the multimedia of your site as well.

Featured Snippets 

Google's search results have become smart as well. With increased focus on User experience, the search engine realises that it is pretty inconvenient for a user to click on every website to read the contained content. So it displays the related content in the form of a Q&A as a part of its featured snippets.

Backlinks

Creating backlinks can also effectively improve SEO rankings and drive traction to the site, but this can only be achieved when the content is good enough to quote, or already has a good enough SEO or an online presence in order to be tracked by other websites. Guest posting is another way of tapping into backlinks. 

Google Passage Ranking

Similar to Featured Snippets, Google has also started to run specific passages from websites that appear relevant to the search result. Google also specified that this feature does not mean that the passages are assessed independently of their pages, but simply means that specific paragraphs can also be an additional ranking factor from now on. 

Domain Authority

With E-A-T evaluation setting in, domain authority is less about links and more about this part of the guideline now - as Google says that it wants to rank pages that are 'reliable sources' and appear to have content that is reflective of the qualities of 'expertise, authoritativeness and trustworthiness'. 

  • Creators of the content of the page are taken into account - is the content generated at random by freelancers, or are these people experts in the particular topic? 
  • A suspicious looking website will not rank well on Google's search results, as the notions of transparency and accountability are gaining ground widely.
  • Maintaining a good reputation outside of a website is also equally important. There is nothing worse than your website claiming something and external sources disagreeing with it. Similarly, being cited on other websites on a positive note is considered while ranking as well.

Combating decreasing CTRs

It is common knowledge that organic click-through-rates are down. And yet it comes as no surprise, because it is quite difficult for organic to survive among features like SERP, Ads, and others. There is a way to combat this practice and stand out, even though a little, in this race - and that is by creating keyword rich URLs, as they have been shown to get much more clicks than URLs without the keyword that the user has searched for.

Conclusion

Even after 20 years of its conception, Drupal continues to remain a favourite in website creation, and that is primarily due to its high level of customisation and adaptability to the present trends. Today we see individuals and organisations both contributing to and relying on Drupal because it has a solid foundation of what it takes to stay up to date, even when it comes to SEO - through its extensive modules and distributions. Rest assured, come what may, the community stands prepared to make the most of these upcoming trends.

Apr 06 2021
hw
Apr 06

I recently opened up a spreadsheet where people can put in their ideas of what I can write about in this DrupalFest series. Someone put in a topic of what advice I would give my younger self. This idea intrigued me and I thought I will make an attempt at writing down advice to new Drupal developers. I am not very comfortable presuming that someone would want to take advice from me; so I am going to say what I would want my younger self to know. I am going to temper my thoughts to be suitable to today’s state of industry. There is no point talking about how the world would be from the point-of-view of 2007. So, let’s get started.

You don’t have to write all the code

One of my first non-trivial programming task was writing an x86 Assembly library for graphics manipulation and computation from QBasic. I started off programming with GW-Basic and QBasic and in time, I realized it is quite slow to do real stuff. That’s when I learnt Assembly language and wrote a library. This started me off on a path where I preferred to write all the code on top of a programming language and not rely on frameworks and libraries. I stayed on this path for about a decade since then.

I eventually learned that to be productive and actually grow, I should stop thinking of code in terms of purity and use what is out there. Other people are talented too and they have gone through the same problems you are going through. Learn from their mistakes and their work and build upon that. I realized much too late (in hindsight) that I was letting perfect be the enemy of good and staying stuck.

Case in point: I found out about Drupal in 2007 from someone and I thought why would I use it when I can and have written multiple CMS’es. The person who introduced me to Drupal (Drupal 5 at the time) was talking about how you can build websites in a matter of hours and use views to build a query with a UI (I hated that idea). He even said that Drupal 6 is even better and is just about to be released. Even after this, I only gave in and built my first Drupal site at the end of Drupal 6 period. That is still the only Drupal 6 site I have built.

There’s another story. I wanted to start a blog and was waiting to perfect the blogging CMS I was building. It had everything I wanted but I was finding more things to add and that became an excuse for me to not start blogging. I realized that one night not able to sleep at 2 AM and it hit me; that’s when I wrote my first (second) blog post. Here’s the actual first.

But do write the code to learn

Yes, I waited a long time to start using other people’s work because I wanted to do it myself. But doing it myself taught me a lot and I encourage you to go through that as well; just not at the expense of getting work done. When you find time, pick one hobby project that you want to do, just one, and do it from scratch.

Learn something not related to what you want to learn

This is something I did without realizing anyway and so I don’t need to give this advice. But I will document it here anyway. Learn a lot. Don’t let go of an opportunity to learn. I cannot stress this enough on how it has impacted me. It was only a feeling until I read more about this in David Epstein’s book “Range: Why Generalists Triumph in a Specialized World“. Essentially, learning things which seem unrelated to what you’re doing is a great work to develop a wide perspective which helps you innovate and excel. If you’re interested in the mechanics behind this, do read the book.

Within the programming area, I started off with QBasic, Assembly, PHP, .NET, C#, C/C++, Java (in school and college), and staples such as HTML, CSS, and JavaScript (much simpler around that time). Since I started working professionally, I have learned ASP.NET, Windows programming internals (from a .NET perspective), CodeIgniter, Kohana, WordPress, Drupal, JavaScript, Laravel, and many others I can’t recollect. More recently, I have started learning Rust, Golang, Flutter, Dart, and technologies such as Docker and Kubernetes. Outside of programming, I often worked with Photoshop, Premiere, Aftereffects, Corel Draw, and generally in printing and video editing projects. Further outside of programming, I used to assemble computers for people and myself and built networks. Going in reasonable depth with all of this helped me understand computers and technology the way I do today.

Also learn something completely outside what you do

It is great to expand your knowledge in the areas around your work but it is also very helpful to pick up completely unrelated activities (what we call hobbies). I used to be part of group that put up props and other types of decorations for community events. As a part of that group, I would cut paper, slice thermocol, apply glitter and other materials, and put them up on walls and hang them from rafters and towers. I also used to volunteer as a photographer and also a vocalist (something similar to a choir group). It may not seem obvious how this would help your career but the broad range of perspectives that develop here help. One aspect of this is just the expanded network that you build which helps you see outside the otherwise narrow world we sometimes confine ourselves to.

Make learning a habit

I read this great book called Atomic Habits by James Clear which opened my eyes to the relevance and effectiveness of habits. Earlier, I often found me fighting against myself to do something: either read more, exercise more, or just behave differently. I used to put up a brave fight and punish myself when I failed (which I often did). You see, I thought I was being a hero by slaying myself with all the burden and was a skeptic when I started reading the book. Not anymore. I now think more about the impact rather than the act and take calculated steps to learn and build my life with the impact in mind, not my current actions.

Go broad and go deep

I already shared why you should go broad with various technologies, but it is just as important to go deep in on one or two technologies you want to focus on. If you’re reading this, one of those things is probably Drupal for you and I would argue you should make that PHP. Go deep into how PHP works. What are the new features in PHP and how are people using those features in other frameworks? How does PHP run on a webserver and what are some of the alternative models of running PHP applications? How does a PHP application differ from something written in Golang, for example, or in Python?

And learn about programming fundamentals too. What problem does object oriented programming solve anyway? Can you apply functional programming principles in PHP? In Drupal? How does a processor execute a program? What does Assembly look like? How does an Operating System schedule programs for execution and how can it run multiple processes at the same time? How does virtualization and containerization work and how does that affect your code?

I know it seems like a lot but you are not going deep in one dive. Take years if you want to but you will see benefits within days of you starting to learn this.

Drupal is awesome

Now, this seems obvious in hindsight but it was not clear to me when I started programming. I already said that I was loathe to try out frameworks and libraries written by other people (that includes CMS’es as well). It was not until I volunteered for a project where I didn’t want to spend much time and just picked up Drupal. That is what set me on the path of my amazing experiences in the Drupal community.

So, I want to say this straight. Drupal is awesome both in terms of the code that is written and the people that have written it or helped to write it. Note that I didn’t say perfect. It wasn’t perfect (even when I pretended it was) and it is probably even less perfect now. But it is awesome when looked at the point-of-view of the impact it has made in my life and the lives around me. I have written often about this so I won’t go deep into it.

The ecosystem is awesome

As I said before, don’t limit yourself to Drupal. Drupal hasn’t limited itself to Drupal anymore since Drupal 8 famously got off the island by adopting practices from the wider PHP community. Learn from other frameworks and languages to determine what’s the best fit. There was a time I used to say that we could build anything in Drupal. That’s still true but that’s neither effective nor efficient. Decide if the code you are writing should be a custom module or a contributed module or a PHP package or a completely different service outside Drupal. There are a lot more awesome libraries and systems out there and you should find out how you can use them in Drupal rather than building that in Drupal.

I feel like I can keep going but I am going to end it here. This was much longer than I thought I would write but that’s the best I can do at this time. If you read it so far, thank you, you’re a star!

Apr 05 2021
Apr 05

In today’s electronically driven communication world, data security is no small matter. What’s safe? Who do you trust? Who else can access your data, and do you even know who those people or companies are selling it to?

A critical part of data security is encryption. It protects everything from our personal information, helping prevent identity theft, financial information like your bank account and credit card from being accessed, to company secrets. According to a 2019 CNBC article, cyberattacks cost businesses an average of $200,000, with 43% of attacks being aimed at small businesses.

What can your business do to help ensure your data is protected, while still enabling collaboration? Take a deep dive into understanding end to end encryption, and how emerging technologies like Yjs can be incorporated to meet your needs. Tag1 Managing Director Michael Meyers and VP of Software Development Fabian Franz are joined by Yjs creator Kevin Jahns, and Nik Graf, a technology consultant and creator of Serenity Notes in this Tag1 Team Talk.

[embedded content]


Related content

Photo by Philipp Katzenberger on Unsplash

Apr 05 2021
hw
Apr 05

This is the fourth post in my DrupalFest series and I am excited to keep it going. I want to write about different tools I am aware of for running quality checks on Drupal code. This will be somewhat similar to my last post where I presented various options but focused on the method I use nowadays.

First of all, what am I talking about? I believe that the code we write is read a lot more times than it is written. It is read by other people than yourselves (2-week older you is another person) and they (you) have to understand what is written. Therefore, code must be optimized for readability. Performant code is a must, of course, but not at the expense of readability. When your best-performing code breaks and you can’t understand it to fix it, that performance is useless.

Types of checks

One of the low hanging fruits here is following a consistent code style. Drupal documents its coding style in detail and the Drupal core and contributed modules (most of them anyway) follow it. True, it’s not like PSR-2 or PSR-12; it was developed long before there were PSR’s, but if you are working with Drupal, it will be a good idea to follow this coding style consistently. Now, you could manually review each and every line of your code to make sure you are following the code style and halt your pull requests, but that is not a good use of your time. Hence, tools.

Apart from the coding style, there are ways to prove “correctness” of your code. Broadly speaking, there are two aspects of correctness–the code is coherent and the business logic is correct. The coherent code aspect can be checked using various static analysis tools; PHPStan and Psalm are few of the popular ones. For verifying the business logic, we write automated tests and PHPUnit is the defacto standard for that.

Tools

Before we get into the Drupal site of things, I’ll list the various tools that we use. I won’t attempt to document them here (in the interest of time) but you shouldn’t have trouble finding their documentation.

  • PHP Code Sniffer – Mainly for code style checks but can be a bit more sophisticated using rules.
  • Drupal coder rules – Code sniffs for checking Drupal coding style.
  • DrupalPractice coder rules – Code sniffs for checking Drupal conventions.
  • PAReview.sh – Automated tool that calls PHPCS with Drupal-related coder sniffs apart from other checks. This is commonly used to check if your module is contribution ready.
  • PHPStan – Static analyzer for PHP code that can perform various levels of type checks and other correctness checks.
  • Psalm – This is another static analyzer with same basic level of checks as PHPStan and then some interesting checks.
  • PHPLint – A simple PHP linter which supports parallel checks and better error reporting than just running php.
  • Other linters such as ESLint, TwigCS, etc – Linters for their specific languages.
  • PHPCPD – PHP Copy Paste Detecter. Like the name says, it checks for repeated lines of code.
  • PHPMD – PHP Mess Detector. Analyze source code for various mathematic measures of code.
  • PHPUnit – Test runner for unit, integration, and functional tests.
  • Behat – Test runner for Behavior tests.

Almost all of these tools can be installed via composer or PHAR files. Composer is an easy way to get these tools but they end up affecting your project dependencies. PHAR files have to be installed on your machine (and everyone in the team should do that too). In both of these methods, you still have to remember to run the tools. That is where the next set of tools come in.

Automatically running checks

One of the ways to make sure everyone on the team adheres to the checks is by running the test in CI. This way, the team would immediately know if their commit is failing checks without even someone having to say so in a pull request. You could again choose to have all of these tools in your composer.json and install them while running your CI, but there is a better way for most cases. DrupalQA is a Docker image which packages almost all of the above tools and you can just run the commands you want within the Docker container. Almost all modern CI tools provide some way of running tests inside a container and you should find documentation to do that for your CI tool. Here is an example of a Gitlab CI job definition which uses the PHP 7.4 version of this image.

drupal_codequality:
  image: hussainweb/drupalqa:php7.4
  stage: test
  script:
    - composer validate
    - phplint --no-cache -v web/modules/custom/
    - phpcs --standard=phpcs.xml.dist --extensions=php,module,inc,install,test,profile,theme --ignore=/node_modules/ web/modules/custom
    - phpmd web/modules/custom/ text phpmd.xml

You could even run the Docker image locally but that’s more trouble than it’s worth. There is a better way in any case.

Have your team run checks automatically

The CI is fine to run these tests but what if you want to save time between commit, push, and CI runs. Wouldn’t it be better for developers to run these checks on their machines before they commit their code. GrumPHP is a tool which allows you to do just that. Vijay CS has written a wrapper on GrumPHP that provides default configuration for checks related to Drupal. While this is great for general use cases, I wanted to make a highly opinionated one for my team at Axelerant. While it is opinionated, it is still available for use and you would just install it using composer this way:

composer require axelerant/drupal-quality-checker

After this, anyone using your project would automatically get git hooks installed (once they run composer install) to run a few Drupal-specific checks every time they commit. You can modify the default configuration and add/remove any tools you wish. Just follow GrumPHP documentation for the same. Of course, more documentation is also available at the Github page for axelerant/drupal-quality-checker.

GrumPHP recently made a lighter package available called GrumPHP Shim. This provides the same set of features but installs a PHAR file instead of a regular composer plugin. This has the benefit of keeping your project dependencies free of GrumPHP’s dependencies reducing the chances of conflict. Axelerant’s version of drupal-quality-checker uses the shim for this reason.

I think I covered all the tools I am aware of and could recollect in the span of couple of hours today. I’m sure there are more tools that are missing here but I am going to call this DrupalFest post done for now. If I am missing something obvious (or even niche), please point it out in the comments so that I can revise or write about it in a separate post.

Apr 04 2021
hw
Apr 04

PHP 7.4 introduced the concept of preloading classes (files) on server start-up into the PHP opcache. This gives us performance benefits for sites that tend to load a lot of files with every request; something that Drupal is known to do. A properly configured web server would have opcache (opcode cache) enabled anyway, but preloading brings in a modest performance boost on top of that.

PHP opcache is designed to cache the opcodes of a PHP file so that the file does not have to be reinterpreted with every request. The bytecode (opcode) is cached in shared memory in RAM which means that the cache lives only as long as the PHP process is running. When the opcache is enabled, PHP caches whichever files are loaded during execution and only recompiles the file if it has changed (this setting can be disabled for an additional performance boost).

Preloading works in a similar way except that you would write a script that would load the files you want to cache. This script is set to PHP’s opcache.preload setting which executes this script every time the server starts. Since this script is run with the server, you have to make sure that any errors are handled properly; otherwise, the server would throw an error and quit. Now, you may want this script to load all the files in your application, but the opcache memory size is limited. This means that you should only preload files that are required by most requests. In many PHP applications, these files may even be hand-written to get the best ratio of memory usage and throughput.

Preloading with Drupal

Now that we understand how preloading works, let’s see how it can be used with Drupal. Writing the preload script by hand is difficult as Drupal is a dynamic system. Even if you write a preload script for all the Drupal core files, it may be your contrib modules that are a better fit for this. This is the reason I have written a Drupal module called preloader to make this easy for you.

The module uses a PHP package called darkghosthunter/preloader which does most of the heavy lifting. The package checks the current opcache usage and generates the preload script. The Drupal module brings in Drupal-specific customization (removing files that shouldn’t be preloaded) and a user interface to generate the file. You still have to manually add the preload script to your PHP settings for the changes to take effect. Still, the difficult task of generating the script file listing all the important files is made easy for you.

The workflow is as follows:

  1. Install the module using composer as you normally would.
  2. Configure the module to ignore any additional directories or files if you want.
  3. Restart the webserver and then load some of the pages that are frequently hit on your site.
  4. Go back to the module configuration page and generate the script.
  5. Set the opcache.preload setting in your php.ini file to the generated script path.
  6. Restart your webserver and test.

Gotchas

Since the preload script is executed at the server start and the cache is permanent as long as the process is running, if you change any of the preloaded files, you have to restart the server. For this reason, it is not a good idea to use this functionality during development. The module may remain enabled but the opcache.preload setting should not be set on the developer machines.

Performance impact

In my early tests, I saw an average of 10% improvement with preloading enabled across different percentiles. This test is quite old and I should repeat this on a better machine but the result should still be indicative. Hopefully, I will be able to test this module again this month and even work on some of the issues that have been reported. I will share screenshots or even a video of the test when possible.

This is it for today’s DrupalFest post. See you tomorrow, hopefully.

Apr 03 2021
hw
Apr 03

This post will cover quickly setting up a Drupal website for testing, experimentation, or evaluating features on your local system. While I cover a different set of options briefly, I will mainly talk about a tool we have built to let us quickly scaffold Drupal sites with best practices built in. This post is a part of the DrupalFest series which celebrates 20 years of Drupal. Let’s get started.

Before I go to the main part of the article, let us look at what options do you have to quickly set up a Drupal website for evaluation. While all the ways are effective, there are trade-offs typical of each method. We’ll start with the simplest way to experiment with a Drupal site and then keep going up the level of complexity, but also the flexibility you get.

Someone else’s machine

The easiest way to set up a Drupal site is in the Cloud, aka, someone else’s machine. Broadly, there are two ways I can think of to do this. The first method involves one of the excellent Drupal hosting providers and signing up for a free account. Drupal.org lists some of the hosting supporters who offer a free account to try out Drupal. Go to this link to get started: https://www.drupal.org/try-drupal.

While the above method lets you try out not just Drupal but also a hosting platform where you might actually run your website, you may not want to create an account to just try out Drupal. In that case, there is SimplyTest.me. This site provides a time-bound sandbox environment where you can quickly try out Drupal, one of the Drupal distributions, with or without modules and themes, and even apply patches. The sandboxes are available for 24 hours and give you complete control of the Drupal site through the UI. You don’t get command-line or SSH access this way, but for quickly testing out a module or a distribution, this is the easiest solution out there. You don’t need an account. Just pick the modules or the distribution and you have a sandbox ready in moments.

Your machine

On your machine, you have a little bit more control over the site but you do need the software required to run Drupal. If you’re only interested in quickly evaluating Drupal on your machine and still have access to the files and command line, the Drupal evaluator guide gives you an option to run this with just PHP. More details and instructions are available at the link: https://www.drupal.org/docs/official_docs/en/_evaluator_guide.html.

The problem with the above method is that it won’t run Drupal in an environment reasonably similar to where you would host. This is good for evaluating Drupal and quickly editing a few files but the experience working with PHP built-in server and SQLite would not help development. To take it a step further, you would need Docker as a pre-requisite.

If you have Docker and you already have a Drupal codebase downloaded, then tools such as Lando and DDEV would help you get started in no time at all. If you want to take it a step further, keep reading to the next section.

Finally, you have the classic method of installing Drupal on your machine by manually installing all the software required to run Drupal (that’s PHP, Apache/nginx, MySQL/MariaDB, etc). I don’t find many developers do this anymore and it is more trouble than it is worth. If you can’t run Docker for any reason, consider running it in a virtual machine using the excellent DrupalVM.

Axelerant’s template tool

Now to the main section of the post. At Axelerant, we wanted to automate the entire process of setting up a Drupal site quickly along with the codebase, Lando configuration, some of the best practices we follow, and even CI configuration. I wrote a tool for that called axl-template which is available via pip (yes, it’s written in Python and needs at least Python 3.6). Once the tool is installed, you can quickly set up a Drupal site along with all the configuration I mentioned in a matter of minutes. I have measured this time from running the first command to have Drupal running to be minutes (longest time taken by Drupal installation). Here’s a somewhat old video where I use this tool to set up Drupal 9 with Lando.

[embedded content]

I have added new features to this tool since I made the video, the most notable feature being able to specify modules and packages right in the first command. The idea is to have your codebase created from a single command and ready to run. I am planning to create a new video to cover these and many other features added to the tool. For now, the documentation is a good reference. Read more at https://github.com/axelerant/axl-template.

If you’re averse to installing a Python package through pip and don’t want to get it from the source code either, you could run it via Docker using whalebrew. Instructions to do these are in the README file but only one of the commands is supported in this way.

We’re continuing to improve this tool by adding support for more common development tools that are typically used. One example that comes to my mind right now is Acquia’s BLT. I can’t promise when that support will come out but it’s on the cards. In any case, this package is released under MIT license and contributions are very welcome.

This is it for today and I am just completing this post with less than four minutes to spare to midnight. Have a good DrupalFest everyone.

Apr 02 2021
Apr 02

This year’s DrupalCon North America 2021 keynotes highlight the power of the global Drupal community to make a difference in some of the most crucial issues of our time and the future of digital experiences. Register today.

The Drupal Association is planning a blockbuster event for DrupalCon North America, the most widely attended Drupal event, 12-16 April from 11:00 - 15:00 EDT daily. This year’s all-virtual event brings together Drupal experts, enthusiasts, end users, and the broader open source software community to connect, collaborate, and contribute to advancing Drupal - the world’s leading open source digital experience platform (DXP).

Heather Rocker, executive director of the Drupal Association states, “Our global community of developers, marketers, and business leaders come to DrupalCon to connect, learn about the experiences of their peers, and share their own expertise. DrupalCon participants also benefit from the opportunity to learn from our keynote and featured speakers. This year, those topics include the role of open source in schools to close the digital divide, the importance of allyship in developing diversity and inclusion, building successful mentorship for people of color in tech, and understanding digital rights as human rights.”

Featured keynotes will highlight inclusion, closing the digital divide, and the Drupal platform’s future.

Sheree Atcheson, Global Diversity, Equity & Inclusion Leader
Allyship—the key to unlocking the power of diversity
Monday, 12 April 12:10-12:40 EDT
Atcheson, an industry-leading voice on diversity and inclusion in tech, will talk about the importance of intersectional allyship in creating inclusive environments and technology. She’ll offer tips on how everyone in any role can actively consider, champion, and advocate for others in their work and be more inclusive in their day-to-day lives.

Atcheson has been named one of the UK’s Most Influential Women in Tech and has received multiple international awards for her work to advance diversity and inclusion in the tech industry.

Dries Buytaert, Founder, Drupal
Driesnote
Wednesday, 14 April 12:30-13:50 EDT
A much-anticipated highlight of DrupalCon, Buytaert, Drupal’s founder, will deliver his annual talk celebrating Drupal successes over the past year, outlining the state of the Drupal project now, and offering his thoughts on what’s next.

Buytaert is the original creator and project lead for Drupal, an open source platform used around the world to build websites and digital experiences, as well as co-founder and chief technology officer of Acquia, a venture-backed technology company.

Stuart Keroff, Social Studies and Technology Teacher, Aspen Academy
School needs open source, now more than ever
Friday, 16 April 14:20-14:50 EDT
Technology educator Stuart Keroff, founder of the first two middle school Linux clubs in Minnesota, has spent the last 10 years guiding middle school students to use open source as a tool to close the digital divide in education. He and his students will share how they used open source software to recycle computers for their fellow students during COVID-19 school closures.

To date, he and his students have provided over 600 Linux computers, helping students learn while also saving money for their schools.

New this year - participants can attend keynote sessions dedicated to strategic Drupal Initiatives:

Decoupled Menus
Tuesday, 13 April
This initiative is focused on developing an easy-to-integrate solution for JavaScript front ends to consume configurable menus managed in Drupal—a key enhancement for developers. This is the first step in standardizing best practices for Decoupled Drupal.

Easy Out of the Box
Wednesday, 14 April
This initiative is designed to refine improvements introduced in the Drupal 9 release and enable new features that can make Drupal even easier to use.

Automated Updates
Thursday 15 April
This initiative is all about implementing a secure system for automatically deploying safe, secure updates for Drupal sites—a crucial enhancement for Drupal service providers and end users.

Drupal 10 Readiness
Friday, 16 April
This initiative is our effort to update and enhance the platform to enable a smooth, secure transition to Drupal 10, which launches in 2022.

Invest in your career, register today
The global pandemic has increased pressures around work-life integration, so DrupalCon 2021 is built with flexibility in mind. Each day is streamlined with 4 hours of live content, and the virtual setting allows easy participation in the featured keynotes, small group discussions, and interactive skill-building sessions most relevant to you.

Tickets are $245 per attendee and include access to all DrupalCon events, premiere access to the session recordings, as well as admission into the industry summits of your choice (higher education, healthcare, nonprofit, and government) held throughout April. Registration details, as well as additional speaker and session information, are available at https://events.drupal.org/northamerica2021

DrupalCon is brought to you by the Drupal Association in collaboration with a team of dedicated contributors and sponsors, including Diamond Sponsors Acquia, Pantheon, and Platform.sh.

DrupalCon Community Photo

Apr 02 2021
Apr 02

This year’s DrupalCon North America 2021 keynotes highlight the power of the global Drupal community to make a difference in some of the most crucial issues of our time and the future of digital experiences. Register today.

The Drupal Association is planning a blockbuster event for DrupalCon North America, the most widely attended Drupal event, 12-16 April from 11:00 - 15:00 EDT daily. This year’s all-virtual event brings together Drupal experts, enthusiasts, end users, and the broader open source software community to connect, collaborate, and contribute to advancing Drupal - the world’s leading open source digital experience platform (DXP).

Heather Rocker, executive director of the Drupal Association states, “Our global community of developers, marketers, and business leaders come to DrupalCon to connect, learn about the experiences of their peers, and share their own expertise. DrupalCon participants also benefit from the opportunity to learn from our keynote and featured speakers. This year, those topics include the role of open source in schools to close the digital divide, the importance of allyship in developing diversity and inclusion, building successful mentorship for people of color in tech, and understanding digital rights as human rights.”

Featured keynotes will highlight inclusion, closing the digital divide, and the Drupal platform’s future.

Sheree Atcheson, Global Diversity, Equity & Inclusion Leader
Allyship—the key to unlocking the power of diversity
Monday, 12 April 12:10-12:40 EDT
Atcheson, an industry-leading voice on diversity and inclusion in tech, will talk about the importance of intersectional allyship in creating inclusive environments and technology. She’ll offer tips on how everyone in any role can actively consider, champion, and advocate for others in their work and be more inclusive in their day-to-day lives.

Atcheson has been named one of the UK’s Most Influential Women in Tech and has received multiple international awards for her work to advance diversity and inclusion in the tech industry.

Dries Buytaert, Founder, Drupal
Driesnote
Wednesday, 14 April 12:30-13:50 EDT
A much-anticipated highlight of DrupalCon, Buytaert, Drupal’s founder, will deliver his annual talk celebrating Drupal successes over the past year, outlining the state of the Drupal project now, and offering his thoughts on what’s next.

Buytaert is the original creator and project lead for Drupal, an open source platform used around the world to build websites and digital experiences, as well as co-founder and chief technology officer of Acquia, a venture-backed technology company.

Stuart Keroff, Social Studies and Technology Teacher, Aspen Academy
School needs open source, now more than ever
Friday, 16 April 14:20-14:50 EDT
Technology educator Stuart Keroff, founder of the first two middle school Linux clubs in Minnesota, has spent the last 10 years guiding middle school students to use open source as a tool to close the digital divide in education. He and his students will share how they used open source software to recycle computers for their fellow students during COVID-19 school closures.

To date, he and his students have provided over 600 Linux computers, helping students learn while also saving money for their schools.

New this year - participants can attend keynote sessions dedicated to strategic Drupal Initiatives:

Decoupled Menus
Tuesday, 13 April
This initiative is focused on developing an easy-to-integrate solution for JavaScript front ends to consume configurable menus managed in Drupal—a key enhancement for developers. This is the first step in standardizing best practices for Decoupled Drupal.

Easy Out of the Box
Wednesday, 14 April
This initiative is designed to refine improvements introduced in the Drupal 9 release and enable new features that can make Drupal even easier to use.

Automated Updates
Thursday 15 April
This initiative is all about implementing a secure system for automatically deploying safe, secure updates for Drupal sites—a crucial enhancement for Drupal service providers and end users.

Drupal 10 Readiness
Friday, 16 April
This initiative is our effort to update and enhance the platform to enable a smooth, secure transition to Drupal 10, which launches in 2022.

Invest in your career, register today
The global pandemic has increased pressures around work-life integration, so DrupalCon 2021 is built with flexibility in mind. Each day is streamlined with 4 hours of live content, and the virtual setting allows easy participation in the featured keynotes, small group discussions, and interactive skill-building sessions most relevant to you.

Tickets are $245 per attendee and include access to all DrupalCon events, premiere access to the session recordings, as well as admission into the industry summits of your choice (higher education, healthcare, nonprofit, and government) held throughout April. Registration details, as well as additional speaker and session information, are available at https://events.drupal.org/northamerica2021

DrupalCon is brought to you by the Drupal Association in collaboration with a team of dedicated contributors and sponsors, including Diamond Sponsors Acquia, Pantheon, and Platform.sh.

DrupalCon Community Photo

Apr 02 2021
Apr 02

Our first Drupal Initiative update was posted in December 2020 showcasing the contributions that drive our community of innovation and highlighting how you can get involved.

Rather than sharing a lengthy report every quarter, we will feature a select number of initiatives monthly to allow for the content to be more easily consumable. Initiatives will rotate so each is featured once per quarter. If you would like to add your group/initiative to these updates, please contact Rachel Lawson.

This month, we reached out to Drupal Diversity & Inclusion, DrupalLadder, Promote Drupal, Event Organizers Working Group, New Front-End Theme, and Drupal Community Working Group, and here is what they tell us about their activities over the last three months.

Join the Drupal Community Summit, Tuesday, 6 April, from 11:00 EDT - 15:00 EDT and hear from Drupal Diversity & Inclusion, Promote Drupal, Event Organizers Working Group, and the Drupal Community Working Group. 

About this initiative 

The Drupal Diversity & Inclusion group seeks to continue the conversation about diversity and inclusion within Drupal. The group organizes regular meetings and curates a resource library.

What have been your priorities in the last three months?

Over the last three months, we've been focused on the early stages of planning for Drupal Diversity & Inclusion Camp, a virtual event focused on centering and lifting up the voices of marginalized folks in the Drupal community. 

What has been your greatest challenge in the last three months?

We would love assistance in planning DDI Camp. We have a proposed budget, and now we need help with selecting and scheduling speakers, choosing a virtual tool to host the event, contacting possible sponsors, planning swag and social events, and much much more.  

And what has been your greatest success in the last three months?

We've been excited about bringing our new leads on board, and the planning for the camp is going well. 

How can people contribute or support the initiative over the next few months?

Please join us for a few upcoming events:

About this initiative 

DrupalLadder is a community initiative to create an onramp for new Drupal users as well as new contributors to the Drupal project, or for those looking to level up their skills.

What have been your priorities in the last three months?

  1. user experience when getting started (create an account, understand next steps); 
  2. adopt an up-to-date theme

What has been your greatest challenge in the last three months?

Demands on contributors' time, and keeping ourselves organized

And what has been your greatest success in the last three months?

Some very skilled contributors have done some very nice work - we're looking forward to launching it!

How can people contribute or support the initiative over the next few months?

  1. Project management
  2. Authoring content - currently requires close attention to detail and rolling with a few frustrations. 
  3. Refactor a few decoupled features that have the right concepts but groped around for the right implementation.

About this initiative 

Promote Drupal Initiative has one main purpose: to create business marketing materials targeted at the decision-makers who choose to adopt Drupal for their business.

What have been your priorities in the last three months?

It's Drupal's 20th birthday this year, plus with the first DrupalFest and DrupalCon next month, there is a lot to celebrate and highlight. As a more long-term goal, it's clear that we need a good core set of evergreen marketing content on Drupal.org.

What has been your greatest challenge in the last three months?

We need to get more organized and make it easier for people to get up and running with contributing to Promote Drupal. Hopefully, we can build on the newly organized roles and committees (see below) and the momentum of the DrupalCon Marketing Committee to take Promote Drupal to the next level!

And what has been your greatest success in the last three months?

Thanks to help from the Drupal Association, the DrupalCon Marketing Committee was formed in March and has been hard at work marketing the upcoming conference. Great work to that team!

Also, we created a common What is Drupal deck and have created evergreen versions of the Drupal Pitch Deck and Drupal 9 one-pager. Now, how to feature this content more prominently on Drupal.org? 

How can people contribute or support the initiative over the next few months?

We would love to grow the Promote Drupal team, and we have some specific roles to fill. Read about the roles and fill in our recruitment form to get involved. 

About this initiative 

The Event Organizers Working Group (EOWG) is concerned with supporting community-led events within the Drupal community. These include camps, summits, training days, contribution days, and meetups.

What have been your priorities in the last three months?

All of the EOWG priorities were focused around our three new initiatives:

  1. Onboarding to the Drupal Community at Events
  2. Drupal Events Platform
  3. Drupal Events Website / Database

During this time, we determined which board members will serve on which initiative, defined each initiative's short-term goals and drafted a call for volunteers for each initiative. I am pretty psyched about what these awesome folks have accomplished. Much love :)

What has been your greatest challenge in the last three months?

Increasing our participation is definitely our biggest challenge. Our event organizer open community meetings have been happening on Zoom for over two years now and just like everyone in the world, I think Zoom fatigue and the challenges of work-life integration can make it difficult for any additional commitments. Many of the organizers are used to attending other camps in a show of support and building community, and for me personally, I am having a tough time missing those connections. By not having the opportunities to meet people in person and talk with other event organizers make it even more difficult for us to attract new members. But I am hopeful that will soon change. 

And what has been your greatest success in the last three months?

Our greatest success was coming together in just three months and collaborating with the Drupal Association with the unveiling of a newly organized web page that will help raise the profile of all Drupal community events happening around the world. Well, I can’t actually tell you what it is. Stay tuned! 

How can people contribute or support the initiative over the next few months?

Sign up to volunteer for one of our three initiatives:  Onboarding to the Drupal Community at Events, Drupal Events Platform, Drupal Events Website / Database. View a description of all of our initiatives here.

About this initiative 

The New Front-End Theme initiative seeks to create a new default front-end theme for Drupal with a modern look and feel.

What have been your priorities in the last three months?

Working toward becoming stable and Drupal's default theme

What has been your greatest challenge in the last three months?

Code-wise, Olivero is in a great place. The difficult part is getting the code into Drupal core. To do this, we frequently have to get sign offs from accessibility maintainers prior to core committers. All of the people within these roles are very busy, and it’s hard to get their attention. This continues to be a challenge, but Mike frequently plays the role of “squeaky wheel” to get attention. The deadline for Olivero to become stable and the default theme for Drupal 9.2 is mid-May 2021, which gives us a bit over a month. We’ll have to step up our momentum if we are going to hit that. 

And what has been your greatest success in the last three months?

During Midcamp, we organized a multi-day sprint to concentrate on testing. This started with Matt Glaman teaching everyone NightwatchJS (Drupal's core JavaScript testing framework) and making sure everyone is up and running on their local environments.

A lot of people then worked together to create our first Olivero Nightwatch test, which involves checking if an element is visible, scrolling the browser, and rechecking visibility.

Later, we split off to work on more automated tests. Brian Perry led the charge to write a number of PHPUnit tests along with many others, and many of us (including Matthew Radcliffe and Benji Fisher) continued writing NightwatchJS tests to ensure the various functionality of Olivero’s menus (which are deceptively complex).

Outside of testing, we’ve been making slow but steady progress on Olivero’s technical debt and accessibility issues. Mike Herchel has been doing occasional “mini-sprints” with core-committer Lauri Eskola to work on getting RTBC issues committed and into 9.2.x. This has been working very well, and we have one more scheduled in the coming weeks.

How can people contribute or support the initiative over the next few months?

I miss you all. 

Issue reviews (from an accessibility point of view) are always helpful, plus you can find me at DrupalCon North America 2021 if you want to chat about the work we’re doing!

About this initiative 

The mission of the Community Working Group (CWG) is to foster a friendly and welcoming community for the Drupal project and to uphold the Drupal Code of Conduct.

What have been your priorities in the last three months?

We have been working to expand the size of the conflict resolution team, working to identify additional community health-related workshops that we can organizer, the launch of "nudges", continue to offer Code of Conduct contact training and make it a more visible aspect of Drupal events, the 2021 Aaron Winborn Award, and our annual report.

What has been your greatest challenge in the last three months?

Expanding the size of the conflict resolution team. Difficult choices.

And what has been your greatest success in the last three months?

Difficult to say - I'm not really sure.

How can people contribute or support the initiative over the next few months?

Be kind to each other.

Apr 02 2021
Apr 02

OVERVIEW/SUMMARY

The goal of this survey was to better understand the preferences of organisations and individuals who are already building decoupled applications in order to help inform the decisions we make going forward. The survey was executed using Survey Monkey and was promoted primarily via existing Drupal developer channels. The survey ran for 2 weeks, and received a total of 133 responses.

This analysis and post where created by Baddý Breidert, Liam Hockley, and Joe Shindelar with support from others in the community.

Below are some of our initial findings from looking at the results. And we anticipate coming back to this data later to help better understand the needs of existing decoupled application developers.

You can learn more about the Decoupled Menus Initiative, and come say hi on Slack in #decoupled-menus-initiative.

ANALYSIS

Q1: How many years have you been building decoupled applications?

Question 1 - Graph showing count of Responses
Caption: Question 1 - Graph showing count of Responses
Question 1 - Table showing count of responses
Caption: Question 1 - Table showing count of responses

These results show a significant amount of users in the 1-3 year range, this is somewhat expected given how the growth of frameworks like Vue, React, has accelerated in the past few years. A notable amount of users have been building decoupled sites for longer than 3 years, perhaps a sign that we have almost 30% of our responses being early adopters?

Q2: Which CMSs do you use?

Question 2 - Graph showing CMS usage
Caption: Question 2 - Graph showing CMS usage
Question 2 - Table showing CMS usage responses
Caption: Question 2 - Table showing CMS usage responses

The overwhelming number of responses are Drupal users. This was a multiple choice question, and there were only 9 respondents who did not list Drupal. Given how the survey was marketed largely to our existing networks this isn’t surprising. It is worth remembering, however, that these results are going to be heavily skewed towards the thoughts of existing Drupal users.

In the future we need to find more ways to engage with users outside the Drupal bubble if we want to learn what is required to make Drupal an attractive platform for them.

Q3: Which JS frameworks do you use?

Question 3 - Graph showing which JS frameworks are being used
Caption: Question 3 - Graph showing which JS frameworks are being used
Question 3 - Table showing which JS frameworks are being used
Caption: Question 3 - Table showing which JS frameworks are being used

It is clear that React is certainly favored among out participants, with Vue being a fairly close second. Other frameworks do not have a lot of representation. These results indicate that we should make efforts to ensure that we cater to both React and Vue users, with other frameworks being secondary concerns in terms of support?

According to the 2020 State of JS survey 80% of JavaScript developers use React, and 49% use Vue. That’s a much larger difference than what we see in our data. And maybe indicates that there’s a stronger attraction to Vue amongst Drupal users than in the general JS world. Which may be worth noting when making decisions using these numbers. Also, Angular has 56% usage, higher than Vue, in the State of JS survey but only 17% amongst Drupal users.

The Next/Nuxt frameworks are used by ~30% of React/Vue developers. This is something we should be aware of. And at least ensure that our solutions are compatible with these tools with minimal fuss.

Q4: Which JS (nodejs) tooling do you use?
 

Question 4 - Graph showing which JS (nodejs) tooling are used
Caption: Question 4 - Graph showing which JS (nodejs) tooling are being used
Question 4 - Table showing which JS (nodejs) tooling are being used
Caption: Question 4 - Table showing which JS (nodejs) tooling are being used

NPM is the most widely used nodejs tool which isn’t too shocking. We didn’t have an option for Yarn, but it was written in the other response 10 times. It is probably safe to say that a majority of our user base still prefer to use NPM as their package manager. Webpack and Gulp use should not be ignored as it looks like these are the two most prevalent node build tools.

This lines up with the broader JavaScript ecosystem where the State of JS data indicates that both NPM and Webpack are nearly ubiquitous among JavaScript developers.

One thing this data doesn’t tell us is what tooling people *want* to use. And it may be worth trying to dig into that more. Especially if the goal is to be an attractive platform for developers. We should be aware of both what tools are most common, but also what tools people prefer.

Q5: Which API technologies do you use?

 Graph showing which API technologies are being used
Caption: Question 5: Graph showing which API technologies are being used
 Table showing which API technologies are being used
Caption: Question 5: Table showing which API technologies are being used

A healthy mix of API technologies are being used here, but again it may be worth noting that a lot of our Drupal users are using JSON:API by necessity as it is the primary way Drupal is used as a REST API. We shouldn’t ignore that over 50% of respondents are using GraphQL, this may or may not be in the context of Drupal, but it does signify that there may be a desire to use this for retrieving decoupled data?

Q6: Which data fields or properties do you believe are essential to render a menu component?

Question 6 - Table showing responses of which data fields or properties are essential to render a menu component
Caption: Question 6 - Table showing responses of which data fields or properties are essential to render a menu component

A surprising result here is that the Active Trail is not a priority to our users. Menu Hierarchy and Multilingual being the most important means that we need to ensure that we are able to cleanly deliver the menu tree data, along with appropriate translation data.

Q7: What is the best experience you have had when working with menu responses?

This was an open-ended question and received 42 write in answers.

There was some interest in Gatsby. Some narratives included:

A recent menu integration with Gatsby worked well - we accessed menu data via gatsby-source-Drupal and then exported these components using webpack along with their data. This allowed us to use the exact same React footer in pages rendered by Drupal and Pages rendered by Gatsby.

Gatsby, with the `activeMenuClass` and `partiallyActive` features, makes it soooo easy to have an active menu and active trail.

We saw some interest in GraphQL, with responses like: 

On the backend we used the GraphQL Drupal module and declared a schema, following the documentation (https://drupal- graphql .gitbook.io/graphql/queries/menus) On the frontend, using Apollo we would just query the menu and then render that into a custom component.

Using the graphql Drupal module with Next.js. The only thing that we had to do was made a query by menu name to Drupal, the response was an array of items of type { link, label, children: [] }

Writing a custom GraphQL resolver for Drupal 9 that returns exactly what I need.

Which highlights that a handful of respondents have been reaching for GraphQL in order to provide a simple data -> frontend flow.

The answers to this question highlight that right now, in order to manage menus using Drupal in a decoupled scenario, people are invariably crafting their own solutions. That people have been able to make things work. And that at best the experience has been fine, and at worst it’s frustrating. People have used a range of approaches including; Using data available in the existing JSON:API output, custom GraphQL resolvers, putting the content of a menu into a custom block and consuming that block, using the jsonapi_menu_items module in contrib, and hard-coding menus into the front-end, and more.

This indicates that there is definite potential for standardization and providing a built-in solution so that people don’t have to reinvent the wheel with every new project. And, some people mentioned having already started work on their own reusable solutions to this problem.

Another common thread in these answers is that most people’s custom solutions involved creating the data in Drupal in some way (custom block entity, GraphQL resolver, jsonapi_menu_links) so that the front-end application could consume the entire menu in a single response that contained titles, links, and hierarchy. This desire to be able to construct a single menu object in the UI was also mentioned in answers where people talked about non-Drupal menu building experiences.

Netlify Menus, set a collection of type Menu, and edit the links. That's the easiest way. For Drupal is not a big deal but separated fragments have to be done in order to pull just those entities.

Q8: How do you use API data to build a Menu Component?

Question 8 - Table showing responses of how do you use API data to build a Menu Component
Caption: Question 8 - Table showing responses of how do you use API data to build a Menu Component

Early analysis of the results, we found this to be a trend which has held. This is quite surprising, given the bounty of available frameworks out there. But it perhaps illustrates either the challenging nature of adapting drupal menu data to a framework, or the demands of clients that need more flexibility than frameworks are able to provide?

Q9: What expectations do you have for Documentation, when working with a headless CMS?

Question 9 - Table showing responses of expectations for Documentation, when working with a headless CMS
Caption: Question 9 - Table showing responses of expectations for Documentation, when working with a headless CMS

We think that quality documentation will be an important part of improving the experience for JavaScript developers consuming data from Drupal APIs. And are already planning on making that a focal point of the work we do in this initiative. Based on the results we clearly need to make sure that code snippets and a getting started guide are part of whatever we create.

Based on the result of question 3, it seems that we should also attempt to provide these code snippets in both React and Vue variations.

Q10: Describe the biggest challenges you encounter when building a project with Decoupled/Headless CMS

This was an open ended question and received 63 responses.
What appears to stand out here are the words Drupal, data, menu, and routing. This probably indicates that the data and routing are challenges that we will want to make sure we address. Drupal and menu are terms that are probably used in a majority of responses without negative or positive context, per se. We could dive into some of the direct response texts in order to attain a better idea of the context in which these terms are being used.

CONCLUSION

The survey results indicate that people view code snippets, and a getting started guide, as a critical part of the documentation we produce. We should try and further define what awesome examples of these look like so we know what to aim for.

We’re aware that the results of this survey for the most part only reflect people who are already engaged with the Drupal community. Since part of this initiative’s goals are to help make Drupal a more attractive platform for JavaScript developers who are not already part of the Drupal community we’ll have to make sure and do the work of connecting with those people. It’s important that their voices are heard and that we don’t build solutions in an echo chamber.

Apr 02 2021
Apr 02

Mike and Matt discuss various aspects of Lullabot's Support & Maintenance Department, and how it differs from Client Services, with Director, David Burns, and Project Manager, Cathy Theys.

Apr 01 2021
Apr 01

This year’s keynotes highlight the power of the global Drupal community to make a difference in some of the most crucial issues of our time and the future of digital experiences.

PORTLAND, ORE. (PRWEB) APRIL 01, 2021

The Drupal Association is planning a blockbuster event for DrupalCon North America, the most widely attended Drupal event, 12-16 April from 15:00 - 19:00 UTC daily. This year’s all-virtual event brings together Drupal experts, enthusiasts, end-users, and the broader open source software community to connect, collaborate, and contribute to advancing Drupal - the world’s leading open source digital experience platform (DXP).

Heather Rocker, executive director of the Drupal Association states, “Our global community of developers, marketers, and business leaders come to DrupalCon to connect, learn about the experiences of their peers, and share their own expertise. DrupalCon participants also benefit from the opportunity to learn from our keynote and featured speakers. This year, those topics include the role of open source in schools to close the digital divide, the importance of allyship in developing diversity and inclusion, building successful mentorship for people of color in tech, and understanding digital rights as human rights.”

Featured keynotes will highlight inclusion, closing the digital divide, and the Drupal platform’s future.

Sheree Atcheson, Global Diversity, Equity & Inclusion Leader
Allyship—the key to unlocking the power of diversity
Monday, 12 April 16:10-16:40 UTC
Atcheson, an industry-leading voice on diversity and inclusion in tech, will talk about the importance of intersectional allyship in creating inclusive environments and technology. She’ll offer tips on how everyone in any role can actively consider, champion, and advocate for others in their work and be more inclusive in their day-to-day lives.

Atcheson has been named one of the UK’s Most Influential Women in Tech and has received multiple international awards for her work to advance diversity and inclusion in the tech industry.

Dries Buytaert, Founder, Drupal
Driesnote
Wednesday, 14 April 16:30-17:50 UTC
A much-anticipated highlight of DrupalCon, Buytaert, Drupal’s founder, will deliver his annual talk celebrating Drupal successes over the past year, outlining the state of the Drupal project now, and offering his thoughts on what’s next.

Buytaert is the original creator and project lead for Drupal, an open source platform used around the world to build websites and digital experiences, as well as co-founder and chief technology officer of Acquia, a venture-backed technology company.

Stuart Keroff, Social Studies and Technology Teacher, Aspen Academy
School needs open source, now more than ever
Friday, 16 April 18:20-18:50 UTC
Technology educator Stuart Keroff, founder of the first two middle school Linux clubs in Minnesota, has spent the last 10 years guiding middle school students to use open source as a tool to close the digital divide in education. He and his students will share how they used open source software to recycle computers for their fellow students during COVID-19 school closures.

To date, he and his students have provided over 600 Linux computers, helping students learn while also saving money for their schools.

Additional Featured Speakers Include (confirmed as of 31 March):
Byron Woodfork, senior software engineer, Segovia Technology
Heather Meeker, founding portfolio partner, OSS Capital
Nani Jansen Reventlow, director, Digital Freedom Fund
Nuritzi Sanchez, senior open source program manager, GitLab, Inc.

The global pandemic has increased pressures around work-life integration, so DrupalCon 2021 is built with flexibility in mind. Rocker added, “Each day is streamlined with 4 hours of live content, and the virtual setting allows easy participation in the featured keynotes, small group discussions, and interactive skill-building sessions most relevant to you”

How to register
DrupalCon North America 2021 will be held 12 - 16 April 2021, with events held daily from 15:00-19:00 UTC. Tickets are $245 per attendee and include full access to the higher education, healthcare, nonprofit, and government summits held throughout the month of April. Registration details, additional speaker and session information, and scholarship applications are available at https://events.drupal.org/northamerica2021

DrupalCon is brought to you by the Drupal Association in collaboration with a team of dedicated volunteers and sponsors, including Diamond Sponsors AcquiaPantheon, and Platform.sh.

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

###

For more information contact Heather Rocker, [email protected]

Apr 01 2021
Apr 01

The last year has highlighted to us all how important it is for the global community to come together and solve problems. We rate ourselves highly at ComputerMinds, and figure it's time to share and stretch our abilities to the full. So I'm here on this special day to announce that we are branching out beyond just resolving bugs on websites, to fixing any kind of bugs in any problem space. There's so much market potential, we're really quite excited at the possibilities for bringing innovative solutions to the world!

Medical bugs

The ugliest bug of them all, COVID-19, has been such a terrible challenge for us all. We've been inspired by the countless heroes across the world who have stood up in the face of it, so we want to help too by putting our services to more significant tests than just Drupal websites. We have continued to serve our clients during the pandemic as well as we can so far, but now it's time for us to help with other kinds of bugs. We'll start with the common cold and flu, and work our way up to the bigger beasts. We believe in our approach and that our experience will propel us to find solutions. To help us with this, we'll team up with the best in the business with offices in Bristol and Coventry.

Pest control

Inspired by the wonderful pest control hawk that flies around our Coventry office, we will help fix your bug problem. Our Drupal experience has taught us to search for the root problems and to stop at nothing to go down debugging rabbit holes - so we are perfectly suited to this industry too. Unwanted animals and insects, beware! But we've also got a strong ethical heartbeat too - we always want to do things the right way, after all. We'll continue to work with existing partners to campaign for sustainable pest control, and against unnecessary culling.

Lifestyle bugs

Life coaching is a blossoming market. We believe too many rush ahead to give advice about making lifestyle changes, before pausing to eliminate 'bugs' in people's lives that hold them back. Too many web projects need rescuing because of the issues that hold them back - and these are often much deeper than mere software issues, but go down to 'people' problems. We're ready to bring our experience from these situations to help people become the best versions of themselves. We recognise that in some scenarios, people need to give themselves more slack in their expectations, whilst others need to the right pressures applied to improve performance. Sometimes proper recovery from major trauma must be prioritised; for others we are well-placed to encourage physical exercise for all the benefits and widened perspective it brings; for others laziness is the 'bug' we will identify and help clients overcome!

Engineering

We've already been solving problems in electrical engineering and patching up domestic engineering horror stories. We've worked with some genuine motor engineering history beneath us. So now we're opening up to offer our services to the great people of Bristol and Coventry. Our cities are well known for engineering feats, so we are keen to partner with the local firms that are facing bugs in their work. Our contribution towards the Coventry Motofest event demonstrates our passion for great engineering - the traditional kind, not just software engineering.

Software problems - not just Drupal

Drupal will always be our specialism, but the knowledge gained over the years from those projects gives us plenty of wisdom for any software project. We can already offer consulting for commerce websites built on other platforms. You probably already knew that we have great experience in building websites with GatsbyJS, and native mobile apps in other technologies. We are ready for you with all sorts of advice that can be applied to nearly any web project, whether that be advice on analytics, A/B testing solutions or development methodologies. But we're not limiting ourselves to the internet either any more - bugs will always be found in all kinds of software!

So what are you waiting for? Find out how we can help fix your bugs!

Apr 01 2021
Apr 01

One of the most annoying errors on websites are broken links, going nowhere or showing completely different content than expected. Neither Internet users nor Googlebot like them. The way to avoid incorrect links in Drupal is to use the Redirect module.

The redirects created by this module are extremely useful when there are changes being introduced to the URL structure of the website - both global ones and those caused by simple editing of individual content. Redirects ensure that the user will always find what they are looking for, even if the URL is no longer valid.

Dates

The module was first made available in 2006 by Moshe Weitzman in a very simplified form. The first alpha version was released in 2010, and a stable version was released for Drupal 8 in 2017. For several years Redirect has been developing much more dynamically, with the support of the Drupal.org community.

Popularity

Even the lack of a stable release for Drupal 7 didn’t discourage web developers from using the Redirect module. According to the official statistics, it’s currently used on over 260 thousand websites, 45% of which use Drupal 8.

The official usage statics for Drupal Redirect module

Module's creators

The module is being looked after by three programmers:

The last few releases had a lot of support from other Drupal.org users. So far, over 110 people have contributed to the creation of the module.

Purpose of the module

The Redirect module is used to create URL redirects within Drupal. Thanks to it, you can redirect the user from one address within the website to another. Note that there is a big difference between a redirect and an alias.

  • An alias is the "user-friendly" URL of the content that you see in the address bar of a web browser. If you won't define an alias for a given subpage, it will have a default address like “/node/123” or “/ taxonomy/term/456”.
  • A redirect is a rule that's triggered when you reach a given URL address. The rule specifies the target address the user will be redirected to, the language for the redirect, and the type of HTTP code returned. The target webpage will only appear in the browser's address bar when there are no more redirects to be carried out.

The URL redirects are primarily used to improve the linking structure within a webpage. Redirect, however, has a few more interesting applications resulting from the fact that in the version for Drupal 8 it received some of the functionalities of the Global Redirect module. I’ll mention them later in this article.

Unboxing

You can download the Redirect module from the Drupal.org website. The recommended installation method is to use the Composer command:

composer require drupal/redirect

You can find the module settings panel by going to Configuration → Search and Metadata → URL Redirects.

Module's use

The main element of the module's configuration is the list of redirects:

The list of URL redirects in Drupal Redirect module

To add a new redirect, select "+ Add redirect" and then fill in the necessary information, i.e. source address, target address, HTTP code and language.

Adding a new URL redirect in the Redirect module

It's good to explore the seven available HTTP codes. This is because they greatly affect the SEO. You will definitely need:

  • 301 Moved Permanently - the requested page has permanently changed its address. This is an important signal for search engines, which remove the previous page address from their resources and replace it with the new one.
  • 302 Found - the requested page is temporarily available under a different address. This code is useful in a situation where you test changing the linking structure on a webpage, but you want the change to be noted by search engine robots.

Other available codes are:

  • 300 Multiple Choices - there is more than one way to process the given query (rarely used, e.g. for processing different video formats).
  • 303 See Other - the response to the request is under a different address (used e.g. for POST requests).
  • 304 Not Modified - information for the browser that the webpage hasn’t changed since the last visit and it can be loaded from the cache.
  • 305 Use Proxy - the requested webpage is only accessible via proxy.
  • 307 Temporary Redirect - same as 302, but with the assumption that the HTTP method can't be changed.

Additional options

When you've mastered creating URL redirects, check the "Settings" tab. You'll find there two important options that will help you achieve better results with Google.

  • Automatically create redirects when URL aliases are changed - be sure to select this setting. It'll help you keep the webpage clean in the case of changes to internal linking. When you modify any alias on a webpage, a redirect from the old address to the new one will be automatically created.
  • Enforce clean and canonical URLs - this is the option that convinces many developers to choose the Redirect module. It redirects the user to the canonical address of the given webpage, so that they won't stay under a working address like "/node/123". This setting was available in Drupal 7 through the Global Redirect module.

Hooks and integrations

The module provides the following hooks:

  • hook_redirect_load() - launched when loading an array with redirects, allows you to add new items to it,
  • hook_redirect_load_by_source_alter() - used to modify redirections for a given source address,
  • hook_redirect_prepare() - changes the form of a given redirection in the module's administration panel,
  • hook_redirect_alter() - allows you to change the settings of a redirect just before it is triggered.

In addition, the Redirect works with the Pathauto module. It's a very harmonious tandem for managing creating redirects when changing page aliases.

Summary

The ease of creating and handling redirects is an important feature of a professional CMS. The Redirect module does this very well. It’s a stable solution that has been developed over the years. I recommend using it in any Drupal development project.

Apr 01 2021
Apr 01

As expected, Drupal 9.1 was released on schedule at the closure of 2020. We have already talked about the Drupal 9 release and how it’s a testament to the predictable and reliable nature of the Drupal release cycle. Drupal 9.1 takes a step forward by adding more features and releasing them as predicted.

In this blog, we will be discussing the new improvements and more that will follow. 

Is it worth upgrading?

The Drupal 9.1 stable release was out as expected on Dec 2nd, 2020. We previously advocated that if you are on Drupal 8.9, you needn’t hurry to upgrade to Drupal 9.0 as you would not see many new features. But that’s changed.

Drupal 9.1 adds exciting features and updates along with support for PHP 8 (we have previously written about making Drupal 9 compatible with PHP 8).

It’s also worth upgrading as Drupal 9.1 brings significant changes in the user interface for both sighted users and assistive technology.

New features

Olivero theme

The much-awaited beta experimental frontend theme Olivero has been added to the Drupal core. As a replacement to Bartik, this is a modern and clear theme planned to become the new default Drupal theme later.

This particular theme is named after Rachel Olivero (1982-2019), the head of the organizational technology group at the National Federation of the Blind. She was a well-known accessibility expert and a Drupal community contributor.

Additions to the Claro theme

Claro was added as an experimental theme in Drupal 8.8. And now, Drupal 9.1 has added designs for various key pages like the extensions administration page, views administration, and status report. Also, the media library received Claro styled designs too.

Composer 2 and PHP 8 support

Drupal 9 fully works with Composer 2, and it is strongly recommended to update. Many of the popular plugins have also been updated. If the one you use doesn’t have updates, please help the plugin author with a PR to add the support (it’s quite easy). The new release comes with a significant improvement in performance and also reduces memory usage.

Drupal 9.1 has added support for PHP 8. PHP 8 brings in a lot of newer languages, and even though Drupal core isn’t using any of them (it still supports PHP 7.3), you could use features like union types and more in your custom code. Further, it’s likely that PHP 8 could be a requirement for Drupal 10 due to release in 2022.

Additionally, the user experience has been improved by making the content load faster as the images rendered by Drupal with known dimensions will now be set to lazy-load automatically. 

How to update from a previous version of Drupal

Now, this begs an important question: how will the current users of Drupal 7 or 8 migrate to Drupal 9.1? And also, if users have already migrated to Drupal 9, is there anything for them to execute with this release?

Every version of Drupal demands a different approach to migration. The idea is to pick the right Drupal migration strategy. Let’s look at how to migrate from different versions in this section. 

Upgrade from Drupal 7

Drupal 7 users can easily continue to migrate to Drupal 8.9 or migrate to 9.0 or 9.1 directly. Migrating directly to Drupal 9/9.1 will help them skip a step. The upgrade path for multilingual sites remains stable in Drupal 8.9, 9.0, and 9.1!

For more on how to upgrade from Drupal 7, check out the ultimate guide to Drupal migration

Upgrade from Drupal 8

For Drupal 8 users, there’s still time to step up to the latest 8.9 version until the end of Drupal 8, i.e., in November 2021. The bug fixes will continue, and the next one is scheduled for January 6, 2021. 

Sites on Drupal 8.8 will no longer receive security coverage. This means moving to Drupal 8.9/9 becomes crucial from this update onwards. 

According to Drupal.org, of the top 1000 most used drupal.org projects, 85 percent are updated for Drupal 9, so there is a high likelihood that most of the modules and themes you rely on are compatible.

Upgrade from Drupal 9

Drupal 9.1 is a minor release of Drupal 9. It can be updated from Drupal 9 versions for utilizing these new features without breaking backward compatibility (BC) for public APIs. While Drupal 9 will keep requiring Symfony 4, Drupal 9.1 has adjustments required to support Symfony 5 already. 

All these updates are underway to make Drupal 9 forward-compatible with Symfony 5 and 6 (not yet released). And also, as Drupal 10 is planned for mid-2022, these new upgrades target an excellent growth curve.

Running the update

We will only talk about updating from Drupal 8.9 or Drupal 9 in this section. Updating multiple versions is possible but needs additional care and consideration, which we won’t cover in this section.

  • First of all, if you are already using the Olivero theme in your project, remove that by running this command. We need to do this as Drupal 9.1 includes Olivero in the core.

$ composer remove drupal/olivero

  • To begin an upgrade from Drupal 8.9 or Drupal 9, run the following command:

$ composer require drupal/core:^9.1
drupal/core-composer-scaffold:^9.1 --update-with-dependencies

  • If your project is using drupal/core-recommended, use that instead of Drupal/core in the command above. Also, for the above, your project must be using the recommended Drupal Composer template. It is quite likely that the command might throw some dependency related errors. 

Since there are a wide variety of possible dependency issues, we won’t cover everything here. But to get started, try replacing the --update-with-dependencies flag with --update-with-all-dependencies flag in the command above and try again.

Drupal 9.1 seems to be a promising update for users ready to take the plunge. If you are still not sure, give us a chance to convince you why upgrading to Drupal 9 is crucial now.

Share your Drupal 9 experience with us and watch this space for more insights!

Apr 01 2021
Apr 01

With the launch of Drupal 9 in June 2020, the topic of Drupal migration is fresh on everyone’s mind. We will be delving deeper into the nitty-gritty around the topic in this blog. 

Migration is the process where the content from the old site, converted into the desired format and is saved in the new site. Sometimes, migration is a simple activity of mapping the source content to the destination content types, and sometimes, it is a bit more complicated.

Let's take a comprehensive look at the Drupal migration process in context to the recently launched Drupal 9, and what’s involved in migrating from different versions.

Drupal 9 is here, and regardless of being on Drupal 7 or 8, you can start preparing to upgrade. Find out how the migration process will affect your site and how to prepare!

01. Drupal 7, 8, and 9

02. Migrating Then and Now

03. Drupal to Drupal Migration

04. Migration from external sources

05. What’s More?

 

Drupal 7, 8, and 9

Drupal has earned a reputation as a great choice for enterprise-level websites and web applications. Drupal 7 was launched in 2011, and its improved JavaScript and CSS optimization made it so popular that a large number of businesses are still on it. 
 

Introduction of Drupal 8

Drupal 8 was introduced with numerous benefits, boasting extensive support for accessibility standards, with Semantic HTML5 that creates more usable interactions and adopts more WAI-ARIA practices, and much more.

Find out what to look for in Drupal 9 based on what we saw during the Drupal 8 journey and why migrate to the latest release.

Drupal 8 also said goodbye to PHPTemplate and rely on readable code when theming with Twig. However, these technical advancements came with a bit of a migration challenge.  
 

The Transition

It’s no secret that the migration process from Drupal 7 to 8 involved a number of challenges. Many questioned the need to migrate from Drupal 6/7 as they were hesitant about the migration process itself. The community has taken a huge leap in the migration process from Drupal 7 to Drupal 9. 

Read about the importance of migrating to Drupal 9 for Drupal 6 & 7 users and the consequences of not migrating to Drupal 8 before its end-of-life.

The infamous Drupal 7 to 8 migration challenged teams' technical capabilities and relied on the business priorities too. However, the Drupal 8 to 9 migration has no such hassles. If you are at the latest version of Drupal 8, then transitioning to Drupal 9 is very similar to a minor upgrade. 

Migrating Then and Now

The most important part of migration is planning and preparing. As a business, you should be able to assess the feasibility of performing a successful migration. To give an overview, it starts with analyzing your source data, managing important files and content, lots of testing, and so on.

The community recommends updating the core to the latest version available to ensure the site’s security and uninterrupted functioning. Using the dependency manager for PHP, Composer, you can update and install packages (modules) in Drupal.

Drupal to Drupal Migration

While moving your Drupal 6/7 site to Drupal 8, most of your time would be spent working in the Migration or Migration Group config. Also, you’d want to declare the different Process Plugins to be used and the Destination Plugins for all of the core entity types included in Drupal core. 

Drupal has reached the highest level of scalability and efficiency with object-oriented code, the latest PHP standards, more unified APIs to add power to your site. 

The entire Drupal 8/9 content migration process is also a brief series of easy steps and offers greater flexibility to tweak the content architecture.

Learn the importance of data and how to execute the content migration with a plan and available modules.

Migration from external sources

If you are on a non-Drupal CMS, like WordPress, then the process starts with Setup Migrate Demo Site and Source Data for data migration. The well structured Drupal 8 makes the execution easier and manageable. An average Drupal developer will have no issue understanding the database structures of both sites, and they can write a series of SQL queries that copy the content from any non-Drupal database to the Drupal database.

Also, there are contributed modules to migrate your non-Drupal website to Drupal. For example, the Migrate API provides services for migrating data from a source system to Drupal 8. Even the Drupal theming is a breeze now with the new Twig template engine. 

What’s More?

Drupal 7 and Drupal 8 are reaching end-of-life in November 2021 and 2022, respectively. This will leave Drupal 9 as the standalone version in the community with support. It won’t be too long before Drupal 10 makes an entry after that, so do make sure you complete your migration well in time.

Read about how we migrated millions of content items to Drupal for Lonely Planet. Axelerant team members helped familiarize Lonely Planet’s team with Drupal 8 migration best practices and streamline the migration process.

Apr 01 2021
Apr 01

Though WordPress's easy setup has made quite a name, the Open Source CMS is still far from perfect. There are instances where Open Source users prefer Drupal as their CMS of choice for the advantages it offers. 

For those who are new to the world of CMSs, WordPress is often the natural choice as it is easy to get started with. For those who would like to level up and need more customized functionality from their websites, Drupal meets these needs well. 

Drupal Vs. WordPress

Both at par with strong arguments at their corners, Drupal and WordPress have often locked horns in the CMS space. In fact, this is one of the most searched topics online among users who are wanting to enter into the Open Source space. And since pros and cons vary depending on the user’s context, there is never a clear winner. 

Let’s first look at the advantages Drupal offers over WordPress. 

Advantages of Drupal 8

  • High Security: This is the foremost reason for migrating to Drupal. Several government websites, including the White House’s official website, have been built on Drupal.
  • Easy Search Engine Optimization (SEO): Drupal is a good choice for businesses wanting their websites to rank via SEO. The platform offers numerous modules like Yoast SEO and makes it easy to optimize the site's content.  
  • Speed: A crucial element in holding your audience’s attention is speed. Drupal extends maximum response speed, allowing users to develop high-performing pages with a high-speed index.
  • Flexibility: More choices mean more flexibility to up your website game. Drupal’s custom content types are flexible and make your site unique. As a user, you can employ delicate detailing and integrate useful functions such as Shopify, Twitter, other social media channels, and more to achieve better results. 
  • Multilingual: Since Drupal 8, the multilingual function has been baked into the core itself. For organizations wanting polylingual pages, Drupal offers 100+ languages in its base settings. And as commonly observed, multilingual sites perform much better than websites having English as their primary language. 
  • Taxonomy: Data is the topmost priority for every website owner. From In-depth nesting to categorizing in a common data catalog, Drupal can reliably store a large amount of data. Such capabilities are still not available in other Open Source CMSs.

Advantages of WordPress

According to W3Techs, WordPress powers 37 percent of all the websites on the Internet. Clearly, it is one of the most sought after CMS for enterprises wanting to start up their websites quickly. Let’s look at its advantages:

  • Ease of Use: If you are a non-technical user, WordPress can give your business a good kickstart. It can take you from no website to a good-looking, user-friendly, and functional site in minutes.  
  • Extensibility: With 53,000+ free plugins and 5,000+ free themes, you can transform your website at no extra cost. It’s easy to extend your WordPress site without the need for custom development.
  • Development Costs: WordPress tends to work great for categories like small-to-medium businesses, eCommerce, publications, startups, and nonprofits. WordPress can address these needs at lower development costs. 

While these advantages take over Drupal, there are a few that both the platforms share equally. For example, both Drupal and WordPress offer eCommerce capabilities and are redesigned to be more platform-agnostic. Similarly, you can decouple Drupal as well as WordPress. The drupal site can act as a content API server on the first day itself, while REST API is now bundled in the WordPress core for developers to experiment and use it in a decoupled way.

If you are a small business, WordPress might be the solution for you, but Drupal offers significant advantages for large enterprises. In case you are one of the latter, the next section will guide you through the migration process. 

Migrate to Drupal

Here’s how you can migrate your site to Drupal in a few easy steps:

  • Download the XML file containing “All content” after you log in to WordPress Admin. 
  • Make sure that the XML file is valid using xmllint through the command line. Then make appropriate fixes to the XML file and run xmllint again to ensure that all errors have been rectified.
  • Use the WordPress Migrate module or any other appropriate module to migrate.
  • Log in to Drupal and navigate to the Find Content screen and click on the WordPress Migration tab.
  • Select the valid XML file that you saved earlier.
  • Make sure that the data was properly imported and everything is in place. 

Supporting Modules

While these steps will execute the migration successfully, there are other aspects to consider, like exporting content files, URLs, extra files, etc. 

Modules can assist you in completing the migration from WordPress to Drupal:

You are at your discretion to choose between the two leading CMSs. Both platforms have their sets of advantages, as listed above. In case you are still confused, get details on how Drupal 8 changed the WordPress Vs. Drupal debate.

Mar 31 2021
Mar 31

The Web Content Accessibility Guidelines (WCAG) are a series of specifications developed and maintained by the World Wide Web Consortium (W3C) for the purpose of ensuring that websites are accessible for people who have disabilities. Due to technological advances and evolving perspectives on web accessibility challenges that individuals disabilities face, the WCAG is regularly being updated and revised. The current version of WCAG 2.2 was issued on Nov. 30, 2020, and the WCAG 2 Series is coming to an end with a new WCAG 3.0 under development.  

WCAG 3.0 will not undo the previous versions, but will extend and provide greater clarity concerning current guidelines. 

The following are some of the questions that I get asked most frequently concerning the upcoming shift to WCAG 3.0. 

 

What’s the current status of WCAG 3.0?

On January 21, 2021 the W3C published the first working draft of what will become WCAG 3.0. This is just a draft and there is the opportunity now to suggest revisions as the W3C works toward a final version. At this point, there is no set date for the publication of the final draft. 

 

Why are ongoing revisions to WCAG standards considered necessary?

The W3C changes the Web Content Accessibility Guidelines (WCAG) for a few reasons. One is to apply the guidelines to new technologies. Technology changes over time so the WCAG needs to change with it. Another is to move toward guidelines that are easier to understand and allow for greater flexibility. Finally, the W3C is committed to broadening the scope of the guidelines to expand web accessibility by covering a greater depth and breadth of disabilities. 

 

Are there features of WCAG 3.0 that could potentially simplify compliance?

One of the goals of the WCAG 3.0 is to increase understanding of the guidelines. This is accomplished by replacing success criteria with outcomes, techniques with methods and understanding documents with how-tos. While I would argue this is not really a simplification of the WCAG, I do believe by replacing the “grey areas” of WCAG 2.2 with expected outcomes, methods and how-tos the overall feel and functionality of WCAG 3.0 will lead to  guidelines that are easier to understand and apply. 

 

FREE Webinar! Register now for WCAG Now and What’s Next. Get insider insights into what to expect with WCAG 3.0.  April 20, 2021, 11 a.m. CST.

What is Promet’s position on the direction the revised standards appear to be moving in?

The revised standards appear to be trying to place less importance on any one rule, while at the same time attempting to create a more balanced picture of any website in comparison to all of the standards. Rather than the current pass/fail system, WCAG is moving toward a score-based system. Here at Promet, we see this as an important step toward increasing accessibility for all by allowing for a better picture of the true accessibility of a site and drawing attention to any aspects of the site that would make the site completely inaccessible to certain segments of the population. 

If we've achieved Level AA WCAG compliance, will we need to have another accessibility audit? 

It is always recommended that audits be conducted on an annual basis. Websites are rarely static entities, and if content is being added to a site or changes are being made, then an audit for accessibility is advisable -- regardless of the status of WCAG or whether a revised version is being issued. It is important to point out, however, that any content that conforms to the current version of WCAG will continue to conform to the new standards under WCAG 3.0.  

 

At this point, should we just just wait until we see what’s in WCAG 3.0 before testing or remediating our site for accessibility?

While the standards are changing it is always best to do as much as possible now to ensure accessibility. The foundational WCAG concepts (Perceivable, Operable, Understandable, and Robust) are not changing, and remain the basis for both WCAG 2.2 and 3.0. Any accessibility upgrades completed today will be a step toward ensuring alignment with the new standards once they are released. 

At Promet Source, we're passionate about opportunities to make web experiences engaging and inclusive for all. Let us know what we can do for you!
 

Mar 31 2021
Mar 31

Dries Buytaert’s name is known to everyone in the Drupal community. As the originator of the project, project lead, and co-founder of Acquia, Dries has been a pivotal person in the success of Drupal. During this interview, you’ll learn more about some of the accomplishments, accidents, and purposeful decisions that have made Drupal what it is today.

While Drupal is an open source project, based in code, many of the things that have made it the CMS that powers 1 out of every 30 websites, are not the code - they’re also the marketing that convinces new users to try Drupal, and the people who make up the community and own necessary portions of the project.

As part of our series of talks with Open Source Leaders, Tag1 Consulting’s Managing Director Michael Meyers, VP of Software Engineering Fabian Franz, and Yjs founder Kevin Jahns talk with Dries about the origins of Drupal, and how it grew as a project and a community. We’ll also tie back to our Tag1 looks back on 20 years of Drupal experiences 20 years of Drupal series to talk about how community members can be critical to the growth and adoption of an open source project.

[embedded content]

For a transcript of this video, see Transcript: Open Source Leaders - Dries Buytaert - part 1.

Photo by David Becker on Unsplash

Mar 30 2021
Mar 30

The Drupal community is clear about our Values and Principles. Our community promotes behaviors and decisions that support diversity, equity, and inclusion and reduce hatred, oppression, and violence. We believe that safety is an important component of dignity and respect, and we encourage behaviors that keep our community members safe.

Adhering to these values is at the core of ensuring a vibrant and successful open source software community. The Drupal Association will re-evaluate our relationships with any organization that demonstrates they don’t share our commitment to similar practices.

Further, Drupal relies on a well-governed Free Software Foundation (FSF) due to our use of the GNU General Public License (https://www.fsf.org/licensing). We share the concerns that the recent actions of the FSF Board undermine public confidence in its governance and threaten its ability to be an effective advocate for the free software movement. We encourage FSF to make the governance changes necessary to regain the trust of the broader community.

Mar 30 2021
Mar 30

Join the San Francisco Drupal User Group (SFDUG) virtually to network, co-work and socialize with fellow Drupal users.

We opened our April 8 meetup to folks who had sessions accepted at DrupalCon and wanted some space to practice and get feedback. We have 5 speakers lined up with a variety of topics.

General Agenda:

Views cookbook - advanced recipes for every web occasion with Anna Mykhailova, Senior Drupal Architect at Kalamuna
Have you ever wondered how to get the most out of the Views, how to go beyond standard config? Have you ever been confused about Views build cycle, hooks and plugins? This session is going to demystify all of the components, clear the instructions and set you up with the "ingredients" for Views recipes that are suitable for every occasion.

Get Off the Island: What We Can Learn From Craft CMS, Contentful, SquareSpace, and WordPress with Suzanne Dergacheva, co-founder of Evolving Web
Creating a great content editor experience is key to Drupal’s success and to the success of every Drupal website. But to build an intuitive interface for content editors, we need to understand content editors’ expectations and what experience other CMSs are offering. In this session, I’ll demo findings of a study of CMS user experience. We’ll look at Craft CMS, Contentful, SquareSpace, and WordPress. Learn what these platforms do right, and what we can learn as Drupal site builders, developers, and contributors.

Manually Curated Solr Search Results with Martin Anderson-Clutz
Drupal has a mature and robust integration with Apache Solr for enterprise-quality site search. That said, some competing search solutions give editors the ability to manually curate results for popular searches. You'll see how the module is installed and configured, and how easy it is to promote content and manage results, even right from the node form. We'll also discuss the different configuration options, and how they influence the results that will be returned.

JSON:API: 101 Understanding JSON:API in Drupal with Parvateesam Konapala, Solutions Engineer at Pegasystems
The JSON:API module is a fully compliant implementation of the JSON:API Specification. The JSON:API is designed to minimize both the number of requests and the amount of data transmitted between clients and servers. This efficiency is achieved without compromising readability, flexibility, or discoverability.

Teams: joining efforts to maintain projects with Marco Villegas, contractor at adapt
Open source benefits from community collaboration a lot, in the form of contributions of different types, but how sustainable they are may depend on the amount of people around them.
This presentation explores the idea of team maintainership in the Drupal community, looking also at some experiences in other open source projects.

 

SFDUG seeks to provide a friendly, safe environment. All participants should be able to engage in productive dialogue. They should share and learn with each other in an atmosphere of mutual respect. We require all participants to adhere to the Drupal Code of Conduct. This applies to all community interactions and events.

Mar 30 2021
Mar 30

Rain logo updated

The best open source distribution for Drupal just got better! The latest version of Rain University and Rain CMS now ship with Layout Builder pre-configured to make page building faster and easier. So how does it work? Check out below!

Editing Layouts

Now, when you navigate to any page with layout builder enabled you can edit the layout by clicking on the “Layout tab” under Tasks. Alternatively, you can click on the same tab while editing a page.

Rain editor experience with layout builder
Rain CMS homepage

Rearranging Blocks

With layout builder you have an instant preview of any blocks added to the page. That being said, it’s usually easier to move blocks around with preview turned off. Drupal provides a checkbox that makes it simple to toggle preview on or off.

Rain CMS, rearranging content blocks

Rearranging blocks in Rain CMS

Adding Blocks

To add a block to the page click the “Add block” link in any section. Rain CMS ships with 15 block types out of the box that you can easily drop onto the page. Each component has a preview wireframe and label to help the author understand the look and function of each component. 

Rain add block

Adding blocks in Rain CMS

Layout Controls

One of the big benefits of Layout Builder is now you have more control over the layout of a page. Editors can easily add new sections with various layouts where blocks can be placed. Layouts can be customized per project.

adding sections in Rain CMS

Adding sections in Rain CMS

Rain University CMS

The Mediacurrent team has also updated our RainU CMS to ship with Layout Builder. Same great experience, but tailored specifically for universities.

Rain University homepage

Rain University homepage layout

Want to Know More?

For developers, you can download and install Rain CMS with Layout Builder using our Drupal project template: https://bitbucket.org/mediacurrent/drupal-project/src/9.x/. Setup and installation remain the same, with detailed instructions provided in the project README file.

We are also happy to demo Rain University or Rain CMS for organizations interested in partnering with Mediacurrent for your next redesign project. To schedule a free demo, please visit our contact page or chat with us right now (see bottom right corner of the page). 

Mar 30 2021
Mar 30

I am a passionate developer and a mediocre salesperson. Still, I have accepted that our collaboration, Drupal, is about selling goods and services. At the end of the day, organizations need to earn a profit, and people want to be paid. My stepfather said to me once, “a nonprofit is not for profit; people working for the nonprofit need to be paid." This is a slightly cynical statement, but everyone needs money to survive.

Mar 30 2021
Mar 30

Drupal 8 brought about significant architectural changes offering modern techniques to build digital experiences. REST API was one of them and it came shipped in Drupal 8 core. A RESTful API is an API that conforms to the architectural style of REST (representational state transfer). It accesses and uses data via HTTP requests to GET, PUT, POST and DELETE data types. 

In this post, you will be learning more about exposing your API in Drupal 8.

HTTP methods used in REST API

GET : This method is used to read the data from server.
POST : This method is used to create data on a server.
PATCH : This method is used to update the data on the server.
DELETE : This method is used to delete the data from the server.

Exposing API in Drupal 8

The above image describes how REST API requests and gives the response to a client. Initially the client sends the request using HTTP methods. REST API interacts with the database and sends the response in JSON or XML formats.

Now let’s see how it take place in Drupal.

Drupal Modules to Expose your API

Mentioned below are some Drupal core and contributed modules that can help in exposing your APIs in Drupal.

    1. HAL

The HAL module is specifically for JSON or XML, and it provides the serialization plugin.
    
    2. HTTP Basic Authentication

The HTTP basic authentication module provides an authentication plugin which allows us to control access to our API resources based on the HTTP method.

    3. RESTful Web Services

The RESTful web services module handles the resources plugin system as well as defining initial resource routes. A good example of resource plugin can be found in the DB log module which provides an API endpoint for watchdog entries.

Resource plugin is responsible for retrieving the data from the database.

    4. Serialization

The serialization module is responsible for deserializing and serializing request response data.
    
    5. REST UI

Rest UI is a helpful module which exposes our RESTful web services configuration via the admin UI. This way we can configure our API endpoints by editing the YML files.

REST Response - How It Works

REST Response

This image describes the pipeline of the REST response.

According to the image, first the client sends a request, and the request goes to the request handler. The Request Handler is responsible for accepting the request.

The request handler interfaces with the REST module and is responsible for the requests. The requests are then sent to deserialize to normalize the data. 

Then deserialize sends to the request handler. The request handler matches the up the resource with the appropriate resource handler. 

Again, request is sent to the Resource plugin. The resource plugin takes the data from incoming request and retrieves the valid information from the database.

Then the resource plugin returns the data to the request handler and again acts with the serializer before sending as response.

How to configure the REST API in Drupal using Core Modules:

Here are 4 easy steps to configure REST API in Drupal using core modules:

Step 1: Initially, you need to install the core modules which are HAl, Http Basic Authentication, REST Web Services, and serialization module.

Step 2: Next, you need to download the REST UI module and you need to enable the module.

Web Services

Step 3: Next, you need to configure the REST API endpoints as required. To configure, go to Configuration -> REST -> then click on edit of the content row.

REST Resources

Step 4: When you click on edit, you will get the edit window. Configure as required then save the configuration.

Configuration

Example:

If you want to get the response of a particular node, you need to send the request using the postman app with URL - hostname/node/nodeid?_format=json. (If you don’t have the Postman app yet, you can either download it from here or get the web version.)

Postman
Mar 29 2021
Mar 29

Decoupled Drupal is now a fixture of the Drupal community and ecosystem, but it has roots in key software concepts like the separation of concerns. Today, decoupled Drupal is commonplace across the Drupal world, not only at the highest echelons of enterprise implementations of Drupal but also among smaller consultancies beginning to get their feet wet with headless CMS architecture.

From the early days of Drupal's remarkably prescient web services, to the adoption of the JSON:API specification in Drupal core, to the ongoing innovation surrounding GraphQL in Drupal and the Decoupled Menu Initiative, how far have we come? How has decoupled Drupal evolved over the years, what makes it such a compelling architectural paradigm in light of the emerging distributed CMS trend, and why is it still in vogue?

In part 2 of our series on decoupled Drupal, Preston So, the author of Decoupled Drupal in Practice (2018), co-originator of the term progressive decoupling, and Tag1 Consulting's Editor in Chief and Michael Meyers, Managing Director at Tag1, in this discussion of decoupled Drupal’s history and future, and the hows and whys of using decoupled Drupal.

[embedded content]

For a transcript of this video, see Transcript: Decoupled Drupal part 2.

Photo by Markus Spiske on Unsplash

Mar 28 2021
Mar 28

Posted Sat, 03/27/2021 </span>

John Jameson, a digital accessibility developer and colleague of mine, has been working hard for months on a new accessibility module for Drupal module Editoria11y.

Editoria11y (editorial accessibility) is a user-friendly accessibility checker that addresses three critical needs for content authors:

  • It runs automatically. Modern spellcheck works so well because it is always running; put spellcheck behind a button and few users remember to run it!
  • It runs in context. Views, Layout Builder, Media and all the other modules Drupal uses to assemble a complex page means checkers that run on individual fields cannot "see" errors that appear on render.
  • It focuses exclusively on content issues: things page editors can easily understand and easily fix. Editoria11y is meant to supplement, not replace, testing with comprehensive tools and real assistive devices.

John and I are part of a great team that works on Princeton University's "Site Builder" Drupal platform. We've already enabled this module on hundreds of our websites with a positive reception.

John's written up a much more detailed introduction to this module on Princeton's accessibility website.

Mar 26 2021
Mar 26
Protect Drupal web forms from new malware injection methods

We all know that malware can come from everywhere — but now that includes web forms.

Hackers have come up with a new malware injection method to distribute malware through web forms on your Drupal website.

Today Drupal web developers from Drudesk will show you how to resist this and protect your Drupal web forms from new malware injection methods. Read this blog if keeping your site safe is important to you.

Mar 26 2021
Mar 26

Over the last few years, we’ve been seeing a proliferation of digital channels and devices, resulting in the website no longer being enough to adequately reach customers across their customer journeys.

With new trends and technologies enabling multi or even omnichannel digital experiences, digital strategies must adapt as well, especially when considering the accelerated digitalization that’s been going on since early 2020.

In this article, we’ll discuss the key components of strategizing for omnichannel digital experiences, together with the key considerations and tactics for each one. In the second part, we’ll also take a look at some of the main challenges of providing omnichannel experiences at scale and how they can be tackled.

Marketing strategy

Meaningfully engaging with customers in the always-on, highly competitive digital age requires adjusting your approach to marketing. Even businesses used to traditional physical marketing have had to digitalize in the Covid era, and a lot of them are innovating in combining physical and digital initiatives.

This can mean different things for different industries. For example, retail brands may leverage technologies such as VR to bring the in-store experience closer to customers; a digital agency could send branded gifts to clients and business partners. 

Certain conferences that have moved online are doing something similar, sending the “conference swag” by mail to all registered attendees. Another great example brands are using are gift cards, which can be sent digitally hassle-free and then redeemed for a physical good.

So, for a truly omnichannel digital strategy, consider leveraging both digital and physical channels for your marketing efforts, in order to at the same time capitalize on everything offered by digital and balance the digital fatigue from over a year of Covid.

Content strategy

The other key pillar of digital strategy, strongly tied to marketing, is content strategy. Content is at the essence of digital experiences, and one-sided content will have trouble succeeding in an omnichannel world.

Until recently, written content used to dominate the web. However, with the proliferation of digital channels, what kind of content people consume and how they interact with it has fundamentally changed.

While longform written content can still be an effective element of content strategy, we’re now seeing much more video and audio content, the latter being especially easy to consume on the fly. On top of that, a lot of this content is also ethereal, meaning that it’s not meant to provide evergreen value, but rather more of a short-term brand element (e.g. “stories”).

Another example of this short-lived, easy consumable, bite-sized content are infographics, which are able to deliver high amounts of condensed information in a visually attractive package - so, they check all the boxes.

A crucial point to make here is that you don’t need unique topics for different channels - you can repurpose the same content ideas for a blog post, a social media story, and an infographic. The options are endless, and there’s no better time to experiment and take risks than right now.

User & customer experience

Now that we’ve discussed the “digital strategy” part, let’s also focus for a bit on the “digital experience” part of the subject line. UX and CX are vital aspects of the digital, and your digital strategy should definitely prioritize them highly.

In order to provide a great experience to any kind of user, your content must be inclusive of and accessible to everyone. The best way to do this holistically is to employ a human-centered approach to design, which will let you design with empathy and organically incorporate these aspects rather than tacking them on as an afterthought.

One of the best ways to let yourself be guided by the needs and wants of your audiences is to make good use of data to drive your decisions and initiatives. Of course, with great data comes great responsibility, so your usage of data should not come at the expense of your customers’ privacy

Additionally, with mobile often being the primary means of accessing digital content, you should always design following the mobile-first approach, using progressive enhancement to scale up designs on bigger screen sizes. This includes meticulous mobile testing which prioritizes performance and information structure.

Most importantly, your users and customers should have an equally delightful experience no matter on which channel they interact with your brand. The experience you provide should be cohesive and well-integrated to eliminate any possible friction and frustration, and increase the chance of customer retention and loyalty.

Technology capabilities

As we stated in the introduction, a website is no longer enough for an omnichannel digital presence and strategy. One of the best and most integrated solutions is a digital experience platform, which can be proprietary (e.g. Adobe) or open (e.g. Acquia / Drupal).

A DXP is able to integrate and connect all of your different software to have a 360-view of customers. Just imagine - a single platform where your customer data platform, your e-commerce store and any MarTech tools all work together seamlessly.

Because of this tight integration, a DXP also offers ample options for personalization, and there’s just as much a rising demand in well personalized experiences as there is a frustration with poorly executed personalization. An important note to add here: too much personalization can quickly lead to creepiness! You should aim for balance.

Something which DXPs tend to offer out of the box, but can certainly be achieved with a CMS such as WordPress or Drupal, is decoupling the back end from the content presentation layer: so, using one system for data storage and for content creation, and then custom front-end technologies such as React or Angular for presentation on various channels.

This allows you to have a single content hub and push that content effortlessly to the kind of channel which will let it perform best and provide the best experience - essentially hugely simplifying the process of content syndication, which can otherwise prove a major pain for larger brands.

Challenges

Differently colored wooden block puzzle pieces

We’ve already touched upon certain challenges of devising omnichannel strategies under previous points, and we’ll discuss the main ones in greater detail in this section.

Actually, let’s start from the back, with content syndication which we just mentioned under the above point. While a decoupled approach can certainly help with this, it’s not always the go-to solution, especially if you lack the developer capacity for such implementations.

A modern CMS with a good content workflow will typically handle most cases. On the organizational side, a well-connected intranet and a strong, transparent company culture contribute to better collaboration between teams and hence easing publication and creation of content.

All of this should also come in handy with addressing another challenge to delivering great cohesive digital experiences - organizational silos, which are allowed to thrive with an unhealthy, closed-off company culture. 

Silos are actually particularly problematic in a multichannel context - how can you deliver cohesive digital experiences across all channels if there’s no or poor collaboration between the teams responsible for each channel?

The best strategy to minimize disjointed experiences is to have a strong brand, one that’s distinct and recognizable across all the different channels. As we stated earlier, you should also use data to your advantage, but beware of the privacy concerns and limitations that come with the use of data.

A good data strategy will also be crucial in knowing and targeting audiences based on their preferences and browsing and device habits. This is a must if you want to be truly omnichannel; you need to serve your customers where they are and in the ways they want, lest you get replaced by a competitor.

Cause, let’s face it - in an era where basically every brand has gone digital, you either have to be super niche or a visionary not to have competition. The Covid-19 pandemic has only exacerbated this by driving digitalization and giving even more power to the already powerful industry giants.

One way to break through the competition is to employ an “always-on” approach to marketing, where your priority is frequency and timely interaction. But this is a challenge all on its own.

A more surefire tactic which will allow you to innovate and act faster - and actually help with most of the challenges we’re discussing here - is to adopt Agile. Agile will help you improve collaboration while facilitating risk-taking and experimentation; learn more about the benefits of Agile here.

The final challenge or consideration we’d like to address are the peculiarities of specific channels. For example, mobile is widely used, but a lot of poorer countries have slow internet connections - how do you develop and design for that?

In this specific case, it’s convenient that we have native mobile applications, which allow perfectly normal usage without any performance problems or data overage. There are also PWAs, or progressive web apps, which operate on a similar concept of retaining basic functionality even without or with poor internet access.

Data will help you uncover what to prioritize. If you notice that a lot of your users are browsing on mobile from, say, Kenya, you should definitely consider how you can best serve those users.

Another broader example we should mention is voice (e.g. voice search and voice assistants). Voice usage is on the rise due to its convenience, but the user experience greatly differs from the traditional input/text-based one. If your data tells you a lot of your users are searching via voice, you should look at how you can optimize their experience.

So, as you can see, there are quite a few considerations that come with creating a great omnichannel digital strategy; knowing about them beforehand, however, and making strategy and technology decisions based on them will go a long way towards having a future-proof, user-centered strategy.

Conclusion

Person sitting in front of laptop

The omnichannel digital reality is definitely here to stay - if anything, we can expect to see more channels and an even greater use of a variety of devices.

This means that you can no longer put off optimizing your digital strategy for this new state of the industry; the sooner you act, the sooner you’ll be able to reap the benefits of your investments.

We hope this article can serve as a good starting point and you were able to get some useful insights from it. We talk about related topics in many of our other articles, so we invite you to also check out our Business and Experience blog sections for more insights like these.

If you’ve already formulated a great omnichannel strategy, but lack the development capacity to execute on it, reach out to us and we’ll be happy to discuss how we can best help you out.

Mar 25 2021
Mar 25

Find out what's possible with CiviCRM and Drupal 8 and 9. Watch Part 1 of Skvare's training series on getting the most out of the Drupal CiviCRM Entity module.

[embedded content]

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

During this training we cover:

  • What is a Drupal entity
  • CE = CiviCRM + Entity
  • How to install CiviCRM Entity
  • The why and the what of integration possibilities
  • Overview of CiviCRM Entity features
  • Introduction to CiviCRM Entity and Views
  • Introduction to CiviCRM Entity and Rule

Presentation Resources

Additional Resources:

Filed under

Mar 25 2021
Mar 25

DrupalCon North America 2021 is just a few weeks away and we’re excited to spend some time learning, building and connecting with the open source community. The event will have more tips and best practices for upgrading to the latest version of the platform – Drupal 9. There’ll be a ton of actionable advice and success stories from experts in marketing, demand generation, and content development to help marketing teams collaborate effectively and improve results and more!

Join us at the most widely attended Drupal event in the world for an amazing programme that features educational, networking, and contribution opportunities for all. With thought leaders featured daily and industry-specific summits featuring deep-dive discussions into issues relevant to nonprofits, higher education, and government. You don’t want to miss out on all the great opportunities to learn and grow. 

Be sure to check out our session with Amazee Labs Backend Developer, Nick O’Sullivan.

Gatsby is a popular static site generator that uses React, and it’s a perfect match for a decoupled Drupal architecture to create lightning-fast websites. Learn how to utilise Drupal’s exceptional multilingual features to produce a fully localised Gatsby site in Nick O'Sullivan's talk Decoupled Translations with Drupal and Gatsby – on April 13th from Tuesday, April 13 - 1:20 PM to 1:50 PM ET.


Whether you’re new to Drupal or a long-time enthusiast, you’ll find valuable information, skills, and connections you can build on after the event. At DrupalCon 2021, you can learn how to use Drupal from the best and most experienced people in the field. There’s still time – register today
 

Mar 25 2021
Mar 25

A good CMS can be recognised by how it deals with the URL addresses of individual subpages. Convenient linking attracts users from search engines and has a significant impact on SEO. In this article, I'll introduce you to the Pathauto Drupal module, which is used to automate the creation of page aliases.

With this module, you can easily configure efficient, maintenance-free aliases for your content, including taxonomy terms and user pages.

Dates

The first version of Pathauto was released in February 2006 as an add-on to Drupal 4. Stable 1.0 version was released for Drupal 5 in 2007. The current code of this module from the 8.x-1.x branch is the result of a long evolution involving many members of the Drupal.org community.

Popularity

The figures from the official statistics speak for themselves – the Pathauto module is used by over 640 thousand pages. And 32% of these are built on Drupal 8 and 9. We’re dealing here with one of the "essentials", installed immediately at the stage of creating new projects.

Official usage statistics for Pathauto Drupal module

Module's creators

The module is currently being maintained by four developers:

Since the beginnings of the Pathauto module, over 100 people have been involved in its development, creating a total of almost 1,600 commits. The tremendous contribution of the community is further evidenced by over 3,000 reported tasks and bugs on Drupal.org. Unfortunately, many of these remain unresolved.

Purpose of the module

With bare Drupal, you can create URL aliases for individual subpages, but you have to do it manually. If you don't fill in the field with the alias, the new content will have standard, inconvenient addresses like /node/123 or /taxonomy/term/456.

The Pathauto module automates the addition of aliases by generating them according to the template with tokens specified by you. For example, static pages may have a title derivative address (/foo-bar), and taxonomy terms may contain a vocabulary name (/vocabulary-name/foo-bar).

Unboxing

You can download the module from Drupal.org or join the project by running the following command:

composer require drupal/pathauto

After launching Pathauto, go to its settings by selecting Configuration → Search and Metadata → URL Aliases → Patterns.

Module's use

Pathauto offers a broad range of settings for the methods of generating aliases. It also allows you to carry out mass operations on already existing content. I'll briefly describe below the most important options available.

URL address templates

The basic functionality of the Pathauto module is creating URL address templates, i.e. strings of characters containing tokens. Individual aliases are generated based on them when content is being saved.

I'll explain it using the example of a blog. If you want your posts to be available under the address http://example.com/2021/foo-bar.html%20 containing the year of publication and the title, go to the panel Configuration → Search and Metadata → URL Aliases → Patterns and add a new template for the appropriate content type:

Adding a new URL address template in the configuration panel of Pathauto Drupal module

Try to create a new blog post now. It should get the address /2021/foo-bar.html. Note that you can still overwrite its URL alias, however by default it is generated automatically:

Generating URL alias in the Pathauto module

Transliteration

Page titles usually contain spaces and special characters. Pathauto module automatically converts them to the ASCII format separated by dashes. Then, a title like "How to Make Crème Brûlée?" will be replaced with a simpler version – "how-to-make-creme-brulee". The settings for this conversion can be found in the "Settings" tab.

I suggest that you leave most of these options at the default position, but pay special attention to the "Strings to Remove" field. It contains strings of characters that will be removed from the address, including numerous English prepositions and articles. If you create a blog post titled "A Guide To Drupal", you'll end up with an address like /2021/guide-drupal.html, which is not always the desired result.

The other settings allow for very detailed customisation of transliteration in aliases, which is useful for multi-language support. Here you can, for example, decide on how to handle punctuation.

Mass generation of URL addresses

By default, Pathauto only generates aliases when the content is being saved. This means that if you change the URL template, the modification will not be reflected immediately in the aliases on the entire page. Also, after adding a new template, all its content will not get a new URL address immediately.

When creating large websites, it is often necessary to quickly regenerate aliases for the existing content. This is done with the "Bulk Generate" function, which enables mass operations on URL addresses.

Regenerating URL aliases with Bulk generate function in Pathauto module

Be very careful not to accidentally overwrite the existing aliases with newer versions. Here I would recommend installing the Redirect module, which saves the redirects between the old and new subpage addresses.

Removing aliases

The Pathauto module also has an advanced panel for removing aliases. Be very careful when using it. Any changes introduced here are irreversible. You'll probably need the "Only delete automatically generated aliases" option to prevent deleting manually overwritten aliases.

Deleting URL aliases in Pathauto Drupal module

Hooks and integrations

Pathauto from the 8.x-1.x branch allows you to handle any kind of entities with plugins like @AliasType, and also provides some simple hooks:

  • hook_pathauto_is_alias_reserved() - blocks the creation of an alias if it is reserved by another module. In such a case, a number will be added to the alias (e.g. /foo-bar1).
  • hook_pathauto_punctuation_chars_alter() – it is used to add new punctuation settings.
  • hook_pathauto_pattern_alter() - allows you to modify the URL address template.
  • hook_pathauto_alias_alter() - allows you to change the alias after generating it.

When creating your own Drupal modules, you should think about adding an optional configuration for Pathauto to them. This is quite a common practice, for example in the Group module. As a result, the user receives default, ready-made alias templates.

Dealing with URL addresses in Drupal

Pathauto is an extremely powerful module that is used in most of our Drupal development projects. It keeps URL addresses consistent and frees editors from having to manually form aliases. Its usefulness is confirmed by hundreds of thousands of installations reported in the official statistics. I definitely recommend getting better acquainted with its abilities.

Mar 25 2021
Mar 25

It's widely reported that Science, Technology, Engineering, and Math professions are in slated for the highest growth potential in the coming years. To varying degrees, women are under represented in these fields. Latest statistics indicate that women account for 27 percent of all STEM workers in the United States, and a much lower 15 percent of engineers.

While these figures do represent progress -- only 8 percent of all STEM workers were women in 1970 -- many find the needle to be moving forward at a disappointingly slow pace. Far fewer women than men are entering STEM careers, and they exit at a far greater rate. 

There's, of course, a complex set of factors at work here, but the long-term advancement of women in STEM calls for early intervention that helps young girls to get excited about the possibility of a career in STEM, and to believe that the field is wide open and welcoming for them.

At the same time, helping women who are currently in STEM roles to amplify their visibility and their voice, can serve to strengthen both their professional stature and potential to serve as role models. 

Promet Source had the honor of partnering with Lyda Hill Philanthropies on a site that's laser focused on these two related objectives.  The IF/THEN® Collection features 125 women across a wide variety of fields, selected as Ambassadors to serve as high-profile role models for middle school girls.  Using a talent agency approach, IF/THEN® supports the Ambassadors and their inspiring work by showcasing them on a national platform.

Read how the IF/THEN® Collection website is advancing its mission and vision

With an ambitious goal of getting these stories and images of women in STEM careers in front of adolescents wherever there is an opportunity to have an impact on cultural norms -- schools, libraries, museums, community centers and more -- the IF/THEN® team had a distinct vision for their Drupal website

Innovative web design and development solutions that help to bring new possibilities to life for our clients is what we are passionate about here at Promet Source. Let's talk about what we can do for you.

Mar 24 2021
Mar 24

Watch Part 1 of our CiviCRM Entity 3.0 training series.

[embedded content]

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

During this training we cover:

  • What is a Drupal entity
  • CE = CiviCRM + Entity
  • How to install CiviCRM Entity
  • The why and the what of integration possibilities
  • Overview of CiviCRM Entity features
  • Introduction to CiviCRM Entity and Views
  • Introduction to CiviCRM Entity and Rule

Presentation Resources:

Additional Resources:

Mar 24 2021
Mar 24

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

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

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