public:// is the sites public file system path. You can change it by navigation to admin/config/media/file-system.
There you can set the public file system path, the default path is sites/default/files.
There was a fault with my migration yaml.
The destination field in Drupal 8 was field_media_audio but as you can see in the question I had it trying to save to field_audio_fileinfo which was the Drupal 7 source. Silly me.
Once I realised and corrected the destination it all worked and now media is created and referenced in the one pass of my migration ...
When I have done a similar type of migration at that time I did the following steps:
First I created media type Audio in Drupal 8 and it's fields.
Then I exported all audio file details and FID from D7 and created csv file.
Written migration script to import audio into media.
path: 'csv file path'
If we want to migrate field collection to paragraphs first you should create paragraph types and it's fields manually. There is no automation available yet to create paragraph types.
After that you can write migration script in .yml format to migrate content.
Reference(Migrating data from a SQL source): https://www.mtech-llc.com/blog/ada-hernandez/...
Don't use the default_bundle at all, instead set the bundle type like other field values in the process section:
For me this solve the problem:
# Only attempt to stub real (non-zero) parents.
migration: d7_taxonomy_term // this migration
if migration sounds too hard ...
install and config
to see a list then:
"drush default-content-deploy:export taxonomy_term"
"drush default-content-deploy:export node"
copy the exported files to your next ...
We found the problem. The site was using HTTPS on the production server and HTTP on the test server, and we had set php_flag session.cookie_secure On in our Apache config. HTTPS wasn't in use, so no cookies were sent, so no logins would work properly. Setting this to Off worked wonders. Thanks for pointing me in the right direction, folks!
You can indeed edit the exported config and then re-import it to make the title field mandatory.
Always be careful when editing config directly.
The config files generally follow the naming convention core.base_field_override.<entity_type>.<bundle>.title.yml.
There should be a required key which is set to false. Simply change false to true, ...
The answer is: the logic is not flowed, it is correct.
when you write your own custom migration module you can establish dependencies to other migrations that you have done via code or done via UI using migrate_ui or d2d_migrate_ui modules.
here is custom migration code that depends on a class generated by d2d_migrade_ui. this code worked for me:
Although it is more elegant to use a sub_process as @dibs proposed, you can also use a get process plugin
- plugin: get
- plugin: default_value