Subscribe to Planet Drupal feed - aggregated feeds in category Planet Drupal
Updated: 40 min 8 sec ago

Promet Source: A Marie Kondo Inspired Guide to Content Migration

Sat, 2019/08/31 - 12:44am
I’ll admit to having watched a few episodes of Marie Kondo’s show on Netflix. She has definitely inspired some of the downsizing my wife and I done over the last few years. I even applied her thought process to my personal website. When I moved it to a new host I thought about how much of the content on it was not sparking joy.  If I didn't really care about stuff did my readers? This thought process is probably even more valuable for a large business-focused Drupal site than it was for my goofy personal website.

Mediacurrent: [Flexible Typography] UX Design Principles for Component-Based Systems

Fri, 2019/08/30 - 8:37pm

In this 5-part series, take a deep dive into universal design concepts in the context of creating component-based systems for dynamic web content. Get a birds-eye view of the inner workings of user experience (UX) architecture. Brand strategy, user psychology, objective methodology, and data-driven decisions come together, guided by timeless fundamental ideas, to construct today’s digital journeys.

Flexible Typography

The Art of Setting Type for Dynamic Systems

It is the typographer’s task to divide up, organize, and interpret this matter in such a way that the reader will have a good chance of finding what is of interest to him.

- Emil Ruder

In the 1950s, Swiss typographer and graphic designer Emil Ruder was involved in developing the International Typographic Style. Cleanliness, objectivity, and the use of “the grid” are key features of this approach which still plays a major role in design today.

In 2006, Oliver Reichenstein said,

Web Design is 95% Typography.

And while faster connection speeds have allowed us to provide more media-rich experiences, text-based information is still vital - and the only thing that devices like Google, Alexa, and assistive technologies for the differently-enabled “see.”

Today, the timeless challenge of how to visually present text-based information is as formidable as it’s ever been. Contemporary design decisions take into account the experiences of billions of potential users, located anywhere in the world, in front of screens of all sizes, with a wide range of backgrounds, situations, and abilities. 

Fortunately, standards such as those for Heuristic Evaluation, the W3C’s Web Content Accessibility Guidelines and user testing tools such as the System Usability Scale and the Single Ease Question have provided an objective structure to inform the creative works of designers today.

Fast, Scalable, Legible Type Styling Guiding principles for font selection and implementation  Limit the number of fonts 

In the name of consistency, efficiency, and optimized load times, consider combining two harmonious fonts that create a visual hierarchy. Two is considered an ideal number for fonts. Choose a font with enough members in its family to allow design options, however. A font with light and black versions, as seen on some of Google’s best fonts, will provide a versatile UI toolkit.

Most brand standards contain definitions for print and well as web fonts. In the absence of such standards, a review of mission and vision statements can guide you to a font that reflects the brand identity.

Use a responsive type scale

Responsive modular typography scales, when designed and implemented, are an easy way to preserve visual hierarchy across the various screen widths of devices. A modular type scale is a series of type sizes that relate to each other because they increase by the same ratio. 

Example of how responsive typography looks across various breakpoints on Mediacurrent’s Rain demo site.


Avoid All Caps for headings and paragraph text

Not only have studies shown text formatted in All Caps decreases reading speed by 10-20%, but this styling presents substantial barriers for users with dyslexia. According to the latest estimates, that is 15-20% of the population.

When headings are less than around 25 characters, all caps is still considered readable for everyone. All caps can also be a valid choice for short navigation titles and concise button copy.

Avoid Italics for headings and paragraph text

A first-time user may spend seconds on your website, not minutes, and as reading speed is dependant on legibility, styling is of paramount importance for all users. In terms of accessibility, italicized letters are nearly illegible to some with reading issues.

Addressing accessibility concerns is a great investment that provides an opportunity to bring in objective best practices to increase usability, readability, and visual impact for all users, opening up your website to a larger audience.

Modern, Readable, Accessible Type Styling  Guiding principles for line and paragraph spacing Look to the gold standard for accessibility

Because Section 508 compliance is currently attuned to the A and AA Level WCAG 2.0 guidelines, the AAA Guidelines are sometimes left out of the conversation. The guidelines around line and paragraph spacing, however, are especially easy to incorporate. Because they improve the experience for all users, they are well worth considering. 

Avoid justified text

People with certain cognitive disabilities have problems reading text that is both left and right justified. The uneven spacing between words in fully justified text can cause "rivers of white" space to run down the page making reading difficult and in some cases impossible. Text justification can also cause words to be spaced closely together so that it is difficult for them to locate word boundaries.

Implement a maximum width for containers of heading and paragraph text

