Upgrade Your Drupal Skills

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

See Advanced Courses NAH, I know Enough
Jul 29 2021
Jul 29

We've been posting blogs about Drupal for over 10 years at OSTraining, and so every once in a while someone finds an old blog post from Drupal 6 or even Drupal 7 and asks a question.  Well that's exactly what happened this week when somebody asked, "How do we display a pdf in the browser with Drupal 9 when someone clicks on a link?"

Keep reading to learn how!

"Hi! This is OSTips from OSTraining.  My name is rod martin, and in this video, I'm going to answer that question.

Actually, it's a really simple answer with Drupal 9. So a few years ago this was a big issue.  Before the Media Manager came along, we were left with modules like PDF Reader (which now really isn't being maintained) or Embedded Google Docs Viewer which is still only in Drupal 8 and hasn't been updated since 2018. Now we have the Media Module that allows us to embed pdfs right on our site! 

  • Click Structure/Content types/Testing/Manage fields

How to Display a PDF in Browser with Drupal 9 & 8

I have just a simple PDF Demo field which is a "media field". 

How to Display a PDF in Browser with Drupal 9 & 8

NOTE: You will need to have installed that over here under the extend menu (see below) - nothing fancy.

DHow to Display a PDF in Browser with Drupal 9 & 8

  • Return to Manage Fields tab
  • Click Edit button
  • Select Document under Media type

How to Display a PDF in Browser with Drupal 9 & 8

  • Click Manage display tab

NOTE: The format is Rendered entity and it is Rendered as Default. That's important!

How to Display a PDF in Browser with Drupal 9 & 8

  • Click Content tab

I have a node in this content type.

  • Click Edit tab
  • Click Add media button

How to Display a PDF in Browser with Drupal 9 & 8

I have one pdf uploaded.

  • Click Insert selected button
  • Click Save button

Now when I click on the pdf link, it's going to open it right up in my browser.  And of course, site visitors can save it from here.

How to Display a PDF in Browser with Drupal 9 & 8

So a difficult thing to do in Drupal 7 has now been brought into core in Drupal 8 and 9 and is now something that's really simple.

Well thanks for joining me again today. This has been OSTips from OSTraining, and I'm Rod Martin."

[embedded content]


About the author

Rod holds two masters degrees and has been training people how to do "things" for over 25 years. Originally from Australia, he grew up in Canada and now resides just outside Cincinnati, Ohio.
Jul 28 2021
Jul 28
Drupal 8 has lot of inbuilt functionality within it, one of the main important features is Configuration Synchronization. It will help us to migrate full setup properly on site deployment. But the main problem is that, According to the Drupal 8 CMI documentation,
Jul 28 2021
Jul 28
In such a time, i want to place blocks in sidebar region with the dynamic weight. It means the blocks should render in different position for each page request. I have searched and tried lots of method but unfortunately i can’t find proper method to do that. So i have decided to do that with some hacky way.
Jul 28 2021
Jul 28
Twig can be extended in many ways; you can add extra tags, filters, tests, operators, global variables, and functions. You can even extend the parser itself with node visitors. In this blog, I am going to show you how to create new custom twig filters in drupal. For example we are going to create a filter to remove numbers from string, will explain with hello_world module. Create hello_world folder in modules/custom/ folder with the following files,
Jul 28 2021
Jul 28
One of the most favourite and  valuable features in drupal is multisite configuration, Drupal 8 provide simple way to create multisite it reduced lots of works. The following steps shows to configure multisite in drupal 8,
Jul 28 2021
Jul 28
I needed a way to check the currect user has permission to view the currect/particular page, Searched lot finally got the exact way, going to show the tricks to you in this blog. Drupal has an api called " drupal_valid_path " , Normally it used to test the url is valid or not. but the trick is that, It also check the user has permission to view the currect/particular page.
Jul 28 2021
Jul 28
Most of the times developers don't like the GUI, It makes feel lazy. Drupal has a tool (Drush) to do some management work from command line. And also the installing the drupal site makes very lazy while doing with browser, The Drush has an option to install the full site with a single command. The Following command will install the drupal in standard method, drush site-install standard --account-name=admin --account-pass=[useruser_pass] --db-url=mysql://[db_user]:[db_pass]@localhost/[db_name]
Jul 28 2021
Jul 28

Drupal 8’s EOL (end of life) is just three months away on November 2, 2021. What does this mean?

No security patches will be provided for Drupal 8 after this date. There is also no extended support for Drupal 8 like there will be for Drupal 7.

You will truly be on your own. And with such a mission-critical piece of software, you do not want to be on your own. 

The good news is that you can avoid being left in the lurch. Start planning your roadmap now. Right now is the easiest it will ever be. It is better to upgrade on your own terms rather than scrambling at the last minute.

Why November 2, 2021?

Drupal 8 has many third-party dependencies, and if one of these dependencies updates to break backward compatibility with previous versions of Drupal 8, then Drupal 8 cannot update that dependency. Eventually, the older version of the dependency will stop being supported by the authors. 

This leaves Drupal 8 in a precarious position. The longer it exists, the more fragile it becomes. The longer it exists, the more the foundations crack. Eventually, the whole thing would need to be demolished.

Drupal 8’s largest dependency is Symfony. Symfony 3, the version Drupal 8 uses, reaches EOL in November of 2021, and moving to Symfony 4 would break backward compatibility with previous versions of Drupal 8.

Supported versions of Drupal must use supported versions of Symfony, which means Drupal must move to a new major version. This is the main reason for the cut-off date.

But wait! Why can’t the Drupal community fork Symfony 3 and maintain that alongside Drupal? Couldn’t we stay on Drupal 8 forever?

Well…no.

Symfony is used precisely because the Drupal community did not want to maintain certain features common to all websites and content management systems. Instead, the community wanted more freedom to focus on what makes Drupal unique.

A lot of work goes into building and maintaining Symfony. Duplicating that effort is not only unattainable but also undesirable.

The Drupal community has supported Drupal 8.9 as long as possible, but now it is time to move on.

Read more about the rationale behind the release schedule and chosen dates.

What happens if I don’t upgrade by that time?

Everything will still work…for a while. Everything might still be secure…for a while. Neither the Drupal nor the Symfony communities will be updating the code your website relies upon.

And eventually, something will break.

Or worse. A vulnerability will be discovered, and you will have no way to fix it.

Or even worse than that. A vulnerability is discovered by nefarious actors and never announced publicly, and you go on using your Drupal 8 website as if everything is fine. But your website has been compromised, or it can be compromised at any moment. You might never know.

The longer you wait to upgrade to Drupal 9, the more effort it will be to accomplish the upgrade. Right now, Drupal 9 and Drupal 8.9 are still very close to being the same piece of software. But that distance will grow with every new Drupal 9 release.

Is there any wiggle room or grace period that is “safe”?

No.

You can go skydiving without a parachute, and you’re technically safe the entire way down. You can even close your eyes and pretend you’re flying. That might even be fun.

But eventually, you have to deal with the sudden stop at the end.

How long will Drupal 9 Last?

Until 2023, at the latest. It might be earlier if another dependency deprecates.

Read the official page on Drupal 9 support.

This is not something to be wary of. Thanks to the new minor release schedule, upgrades to new major releases of Drupal no longer require a complicated migration or upgrade process. Upgrading from Drupal 9 to Drupal 10 should be no more complex than upgrading from Drupal 8 to Drupal 9.

And you’ve already done that, right?

Or at least you’ve already started planning to do that, right?

How do I get started?

Start by making a plan and then start implementing that plan. The best time to start planning is yesterday. The next best time to start planning is today.

If you are busy or are feeling a little overwhelmed, we can help. We have started planning and implementing the transition to Drupal 9 for many other organizations. Contact us today to start the conversation.

Jul 28 2021
Jul 28

Drupal is among the standard Content Management Systems (CMS) used in designing more complex websites. It uses advanced features to aid the developers in designing beautiful websites. It is also known for frequent updates, and the recent update to Drupal 9 is necessary for the marketplace. However, businesses are worried about the approximate cost to migrate from Drupal 7 to Drupal 9. We will discuss this aspect along with various considerations for the migration project.

Why must you Migrate to Drupal 9?

End of life is around the corner

It would be best if you upgraded the CMS at regular intervals. It helps add new features to the website and offers several core modules for better user interfaces. Performance enhancements are another reason you should go for upgrades. Moreover, any security vulnerabilities in earlier versions are also plugged through the upgrades.

It is essential to note that Drupal 8 is reaching the end of its life in November 2021 and Drupal 7 reaching end of life in November 2022, and it is necessary to migrate the website to Drupal 9. Web admins will not receive support or fixes from the Drupal community after this timeline. There are more than 565,000 websites still on Drupal 7 and more than 267,000 on Drupal 8, and they must be migrated in the near future for the sites to receive security updates.

Reasons to Migrate to Drupal 9

There are other reasons for your benefit when you migrate to Drupal 9. The new Drupal version has led to improved performance of the website. Few web admins may be awaiting a stable version of the upgrade, but there are no severe changes in the features. We will discuss some of the new features in detail.

Faster & Better Performance

With search engines preferring mobile responsive websites, Drupal 9 supports responsive images, leading to lesser data consumption. You can define several workflows, and the BitPipe enhances page viewing performance. Moreover, the upcoming versions will only provide a better user experience and faster websites.

Backward Compatible

The earlier versions of Drupal were not compatible with previous versions. However, Drupal 9 is consistent with the earlier version and preserves Backward Compatibility. It will essentially mean that most of the contributed modules in Drupal 8 will be compatible with the new version. The latest version can use the modules, data, and configuration from the earlier version. 

Cleaner Code Base

One of the best benefits of Drupal 9 is that it does not contain any of the deprecated code. Thus, the websites will have a clean codebase, and you must remove the deprecated code from the earlier versions before migrating to Drupal 9. It will help if you gradually remove the deprecated code from Drupal 8, and it will help make the Drupal 9 upgrade simpler.

Easiest Upgrade

Software experts are stating that the Drupal 9 upgrade is easy and is like a breeze. Earlier, the upgrades implied a time-consuming process that led to huge costs. In addition, there were configuration changes and involved content migration and porting modules to allow them to function as needed. One of the key targets for the Drupal 9 release was to ensure easier upgrades in future.

Understandably, future Drupal releases could be such that upgrades would not need major migration activities.

Symfony & Twig Updates

There have been upgrades in the Symfony and Twig software too. As they also see an upgrade, migrating your Drupal website to the new version is necessary. Other dependencies are getting updated too.

The Drupal Migration Cost

Website migration projects can expectedly be time-consuming. First, the migration team must find out the projected issues in the process. The timeline can usually depend on the size of data on your website.

Time Taken to Migrate

As with any other migration project, most web admins are worried about the time of Drupal 7 to Drupal 9 migration. The migration timeline will depend on the amount of data and content on the website. For example, it is estimated that a website without any customized modules and a few content types can be migrated within a few weeks. However, complex websites can take longer to migrate to Drupal 9.

The migration project involves migrating the content and the configuration to a new instance of the website. The content can cover various posts, files, blogs, and articles, etc. Therefore experts analyze and decide on the entire migration process. 

It is essential to take note that the custom modules must be written according to Drupal 9. This activity can take much time during the entire process. However, several techniques can be automated, as there are several modules to help in migration. Manual recreation may be needed too. Some projects may need field mapping while importing the website data present in different formats.

When the data is migrated, the migration team must check for errors and ensure that the correct data has been entered in the fields. Once everything is in order, you can go live with the migrated website.

Cost of the Migration

You must bear in mind that any migration activity can be tedious. It is also difficult to judge the precise estimates of Drupal 7 to Drupal 9 migration. The cost associated with the migration will depend on the content and design of the website. It will also depend on the functionalities involved and the associated custom code.

The migration strategy can be created keeping in mind the website's content, the investments involved, and the timeline. It is very important to appropriately analyze the requirements in the migration process to minimize the risk of cost escalation. Once the various features and functionalities are listed out, the developer can start the migration activity.

As mentioned earlier, it is difficult to predict the time of Drupal 7 to Drupal 9 migration. Some of our quickest migrations for medium-sized websites took around 2.5 - 3 months. On the other hand, a website of high complexity took about 5 - 6 months.

The migration to Drupal 9 is easier once you have migrated to Drupal 8 already. Drupal 9 is mostly like the last minor Drupal 8 release - Drupal 8.9. There are no huge configuration modifications or content migration and requirement to port modules. The new Drupal 9 release was mostly built on Drupal 8 by removing the deprecated unwanted APIs and updating the dependencies.

It is necessary that you update the website to the latest version of Drupal 8. Drupal 8.8 is fully compatible with Drupal 9. Hence, it is suggested to update to at least Drupal 8.8 before the migration. Our Drupal migration experts have the right experience across diverse Drupal projects. We expect that a medium complexity website can be migrated from Drupal 8 to Drupal 9 within 1 month. A high complexity website could take around 2 - 2.5 months to migrate.

Considerations before the migration

Revisit the Functionalities

You must finalize the features that you want on the new site. For example, do you wish to change the newsletters, forms, etc.? Also, it would help if you considered whether you want to make changes to the existing appearance of the website. The decision on migrating whole or part of the content must be taken as well.

Developer Skill Set

Are the developers skilled enough to carry out the migration activities? If they are not, then they must undertake adequate training before setting out with the migration. In addition, they must know about the migration's dependencies and be aware of the core code in Drupal 9.

Compatible Hosting Environment

The migration needs to keep in mind that the hosting environment must be compatible with the new Drupal version. The team must ensure that the required changes are carried out in the hosting environment to ensure a hassle-free upgrade.

Time and Budget Considerations

It is suggested that you understand the time of Drupal 7 to Drupal 9 migration. The timeline must also consider the resting of the new site and checking how the SEO of the new site is working.

Conclusion

Businesses must readily migrate their Drupal website to the latest version. The new version is laden with several valuable features. It is, however, difficult to assess the actual cost of the Drupal 7 to Drupal 9 migration. It depends on the size of the website and the content and features you wish to migrate.

We have undertaken several projects covering Drupal 8 to Drupal 9 migration within 200 hours. So if you are willing to migrate your website to Drupal 9, we are just a phone call away.

Jul 27 2021
Jul 27

DesignHammer has been awarded five dotCOMM Awards in the 2021 competition, including two Platinum Awards, one Gold Award, and two Honorable Mentions.

Our custom TransmetriQ website build and the DesignHammer website have each been recognized with a  Platinum Award in the B2B category and in the marketing/digital agency category, respectively. Additionally, our redesign of the Divers Alert Network website has been awarded one Gold Award in the nonprofit category, as well as two Honorable Mentions, one in the association category and one in the sports/recreation category.

Longtime client Railinc commissioned their third project with DesignHammer for a custom website to effectively reflect the rebranded identity for their commercial product line (TransmetriQ), a website that dotCOMM has now recognized with a Platinum Award. DesignHammer’s latest Gold dotCOMM Award was the result of close collaboration with Divers Alert Network in 2020 to consolidate a number of web properties into a user-friendly WordPress website with a custom theme. In addition to these two clients, DesignHammer took home a Platinum dotCOMM for the 2021 redesign of our own company website.

“We are pleased with the recognition of the new Divers Alert Network website — and we’re thrilled with the improved user experience for our customers and members”

— Bill Ziefle, DAN President & CEO

 

Administered and judged by the Association of Marketing and Communication Professionals (AMCP), dotCOMM Awards is an international competition honoring excellence in web creativity and digital communication. The AMCP is one of the largest and oldest, third-party evaluators of creative work in the world. Other noteworthy dotCOMM award-winning projects from 2021 were commissioned by Duke Energy, NATO, Cornell University, and WP Engine. See the rest of the 2021 dotCOMM award winners.

These five awards bring DesignHammer’s total dotCOMM Awards total to fifteen, since 2017. Previous DesignHammer projects to have taken home awards include work for the Council for Entrepreneurial Development (CED)Highland CompositesInteriors in FlightThe William Blake Archive, the North Carolina Center for Nonprofits,RailincDuke Health, and the Full Frame Documentary Film Festival.

“I’m very proud to hear of our agency's recent achievement and happy to see the AMCP judges have recognized the value of the results we deliver our clients. By earning two Platinum Awards, one Gold, and two Honorable Mentions from dotCOMM, DesignHammer has set the standard for innovation and creativity on the Internet. This award is a testament to the skill, vision, and collaborative effort our team has put into these projects”

— David Minton, DesignHammer Managing Partner

2021 dotComm awards

About DesignHammer

As a full-service web strategy, design, and development agency, DesignHammer has been integrating proven practices and delivering tailor-made technology solutions to help companies and organizations achieve their business goals since 2001. Headquartered in Durham, North Carolina, DesignHammer has been internationally recognized for their award-winning websites and web design & development industry expertise. Using a collaborative development process, DesignHammer’s close-knit team of experienced web strategists, developers, and designers leverage existing software platforms, custom software frameworks, and third-party software integrations to provide client organizations with the best ROI. For more information visit: https://designhammer.com.

Jul 27 2021
Jul 27

This article assumes a basic knowledge of the building of custom modules, the Drupal 8 / 9 Migration system, and the processes behind creating customised migrations from a previous version of Drupal.

One of the more common components of any migration from a previous version of Drupal is the need to migrate files. In Drupal 7 there was a core ‘File’ entity type and on pretty much all of our clients' sites we would also have the contributed module File Entity enabled. This extended the core file functionality and gave the ability to add fields to the file entity, have separate file types, integrate with views and more.

As of Drupal 8.4.x and above, Drupal Core has the concept of a ‘Media’ entity type that allows you to upload, manage and reuse files and multimedia assets. This acts as a replacement for the standard core File entity upload field and once you have configured a Media entity reference field on your entity type, it allows you to reference previously uploaded files from a Media library, instead of having to upload a new file every time.

Internally, a Media entity references a file entity and this process happens automatically for uploads made through the site frontend. When you upload a file to a Media entity reference field that has been set to use the 'Media Library' field widget, Drupal will handle importing the file, creating the entry in the file_managed table, creating the Media entity and then referencing the newly created file in the file reference field on the media entity. You can then reference this newly created media entity in any other media entity reference fields that allow referencing the same media entity bundles as this field.

The Core Drupal 8 / 9 migration of files doesn’t automatically allow you to migrate from Files to Media entities. The core file migration plugin for Drupal 7 to 8 / 9 just provides a migration route for Files to Files, and any auto-generated entity to entity migrations (provided by the migrate_drupal core module) will only support a File reference field to a File reference field. However, we want the ability to migrate into Media entities, so read on to see how to accomplish this with a bit of custom code.

The Process

The process of getting Files migrated as Media entities is a two-step process. First, we need a migration to migrate the Drupal 7 Files into our Drupal 8 / 9 site as Files, and then we need one or more secondary migrations (one per file/media type) to create Media entities from those now-migrated Files.

Creating the custom module

