Originally a followup to #2543536: [meta] Reduce/remove tight coupling of migration classes - the scope here has narrowed to fixing the gross hackery of md_entity, and the original issue is now covered by #2822021: Reduce/remove tight coupling of migration destination plugins.

Problem/Motivation

migrate_drupal's EntityFieldStorageConfig does the following:

  public function calculateDependencies() {
    $this->dependencies = parent::calculateDependencies();
    // Add a dependency on the module that provides the field type using the
    // source plugin configuration.
    $source_configuration = $this->migration->get('source');
    if (isset($source_configuration['constants']['type'])) {
      $field_type = $this->fieldTypePluginManager->getDefinition($source_configuration['constants']['type']);
      $this->addDependency('module', $field_type['provider']);
    }
    return $this->dependencies;
  }

The destination plugin is reaching through the migration to get the 'type' out of the source plugin's configuration, so it can determine what destination module it depends on. This is a complete WTF - I'm sure it must be at least tangentially related to #2507607: [META] Replace Cthulhu-forsaken load plugins with migration builders, but even if that effort doesn't remove this, we must kill it dead.

Proposed resolution

Fix the EntityFieldStorageConfig WTF.

Remaining tasks

User interface changes

N/A

API changes

None.

Data model changes

None anticipated.

Files: 
CommentFileSizeAuthor
#69 interdiff.txt643 bytesmikeryan
#69 remove_the_md_entity-2543568-69.patch5.08 KBmikeryan
#64 interdiff.txt4.78 KBmikeryan
#64 remove_the_md_entity-2543568-64.patch5.12 KBmikeryan
#59 interdiff-2543568-56-59.txt4.43 KBchipway
#59 2543568-59.patch7.85 KBchipway
#56 reduce_remove_tight-2543568-56.patch13.6 KBiMiksu
#56 interdiff-51-56.txt724 bytesiMiksu
#51 reduce_remove_tight-2543568-51.patch13.59 KBmikeryan
#44 interdiff.txt1.08 KBmikeryan
#44 reduce_remove_tight-2543568-44.patch35.22 KBmikeryan
#41 interdiff.txt1 KBmikeryan
#41 reduce_remove_tight-2543568-41.patch35.33 KBmikeryan
#39 reduce_remove_tight-2543568-39.patch34.5 KBmikeryan
#34 interdiff.txt1.61 KBmikeryan
#34 reduce_remove_tight-2543568-34.patch38.29 KBmikeryan
#31 interdiff-2543568-28-31.txt539 bytesRyan Weal
#31 reduce_remove_tight-2543568-31.patch37.98 KBRyan Weal
#28 interdiff.txt891 bytesmikeryan
#28 reduce_remove_tight-2543568-28.patch37.98 KBmikeryan
#24 reduce_remove_tight-2543568-24.patch37.54 KBquietone
#22 reduce_remove_tight-2543568-22.patch40.97 KBquietone
#20 reduce_remove_tight-2543568-20.patch40.99 KBquietone
#18 reduce_remove_tight-2543568-18.patch40.01 KBquietone
#16 reduce_remove_tight-2543568-16.patch37.51 KBquietone
#14 reduce_remove_tight-2543568-14.patch37.2 KBquietone
#12 reduce_remove_tight-2543568-12.patch37.07 KBmikeryan
PASSED: [[SimpleTest]]: [PHP 5.5 MySQL] 112,577 pass(es). View

Comments

mikeryan’s picture

Title: [meta] Reduce/remove tight coupling of migration destination plugins » Reduce/remove tight coupling of migration destination plugins
mikeryan’s picture

The calculateDependencies() thing was added in #2460529: Migrations need to use the configuration entity dependency system. Looking at that issue, and how this plugin is used, I believe #2533886: [meta] Move module-specific migration support into the particular modules supported should obsolete the entire plugin - once all migrations are defined within their destination modules, this hack to enforce the dependency on that module will no longer be necessary.

mikeryan’s picture

Digging in a little more deeply to identify where EntityFieldStorageConfig::calculateDependencies() has an effect:

  1. d6_upload_field is at this moment in migrate_drupal, and the dependency is on the file module - #2534012: Move module-specific migration support into the file module should be committed like, any minute now, so this will be fixed.
  2. d6_vocabulary_field, in the taxonomy module, is adding a dependency on entity_reference.
  3. d6_user_field, in the user module, is adding a dependency on the image module.