For people with some reading or vision disabilities, long lines of text can become a significant barrier. They have trouble keeping their place and following the flow of text. Having a narrow block of text makes it easier for them to continue on to the next line in a block. Text blocks must be no wider than 80 characters. 

When determining how to limit the width of a responsive text block, it can be helpful to use a character counting tool. Or try advanced math! The Golden Ratio Typography Calculator generates suggestions for your entire type hierarchy based on the Golden Ratio: a pattern found in nature that is inherently pleasing to the human eye.

Provide ample line spacing for paragraph text

People with some cognitive disabilities find it difficult to track text where the lines are close together. Providing extra space between lines and paragraphs allows them to better track the next line and to recognize when they have reached the end of a paragraph. Provide line spacing that is at least 1.5 (a space and a half) in text blocks and spaces between paragraphs are at least 1.5x line spacing.

In the first post of this series, we discussed the advantages of generously-sized type comfortably line-spaced within a width-restricted column. Not only does this approach align with that of today’s best-in-class websites and provide a comfortable, welcoming reading experience, it is universal design that is accessible and all-inclusive.

Preparing to Reach a Global Audience Scratching the surface of localization Designing type for Right To Left (RTL) languages

Arabic is the 4th most popular language globally and 60% of Arabic speakers prefer browsing internet content in Arabic. Aligning text to the right side is key, and so is upsizing the font to preserve text readability. Factoring in the shorter length of words as most Arabic words. Read more about web design for RTL languages.

Example of RTL language typography on

Accommodating translated text

Character counts expand or contract according to language. Expect a 15 - 30% expansion when translating English to Spanish or Portuguese, for example. When planning to translate English to Chinese or Japanese, however, expect variation. Read more about typography for translated text here.

Planning for character-based languages

Written Japanese, for example, consists of thousands of characters across four character sets: hiragana, katakana, kanji and the Latin alphabet. Japanese users perceive carelessly designed websites as reflective of brand quality. They describe products as “unnatural”, “foreign”, and “suspicious.” The work to get from unnatural to perfect is not hard. Read more about standards for presenting Japanese text on the screen.

Applying and Iterating Type Systems Continuous improvement based on user feedback

After carefully selecting type styles representative of the brand experience, applying them with accessibility in mind, defining parameters within responsive components, and perhaps including specifications for translated type, what comes next?

We take these specs and build a living style guide to catalog the site’s elements and components. Having the building blocks all in one place not only ensures consistency but allows developers to rapidly adjust or efficiently leverage the existing pieces to create more complex components.

A living style guide makes it easier to add new patterns to meet your needs and the needs of your users that arise as “the rubber hits the road” when content editors begin using the site and feedback is collected from users, ideally through methodical tests.

Technology has evolved rapidly since pioneers like Emil Ruder developed the Swiss style, and is always offering new challenges for designers. But happily, this evolution has allowed us to collect data to objectively guide our practice and to create, share, and continuously improve standards for accessibility and usability, allowing us to meet the challenge of designing with confidence for the global audience. What a great time to be a designer!

In the next installment, we’ll cover pattern libraries/ living style guides in greater detail. We’ll discuss how style libraries ensure a consistent experience and make ongoing enhancements much easier. Learn about the steps it takes to build an emotion-rich, brand-true user journey within the restricted structure of a website built to last for years displaying dynamic, user-entered content.


Palantir: Drupal Sustainability: Contribution, Credit and Impact

Fri, 2019/08/30 - 6:24pm

Having more companies working with Drupal is a good and necessary thing, but it means we need to improve the way that we onboard, recognize, and differentiate those who help sustain and innovate Drupal.

A few weeks ago, I earned my first ever Drupal contribution credit for my DrupalCamp Colorado keynote. While I am oddly excited about that, I also find it somewhat ironic, as that keynote should not be mistaken for my first contribution to Drupal.

According to my profile, I’ve been a community member for over twelve years. In that time, I’ve presented keynotes for three other DrupalCamps, presented sessions and participated in panels going back to DrupalCon Boston 2008, led the RFP process for the redesign of, chaired DrupalCon Chicago 2011, served on the board of the Drupal Association for nine years and, most recently, served on the Executive Director Search committee. That is but a partial tally of my individual contributions; of course my company,, has also made considerable contributions of time, talent, and treasure over all these years.

Recognition is not my motivation for these efforts; like so many open source contributors, I give back to Drupal because I am committed to stepping up when I see a need or an opportunity. When I was new to the community, the karma earned from such efforts, code and non-code, was informally held in the living memory of those who were there. I always felt that I had earned the credibility and support of those with whom I collaborated closely to move on to the next opportunity, to tackle and solve the next problem. In many ways, as a woman on/of the internet, I appreciated the relative anonymity of it.

