- Issue created by @HongPong
- Status changed to Needs work
12 months ago 8:05am 30 September 2023 - 🇺🇸United States HongPong Philadelphia
WIP added to issue fork with extracted comment entity generator function. https://git.drupalcode.org/issue/wordpress_migrate-3390754 . then reroll after 📌 remove createPluginEntityFromPlugin in WordPressMigrationGenerator Needs review is committed.
That does not fix the problem but does isolate it within a much smaller function.
- 🇺🇸United States HongPong Philadelphia
For anyone else debugging such stuff. with devel and symfony dumper turned on:
Adding the following to web/core/modules/migrate/src/Plugin/Migration.php circa line 745:
if (in_array($plugin_configuration['plugin'], ['migration', 'migration_lookup'], TRUE)) { if (!isset ($plugin_configuration['migration'])) { ddm('---- migration is not set on this plugin_configuration!'); ddm($plugin_configuration, 'findmigrationdependencies plugin_configuration'); ddm($process); ddm('--end---'); } else { ddm('---- OK: migration is set on this plugin_configuration'); ddm($plugin_configuration, 'findmigrationdependencies plugin_configuration'); ddm($process); ddm('--OK end--- \n'); } $return = array_merge($return, (array) $plugin_configuration['migration']); }
Getting closer to this!
- 🇺🇸United States HongPong Philadelphia
Brought this to slack drupal #migrate and mikelutz gave useful info. i think this is the 'plugin derivatives' / plugin derivers' idea. Thus we should transition these migration config entities to 'derivers' when possible. (I think thats the same as derivatives.)
related examples: https://www.drupal.org/project/entity_timeline/issues/3281990 →
https://api.drupal.org/api/drupal/core!lib!Drupal!Component!Plugin!Deriv...
https://www.sitepoint.com/tutorial-on-using-drupal-8-plugin-derivatives-...
https://drupal.stackexchange.com/questions/293667/how-do-i-create-a-deri...
https://api.druphelp.com/api/drupal/core%21lib%21Drupal%21Component%21Pl...
https://www.drupal.org/docs/drupal-apis/plugin-api/plugin-derivatives →
https://manifesto.co.uk/drupal-plugin-api-examples-tutorial/
https://www.hashbangcode.com/article/drupal-9-creating-category-menu-usi...
https://www.adamfranco.com/2018/11/13/creating-a-drupal-plugin-system/mikelutz: The quick and dirty fix here, without refactoring to derivatives is to put something in the template plugin for that key like migration: wordpress_comment so the plugin can load and pass it’s checks. It doesn’t quite matter much, it’s getting overwritten in the dynamically generated config entities anyway, but something needs to be there in the plugin template itself so it can be loaded and used to create the config entities.
The problem isn’t in the importer. You are generating valid config entities there. The module is trying to dynamically generate migrate_plus config entities using the migration plugins in the /migration folder as templates. It’s really not the right approach. If you want to derive multiple migrations from a template, you should use a plugin deriver similar to the way core derives node plugins by content type. The issue here is that your template migrations has https://git.drupalcode.org/project/wordpress_migrate/-/blob/8.x-3.x/migr...
pid: plugin: migration_lookup source: comment_parent # migration ID generated dynamically
Despite the fact that this migration is only supposed to be a template, it’s a real valid plugin. And any version of createEntityFromPlugin creates an instance of this plugin to read the template from. Creating an instance of the plugin checks the dependencies. Checking the dependencies of the plugin scans it for migration lookup processes and adds the migration that you are looking up against to the dependencies. And it can’t because there is an undefined offset ‘migration’.