In light of the recent COVID-19 pandemic - OPTASY would like to offer DRUPAL website support for any Health Care, Government, Education and Non-Profit Organization(s) with critical crisis communication websites or organizations directly providing relief. Stay Safe and Stay Well.

Wordpress to Drupal 8 Migration

by Adrian Ababei on Feb 24 2015

Wordpress to Drupal 8 migration setup

Here’s an example of an existing WordPress site, which has registered users with comments, anonymous comments and an archive of previous postings with metadata (tags) that we will import. We’ll finish with this posting displayed in Drupal 8 version of the blog.

The following tables in Wordpress are relevant to the migration:

  • wp_posts (contains blog posts and pages)
  • wp_comments (comments)
  • wp_users (users)
  • wp_terms (categories - taxonomy)

We will started writing our migration module using Migration API (migrate) that comes packaged with D8 core. As usual in Drupal 8 module development, we had .info.yml, files, which uses the Symfony 2 YAML to map data types into an XML-like schema for easy migration from one environment to another, and traditional Drupal .module files. The only thing worth noting here is a dependency on the migrate module in our info.yml file.

For each Entity migration (users, posts, comments) we created 2 more files:

Code breakdown

Users

Let start understanding things by migrating Users first. Here is the complete user YAML file for this migration. Let’s break it down:

In this migrate.migration.users.yml file, ID, Source, Destination and Process (field mapping) are important keys.

 

id: users # Links this file with wordpress.migrate.yaml

label: Wordpress Users

migration_groups:

  - Wordpress

ID key is ‘users’ which has been referred in manifest_wordpress.yml and also in Source Plugin (User.php) as part of Annotation.

 

source:

  plugin: users

Source key is referring to Source Plugin (User.php) created by us to fetch Wordpress users data, which we will see shortly in detail.

 

destination:

  plugin: entity:user

Destination key is user entity as defined by Migration API.

 

process:

  uid: id

  name: user_login

  pass: user_pass

  mail: user_email

  status:

    -

     plugin: default_value

     default_value: 1

  created:

    -

     plugin: callback

     callable: strtotime

     source: user_registered

Process is key to mapping source (Wordpress) and destination (Drupal) fields. Some fields are mapped directly like ‘id’ with ‘sid’ while some fields are pre-processed by Migration API before being assigned to a destination field. For instance, ‘user_registered’ will be processed by PHP function strtotime() before it’s value gets assigned to destination field, because the target Drupal site must recognize those users as registered to associate their previous activity in WordPress with their Drupal activity on the new site. We can even write our own process plugins if required.

Now let’s look at Source Plugin (Users.php) which has been used to fetch the Wordpress users data,

 

<?php

/**

* @file

* Contains \Drupal\migrate_wordpress\Plugin\migrate\source\Users.

*/

namespace Drupal\migrate_wordpress\Plugin\migrate\source;

use Drupal\migrate\Row;

use Drupal\migrate\Plugin\SourceEntityInterface;

use Drupal\migrate_drupal\Plugin\migrate\source\DrupalSqlBase;

/**

* Extracts users from Wordpress database.

*

* @MigrateSource(

*   id = "users"

* )

*/

Remember the id field in the YAML file? The id field tells Drupal that this class should be used to process data for that migration set, taking the results of “users” in WordPress and adding them to a new table in the Drupal database, wp_users.

 

class Users extends DrupalSqlBase implements SourceEntityInterface {

  /**

   * {@inheritdoc}

   */

  public function query() {

    return $this->select('wp_users', 'u')

      ->fields('u', array_keys($this->userFields()));

  }

The query() method is used to fetch records from Wordpress database table (wp_users).

 

  /**

   * Returns the User fields to be migrated.

   *

   * @return array

   *   Associative array having field name as key and description as value.

   */

  protected function userFields() {

    $fields = array(

      'id' => $this->t('User ID'),

      'user_login' => $this->t('Username'),

      'user_pass' => $this->t('Password'),

      'user_email' => $this->t('Email address'),

      'user_registered' => $this->t('Created time'),

    );

    return $fields;

  }

  /**

   * {@inheritdoc}

   */

  public function fields() {

    $fields = $this->userFields();

  }

userFields() method is called in query() and fields() methods. It contains the list of fields that describe a WordPress user along with their field descriptions.

 

