- last update
over 1 year ago Composer error. Unable to continue. - last update
over 1 year ago Composer error. Unable to continue. - last update
over 1 year ago Patch Failed to Apply - last update
over 1 year ago Composer error. Unable to continue. - last update
over 1 year ago Composer error. Unable to continue. - last update
over 1 year ago Composer error. Unable to continue. - last update
over 1 year ago Composer error. Unable to continue. - last update
over 1 year ago Composer error. Unable to continue. - last update
over 1 year ago Patch Failed to Apply - last update
over 1 year ago Patch Failed to Apply - Status changed to RTBC
over 1 year ago 9:39am 24 August 2023 - 🇬🇷Greece vensires
In my D9 installation this patch played perfectly! I set it as RTBC.
- last update
over 1 year ago 30,006 pass, 14 fail - @vensires opened merge request.
- Status changed to Needs work
over 1 year ago 12:42pm 24 August 2023 - 🇺🇸United States mikelutz Michigan, USA
The change to the test fixture is what surfaces the bug to the core test suite, so the tests fail. This is not ready to commit. There are 14 failed tests because the changes in #22 aren't backwards compatible. Fixing the bug in this way would break existing migrations that have already implemented workarounds. This needs more work to allow opting into the fix and a warning that migrations should be updated to use the fix or they will break in the next major version.
- 🇬🇧United Kingdom james.williams
I've had a go at allowing this new behaviour to be optional (disabled by default). So when using the migration_lookup process plugin, a 'skip_unmigrated' option can be passed.
From reading above, it looks as though we might ultimately want the option to be enabled by default, but I'm just being conservative for now - and presumably tests will pass with this as no migrations will actually be using it yet. But sure, the next step could be to invert that, and update existing migrations and add the warning.
I'm also not sure about the BC implications. I've added an optional parameter to some methods to pass the configuration along. I'm not sure if there's a better way. Presumably we could just target 11.x without any backporting, but with a change record?
- last update
over 1 year ago Custom Commands Failed - 🇬🇧United Kingdom rossb89 Bristol
Thanks @james.williams This looks promising but unfortunately I encountered an issue when using Migrate Tools:
Fatal error: Declaration of Drupal\migrate_tools\IdMapFilter::lookupDestinationIds(array $source_id_values): array must be compatible with Drupal\migrate\Plugin\MigrateIdMapInterface::lookupDestinationIds(array $source_id_values, bool $skip_unmigrated = false)
In @migrate_tools/src/IdMapFilter.php:195@ there is a declaration of
public function lookupDestinationIds(array $source_id_values): array { $map = $this->getInnerIterator(); \assert($map instanceof MigrateIdMapInterface); return $map->lookupDestinationIds($source_id_values); }
which would also need to be modified to handle the extra parameter, to work in conjunction with this patch.