Drupal 8 provides a flexible, plugin-based architecture for migrating data into a site. In Part 3 of this series, we explored how to migrate taxonomies from a Drupal 7 site. We will now expand on this by migrating basic nodes from a Drupal 7 site into Drupal 8.
Drupal 8 provides a flexible, plugin-based architecture for migrating data into a site. In Part 2 of this series, we explored how to migrate users from a Drupal 7 site. We will now expand on this by migrating Taxonomy vocabularies and terms from a Drupal 7 site into Drupal 8.
In this article, we will be building a custom migration which will import users from a Drupal 7 site into a Drupal 8 site. The migration will include the standard user profile fields like username and email address, plus a few custom fields added to the user profile.
Drupal 8 includes a powerful built-in migration system for importing content into your site. It is designed to handle data from Drupal 6 or 7, and much more. It is built around a plugin-based architecture, which allows importing of data from any external data source if you write your own source plugin.
Drupal 8 is in beta now, and recently I’ve had a chance to start working with it. While much of the admin interface is comparable to Drupal 7, there have been some important changes for site builders and back-end developers. In this post, I will be looking at file system and database structure changes, Drush setup, and the new configuration entity type.
Much like an evolutionary tree our goal in technology adoption is too continue to move forward and evolve, rather than getting caught in a dead end. In the natural world, becoming bigger can be good but can lead to extinction events should the environment or food source change. Right now we are in a technology Jurassic...
Recently inspired by Peter Thiel's excellent book Zero to One, I've been reflecting on the software industry as the preeminent place where we can expect to see radical innovation - and the blockers that exist in the industry that need to be addressed for us to maximize the pace of change.
Like many Drupal developers, we have become big fans of decoupled front-ends using Drupal as a RESTful backend (a.k.a. "headless" Drupal). The myriad of authorization options can be confusing, however. We've settled on OAuth 2.0 for most situations. When OAuth is brought up, many people will think of the single-sign-on flow in a browser, with the associated redirects and permission dialogs. This flow is widely used, but not always a good fit for first-party applications, or machine-to-machine API interactions.
I've been playing with D7 forms lately and have found #states to be somewhat challenging due to lack of documentation on Form API page.
I've poked around a bit and decided to write a blog with my findings in case someone else is in need of this info down the road.