Abico aptent erat gilvus immitto lenis nisl os pala virtus. Augue caecus neo nostrud pagus secundum valetudo vero. Dolore jumentum melior quae ullamcorper. Abbas exputo iusto modo quae ullamcorper uxor vulputate. Abbas aliquam aliquip inhibeo mos vel. Abbas aliquam brevitas commodo dolor macto populus premo sino. Abico aliquip causa consectetuer diam dolus imputo jugis obruo olim.

Accumsan caecus eros esca eu huic letalis metuo vereor zelus. Immitto macto os pneum praemitto sudo vereor. Aliquam loquor luptatum nulla pertineo praemitto tum ut virtus.

Eros te usitas. Diam distineo erat facilisi humo lucidus nulla occuro quibus vel. Abluo eu jumentum lucidus minim neque quidem tamen ymo. Commoveo defui eros pecus quadrum sed si tincidunt uxor.

Abbas facilisis nibh nisl similis tation. Appellatio ex ibidem immitto pala valde. Decet esca nutus oppeto pecus si tum valde venio. Dolore facilisis inhibeo interdico molior te. Dolor eros facilisi facilisis genitus haero letalis obruo torqueo. Abluo at conventio diam duis eros iusto molior sudo ymo.

Acsi comis mauris saluto. Augue brevitas caecus neo nibh tamen validus. Blandit eligo eu hos quia scisco voco volutpat ymo. Distineo erat gilvus lenis quae vero. Capto consequat iaceo in jus quae ullamcorper. Humo magna nutus os quadrum singularis usitas.

Caecus distineo neque si ymo. Exerci hos pagus similis velit. Abbas aptent brevitas capto hendrerit in pertineo. Acsi hendrerit occuro odio roto saluto sed tum vicis zelus. Duis exerci jumentum meus nisl oppeto premo proprius sudo suscipere. Capto mauris neque secundum. Cogo cui et pneum torqueo. Euismod iusto neo nostrud. Hendrerit usitas volutpat.

Aptent caecus ibidem loquor nulla secundum tamen. Facilisis iriure iustum paratus tincidunt. Quidne turpis ullamcorper. Accumsan aliquip at facilisi premo sit tego torqueo virtus. Hos incassum iustum lucidus nobis plaga. Dolus esca eum jus validus ymo. Ad bene consectetuer erat obruo utinam virtus. Abico comis cui exerci incassum scisco. Diam pertineo sed sudo. At facilisi mauris praemitto quis vulputate.

Adipiscing brevitas dignissim hendrerit os qui suscipere vereor. Diam huic natu nisl veniam. Abdo eros iaceo iustum lobortis melior oppeto probo tum vulputate. Feugiat genitus nimis. Diam eligo elit esca fere laoreet paratus tamen. Conventio defui diam elit obruo oppeto pagus premo voco volutpat.

Dolore feugiat jumentum obruo proprius quadrum validus velit verto. Antehabeo in lenis. Erat praesent quidem vulpes wisi. Consectetuer jumentum mos vindico. Abico causa fere humo nisl olim sudo suscipit ulciscor venio. Abigo ea eu nutus suscipit. Consequat genitus humo metuo minim nibh roto rusticus tincidunt utrum. Esse lenis pecus tum turpis usitas. Dolor et ibidem lobortis melior olim tum utinam vulpes.

Accumsan eligo esca gemino importunus in ludus melior paulatim tego. Acsi camur feugiat iriure quae sed ymo. Eum meus nunc quidne virtus. Caecus jumentum neque suscipit wisi. Cui duis eu haero letalis ludus plaga ut valde. Acsi eligo immitto quibus si tum. Antehabeo tincidunt wisi. Blandit facilisis importunus laoreet.

Accumsan hos si. Enim letalis minim suscipit valde valetudo vicis. Comis occuro torqueo ullamcorper. At blandit dolus haero hendrerit ille jus verto. Abluo at consequat immitto in olim sed volutpat. At nibh velit. Autem esse facilisis secundum sudo. At augue incassum quidne voco vulpes. Melior paratus scisco. Dignissim haero modo molior sed vereor vulpes.

