Hello all, it’s time for the biweekly migration subsystem meeting. The meeting will take place in slack in various threads. This meeting:
➤ Is for core migrate maintainers and developers and anybody else in the community with an interest in migrations
➤ Usually happens every second Thursday and alternates between 1400 and 2100 UTC.
➤ Is done on the #migration channel in Drupal Slack (see www.drupal.org/slack for information).
➤ Happens in threads, which you can follow to be notified of new replies even if you don’t comment in the thread. You may also join the meeting later and participate asynchronously!
➤ Has a public agenda anyone can add to. #3456078: [meeting] Migrate Meeting 2024-07-18 2100Z)See the parent issue for an idea of the typical agenda.
➤Transcript will be exported and posted to the agenda issue. For anonymous comments, start with a 👤 emoji. To take a comment or thread off the record, start with a 🚫 emoji.
| Migrate Initiative Meeting |
#3315257: [meta] Tasks to deprecate Migrate Drupal (edited) |
| benjifisher |
The Plan issue is now Fixed: #3371229: [Policy] Migrate Drupal and Migrate Drupal UI after Drupal 7 EOL |
| benjifisher |
@quietone recently added #3463321: Deprecate Migrate Drupal UI, and I just marked the issues are Related. |
| benjifisher |
I think that deprecating migrate_drupal_ui will not be very complicated. Should we start there? |
| benjifisher |
The first item under "Remaining tasks" for migrate_drupal (#3315257) is
Move integrations implemented by other modules to the extension.
Are we still planning to do that?
|
| benjifisher |
We are planning to move some things from migrate_drupal to migrate. At least the content_entity source plugin, Drupal\migrate_drupal\Plugin\migrate\source\ContentEntity.
|
| benjifisher |
But the line I quoted seems to be saying that we should move the d7_node source plugin, Drupal\node\Plugin\migrate\source\d7\Node, to the migrate_drupal module. That was the plan at one point, and it would make the final removal easier, since it would all be in one module. But I do not think it is the current plan.
|
| benjifisher |
@quietone closed the two child issues #3332224: Move migratefield plugins to migrate drupal and #3332998: Move migration code from content_translation to migrate_drupal as "won't fix". I think that is because we decided it would be too much work to move everything to migrate_drupal before removing it.
|
| quietone |
The issue summary is the standard template for removing modules and moving them to core. I removed the obviously no longer needed steps but left anything that might possibly be needed. |
| quietone |
I can't think of any integrations. |
| quietone |
In about 2 weeks I was hoping to start working on these issues. |
| Migrate Initiative Meeting |
#3123534: Process plugin: snippet to re-use YAML config (edited) |
| benjifisher |
The issue is NW for two reasons:
- Issue summary update.
- Tests
|
| benjifisher |
I have been cautious about changing the issue title and the summary, since there are several suggestions on how to implement it and I do not want to push my own idea too strongly. |
| benjifisher |
But I think we have consensus that the snippet plugin is a good solution to the problem. @danflanagan8 explicitly endorsed it in the most recent comment, and several people are using it in their custom migrations. |
| benjifisher |
I also asked, in some previous meeting, whether we still need it now that we have shared configuration in the migrate_tools module. I think the answer is yes: snippet is still useful. |
| benjifisher |
TL;DR: I should update the issue summary and provide a test. |
| alison |
Happy user of snippet here, following along -- thank you!
I looked at your updates, I'm not equipped to test tests, I'll keep an eye on the issue, though. (edited) |
| Migrate Initiative Meeting |
#3440904: Process plugin: build an array from source, destination, pipeline (edited) |
| benjifisher |
I find this plugin incredibly useful ... but I am biased, because I wrote it. |
| benjifisher |
The issue is NR. The issue summary and comments have several examples of how it can be used. |
| amaisano |
NR? |
| benjifisher |
Needs Review |
| joelpittet |
Had a quick look @benjifisher and it went way over my head in terms of use-case, probably because I have not needed callback or service yet. Just wanted you to know I had a look but ended up like :upside_down_face: |
| benjifisher |
Thanks for trying. |
| joelpittet |
A targeted review audience, aka poking the people in the issue comments, may yield better feedback |
| joelpittet |
As they might face the problem, assuming that’s why they are there |
| benjifisher |
FWIW, here is another example. Apply skip_on_empty to both subfields of a formatted-text field:
field_body:
- plugin: skip_on_empty
method: process
source: body/0/value
- plugin: array_template
template:
value: 'pipeline:'
format: hwp_full_html
|
| joelpittet |
It’s tricky to see/grok that is happening by looking at that. |
| joelpittet |
gotta reboot, --sync went rogue and ate up all my disk space. |
Comments
Comment #2
ddavisboxleitner commentedComment #7
benjifisher@ddavisboxleitner:
Thanks for adding the transcript. Next time, please set the issue status to NR when you do that.
Unfortunately, the meeting parser seems to be giving incomplete results. I am having trouble with it, too. I added a bunch of missing comments and some formatting.
Comment #8
benjifisherComment #9
benjifisherComment #10
smustgrave commented@Benjifisher there was a bug recently https://github.com/mdlutz24/drupal-meeting-parser/issues/23#issuecomment... but seems to have been resolved. I'm not super familiar with custom plugins but was told have to update the git branch of the extension locally and reload in chrome.
That fixed it for me at least if that's the error being seen
For this meeting though went into #migration for 8-01-2024 and verified threads were captured.