As I understood, it's impossible to use this version of feeds to import commerce products.
I've tried to do that and mapped Article (SKU) as source for Variations. But got a message that Variations could not be empty.
Will it be additional module, like commerce_feeds for D7, or it be realized here?

Comments

Alex_eav created an issue. See original summary.

Alex_eav’s picture

Issue summary: View changes
Alex_eav’s picture

I need to clarify.
It's possible to make import when variations reference by: Title. In this case we have options to Autocreate terms. In all other variants like SKU, ID, UUID impossible to create product variation.
Is it posible to made option Autocreate terms for SKU?

megachriz’s picture

Category: Feature request » Support request
Status: Active » Fixed

You need to import the variations first, then the products. For the product importer, the variations can then be referenced by sku.

megachriz’s picture

Title: Commerce products import » Commerce products import (D8)
Project: Feeds » Commerce Feeds
Version: 8.x-3.0-alpha2 » 7.x-1.x-dev

Moving to Commerce Feeds issue queue.

Status: Fixed » Closed (fixed)

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

anybody’s picture

Title: Commerce products import (D8) » Provide simple product (combined product + variations) feed importer default
Version: 7.x-1.x-dev » 8.x-1.0-alpha1

Well this is closed, but I think we should change this into a feature request for a combined import as regular shop systems do. Most users don't unterstand that they have to create two imports to create one "full" product, I guess. This issue is the perfect example why that should be done... and I think is what the creator of this issue needs.

anybody’s picture

Category: Support request » Feature request
megachriz’s picture

Status: Closed (fixed) » Active
StatusFileSize
new2.62 KB
new3.12 KB
new2.96 KB

I agree that it would be useful. When implementing support for Commerce I did try that at first, but I remember from it that it became quite complex: I tried to introduce a "sub feed type" concept, but I got myself a bit tangled in the code, and ultimately decided that separate feed types was a lot easier to implement.

Attached the results of my experiments from then (I still had these files on an old local branch of a project).

anybody’s picture

Thank you MegaChriz,

I currently also don't have the time to implement this, but I think we could have 2 strategies:

  1. Create a specific "Easy Product importer" feed target which maps the fields of parent product and product variation(s) to their specific field targets, for example by prefixing all variation fields with "variation_" (to ensure they're not the same as the parent product and only create a new parent product if it doesn't exist yet (by product name or flag??) > We should have a look if there is a standard and how other Shop systems solve that typically
  2. Extend feeds (by a contrib module or patch or in feeds_tamper?) by (entity) relationships to make it possible to (re-)use an entity relationship for multiple fields. I'd suggest to base that on the current way entity relationships are handled (create if not already existing option) and extend that on other fields from that (new or loaded) entity to make it possible to set their values.

The second solution would also improve feeds for many many other cases, but I couldn't find a module for that yet in Drupal 8. What do you (and others) think?

megachriz’s picture

@Anybody
About the second solution, the Feeds implementation for the Paragraphs module tried to implement something like that. (I did not use that solution for a site as only a few field types on the paragraph entity are supported and I needed support for file fields on paragraphs.)
I may not remember it correctly, but I believe that solution #1 was what I tried to do with the code in #9, at least from an user point of view (maybe not under the hood).

hussein-elhussein’s picture

have a look at Drupal 8 version of: https://www.drupal.org/project/media_feeds
what it does, it grabs all the fields inside a Media entity type, makes them available as 'Targets',
i could do the same with Variations fields, extending this module, and so the user can map to them,
the source would look something like that:
product_title | variation_field_1 | variation_field_2
My product | value 1, value 2 | value 1, value 2

this will result creating 1 product with 2 variations

4kant’s picture

Doesn´t that sound like a practicable solution?

rgnyldz’s picture

This would be a major feature request in my opinion :)

dudeweb’s picture

Hi there, thanks for this module.

As often there is a severe lack of documentation that makes people loose a lot of time, sometimes. Sorry to underline that.

In my case I had to spend days on how to finally import a CSV the right way, using drupal 11 and commerce and feeds.

I finally solved it with an unintuitive solution.

1. Import/create the product variations with no reference to a parent product. You won't be able to see the result but it will work.
2. Import/create the main product with a ref wt the SKU you just created in the first feed.

I used the same CSV with 2 importers.

There might be easier ways but it is the only method that worked for me. I just wanna share it in case another drupalist gets crazy ;-)

megachriz’s picture

@dudeweb
This module does get very little attention from me, so indeed also for the docs. Great that you were able to figure out how to get products imported. It is indeed product variations first and products second. I don't know of an easier way.

If you run into issues like these, it's okay to ask a question on Drupal Slack. For Feeds specific questions, there is the #feeds channel. You are not guaranteed to always get an answer quickly, but the community is quite active on Slack, so it's worth a shot. 🙂