Sign up to be notified when Agaric gives an online or in-person migration training:

Learning objectives

• Step through the Drupal installation process.
• Create nodes and understand their properties.
• Create content types and add fields.
• Configure fields of different types.
• Create taxonomy vocabularies and terms.
• Create views to display listings of content.
• Create, place, and control the visibility of blocks.
• Override the presentation of nodes with Layout Builder.
• Understand the user and permission system.
• Understand the taxonomy system.
• Understand the menu system.
• Install and configure contributed modules and themes.
• Understand how Drupal can be extended to meet specific project needs.

Prerequisites

No previous experience with Drupal is needed.

Setup instructions

A working Drupal 11 installation using DDEV will be provided.

This training will be provided over Zoom. You can ask questions via text chat or audio. Sharing your screen is optional, but you might want to do it to get assistance on a specific issue. Sharing your camera is optional.

What to expect

Prior to the training

Attendees will receive detailed instructions on how to setup their development environment. In addition, they will be able to join a support video call days before the training event to make the the local development environment is ready. This prevents losing time fixing problems with environment set up during the training.

On the days of the training

• The training totals 7 hours of instruction, which we usually split into 2 sessions
• A team of developers available to answer questions and help with training-related issues

After the training

• Attendees will receive a copy of the training recording.
• Attendees will receive a certificate of completion.

Using a collaborative, co-design process grounded in design justice principles, Agaric will move your website to have mobile-first design, powerful content management capabilities, and built-in accessibility. The site will continually be improved with new features, strengthened security, and more joyous experience of use.

Aproach

Agaric adheres to high standards of collaboration, communication, active client participation, and transparency.

Using design and development processes that center the people who will be affected by the website, a core team from Agaric will work closely with you to define overall goals, key outcomes, and user stories.

Through collaborative design, which will proceed iteratively throughout the project, we will identify and build a minimum viable product, and subject that to a round of feedback and further research. In this context, as Zora Neale Hurston put it, "Research is formalized curiosity. It is poking and prying with a purpose." Critically, this is research with people using the website. We then take what we learned and use that to identify and build the next minimum viable improvement.

This learning is not just for us building the site but for everyone who has a stake in success for the goals for which the site is being built. The learning covers both the website's usability and its effectiveness in reaching your goals, including effectiveness in communicating to colleagues and the general public your values and goals. Ideally, Agaric's research with you and the people who are or will be visiting the site is continuous and collaborative, constantly informing continued development.

In the steps of clarifying need and customizing the solution (leveraging state of the art open source libre software), we prefer to write and work off of user stories that clearly define the website's purpose. This helps ensure that product owners, designers, and developers are on the same page. User stories describe software functionality from the perspective of the person using the software, including motivation or benefit, such as "A visitor can ".

We use an agile methodology to prioritize with you to put critical functionality first, getting a functional website in your hands as soon as possible for review. We continue this iterative and collaborative development cycle, typically in two week sprints, always building the highest impact functionality first.

Comparative analysis

No one is doing exactly what you will do, but identifying quality peers and reviewing their respective content helps you get a wider perspective both on what potential visitors may have seen elsewhere and what seems to be working for others— we can start thinking together about where to emulate and where to differentiate, informing all aspects of building the site to achieve your goals needs.

Content strategy

Building on the review of competitors, Agaric will briefly interview people who should be interacting with your site (from content creators to potential visitors) and develop personas and user stories.

Content style guide

Along with bringing consistency to cooperative output (and saving time sweating the details every time they come up), a good content (copywriting) style guide incorporates suggestions for clear and effective writing and helps your unique aspects shine through. It can help tell your story in a consistent way and help let your individual personalities show through while maintaining collective coherence.

Agaric's content style guide has not received the dedicated attention we recommend for our clients, but can still be a useful starting point for you.

From our discussion and review of your goals and audiences we recommend the following services, to be provided by Agaric in collaboration with the Drutopia cooperative web platform. Our agile method allows for flexibility throughout the project.