In that way, Drupal has become the largest independent community-driven open source project. And many of us believed that our collective success and the impact we made was enough to sustain the virtuous cycle of open source. But was it?

Open source has won: we now have legions of people and companies who rely on Drupal and other open source tools and products; however, these companies picked the best tool, which just happened to be an open source tool, and they don’t necessarily yet know the open source way. Twelve years ago, the Drupal community was small enough that those established norms and expectations were passed on person-to-person, along with the lore and the legends. The old ways of influencing behavior and enforcing norms through social bonds (aka peer pressure) aren’t strong or explicit enough for the swells of newcomers.

There is a lack of shared understanding, visibility and support for what it takes to not just keep Drupal sustainable, but to have it thrive and win in a competitive landscape. This lack of clarity has led to the emergence of multiple subcultures within the commercial ecosystem and a worrying disparity between those who benefit the most from Drupal versus those who give the most.

In his Amsterdam 2014 keynote, Dries noted that while open source has a long history of credit (for code) to the individual contributors, this does not adequately recognize (or incentive) the organizations. He proposed a simple way to give organizations credit in addition to individual credits for the core issues their teams either performed directly or sponsored, which the Drupal Association released in late 2015. Over time, this system has been expanded to capture more than just code contributions.

And yet, the contribution credit system has not wholly replaced karma. As my own experience shows, so much of the vital work that Drupal relies on is not yet captured in credits. Due to my privilege (not looking for a job, having well-established connections in the community, etc.), the lack of visibility was a feature, not a bug, for me as an individual contributor.

However, wearing my Palantir CEO hat I’ve come to realize that the failure to capture fully what and how companies do (and are expected) to contribute is far more problematic for the sustainability of the project. Some of the most essential work in the community (Drupal Association Board of Directors, the Community Working Group (CWG), the Security Team and non-code Core team work including release management, communication, sprint organizing and overall project and initiative coordination) is severely undervalued or all-in-all ignored by the contribution system. George DeMet's ongoing commitments as the chair of the CWG often average anywhere from ¼ - ½ of his time (more at intense times) and over the last year he received four credits (the other members of the CWG received even less!). The community and the project suffer because this invisibility obscures, and indeed over time deteriorates, the community expectations and norms by measuring what is easy, rather than what matters.

When Drupal 7 was released, the firms that built Drupal enjoyed a competitive advantage: those who wanted to use Drupal knew which firms meaningfully contributed and why it mattered. However, over the last five years, the Drupal ecosystem has expanded to include many new, larger firms that leveraged partnership and sponsorship programs to establish their Drupal credentials.

These programs and the new implementers and agencies they ushered into the Drupal community are essential to Drupal’s growth and adoption. They are a welcome addition to the ecosystem. However, there are serious problems with the ways that these programs have been structured to date and their unintended impact on our culture of contribution:

  • Status within these programs is primarily pay-to-play and non-financial contributions to the project are not required.
  • The programs do not directly directly support or indirectly incentivize the time or talent contributions on which the Drupal project depends.
  • The financial proceeds of such programs benefit infrastructure initiatives ( and more broadly the Association) and market visibility, which are not necessarily the areas of greatest need for the project or community.
  • These programs have undermined the reputational system that prioritized successful outcomes (successful client implementations AND contributions back to the project) and replaced it with one that favored outputs (financial success and client list).

Allowing companies to position themselves as leading experts in Drupal without validation that these firms are contributing commensurate with the benefits derived from Drupal has been corrosive to the sustainability of the project. This has tacitly supported the commoditization of Drupal services, devalued the competitive advantage received from direct contribution, and simultaneously incentivized and conditioned all in the ecosystem to increase indirect contribution (sponsorship and advertising on and events including DrupalCon).

As I noted on a panel at OSCON, I see all of this as a success problem. Having more companies, including large scale implementers and agencies, working with Drupal is a good and necessary thing. What we need to improve is the way that we onboard, recognize, and differentiate those who help sustain and innovate Drupal to (re)establish a culture of contribution for Drupal. Doing this well will involve creating new and easy-to-access avenues for contribution that match the project’s weighted needs and companies’ available resources (be they time, talent or treasure). A concerted focus on what matters will shore up Drupal’s path to long-term sustainability.

Community Drupal Open Source People

Event Organizers: Making it Official

Fri, 2019/08/30 - 6:10pm

For over a decade* the Drupal community has gathered in volunteer-led “camps”, based on the BarCamp model, to follow in that camp’s initial goals:

  • Introduce web developers to the Drupal platform.
  • Skill sharing among established Drupal developers
  • Give back to the Drupal project (e.g. fix bugs, documentation, lesson materials)