  /**

   * {@inheritdoc}

   */

  public function bundleMigrationRequired() {

    return false;

  }

  /**

   * {@inheritdoc}

   */

  public function entityTypeId() {

    return 'users';

  }

  /**

   * {@inheritdoc}

   */

  public function getIds() {

    return array(

      'id' => array(

        'type' => 'integer',

        'alias' => 'u',

      ),

    );

  }

As we are also implementing an interface SourceEntityInterface, we need to define 2 more methods namelybundleMigrationRequired() and entityTypeId() to map user-generated content, such as postings and comments, to Drupal. The getIds() method is used to return the key field for this Entity.

Posts

The Posts Entity migration (YAML, Source Plugin) is quite similar to User Entity migration. There is one additional method prepareRow() defined in post migration source plugin. This method gets called for each row to do an additional processing of the source data.

 

public function prepareRow(Row $row) {

$post_type = $row->getSourceProperty('post_type');

$type = $post_type == 'page' ? 'page' : 'article';

$row->setSourceProperty('type', $type);

return parent::prepareRow($row);

}

In this method, we are first checking the post type of source data and based on that we set the ‘type’ property. As we have two types of posts in Wordpress (Pages, Blogs posts) we want to map them to two content types in Drupal (Basic page, Article). The ‘type’ property is available in the post-migration YAML file Process step, as discussed above, and we have mapped it to the Drupal content type field.

Comments

The Comments Entity migration is more or less similar to Users and Posts migration. There are some following additions in Comments migration YAML file which are quite interesting to know.

 

uid:

-

   plugin: skip_process_on_empty

   source: user_id

-

   plugin: migration

   migration: users

'comment_body/value': comment_content

'comment_body/format': 'basic_html'

migration_dependencies:

required:

   - posts

