Skip to main content
- In D7, we used the Migrate Drupal to Drupal module, what’s the case for D8?
- Speak on pattern of using Migrate Drupal as a basis for a migration.
- Migration plugins and yml configuration declarations are an improvement on an already excellent module - if you are going to handle migrations like you did in 7 - which might be appropriate depending on your use case
- Appropriate where you are significantly revising the content model, configuration or site composition.
- What are some of the pros and cons of the way Migrate Drupal works in D8?
- Migration of most Drupal settings: registration emails, site name, debug settings, etc.
- Migration of most fields (work is ongoing to include contrib into upgrade migrations)
- Migration of all content types with nodes and revisions
- By default, fixed ids (not ideal for staged work)
- Miss an opportunity to take out the trash
- Let’s talk about configuration management. I know from working with you guys that you started out using Features...
- Tried out a features based approach at first - because it was similar to well established patterns in 7 - but abandoned it for the project
- Feature branch activity then confex seems to be working out well
- Configuration import and export has inspired a lot of confidence in getting to known states.
- The challenge is probably in managing environmental config settings - that’s where Master still might have a place.
- Using configuration export and import committed to git repo.
- Challenges of local configuration vs production configuration.
- Managing code review
- Automated removal of local configuration
- Would like to know some other people’s workflows