The scope of Drupal Camps has expanded as our community has grown and matured, and camps now serve everyone in the community, not just developers. They serve as an on-ramp for new developers, a networking opportunity for clients and agencies, a marketing opportunity for service providers, and much more.

The Drupal Event Organizers have documentation of over 50 volunteer-led events with over 10,000 attendees worldwide in the past year, and we know there are almost double this number that we don’t have good data for. These events have evolved organically, with little central organization, and are estimated to comprise more than one million dollars in sponsorship and ticket sales worldwide, yearly.

The Event Organizers have organized in various forms over that time… from various documentation efforts to our current monthly meeting format. With Kaleem’s instigation, the group started toward a more formal organization in late 2018, and that process is almost a reality. 

We’ve established a formation board composed of organizers from across the globe and have been collaborating on a charter for the Event Organizers Working Group over the past few months. We’re looking forward to presenting it soon and beginning the next chapter of the Drupal Event Organizers.

Thanks to the following folks who have contributed to the effort thus far.

Our Formation Board members:

And our trusted advisers:

* Possibly starting at Drupal Camp Toronto, 2006? If you know of an earlier camp, please let us know in the comments.


Code Karate: Custom Entities with Drupal Console

Fri, 2019/08/30 - 4:37pm
Episode Number: 226

In the last episode we covered creating a Drupal 8 module with Drupal Console. In the episode before that, we covered using the Drupal 8 ECK module to create custom entities. In this episode, we cover how you can use Drupal Console to scaffold out custom entities on your Drupal 8 website.

Tags: DrupalDrupal 8Drupal Planet

OSTraining: How to Create a Masonry-Like View in Drupal 8

Thu, 2019/08/29 - 7:53pm

Masonry is a very popular JavaScript library, that stacks items in columns and rows, like a masonry brick wall.

The items reorder themselves according to their size as the viewport size changes with a nice animation effect. For some examples, take a look at the official Masonry site.

It is possible to create a view in Drupal with this style of layout. Keep reading to learn how!


Cheeky Monkey Media: Module Mayhem in the Drupal Kitchen

Thu, 2019/08/29 - 7:31pm
Module Mayhem in the Drupal Kitchen kodie Thu, 08/29/2019 - 17:31

In my opinion, there’s nothing in the world quite like learning a new skill. It’s a huge rush figuring out how to do something you didn’t know how to do before. You start with the basics, and then once you’ve got the gist of it, you begin to improve. Over time you’ll get better at it, and you’ll get faster at it. Aside from just improving your abilities, your confidence level might change too. This process can go a few different ways. One is imposter syndrome, where you feel like a fraud that doesn’t know what they’re doing. The other is overconfidence, where you think that your skills are better than they are. Be it due to imposter syndrome, overconfidence, or just plain ol’ inexperience; you’re bound to make some mistakes. And we don’t wanna make mistakes, do we?


Hook 42: Quickly Find out What’s Being Processed in Your Migration Pipeline

Thu, 2019/08/29 - 4:55pm
Quickly Find out What’s Being Processed in Your Migration Pipeline Darryl Richman Thu, 08/29/2019 - 14:55

Code Karate: Generating A Module with Drupal Console

Thu, 2019/08/29 - 3:59pm
Episode Number: 225

Drupal Console is a command line tool for Drupal (similar to Drush) that has built in code generation tools. This makes it easy to generate boilerplate code for a custom Drupal 8 module. In this episode, we discuss how to use Drupal Console to generate an example module with an administrative settings form.

Tags: DrupalFormsDrupal 8Module DevelopmentDrupal Planet
Categories: Blog: Agiledrop recognized as a top Drupal development company by

Thu, 2019/08/29 - 10:11am

In a recent press release, declared Agiledrop one of 2019’s best Drupal development firms in the world. With over 10 years of extensive Drupal expertise and several Acquia certified developers, we see this recognition as a true testament to the quality of our work, both with clients and within the Drupal community.


Agaric Collective: Using migration groups to share configuration among Drupal migrations

Thu, 2019/08/29 - 5:48am

In the previous posts we talked about option to manage migrations as configuration entities and some of the benefits this brings. Today, we are going to learn another useful feature provided by the Migrate Plus module: migration groups. We are going to see how they can be used to execute migrations together and share configuration among them. Let’s get started.

Understanding migration groups

The Migrate Plus module defines a new configuration entity called migration group. When the module is enabled, each migration can define one group they belong to. This serves two purposes:

  1. It is possible to execute operations per group. For example, you can import or rollback all migrations in the same group with one Drush command provided by the Migrate Tools module.
  2. It is is possible to declare shared configuration for all the migrations within a group. For example, if they use the same source file, the value can be set in a single place: the migration group.

