Problem/Motivation
One of our D7 sites includes English, French and Spanish nodes.
We'd like to migrate only English and French nodes to D9 as we are dropping support for Spanish content.
The migration system does not seem to offer a way to limit the language of nodes being migrated. Any chance this can be supported ?
Proposed resolution
We could do something similar to the node_type configuration key in source plugins d6_node, d7_node and possibly d7_node_entity_translation.
i.e. add a configuration key language that people could use like so:
source:
plugin: d7_node
language: [en, fr, und]
# Only migrates English and French nodes, as well as nodes which have an undefined language.
Remaining tasks
Attached is a proposed patch.
Add test coverage
Code review
| Comment | File | Size | Author |
|---|---|---|---|
| #2 | limit-language-node-migrations-3339717-1.patch | 4.74 KB | fengtan |
Comments
Comment #2
fengtanComment #3
smustgrave commentedThis issue is being reviewed by the kind folks in Slack, #needs-review-queue-initiative. We are working to keep the size of Needs Review queue [2700+ issues] to around 400 (1 month or less), following Review a patch or merge request as a guide.
Seems like a valid request.
This will need test coverage to show it working.
Comment #4
mikelutzThe core migration sources are designed to support the core migration UI, which itself is designed to migrate all content from a d7 site. There is no need to limit nodes by language, as they are all migrated at once in the various core migration. You will want to have a custom source plugin to support your custom migration, but it is not appropriate to include custom migration sources in Drupal core. The migration system is designed to be extensible to allow you to create targeted source plugins like this as needed.
Comment #5
mikelutzComment #6
smustgrave commentedThanks @mikelutz for taking a look!
Comment #7
mikelutzNote: we do have an issue #3069776: SQL source plugins: allow defining conditions and join in migration yml to allow arbitrary sql filtering on ANY plugin extending SqlBase. This is something that we would make use of in core to reduce the number of source plugins needed. It would also be a path to solving your issue. In retrospect, I'm going to close this as a duplicate of that one.