Following up on my comment in https://www.drupal.org/node/2559571#comment-10282791:
A word on removing the $this->message->display() (and not adding it to the new catch())... display() is meant for messages that go directly to the front-end (drush terminal or web UI page), and my feeling is that the detailed per-row messages should not be sent through display(). My experience is that in many cases, the volume there can be overwhelming and hide more immediately useful messages (like a migration being skipped if dependencies aren't met) - these detailed messages are best reviewed at leisure (yes, I need to implement message viewing in migrate_tools). If there's a strong feeling otherwise, then we should not be expected to always pair calls to saveMessage() and display(), but rather have saveMessage() itself call display().
Better yet, it would be best if the id map plugin had a boolean option whether to display logged messages... Hmmm...
So, I still think in the general migration development case we want the per-row messages to only go into the message tables. However, migrate_upgrade should probably display them as they come, and actually for development you might want to add a --debug option to your drush migrate-import command and see them come out. So, let's add the option.
My current thought is the best way to do this will be for the idmap saveMessage() to dispatch an event, which the MigrateMessageInterface implementor can catch and display if requested. Will try that out...
Comment | File | Size | Author |
---|---|---|---|
#8 | interdiff.txt | 8.51 KB | mikeryan |
#8 | option_to_tee_idmap-2574973-8.patch | 8.26 KB | mikeryan |
Comments
Comment #2
mikeryanPatch attached, see also #2575127: Support displaying all messages sent to message tables for a patch for migrate_upgrade to make use of this.
Comment #3
mikeryanA discussion with @phenaproxima raises the point, this loses the context of the source ID corresponding to the message, we should make sure that gets put out through the message interface.
Comment #4
mikeryanAmazing sometimes how much effort it takes to produce a simple-looking test...
Comment #5
mikeryanmikeryan-- for messing up a simple implode().
Comment #6
phenaproximaWhy @see MigratePostRowSaveEvent?
This doc comment ain't accurate :)
I'm not sure why this is an option, because then we need to explicitly remember to do it. IMO we should *always* register the MigrateExecutable as a message event listener, and pipe only errors and warnings to $this->messages.
Should use $this->eventDispatcher.
Ditto.
Not sure what this is used for.
Comment #7
mikeryanUpon discussion with phenaproxima, I'm removing the support for this from MigrateExecutable - it'll be up to the front end to implement the listener and decide when to handle the idmap messages.
Also, fixing copypasta in MigrateIdMapMessageEvent...
Comment #8
mikeryanHere we're basically just implementing the event, it's up to the front ends to make use of it to choose whether or not to display idmap messages.
Comment #9
phenaproximaThis is still wrong, but can be fixed on commit. :)
Other than that, I think this approach is much cleaner and clearer. RTBC from me once DrupalCI passes it!
Comment #10
phenaproximaMMM-hmm.
Comment #12
mikeryanCI failure, not an actual test failure.
Comment #15
phenaproximaComment #17
webchickOh, awesome. Really happy to see this ready.
I'm moving from feature request to task. My understanding is that this a requirement for the Migrate UI to show messages from within a migration.
Committed and pushed to 8.0.x. Thanks!