To demonstrate how to leverage migration groups, we will convert the CSV source example to use migrations defined as configuration and groups. You can get the full code example at The module to enable is UD configuration group migration (CSV source) whose machine name is ud_migrations_config_group_csv_source. It comes with three migrations: udm_config_group_csv_source_paragraph, udm_config_group_csv_source_image, and  udm_config_group_csv_source_node. Additionally, the demo module provides the udm_config_group_csv_source group.

Note: The Migrate Tools module provides a user interface for managing migrations defined as configuration. It is available under “Structure > Migrations” at /admin/structure/migrate. This user interface will be explained in a future entry. For today’s example, it is assumed that migrations are executed using the Drush commands provided by Migrate Plus. In the past we have used the Migrate Run module to execute migrations, but this module does not offer the ability to import or rollback migrations per group.

Creating a migration group

The migration groups are defined in YAML files using the following naming convention: migrate_plus.migration_group.[migration_group_id].yml. Because they are configuration entities, they need to be placed in the config/install directory of your module. Files placed in that directory following that pattern will be synced into Drupal’s active configuration when the module is installed for the first time (only). If you need to update the migration groups, you make the modifications to the files and then sync the configuration again. More details on this workflow can be found in this article. The following snippet shows an example migration group:

uuid: e88e28cc-94e4-4039-ae37-c1e3217fc0c4 id: udm_config_group_csv_source label: 'UD Config Group (CSV source)' description: 'A container for migrations about individuals and their favorite books. Learn more at' source_type: 'CSV resource' shared_configuration: null

The uuid key is optional. If not set, the configuration management system will create one automatically and assign it to the migration group. Setting one simplifies the workflow for updating configuration entities as explained in this article. The id key is required. Its value is used to associate individual migrations to this particular group.

The label, description, and source_type keys are used to give details about the migration. Their value appear in the user interface provided by Migrate Tools. label is required and serves as the name of the group. description is optional and provides more information about the group. source_type is optional and gives context about the type of source you are migrating from. For example, "Drupal 7", "WordPress", "CSV file", etc.

To associate a migration to a group, set the migration_group key in the migration definition file: For example:

uuid: 97179435-ca90-434b-abe0-57188a73a0bf id: udm_config_group_csv_source_node label: 'UD configuration host node migration for migration group example (CSV source)' migration_group: udm_config_group_csv_source source: ... process: ... destination: ... migration_dependencies: ...

Note that if you omit the migration_group key, it will default to a null value meaning the migration is not associated with any group. You will still be able to execute the migration from the command line, but it will not appear in the user interface provided by Migrate Tools. If you want the migration to be available in the user interface without creating a new group, you can set the migration_group key to default. This group is automatically created by Migrate Plus and can be used as a generic container for migrations.

Organizing and executing migrations

Migration groups are used to organize migrations. Migration projects usually involve several types of elements to import. For example, book reports, events, subscriptions, user accounts, etc. Each of them might require multiple migrations to be completed. Let’s consider a news articles migration. The "book report" content type has many entity reference fields: book cover (image), support documents (file), tags (taxonomy term), author (user), citations (paragraphs). In this case, you will have one primary node migration that depends on five migrations of multiple types. You can put all of them in the same group and execute them together.

It is very important not to confuse migration groups with migration dependencies. In the previous example, the primary book report node migration should still list all its dependencies in the migration_dependencies section of its definition file. Otherwise, there is no guarantee that the five migrations it depends on will be executed in advance. This could cause problems if the primary node migration is executed before images, files, taxonomy terms, users, or paragraphs have already been imported into the system.

It is possible to execute all migrations in a group by issuing a single Drush with the --group flag. This is supported by the import and rollback commands exposed by Migrate Tools. For example, drush migrate:import --group='udm_config_group_csv_source'. Note that as of this writing, there is no way to run all migrations in a group in a single operation from the user interface. You could import the main migration and the system will make sure that if any explicit dependency is set, they will be run in advance. If the group contained more migrations than the ones listed as dependencies, those will not be imported. Moreover, migration dependencies are only executed automatically for import operations. Dependent migrations will not be rolled back automatically if the main migration is rolled back individually.

Note: This example assumes you are using Drush to execute the migrations. At the time of this writing, it is not possible to rollback a CSV migration from the user interface. See this issue in the Migrate Source CSV for more context.

Sharing configuration with migration groups

Arguably, the major benefit of migration groups is the ability to share configuration among migrations. In the example, there are three migrations all reading from CSV files. Some configurations like the source plugin and header_offset can be shared. The following snippet shows an example of declaring shared configuration in the migration group for the CSV example:

