Support for Drupal 7 is ending on 5 January 2025—it’s time to migrate to Drupal 10! Learn about the many benefits of Drupal 10 and find migration tools in our resource center.If you take a look at the migrate module. Even hook_migrate_MIGRATION_prepare_row allows you to narrow down to a specific migration. From what I can tell the MigratePrepareRowEvent class doesn't allow this because everything is protected on Source and Row. I don't see a ->getMigration() or ->getMigrationId() method anywhere in the migrate modules. I don't know if you would be able to gather that information since you are getting a $row and $source as an instantiated object (and not exetending them at all), so maybe this needs to be something to go to migrate. would be cool though, that way we wouldn't have to use the existing "hooks" system.
Comments
Comment #2
mikeryanCan you describe what you need the migration instance for in the PREPARE_ROW event? As a general rule, coupling between classes should be minimized, and we do have a (long-term, i.e. D9) goal of isolating the source plugin from the migration class: #2543552: Modernize migration source plugins. That is of course an ideal, and sometimes the real world intrudes on our ideals, so I'm interested in hearing about real-world cases where the migration would be needed in a source plugin event.
Comment #3
generalredneckI saw the ability to use events as a great object oriented way to replace hooks. That's my own use case for this. So instead of a functional reprentation like we have now, one could subscribe to an event (which is all a hook is anyway) and perform the action. Beyond that... I've got nothing.
Comment #4
mikeryanYes, absolutely!
But - why does that make the Migration useful in the event?
Leaving the issue open in case someone has a good use case for having the migration available in the event.
Comment #5
generalredneckUnless you can tell me how to narrow down the effects of the code that is implemented here... then it can't be used the same way the hook is used currently. Example... I create a migration that uses a csv source called breeds. I then use it in a migration called rabbits... but I then use that same source in another migration called ears (because breeds actually have a field on them that requires the taxonomy for ear type)... to dedup the rows (meaning remove all the data that actually does represent the same taxonomy... not actually adding _1 or _2 to the end) I would have to know I'm doing the ears migration...
If I was able to do this I would then be able to use the migrate process plugin for ears in breeds and maintain the taxonomy term Id that way.
As it stands using the event class you would affect all migrations from the current source. By deduping ears... but that's not what we want when we go and do the actual breeds
Granted there are other ways to achieve the same technique... including using the hook and checking the migration name.... Source data manipulation (physically changing or making a new csv from the original) or even using the preprocessor hook to create ears taxonomy items during the breeds migration (though this one isn't fully reverseable so not as ideal)
So literally being able to manipulate the source data based on the name of the migration.
Comment #6
generalredneckHere is my source... https://gist.github.com/generalredneck/b7ac6e5534c263362275
Those "fields" on breeds are guild lines for what rabbits look like... a "rabbit" in fact has many of the Same taxonomy fields as the breed does but with specifics.
So you can see how those attributes for breeds can lend themselves to be taxonomy. With that said... in order to not have to make multiple csvs... I can use this one to get all my data...
Thus using a preprocessor hook makes sense to change the source data based on the migration while still using yaml files to configure the majority of the migration.
Comment #7
mikeryanYep, you're right, we need this. To fix #2661990: --limit on drush migrate-import command not working as well...
Comment #9
mikeryanDone!