First of all, we’ll need to create a new custom module (if you haven’t already got a custom migration module in place already!). You can name this anything you want - usually, we’d use a project name prefix followed by the name of the module but for this tutorial, we’ll just call the module ‘example_custom_migration’ for simplicity.

example_custom_migration.info.yml

name: Example Custom Migration
description: Includes a custom migration for files.
package: example

type: module
core_version_requirement: ^8.8.0 || ^9.0
dependencies:
  - migrate:migrate

This is a minimal module info.yml file in which we include a dependency on the core migrate module.

Writing the migration source plugin

Next up we’ll need to create our custom migration source plugin. This is the plugin that we will reference in our migration(s) later on. We are going to be extending the core File migration source plugin to give the ability to filter the source files we want to migrate by file type, which we’ll need later on in order to determine which files will be referenced by which Media entity type.

We’ll name the plugin class file FileByType.php and it will live inside of our custom module in the directory src/Plugin/migrate/source. Be sure that the directory structure matches that exactly as Drupal 8 uses the PSR-4 standard for PHP autoloading. For more information about the PSR-4 standard with regards to Drupal 8 / 9 development, read this article.

We’ll start writing the class by extending the core File migration process plugin.

src/Plugin/migrate/source/FileByType.php

We only need to override two methods provided by the File class, query() and fields().

Our query() method override will handle filtering the files by a configured file type that we can pass into the plugin. The fields() method override will include the names of any extra fields that we will be returning in addition to the fields from the base File class.

The query() function

First of all, let's write the query function. The start of the function will call the parent query() method which will build up the query to query the Drupal 7 file_managed table for all files that are not stored under the temporary:// scheme, also providing the ability to only return files for a specified scheme based on the scheme configuration parameter. We don’t need to modify anything about the innards of the parent method so we can just call it here to save having the same code duplicated.

/**
 * {@inheritdoc}
 */
public function query() {
  $query = parent::query();
}

Next, we’ll add our customisations to support filtering the files by a specific file type. Later on, this will be passed in as a configuration option from our migration.

// Filter by file type, if configured.
if (isset($this->configuration['type'])) {
  $query->condition('f.type', $this->configuration['type']);
}

As we are migrating into Media entities, we may want additional data such as image alt and title text values from the Drupal 7 database. So we’ll support (optionally) returning this data as well.

// Get the alt text, if configured.
if (isset($this->configuration['get_alt'])) {
  $alt_alias = $query->addJoin('left', 'field_data_field_file_image_alt_text', 'alt', 'f.fid = %alias.entity_id');
  $query->addField($alt_alias, 'field_file_image_alt_text_value', 'alt');
}

// Get the title text, if configured.
if (isset($this->configuration['get_title'])) {
  $title_alias = $query->addJoin('left', 'field_data_field_file_image_title_text', 'title', 'f.fid = %alias.entity_id');
  $query->addField($title_alias, 'field_file_image_title_text_value', 'title');
}

Later on, when we are writing the migration for ‘Image’ media items we will be including two additional configuration lines in the call to our source plugin, get_alt and get_title. When we write the migration for ‘Document’ media items, we don’t want alt text and title text as they aren’t applicable, so we will omit them from the configuration there.

The finished query() function will look like this:

/**
 * {@inheritdoc}
 */
public function query() {
  $query = parent::query();

  // Filter by file type, if configured.
  if (isset($this->configuration['type'])) {
    $query->condition('f.type', $this->configuration['type']);
  }

  // Get the alt text, if configured.
  if (isset($this->configuration['get_alt'])) {
    $alt_alias = $query->addJoin('left', 'field_data_field_file_image_alt_text', 'alt', 'f.fid = %alias.entity_id');
    $query->addField($alt_alias, 'field_file_image_alt_text_value', 'alt');
  }

  // Get the title text, if configured.
  if (isset($this->configuration['get_title'])) {
    $title_alias = $query->addJoin('left', 'field_data_field_file_image_title_text', 'title', 'f.fid = %alias.entity_id');
    $query->addField($title_alias, 'field_file_image_title_text_value', 'title');
  }
}

If you wanted to add any further logic in this function to return any other field data (your fieldable files may have extra field data that you need!) then you could do so here.

The fields() function

In the fields function, we want to return the additional fields that this source plugin now provides (file type, alt text, title text), in addition to the standard fields the File plugin already provides.

/**
 * {@inheritdoc}
 */
public function fields() {
  $fields = parent::fields();
  $fields['type'] = $this->t('The type of file.');
  $fields['alt'] = $this->t('Alt text of the file (if present)');
  $fields['title'] = $this->t('Title text of the file (if present)');
  return $fields;
}

We first call parent::fields() to get the list of fields from the parent method and then add our additional fields onto the $fields array afterwards. If you were to add further logic to the query() method which returned further additional fields, you would also want to add these here as well.

The finished source plugin

The finished source plugin should now look like this:

configuration['type'])) {
      $query->condition('f.type', $this->configuration['type']);
    }

    // Get the alt text, if configured.
    if (isset($this->configuration['get_alt'])) {
      $alt_alias = $query->addJoin('left', 'field_data_field_file_image_alt_text', 'alt', 'f.fid = %alias.entity_id');
      $query->addField($alt_alias, 'field_file_image_alt_text_value', 'alt');
    }

    // Get the title text, if configured.
    if (isset($this->configuration['get_title'])) {
      $title_alias = $query->addJoin('left', 'field_data_field_file_image_title_text', 'title', 'f.fid = %alias.entity_id');
      $query->addField($title_alias, 'field_file_image_title_text_value', 'title');
    }
  }

  /**
   * {@inheritdoc}
   */
  public function fields() {
    $fields = parent::fields();
    $fields['type'] = $this->t('The type of file.');
    $fields['alt'] = $this->t('Alt text of the file (if present)');
    $fields['title'] = $this->t('Title text of the file (if present)');
    return $fields;
  }

}

Writing the Migrations

As you will hopefully know already, since Drupal 8.1.x, migrations are now Plugins instead of Configuration, which means we can just add them into a migrations folder inside of our custom module. You no longer have to include the migrations as config in a config/install folder inside of your module or worry about deleting and re-importing said config to pick up any changes that were made. You simply need to do a cache rebuild and the changes will be picked up automatically.

The First migration - Drupal 7 Files to Drupal 8 / 9 Files

Create the migrations directory inside of your custom module which will contain this migration and the other ones later on. Then create the file that will contain our migration plugin and call it example_custom_migration.upgrade_d7_file.yml

At this point, the innards of our migration plugin definition will be pretty much the same as the core Drupal 7 migration file plugin. At this point, we are not using our custom migration source plugin that we wrote earlier. The standard d7_file plugin provided by core will suffice to initially migrate all of the files, regardless of their type.

id: upgrade_d7_file
class: Drupal\migrate\Plugin\Migration
migration_tags:
  - 'Drupal 7'
  - Content
migration_group: migrate_drupal_7
label: 'Public files'
source:
  plugin: d7_file
  scheme: public
  constants:
    source_base_path: /path/to/your/drupal7/webroot
process:
  fid: fid
  filename: filename
  source_full_path:
    -
      plugin: concat
      delimiter: /
      source:
        - constants/source_base_path
        - filepath
    -
      plugin: urlencode
  uri:
    plugin: file_copy
    source:
      - '@source_full_path'
      - uri
  filemime: filemime
  status: status
  created: timestamp
  changed: timestamp
  uid: uid
destination:
  plugin: 'entity:file'

As you can see, this is pretty standard stuff for a migration plugin and we aren’t doing anything overly complex yet. This plugin definition will ensure we grab all the files from the Drupal 7 site and migrate them as files onto our Drupal 8 / 9 site.

You may notice the ‘migration_group’ key which isn’t something you would find with core migration plugins. This is an optional key that the migrate_plus module allows you to define in your migration plugin that allows you to group your migrations together and share configuration between migrations. This enables you to then run the migration(s) as a group through both the Migrate UI and through the command-line (Drush). This is a feature we use quite a lot when building Drupal to Drupal migrations! You don’t have to have migrate_plus in order to run these migrations but the grouping stuff is very useful.

Next up, we need to write the migration(s) to turn these Files into Media entities.

The Secondary migration(s) - Drupal 8 / 9 Files to Media

For this bit I’m assuming that you already have created the various media entity types in the site UI for ‘image’ and ‘document’ media types. If you haven’t, be sure to go ahead and create them and if you decide to name them something different you’ll have to update the relevant places in the scripts.

Images

Now we have the file migration in place, we’ll begin by writing the migration for the Image media entities. Create a new file named example_custom_migration.upgrade_d7_file_to_media_image.yml inside of the migrations folder with the following contents.

id: upgrade_d7_file_to_media_image
class: Drupal\migrate\Plugin\Migration
migration_tags:
  - 'Drupal 7'
  - Content
migration_group: migrate_drupal_7
label: 'Migrate Media image entities'
source:
  plugin: d7_file_by_type
  scheme: public
  type: image
  get_alt: true
  get_title: true
  constants:
    source_base_path: /path/to/your/drupal7/webroot
process:
  field_media_image/target_id:
    -
      plugin: migration_lookup
      migration: upgrade_d7_file
      source: fid
    -
      plugin: skip_on_empty
      method: row
  thumbnail/target_id:
    plugin: migration_lookup
    migration: upgrade_d7_file
    source: fid
  field_media_image/alt: alt
  field_media_image/title: title
  status: status
  created: timestamp
  changed: timestamp
  uid: uid
destination:
  plugin: 'entity:media'
  default_bundle: image
migration_dependencies:
  required:
    - upgrade_d7_file

Let’s break this down section by section.

In the source section, you can see that this time we are now using our custom source plugin d7_file_by_type that we wrote earlier. We are also passing in a couple of additional options to the plugin; get_alt and get_title that will enable the plugin to return the additional alt text and title text data that we want for our image media entities.

In the process section we write to the appropriate fields on the media entity; field_media_image/target_id and thumbnail/target_id to save the references to our file, field_media_image/alt and field_media_image/title to save the alt and title values. We also save the standard entity data like our file migration before; status, created, changed, and uid.

The destination plugin we use this time is ‘entity:media’ because we are now creating a media entity, and the default_bundle is set to ‘image’ as that’s the media bundle type we are using for this migration.

Finally, we add a required migration_dependency on our upgrade_d7_file migration. This will ensure that the migration will only run once the file one has fully ran and imported all of the available items.

Documents

The document migration will be pretty similar to the image migration that we wrote above.

id: upgrade_d7_file_to_media_document
class: Drupal\migrate\Plugin\Migration
migration_tags:
  - 'Drupal 7'
  - Content
migration_group: migrate_drupal_7
label: 'Migrate Media file entities'
source:
  plugin: d7_file_by_type
  scheme: public
  type: document
  constants:
    source_base_path: /path/to/your/drupal7/webroot
process:
  field_media_file/target_id:
    -
      plugin: migration_lookup
      migration: upgrade_d7_file
      source: fid
    -
      plugin: skip_on_empty
      method: row
  field_media_file/display:
    plugin: default_value
    default_value: 1
  status: status
  created: timestamp
  changed: timestamp
  uid: uid
destination:
  plugin: 'entity:media'
  default_bundle: document
migration_dependencies:
  required:
    - upgrade_d7_file

The source section is the same except this time we pass in a type of document to our source plugin and as we don’t need the alt and title text data that we needed for the image media, we’ll omit the get_alt and get_title configuration lines.

The process section again is similar, except this time we are setting the referenced file inside of field_media_file/target_id and we also set the field_media_file/display to 1 which will enable the file to be displayed when viewing content. Again, we omit the get_alt and get_title bits and the rest of the configuration here are the same entity properties as before.

We keep the destination plugin the same (entity:media) but the default_bundle is changed to ‘document’.

Before running the migrations.

Before we are able to run our migrations, we need to make sure that your Drupal 8 / 9 site knows how to connect to your Drupal 7 site. If you are already mid-way through writing migrations from Drupal 7 to Drupal 8 / 9 then you will most likely already have this in place, but if not, you need to ensure your settings.php (or settings.local.php - wherever your current site database connection details are present!) has an entry with the connection details to the Drupal 7 site.

e.g. inside of settings.local.php

$databases['drupal_7']['default'] = [
  'database' => ‘your_database_name’,
  'username' => 'your_database_user_name',
  'password' => 'your_database_user_pass',
  'prefix' => '',
  'host' => 'localhost',
  'port' => '3306',
  'namespace' => 'Drupal\\Core\\Database\\Driver\\mysql',
  'driver' => 'mysql',
];

Note the connection key drupal_7 there, in the $databases definition. We also need to ensure that our migration group knows that we should be using this key if it doesn’t already.

If you have already got a migration_group configuration setup as part of a Drupal -> Drupal site migration (you most likely will if you have migrate_plus enabled and have begun work on a migration) then ensure in the shared_configuration section at the bottom that you have the following:

shared_configuration:
  source:
    key: drupal_7

If you don’t have a migration group config already, then create a new one named migrate_plus.migration_group.migrate_drupal_7.yml

langcode: en
status: true
dependencies: {  }
id: migrate_drupal_7
label: 'Import from Drupal 7'
description: ''
source_type: 'Drupal 7'
module: null
shared_configuration:
  source:
    key: drupal_7

Put it into your site’s configuration directory (e.g. config/sync) and import the config.

If for some reason you aren’t using migrate_plus with migration groups then you’ll need to ensure in the source section of each migration plugin we have written earlier that you have

key: drupal_7

in the plugin definition. e.g. (for the document plugin this would be as follows)

source:
  plugin: d7_file_by_type
  scheme: public
  type: document
  key: drupal_7
  constants:
    source_base_path: /path/to/your/drupal7/webroot

Running the migrations

Nearly there (I promise!). Now you have your migration plugins all correct and in place, it’s time to try them out! First, ensure your module is enabled if it isn’t already (either via the extend menu in the UI or via Drush - drush en example_custom_migration).

Next, you can either try running the migrations through the UI (admin/structure/migrate) or via Drush (if you are using the migrate_tools module version 4.x / 5.x and Drush 9.x / 10.3.x OR Drush 10.4.x+ which includes most of the Drush commands the migrate_tools module included..) I’m a Drush man myself, so I’d either run the migrations individually with these commands

  • drush migrate:import upgrade_d7_file
  • drush migrate:import upgrade_d7_file_to_media_image
  • drush migrate:import upgrade_d7_file_to_media_document

or as a group (if you are using migrate_plus with the group support) with

  • drush migrate:import --group=migrate_drupal_7

although if you are writing these migrations as part of a larger migration with other migrations in the group, you’ll probably just want to run them individually to be sure they are working correctly.

All being well, after running the migrations you should find all the relevant files have been copied into your new site’s public files directory and you should be able to see all your lovely files as media entities by visiting /admin/content/media. (Great Job!)

Referencing the media in migrations that previously referenced files

Any migrations that you have previously written that referenced files and fid’s instead of media entities should now be updated. This is a relatively trivial task as the following example details. Please note that the fields you are migrating into will need to be recreated as Entity Reference fields, referencing the Media entity type. If you have let Drupal handle migrating your fields from a previous version then it will have created these fields as File entity reference fields.

This is an example of what part of your process plugin may look like before and after, on an entity migration for an image field named ‘field_images’.

Before (File)

field_images:
  plugin: sub_process
  source: field_images
  process:
    target_id: fid
    alt: alt
    title: title
    width: width
    height: height

After (Media)

field_images:
  plugin: sub_process
  source: field_images
  process:
    target_id:
      plugin: migration_lookup
      migration: upgrade_d7_file_to_media_image
      source: fid
      no_stub: true

And here is an example of what part of your process plugin would look like before and after for a document field named ‘field_documents’.

Before (File)

field_my_documents:
  plugin: sub_process
  source: field_my_documents
  process:
    target_id: fid
    display: display

After (Media)

field_my_documents:
  plugin: sub_process
  source: field_my_documents
  process:
    target_id:
      plugin: migration_lookup
      migration: upgrade_d7_file_to_media_document
      source: fid
      no_stub: true

If your file field in Drupal 7 allows both images and documents, then your field in Drupal 8 / 9 should allow the same. You can reference both media migrations in the process as follows:

field_my_documents:
  plugin: sub_process
  source: field_my_documents
  process:
    target_id:
      plugin: migration_lookup
      migration:
        - upgrade_d7_file_to_media_document
        - upgrade_d7_file_to_media_image
      source: fid
      no_stub: true

Extending further

We have covered the basics on how to get images and document files migrated, but you can (and we have on lots of client’s sites) get this running for Video files as well in a similar manner with minimal changes.

You just need to create another file to media migration plugin for video files, in addition to the image and document ones already made. Ensure that the type of file passed into the source plugin section of the migration is ‘video’ and the default_bundle of your entity:media destination in the destination section is ‘video’. Then you should be hot to trot!

Bonus - How to have a dynamic file source_base_path

You may be wondering, “What if I don’t want to hard code my source_base_path in the source plugin definition of my migrations?”

This is another common requirement we have when writing our own migrations, and luckily the solution isn’t too tricky with a bit of custom code. You may find this useful if you are going to run this migration across different environments (e.g. your dev machine, testing server, production environment when the time comes) and you don’t want to keep having to change your migration plugin files each time.

In your migration source plugin for both the file and file -> media migrations, change

source_base_path: /path/to/your/drupal7/webroot

to

source_base_path: /

You don’t strictly have to do this as we are going to override it anyway but I think having a blank path gives a clearer indication that we haven’t explicitly set one, as we are going to override the value. Of course, you could also have a comment above the line explaining that this will be overridden if you so wish.

Migration Event Subscriber

In order to override the souce_base_path, we’ll create an Event Subscriber in our custom module. This will enable us to subscribe to the appropriate Migrate events and will allow us to modify the data at the correct point in time. For more detailed information about event subscribers, see this article we wrote way back in 2016 ‘Drupal 8 Event Subscribers - the successor to alter hooks’.

You’ll first want to create a services.yml file directly inside of the custom module as well named example_custom_migration.services.yml. This will let us define our migration subscriber so that Drupal knows about it.

services:
  example_custom_migration.d7_file_migration_subscriber:
    class: Drupal\example_custom_migration\D7FileMigrationSubscriber
    arguments: ['@config.factory']
    tags:
      - { name: event_subscriber }

Next, create this file inside of the src folder in our custom module. You can name it what you want really but for this example, we’ll call it D7FileMigrationSubscriber.php.

configFactory = $configFactory;
  }

  /**
   * {@inheritdoc}
   */
  public static function getSubscribedEvents() {
    $events[MigrateEvents::PRE_IMPORT] = 'onMigrationPreImport';
    return $events;
  }

  /**
   * Act on a migration before it imports.
   */
  public function onMigrationPreImport(MigrateImportEvent $event) {
    $migrate_id = $event->getMigration()->id();

    // Inject the correct source_base_path to the file migrations.
    $file_migrate_ids = [
      'upgrade_d7_file',
      'upgrade_d7_file_to_media_image',
      'upgrade_d7_file_to_media_document'
    ];

    if (in_array($migrate_id, $file_migrate_ids)) {
      $source_config = $event->getMigration()->getSourceConfiguration();
      $source_base_path = $this->configFactory->get('example_custom_migration.settings')->get('files_source_base_path');
      $source_config['constants']['source_base_path'] = $source_base_path;
      $event->getMigration()->set('source', $source_config);
    }
  }
}