uuid: e88e28cc-94e4-4039-ae37-c1e3217fc0c4 id: udm_config_group_csv_source label: 'UD Config Group (CSV source)' description: 'A container for migrations about individuals and their favorite books. Learn more at' source_type: 'CSV resource' shared_configuration: dependencies: enforced: module: - ud_migrations_config_group_csv_source migration_tags: - UD Config Group (CSV Source) - UD Example source: plugin: csv # It is assumed that CSV files do not contain a headers row. This can be # overridden for migrations where that is not the case. header_offset: null

Any configuration that can be set in a regular migration definition file can be set under the shared_configuration key. When the migrate system loads the migration, it will read the migration group it belongs to, and pull any shared configuration that is defined. If both the migration and the group provide a value for the same key, the one defined in the migration definition file will override the one set in the migration group. If a key only exists in the group, it will be added to the migration when the definition file is loaded.

In the example, dependencies, migration_tag, and source options are being set. They will apply to all migrations that belong to the udm_config_group_csv_source group. If you updated any of these values, the changes would propagate to every migration in the group. Remember that you would need to sync the migration group configuration for the update to take effect. You can do that with partial configuration imports as explained in this article.

Any configuration set in the group can be overridden in specific migrations. In the example, the header_offset is set to null which means the CSV files do not contain a header row. The node migration uses a CSV file that contains a header row so that configuration needs to be redeclared. The following snippet shows how to do it:

uuid: 97179435-ca90-434b-abe0-57188a73a0bf id: udm_config_group_csv_source_node label: 'UD configuration host node migration for migration group example (CSV source)' # Any configuration defined in the migration group can be overridden here # by re-declaring the configuration and assigning a value. # dependencies inherited from migration group. # migration_tags inherited from migration group. migration_group: udm_config_group_csv_source source: # plugin inherited from migration group. path: modules/custom/ud_migrations/ud_migrations_csv_source/sources/udm_people.csv ids: [unique_id] # This overrides the header_offset defined in the group. The referenced CSV # file includes headers in the first row. Thus, a value of 0 is used. header_offset: 0 process: ... destination: ... migration_dependencies: ...

Another example would be multiple migrations reading from a remote JSON. Let’s say that instead of fetching a remote file, you want to read a local file. The only file you would have to update is the migration group. Change the data_fetcher_plugin key to file and the urls array to the path to the local file. You can try this with the ud_migrations_config_group_json_source module from the demo repository.

What did you learn in today’s blog post? Did the know that migration groups can be used to share configuration among different migrations? Share your answers in the comments. Also, I would be grateful if you shared this blog post with others.

This blog post series, cross-posted at as well as here on, is made possible thanks to these generous sponsors. Contact Understand Drupal if your organization would like to support this documentation project, whether it is the migration series or other topics.

Read more and discuss at


Agaric Collective: What is the difference between migration tags and migration groups in Drupal?

Thu, 2019/08/29 - 5:47am

In the previous post we talked about migration groups provided by the Migrate Plus module. Today, we are going to compare them to migration tags. Along the way, we are going to dive deeper into how they work and provide tips to avoid problems when working with them. Let’s get started.

What is the difference between migration tags and migration groups?

In the article on declaring migration dependencies we briefly touched on the topic of tags. Here is a summary of migration tags:

  • They are a feature provided by the core Migrate API.
  • Multiple tags can be assigned to a single migration.
  • They are defined in the migration definition file alone and do not require creating a separate file.
  • Both Migrate Tools and Migrate Run provide a flag to execute operations by tag.
  • They do not allow you to share configuration among migrations tagged with the same value.

Here is a summary of migration groups:

  • You need to install the Migrate Plus module to take advantage of them.
  • Only one group can be assigned to any migration.
  • You need to create a separate file to declare group. This affects the readability of migrations as their configuration will be spread over two files.
  • Only the Migrate Tools provides a flag to execute operations by group.
  • They offer the possibility to share configuration among members of the same group.
  • Any shared configuration could be overridden in the individual migration definition files.
What do migration tags and groups have in common?

The ability to put together multiple migrations under a single name. This name can be used to import or rollback all the associated migrations in one operation. This is true for the migrate:import and migrate:rollback Drush commands provided by Migrate Plus. What you have to do is use the --group or --tag flags, respectively. The following snipped shows an example of importing and rolling back the migrations by group and tag:

$ drush migrate:import --tag='UD Config Group (JSON Source)' $ drush migrate:rollback --tag='UD Config Group (JSON Source)' $ drush migrate:import --group='udm_config_group_json_source' $ drush migrate:rollback --group='udm_config_group_json_source'