I think for use cases #2 & #3, forcing the dependency directly is less of a hack than what we have going on in EntityFieldStorageConfig::calculateDependencies now.

mikeryan’s picture

I've started playing around with this, and the migration coupling seems to have similar defense mechanisms to Alien - you don't dare remove it. Posting what I did so far, will pick it up again at some other point.

benjy’s picture

+++ /dev/null
@@ -1,93 +0,0 @@
-  public function calculateDependencies() {

I'm surprised we can remove this, although it's good. Is this because of the builders?

mikeryan’s picture

Status: Postponed » Active

Should be doable now that load plugins are gone.

mikeryan’s picture

Status: Active » Needs review
FileSize
34.71 KB
FAILED: [[SimpleTest]]: [PHP 5.5 MySQL] Unable to apply patch reduce_remove_tight-2543568-7.patch. Unable to apply patch. See the log in the details link for more information. View

I do believe I've removed the tumor without killing the patient...

Status: Needs review » Needs work

The last submitted patch, 7: reduce_remove_tight-2543568-7.patch, failed testing.

mikeryan’s picture

Status: Needs work » Needs review
Issue tags: +Needs change record
FileSize
36.87 KB
FAILED: [[SimpleTest]]: [PHP 5.5 MySQL] Unable to apply patch reduce_remove_tight-2543568-9.patch. Unable to apply patch. See the log in the details link for more information. View
2.02 KB

Oops, missed one.

The last submitted patch, 7: reduce_remove_tight-2543568-7.patch, failed testing.

Status: Needs review » Needs work

The last submitted patch, 9: reduce_remove_tight-2543568-9.patch, failed testing.

mikeryan’s picture

Status: Needs work » Needs review
FileSize
37.07 KB
PASSED: [[SimpleTest]]: [PHP 5.5 MySQL] 112,577 pass(es). View

Rerolled for changed EntityComment.php.

quietone’s picture

Status: Needs review » Needs work
Issue tags: +Needs reroll

No longer applies.

quietone’s picture

Status: Needs work » Needs review
FileSize
37.2 KB

Interdiff fails.

Status: Needs review » Needs work

The last submitted patch, 14: reduce_remove_tight-2543568-14.patch, failed testing.

quietone’s picture

Status: Needs work » Needs review
FileSize
37.51 KB

Hah, I think I submitted while that webchick was doing a bunch of commits for migrate.

This one should be ok. And, as before the interdiff fails.

Status: Needs review » Needs work

The last submitted patch, 16: reduce_remove_tight-2543568-16.patch, failed testing.

quietone’s picture

Status: Needs work » Needs review
FileSize
40.01 KB

And again.

Status: Needs review » Needs work

The last submitted patch, 18: reduce_remove_tight-2543568-18.patch, failed testing.

quietone’s picture

Status: Needs work » Needs review
FileSize
40.99 KB

Yep, another commit was made, thus the error. That is fixed in the attached.

Status: Needs review » Needs work

The last submitted patch, 20: reduce_remove_tight-2543568-20.patch, failed testing.

quietone’s picture

Status: Needs work » Needs review
Issue tags: -Needs reroll
FileSize
40.97 KB

Another reroll.

Version: 8.0.x-dev » 8.1.x-dev

Drupal 8.0.6 was released on April 6 and is the final bugfix release for the Drupal 8.0.x series. Drupal 8.0.x will not receive any further development aside from security fixes. Drupal 8.1.0-rc1 is now available and sites should prepare to update to 8.1.0.

Bug reports should be targeted against the 8.1.x-dev branch from now on, and new development or disruptive changes should be targeted against the 8.2.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

quietone’s picture

mikeryan’s picture

Version: 8.1.x-dev » 8.2.x-dev
Issue tags: +neworleans2016, +Migrate BC break, +Novice

New work (tasks/features) should be targeted to the 8.2.x branch.

Writing a change record may be a Novice task...

quietone’s picture

Ok, I'm not much of a word smith and I've not done a change record but let's keep this moving. How is this for a start?

Title: $migration parameter removed from destination plugin declaration
Project: Drupal Core
Introduced in branch/version: 8.2.x
Issues: 2543568
Description: The migration destination plugins used to receive the $migration parameter, allowing full access to the migration configuration. This coupling has been removed so that the destination plugins are independent.

What else is needed?

chx’s picture

This:

  1. Everything to be saved in the destination object should be in the process section. The destination plugin should not copy anything from the source directly.
  2. The configuration of the destination plugin should be in the destination section. The destination plugin should not rely on the value of any other top level key.

And if I were doing this (I am not) I would postpone this on #2695297: Refactor EntityFile and use process plugins instead.

mikeryan’s picture

Let's deprecate md_entity:field_storage_config rather than remove it entirely.

heddn’s picture

Status: Needs review » Reviewed & tested by the community
Issue tags: -Novice

Removing novice tag. Writing meaningful change notices are usually harder than you think. I did a review of the code. Nothing jumped out at me that seems strange. We have plenty of test coverage in this area. So I think this is RTBC.

+++ b/core/modules/migrate_drupal/src/Plugin/migrate/destination/EntityFieldStorageConfig.php
@@ -2,87 +2,19 @@
+ * @deprecated in Drupal 8.2.x and will be removed in Drupal 9.0.x. Use

Wise to keep it around. Who know who is doing what at this point. Providing an @deprecated is about the best we can do.

alexpott’s picture

Status: Reviewed & tested by the community » Needs work
  1. +++ b/core/modules/migrate/src/Plugin/MigrateDestinationInterface.php
    @@ -39,17 +39,10 @@ public function getIds();
    -   * @return array
    

    Looks like this shouldn't be removed.

  2. +++ b/core/modules/migrate_drupal/src/Plugin/migrate/destination/EntityFieldStorageConfig.php
    @@ -2,87 +2,19 @@
    -  /**
    -   * {@inheritdoc}
    -   */
    -  public function calculateDependencies() {
    -    $this->dependencies = parent::calculateDependencies();
    -    // Add a dependency on the module that provides the field type using the
    -    // source plugin configuration.
    -    $source_configuration = $this->migration->getSourceConfiguration();
    -    if (isset($source_configuration['constants']['type'])) {
    -      $field_type = $this->fieldTypePluginManager->getDefinition($source_configuration['constants']['type']);
    -      $this->addDependency('module', $field_type['provider']);
    -    }
    -    return $this->dependencies;
    -  }
    

    Given #3 I'm surprised we can remove this without adding any dependencies anywhere. How come this is possible?

Ryan Weal’s picture

Adding the return statement back to the annotation.

Ryan Weal’s picture

Status: Needs work » Needs review
mikeryan’s picture

Status: Needs review » Needs work

Given #3 I'm surprised we can remove this without adding any dependencies anywhere. How come this is possible?

For migrations of field storage configuration from Drupal, this takes the source configuration constants/type (the name of the field type being created in the migration) and makes the module of the same name as the field type a dependency. Things wrong with this:

  1. The only reason the destination plugin is coupled to the Migration class is to reach through it to get the source plugin's configuration. Blech.
  2. It may so happen that core field types match their module names, but there's nothing that guarantees that, is there?
  3. This is only applicable when migrating from Drupal. What if we were migrating from some other system where we were able to access field definitions and transmogrify them to create equivalent Drupal fields? If we want to apply proper dependencies in that case, we would need to do it in migrate's EntityFieldStorageConfig, not migrate_drupal's.

So, we really should get rid of this md_entity:field_storage_config nonsense. But, yes, there should be some way to add dependencies on the field module. The most direct way to do that would be to simply make them explicit in the destination configuration (where they belong). Say, for user_picture_field, replace

destination:
  plugin: md_entity:field_storage_config

with

destination:
  plugin: entity:field_storage_config
  dependencies:
    module:
      - image

Thoughts?

mikeryan’s picture

Status: Needs work » Needs review
FileSize
38.29 KB
1.61 KB

Let's try that.

Version: 8.2.x-dev » 8.3.x-dev

Drupal 8.2.0-beta1 was released on August 3, 2016, which means new developments and disruptive changes should now be targeted against the 8.3.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

mikeryan’s picture

Version: 8.3.x-dev » 8.2.x-dev
mikeryan’s picture

Issue tags: -Needs change record

Change record added.

phenaproxima’s picture

  1. +++ b/core/modules/migrate/src/Plugin/MigrateDestinationPluginManager.php
    @@ -54,11 +58,20 @@ public function __construct($type, \Traversable $namespaces, CacheBackendInterfa
    -    return parent::createInstance($plugin_id, $configuration, $migration);
    +    $plugin_definition = $this->getDefinition($plugin_id);
    +    $plugin_class = DefaultFactory::getPluginClass($plugin_id, $plugin_definition);
    +    // If the plugin provides a factory method, pass the container to it.
    +    if (is_subclass_of($plugin_class, 'Drupal\Core\Plugin\ContainerFactoryPluginInterface')) {
    +      $plugin = $plugin_class::create(\Drupal::getContainer(), $configuration, $plugin_id, $plugin_definition);
    +    }
    +    else {
    +      $plugin = new $plugin_class($configuration, $plugin_id, $plugin_definition);
    +    }
    +    return $plugin;
    

    Since this now extends DefaultPluginManager, why do we need to bother copying and pasting the factory logic here? DefaultPluginManager uses ContainerFactory by default, which is aware of ContainerFactoryPluginInterface.

  2. +++ b/core/modules/migrate_drupal/src/Plugin/migrate/destination/EntityFieldStorageConfig.php
    @@ -2,87 +2,19 @@
    + * @deprecated in Drupal 8.2.x and will be removed in Drupal 9.0.x. Use
    

    I imagine we'll probably remove this *before* D9. Can we s/in/before?

  3. +++ b/core/modules/user/migration_templates/user_picture_field.yml
    @@ -18,4 +18,7 @@ process:
    +  dependencies:
    +    module:
    +      - image
    

    Where are these used? It seems to me that we should have a calculateDependencies() implementation on DestinationBase that actually makes use of this configuration.

mikeryan’s picture

Turned out we needed a reroll anyway with recent commits - no interdiff, because it got confused...

Since this now extends DefaultPluginManager, why do we need to bother copying and pasting the factory logic here?

Well, the assumption was to retain the MigratePluginManager stuff here - but, the comment "A specific createInstance method is necessary to pass the migration on" suggests that's no longer needed, so let's see how we do without createInstance()...

I imagine we'll probably remove this *before* D9. Can we s/in/before?

Done.

Where are these used? It seems to me that we should have a calculateDependencies() implementation on DestinationBase that actually makes use of this configuration.

'dependencies' is part of the base plugin system. The point of calculateDependencies() would be to automatically calculate them, but, per #33 above, the attempt previously being made to calculate them was misguided - it just happened to get lucky with these cases provided in core, but would break in the more general case, so it's best to simply make the dependencies explicit.

Status: Needs review » Needs work

The last submitted patch, 39: reduce_remove_tight-2543568-39.patch, failed testing.

mikeryan’s picture

Status: Needs work » Needs review
FileSize
35.33 KB
1 KB

Are those new tests? Hard to see how they would have been passing previously... Anyway, fixed those up...

neclimdul’s picture

re #41: newish but no, blame says they where both part of the d6 translation patch. Your patch changes the EntityContentBase constructor so it makes sense it would have to fix the tests instantiating it directly. That or keep the argument and ignore the value depending on how we want to handle BC.

phenaproxima’s picture

+++ b/core/modules/migrate/src/Plugin/MigrateDestinationPluginManager.php
@@ -45,20 +46,11 @@ class MigrateDestinationPluginManager extends MigratePluginManager {
+    $plugin_interface = isset($plugin_interface_map[$type]) ? $plugin_interface_map[$type] : NULL;

What is $plugin_interface_map? Doesn't seem to be defined in this function, or as a parameter.

Apart from that, I think this is RTBC.

mikeryan’s picture

What is $plugin_interface_map? Doesn't seem to be defined in this function, or as a parameter.

As with createInstance(), when switching from extending MigratePluginManager to extending DefaultPluginManager, this was copied from MigratePluginManager on the assumption it was still needed. So, let's take it out (note: MigratePluginManager also has this bit of code which seems to do nothing).

phenaproxima’s picture

Status: Needs review » Reviewed & tested by the community

Preemptively RTBC. I see no reason why Drupal CI won't pass this.

alexpott’s picture

+++ b/core/modules/migrate_drupal/src/Plugin/migrate/destination/EntityFieldStorageConfig.php
@@ -2,87 +2,19 @@
+ *
+ * @deprecated in Drupal 8.2.x and will be removed before Drupal 9.0.x. Use
+ *   \Drupal\migrate\Plugin\migrate\destination\EntityFieldStorageConfig
+ *   instead.
+ *
+ * @see \Drupal\migrate\Plugin\migrate\destination\EntityFieldStorageConfig
  */
-class EntityFieldStorageConfig extends BaseEntityFieldStorageConfig {

Given that migrate is still not out of alpha what is the advantage of deprecating this and not removing?

alexpott’s picture

Nice diff stat btw.

mikeryan’s picture

Given that migrate is still not out of alpha what is the advantage of deprecating this and not removing?

We'd still like to minimize disruption where we can. There may be contrib field modules which used md_entity for their migrations paths - probably more commonly, people who've used the practice of doing migrate-upgrade --configure-only will still have md_entity references in their generated migrations, which will bite them if we remove it entirely immediately.

alexpott’s picture

And they won't need to make any changes if we leave it as is?

chx’s picture

  1. Why is MigrateDestinationPluginManager::createInstance removed?
  2. This should be split into unhacking EntityFieldStorageConfig which is a good idea and removing the migrateinterface from the destination which has absolutely no justification given and given it relies on the Row it's only lip service to haughty ideas and zero gain in practice. Or I missed those.

In particular

Ideally, migration destination plugins (which wrap delivery of data to destinations such as Drupal entities) should be usable by themselves,

For what? These plugins are thin wrappers around perfectly usable APIs on their own. I fail to see how a migration destination plugin could be used for anything else but being the glue between Row and whatever CRUD API it wraps.

mikeryan’s picture

Status: Reviewed & tested by the community » Needs review
FileSize
13.59 KB

And they won't need to make any changes if we leave it as is?

If their field migration depends on a module other than the one defining the migration, then they should add an explicit dependency to the migration. So - I see what you're saying, they might as well change the destination plugin while they're at it. At least some, though, would have no problem with the BC layer present, so it seems nice to save them the trouble of "why am I suddenly getting errors about md_entity" if it's simple. I'm not wedded to that though, I can remove the BC layer if you prefer.

As for removing the Migration argument, when opened the idea here was simple API cleanup - there is no reason the destination plugin should need the migration plugin, and it only existed to support this ugly hack, so we might as well remove it. A year ago I would have fought to get it in, but unfortunately it didn't get RTBC'd until after 8.2.0-rc - given that we're trying very hard to stabilize the API, and this particular BC break is more about API cleanliness than practical benefits, it's not worth wasting more time arguing over it. The attached patch fixes the md_entity WTF without removing the migration parameter from the migration plugins (I did keep removal of the optional migration parameter from the fields() method - that makes no sense whatsoever).

mikeryan’s picture

BTW, no interdiff because the interdiff is bigger than the new patch...

heddn’s picture

Is this BC breaking still?

mikeryan’s picture

Issue tags: -Migrate BC break

No - see #51.

claudiu.cristea’s picture

+++ b/core/modules/migrate_drupal/src/Plugin/migrate/destination/EntityFieldStorageConfig.php
@@ -2,87 +2,19 @@
+ * @deprecated in Drupal 8.2.x and will be removed before Drupal 9.0.x. Use

It cannot be "removed before Drupal 9.0.x" but it can be:

  • "removed before Drupal 9.0.0"
  • OR

  • "removed in Drupal 9.0.x"
iMiksu’s picture

Lets go with "removed in Drupal 9.0.x".

claudiu.cristea’s picture

Status: Needs review » Reviewed & tested by the community
mikeryan’s picture

Title: Reduce/remove tight coupling of migration destination plugins » Remove the md_entity destination plugin hack
Issue summary: View changes
Status: Reviewed & tested by the community » Needs work
Issue tags: +Novice
Parent issue: #2543536: [meta] Reduce/remove tight coupling of migration classes »

Now that I'm explicitly narrowing the scope, I recognize that removing the unused $migration parameter from fields() is out-of-scope here. Taking those changes out is a novice task - if no one picks it up in a day or so I'll do it myself.

chipway’s picture

Status: Needs work » Needs review
FileSize
7.85 KB
4.43 KB

Applied mikeryan comment #58.

heddn’s picture

Assigned: Unassigned » heddn

Assigning to myself to review. Reviews from others is fine in the mean time.

heddn’s picture

Status: Needs review » Reviewed & tested by the community

There are no more md_entity mentions in all of core, except for the BC layer. The migration is no longer passed into fields. Do we need to add a test of the BC layer? Me thinks no. Ready to go.

heddn’s picture

Assigned: heddn » Unassigned

un-assigning.

alexpott’s picture

Status: Reviewed & tested by the community » Needs work
  1. +++ b/core/modules/migrate/src/Plugin/MigrateDestinationInterface.php
    @@ -39,9 +39,6 @@ public function getIds();
    -   * @todo Review the cases where we need the Migration parameter, can we avoid
    -   *   that? To be resolved with https://www.drupal.org/node/2543568.
    -   *
        * @param \Drupal\migrate\Plugin\MigrationInterface $migration
        *   (optional) The migration containing this destination. Defaults to NULL.
    

    Does this need a new issue then? Rather than removing the comment.

  2. +++ b/core/modules/migrate_drupal/src/Plugin/migrate/destination/EntityFieldStorageConfig.php
    @@ -2,87 +2,19 @@
    -  /**
    -   * {@inheritdoc}
    -   */
    -  public function calculateDependencies() {
    -    $this->dependencies = parent::calculateDependencies();
    -    // Add a dependency on the module that provides the field type using the
    -    // source plugin configuration.
    -    $source_configuration = $this->migration->getSourceConfiguration();
    -    if (isset($source_configuration['constants']['type'])) {
    -      $field_type = $this->fieldTypePluginManager->getDefinition($source_configuration['constants']['type']);
    -      $this->addDependency('module', $field_type['provider']);
    -    }
    -    return $this->dependencies;
    -  }
    

    This is the only code that might result in different behaviour. I'm not sure why we are emptying this class.

  3. +++ b/core/modules/migrate_drupal/src/Plugin/migrate/destination/EntityFieldStorageConfig.php
    @@ -2,87 +2,19 @@
    -  /**
    -   * {@inheritdoc}
    -   */
    -  protected static function getEntityTypeId($plugin_id) {
    -    return 'field_storage_config';
    -  }
    

    I think removing this would break things. Since it'll now do:

      protected static function getEntityTypeId($plugin_id) {
        // Remove "entity:".
        return substr($plugin_id, 7);
      }
    

    Which wouldn't return 'field_storage_config'. Again I just think we should be deprecating the class and not actually changing it. If we change it we definitely need a test to prove we've not broken it.

mikeryan’s picture

Status: Needs work » Needs review
Issue tags: -Novice
FileSize
5.12 KB
4.78 KB

Does this need a new issue then? Rather than removing the comment.

New patch deprecates the parameter (and documents that it is unused).

This is the only code that might result in different behaviour. I'm not sure why we are emptying this class.

It's kind of the whole point to remove this hack, which pretty much only works by accident... But, if simple deprecation is the easiest path forward, let's do that.

heddn’s picture

Assigned: Unassigned » heddn

Assigning to myself for a final review.

heddn’s picture

+++ b/core/modules/migrate/src/Plugin/MigrateDestinationInterface.php
@@ -83,11 +83,9 @@ public function getIds();
+   * @deprecated in Drupal 8.2.x, will be removed before Drupal 9.0.x.

I can see what we are trying to do here, but I don't think we can mark a parameter deprecated via an annotation. But I also cannot find any docs on how or if this is allowed or possible.

Except for that small nit, this is good to go. Anyone know?

heddn’s picture

Assigned: heddn » Unassigned
mikeryan’s picture

Assigned: Unassigned » mikeryan

I'll remove the annotation and expand the comment.

mikeryan’s picture

heddn’s picture

Status: Needs review » Reviewed & tested by the community

Random test failure against 8.3.x. All feedback addressed. Back to RTBC.

  • catch committed 09ad5fd on 8.3.x
    Issue #2543568 by mikeryan, quietone, Ryan Weal, chipway, iMiksu, heddn...
catch’s picture

Status: Reviewed & tested by the community » Fixed

Committed/pushed to 8.3.x and cherry-picked to 8.2.x. Thanks!

  • catch committed bcb0a90 on 8.2.x
    Issue #2543568 by mikeryan, quietone, Ryan Weal, chipway, iMiksu, heddn...
xjm’s picture

I think this may have broken HEAD.

xjm’s picture

It was actually #2746671: CCK field data not available for D7 taxonomy term migrations so I left this issue alone. :)

Status: Fixed » Closed (fixed)

Automatically closed - issue fixed for 2 weeks with no activity.