Understood Wim -- I think we just have 2 contrasting approaches to development, neither wrong or right.
We'll work on some of these changes on a separate fork or branch and offer to merge later after a proven outcome.
-1. Drastic slow down is exaggerated. A few SQL queries per migration import task is < 0.1% impact. Total cost / benefit -- that would save our team time tracking down logging issues across all of Drupal.
Proper solution in a perfect world is as you describe, but we're balancing other constraints.
jienckebd → created an issue.
Great idea and great work Dan. You're awesome and I object to the current context.
If we land #3426231 ✨ Port AMA install process from ACLI to Drupal Active to port the AMA install process to Drupal from ACLI and support installs with composer lenient or non-vetted recommendations, I'd like to MR a set of changes to curated.json with the remaining ~700 D9 curated recommendations that can be installed as non-vetted in D10. We can look at refactoring the vetting process later, but the outcome of that experimental process could be committed as non-vetted without major impact. We could elevate recommendations to vetted once they're validated on real migrations.
Started a draft MR.
Need a day or 2 to finish the rest if we're agreed on the direction.
jienckebd → created an issue.
It seems that this issue 🐛 Custom aliases (which are not generated with the actual patterns) can be lost during the migration Needs review combines 4 pathauto 1.x issues including this one. So I applied the same change to that issue to make the combined patch pass tests.
It seems that this issue 🐛 Custom aliases (which are not generated with the actual patterns) can be lost during the migration Needs review combines 4 pathauto 1.x issues including this one. So I applied the same change to that issue to make the combined patch pass tests.
Confirming that Dan is awesome and did great work on this and I feel questionable and compromised trying to finish his work in the current context. So I'm doing this on my own time.
Tests are running okay locally now based on this updated patch 🐛 Custom aliases (which are not generated with the actual patterns) can be lost during the migration Needs review .
That patch combines 4 of the original pathauto patches from Drupal 9 and adjusts them to pass tests on Drupal 10.
We can't discern if the tests pass because our pipeline configuration is still failing either due to IEF in D10, bean_migrate in D9, or database connection issues. I'm moving around those for now but let me know if I can help there.
jienckebd → made their first commit to this issue’s fork.
Patch from #69 is failing tests.
The node_type condition plugin was deprecated since Drupal 9.3 → in favor of a generalized entity_bundle:* condition plugin.
This pathauto issue → applies this change to 1.x branch.
The patch in this issue still references the removed node_type condition plugin and results in test failures.
The attached patch:
- Replaces references to the node_type condition plugin with references to the generalized entity_bundle:node condition plugin.
- Changes pathauto pattern label "Taxonomy term - Sujet de discussion" to "Taxonomy term - forums" as expected by latest D10.
jienckebd → created an issue.
Updated MR to support both "drush ama:*" and "drush migrate:*" commands.
jienckebd → created an issue.
jienckebd → created an issue.
It seems that the kernel tests are failing because of schema changes in Webform 6.
The attached patch helps these tests pass.
Hey Dan!! I know you.
The node_type condition plugin was deprecated since Drupal 9.3 → in favor of a generalized entity_bundle:* condition plugin.
This pathauto issue → applies this change to 1.x branch.
The patch in this issue still references the removed node_type condition plugin and results in test failures.
The attached patch replaces references to the node_type condition plugin with references to the generalized entity_bundle:node condition plugin.
The node_type condition plugin was deprecated since Drupal 9.3 → in favor of a generalized entity_bundle:* condition plugin.
This pathauto issue → applies this change to 1.x branch.
The patch in this issue still references the removed node_type condition plugin and results in test failures.
The attached patch replaces references to the node_type condition plugin with references to the generalized entity_bundle:node condition plugin.
Aside from IEF and the D10 test failures, the DB connections may be causing the D9 tests to fail.
The "Contrib migrations Drupal 9 (pinned) 📌: [8.1]" job is now indicating "Connection refused" to the database before and after the change in comment 4.
Previously, this same job was failing because of a failure in bean_migrate. I downloaded the artifact for that job and ran the same tests locally and they passed. The block that's null in that job is loaded here, and it could be null if there was a database issue in a prior step. The fact that it runs fine locally and the same job is now indicating a separate DB error makes it likely the root cause is a DB issue and not specific to the logic.
The attached patch is rerolled on 2.0.x.
It also addresses feedback in comment 8 except for accounting for "negate" configuration. I'm only seeing that property on a few validation types and not on the "equals" one.
Also tested on a few clients and adjusted the schema to map correctly. And cleaned up a few PHP warnings.
2 patches from these core issues cause the IEF default widget test to fail:
- https://www.drupal.org/project/drupal/issues/3204212 📌 Convert remaining widget and formatter type migrations to MigrateField plugins Needs work
- https://www.drupal.org/project/drupal/issues/3108302 →
IEF expects a specific schema in migration "d7_field_instance_widget_settings" for it to map the D7 widget plugin IDs (inline_entity_form and inline_entity_form_single) to their D10 widget plugin IDs.
Because these patches change that schema, IEF no longer does this mapping and the widget is replaced to its field type's default of "entity_reference_autocomplete" and that fails the test.
Seems like there are some dependencies to solve in core before IEF could have passing tests. What do you advise for next step?
Thanks Wim!
I'm able to recreate this test failure for inline_entity_form locally now after copying the composer.* files out of the "Artifacts" from the failed CI job.
Working my way back from that to determine specific root cause. Will follow up here.
Looks like there's a great idea here for the DB connection issues: https://www.drupal.org/project/gitlab_templates/issues/3414252#comment-1... →
jienckebd → created an issue.
Great start Dan!
As you noted, the data does need to be mapped in 2 ways:
1. D10 field property "entry_id" was field property "entryid" in D7.
2. D10 field property "partner_id" was a Drupal variable applied to all Kaltura field values.
The attached patch works on a sample client.
There may be a better way to map a D7 Drupal variable to a D10 field value property. But the only examples I saw for mapping D7 variables required a "variable" source plugin, while MigrateField plugins have their own source plugin.
jienckebd → made their first commit to this issue’s fork.
jienckebd → made their first commit to this issue’s fork.
jienckebd → created an issue.