Note: You might get errors indicating that the "--tag" or "--group" options do not accept a value. See this issue if you experience that problem.

Neither migration tags nor groups replace migration dependencies. If there are explicit migration dependencies among the members of a tag or group, the Migrate API will determine the order in which the migrations need to be executed. But if no dependencies are explicitly set, there is no guarantee the migrations will be executed in any particular order. Keep this in mind if you have separate migrations for entities that you later use to populate entity reference fields. Also note that migration dependencies are only executed automatically for import operations. Dependent migrations will not be rolled back automatically if the main migration is rolled back individually.

Can groups only be used for migrations defined as configuration entities?

Technically speaking, no. It is possible to use groups for migrations defined as code. Notwithstanding, migration groups can only be created as configuration entities. You would have to rebuild caches and sync configuration for changes in the migrations and groups to take effect, respectively. This is error prone and can lead to hard to debug issues.

Also, things might get confusing when executing migrations. The user interface provided by Migrate Plus works exclusively with migrations defined as configuration entities. The Drush commands provided by the same module work for both types of migrations: code and configuration. The default and null values for the migration_group key are handled a bit different between the user interface and the Drush commands. Moreover, the ability to execute operations per group using Drush commands is provided only by the Migrate Tools module. The Migrate Run module lacks this functionality.

Managing migrations as code or configuration should be a decision to take at the start of the project. If you want to use migration groups, or some of the other benefits provided by migrations defined as configuration, stick to them since the very beginning. It is possible to change at any point and the transition is straightforward. But it should be avoided if possible. In any case, try not to mix both workflows in a single project.

Tip: It is recommended to read this article to learn more about the difference between managing migrations as code or configuration.

Setting migration tags inside migration groups

As seen in this article, it is possible to use set migration tags as part of the shared configuration of a group. If you do this, it is not recommended to override the migration_tags key in individual migrations. The end result might not be what you expect. Consider the following snippets as example:

# Migration group configuration entity definition. # File: migrate_plus.migration_group.udm_config_group_json_source.yml uuid: 78925705-a799-4749-99c9-a1725fb54def id: udm_config_group_json_source label: 'UD Config Group (JSON source)' description: 'A container for migrations about individuals and their favorite books. Learn more at' source_type: 'JSON resource' migration_tags: - UD Config Group (JSON Source) - UD Example # Migration configuration entity definition. # File: migrate_plus.migration.udm_config_group_json_source_node.yml uuid: def749e5-3ad7-480f-ba4d-9c7e17e3d789 id: udm_config_group_json_source_node label: 'UD configuration host node migration for migration group example (JSON source)' migration_tags: - UD Lorem Ipsum migration_group: udm_config_group_json_source source: ... process: ... destination: ... migration_dependencies: ...

The group configuration declares two tags: UD Config Group (JSON Source) and UD Example. The migration configuration overrides the tags to a single value UD Lorem Ipsum. What would you expect the final value for the migration_tags key be? Is it a combination of the three tags? Is it only the one key defined in the migration configuration?

The answer in this case is not very intuitive. The final migration will have two tags: UD Lorem Ipsum and UD Example. This has to do with how Migrate Plus merges the configuration from the group into the individual migrations. It uses the array_replace_recursive() PHP function which performs the merge operation based on array keys. In this example, UD Config Group (JSON Source) and UD Lorem Ipsum have the same index in the migration_tags array. Therefore, only one value is preserved in the final result.

The examples uses the migration_tags key as it is the subject of this article, but the same applies to any nested structure. Some configurations are more critical to a migration than a tag or group. Debugging a problem like this can be tricky. But the same applies to any configuration that has a nested structure. If the end result might be ambiguous, it is preferred to avoid the situation in the first place. In general, nested structures should only be set in either the group or the migration definition file, but not both. Additionally, all the recommendations for writing migrations presented in this article also apply here.

What did you learn in today’s blog post? Did you know the difference between migration tags and groups? Share your answers in the comments. Also, I would be grateful if you shared this blog post with others.

This blog post series, cross-posted at as well as here on, is made possible thanks to these generous sponsors. Contact Understand Drupal if your organization would like to support this documentation project, whether it is the migration series or other topics.

Read more and discuss at


Code Karate: Drupal 8 Entity Construction Kit (ECK) Module

Thu, 2019/08/29 - 3:35am
Episode Number: 224

The Drupal 8 Entity Construction Kit (ECK) Module allows you to use the Drupal admin interface to build custom entity types. Sometimes you need additional data structures in your Drupal site and it doesn’t make sense to create it as a content type, this is where the ECK module comes in. Using it, you can create your custom entity data structures in Drupal 8 and add fields to them, similarly to how you build out content types.