There is a lot going on here which I'm not going to get into in this article. (The article I linked to above should help explain it all if you aren’t familiar with concepts such as event subscribers and dependency injection!) But the end result of this code will be to swap out the source_base_path in our source plugin configuration to one defined by a config entry named ‘example_custom_migration.settings’ with a key of ‘files_source_base_path’

Finally, all you need to do next is just pop this line into the bottom of your settings.local.php (which should be different per environment) replacing ‘/path/to/your/drupal7/webroot’ with the path to the Drupal 7 site webroot for the current environment.

$config['example_custom_migration.settings']['files_source_base_path'] = '/path/to/your/drupal7/webroot';

This will then allow you to have a different path set on a local dev build, another team member’s local dev build, testing and production servers as well! Neat huh?

Photo by Kaboompics.com on Pexels

Jul 27 2021
Jul 27

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

Credits & Thanks

Thank you to:

About the Sitemap Module

The Sitemap module provides an HTML sitemap that gives visitors an overview of your website. It also displays RSS feeds for blogs and categories.

The Sitemap module makes it easier for visitors to find content and that improves SEO. This helpful page can increase visitor time on site and reduce bounce rate.

Search engines will also crawl the HTML sitemap which, along with the XML sitemap, increases positive exposure for your content.

Install and Enable the Sitemap Module

  1. Install the Sitemap module on your server. (Go here for more instructions on installing modules.)
     
  2. Go to the Extend page: Click Manage > Extend (Coffee: “extend”) or visit https://yourDrupalSite.dev/admin/modules in your browser.

    enabling the drupal sitemap module
     

  3. Select the checkbox next to Sitemap.
     
  4. Click the Install button at the bottom of the page.

Configure Permissions for the Sitemap Module

  1. Click Manage > People > Permissions (Coffee: “perm”) or visit https://yourDrupalSite.dev/admin/people/permissions in your browser.

    drupal sitemap module permissions
     

  2. Select the appropriate checkbox to give yourself permissions for “Administer sitemap” if necessary.
     
  3. Since you want visitors to view the sitemap, you’ll need to select the check boxes to allow Anonymous User and Authenticated User to “View published sitemap”.
     
  4. Click the Save permissions button at the bottom of the page.

Configure the Sitemap module

  1. Click Manage > Configuration > Search and metadata > Sitemap (Coffee: “sitemap”) or visit https://yourDrupalSite.dev/admin/config/search/sitemap in your browser.

    configuring the drupal sitemap module
     

  2. In the Page title field, add the title of the page using some keywords or your site name.
     
  3. Add some text to the Sitemap message field that will display at the top of the page as an introduction to the page listing. This helps the page look more like a natural page on your website, and not just a “sitemap”. You can make this as long or as short as you like.

    drupal sitemap module content configuration
     

  4. Within the SITEMAP CONTENT section, select the appropriate check boxes. You’ll likely want your Main navigation and any other visitor-facing menus along with your primary Vocabularies (tags and categories).

    drupal sitemap module configuration settings section
     

  5. Within the SITEMAP SETTINGS section, make sure the Show titles checkbox is selected.
     
  6. Click the Save configuration button at the bottom of the page.

You can view the sitemap at https://yourDrupalSite.dev/sitemap.

what the drupal sitemap looks like

The little orange icons next to each section are links to RSS feeds. Visitors who want to subscribe to your site and return when you’ve published new content will use that link in their newsreader applications.

Jul 27 2021
Jul 27

Every strategic initiative begins with a vision. Drupal’s success as an opensource project substantially thrives on its vision for strategic initiatives. The adoption of continuous innovation and strategic initiatives since Drupal 7 is what distinguishes it from the rest. With successful past initiatives like the Configuration Management initiative (CMI), the Web services initiative, Layout initiative, Media initiative and more, the Drupal community is all charged up to be working on many more initiatives as you are reading this. 

But what exactly are strategic initiatives? What initiatives are Drupal working on? Who makes them? Why should you care? Read on to find answers to these burning questions.

Drupal Strategic Initiatives

What are Strategic Initiatives?

Thomas Edison – the man who garnered over 1000 patents - had once said in an interview – “I have not failed 10,000 times but have successfully found 10,000 ways that will not work”. Success comes when you embrace changes that can lead you to your end goal. The day you stop evolving is the day you stop growing. Strategic initiatives are typically sparked from a need for a change that guides an organization towards its future goals. It fuels growth and development of a product or organization.

How are Drupal’s Core Strategic Initiatives formulated?

As a continuously evolving opensource project, its strategic initiatives must always result in a breakthrough for Drupal. But how does Drupal’s project lead - Dries Buytaert – come up with these initiatives? 

  • They are backed by solid data. Regular surveys and usability studies are conducted to help build this data. This is usually done after every major Drupal release.
  • Fueled by a vision to build superlative digital experiences focusing mainly on non-technical content authors and site builders.
  • Market relevancy and competitor research is performed to ensure improvements on editorial, developer and customer experiences are delivered.
  • The initiative ideas are validated via community collaboration and discussions.

Initiative Stages

Proposed Stage: This is the beginning stage of the initiative where the initiative is recommended by Dries or the Drupal community members.

Planned Stage: This is when the initiative is nurtured with detailed plans. A strong team of initiative contributors is created who set goals and plans for the initiative.

Active Stage: This stage is where the real work happens, and the initiative comes alive.

What are the current initiatives Drupal is working on?

At DrupalCon North America 2021, the audience witnessed a first-of-its-kind “Initiative days” program where each day was dedicated to one initiative. Here the initiatives were introduced, discussed, and contribution sprints were also held at the end the program. 

  • Decoupled Menus Initiative

This initiative was proposed by Dries during his DrupalCon Global 2020 keynote speech. The goal of this initiative is to build APIs and documentation that can enable JavaScript frontend developers to integrate Drupal menus to the frontend in the best way possible. It also aims at offering content editors and site builders with an easy and intuitive way to build menus on Drupal with very less to no code. However, the broader goal of this initiative is to create a pattern that can be replicated to build various decoupled components, thus making Drupal the best decoupled CMS in the market.

  • Easy Out of The Box Initiative

During a user survey at a DrupalCon in 2019, it was gathered that many users preferred Drupal over other CMSs’ but only after a while of using it. Simply put, Drupal wasn’t as much of a CMS choice of a beginner user as much it was of an expert Drupal user. Which meant that Drupal needed to be more acceptable even at the beginner level. The goal of the Easy Out Of The Box (EOOTB) initiative is to make Drupal easy right out of the box for non-technical users as well. It bundles the three initiatives together – Layout, Media and Claro – to offer unmatched and simplified user experiences.

  • Automated Updates Initiative

Automated updates was one of the highest requested Drupal features in a survey conducted in 2020. The vision of this initiative is to address the challenges faced by small to midsized businesses in updating their Drupal sites manually. It aims at ensuring the website is safe to update and verify updates with package signing. Updates applied should also be able to be rolled back in case of any errors. 

  • Drupal 10 Readiness Initiative

Similar to the success of the Drupal 9 readiness initiative that ensured a smooth and on-time release of Drupal 9 by June 2020, the Drupal 10 readiness initiative aims at guaranteeing a timely release of Drupal 10 by June 2022. Along with an on-time release, the goals are also to get Drupal 10 compatible with the latest versions of the dependencies like PHP, Symfony, jQuery, Guzzle and more. Older modules, themes and other dependencies will also need to be deprecated.

  • New Front-end Theme (Olivero) Initiative

The goal of this initiative is to build a fresh new front-end theme with many improvements than what we had previously in Bartik. Olivero is going to be a modern theme with a positive and powerful look and feel. It aims at offering functionality that can support new features like the layout builder, embedded media and more. It will also be WCAG AA conformant ensuring the theme passes Drupal’s accessibility standards.

  • Project Browser Initiative

The Project browser initiative is at its very early stages – the planning stage. The initiative was proposed by Dries during DrupalCon North America 2021. The vision is to build a project browser that makes it easy for users to find and install modules without using command line. It aims at making module discovery and installation easy and fast.

Jul 26 2021
Jul 26

It’s been 10 years of not only teaching Drupal Career Online; but also working to attract people into Drupal careers as we market and do outreach for our 12-week course. We’ve made presentations to local and state workforce boards, the national workforce association, many Drupal Camp and Con sessions, and correspond with individuals, businesses, potential education partners and field inquiries every week about Drupal, working in Drupal and the DCO from all over the world.  We've become a bit of a Drupal recruiter. 

After a decade of explaining what Drupal is, finding answers, and collecting some pretty good information, we’ve compiled a solid list of Drupal Career Resources, now a fixture on our site. So, in the spirit of our Top 10 List anniversary series, here is a good one to use when you run into someone who you think might be a good addition to the Drupal Community, but needs some insight and background. Let us know if you have any other great resources; and go forth and attract.

#1:  Web Developers and Digital Designers Occupational Outlook HandbookThe facts on web developer careers from the US Department of Labor, Bureau of Labor statistics with a lot of great info., including a description of the job, geographic salary information, as well as future job prospects. 

#2: How do I get a Job In Drupal?The OS Training interview with our own MIke Anello: An oldie but a goody; with links to the audio of the expert-rich Drupal Career Trailhead panel presentation at DrupalCon Austin 2015. 

#3: Indeed Build a Career You’ll Love: Drupal DeveloperIndeed’s career overview, including links to average salaries, geographic statistics, job openings, common benefits and salary comparisons.

#4 Drupal Statistics & FactsA fun piece about Drupal history, facts and how it compares to other CMSs.

#5: Everything you need to know Before Starting a Drupal CareerLondon-based Cocoon provides a good, honest description of the elements, issues and steps to a Drupal Career. 

#6 Case Study: AmyJune HinelineSome inspiration and insight from a DCO alumna, and winner of the Drupal Community’s 2021 Aaron Winborn Award.

 #7 Drupal for DevelopersGreat descriptions and material on the markets and opportunities for developers considering Drupal as a CMS

#8 Drupical.comInteractive map with a calendar of Drupal events all over the world.

#9 DCO Scholarship PageWe can't help but promote the three amazing scholarship programs through Palantir.net, Bounteous and the Drupal Association that are helping to attract more, and more diverse Drupal talent!

#10 Taste of Drupal registrationThe sign-up sheet to attend the Taste of Drupal no-cost mini information webinars that Mike Anello leads in advance of the Spring and Fall sessions of the DCO. Next TOD is August 11!

The deadline to apply for the Fall 2021 session of Drupal Career Online is August 27th, with classes beginning August 30.  

Jul 26 2021
Jul 26

Is there a Drupal 9 community-supported platform for organizing a DrupalCamp or Drupal event? What happened to the Conference Organizing Distribution (COD)? Join us on the 4th Tuesday (tomorrow) of the month at 2 PM EST to help contribute to building the next Drupal Events Platform. Join our Meeting Here.

Earlier this year, the Drupal Event Organizer's Working Group (EOWG), took a page out of the infamous Driesnote’s and announced the three initiatives for the working group to make a priority. The three initiatives are: Getting Started with Drupal, Drupal Events Database, and the Drupal Event Platform. You can read about each of the initiatives here.  

The Drupal Event Platform (DEP) initiative is aiming to solve a challenge for all event organizers, the website. The event website is one of the most important and laborious tasks associated with producing a quality Drupal event. For some events, the website is the main application that helps organize and build the entire experience from collecting session submissions to assigning presentations to the schedule.

The Drupal Event Platform (DEP) initiative is forming a committee within the Drupal Event Organizers Working Group (EOWG) that is looking to reduce the time and resources it takes to create an event website site through the creation of a flexible and customizable website starter kit for event organizers.

Goals

  • Focus the website creation efforts of event organizers on a single open-source platform to reduce duplication of efforts

  • Create an MVP (minimal viable product) that can meet the needs of at least 80% of Drupal events globally

  • Reach and maintain adoption by at least 40% of all Drupal events globally

  • Model for Drupal best practices including accessibility, usability, inclusive design, documentation, security, performance, and internationalization

  • Provide an extensible, modular platform that allows event organizers to choose to use default functionality or build custom components

Join us on the 4th Tuesday of the Month at 2pm EST.

For more information on how to join the meeting visit The Drupal Event Platform (DEP) initiative page today.

Jul 23 2021
Jul 23

Websites are increasingly becoming an essential marketing tool for businesses. It helps companies reach out to a more influential audience at a relatively lower cost and enhance conversion rates. Websites are also used as a means of providing information about the portfolio of solutions provided by businesses.

As competition increases, there is a need to enhance website ranking during a keyword search. Therefore, you must adhere to the best Google ranking factors to ensure your website ranks high during a keyword search. We will take you through some of the Google ranking factors in this article.

Technical SEO Google Ranking Factors

Ensuring that you are adopting technical SEO best practices can be daunting. Therefore, you may take the help of a professional web design and development company to ensure you adhere to the best practices.

Easy Crawling for Search Engines

One of the critical Google search engine ranking factors is the use of a sitemap. It helps a search engine to index the web pages more thoroughly and quickly. It provides better visibility of the web pages to the users. The crawlers can understand the structure of the website better and can ascertain where the pages are located. You can utilize software like Screaming Frog to check the presence of the sitemap.

You must also check the Sitemap section at the Google Search Console to inform you if the sitemap was submitted and the number of indexed URLs. It can also notify you if there are any problems encountered. You can also check the sitemap for errors by using various XML validator tools.

rendering queue

 

The robots.txt file allows the crawlers to understand the URLs they can access on the site. The instructions enable the crawlers to understand the URLs that are allowed or disallowed from being crawled. If you have any pages that you do not wish to be crawled can be mentioned in this file.

The Site Must be Responsive

As the number of mobile users increases, search engines like Google ensure that the websites provide a seamless experience for them. Therefore, website developers must ensure that the website can be viewed seamlessly on all devices by the visitors. If it does not, the SEO rank of your website is bound to fall.

Mobile responsiveness has become one of the critical google search engine ranking factors since 2015. Google has plans to move all sites to mobile-first indexing and crawling. It would mean developers must consider the mobile design, too, as Google would use this version to rank websites. In addition, you can use the Search Console to check if there are any mobile-related errors on the site.

The Page Load Speed Should be Optimal

Are you aware that most of your visitors will wait for only three seconds for a website to load? These visitors will move to your competition and may never return to your site. Moreover, the bounce rate will increase and is an important SEO ranking factor too. You can use various tools like Google PageSpeed Insights and GTMetrix to inform you about the page load speeds.

One of the main optimizing factors would be to identify the heavy images. You must use plug-ins to ensure the photos are of optimal size. If the images are optimized correctly, it can help to increase site speed.

Use an SSL Certificate

Google had come up with an update in 2014 that showed its preference towards secure websites. The update stated that if all other factors remained the same, Google would prefer HTTPS websites. It is mainly as the certificates that install an SSL certificate encrypt the communication exchanged with the visitor's browser. This update is in line with Google’s mission towards a safer internet browsing experience for its users.

The Use of Schema Markup

An essential factor that SEO executives must remember is the use of Schema Markup. It helps the search engine to have a better knowledge about specific sections of the text. It is ideal when you plan to do local SEO. You can also use it to inform Google where your business is located.

You can use it to present meaningful information to Google about a web page. If you use the schema markup intelligently, you can get into Google Knowledge Graph. It also helps in showing up visually enhanced search results for your website. It also supports semantic search and enhances the authoritativeness of your website.

schema markup

On-page SEO Ranking Factors

There are also specific Google ranking factors that are more page-specific.
 
Use of Relevant Keywords

All SEO experts will tell you about ensuring that your website content is written, keeping the relevant keywords in mind. The keywords essentially search terms used by users and form the basis of the content on your website. Most marketers also feel it is a high-impact driver of website traffic and is among the key Google ranking factors. When writing content for a page, always keep in mind that you can have only 4 - 5 keywords on a page. Also, keep the keyword density best practices in mind.

The Need for High-Quality Content

One of the critical Google ranking factors is the high quality of content on the website. The content must be fresh, unique, and helpful for users. While you must ensure it is optimized for SEO, always ensure that it must be valuable for the website visitors. 

You must create original content and always undertake a duplicate check before publishing on your site. It would be best if you considered the length of the content too. While there is no word limit set for the content, it must neither be too short nor should it be too long. Most SEO plug-ins require your content to be a minimum of 300 words. Apart from the content quality, it must be well-organized and structured using proper tags. 

Optimizing the Title Tags and Meta Description

The title tags and the meta description show up on the Google SERP that allows a user to understand the web page's contents. You must ensure that you optimize the content you write here to help you draw more visitors to your website. You can use the keywords here as well.

Google can pull the information to create snippets that preview the content on the page relating to the search term used. You can also use the keywords for the image alt-text, and if you optimize it, you can also move the images higher up during image search. Also, do not use jumbled-up URLs as they are not SEO-friendly. If the URL has a simple structure, is concise, and contains the optimized keyword, it will be easier to rank these pages higher in search ranking.

Off-Page Ranking Factors

The search ranking of your website is also dependent on few entities outside your website. Some of them are other high domain authority (DA) websites, social media, etc.

Use of Social Bookmarking

The foundation of the ranking algorithm requires you to ensure that your website has backlinks from high DA websites. It is an essential SEO ranking factor, and you must also keep in mind that the backlinks must be relevant and related to the content on your website. While you may have backlinks from high DA sites, you must also ensure that the backlinks are fresh. It is because the users prefer the latest news. However, it will depend on the search term used.

The Search Intent

One thing that Google does is that it does not rank the same content for all queries. The ranking also varies according to the search intent of the user. For example, if you are looking for a "how-to" guide, the web pages shown to you will differ when you search for the best gadgets. The content types are also critical for the search engine when it is ranking the web pages. The search engine also checks whether the piece of content covers what the user is expecting to see.

Conclusion

The search algorithm covers various factors that SEO managers must consider ensuring their website ranks high during a keyword search. While the number of such parameters may total over 200, we have covered the top SEO ranking factors believed to be used by Google.

If you are planning to design a new website, you must keep these factors in mind. You can also take the services of a professional web design and development company and discuss with their subject matter experts on these parameters.

Jul 23 2021
Jul 23

As digital experiences become more and more ubiquitous, we’re also seeing a directly proportional proliferation of tools and frameworks for realizing digital strategies. This includes both a variety of differently specialized tools as well as very similar competitive tools with negligible differences.