The Drutopia initiative builds powerful website software for grassroots groups and offers a Libre Software as a Service platform to make getting a website even easier for these groups. Drutopia members benefit from the collective development and maintenance of the software and platform; currently under the aegis of a not-for-profit, Drutopia plans to grow into its own cooperative.

May First Movement Technology is a non-profit cooperative which builds movements by advancing the strategic use and collective control of technology for local struggles, global transformation, and emancipation without borders. Together, through the cooperative, members buy information technology equipment to run websites, email, email lists, and just about everything else we do on the Internet. Drutopia is hosted on May First infrastructure, and Drutopia members become May First members.

Building on and with these cooperative initiatives, Agaric can focus our energy towards custom design or development that will benefit you.

Included Features

Cutting-Edge Website Capabilities

As a member organization of Drutopia, the your website will automatically gain access to the following features:

• Configurable homepage - that include but is not limited to any of the following: prominent elevator pitch, recent news feed, featured resources, upcoming events, partner organizations list, and a list of current campaigns.
• Actions
• Campaigns
• Events
• Fundraising
• Groups
• News and/or Blog
• Profile pages
• Social media integration
• SSL (all pages on the site reachable at secure, privacy-protecting https:// URLs)

Highly Secure Internal Tools

In addition to these benefits, we recommend [membership in May First Movement Technology] and will discount your Drutopia membership by the amount of a standard organization membership in May First ($50/year). As a result of this membership, you will gain access to additional services beyond the website, including the following:

• E-mail boxes and forwards
• Webmail
• NextCloud Files and Gallery (similar to Dropbox or Google Drive)
• OnlyOffice (integrated with NextCloud for online editing of word documents and spreadsheets)
• NextCloud Calendar and Tasks
• NextCloud Contacts
• NextCloud Bookmarks and Notes

We will work closely with your team to define an effective content strategy for your website and a clean, scalable information architecture. These will result in the following deliverables:

• Website goals
• User personas
• Content style guide
• Sitemap
• Technical architecture

Building off of the content strategy and information architecture work, we will work with your team to provide a compelling a theme that speaks to your audience and reinforces your brand.

We begin with our clean, responsive theme, with the following features baked in:

• Clean - simple design that puts your content first
• Secure - covered by the Drupal security team
• Accessible - works with assistive devices and keyboard-only navigation
• Responsive - looks beautiful on any device
• Extensible - well organized templates and Sass (style sheets)

We then identify and implement the customizations that will set your website apart and best tell your story, reflecting the unique voice and tone of your organization.

By leveraging Drutopia, we are able to quickly prototype with your team. After defining the information architecture we turn on all relevant features, and stub out the pages in the sitemap. We put on a collaborative training on how to work with the site and then allow your team to add content, test out the features and make note of any adjustments that would be helpful to the project.

We will then work closely together to prioritize remaining enhancements to be made to the website. Enhancements that do not make it into the initial build are added to our backlog for the Drutopia project as a whole.

Content Migration

Agaric staff will work with the you to move content from an existing website to your .

This plan will consist of manual migration work to move content from existing pages into the new website. Additionally, optional programmatic migration processes are available for moving user data and other content into Drupal. A redirect strategy will also be put in place for pages that are being culled from the old site.

Accessibility

It is critical that your site be accessible to as many people as possible, including those using screen readers. To that end, all of our work is built to support compliance with W3C Web Content Accessibility Guidelines (WCAG) 2.0. The WCAG Guidelines, however, are not comprehensive and so we go beyond those guidelines to ensure high accessibility. Lastly, much of what makes a site accessible happens on the content entry and management side. We will provide resources for your content team so that after the site launches, you can rest assured that what you are creating is reaching as many people as possible.

SEO

Our developers will also follow SEO best-practice development and utilize Drupal's range of SEO-related features that allow administrators to edit page titles, implement human-readable and editable URLs, enter meta tags, and more. For further SEO-related services, we can also recommend SEO consultants.

Launching with a site on Drutopia means more than getting all of the features and functionality Drutopia has to offer. It also means joining a platform cooperative of like-minded people. The cooperative consists of a one member one vote model and an accountable leadership team. Joining the Drutopia platform includes:

• Secure hosting with timely security updates
• The ability to request new features and endorse existing ideas
• Quarterly updates on the project
• Ability to coordinate with fellow members to crowdfund special development sprints

When joining Drutopia your site launch is not the end, but rather the beginning. Drutopia is in continual communication with all its members about what enhancements team members should work on next. Drutopia's roadmap is public to all so you know where the project is heading.

Agaric, as both your partner in maintaining your website and as a Drutopia partner, is well positioned to help see your priorities become realized.

Content Strategy documents

Information Architecture

Design

Development

Migrating content into a Drutopia typically takes an additional 10 to 50 hours ($1,500 to $15,000), varying

We are experts in Drupal migrations. We can move content from your old site to your Drutopia site so that you can keep working with all of your old content, all while gaining access to the flexibility and functionality of Drupal.

For a potentially much lower cost option, in four hours ($600) we can make a static archive of your old site, remove interactive features, add a link to the new site, place the old site at a subdomain, and configure your site to allow visitors looking for pages that exist on the old site but not on the new site to pass through and reach the old site.

We do not charge extra for hosting the static site.

Drutopia Membership, Hosting & Services $50/month or $500/year.

There will be no license fees for any software.

Agaric, founded in 2006, is a worker-owned web development cooperative headquartered in Boston (USA), with worker-owners also in Minneapolis and in Managua, Nicaragua. We help organizations meet their goals and strengthen the free software movement by providing consulting in online technology strategy, by building and customizing high quality software, by training people and by speaking at events. We use design justice principles to help your online presence meet your goals and make real world impact. We build with proven software that gives you power and control over your website and online presence. We use and contribute to libre software whenever possible, creative commons license our documentation, and work under an open organization model.

We look forward to creating a better website for building a better world with you!

CKEditor is well-known software with a big community behind it and it already has a ton of useful plugins ready to be used. It is the WYSIWYG text editor which ships with Drupal 8 core.

Unfortunately, the many plugins provided by the CKEditor community can't be used directly in the CKEditor that comes with Drupal 8. It is necessary to let Drupal know that we are going to add a new button to the CKEditor.

Why Drupal needs to know about our plugins

Drupal allows us to create different text formats, where depending on the role of the user (and so what text formats they have available) they can use different HTML tags in the content. Also, we can decide if the text format will use the CKEditor at all and, if it does, which buttons will be available for that text format.

That is why Drupal needs to know about any new button, so it can build the correct configuration per text format.

Adding a new button to CKEditor

We are going to add the Media Embed plugin, which adds a button to our editor that opens a dialog where you can paste an embed code from YouTube, Vimeo, and other providers of online video hosting.

First of all, let's create a new module which will contain the code of this new button, so inside the /modules/contrib/ folder let's create a folder called wysiwyg_mediaembed. (If you're not intending to share your module, you should put it in /modules/custom/— but please share your modules, especially ones making CKEditor plugins available to Drupal!)

cd modules/contrib/
mkdir wysiwyg_mediaembed

And inside let's create the info file: wysiwyg_mediaembed.info.yml

name: CKEditor Media Embed Button (wysiwyg_mediaembed)
type: module
description: "Adds the Media Embed Button plugin to CKEditor."
package: CKEditor
core: '8.x'
dependencies:
  - ckeditor

Adding this file will Drupal allows us to install the module, if you want to read more about how to create a custom module, you can read about it here.

Once we have our info file we just need to create a Drupal plugin which will give info to the CKEditor about this new plugin, we do that creating the following class:

touch src/Plugin/CkEditorPlugin/MediaEmbedButton.php

With this content:

namespace Drupal\wysiwyg_mediaembed\Plugin\CKEditorPlugin;

use Drupal\ckeditor\CKEditorPluginBase;
use Drupal\editor\Entity\Editor;

/**
 * Defines the "wysiwyg_mediaembed" plugin.
 *
 * @CKEditorPlugin(
 *   id = "mediaembed",
 *   label = @Translation("CKEditor Media Embed Button")
 * )
 */
class MediaEmbedButton extends CKEditorPluginBase {

  /**
   * Get path to library folder.
   * The path where the library is, usually all the libraries are
   * inside the '/libraries/' folder in the Drupal root.
   */
  public function getLibraryPath() {
    $path = '/libraries/mediaembed';
    return $path;
  }

  /**
   * {@inheritdoc}
   * Which other plugins require our plugin, in our case none.
   */
  public function getDependencies(Editor $editor) {
    return [];
  }

  /**
   * {@inheritdoc}
   * The path where CKEditor will look for our plugin.
   */
  public function getFile() {
    return $this->getLibraryPath() . '/plugin.js';
  }

  /**
   * {@inheritdoc}
   *
   *  We can provide extra configuration if our plugin requires
   *  it, in our case we no need it.
   */
  public function getConfig(Editor $editor) {
    return [];
  }

  /**
   * {@inheritdoc}
   * Where Drupal will look for the image of the button.
   */
  public function getButtons() {
    $path = $this->getLibraryPath();
    return [
      'MediaEmbed' => [
        'label' => $this->t('Media Embed'),
        'image' => $path . '/icons/mediaembed.png',
      ],
    ];
  }
}

The class's code is pretty straightforward: it is just a matter of letting Drupal know where the library is and where the button image is and that's it.

The rest is just download the library and put it in the correct place and activate the module. If all went ok we will see our new button in the Drupal Text Format Page (usually at: /admin/config/content/formats).

This module was ported because we needed it in a project, so if you want to know how this code looks all together, you can download the module from here.

Now that you know how to port a CKEditor plugin to Drupal 8 the next time you can save time using Drupal Console with the following command:

drupal generate:plugin:ckeditorbutton

What CKEditor plugin are you going to port?

We believe in the freedom to move our data to whichever platforms best meets our needs. For that reason, we specialize in helping people migrate onto liberating software such as Drupal— and helping you learn how to do the same.

As the COVID-19 crisis continues, we will be announcing online trainings soon!

Join our trainings announcement list to be the first to get news of training opportunities:

In previous posts, we introduced the concept of defining migrations as configuration entities. These types of migrations can be executed from a user interface provided by the Migrate Tools module. In today’s article, we will present the workflow to import configuration entities and execute migrations from the user interface. Let’s get started.

Important: User interfaces tend to change. In fact, Migrate Tools recently launched a redesign of the user interface. Screenshots and referenced on-screen text might change over time. Some exposed settings might work, but give no feedback indicating a successful outcome. Some forms might only work with specific versions of modules. The goal is to demonstrate what is possible and what are the limitations of doing so. In general, executing migrations from the command line offers a better experience.

Getting the example code

You can get the full code example for today’s example at https://github.com/dinarcon/ud_migrations The module to use is UD configuration group migration (JSON source) whose machine name is ud_migrations_config_group_json_source.  It comes with three migrations: udm_config_group_json_source_paragraph, udm_config_group_json_source_image, and  udm_config_group_json_source_node. Additionally, the demo module provides the udm_config_group_json_source group.

You could install the module as we have done with every other example in the series. Instructions can be found in this article. When the module is installed, you could execute the migrations using Drush commands as explained in this article. But, we are going to use the user interface provided by Migrate Plus instead.

Importing configuration entities from the user interface

The first step is getting the configuration entities into Drupal’s active configuration. One way to do this is by using the "Single item" import from the "Configuration synchronization" interface. It can be found at /admin/config/development/configuration/single/import. Four configuration items will be imported in the following order:

1. The udm_config_group_json_source using "Migration Group" as the configuration type.
2. The udm_config_group_json_source_image using "Migration" as the configuration type.
3. The udm_config_group_json_source_paragraph using "Migration" as the configuration type.
4. The udm_config_group_json_source_node using "Migration" as the configuration type.

When importing configuration this way, you need to select the proper "Configuration type" from the dropdown. Otherwise, the system will make its best effort to produce a valid configuration entity from the YAML code you paste in the box. This can happen without a visual indication that you imported the wrong configuration type which can lead to hard to debug errors.

Note: If you do not see the "Migration" and "Migration group" configuration types, you need to enable the Migrate Plus module.

Another thing to pay close attention is changes in formatting when pasting code from a different source. Be it GitHub, your IDE, or an online tutorial, verify that your YAML syntax is valid and whitespaces are preserved. A single extraneous whitespace can break the whole migration. For invalid syntax, the best case scenario is the system rejecting the YAML definition. Otherwise, you might encounter hard to debug errors.

In today’s example, we are going to copy the YAML definitions from GitHub. You can find the source files to copy here. When viewing a file, it is recommended to click the "Raw" button to get the content of the file in plain text. Then, copy and paste the whole file in the designated box of the "Single item" import interface. Make sure to import the four configuration entities in the order listed above using the proper type.

To verify that this worked, you can use the "Single item" export interface located at /admin/config/development/configuration/single/export. Select the "Configuration type" and the "Configuration name" for each element that was imported. You might see some extra keys in the export. As long as the ones you manually imported are properly set, you should be good to continue.

Note that we included uuid keys in all the example migrations. As explained in this article, that is not required. Drupal would automatically create a uuid when the configuration is imported. But defining one simplifies the update process. If you needed to update any of those configurations, you can directly visit the "Single item" import interface and paste the new configuration. Otherwise, you would have to export it first, copy the uuid value, and add it to the code to import.

Executing configuration entities from the user interface

With the migration related configuration entities in Drupal’s active configuration, you should be able to execute them from the user interface provided by Migrate Tools. It is available in  "Manage > Structure > Migration" at /admin/structure/migrate. You should see the UD Config Group (JSON source) that was imported in the previous step.

Note: If you do not see the "Migration" link in "Manage > Structure" interface, you need to enable the Migrate Tools module.

This user interface will list all the migration groups in the system. From there, you can get to the individual migrations. You can even inspect the migration definition from this interface. It is important to note that only migrations defined as configuration entities will appear in this interface. Migrations defined as code will not be listed.

For the udm_config_group_json_source group, click the "List migrations" button to display all the migrations in the group. Next, click the "Execute" button on the udm_config_group_json_source_image migration. Then, make sure "Import" is selected as the operation and click the "Execute" button. Drupal will perform the import operation for the image migration. A success status message will appear if things work as expected. You can also verify that images where imported by visiting the files listing page at /admin/content/files.

Repeat the same process for the udm_config_group_json_source_paragraph and udm_config_group_json_source_node migrations. The final result will be similar to the one from the JSON source example. For import operations, the system will check for migration dependencies and execute them advance if defined. That means that in this example, you could run the import operation directly on the node migration. Drupal will automatically execute the images and paragraphs migrations. 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.

This example includes a paragraph migrations. As explained in this article, if you rollback the node migration, any paragraph associated with the nodes will be deleted. The Migrate API will not be aware of this. To fix the issue and recover the paragraphs, you need to rollback the paragraph migration as well. Then you re-import the paragraph and node migrations again. Doing this from the user interface involves more manual steps compared to running a single Drush command in the terminal.

Limitations of the user interface

Although you can import and execute migrations from the user interface, this workflow comes with many limitations.The following is a list of some of the things that you should consider:

• Updating configuration in production environments is not recommended. This can be enforced using the Configuration Read-only mode module.
• If the imported configuration entity did not contain a uuid, you need to export that configuration to get the auto generated value. This should be used in subsequent configuration import operations if updates to the YAML definition files are needed. Otherwise, you will get an error like "An entity with this machine name already exists but the import did not specify a UUID."
• The following operations to not provide any user interface feedback if they succeeded: "Rollback", "Stop", and "Reset". See this issue for more context.
• As of this writing, most operations for CSV sources fail if using the 8.x-3.x branch of the Migrate Source CSV module. See this issue for more context.
• As of this writing, the user interface for renaming columns in CSV sources produces a fatal error if using the 8.x-3.x branch of the Migrate Source CSV module. See this issue for more context.
• As of this writing, it is not possible to execute all migrations in a group from the user interface in one operation. See this issue for more context.
• The Migrate source UI module can be used to upload a file to be used as source in CSV migrations. As of this writing, a similar feature for JSON and XML files is not working. See this issue for more context.

To reiterate, it is not recommended to use the user interface to add configuration related to migrations and execute them. The extra layer of abstractions can make it harder to debug problems with migrations if they arise. If possible, execute your migrations using the commands provided by Migrate Tools. Finally, it is recommended to read this article to learn more about the difference between managing migrations as code or configuration.

What did you learn in today’s blog post? Did you know you can import migration related configuration entities from the user interface? Did you know that Migrate Tools provides a user interface for running migrations? Share your answers in the comments. Also, I would be grateful if you shared this blog post with others.

Next: Understanding the entity_lookup and entity_generate process plugins from Migrate Tools

This blog post series, cross-posted at UnderstandDrupal.com as well as here on Agaric.coop, 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.

When one starts working with migrations, it is easy to be overwhelmed by so many modules providing migration functionality. Throughout the series, we presented many of them trying to cover one module at a time. We did this to help the reader understand when a particular module is truly needed and why. But we only scratched the surface. Today’s article presents a list of migration related Drupal modules, all good for Drupal 8, for quick reference. Let’s get started.

Core modules

At the time of this writing, Drupal core ships with four migration modules:

• Migrate: provides the base API for migrating data.
• Migrate Drupal: offers functionality to migrate from other Drupal installations. It serves as the foundation for upgrades from Drupal 6 and 7. It also supports reading configuration entities from Drupal 8 sites.
• Drupal Migrate UI: provides a user interface for upgrading a Drupal 6 or 7 site to Drupal 8.
• Migrate Drupal Multilingual: is an experimental module required by multilingual translations. When they become stable, the module will be removed from Drupal core. See this article for more information.

Migration runners

Once the migration definition files have been created, there are many options to execute them:

• Migrate Tools: provides Drush commands to run migrations from the command line. It also exposes a user interface to run migrations created as configuration entities. It offers support for migration groups and tags. The module depends on Migrate Plus.
• Migrate Run: provides Drush commands to run migrations from the command line. It does not offer support for migration groups, but tags are supported.  The module does not depend on Migrate Plus.
• Migrate Upgrade: provides Drush support for upgrading a Drupal 6 or 7 site to Drupal 8.
• Migrate Manifest: provides a Drush command for running migrations using a manifest file. See this article for an example of using this module for Drupal upgrades.
• Migrate Scheduler: integrates with Drupal Core’s Cron API to execute migrations on predefined schedules.
• Migrate Cron: exposes a user interface to execute migrations when Cron is triggered. At the time of this writing, the module does not execute dependent migrations. Follow this issue for updates.
• Migrate source UI: provides a form for uploading files to use as source for already defined CSV, JSON, and XML migrations. At the time of this writing, it seems that JSON and XML migrations are not being detected. Follow this issue for updates.

Source plugins

The Migrate API offers many options to fetch data from:

• Migrate (core module): provides the `SqlBase` abstract class to help with fetching data from a database connection. See this article for an example. It also exposes the `embedded_data` plugin which allows the source data to be defined inside the migration definition file. It was used extensively in the example migrations of this series. It also offers the `empty` plugin which returns a row based on provided constants. It is used in multilingual migrations for entity references.
• Migrate Plus: combining various plugins, it allows fetching data in JSON, XML, and SOAP formats. It also provides various plugins for parsing HTML. See this article by Benji Fisher for an example. There is also a patch to add support for PDF parsing.
• Migrate Source CSV: allows fetching data from CSV files.
• Migrate Google Sheets: leverages Migrate Plus functionality to allow fetching data from Google Sheets.
• Migrate Spreadsheet: allows fetching data from Microsoft Excel and LibreOffice Calc files.
• Migrate Source YAML: allows fetching data from YAML files.
• WP Migrate: allows fetching data from a WordPress database.

Destination plugins

The Migrate API is mostly used to move data into Drupal, but it is possible to write to other destinations:

• Migrate (core): provides classes for creating content and configuration entities. It also offers the `null` plugin which in itself does not write to anything. It is used in multilingual migrations for entity references.
• Migrate Plus: provides the `table` plugin for migrating into tables not registered with Drupal Schema API.
• CSV file: example destination plugin implementation to write CSV files. The module was created by J Franks for a DrupalCamp presentation. Check out the repository and video recording.

Development related

These modules can help with writing Drupal migrations:

• Migrate (core): provides the `log` process plugin. See this article for an example of its use.
• Migrate Devel: offers Drush options for printing debug information when executing migrations. It also provides the `debug` process plugin. See this article for an example of its use.
• Migrate Process Vardump: provides the `vardump` plugin. It works like the `debug` plugin.

Field and module related

• Migrate Media Handler: provides migration process plugins to facilitate the migration into Drupal 8 media entities. The source can be Drupal 7 file or image fields. It also supports inline file embeds in rich text. It leverages the DOM parsing plugins provided by Migrate Plus.
• Media Migration: provides an upgrade path from Drupal 7 to Drupal 8 media entities. The source can be image fields and fields attached to media and file entities.
• Migrate File Entities to Media Entities: migrates Drupal 8.0 file entities to Drupal 8.5 media entities.
• Migrate Files: provides process plugins for migrating files and images.
• Webform Migrate: provides a plugin to help migrating from the Drupal 6 and 7 versions of the Webform module.
• Migrate HTML to Paragraphs: turns HTML markup into paragraph entities.
• Commerce Migrate: offers a general purpose migration framework for bringing store information into Drupal Commerce.
• Address: offers a process plugin to migrate data into fields of type address. It also provides an upgrade path from Drupal 7’s Address Field module. See this article for an example.
• Geofield: offers a process plugin to migrate data into fields of type geofield. See this article for an example.
• Office Hours: offers a process plugin to migrate data into fields of type office hours.
• Workbench Moderation to Content Moderation: migrates configuration from one module to the other.

Modules created by Tess Flynn (socketwench)

While doing the research for this article, we found many useful modules created by Tess Flynn (socketwench). She is a fantastic presenter who also has written about Drupal migrations, testing, and much more. Here are some of her modules:

• Migrate Directory: imports files from a directory into Drupal as managed files.
• Migrate Process S3: downloads objects from an S3 bucket into Drupal.
• Migrate Process URL: provides a process plugin to make it easier to migrate into link fields.
• Migrate Process Vardump: helps with debugging migrations.
• Many process plugins that wrap PHP functions. For example: Migrate Process Array, Migrate Process Trim, Migrate Process Regex, Migrate Process Skip, and Migrate Process XML.

Miscellaneous

• Feeds Migrate: it aims to provide a user interface similar to the one from Drupal 7’s Feeds module, but working on top of Drupal 8’s Migrate API.
• Migrate Override: allows flagging fields in a content entity so they can be manually changed by side editors without being overridden in a subsequent migration.
• Migrate Status: checks if migrations are currently running.
• Migrate QA: provides tools for validating content migrations. See this presentation for more details.

And many, many more modules!

What did you learn in today’s blog post? Did you find a new module that could be useful in current or future projects? Did we miss a module that has been very useful to you? Share your answers in the comments. Also, I would be grateful if you shared this blog post with others.

Next: Introduction to Drupal 8 upgrades

This blog post series, cross-posted at UnderstandDrupal.com as well as here on Agaric.coop, is made possible thanks to these generous sponsors: Drupalize.me by Osio Labs has online tutorials about migrations, among other topics, and Agaric provides migration trainings, among other services.  Contact Understand Drupal if your organization would like to support this documentation project, whether it is the migration series or other topics.

Thank you for being awesome!  Use this page to register with your discount. If you want to attend more than one training, fill out the form once per training.

Ben and Micky spoke at DrupalCon Seattle 2019 and New England Drupal Camp 2019 about scaling community conversations and decision-making.  Rather than having slides of fine print and links, we're posting resources here in this blog post.

Here's a short-enough-to-write-on-a-business-card link for this page – agaric.coop/scaling-community – for easier sharing these resources with others.

350.org is a global climate justice organization that helped organize the largest climate strike in history. Together we improved their Climate Justice Action Map (CJAM) in the lead up to the strike so that activists could better mobilize their communities.