Tags: DrupalDrupal 8Site BuildingDrupal Planet

Mediacurrent: [Webinar] Usability Testing: How Builds Great Government UX

Thu, 2019/08/29 - 3:25am


Crafting UX - for the people, by the people takes a data-informed approach to site decisions. An open ear to constituent feedback ensures a "wicked awesome" user experience. So it's no surprise that when the site’s navigation needed improvement, user testing became a guiding light.

In our upcoming webinar, hear how Mediacurrent teams with on a user testing strategy leveraging Drupal 8 and Google Optimize. 

Join our webinar

Watch how to deliver a constituent experience that is discoverable, accessible, and truly “for the people, by the people.” Join us on September 18, 2019, at 2:00 EDT to follow along with our process. Learn tips to user test your way to better website UX. 

Register for the webinar.

You'll learn
  • Our approach to testing and gathering user feedback
  • The A/B testing variants we used to steer site navigation and layout
  • Deep dive into testing with Google Optimize 
  • Clair Smith, Senior Front End Developer, Mediacurrent
  • Becky Cierpich, UX/UI Designer, Mediacurrent

We hope to see you there!


Lullabot: Level Up Your Twiggery

Wed, 2019/08/28 - 10:40pm

Drupal 8’s templating language, Twig, provides a powerful suite of tools that often go underutilized. Learning when and where to apply them will empower you to create more readable and DRY code, and allow themers of all experience levels to contribute in a maintainable way.

To highlight some key concepts, let us consider a simple example—wrapping the Article node’s body field in a element. We start with this simple tweak to node--article.html.twig.


Hook 42: Hook 42 is Returning to BADCamp in 2019

Wed, 2019/08/28 - 9:08pm
Hook 42 is Returning to BADCamp in 2019 Lindsey Gemmill Wed, 08/28/2019 - 19:08

Drudesk: 7 characteristics of a good Drupal support agency

Wed, 2019/08/28 - 1:12pm

To always work smoothly and be up-to-date, your Drupal website needs support and maintenance. It’s nice to know you can rely on experts for things like Drupal updates, website performance audit, bug fixes, or anything else. However, you need to choose them carefully. 


Drupal Association blog: Welcome Carole Bernard to the Drupal Association

Tue, 2019/08/27 - 8:50pm

The Drupal Association (DA) is pleased to announce the recent hire of Carole Bernard as the Director of Marketing and Outreach. She and her team will focus on increasing visibility for the Drupal Association and opportunities for Drupal adoption through marketing, community engagement, volunteer management and public relations activities.

With extensive nonprofit and public sector experience, Bernard has served in senior leadership roles for more than 15 years at local, regional and national organizations.  

Bernard, a Boston native, began her career as a speechwriter for the Mayor of Boston. She then worked as the Director of Public Information for the largest human service agency in New England, Action for Boston Community Development, Inc. She started her own consulting business in 2015, providing strategic communications, fundraising and executive management services to nonprofit organizations in the Washington, DC area. She recently served as the Director of Communications and Marketing for Sickle Cell Disease Association of America, Inc. She also has worked for Paralyzed Veterans of America, National Center for Women and Children and the National Minority AIDS Council as their Director of Communication.

“I am so excited to be a part of the dynamic team at the Drupal Association,” says Bernard. “I am blown away by the passion and commitment of the Drupal community, and I look forward to working with everyone to tell the DA story, to showcase the Drupal project, to broaden the organization’s reach to new audiences and to increase opportunities for Drupal adoption around the world through strategic communications and outreach efforts.”

“We want to continue to position Drupal as the leading open-source CMS for ambitious digital experiences that reach audiences across multiple channels around the world,” says Heather Rocker, DA Executive Director. “We also want to expand our efforts to bring new entities and individuals to the table to participate in our global community. We are excited to have Carole join us and to help us lay out and execute a plan that leverages all of the DA assets for growth, inclusion, awareness and participation.”

Bernard received her bachelor’s degree in Political Science from Framingham State College and her master’s degree in Journalism from Boston University.


Code Karate: Drupal 8 URL Embed Module

Tue, 2019/08/27 - 4:42pm
Episode Number: 223

The Drupal 8 URL Embed Module makes it easy to add embeddable URL’s into your Drupal website. What exactly is an embeddable URL? It’s an easy way to turn your links to popular social sites such as Twitter, YouTube, Facebook, Instagram, Spotify, and more into a nicely formatted embed code that displays a preview of the content directly on your site.

Tags: DrupalDrupal 8MediaSite BuildingSocial ToolsDrupal Planet