How, then, do you choose the right technologies to power your brand’s digital strategy? How can you simultaneously eliminate both decision paralysis and the fascination with shiny newly emergent frameworks while ensuring your sites and apps remain modern? And, perhaps most importantly, why is it so key to have the right components comprising your technology stack?

We answer all of those questions in this article. Read on to learn more about the importance of a well-defined technology stack and the considerations you should have top of mind when building it.

Key considerations for building your technology stack

One of the first things that will determine your technology choices is the industry your company operates in. This will not only be important because of the nature of the products or services you offer, but also due to potential legal requirements and/or following established standards and regulations.

Closely tied to this are your company’s mission and its culture. A company promoting sustainability, for instance, will prefer to align itself with technologies based on similar values rather than those supported by companies who don’t share the same vision, or even work against it.

As for the company culture, you should ensure that the technologies you use for internal processes empower your employees as much as possible. Similarly to the above point, you’ll also likely want to ensure that the values of the companies behind those solutions don’t clash with those of your company.

Next comes your target audience. What are their preferences? Do they rely on mobile to such an extent that you should invest in a native app? Where and how much do you need to interact with them? These are all things you’ll need to consider to be able to best reach your optimal customers.

A big part of all this is integration. Having disparate systems working together to provide a great experience has become a trend, but that doesn’t mean you should overcomplicate things just for the sake of it even when your needs are simple. 

For brands engaging across numerous channels or operating in IoT, a headless/decoupled approach to managing their digital experiences may be the best fit to accommodate their multichannel reach. The same approach can be used for a single site with a heavily customized front end in the form of microservices.

Finally, you need to consider some of the fundamentals of great digital experiences: data, security, usability/accessibility and performance. 

  • You need systems that enable you to make data-driven decisions and provide personalized experiences, while also considering the privacy of your users/customers.
  • Privacy goes hand in hand with security. By choosing well maintained and regularly updated technologies, you drastically reduce the risks of cyberattacks, which have been on the rise lately. Additionally, in industries dealing with a lot of sensitive data, e.g. healthcare, you need solutions which guarantee the data is well protected and secure.
  • Usability is vital to a good digital experience, and that means usability for everyone. Make sure you use technologies that not only produce accessible experiences, but also take care to make the content creation experience accessible and user-friendly. 
  • Unfortunately, the above points matter little if your site or application performs slowly. Your super slick UI and super secure checkout process will be missed by everyone if the site takes ages to load. Invest in performant and lightweight front-end solutions to ensure a good experience both for users and for the Google algorithm.  

Tips for getting the most out of your technology choices

In this section, we’ll take a look at 5 ways to help you make more informed decisions and consequently get more out of your technology investments.

  1. Be in the loop. You’ll have a much better overview of your options if you keep up to date with new innovations in the field(s) relevant to you. That doesn’t mean you should jump on every new technology you discover, of course, but staying informed will enable you to move with more confidence when an opportunity does arise.
  2. Don’t adopt new tech willy-nilly. Tying back to the previous point, you shouldn’t haphazardly adopt each new modern framework out of concern of missing out or relying on an outdated technology. Instead, you should:
  3. Do thorough research and analysis. This can also be done proactively if you’re looking to replace old legacy systems, but definitely once you’ve discovered a potential new solution, or a new trend or problem demanding a solution. A key tip is to also research, if possible, the choices of your competitors and/or other companies with similar needs.
  4. Build with future-readiness in mind. At the current speed of innovation, if you’re building for today, you might as well be building for yesterday. When making technology investments, be mindful of possible and/or needed integrations and future capabilities, as well as flexibility, to ensure your digital experiences are as future-proof as possible.
  5. Partner with a specialized agency. This is your best bet for ensuring both the right choices and the best implementation of the choices, as well as their longevity. Not only does a digital agency provide the specific services you need, it can also provide technology consultancy as well as long-term ongoing maintenance.

Bonus point: if you’re adopting new technologies that your employees are very unfamiliar with, make sure to also invest in the necessary training to help them get on board and enable them to make efficient use of the new technology.

Why the right choice matters so much

Finally, let’s look at the benefits of investing in the right solutions for your technology needs.

Top-notch user experience

By choosing the right technology suite, you’ll be maximizing both your internal and external user experience. The user-friendliness of your content management system and great integration capabilities will gain you the efficiency and speed so needed in the highly competitive and fast-paced digital environment.

The main part, though, is of course the external experience. With so much competition, customer experience can serve as a great differentiating factor, and it needs to be more than just adequate - great is now essentially the baseline, so you should aim for more than that if you want to cut through the competition.

High ROI

A good internal and external UX will entail a much higher return on your investment and enable you to truly scale your business. And that’s ultimately what it’s all about, isn’t it? It only makes sense that you’ll want to make the investment with the highest return, and one with the most long-term potential.

Not getting locked into one system

One of the main reasons for sticking with a technology stack which is no longer adequate is the difficulty of switching to a new one. In extreme cases, this can even mean being completely locked into a particular system, where it’s not only difficult but actually impossible to migrate your data.

By investing in the right future-ready technologies you not only diminish the chances of having to switch, you also have a much easier time in case you do have to switch in the future.

Longevity

This is what it all comes down to. You’ll want your technology choices to continue benefiting you in the future without drastic overhauls. This means you’ll need both the ability to leverage them to customize your customer-facing experiences as well as the ability to easily swap out different components of the stack in order to facilitate this.

Woman at the beach forming camera frame with hands

Need additional help?

Choosing and building a technology stack is no easy task and it’s not an investment you’ll want to be making every few years. We hope this article will help you to make more informed decisions when selecting the right solutions for your business.

If you need help selecting the optimal content management system and frameworks for your company, reach out to us and we’ll be happy to help you out with both the decision as well as its implementation.

Jul 22 2021
Jul 22

A security audit is the process of identifying security threats that can lead to unauthorised access to content, data leaks, bypassing the security, and other dangers. In the first part of the series on conducting a security audit, we'll focus on the overview of the Drupal module versions that we use at Droptica for this purpose, as well as on PHP and JavaScript libraries.

Drupal security audit

At Droptica, we make every effort to ensure that the solutions we provide are as safe as possible. We use the tools provided by the Drupal community, such as the Security Review module, to optimize the process of detecting the most popular security errors. We also use the Security Kit to make the project we're working on more resistant to attacks. You can learn more about the functionality of these modules in the linked posts, and the information on their operation will be useful in the following parts, in which we'll talk about the Drupal configuration review and code analysis.

Checking the versions of the installed Drupal modules

Updating modules and libraries is the simplest activity that we can perform to improve the security of our application. Drupal provides a view listing all the modules, which additionally indicates whether a given module is up-to-date, and if it isn’t – whether the update contains security fixes.

To check if the modules are up-to-date, go to /admin/modules/update

Checking the versions of Drupal modules as part of security audit

In the screenshot above, you can see that some of the modules need updating. Of course, in such cases we always recommend that you update all possible modules. If any of the modules contain a security fix, the update is required to ensure a high level of security for the application.

In the case of Drupal, the information about whether a given module has a security flaw is made available to the public when the author of the module releases its patched version. Module authors usually try to hide which code has been changed to patch a security flaw, but this always means that the attacker just needs more time to find a way to cause the bug and exploit it. Time is important, so you should keep track of security updates regularly, not only during a Drupal security audit. As we mentioned earlier, this is one of the simplest steps we can take to ensure a higher level of security for our application.

Patches review

When updating the Drupal modules, you should also check if a patch has been applied to a given module. If so, we proceed as follows:

  1. We check whether the patch was created by the community and if it concerns a specific issue on drupal.org. If so, we look for the issue that the patch is from. It's possible that the patch has been applied to one of the newer versions of the module. In such a case, we recommend updating the module and removing the patch with the information that the code that fixes the bug or adds a given functionality has been applied to the official, newer version of the module. If the patch hasn’t yet been applied to the newer version of the module, we still recommend updating and testing if the latest version of the patch serves its purpose.
  2. If the patch wasn’t created by the Drupal community, but is the result of working on the project, we still recommend updating the module. In this case, however, ensuring the correct operation of the patch lies with the people responsible for the custom code of the project. After updating, you should check whether the patch works as intended. If not, we recommend introducing appropriate fixes to the patch which will ensure its correct operation on the latest version of the module.

PHP libraries review

The next step will be reviewing the used PHP libraries. To list them, we can use the composer show command or the local-php-security-checker package. We recommend the latter solution because it significantly speeds up the process.

Result of the composer show command during the review of the used PHP libraries

Result of the composer show command.

If you choose to install the local-php-security-checker package, follow the guidelines in the README.md file.

Result of the scan using local-php-security-checker during a Drupal security audit

Result of the scan using local-php-security-checker.

There's also the little-known Drupal Composer Security Checker module that uses the security-checker package. Currently, this module doesn't fulfill its task and the security-checker package itself isn't actively developed (since January 2021), therefore we'll focus on the local-php-security-checker package itself. If you find a security risk, our recommendation will be to update the library, of course – as in any case. An audit of the PHP libraries should be carried out regularly, the same as in the case of the Drupal modules.

JavaScript libraries review

The next step will be to check if the used JavaScript libraries are up-to-date and if they contain security fixes. To do this, you should review the library directory and the used package.json files.

In the case of the library directory, you need to check the version manually. In the case of package.json, we use the npm-audit command.

Result of the npm-audit command checking the package.json during the JavaScript libraries review

Result of the npm-audit command

The npm-audit command will list all known vulnerabilities, determine the threat level, package, dependencies, package path, and show a link with information about the vulnerability.

The npm-audit command shows all vulnerabilities in the JavaScript libraries

If you find a vulnerability, as always we recommend the update. JS library scans should be performed routinely, more often than a comprehensive security audit.

Improving the Drupal security - further steps

In this part of the Drupal security audit cycle, we've learned how to check whether the used versions of the modules and libraries are up-to-date and don't contain known security bugs. We also understand how to proceed if there is a patch available for a module – both when the patch comes from the Drupal community and when it was prepared by the developer working on the application.

Acquiring the knowledge provided in this post is the easiest way to improve the security of your application. Checking the versions of the used solutions is the first step that we perform during a security audit - our Drupal support team recommends periodic checking for updates. In the event that an update containing security fixes is released, we recommend that you perform an update as soon as possible.

In the next part of this series of articles, we'll get to learn more about the Drupal configuration aimed at increasing the security of our application. We'll also learn how to reduce the number of attack vectors and we'll find out more about the modules that'll help us with this.

Jul 21 2021
Jul 21

Current stats on the high percentage of Drupal websites that are still on version 7, with no apparent migration plan in sight, are sparking concern and curiosity throughout the Drupal sphere. What exactly is standing in the way of decisions to shed this outdated version and start reaping the benefits of better security and a far superior CMS? 

The Drupal Association pandemic-inspired decision to move the Drupal 7 end-of-life date forward by one year to November 2022, may have derailed migration timelines from their previous top-of-mind status. We believe though, that the big reason for the migration delays, is a track record for complicated and cumbersome (and often, costly) migration processes. Drupal Community insiders are aware of this reputation, and have made great strides in reversing it with new modules, tools, systems, and accelerated project planning. The result is a new era for streamlined Drupal 7 to 9 migrations with minimal snags.

Here at Promet Source, we’ve stepped up as a key player in this process. We've also taken a big picture overview of all the work that’s going on to fast-track Drupal migrations. In doing so, we’ve assembled a comprehensive guide to information, insights, expert opinions, modules, tools, systems and more. 

Let’s start with our top picks for insights and expertise. 

Expert Perspectives

Upgrading to Drupal 9 Using the Migrate API 
This 30-minute recording from a DrupalCon North America 2021 presentation provides straightforward and solid information concerning a Drupal 9 migration path, leveraging the Drupal Migrate API. The presenters also cover recommended tools to facilitate a Drupal 9 migration, pitfalls, and essential perspectives. This presentation is chock full of great information and I highly recommend it. 
 
Tools to get your site ready for Drupal 9 & 10
When you are ready to get into the actual weeds of a Drupal 9 migration, this presentation from DrupalCon North America 2021 can serve as an excellent resource with recommendations concerning the right tools, along with step-by-step explanations of when and how to put them to work. 
 
How to Optimize a Drupal 7 to Drupal 9 Migration
There’s much more to a Drupal migration than simply following the right steps. A Drupal 7 to Drupal 9 migration represents an excellent opportunity to rethink and press the reset button on your organization’s entire web experience. This recent perspective sets forth eight considerations for reaping the most benefit from a Drupal migration.
 
What? So Drupal 8 Support Ends Before Drupal 7 Support?
In June of 2020, during the same week as the long-anticipated arrival of Drupal 9, I wrote a blog concerning the essential steps involved in a Drupal 8 to 9 migration. There’s a slight irony, in the fact that Drupal Community support for Drupal 8 will stop cold on November 28, 2021, without the option of extended commercial support, but Drupal 7 support will remain intact through November 2022, with the option of extended commercial support. This disparity is due to the Drupal 8 Symfony dependency, which has an end-of-life date of November 2021.

Drupal 9 Migration: Top Questions and Expert Insights 
Recognizing that there are more than a few facets to Drupal migrations, Promet Source tapped the brainpower of some of our top devs and solutions architects for insights and observations concerning how to make the most of migration-related challenges and opportunities. Here’s what they had to say.

Migrating From Drupal 7 to Drupal 9? Acquia has your back
Acquia has developed a Drupal 7 to Drupal 9 Migrate Accelerate tool designed to fast track the migration process. This blog post from the Acquia site covers some of the capabilities of that tool along with links to other helpful Drupal migration resources. 

Migration From Drupal 7 to Drupal 8 or Drupal 9
For the visual and audio learners among us, this online tutorial from Drupal expert Kantesh Hotchandani, an India-based Sr. PHP Drupal Developer, provides a step-by-step, on-screen tutorial of some of the key steps in involved in the Drupal 9 migration process. 
 

How to Plan Your Drupal 7 Migration
An overarching theme from all of the Drupal 9 migration literature is this: successful migrations are built upon thorough assessments of the existing site and thoughtful planning. This step-by-step overview offers a helpful strategy for doing just that.

Drupal Release Dates Gantt Chart

Due to Symphony 3 and 4 dependencies, EOL dates for Symphony 3 and 4 will mean a forced EOL on Nov. 28, 2021 for Drupal 8 and a forced EOL in Q4 2023 for Drupal 9. Drupal 7 sites, on the other hand, will have the option of extended paid commercial support.

Project Planners

Drupal 8 to 9 Upgrade Planning Template

Drupal 7 to 9 migrations are taking up most of the oxygen these days from conversations concerning Drupal 9 migrations. Fact is, Drupal 8 end-of-life is scheduled for four months from now -- with no option for extended commercial support. Even though, as many have pointed out, Drupal 8 to 9 is more accurately called an upgrade than a migration, Drupal 8 site owners face a critical imperative for upgrading ASAP to Drupal 9. This template can serve as a helpful tool in doing so. 
 

Checklists

Drupal Migration Planning Checklist

Sometimes, a single oversight that could have been easily addressed at the start of a project can set a migration off course and spark undue setbacks. This Drupal migration planning checklist provides eight essential pointers that can set your migration up for success right from the start.
 

Pre-Migration Intelligence Gathering

The Upgrade Status module in its Drupal 7 version will check the list of projects your have installed and show their availability for Drupal 8/9
 https://www.drupal.org/project/upgrade_status

The Drupal Module Upgrader is a command line script that scans the source of a Drupal 7 module, flags any code that requires updating to Drupal 8/9, points off to any relevant API change notices, and (where possible) will actually attempt to convert the Drupal 7 code automatically to the Drupal 8/9 version.
https://www.drupal.org/project/drupalmoduleupgrader 
 

Migrate Modules

With the arrival of Drupal 8, Migrate module has moved into Drupal Core. However there are a number of contributed modules that are helpful for migrations and are used in most, if not all, projects here at Promet Source.

 

Must-have Migration Modules

Migrate Plus
The Migrate Plus module provides a swiss army knife of useful extensions and plugins. Migrate Plus allows the grouping of migrations, which is often handy if there are multiple types of migrations in a project.

Additionally, Migrate Plus provides two example modules which are especially useful for learning how migrations work first hand.

See the full list of Process, Source, Destination and additional plugin types on the project page: https://www.drupal.org/project/migrate_plus
 

Migrate Tools
Migrate Tools is essential for most projects as it provides Drush commands and a user interface to run, roll back, and perfect migrations.

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

General Use Migration Modules