   - users

Here we are using ‘skip_process_on_empty’ plugin which means skip the process if the source value is empty. As key fields can have different values in source and destination databases so we are using migration plugin to map ‘user_id’ field with ‘uid’ field. This will look for destination id in migration map tables for given source id (user_id).

Next, the ‘comment_body’ field is a text field and made up of two fields in Drupal 8, so we must map the Wordpress ‘comment_content’ field to value field and mapping basic html to format field. Next we have defined comment migration dependencies to posts and users which means comments will be migrated once both posts and users are already migrated.

Putting it all together

Finally you can run the migration using 'migrate-manifest' drush command as below. Make sure to run this command in Drush 7.

 

drush migrate-manifest manifest_wordpress.yml --legacy-db-url=mysql://{dbuser}:{dbpass}@localhost/{dbname}

The manifest_wordpress.yml is a YAML file which contains reference to IDs of each migration (users, posts, comments etc.).

 

# A Wordpress posts/users/comments migration, with dependencies.

- posts

- users

- comments

Finished: WordPress postings shown in Drupal

Development

We do Web development

Go to our Web development page!

Visit page!

Recommended Stories

10 Best Headless CMS in 2020, That Cover Most of Your Requirements (Part 2)
Ready to compare the features of 5 other best headless CMS in 2020?   We've got them ready for you to just dive in and: survey the key reasons why you'd want to choose one over the other discover each one's main use cases narrow down your options … and pick the one that matches your requirements. What Is the Best Headless CMS in 2020? 5.6. Directus An open source tool for managing and delivering content across an entire network of platforms and devices. And here are some of the top reasons for choosing Directus: it provides your editorial team with an easy to use admin app for managing content it can be in the cloud or self-hosted it provides API for your development team to fetch content 5.7. Netlify CMS  One of your top 10 headless CMS options, an open source one, that you get to add to any static site generator of your choice. A React single-page application that provides you with an easy to use UI, playing the role of a… wrapper for your Git Workflow. Basically, when using Netlify CMS your content gets stored in your web app's git repository (as markdown files), close to your codebase.   "How does a Netlify CMS Gatsby setup work?"   It's pretty straightforward: You enter your content via that user-friendly interface, then Gatsby uses it to come up with the right pages for your web app. Why would you use it? it fits both large and small-sized projects, with fewer pages to create, add content to, to edit, and to manage you get to review/preview your content and make changes in real-time, and even control entries status in editorial workflow mode it provides you with an easy-to-use UI, with just 3 tabs: workflow, media, and content you're free to use it with any static site generator you get to extend its functionality: add your own UI widgets, editor plugins, customized previews, etc. 5.8. GraphCMS     An API-first content management system, a GraphQL-native one, that allows you to distribute content across multiple digital platforms. And not just anyhow, but… within minutes. Your developer team gets to create content APIs in no time, whereas your content team gets all the tools they need for a smooth editor experience.   Source: capterra.com GraphCMS vs Contentful: Main Differences GraphCMS works best for enterprise and mid-market companies, enabling them to build highly scalable applications GraphQL is its underlying technology: an open source query language for APIs, that's been growing more and more popular among developers Contentful targets top global brands, helping them distribute digital content experiences across complex networks of markets and channels REST is its underlying technology: a programming paradigm for distributed systems And here are 2 good reasons for choosing GraphCMS as your go-to headless content management system:  you get a CMS that's client-side and JAMstack compatible you get to tap into the benefits of a JAMstack approach to development (JavaScript &amp; Markup &amp; API) 5.9. Cosmic A cloud-hosted headless content management system that provides you with both GraphQL and REST APIs. But What makes Cosmic one of the best headless CMS in 2020? Why choose the Cosmic Headless CMS?  it ships with features like content modeling, media management, localization, and webhooks it grants you a smooth editor experience with its WYSIWYG  editor, that you can use to incorporate (by embedding code) third-party services like Typeform and GitHub. it integrates smoothly with AWS, Slack, Algolia, Stripe, HubSpot 5.10. Kentico Kontent A cloud-based content delivery API that turns your structured content into content that's easy to be "consumed" by any device or digital platform that you might use as a front-end delivery layer.  Why would you choose it over other great options of headless CMS? you get an AI chatbot when using Kentico Kontent it provides webhooks and custom elements that make third-party integrations a lot smoother you get content management API enabling content consumption And we've come to… the END of the list of 10 best headless CMS in 2020. Which one checks the most features off your list?   If you're facing a "Headless Drupal 8 vs Contentful" dilemma, we're here to: help you identify the one that works best for your business and your requirements make your headless CMS-based project work Just drop us a line!   Image by tdfugere from Pixabay   ... Read more
Adriana Cacoveanu / Sep 26'2020
10 Best Headless CMS in 2020, That Cover Most of Your Requirements (Part 1)
Overwhelmed with options? Are you building your first (e-commerce) headless CMS and you don't know what headless CMS platform to choose?  What are the best headless CMS in 2020, so you can at least narrow down your choices and start... somewhere? Which system matches most of your feature requirements? Here's a top 10: 1. But First: What Is a Headless CMS, More Precisely? Relax, I won't bore you with too many details — we already have an in-depth post on the differences between headless and traditional CMS. So, if we were to sum up the concept in just a few words, we could say that: A headless content management system is an architecture where content is separated from the presentation layer (the client-side front-end). Meaning that you get to create, store, and edit "raw" content (with no design or layout) in the backend and deliver it wherever needed —wearable, mobile app, website — via API. In short, what you get in a headless architecture is: a database to store your content in a dashboard for editing your content Source: Zesty.io As for the "head" that serves your content to the end-user : you're free to build your own front-end, from the ground up … and even multiple front-ends, if needed, that will all use calls from the API to retrieve and display content 2. … Then What's a Decoupled CMS? Headless CMS vs decoupled CMS: what's the difference? And why headless over decoupled? The role that the API plays… That's what makes the difference (and why you'd want to go for a headless approach): If, in a decoupled architecture, the API plays the role of an intermediary between back-end and front end, in a headless architecture the API can be used by any of the front-end portions for pulling data. In other words, a decoupled CMS does come with a built-in front-end delivery layer, that you can rely on, but a headless approach is an API-driven content repository. Which gives you more flexibility for delivering content to any type of display layer. … to multiple "heads". You're free to distribute it wherever it needs to get displayed. 3. Why Choose a Headless CMS? Top 9 Benefits Before I "divulge" the best headless CMS in 2020 to you, here's a shortlist of the key advantages of using a headless CMS software: you get to engage your customers with personalized content across an entire network of digital channels, at different stages in their journey you can deliver richer digital experience, tailored to each channel you gain platform independence you're free to choose your technology of choice you benefit from cross-platform support you get to manage your content from a central location and distribute it to multiple platforms/IoT-connected devices, in a universal format you're free to manage all your platforms from one interface your development team gets to choose the development framework of their choice, integrate new technologies and, overall… innovate you're free to redesign as often as you need to, without the dread of re-implementing your entire CMS from the ground up     4. … And When Should You Use It? 5 Best Use Cases  How do you know for sure that you need to adopt this approach? You know it because your scenario describes one of the following use cases for headless CMS: you're building a site using a technology you're familiar with you're building a website with a static site generator you're building a JS-based website or web app you're building a native mobile app you're building an e-commerce site and you know that the commerce platform you're using won't… cut the mustard as a CMS; or you need to enrich product info in your online store 5. What Are the Best Headless CMS in 2020? Top 10 "Which CMS should I use?" you wonder. "The one that meets most of your requirements…" So, you should start by pinning them down. What features are you looking for in a CMS? Maybe you need a system that should: be straightforward and easy to use for the marketers/non-technical people in your team be built on… Node be highly customizable and editable for your content team to be able to change overlay text, logo, background video/image be simple to set up integrate easily with Gatsby support multi-site setups not be tied up to (just) one specific database provide ease of content entry and rich-text support provide a granular permission system provide native support for content types What are the features that your project couldn't live without? Now, with that list of "mandatory" features at hand, just drill down through your top headless CMS options in 2020. Here they are: 5.1. Storyblok A purely headless CMS that ships with a visual editor, as well. Why would you go for Storyblok? What makes it one of the best headless CMS in 2020? it provides the experience of a page builder for all those non-technical users in your team: editors get to manage content via a more user-friendly interface it grants your developers easy access to the APIs they need 5.2. Prismic Its major selling point? It allows you to choose your own language, framework, technology… And these are the 3 good reasons to go with Prismic as your headless CMS: it allows you to model your content schema and to add your content you're free to choose whatever framework that meets your feature needs: React, Vue, Next, Nuxt, Node, Gatsby… you're free to choose either GraphQL or RESTful API to query content 5.3. Drupal 8 Headless CMS   Another great option is to exploit Drupal's headless capabilities and pair them with the JavaScript framework of your choice. Here are some of the best reasons why you'd use a Drupal 8 API-first architecture: Drupal's a mature and enterprise-level headless solution backed by a wide community, used by more than 1 million sites globally; you get to tap into its massive module collection and even create new custom ones to extend your website's functionality its JSON:API follows the JSON:API specification; developers in your team can start using the API even if they're not experts in working with Drupal you get to load your GraphQl schemas straight from your Drupal content repository; there's a specialized module for this: the GraphQL module you get to use all of  Drupal's famed features (granular access to content, processes, workflows, modules, etc.) right away; you get them out-of-the-box since the REST API is… rooted deep into Drupal 5.4. Strapi, One of the Best headless CMS for Gatsby. It's an open-source Node.js headless CMS, a "host it yourself" one, that allows you to build Node.js apps in… minutes. Why would you use it? because it generates available RESTful API or uses GraphQL shortly after installation, making data available via customizable API because it allows your developers to invest all their resources in writing reusable app logic (instead of having to use some of that time to build an infrastructure) because it's fully JavaScript because it supports plugins that extend the platform's functionality because it's open-source: you'll find the entire codebase on GitHub  5.5. Contentful  Looking for a platform-agnostic solution? A… content delivery network that would enable your development team to manage and distribute (and reuse) content to multiple channels? Then this is the API-driven headless CMS you're looking for. Here are 6 other reasons why you'd want to put Contentful on your shortlist: consistent APIs easy to set up you're free to create your own models easy to use: ships with a robust, non-technical, user-friendly UI you get to add custom plugins quick and easy you get to set your own schemas to get displayed the way you want them to, across different apps Good to know! There's even a Shopify extension available. What it does is connect your online store to your content, stored in Contentful. And if you'll need help with building, fine-tuning, and integrating your content hub, we're ready to tweak Contentful to your needs.  END of Part 1! Stay tuned, for there are 5 more candidates for the title of "the best headless CMS in 2020" waiting in line.  Image by Couleur from Pixabay ... Read more
Adriana Cacoveanu / Sep 25'2020
Drupal 9 Modules Readiness: How Hard Is It to Find Compatible Modules and Build a Website in Drupal 9?
Is it (still) too early to give Drupal 9 a try? To start fresh and build a website from scratch in the latest version of Drupal? Should you stick to Drupal 8 for... a little longer and upgrade later? How difficult will it be for you to find compatible Drupal 9 modules (and themes)? Let's find out: 1. But First: Why Drupal 9? What are the biggest benefits of Drupal 9 over Drupal 8? Why would you choose precisely this version of Drupal to build your new website with? because of the automated updates that it makes possible because of the headless support that it ships with because of the robust multilingual capabilities because of the improved performance: your web pages will load faster thanks to the BigPipe technology because it removes a lot of the legacy code because of its layout features because of its extensibility: you get to incorporated third-party systems quick and easy because of its media library and robust media functionality because of the new, Twig-based theme engine because it's easier to use: you can make the most of its in-place editing (CKEditor) And particularly because there will be no more major re-builds (aka "major pains to upgrade"). Instead, a set of new features gets released every 6 months, including new improvements and additions to be incorporated seamlessly into your Drupal 9 build. 2. Most Drupal 9 Modules Don't Change at All So, stay assured: you won't be having a hard time finding compatible modules for your new Drupal 9 website. Many of the modules on Drupal.org have been, are being made, and will be made compatible with Drupal 9. There's a collective effort coming from the Drupal community in this direction. And where do you add that the process is pretty straightforward:  Same code, but without the deprecated APIs. 3. But What About Those that Do Need Changes? For there have been changes under Drupal 9's hood. Changes in coding with a direct impact on some modules and APIs. Which means that some modules have turned from Drupal core modules to... outside dependencies: this is good news, considering the performance gains you get but also a challenge if you were relying precisely on those modules for your Drupal 9 website Luckily, you have at least 2 helpful tools at hand that you can use to: identify the Drupal modules that still need to get updated apply the fixes needed to make those modules compatible with Drupal 9 3.1. The Upgrade Status Module Why use it? Because it offers you a view of all that has been changed in Drupal.  Source: Drupal.org You have links to the modules' pages there, that you can access to review those changes. 3.2. The Upgrade Rector Module The great thing about this tool is that it provides you with automated code fix suggestions to help you make your target modules Drupal 9 compatible. Source: Drupal.org 4. Some Module Get Removed from Drupal 9 Now, there are a few Drupal modules that didn't get the chance to grow into Drupal 9 modules. And I'm talking here about: Simple Test, that's now replaced by PHPUnit Place Blocks, now replaced by the Layout Builder  As you can see, in both cases you get to use better alternatives. So, it's just a matter of favoring more powerful solutions. Good to know! Expect other modules and themes (i.e. the Classy theme, the Stable theme) to get deprecated and removed by the time we reach Drupal 10. 5. What About the Contributed Modules? What if you need more than the out-of-the-box Drupal 9 modules to build your new website? What if you depend on particular contributed modules? Or on... many contributed modules? Well, then things get a little more challenging... Because many of the contributed Drupal modules still need to be made compatible with Drupal 9. They need some time to catch up with the new version of Drupal. Take for instance: updating tests to PHPUnit or updating deprecated API usages. Now, what you can do is give a helping hand to accelerate the updating of these modules. And the steps/best practices to follow are pretty simple, as suggested in this guide on Drupal.org : use the patch referred to here, create an issue in the module project (first, make sure it doesn't exist already), and choose a title suggestive enough to let the maintainer know that it needs to be tested for Drupal 9 deprecations add an explanation for the signaled issue ... and follow all the other steps suggested in that Drupal.org guide. Tip! Ask that contributed module's maintainer how he/she would like to address the issues you're signaling. Because the guidelines available for Drupal core aren't always relevant for addressing contributed module issues, as well. The END! Now, assuming that: you only need a limited no. of contributed modules for your new Drupal 9 build it's not a heavily customized website that you're building ... how do you get it up and running in? We're here to help. Just drop us a line! We've been building Drupal websites since... Drupal 5. Image by Siggy Nowak from Pixabay   ... Read more
Adriana Cacoveanu / Aug 28'2020