Problem/Motivation

In migration tests, the 'localize_d7_comment' migration is discovered, which needs d7_comment plugin.
This happens even in those tests where we do not run that specific migration.
The 'd7_comment' plugin is provided by 'comment' module which is not enabled explicitly in all the migration tests.
The migration is in config/optional, so it will only be loaded if all its dependencies are there.

Steps to reproduce

Proposed resolution

Instead of enabling the 'comment' module from every migration test, it should be a dependency of the migration.
This way, the migration will be skipped if 'comment' module is not present, thanks to how config/optional works.

Remaining tasks

User interface changes

API changes

Data model changes

Command icon Show commands

Start within a Git clone of the project using the version control instructions.

Or, if you do not have SSH keys set up on git.drupalcode.org:

Comments

donquixote created an issue. See original summary.

donquixote’s picture

Status: Active » Needs review
donquixote’s picture

The question was raised by Guiu what happens to the migration when we uninstall and reinstall comment module.
It is quite simple, because the migration is in config/optional:
(that is if the dependency is present as in the MR)
- When we uninstall comment module (if no migration has started yet), the migration config entity is gone.
- When we install comment module, while l10n_migrate is enabled, the migration config entity comes back.

I have not checked what happens if there is already a migration based on the config entity.
In my own experiment, the migration would not work anyway because I did not set up the source database.

However, there are some other observations:
- The l10n_migrate module currently depends on migrate_tools via l10n_migrate.info.yml. That module is not present via composer.json require-dev. This should be investigated further.
- To uninstall comment module, one must first uninstall fields that reference comments.

This said, I don'T see that any of the above would be a blocker to adding this dependency in the migration.

guiu.rocafort.ferrer’s picture

Assigned: Unassigned » guiu.rocafort.ferrer
guiu.rocafort.ferrer’s picture

Status: Needs review » Reviewed & tested by the community

I have tried that indeed, installing and uninstalling comment module causes the config object for the migration to be removed or installed.

Looks good to me, setting as RTBC

guiu.rocafort.ferrer’s picture

Assigned: guiu.rocafort.ferrer » Unassigned
donquixote’s picture

Btw I don't really know if we need that "enforced" part.

dependencies:
  enforced:
    module:
      - comment

vs

dependencies:
  module:
    - comment

See https://www.drupal.org/node/2404447

From how I understand it:
If we would let Drupal save the migration config entity, then dependencies are re-calculated. Any non-enforced dependency can be lost, and new non-enforced dependencies could be added, based on the plugins being used.
Having the dependency "enforced" means that we are fully in control, and Drupal is not allowed to remove it when it re-calculates dependencies.
However, for migration config entities, we typically don't allow Drupal to do anything, we only edit them by hand. At least this is how I remember working with migrate_plus migration config entities.
So in our case there is no practical scenario when the "enforced" would make a difference. But it is still safer and more correct, if we manually add a dependency, that we add it as "enforced".

guiu.rocafort.ferrer’s picture

If the dependency is not declared as enforced, then uninstalling the comment module would not cause the configuration to be removed, and we will end up with migrations that depend on modules that are no longer installed, so it needs to be "enforced" to avoid that situation.

fmb made their first commit to this issue’s fork.

  • fmb committed 077dbf5e on 3.0.x
    Merge branch '3553111-the-localized7comment-migration' into '3.0.x'...
fmb’s picture

Status: Reviewed & tested by the community » Fixed

Merged, thanks!

Now that this issue is closed, review the contribution record.

As a contributor, attribute any organization that helped you, or if you volunteered your own time.

Maintainers, credit people who helped resolve this issue.

Status: Fixed » Closed (fixed)

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