Migration Tools
Made by the awesome people at CivicActions, Migration Tools is a bevvy of useful plugins to help with the thorniest of migrations -- especially those from HTML sources. It is perhaps worth noting that the maintainer, dkucharm (https://www.drupal.org/user/3072643), is not only a great developer but also a fantastic musician!

See: DrupalCon Seattle 2019 - Migrating terrible static content into Drupal 8 

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

Migrate Manifest
While Migrate Plus provides the ability to group migrations, Migrate Manifest takes this to the next level by allowing developers to create a manifest file to run migrations. This can be very useful for large projects and complex migration workflows. https://www.drupal.org/project/migrate_manifest

Migrate Upgrade
Provides Drush support for Drupal 6 or 7 to 9 upgrades. https://www.drupal.org/project/migrate_upgrade 

Migrate Scanner
Provides a recursive directory scanner for migrations files, which helps to organize migrations into sub-directories.

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

Migrate Files
This is useful when you need to migrate files in the same migration as other data. It is especially relevant when migrating from sources where relevant entity data is offered in a single row such as CSVs or some APIs.

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

Source-specific Migration Modules

Entity-specific Migration Modules

Process and Source Plugins

Migration Facilitators

Import/Export Modules

At Promet Source we tend to approach every engagement with a deep dive into the details and a determination to understand big-picture perspectives, as well as all of the minutiae that also matters a lot. Looking for insight or consultative support on any aspect of a Drupal migration? Let us know how we can help

Jul 21 2021
Jul 21

The Drupal project uses the pear Archive_Tar library, which has released a security update that impacts Drupal.

The vulnerability is mitigated by the fact that Drupal core's use of the Archive_Tar library is not vulnerable, as it does not permit symlinks.

Exploitation may be possible if contrib or custom code uses the library to extract tar archives (for example .tar, .tar.gz, .bz2, or .tlz) which come from a potentially untrusted source.

This advisory is not covered by Drupal Steward.

Jul 20 2021
Jul 20

➡️ ➡️ ➡️ ➡️ Submit your session: https://sessionize.com/ddi-camp/

Drupal Diversity & Inclusion, an independent working group within the Drupal community, is holding the first ever Drupal Diversity & Inclusion (DDI) camp! Our aim is to bring new voices and important topics together into a relaxed and fun virtual conference.  

This event exists to center and elevate marginalized voices in the Drupal & web community. We want to hear about what you want to talk about!

We want to know what’s important to the marginalized people in our community: People of color, women, LGBTQIA2S+ folx, religious minorities, people from the Global South, neurodivergent or disabled techies, and many others we couldn’t begin to name. Whether you’re a site builder, content creator, developer, designer, or any other kind of person in the Drupal world, we’d love to hear from you.

That’s you - what have you experienced? What has your experience in Drupal, tech, or the wider world been like? Teach us something! This isn’t a traditional Drupal Camp - we aren’t looking for any specific topics. Rather, we are looking to elevate marginalized speakers. Talks could cover all kinds of topics, including: 

  • How you’ve gotten to where you are, and where you’re going. Share your career struggles and job-hunting woes and successes.
  • Something awesome you’ve worked on, whether it’s technical, social, both, or neither. If you have a technical talk you want to give, submit it! 
  • If you have a people-oriented talk, go for it! We want to know how you relate to others, how you work with people, what you wish people knew, and much, much more.
  • If you want to talk about something else and you have no idea how to categorize it, submit that too! 

We don’t require any prior speaking experience, though if you have some, we’d love to know about it. You don’t need to be a part of the Drupal community to participate. 

We are planning to have 30 minute talks, delivered on Zoom. That time will include any Q&A, should you choose to include it - it’s not required. We’ll also have a Slack channel for the event so that any questions can be answered there, and we can have a “hallway track” during the event.

Jul 20 2021
Jul 20

When you start with the wysiwyg-container div, you will see four direct children with the top-level class. Starting with the first child, test for each special case. One of the advantages of using a DOMDocument is that you can use the getElementsByTagName function to ask any DOMNode if it has children tags like img, table, or iframe. On a match, turn all the content in the branch to a new paragraph. Otherwise, put each chunk of consecutive text into a new text paragraph. Here lies the first problem with Benji’s template: branches with mixed content.

Most of the time this isn’t an issue. If there’s a table inside a div, you probably want the entire div for your table paragraph. However, if there’s an image inside an anchor tag, your image paragraph will grab the image data but ignore the link, losing data along the way.

{# Top level tag #}

This may be an acceptable loss, or an issue that can be flagged for manual intervention. Otherwise, you’ll need a method that can recursively traverse an entire branch of the DOMDocument, cherry-pick the desired HTML element, and put the rest into the default bucket.

For instance:

/** * Recursively navigate DOM tree for a specific tag * * @param $post * The full page DOMDocument * @param $parent * The parent DOM Node * @param $tag * The tag name. * @param string $content * The content string to append to * * @return [] * Return array of DOM nodes of type $tag */ static protected function recursiveTagFinder($post, $parent, $tag, &$current) { $tagChildren = []; // Iterate through direct children. foreach ($parent->childNodes as $child) { // DOMText objects represent leaves on the DOM tree // that can't be processed any further. if (get_class($child) == "DOMText") { $current .= $post->saveHTML($child); continue; } // If the child has descendents of $tag, recursively find them. if (!is_null($child->childNodes) && $child->getElementsByTagName($tag)->length != 0) { $tagChildren += static::recursiveTagFinder($post, $child, $tag, $current); } // If the child is a desired tag, grab it. else if ($child->tagName == $tag) { $tagChildren[] = $child; } // Otherwise, convert the child to HTML and add it to the running text. else { $current .= $post->saveHTML($child); } } return $tagChildren; }

If a top level DOMNode indicates that it has an img tag, then this method will search all the DOMNode children to find the img tag and push everything else into the default text paragraph, the $current variable. There will likely be some disjointed effects when pulling an element out of a nested situation: a table may lose special formatting or an image may not be clickable as a link anymore. Some issues can be fixed in the plugin. In the migration, I checked if any img tags had an adjacent div with the caption class and stored that in the caption field on the paragraph. Again, others may need to be manually adjusted, like reordering paragraphs or adjusting a table. Remember that it’s much faster to tweak flagged migration content than to find and fix missing data manually.

On to the next issue, let’s dig into embedded media in Drupal 7. The tricky aspect here is that the media embed is not stored in the database as an image tag, but as a JSON object inside the HTML. This requires a whole new set of tests to parse it out. To start, check each DOMNode for the opening brackets of the object [[{ and the closing brackets }]]. If it only contains one or the other, then there isn’t enough information to do anything. If it contains both, then get the substring from open to close and run json_decode. This will either return an array of data from the JSON object or null if it’s not valid JSON. The data in this array should contain an fid key that corresponds to the file ID of the embedded image. That file ID can then be used to grab the image from the migration database’s file_managed table and create an image paragraph.

Those are the main gaps in Benji Fisher’s custom source plugin. Of course each implementation requires even more tweaks and data manipulations to get the exact migration to work correctly. Some content simply will not transfer cleanly, so remember to test thoroughly and stay in tight communication with your client in order to turn WYSIWYG chaos into neat paragraphs.


If you found this migration series useful, share it with your friends, and don’t forget to tag us @redfinsolutions on Facebook, LinkedIn, and Twitter.

Jul 20 2021
Jul 20

Being present when your customer needs you the most displays how much your business values responsiveness and customers engagement. Having a chatbot enables your business with these capabilities and more. A chatbot is a computer algorithm that simulates a human conversation. People interact with these bots by selecting predefined options. To give valid answers, chatbots require people to make a few selections.

With Drupal, you can try your hands out at different chatbots using modules like the Drupal Chatbot or other integration modules and APIs. In this article, we will be exploring more on Drupal Chatbot which uses Dialogflow as the NLP agent.

Building Chatbots in Drupal

Why use a Chatbot?

A Chatbot is an excellent marketing tool for a business to drive customer engagement. Chatbots enable a business to:

  • Gather customer insights
  • Increase sales
  • Be available 24/7
  • Save on time and money
  • Improve customer satisfaction

How do Chatbots built with Dialogflow work?

In a nutshell, this is how a chatbot normally works:

  1. User sends a text message through chat window 
  2. The chat app transfers the message to Dialogflow
  3. The message is matched to as intent (Intents updated manually by developers or admin in Dialogflow console)
  4. Based on the matching intent, a response is fetched. (Each intent will have its own developer defined response)
  5. The user gets a response back.

Why Dialogflow?

Dialogflow is a natural language understanding platform that makes it easy to design and integrate a conversational user interface into your mobile app, web application, device, bot, interactive voice response system, and so on. Dialogflow can analyze multiple types of input like text or audio. It can also respond to user in multiple ways, either through text or speech. 

Building a Chatbot in Drupal using Dialogflow

Step 1: Create a New Agent

  • Create and sign in to your Dialogflow account 
  • Click on Create Agent in the navigation bar and fill in the required fields.
  • Give a name and select language to your agent. Then, click the Save button.
Create New AgentAgent Name

Step 2: Create an Intent

But first, what is an intent? An intent links what a user says with what your agent does. Dialogflow matches the end-user phrase to the best intent in your agent.

A basic intent contains the following:

  • Training phrases: These are example sentences or phrases of what end-users might say. This should be updated in Dialogflow console by developer.  When an end-user expression resembles one of these, Dialogflow matches the intent. You don't have to define every possible phrases, Dialogflows built-in ML handles other, similar example phrases.
  • Responses:  Developer defined text response in return to the end-user. These may provide the end-user with answers or ask the end-user for more selection or terminate the conversation.

To create an intent:

  1. Select the agent that you created in step 1
  2. Click on the Add button next to Intents in the menu.
  3. Enter a name for your intent. 
  4. Enter Training Phrases
  5. Enter Response Test 
  6. Click Save.
Internet NameTraining Phase

Context:

Dialogflow contexts are similar to natural language context. If a person says to you "they are green", you need context to understand what "they" is referring to. For Dialogflow to handle an end-user phrase like this, it needs to be provided with output or input context to accurately match an intent.

There are 2 types of contexts:

  • Output contexts: control active contexts. When an intent is matched, any configured output contexts for that intent become active.
  • Input contexts: control intent matching. While contexts are active, Dialogflow is more likely to match intents that are configured with input contexts.

Input and output contexts are applied to intents. They work together to control bot conversation flow.

Context

Step 3: Integrating Drupal with Dialogflow

  • Install the Drupal chatbot module from here.
  • Enable Webhook for first intent and then click on Fulfillment in the left panel, enable webhook and enter the URL (for example: www.yourURL.com/assist). Click on Save.
HelloWebhook
  • Click on the settings icon beside the Agent name in the left navigation. Copy the client access token to be used in the Drupal module.
  • Go to admin/config/services/chatbot-settings and fill in the client access token and other information required. 
  • Go to admin/structure/block and look for the "Chat Bot" block. Place the block wherever desired.
Jul 20 2021
Jul 20

Sometimes it can be handy to have extra pages for a node (or any entity). For example:

  • To show different sets of information on separate pages for a single product, page, or thing.
  • So you can set different access requirements on each page for a node.
  • You want to block access to the ordinary route (e.g. node/123 and its aliased equivalent) for some reason, but you still want some other page to represent that node.

I've found a few people with that need on Drupal slack before, so I thought I'd write a guide because it's surprisingly easy!

My imaginary requirement

I'm going to imagine my client has asked me to set up an additional page for products, to show information relevant to someone that has already bought the product. We'll call it the 'Product support' page. This page could be public, but shown as a separate tab for products, or even just hidden as a link only sent out to customers that have ordered the specific product. Access could even be restricted to those people entirely. All the content to show on the page would come from fields on the product. We don't really want to go creating another separate entity to hold data that's only relevant to the product in question anyway. This makes sense from a data point of view as all the fields are for one thing, whether for existing or potential customers. (Of course, Field Group could be used to split those things into tabs on the product's edit form, or a similar technique to this article's could be used to separate them out into an additional edit page!)

First, set up a view mode for your node/entity

Just like teasers can be configured separately to the full content version of a node, you can create your own view mode. Add it from /admin/structure/display-modes/view on your site, and then enable it from the 'Custom display settings' section at the bottom of the 'Manage display' tab for your entity type/bundle. Once that's done, navigate to the sub-tab for your view mode and choose the fields you'll want to show.

So I'll make one called 'Product support', and configure only fields like 'Support helpline', 'Manuals' and 'Returns information' to show in this view mode. I will probably go hide those fields in the usual (default/full) mode too.

Next, set up the page to use that view mode

HTML page routes for viewing entities are usually set up by the 'route_provider' specified in an entity type's annotation block. For nodes, that's Drupal\node\Entity\NodeRouteProvider, which dynamically sets up the view, edit & delete routes (take a look!). But you can define your route with some simple YAML. In a custom module, add (or use an existing) mymodule.routing.yml file, with the following code. Replace 'mymodule' with your module's machine name, and 'product_support' with the machine name of your view mode:

mymodule.product_support:
  path: '/node/{node}/product-support'
  defaults:
    _entity_view: 'node.product_support'
    _title: 'Product support'
  requirements:
    node: '\d+'
    _entity_access: 'node.view'
    _custom_access: 'mymodule_product_support_access'

The last line contains the name of a function you might want to use to add any custom access logic. The function could just be in your .module file. In my case, I might look up the current user's orders to check whether they have bought the product before allowing access. You might want to at least restrict which bundles the route works for, like so:

/**
 * Extra access callback for product pages.
 */
function mymodule_product_support_access(\Drupal\Core\Entity\ContentEntityInterface $node) {
  return \Drupal\Core\Access\AccessResult::allowedIf($node->bundle() === 'product');
}

But you can just omit that _custom_access: line from the YAML entirely to just use the same access that the ordinary node page has, no problem.

Rebuild the site caches; you're done!

Now you can access /node/123/product-support to view a different page of content for your product! If you want to set it up as a tab where the usual 'View'/'Edit' tabs of a node would be, then use the following YAML in a mymodule.links.task.yml file in your module. Again, replace 'mymodule' and 'product_support' as appropriate, and then rebuild the site caches to see it work:

mymodule.product_support:
  route_name: mymodule.product_support
  title: 'Product support'
  base_route: entity.node.canonical
  weight: 5

All of this can work for any entity type - try just replacing 'node' in each of these code snippets with the machine name of the entity type that you want to use.

There's a module for that

There are modules like View Mode Page which let you set these extra pages up in the UI. But I've found my additional pages usually need some additional bespoke logic though, whether for access or something else on the page. So given how little actual code is needed, I tend to just make them this way. But it does have some handy features, like supporting URL aliases for nicer paths.

Entity Form Mode also claims to help you make separate edit pages for form modes, which is very handy. But again, I find these tend to have even more interesting bespoke requirements with custom access logic. But see how you get on. Making these in custom code can be just as easy anyway - just replace the _entity_view: 'node.product_support' part of the routing YAML with _entity_form: 'node.my_form_mode', and the _entity_access part should use 'node.update' instead of 'node.view'.

I'm sure there are some interesting use cases for this - let me know in the comments what you've needed custom entity routes for!

Photo by Thant Zin Oo on Unsplash

Jul 19 2021
Jul 19

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.

Jul 19 2021
Jul 19

Are you willing to develop a mobile app for your business? This article describes various phases in mobile application development process. Read it for more information.

The increased penetration of smartphones has led to more mobile users. Businesses are also trying to cater to this new set of users by creating mobile apps and improving customer experience. As a result, there is an increased requirement for developing mobile apps, rapidly addressing this audience, and catering to their needs. However, to ensure the application's success, businesses must adhere to a robust mobile app development process. We will discuss the steps involved in the process in detail.

Stages of Mobile App Development Process

Here is now the detailed overview of each phase involved in mobile application development.

Research and Strategy

The process of mobile app development starts by deciding the strategy for why you will need the app. Many apps are an extension of the desktop application. Next, you must identify the audience and understand their likes and dislikes. Research and strategy must take up a significant amount of time in the initial stages. The demographics and behavioral patterns of the audience must be considered too. 

While doing your research, you must also check out your competition and assess how they are reaching out to their audience and the features they are offering. The information forms the background in deciding the goals and objectives that include a critical step in mobile app development. 

Planning and Evaluating the Feasibility

Once you have finalized the app's goals, you can now analyze the features you will need in the project. It is where the analysis of competitor apps is critical. You can include the features that are absent in your competition and include them in yours. Once you have identified the elements you wish to include, you must prepare a product roadmap.

The features must be prioritized based on their importance and grouped into delivery milestones. It is also essential to identify the technologies that you will require. You must also check whether the backend system will support the functionalities you wish the app to have. You can take the help of experts from a leading mobile app development company.

UI/ UX Design

The app design must follow the optimized workflows that will allow the users to use the app seamlessly. In addition, it must ensure customer loyalty and increase dwell time on the app. So, first, map the customer journey and visualize how the visitors will go through the workflows in your app. Then, create the wireframes and a storyboard to explore the mobile app and demonstrate the navigational workflows.

The wireframes will cover the app layouts along with the device-specific designs. During this process, you must also include the specific branding guidelines of your company, also called the Style Guides. It will cover the font and style to be included in the app. The design of the navigation icons and how the app will adhere to your branding guidelines will also be covered.

Based on the guides created, the mockups will be made based on the wireframes. You can discuss with the client and finalize the aesthetic and the workflows. The static mockups can be turned into prototypes with high-quality tools. It can help stimulate the workflows that the final app will use. The user experience can also be assessed.

Development

Before the actual development of the mobile app starts, you must define the architecture and finalize the technology stack to be used. It is the most critical portion of the mobile application development process. Next, the backend technology covering the database and various other server-related objects is finalized. Next, the APIs to be created are assessed too. Finally, an intuitive user interface design is prepared for the front-end using the selected technology.

The developers will set up the project, and the pieces of code are checked before being merged into the project. Then, the app could be released to a small group of external testers for further testing of the code. If you are developing a complex app, you can use the agile methodology that helps in continuous improvements and progressive development.

Testing

The testing phase forms an integral part of your mobile app development initiative that ensures that the app is secure and stable. A team of expert testers must create appropriate use cases based on the industry and the various workflows included in the app. It will help the testers to record the results involving evaluation of the software quality. It will also help them to track the fixes in the code that must be done.

Your Quality Assurance team must be an integral part of this process. The application is now tested for compatibility, usability, performance, stress, and security, etc. The mobile app must undergo several tests to ensure a high-quality mobile solution. Some of the testing processes to be followed are:

  • User Experience Testing
  • Functional Testing
  • Device and Platform Testing
  • Security Testing

Deployment and Support

When the app is ready, you must choose the time to launch the app. After that, you can wish to publish the app on the Google Play Store or the App Store, or both. Of late, the Amazon App Store is also famous. The process involved in publishing on the different mobile app stores can vary across the various platforms.

Before publishing, you must have the metadata content ready. Keep in mind that the content must be optimized for the App Store you have chosen. You can also upload various promotional materials like videos and graphics. Some other necessary information like any geographic restrictions, configurations, and pricing may require uploading.

With Google Play Store, there would be a time lag before your mobile app is formally published. It is not the end, but only the beginning of future changes. You will receive feedback from the users that can be used as feedback for future improvements. 

App Maintenance and Future Developments

Once the app has been published, the app's performance can be tracked by deploying adequate control points through KPIs. You can detect the crashes, downloads, etc. long with other metrics as set by you. However, your work on the app continues through the support activities and future developments needed. You must keep in mind that the enhancements must be uploaded onto the app store platforms in the same process as before.

Conclusion

Mobile app development is a continuous process that does not stop with the app being published on the app stores. You must take the help of a leading mobile app development company that can help you visualize the app and suggest the features and functionalities needed through adequate research.

We have been providing mobile app development services to some of the leading businesses cutting across different industries. You can reach out to us to start a discussion about how we may be of help.

Jul 17 2021
Jul 17

Drupal is evolving as one of the leading open-source projects that is providing the best services to its community by adopting some significant initiatives, focusing on desirable goals and outcomes. These initiatives are known as strategic initiatives that are currently being worked on and are progressing over a while. Therefore, strategic initiatives of Drupal play a major role in making Drupal the first choice for any open-source user. This article will take you through the contributions made by these initiatives in helping Drupal reach the position that it stands today. 

The role of strategic initiatives in Drupal’s success

Drupal is supported by its community and group collaborations that lead to accomplishing common priority goals. Their strategic initiatives are prioritized at solving major problems that act as a barrier for the users from receiving the optimum benefits from this free and open platform.

Dries Buytaert, Drupal founder and project lead, envisioned the power of strategic initiatives in making Drupal a huge success. Receiving support from community collaboration, these initiatives have contributed to producing some remarkable developments driven by forces such as:

  • Cooperation with the core maintainers
  • Studies related to usability and survey data
  • Building an open-source digital platform experience
  • An improvement in customer experience and advanced editorial can lead to progress in market relevance
  • The facility of validation by collaborations and larger community discussions 

After the initiatives are recommended, they are forwarded to the planned initiatives stage, where every initiative is nourished with objectives and goals by its dedicated contributors. Once an initiative crosses this stage, it then moves forward to the next stage, i.e. active initiatives stage. This is how initiatives come into existence. Drupal has numerous ongoing strategic initiatives that are in progress to provide exceptional outcomes. To learn more on how Community initiatives are proposed and how Strategic initiatives come about, read here. Also, learn what’s happening with these strategic initiatives: Drupal 10 readiness initiative and Automatic updates initiative. We will now focus upon another strategic initiative of Drupal, Decoupled menus which has significantly contributed to Drupal's accomplishments.

Understanding Decoupled menus initiative in depth

At the event of DrupalCon Global 2020, Dries came up with an idea of a new initiative for building a decoupled menu component that is well written in JavaScript. Therefore, for Drupal, to be framework agnostic, he preferred to begin with building components for Vue.js and React.js.

Dries expresses that various websites are progressing into customized, omnichannel digital experiences. Drupal has to keep on advancing with the growing demands in the marketplace. It has to be built into the best web service platform and well-structured data engine regarding the back end. On the other hand, JavaScript seems to grow rapidly on the front end. As Drupal is considered as a decoupled CMS and capable headless, a lot of improvements and advancements can be made with the right approach.

Learn more about decoupled Drupal here:

According to the Drupal 2020 Product Survey, the second most requested feature was a need for a much modern administration UI. Such types of UIs can be built with the help of web services APIs and JavaScript. There is a major need to improve JavaScript and invest in web services APIs. It is well proved by the following facts.

  • Most of Drupal’s end users focus on creating decoupled front ends and omnichannel digital experiences.
  • An improvement can be made upon its administration UI with more WYSIWYG, drag-and-drop, and other ease-of-use features.

Dries further shares that to take a step towards enhancing Drupal's headless capabilities and administration UI, there is a need to include official Drupal JavaScript components to Drupal Core. The first step can be executing a JavaScript menu component in Vue and React. It can mark the first official JavaScript component in Drupal. By developing a JavaScript component, the major issues of the front-end developers can be solved. So, this menu component would provide a menu that can be placed in a front-end JavaScript application. To release the first official JavaScript component, will require the tools and processes to control and release JavaScript components. This further helps in forming a pattern for more components allowing Drupal to successfully embrace JavaScript, the need of the hour.

Illustration with a rectangle describing the path towards having a first official JavaScript component which is longer than it might appearSource: Drupal.org

The path to having a first official JavaScript component is longer than it may appear.
                                           
Here, I would like to take you across one important aspect of Decoupled menus, i.e. Drupal Decoupled Menus Survey which was announced at DrupalCon Global 2020. The reason behind conducting this survey was to get an insight into the preferences of individuals and organizations who have already built decoupled applications. By receiving the necessary understanding, Drupal actively tries to make this platform a preferred choice for the JavaScript developers. Therefore, using Survey Monkey, this analysis was executed and was promoted majorly through existing Drupal developer channels.

The primary goal of the decoupled menus initiative in Drupal is to facilitate the most convenient way for JavaScript front-ends to consume configurable menus managed in Drupal. It includes forming official, community-supported components (e.g. React & Vue) that one can use in his project or as a recommended implementation followed by necessary support that includes docs, security, and packaging, etc. Drupal prefers to keep a practically achievable target, for example, stating the fact that they will be able to ship a single menu component in place of an entire overhaul of Drupal's admin UI is good proof.

Illustration with a rectangle describing the mission and success of Decoupled menus initiative of DrupalSource: Drupal.org


Challenges faced

JavaScript is rapidly growing but Drupal doesn’t have much to offer to this specific field resulting in the feeling of incompetence among its competitors. Using Drupal, many developers are seen building “decoupled sites” for the back end and JS frameworks for the front end. This makes the following people less likely to opt for Drupal:

  • Since by using Drupal not many benefits are attained, JavaScript developers show less interest in this open-source project.
  • Less participation by Drupal evaluators who would prefer using Drupal for its content management features but at the same time would want their site to witness the more "application-like" experience facilitated by modern JavaScript frameworks. They would want to hire developers who are well versed in HTML, CSS, and JS, but not importantly familiar with Drupal.

Problems to be resolved

  • Drupal lacks an important process for building, maintaining modern JavaScript libraries, and shipping.
  • Drupal doesn’t share a good connection with the JavaScript developers as it is unable to resolve the problems they witness.
  • Working on a site using a JavaScript front end, the content editors have less authority over their content and also the structure of their site.

Solutions to the existing problems

With the help of the below strategies, it is possible to solve all the above-discussed problems.

  • Including read-only menu items to Drupal's HTTP APIs (e.g. the JSON: API module)
  • An easy process made for a front-end developer to consume the menu data to provide navigation instead of hardcoding it by:
  1. Writing documentation for the process of integrating a React or Vue application with Drupal to render an effective menu.
  2. Eliminating the unnecessary and monotonous steps by providing JavaScript tools and/or libraries for consuming the HTTP API specified above. With the help of these libraries or tools, the processes for building modern JavaScript and policies can be documented and approved.

This initiative is suitable for

  • It will be beneficial for JavaScript framework developers who would want to use Drupal as a back end and also provide user-editable menus.
  • A good option for Drupal evaluators who prefer to have all of Drupal's CMS features and more options for their front end.

Scope excludes

  • Components of frontend with markup and styles
  • Changes made to admin UI/editing interface

Here is a short informative video giving a brief about Decoupled menus initiative in a very interesting way. Take a look.

[embedded content]


To emphasize more upon the milestone which this initiative has achieved, take a look at the Decoupled Menus Initiative Keynotes which were delivered at DrupalCon North America 2021. Below are the sessions.

[embedded content]

[embedded content]

[embedded content]

[embedded content]


Conclusion

Drupal aims at building a community where the participants can easily get access to all its features, new modules, etc without any concerns that can make their software and sites much secure and convenient. This desired vision can be turned into reality by the support of strategic initiatives that can significantly make a positive shift in attaining the community goals and objectives. Decoupled menus are one of the most key initiatives that focus on upgrading the most expeditiously grown JavaScript of present times. Hence, this initiative is a work in progress that will lead to exceptional outcomes making Drupal the best choice for an open-source platform.

Jul 16 2021
Jul 16

For the July 2021 SC DUG, I gave my new talk titled “Queries on Queries” which poses questions to ask yourself when migrating data between systems. Data migrations are often critical to project success, but all too often that are treating as a throw-away process. This talk is intentionally platform agnostic building from my experience with both Drupal and Salesforce.

[embedded content]

If you would like to join us please check out our up coming events on MeetUp. You’ll find our meeting times and, once you RSVP, remote connection information.

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

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

Jul 16 2021
Jul 16

Many people probably wonder why system creators recommend regular updating to the latest version and why we are informed at every step by pop-ups that the latest patch or other fix has been released, sometimes changing only a few lines of code in the software. Using Drupal as an example, I'll try to explain why it's so crucial. Although the system works properly, it can contain many errors and surprise you with unstable work.

Why should you update your systems?

The first and most important reason why you should carry out regular updates (including the ones related to Drupal) is the security of the system itself. If the authors or the community discover a software flaw, with an update they can immediately fix it and protect users from threats (such as hacker attacks) that lurk at every step.

In the case of Drupal, new versions of the software not only protect you against dangerous attacks, but may also provide new functionalities. Usually options of this type appear in the "major" versions, such as 8.2, 8.3. You can check the update plan at any time on the roadmap on the Drupal website.

System personalization is important for every user and thanks to an update you can gain new modules or additional options that'll make your work easier. It's also worth keeping in mind that regular updates protect you from unnecessary programming work in the future, because the older your Drupal version is, the more difficult it is to install the latest update. Another advantage is the continuity of the webpage's operation, because you avoid time-consuming failures and minimise the risk of unstable system operation.

When is it worth performing an update?

As we've already mentioned, it's best to perform updates on a regular basis. As soon as you receive a notification about a new version or find out about it from another source, you should plan that update in the near future.

In the case of Drupal, updates are released approximately twice a month. You should also remember that monitoring the date until which support for a given version of Drupal is provided is sometimes a matter of several years. Therefore, you should bear in mind that every version has its "end of life" planned, and usually a migration to the newer version should be performed when updating. If you want to protect your system from hacker attacks and downtime, as well as keep the website running smoothly, you should remember to always use the latest version (or the one that is supported).

In addition, there are also updates of the modules themselves (depending on which ones are currently installed) and the PHP itself. In the case of modules, you don't always have to act so quickly, because when they are released, the information about what exactly has been fixed and who is at risk is provided. If the given problem doesn't concern you, you can do it at a time that's more convenient for you. You should pay attention in the case of PHP - it's worth acting quickly in this case, especially if the new release fixes security holes from the previous version.

To sum up, when you don't have time to install the latest update (such situations, unfortunately, sometimes happen), try to use a version that's currently supported. In the case of modules, you can take care of the ones you use most often first. This will ensure stress-free work and the certainty that you'll always be able to count on quick help in the event of unexpected errors.

Drupal update - upgrading to a higher version

A Drupal update within the same major version usually runs smoothly and doesn't cause many bugs. However, if you change major versions of Drupal, updating may be much more difficult.

Upgrading from Drupal 7 to 8

The update from version 7 to 8 can't be performed automatically, unfortunately. In most cases, you need to write the page from scratch. Drupal 8 has significantly changed the way content and configuration are stored in the database. Therefore, the database and other files must be transferred to the new page based on version 8. The configuration data include content types, user roles, and field definitions. You must also remember that not all modules have automatic update paths. Manual code tampering or custom migration will sometimes be required.

The structure of the themes has changed compared to version 7. This is another thing that needs to be rebuilt for the content to display properly in version 8. To facilitate this task, it's best to obtain the appropriate tools from the official Drupal website:

Another thing that'll help you migrate is an analysis of the Drupal modules. You need to determine which modules are most important to you (preferably in the form of a list), and whether their installation on Drupal 8 is really necessary. Also, remember to update Drupal 7 to the latest version. This'll make it easier to transfer the configuration and content data. The last step before the migration is to back up your current page, based on version 7. If anything goes in the wrong direction, you'll have a guarantee that you won’t lose the page and data.

Upgrading Drupal 7 to 8 is a complicated operation, but it brings many benefits.

  1. Lots of new features and modules have been added to the Drupal 8 core, e.g. Media and Layout Builder.
  2. Drupal 8 has access to more modern technologies - it uses more modern tools that facilitate an editor's work. Thanks to this, the configuration is easier and better adapted to people who are just starting their adventure with this CMS.
  3. In Drupal 8, part of the core is the Views module, which easily presents the added content to you in many different ways. In addition, the main page itself is a separate view, therefore you can easily manage individual elements.
  4. The core also includes the modules that provide new field types (such as phone, e-mail, link, meta tags, entity reference and contact forms).

In addition, Drupal 8 is much better suited for larger pages than Drupal 7, because it can be optimized (it has a much more advanced cache system, controlled by tags and contexts), which makes it smooth and fast to work with. It's based on the components of the Symfony framework, which is considered in the world of PHP development to be the best solution for creating complex applications.

Upgrading from Drupal 8 to 9

Drupal 9 doesn't differ significantly from version 8. One important piece of information is the upgrade to Symfony 4, which ensures compliance with the latest standards - thanks to this you can program in accordance with the latest specifications. Besides, Drupal 9 is an improved variant of the previous version. Some of the old code has been removed, Symfony and Twig have been updated, so you can be sure that the system will always work effectively and without any problems. The quick and easy update between releases (i.e. switching from 8 to 9) has also been kept. Also, the modules' updates will not require many additional changes. You should also keep in mind that Drupal 9 uses PHP 7.3 or higher versions.

The migration to the latest version will certainly require you to verify the application's code. You should remove the items marked as "deprecated" from it. You can use the drupal-check tool for this, which will automatically track down the obsolete code fragments. Then you can proceed with an automated process, the execution time of which depends on the page, and which will provide you with the latest version of the software.

How to test the system after the update?

One of the most important steps you should take after any software update is to test the introduced changes or the entire application or system. There are situations when an update is associated with data loss, system crash or unexpected errors. In the case of Drupal, you can, for example, use smoke tests. They allow you to check whether all subpages are displayed without critical errors. Another option is any visual tests that compare the previous look of the page to the new one. It would also be necessary to verify the operation of individual forms and modules and check whether the data entered on the pages is assigned to the correct fields.

To sum up, you should check the website both visually and functionally. Technically the page should work fine. You can correct minor changes to its appearance later.

Summary

Software, whether it is for a web page (as in the case of Drupal) or an operating system or other application, should be updated regularly. This ensures the support of the producer or creators and may protect you from any external attacks. In addition, you often have at your disposal new functions, modules or improvements that can significantly change your comfort of working with a particular system.

If you aren't sure how to update your CMS's version, find out how we can help you with Drupal support.

Jul 16 2021
Jul 16

Unlike other CMSs, the update of Drupal core is not difficult, but somehow complicated because of all the details involved. In this tutorial, we are going to implement a local Drupal 9 installation, and then we will upload (push) this codebase to a central repository on Bitbucket. We will then download (pull) the codebase from this repository to the live server, where the website is going to be stored.  

How to set up a Drupal workflow in cpanel with Git

Using this (terminal-oriented) process, you will be able to speed up Drupal core and module updates, and you will follow best practices. 

It is assumed that you already have a LAMP stack installed on your system. Furthermore, you require terminal access on your web server.

Keep reading to learn how!

Step 1: Install Drupal 9 Locally

Open the Terminal application of your system, and place the cursor on your local server directory, typically /var/www/html on a Linux system.

  • Type:  composer create-project drupal/recommended-project my_drupal

This will download the latest stable Drupal version to your machine. 

cd my_drupal/
mkdir config
cd web/sites/default/
cp default.settings.php settings.php
cd ..
sudo chmod -R 777 default/ 

These terminal commands perform the following actions in order: 

  • Access the my_drupal directory
  • Create a directory called config
  • Access the default directory
  • Copy the file default.settings.php and change its name to settings.php
  • Go back to the sites directory
  • Assign global permissions to the default directory, so that the system can complete the installation process

How to set up a Drupal workflow in cpanel with Git

Once this is completed, we need to create a database. 

  • Type:  mysql -u root -p 

Enter your MySQL root password.

create database my_drupal;
exit;

This creates the database you will link to your codebase. 
How to set up a Drupal workflow in cpanel with Git

  • Open your web browser
  • Type:  localhost/my_drupal/web

Finish the local installation process.


How to set up a Drupal workflow in cpanel with Git

Step 2: Creating and Adding a Key to the Remote Repository

For the purpose of this tutorial, I am going to use Bitbucket. The steps are pretty similar to a Github profile. 

Once you have logged in to your Bitbucket account, click your profile icon, located (at the time of this writing) on the bottom left corner. 

  • Select Personal settings
  • Click SSH Keys

How to set up a Drupal workflow in cpanel with Git

  • Click Add key

You will see a popup window prompting you for a label and a key. 

  • Type MyLaptop, BobsPC, or whatever you like to identify your own machine at Bitbucket

How to set up a Drupal workflow in cpanel with Git

  • Open your terminal application
  • Type:  ls -al ~/.ssh

The period before the name is telling us, this is a hidden directory.  There are two possibilities:

  1. You get a list of files, one of these files has the extension .pub.

How to set up a Drupal workflow in cpanel with Git

  1. You get the message "File or directory not found".

The file with the .pub extension is the public key of your system. If you do not see this file, you have to create one. If you do see the file, keep reading anyway. 

  • Type:  ssh-keygen -t rsa -C "[email protected]_domain.com"
  • Press Enter to select the default directory where the key is going to be stored (.ssh).
  • Enter the same passphrase twice (You can leave this empty by pressing Enter twice.)

The system will notify you about the location of your public key and its fingerprint. If you already had the .pub key on your system, step back in here.

  • Open the file .ssh/id_rsa.pub with your preferred code editor
  • Copy the whole text, including your email address

How to set up a Drupal workflow in cpanel with Git

  • Open your browser and paste it into the text area
  • Click Add key

How to set up a Drupal workflow in cpanel with Git

Your local machine can now connect to Bitbucket.

Step 3: Creating the Remote Repository

On your Bitbucket profile:

  • Click Create repository
  • Select a Workspace and a project name (create them if this is the first time)
  • Give your repo a proper name
  • Do not include a README file
  • Do not include a .gitignore file
  • Click Create repository

How to set up a Drupal workflow in cpanel with Git

Step 4: Add the Local Repository to Bitbucket

cd /var/www/html/my_drupal/web
mv example.gitignore .gitignore
git init
git add .
git commit -m 'Fresh Drupal installation'

You are accessing the root directory of your Drupal installation, changing the name of the file example.gitignore to .gitignore, initializing your local repository, adding the files to the git staging area, and finally committing these “changes” (the repo was initially empty) to the repository.

git remote add origin [email protected]:[MY_PROJECT]/my-drupal.git
git push -u origin master 

You can copy and paste these two commands from the repository’s page at Bitbucket.


How to set up a Drupal workflow in cpanel with Git

How to set up a Drupal workflow in cpanel with Git

  • Type yes, if prompted
  • Enter your passphrase

Check the repository on Bitbucket. Almost all files inside the web directory (your local repo) have been copied over to your remote repository. Take a look at the sites/default directory.  

How to set up a Drupal workflow in cpanel with Git

Notice that the settings.php file is missing. This is because it is included inside the .gitignore file.

  • Open your terminal and
  • Type:  nano .gitignore

How to set up a Drupal workflow in cpanel with Git

  • Type Ctrl+x to close the nano editor

If you take a look at the cards in the first image of this tutorial, you will notice that we have already finished the tasks of card 1, and there is only one task left in card 2. Let’s continue with the last part of this process.

Step 5: Create a Live Database

Open your dashboard at your hosting provider and create a new Drupal account with your domain name.

  • Click the Drupal “one button installer”.
  • Click Create account

This may vary from provider to provider, so you have to find your way out here. 

How to set up a Drupal workflow in cpanel with Git   

You will receive an email with a Drupal user (admin) and a Drupal password. Furthermore, you will also receive the username and password for your cPanel account. These are the ones we need. They are also available on your dashboard at your hosting provider.

How to set up a Drupal workflow in cpanel with Git

  • Click Enable SSH, so we can have access to the terminal on the live server.

How to set up a Drupal workflow in cpanel with Git 

  • Click the cPanel link
  • Type databases in the search box
  • Select MySQL® Databases

The one-clck installer created a database. Delete this database.

How to set up a Drupal workflow in cpanel with Git

  • Enter a proper name for your database.

Notice the database prefix automatically added by cPanel (in most of the cases your user name). 

How to set up a Drupal workflow in cpanel with Git

Step 6: Import the Local Database

  • Open your terminal application
  • Type:  

mysqldump -u root p my_drupal >
~/[path/to/your/desktop]/[cpanel_sql_db_name].sql

  • Enter your SQL root password

This will make a copy of your database and place it on your desktop. This database on the desktop must have the same name as the one you created on cPanel. 

If you have MySQL version 8 on your machine, you will most probably have to adapt the database to work with MySQL 5 (available at your hosting provider).

sed -i -e 's/utf8mb4_0900_ai_ci/utf8mb4_unicode_ci/g'
[cpanel_sql_db_name].sql 

This is the Linux command to perform this operation.
How to set up a Drupal workflow in cpanel with Git

  • Open your cPanel dashboard
  • Type phpMyAdmin in the search box and select it
  • Click on the name of your database to select it. It should be empty (No tables found in database)
  • Click Import

How to set up a Drupal workflow in cpanel with Git

  • Click Choose file
  • Select the database from your desktop
  • Scroll down and click Go

This will take a couple minutes, so please be patient. 

How to set up a Drupal workflow in cpanel with Git

Step 7: Redirect Your Domain

Drupal is stored inside the web directory, so to access your site, you have to enter the URL:  https://yoursite.xxx/web

If you use a cloud service, this is no problem, you can edit your hosts file. With cPanel, this is not possible (as far as I know). You have to create a permanent URL redirect.

  • Open your cPanel dashboard
  • Type Redirects on the search box and press Enter
  • Select Permanent redirect (301)
  • Choose the name of your domain from the dropdown
  • Add the redirect link
  • Click Add

How to set up a Drupal workflow in cpanel with Git

  • Type Domains in the search box
  • Press Enter
  • Click the Force HTTPS Redirect toggler

How to set up a Drupal workflow in cpanel with Git

Step 8: Upload the Codebase

  • Open your cPanel dashboard
  • Type File Manager in the search box
  • Press Enter
  • Double click the public_html directory
  • Click the Settings button on the top right part of the screen
  • Check Show Hidden Files (dotfiles)
  • Click Save
  • Click Select all
  • Click Delete

How to set up a Drupal workflow in cpanel with Git

  • Open the File Manager of your system
  • Compress the whole my_drupal folder

How to Set Up a Drupal Workflow in cPanel with Git

  • Open the cPanel File Manager
  • Click Upload Inside the public_html directory
  • Click Select File
  • Upload the zip file
  • Click Go back once the file has been uploaded to the server
  • Right-click the zip file and select Extract > Extract Files > Close
  • Double click the my_drupal folder
  • Make sure you have the Show hidden files option activated
  • Click Select all
  • Click Move
  • Select the public_html directory
  • Click Move files

How to set up a Drupal workflow in cpanel with Git

  • Click Up one level
  • Right-click the zip file and click Delete
  • Remove the zip file from your local server too

How to set up a Drupal workflow in cpanel with Git

  • Open your terminal or file manager
  • Copy the settings.php file of the local installation to your desktop

How to set up a Drupal workflow in cpanel with Git

  • Open the file with your preferred code editor
  • Replace the username with the username supplied by your hosting provider (Do the same with the name of the database and the password - see Step # 5)
  • Save and close the file

How to set up a Drupal workflow in cpanel with Git

  • Open the File Manager in the cPanel dashboard
  • Click public_html/web/sites/default
  • Click Upload
  • Select the settings.php file from your desktop
  • Click Yes to overwrite the file
  • Click Go back
  • Change the file and directory permissions according to the image below

How to set up a Drupal workflow in cpanel with Git

  • Click Up one level
  • Change the permissions of the default folder to 0755

Step 9: Set the PHP Version on Your Server

Drupal requires at least PHP 7.3. 

  • Open your cPanel dashboard
  • Type Select PHP in the search box
  • Press Enter
  • Select 7.4 
  • Click Set as current
  • Check the opcache extension

How to set up a Drupal workflow in cpanel with Git

  • Type [yoursite.xxx/web] in the address bar of your browser
  • Click Login with the username and password of your local Drupal installation
  • Click the Edit tab and change your password if necessary

Step 10: Add the Production Server Key to Bitbucket

  • Open your cPanel dashboard
  • Type Terminal in the search box
  • Click Enter
  • Click I understand and want to proceed
  • Repeat the process detailed in Step # 2

How to set up a Drupal workflow in cpanel with Git

  • Type:  less ~/.ssh/id_rsa.pub

less is a terminal editor

  • Copy and paste the key like shown in Step # 2, this time for the server machine
  • Type:  q

That will let you exit less.

You will have one key for each machine (or virtual machine) connected to Bitbucket.

 How to set up a Drupal workflow in cpanel with Git

Step 11: Clone the Remote Repository to the Production Server

  • Open the terminal application of your server
  • Type: 

cd public_html
rm -rf web
git clone [email protected]:[YOUR_PROJECT]/my-drupal.git web

 
How to set up a Drupal workflow in cpanel with Git You are deleting the web folder and replacing it with the remote repository. You obtain the last terminal command if you open the Bitbucket repository and click the Clone button (don’t forget to add web at the end of the command!).

How to set up a Drupal workflow in cpanel with Git

 Step 12: Install a Module or Theme

  • Open the terminal application of your local system
  • Type:

cd /var/www/html/my_drupal
composer require drupal/bootstrap

How to set up a Drupal workflow in cpanel with Git

  • Type cd web to get into the web directory
  • Type:

git add .
git commit -m 'Bootstrap theme installation'
git status

How to set up a Drupal workflow in cpanel with Git

  • Type git push 
  • Enter the passphrase if required

How to set up a Drupal workflow in cpanel with Git

  • Open the terminal on your remote server.
  • Type (enter passphrase if required):

git fetch
git status

How to set up a Drupal workflow in cpanel with Git 

If you see:  Your branch is behind 'origin/master' by 1 commit, and can be fast-forwarded,

  • Type:  git merge

 This will merge the code in your server with the code being pulled from the remote repository.  

  • Go to the themes section of your Drupal backend, the Bootstrap theme should be there

How to set up a Drupal workflow in cpanel with Git

NOTE:  You only have to repeat this last step, each time you download a module, update Drupal core, or edit the CSS code of your theme.

Troubleshooting

If you get 404 Error pages after installing Drupal on the production server,

  • Delete the .htaccess file
  • Upload it again to the server

How to set up a Drupal workflow in cpanel with Git

 I hope you liked this tutorial. Thanks for reading!


About the author

Jorge lived in Ecuador and Germany. Now he is back to his homeland Colombia. He spends his time translating from English and German to Spanish. He enjoys playing with Drupal and other Open Source Content Management Systems and technologies.
Jul 16 2021
Jul 16

Since Drupal 8 there Tour module is in core. It is very useful when you need to guide user within your application. We use it In EK management tools targeted at users with small to medium scale companies. They usually have limited resources and time to spend on back office trainings. This is where the Tour module is very convenient to introduce functionalities to users who can quickly grasp the functions available to manage their back office.

You can try the latest version of Tour with the demo application where many of the forms and pages have a tour guide for users.

Jul 15 2021
Jul 15

The long answer:

  1. cd to /web/themes/contrib/localgov_base
  2. run bash scripts/create_subtheme.sh
  3. done

The details are available in this short video:

I've started streaming some of my work, especially if it's contributions to open source, on twitch if you'd like to follow along/subscribe. As it turns out, Twitch deletes your videos after 14 days, so I have also been uploading them to YouTube. Feel free to subscribe.

Jul 14 2021
Jul 14

Option 1: Rebuild

Rebuilding in Drupal 9 is the perfect option for companies who wish to continue to get the absolute most from their online presence. It does require effort - both on the part of developers and the company itself - to ensure that the resulting system matches the business objectives in order to maximise effectiveness and ROI.

Rebuilds work best when they are backed up with proper discovery and design phases, and do not rely on historical design patterns from past iterations. As mentioned above, rebuilding in Drupal 9 is the last major rebuild required, as Drupal’s new semantic versioning makes all future upgrades far less onerous.

Option 2: Minimise

The minimise option is for those who may wish to have all the engine-room clout of Drupal 9 behind their site, but for whom it is not the right time for a full rebuild.

In this case, an option might be to minimise the feature set and build a ‘minimum viable product’ - i.e. a core website with a limited feature set, which can be expanded on in the future as business needs arise. You could liken it to 'bridging' between an old system and a new system.

Option 3: Decouple

A decoupled approach is not a conventional solution, but in certain cases could make sense. Decoupling means that the “front end”, as viewed by the public, is separate and distinct from the “back-end”, which stores the data and which would be used by website editors.

In this scenario, you could feasibly firewall off an old Drupal 7 system from the internet, but allow it to feed data to the front end for consumption by visitors. In this way, you could continue to use an established system well past its end-of-life, allowing editors to continue using an interface they know, and data structures with which they are familiar.  The front end is typically a ‘static’ site, which usually means that it is fast, secure, and requires minimal maintenance.

Option 4: Reassess

The ‘reassess’ strategy is where a company reconsiders what it wants out of its digital presence. Possibly business objectives have changed, or KPIs dictate another direction, or possibly even digital is the obvious only game in town. 

This strategy is all about making deliberate, informed decisions about how to invest in your company’s digital identity and your customers' digital experiences. Outcomes could range from a minimalist approach through full rebuild or even as far as a digital experience platform.

Option 5: Redistribute

In a redistribute strategy, a company might take a legacy monolith site which does many things, and break it apart: splitting functions and features across specialist services across the web.

For example, you could use a shopping platform for e-commerce, a GIS platform for mapping, a storytelling platform for rich engagement pieces, etc. In this scenario, a minimalist core website might tie together several disparate specialist services.

Jul 14 2021
Jul 14

We are excited to announce the creation of Palantir.net's Fellowship program, a wonderful opportunity for us to provide qualifying candidates with the chance to attend DrupalEasy's Drupal Career Online (DCO). The first two fellowships will be awarded for the Fall 2021 session, and the second two will be awarded for the Spring 2022 session.

Fellowships At A Glance

  • Award: Full scholarship to cover the cost of Drupal Career Online and need-based support stipends. Paid internship/junior developer position with Palantir.net, dependent upon level of expertise and capabilities upon graduation
  • Eligibility: Available to candidates with diminished industry representation and/or who have been discriminated against and marginalized
  • Requirements: All candidates must meet the background requirements, apply to, and be accepted to Drupal Career Online. Recipients must commit to a paid internship and/or junior staff position with Palantir.net
  • Additional Perks: To celebrate your graduation, you'll receive additional stipends, professional mentoring, and an opportunity to work here with us

Think this is the perfect fit for you? Check out the application process!

You can also read more about the fellowship program and how DCO provides its participants with a clear pathway towards a successful Drupal career.

Our fellowships were created to provide the foundational tools and vital resources necessary for each of our recipients to become successful professionals who will bring valuable and unique perspectives to the Drupal community. 

As a company that believes in fostering, cultivating, and preserving diversity, equity, and inclusion makes us - and the world - a better place, this fellowship program is one part of our ongoing efforts to proactively identify and remove systemic barriers to equality. 

Here at Palantir.net, we're more than just a group of web professionals - we're curious, independent thinkers with exceptional passion, initiative, and talent. And if you're still curious about us, we invite you to learn more about our CultureTeam, and Work.

Or, better yet, reach out to me (Rachel Waddick) directly at [email protected]. As an extroverted communications person, I can guarantee that I'd love to hear from you! 

Jul 13 2021
Jul 13

Headless commerce is quickly becoming the gold standard in content management system architecture. In this article, Josh Miller delves into the capabilities of Drupal Commerce 2 for a headless setup.

Using Drupal Commerce 2 checkout for headless ecommerce

Drupal Commerce 2, like Drupal 9, was a big change from previous versions. The codebase is much different and it’s quite a learning curve when moving from older versions of Drupal, like 7 or 8. However, this is good. The new versions are modern and all-around better. I’ve had a number of revelations while working with Drupal Commerce 2 and Drupal 8 that made me smile. (If you haven’t upgraded to Drupal 9, check out my blog Drupal 8 to Drupal 9: The Easiest Major Upgrade in a Decade).

In this post, I’ll explore one revelation I had while working with Drupal Commerce 2’s checkout handling and how its forward-thinking development has paved the way (and encourages all new checkout panes to follow suit) for headless ecommerce using Drupal.

Drupal Commerce 2 checkout is not a form. Say what!?

Generally, when you think of checkout, you think of it as a sequence of events and one big final submission. This is further driven home by the idea that you can, and should, be able to go back and edit your checkout choices before the final submission. In Drupal Commerce 2, going back and forth between checkout steps is supported, but there is no final submission handler that saves everything.

Wait, what? That’s right, there’s no need to save all the data on the checkout form once checkout is completed. You see, all checkout panes (a step in the checkout process) have a submission event that gets called when it's time to save the data. So if you’re going to save data in a checkout pane, you have to do it after your customer has moved forward in the checkout process but before your customer is ready to commit to the checkout pane’s final value state (complete checkout). Submission is perceived to be at the end of checkout, not before.

On the surface that might make sense, in fact, this workflow being so obvious might even blind you to the implications. Since each pane is basically handling its own submission workflow, you can’t allow your form state to persist choices and not make a decision until the end. You’re probably, like me, thinking that saving data and reacting to data is the same thing. But this assumption is old, out-of-date, incompatible with best practices, and in checkout for Commerce 2, causes design problems.

Click to discover your ideal architecture with our analysis.

Explanation through an example: A checkout newsletter subscription

A common want is to include a little checkbox underneath a contact information email field where new or returning customers can opt-in to a newsletter. Sure, that’s no big deal, right?

Our customer expects that things in checkout aren’t real until they complete checkout (i.e. nothing is saved until they actually place the order). On the other hand, Drupal Commerce 2 expects all panes to save their data after a “continue to next-step” button gets clicked, submitting that pane.

Here’s how the checkbox would be made using our current form submission logic:

  1. Create a CheckoutPaneBase object that collects data through a checkbox.
  2. On the pane form submission, subscribe the customer to your newsletter.

Do you see the problem? If we react on pane submission (our only choice in our current way of thinking), we’ll subscribe the customer to our newsletter well before they are done with checkout. In fact, each time they see the first page of checkout and proceed to the second, they will be subscribed to our newsletter. Not only is this not what the customer would expect, but subscribing them multiple times is totally unnecessary and would likely cause problems. Subscribing the customer on pane form submission is the wrong approach.

This is where things get really trippy — and awesome and beautiful and wonderfully clever and great. You see, Drupal 8, which Commerce 2 is built around, has been designed to not require forms, form states and value persistence in order to trigger important actions. This is a whole new way of thinking and maybe the most important to our discussion. Previous to this, most Drupal 7 developers would have assumed that all forms require user-facing interfaces that would be submitted, but that is a pretty brutal assumption and has plagued a lot of Drupal installations over the years. If that was still the case, then form submissions are something that headless implementations of Drupal would never really trigger. There must be a better way.

Headless decoupling breeds better code using events.

If checkout was a single form with a final submission handler that submitted payment, subscribed users to newsletters, saved addresses to profiles, and did all the things you would expect all at once, then all the code that manages these things would have to react to a single form submission.

However, if we use Drupal's built-in event system instead, we suddenly have a much greater degree of control. But before we get into that, let’s first take a quick look at what events are and where they come from.

Drupal 8 made a big shift towards being object-oriented by adopting Symfony within its framework. Symfony provides a number of components useful in modern object-oriented programming, one of which is events. Events in Drupal 8 give developers a new way to extend and modify how interactions with core and other modules work. If you’re already familiar with Drupal 7, events are basically meant to replace hooks. Drupal 8’s event system documentation helps us to understand the basic concepts and components making up the event system.

  • Event Subscribers — Sometimes called "Listeners", are callable methods or functions that react to an event being propagated throughout the Event Registry.
  • Event Registry — Where event subscribers are collected and sorted.
  • Event Dispatcher — The mechanism in which an event is triggered, or "dispatched" throughout the system.
  • Event Context — Many events require a specific set of data that is important to the subscribers to an event. This can be as simple as a value passed to the Event Subscriber, or as complex as a specially created class that contains the relevant data.

Source: Drupal.org documentation, Subscribe to and dispatch events (link)

Getting back to our checkout scenario, if you use the events system and your checkout completion is simply a state transition from Draft to Completed, then other modules could subscribe to that transition event, take the saved data from the different pane submissions, and do whatever they want with it.

Do you see the beauty here? By forcing checkout panes to submit before the final submission, we (module builders, implementers, etc.) have a baked-in reason to store checkout decisions on the order so that order events can access them separately, giving us the ability to create orders with checkout decisions saved that can skip checkout completely and still have the events trigger the needed actions. This is quite powerful and opens up a whole new world of possibilities. Of course, since this is an implicit design choice, it’s up to the author of the module or code to see the reasons and embrace them.

Entity and event-based, instead of form-based

So to complete our newsletter subscription pane example using our new knowledge of events instead of form submissions, here’s what we would do:

  1. Create a CheckoutPaneBase object that collects data through a checkbox and saves it to the order (either through a field value or the ->setData typed data interface.
  2. Save this value on pane submission but don’t act on the value (i.e. don’t subscribe the user).
  3. Create an event subscriber and use the transition event you want to use as a trigger. Completing checkout makes the most sense.
  4. Treat the order value as a "request subscription to newsletter." Then, when the event fires and the event subscriber runs, it can look for the saved value and set the user to subscribed or not after it returns. This allows us to handle someone going through an event twice for some reason, like for multiple orders, etc.

Your customer gets subscribed to your newsletter when they, and you, expect them to. No forms are needed. ISN’T THAT AMAZING!

Thanks to the many authors of Drupal Commerce 2, including Bojan Živanović and Matt Glaman, who implemented this design choice years ago, many modules and implementations are simply technically better and likely ready for headless implementations now that headless is all-the-rage.

And best of all, from a developer standpoint, this also means the bulk of your most critical automated tests that interact with your code doesn’t have to access the checkout form. They simply have to have orders that get transitioned. This makes writing tests, which equates to better code, simpler.

Your Drupal Commerce experts

As a full-service Drupal agency, Acro Media has significant expertise in digital commerce architecture, ecommerce consulting and design, customer experience, Drupal development and hosting architecture. We would love the opportunity to work with you.

View Our Drupal Commerce Services

Editor’s note: This article was originally published on October 28, 2019, and has been updated for freshness, accuracy and comprehensiveness.

Jul 13 2021
Jul 13

Migrating data from any source to Drupal 8 is now made simple with various modules that allow easy data transfer. Migration in Drupal is a term for any process that moves data from an external source to the current Drupal site. You can migrate data that includes nodes, users, configuration, and any other components of the site. 

Drupal provides you many ways to migrate content. Depending on the website and source of the data, you can choose the best way to do it. However, migrating multilingual data can add a few more steps to your migration process. You will first need to migrate the base content and then migrate the translations. In this article, we will elaborate on these steps to help you get a better understanding of migrating multilingual content from CSV to Drupal 8.

CSV Import

Drupal 8 Migration Modules You Will Need

As mentioned earlier, Drupal offers tons of options and modules that can help you with an easy, hassle-free migration. For migrating multilingual content, you will need:

  1. Migrate: Provides a flexible framework for migrating content into Drupal from other sources.
  2. Migrate plus: Provides plugins for migrations like source plugins, process plugins, destination plugins and API extensions.
  3. Migrate Drupal: Provides support for migrating content and configurations.
  4. Migrate source CSV: Provides a plugin to import contents to Drupal from a CSV file.
  5. Migrate tools: This module gives UI tools and Drush commands used for migration.
  6. Configuration development module: This module converts script into configurations.

Step 1: Migrating the base content

To begin with migrating the base content, we will first need to create a custom module in Drupal 8.

Create Custom Module

Make sure that the info.yml has these keys and values.

You will need to create yaml files, which are known as migration scripts, and place it in the config/install directory of the custom module created. The config_devel/install key of info.yml should have all the yaml files written.

Yaml File

This is a sample yaml file for importing taxonomy terms. The migration script has 4 sections:

  1. Metadata: will have the id, label, and migration group id.
  2. Source: The source key should have the path to the CSV file.
  3. Process: The mapping between the fields and the CSV columns.
  4. Destination: The destination where the imported data is saved.

The yaml file node contents should be written similarly. The only difference being the destination. 

Entity Node

The destination plugin should be entity:node and the default_bundle will have the machine name of the content type to which the content is imported.

After creating all the yaml files, the IDs of the yaml should be included in the info.yml. Once everything is done, enable the custom module.

Use the Drush command drush cdi . Here the migration id is techx migration. This will convert the script into configurations.

After running the command go to admin>structure>migration. You will find the migration group you created by clicking on list migration. This will show you the list of the migration scripts created.

Operations

Clicking on execute tab will show the list of operations available:

Operations Available

Import is to pull the data from the source. 

Rollback will delete the data imported. 

The Stop is to interrupt the import or rollback process.

Sometimes a process gets stuck. To move the status to idle, Reset is used.

For a more detailed information on how to migrate the data of different entities like the user, paragraph, check CSV Import to Migrate Drupal 7 to 8 - A complete guide.

Step 2: Migrating the translations of the base content

If you already have enabled multilingual content on your Drupal 8 website, you can skip the first step. If you want to know how to create multilingual Drupal 8 websites (and why you might need one), check out this article.

1. Adding language to the Drupal website

To import translations, first we must make our website multilingual. Let us see how to download languages to the site.

  1. Enable the Language and Content translation module. These are core modules.
  2. Go to /admin/config/regional and language/language/add language.Add Language
  3. Clicking on the dropdown gives you a list of languages. Select the language you want on the site and click on Add language. This will download the language for your site.

2. Enabling translation for entities

Once we have installed the languages we need, we must enable the translations for the entities before importing or adding the translations to the content. For this, go to admin/config/regional/content translation. Select the entities to which you want to enable the translation and click on Save configurations.

In this example, I am importing the blog content type and thus I will enable translation for blog content type.

Language

3. Update the migration files

There are some changes that need be made on the yaml files to import the translations. Give the path of the CSV file of translated content as a base contents and translated contents are stored in different files. Changes in term translation.

tid

Add a new key tid in the process section of the script with the plugin as migration, source as id, and migration value should be the migration id of its base content migration script.

For node migration add a new key nid in the process section. Here the migration key will have the value of the migration id of its base content migration script.

Source Id

Another key should be added is translations with the value set to true. This should be added in the destination section of all the translation migration scripts irrespective of the entities.

Destination

Define the language to which the translation is imported using the langcode key. In this example I am importing Japanese translations, so the value will be ja.

Langcode

These changes tell the script to take the id of the content from the base content migration from which these contents are treated as translations rather than a new node.

Points to remember

  • The importing process should go in order. For example, if the terms are referred to in the node, the terms should be imported first before the node contents.
  • Enable the translation for the entities before importing the translations.
  • The order of translation contents in the CSV file should be the same as the base content. That is, the base content and its translations should be in the same line in the CSV file.
  • Import the base content first then the translation content. Else both will be treated as individual contents.
Jul 13 2021
Jul 13

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

Credits & Thanks

Thank you to:

SEO Training Camp: https://moz.com/learn/seo/title-tag

About the Editor Advanced Link Module

The Editor Advanced link module allows you to define title, class, id, target, and rel for links in CKEditor. This helps your SEO by placing more text information about each link on the page.

Install and Enable the Editor Advanced Link module

  1. Install the Editor Advanced Link module on your server. (See this section for more instructions on installing modules.)

    editor advanced link module installation
     

  2. Go to the Extend page: Click Manage > Extend (Coffee: “extend”) or visit https://yourDrupalsite.dev/admin/modules  in your browser.
     
  3. Select the checkbox next to Advanced Link.
     
  4. Click the Install button at the bottom of the page.

There are no separate permissions required for the Editor Advanced link module.

Configure text formats to use Editor Advanced link module

  1. Go to the Manage > Configuration > Content Authoring > Text Formats and Editors (Coffee: “text”) or visit https://yourDrupalsite.dev/admin/config/content/formats in your browser.

    editor advanced link module configuration screen
     

  2. Click the Configure button next to the first text type listed. This will take you to the configuration options page for that content type.
     
  3. Scroll down to the bottom of the page and find the vertical tab called Limit allowed HTML tags and correct faulty HTML. If that tab is not there, skip to step 6.

    editor advanced link module allowed html tags
     

  4. In the field called Allowed HTML tags look for the tag.
     
  5. Put your cursor at the end of that tag within the field, and add “title class id target rel”. It will end up looking something like this but could vary:


     

  6. Click the Save configuration at the bottom of the page.
     
  7. Repeat steps 1-5 for each of the text formats.
     
  8. After completing all text formats, make sure to click the Save button at the bottom of the Text and Format Editors page.

Using the Editor Advanced link module when adding links to your nodes

  1. Open an existing node and click the Edit tab or create a new node.
     
  2. Select the text to be linked and click the link image button in the editor menu bar.

    editor advanced link module in action
     

  3. Open the Advanced drop-down section.

    editor advanced link module add link pop p window
     

  4. There will be fields to add a Title, CSS classes, ID and Relation information along with a checkbox that will open the link in a new window. Fill in the appropriate fields as needed.
     
  5. Click the Save button to create the link and make sure to save your content.

Did you like this walkthrough? Please tell your friends about it!

facebook icon twitter social icon linkedin social icon

Jul 13 2021
Jul 13

With digital accessibility getting more awareness lately, content management systems are also adapting to this by offering more and more features that enable marketers to produce content which is easily accessible to all.

Drupal is one of the best-known CMS solutions and it also holds the title as one of the most accessibility-focused ones, especially when it comes to open-source options. In this article, we’ll take a look at what makes Drupal such a great choice for accessibility needs.

Commitment to inclusivity

The Drupal community is one of the most diverse and inclusive tech communities in the world. Diversity and inclusion are not just essential values on paper; they’re also lived by leaders and members of the community.

This human-based approach also shines through when it comes to designing new core features, themes and modules, as well as all other activities related to the Drupal project. Both the core team and individual contributors are committed to contributing tools that can be used equally well by anyone, in the true spirit of Drupal’s commitment to accessibility.

A11y best practices baked into core design

As just stated under the previous point, the Drupal core team makes sure that contributed code follows accessibility standards and these best practices are then implemented in the core design of the Drupal framework. Its code uses well-structured, semantic HTML which uses ARIA (Accessible Rich Internet Applications) attributes and is WCAG 2.0 AA compliant.

Streamlined editorial features

One of Drupal’s biggest accessibility wins is how far its editorial interface has come. Drupal 8 already introduced massive improvements from version 7 with handy features for administrators and editors such as requiring alt text for uploaded images. Drupal 9, released just over a year ago, has streamlined the editorial experience even further.

  • Claro, the new admin theme: the modernized Claro back-end theme arrived in Drupal core with version 9. Not only is the theme sleeker and more user-friendly, it also takes care of some less obvious potential accessibility issues, for example by automatically generating some extra padding for images inserted in articles.
  • The Layout Builder: similarly, this Drupal 8 experimental module was moved into core with version 9. While comparable to the Gutenberg block editor in WordPress, Layout Builder was accessible right out of the box; in contrast, the block editor was initially infamously criticized for its accessibility failures (granted, WordPress was quick to start resolving these).

New and fresh front-end theme

While most brands will opt for a customized theme for their Drupal websites, having a strong and accessible default theme certainly doesn’t hurt. The new theme Olivero was shipped as an experimental theme with the release of Drupal 9.1 and it’s planned to be included as a default starter theme by version 10.

Not only does Olivero support the latest features of Drupal, it was also built with WCAG AA conformance top of mind right from the start, with the core Olivero team containing several accessibility experts.

Abundance of accessibility modules

If all the out-of-the-box features aren’t enough, there’s also a wide variety of accessibility-focused Drupal modules available to download and install, ranging from general to heavily specialized ones. You can read more about the top Drupal accessibility modules here

Open source

One of Drupal’s most compelling features is its open-source nature. This is particularly important for accessibility, since both Drupal core and contributed modules are literally accessible to everyone, free of charge (in contrast, the majority of the top WordPress plugins are paid plugins).

Moreover, due to the strong commitments to accessibility we’ve outlined in this article, Drupal is not only accessible to download, but also usable. Granted, the learning curve for less tech-savvy beginners is steep, but even that is primed for improvement with the new Easy out of the box initiative. 

Conclusion

Lightbulb with several crinkled pieces of paper scattered around

Drupal has made great strides towards becoming the number one accessibility-focused CMS in the past half a decade, and its future plans are to become even more people-centered and user-friendly.

If your company or organization is in need of powerful accessibility features, Drupal may just be your best bet, especially if you also benefit from some of its other strong suits, e.g. its advanced publishing workflows or its customizability. 

In case you do decide on Drupal and need some extra development capacity, our experienced Drupal developers will be happy to help you out. Get in touch with us or learn more about working with us.

Jul 13 2021
Jul 13

With Drupal 8 reaching its end-of-life on Nov 2, 2021, you must upgrade to Drupal 9 before November to keep your site secure. Let's have a look why migrating now is best option for your web platform.

Drupal is among the most robust CMS that is seeing increased use in complex websites. Like most CMSs, Drupal is upgraded regularly to add new features for a holistic visitor experience and added security features. Therefore, it is always helpful to have the CMS upgraded to the latest version. However, the impending end of support of Drupal 8 on 2nd November 2021 requires you to go for a Drupal 8 to 9 upgrade quickly.

Why must you Upgrade to Drupal 9?

Drupal 8 is Nearing the End-Of-Life

One of the prime reasons you need this upgrade is that Symfony 3 and Drupal 8 reach the end of life. It is happening even before Drupal 9.3.0 is released. It is also essential to know that the upgrade from Drupal 8 to Drupal 9 is more straightforward than the earlier versions. Once the support is lifted, there will be no bug fixes, security updates, or creation of new features or modules. It will be challenging to protect the website from cyberattacks or stay ahead of the competition. The Drupal 9 upgrade will provide you with support from the Drupal community.

drupal 8 end of life - upgrade to drupal 9

(Source: Drupal.org - How to prepare for Drupal 9)

Few Unique Features in Drupal 9

Let us learn about some of the critical features of Drupal 9 that will provide an impetus for a quick upgrade.

  • It is Backward Compatible

    Drupal 9 is compatible with its predecessor and can use the modules and configurations used in Drupal 8. It will ensure that the performance of the system will not be affected. Your website will operate faster and with clutter-free technology.
     

  • No Deprecated Code

    One of the issues of migration projects is the need for a cleaner codebase. No deprecated code will be supported and used in the Drupal setup. When you upgrade to Drupal 9, there will be a cleaner codebase and improved site performance.
     

  • New Versions of Symfony and Twig

    The older versions of these platforms will be removed, and you must upgrade to the newer versions. It helps to enhance website security and enhances the developer experience. For example, there will be an upgrade to Symfony 4 or 5, while there could be an upgrade to Twig 2.0.
     

  • Multi-Lingual Support

    Global corporations have websites in the language of the country where they are operating. It helps them to talk in the language of the audience. Drupal 9 allows multi-lingual support, and the editors can manage language versions conveniently.

Tips for Upgrading to Drupal 9

When you upgrade to Drupal 9, you must ensure that the version is updated. Are you aware that the upgrade from Drupal 8.9.0 to Drupal 9 would involve updating Symfony and Twig? It will also include the removal of the deprecated libraries and code.

As a first step, you must ensure that the site runs on a stable version of Drupal 8. The Upgrade Status module can help check the contributed module's compatibility and assess the system requirements. The custom modules must be checked for the use of APIs or deprecated libraries.

While you are still on Drupal 8, you must upgrade the contributed modules and the themes to the Drupal 9 compatible versions. You can use the Upgrade Status module to generate a report on the readiness of the modules for the proposed upgrade to Drupal 9.

If you are using custom themes or modules, always check if they are compatible with the new version of Drupal. You can scan using the Upgrade Status module and remove any deprecated APIs that may be present. Moreover, you must also check whether the PHP, MySQL, and the web server are running on compatible versions.

How can you upgrade to Drupal 9 from Drupal 8.7 or earlier?

You must migrate the Drupal 8 site to Drupal 9 to see the end of life in November this year. When you have decided to relocate, you must first update the Drupal 8 site with the most recent version of both the contributed and core themes and modules. In addition, the site must be upgraded to at least Drupal 8.8.0 as earlier modules are unlikely to be compatible with Drupal 9.

Before you plan the upgrade to Drupal 9, you must have an inventory of the contributed modules, custom modules, and themes.

Custom modules: You can install drupal-check running as a part of CI workflow or running on the development environment. You will understand the activities to be performed to have the custom code compatible with Drupal 9. You can note down the modules which have a compatibility issue. Check whether you need them anymore.

Contributed modules: The contributed modules can be segregated into groups that will show the amount of effort needed. First, check the modules that have a Drupal 9 release. Also, check whether these would be significant updates or would they be minor ones.
The latest releases of the contributed module can often support both the versions of Drupal 8 and 9. Thus, the effort needed will be the least, and you can start from here.

You must update to the latest version of the core to allow the database to be ready for migration. The contributed modules will also be prepared for the Drupal 9 upgrade. Once all the components are compatible, you must update the core to Drupal 9 and run the update.php program.

How can you upgrade from Drupal 8.8 or later?

The themes and the contributed modules must be updated. You can use the Update Status module to check the compatibility with the Drupal 8.8 site. You can check the module’s project pages for the Drupal 9 upgrade. If the website has themes or custom code, always ensure they are not using any code that was deprecated in 8.8 and must be removed. When all the components are compatible, you can update the core to Drupal 9 and run the update.php.

Conclusion

Drupal is increasingly getting popular with heavier and more complex websites. In keeping with the trend of periodically upgrading Drupal, the advent of upgrade to Drupal 9 comes with several benefits. You must upgrade from Drupal 8 to Drupal 9 as Drupal 8 will see the end of life by November this year.

Are you looking for experts for migrating your website to Drupal 9? We are happy to help and are just a phone call away or contact our experts to get started on your Drupal upgrade today!

Jul 13 2021
Jul 13

Accepting payments on a Drupal website

Drupal is a very good and secure content management system the website admin uses to upload text and images. However, to enable this website to do something more than just serve as a blogging platform, its functionality can be extended by integrating additional modules. The modules consist of a set of PHP, CSS, and JavaScript code that interacts with the system core and adds new capabilities. The modules and Commerce, Kickstart, and Ubercart distributives are what you need to enable your website to work with goods and cash transfers.

Though Commerce in itself doesn’t include the payment function, it offers a ready framework and an admin panel the function can be integrated into. The user should download the module for the Drupal Commerce platform, which is integrated with the selected payment system or gateway, and set it up in the admin panel. The list of EPSs and payment gateways compatible with Commerce includes both the world-known PayPal, Stripe, Braintree, Authorize.net and 100-plus small aggregators listed in the module documentation. If the payment gateway you wish to use on your website is missing from this list, Drupal Commerce framework allows developing the module on your own.

And what will happen if you neglect to perform integration with the payment gateway? We were approached by a client whose buyers, when trying to pay for the order, were pushed out to the bank website where the payment was to be carried out. The magic was unveiled and unnecessary steps were added to the payment procedure; as the result, the buyer was not happy. You’ll be lucky if the buyer finalizes the purchase, but the chances of the buyer returning reduce as there are more convenient stores. Based on programmers’ estimates, it may take tens of hours to develop a solution for Drupal Commerce integration into an unknown payment system. It’s expensive but look ahead — by saving on development now, you are likely to lose buyers and money later.

We talked about Commerce, Kickstart and Ubercart in our first post and provided the Commerce installation and setup guidelines in the same post. That’s why let’s use the remaining space for other aspects. For instance, we’ll describe an exceptional case you also can experience if you accept payments from a foreign bank.

The child health clinic "Under 16 years old" is one of our clients. To enable payment for services, we used the payment gateway of Sberbank (a major Russian bank). Some gaps were found in the bank documentation: nothing was said about the case when a payment made by a foreign bank card fails. This was the case the clinic’s customers faced when they tried to pay by cards issued by Kazakh banks. The problem was resolved only in personal consultation with the technical support of Sberbank. The moral and recommendation would be as follows: since it is not always the developers who are to blame for all acquiring issues, contact the support teams of all services involved in the process if you are going to have international transactions.

Data security

Who is responsible for data security? What is the site owner to do to protect the buyers’ payment data from leaking anywhere?

Usually, if you need to keep card details, you should select a payment system that allows doing this on its side (for example, Stripe). In this case, the online store website operates only with the identifiers needed to request data from the payment system. However, the data leak is still possible as the attacker might find some security gaps during setup of the web server or in the application itself and use the gaps to embed the code to collect personal data or can steal private keys for the aggregator integration.

To be on the safe side, it makes sense to maintain security updates for CMS and the modules, configure the web server and access rights correctly, and be mindful of the system functional testing to differentiate the access rights to ensure that anonymous users cannot access the orders or that buyers cannot view each other’s orders.

Costs

Surely, a third-party service also wants to earn money and charges business internet professionals a fee for some of its services. All providers of internet acquiring services are similar in that they charge a commission for each remittance. For instance, Stripe charges 2.9 % of the payment plus 30 cents and promises ‘no setup fees, monthly fees, or hidden fees’. Good client-oriented services are ready to offer you a special percentage rate based on your region, business type, and monthly revenue.

In addition to the remittance fee, payment services can charge fees for:

  • Monthly usage
  • Service setup
  • Chargebacks
  • International fund transfers

Read the tariff information of each payment service provider carefully.

An online shop offering search by products, filters, payment page, personal account, etc. will require a higher-performance server as compared with an online business card or a media outlet, which is why additional expenses will be needed for the online shop hosting.

Conclusion

Judging from experience, website owners can go very deep into the aspects relating to the differences between the payment systems, data security, and so on, but they are not always able to put this knowledge readily into practice. Remember the story about in-house development of the module that enables interaction with the payment gateway. As you might guess, this task requires some programming skills. We are writing this post because we want to share the same language with entrepreneurs but we suggest that you should delegate the tasks of the payment system implementation and setup to your contractor.

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