- 🇺🇸United States makbeta
Tested the patch #45 with v3.2 & v4 against Drupal 9 running PHP v8.
@heddn Can this be incorporated into version 3.2 & 4, so all this work doesn't get lost in iterations?
This started out as a starting point to address the errors generated from running d7_field. It has grown to cover all the field migrations.
The problem with the field migrations is that in Commerce 1 product displays are nodes and in Commerce 2 they are products. So, the fields on nodes in D7 need to be 'moved' to fields on the products. Simple eh?
There are 5 field migrations that need to be modified, field, field_instance, view_mode, formatter, and widget. if the field being processed is on a product display then change the destination from node to commerce_product. This can be done in the alter where the migration is given as an array. But identifying the desired field migration is a bit tricky. To identify the field migration the migration['id'] shouldn't be used, because this is configurable by the user. Instead, it would be better to look at the class of the source plugin. If it is one of the field migrations, then this is a migration to alter. But is this class available - still working on that.
Commerce 1 also has fields on entities that do not exist in Commerce 2. Those fields are currently skipped to avoid errors and fatals about non existing entities.
Also note that, unlike the Ubercart 6 related issue, there is a product deriver issue for commerce #2908399: Deriver for products → . I don't think there is a code reason for the difference, I suspect it was just because I was writing derivers for product variations and line items at the time and another one was easy. Whether the deriver is used or not (the existing node migration can be altered) the field migrations need to be altered because the field migrations look at field_config and field_config_instance which, of course, have the Commerce 1 entity types.
Keeping the original report to assist with tracking the follow up issues created.
original report
Simply said, d7_field generates lots of errors. These need to be sorted for
#2899672: Commerce 1 Test "All The Things" →
These field type need solutions:
And these entities have fields, which need a solution.
Modify the field migrations
Make a patch
N/A
N/A
N/A
Fixed
2.0
Drupal Commerce 1.x
Not all content is available!
It's likely this issue predates Contrib.social: some issue and comment data are missing.
Tested the patch #45 with v3.2 & v4 against Drupal 9 running PHP v8.
@heddn Can this be incorporated into version 3.2 & 4, so all this work doesn't get lost in iterations?