I recently needed a way to update the value of a single field of a D7 to D8 node migration.
The client was already updating the migrated content so I had to be careful with what I migrated.
The entity destination plugin has a wonderful configuration option that allows you to specify which fields you want to migrate. Search the code here for overwrite_properties.
Here’s how I used this to ignore every field except two:
I tested this by editing a node’s title, subtitle, field_tax_groups, and field_tags values. I ran the migration and the edits were preserved on the title and subtitle fields as expected.
Consider this scenario:
- Drupal 7 site contains Profile2 profile called person with image field called field_oldsite_person_image.
- Users each have a profile2 profile associated with their account.
- Drupal 8 site has an image field called field_newsite_user_photo on the user entity itself.
If you need to migrate the image field from the Drupal 7 profile to the Drupal 8 user entity you can extend the d7_user plugin and query for the additional field data. I’m executing an extra query for each user (because the code is in the prepareRow() method), rather than attempting to pull all of the profile data as part of the query in the query() method of the class.
First, create a file in your module like /modules/custom/mysite_migrate/src/Plugin/migrate/source/MysiteUser.php that extends the d7_user plugin: Read more ›
Here are a few quick tips for a Drupal 7 to Drupal 8 migration. I will add more over time; admittedly it’s pretty lame right now!
For general Drupal 8 Migrate API tips, you may also want to check out my other post: Drupal 8 Migrate – Tips and Tricks
If you’re using a source plugin like d7_user or d7_node it will help you understand what’s happening if you view the source code for the plugin. Pay close attention to the query(), prepareRow(), and fields() methods. Read more ›
I’m not going into much detail here but hopefully this helps someone.
If you need to migrate only published nodes you can extend the d7_node plugin and add a condition to the query.
First, create a file in your module like /modules/custom/mysite_migrate/src/Plugin/migrate/source/MysiteNewsNode.php that extends the d7_node plugin: Read more ›
Recently I was working on a D7 to D8 migration. I was trying to import news items and their taxonomy terms (among many other things). To make things simple I wanted the query results to have (for each node) a single field that contained a comma-separated list of taxonomy terms which I could then explode during the row processing. Using GROUP_CONCAT we can achieve this! Let’s break it down:
The Drupal 7 site has the following structure (focusing on the important bits for this blog post):
-- News Item (news_item) <content type>
---- Categories (field_categories) <field collection>
------ Audience (field_term_audience) <taxonomy reference; unlimited values>
The migration relies on the d7_node migrate source plugin, which basically queries for nodes of a specific type. The query object looks like this (simplified for this blog post): Read more ›
I’m working on a site that has a “Statistics” paragraph bundle. The output looks like this:
The specification calls for the content author to be able to choose between a few different visual styles for the header (title), shown as Statistics: 3 Up Feature Ipsum Sit H2 in the screenshot above.
The simplest way to achieve this is to add a field to the paragraph bundle:
Name: Header Style
Machine name: field_header_style
Type: List (text)
Allowed number of values: 1
Default value: Visually normal
Note that the key (key|value) needs to work as a css class. Read more ›
Tagged with: drupal 8
Posted in Development
Inline Entity Form is a useful module for reference entities and being able to edit them in place.
Here’s what the edit form looks like out of the box for an unlimited value entity reference:
Often it’s helpful to provide additional information to your editors.
If you have a look at inline_entity_form.module you will find a function called theme_inline_entity_form_entity_table(). Within this you will see how this table is built, and how you can manipulate the form to add additional columns of information. Read more ›
You love git-difftool, right? Of course! You also love PHP Storm, right? Of course! This easy procedure lets you use PHP Storm as your git-difftool.
- Open a project in PHP Storm
- Click Tools » Create Command-line Launcher…
- Edit your ~/.gitconfig file:
tool = pstorm
prompt = false
cmd = /usr/local/bin/pstorm diff "$LOCAL" "$REMOTE"
tool = pstorm
cmd = /usr/local/bin/pstorm merge "$LOCAL" "$REMOTE" "$BASE" "$MERGED"
- Open the project in PHP Storm (see notes below)
- Open iTerm2 (or any other terminal emulator)
git difftool as you normally would (e.g.,
git difftool .htaccess)
- If you don’t have PHPStorm open when you try to use
git difftool it doesn’t seem to work. I need to see if I can get it to open non PHP Storm projects, and/or I need to figure out how to switch on-the-fly between vimdiff and PHP Storm as my difftool.
- If you have PHP Storm open but the project itself isn’t open, “Annotate” is not available on right-click. Other functionality may be missing too. If you project is already open in PHP Storm you can annotate the diff!
Thank you to JohnAlbin for the configuration snippet above.