Integrate with the Commerce Physical Product / Physical Fields

I too would find this useful functionality.

As it is not possible to import weight into the physical field, I have imported weights into a custom temporary field, now I am looking for a way to copy the contents of that field to Weight field and delete the custom temporary field. Any advise please?

I had a go at exposing enabling the mapping of physical weights by Commerce Feeds in the attached patch.
Some limitations of the patch though :

• It does not map physical dimensions, just weight, but it would be relatively straightforward to add that mapping
• The default unit is hard-coded as 'kg' as I couldn't find a function that would pick up the default unit, as defaulted in weight field that needs to be defined for each product type
• The name of the weight field is field_physical_weight. I have not tested if another name would work

I hope this patch will help build a robust solution to this issue.

Marking as needs review

I applied the patch #3 and now when I want to got to mapping page, I get the following error message:

Fatal error: Call to undefined function _commerce_physical_feeds_processor_targets_alter() in /foo/sites/all/modules/commerce_feeds/commerce_feeds.module on line 63

Any advise to fix, please?

In the file commerce_feeds.module I changed the lines:

function commerce_physical_feeds_processor_targets_alter(&$targets, $entity_type, $bundle_name) {
module_load_include('inc', 'commerce_feeds', 'mappers/commerce_physical');
_commerce_physical_feeds_processor_targets_alter($targets, $entity_type, $bundle_name);
}

into

function commerce_physical_feeds_processor_targets_alter(&$targets, $entity_type, $bundle_name) {
module_load_include('inc', 'commerce_feeds', 'commerce_physical');
_commerce_physical_feeds_processor_targets_alter($targets, $entity_type, $bundle_name);
}

that solved my problem.

Yes, the file commerce_physical.inc is supposed to be stored in the mappers directory, but the patch at #3 does not take this into account.
Sorry for the inconvenience.

I don't see anything wrong with #3, it applies and works fine for me out of the box.

However, I'd like dimensions support to be included prior to committing this into commerce feeds.

applying the patch in #3 I get

patch unexpectedly ends in middle of line
patch: **** malformed patch at line 96:

Hi, Yes please for dimensions support! Greetings, Martijn

Subscribing. We have over 2000 products that we need to import from a client's previous propriety CMS. The commerce feeds works great for this except for the problem of not being able to import weight and dimensions. The weights are in pounds too, so the default to kg is not good for us either.

Love this - but one question. If I replace 'kg' with 'lbs' as the default unit - will this work? Is it 'lbs' or 'lb'?

$field[LANGUAGE_NONE][$i]['unit'] = 'lbs';

#3 work for me. Thanks Patricec!
very strange that it is not done initially ..

Just noting that #1356462: Feeds Support for Commerce Physical Product has been marked as duplicated in favor of this one and has a very useful patch that may be merged with the one here.

I've created a patch based on @Patricec #3 patch above and the one that I initially created for #1356462: Feeds Support for Commerce Physical Product. This patch allows you to import commerce physical product dimensions, weight, and their respective units. This is working great for our needs and will hopefully help some of you out.

Note: I had trouble applying patch #3 so this patch is based off of commit: http://drupalcode.org/project/commerce_feeds.git/commit/cb2bcdc.

Marking as needs review

Hi,

I just tried this patch 'commerce_feeds_physical_weight_and_dimensions-1293820-17.patch' on the latest dev release of commerce_feeds and it results in a white screen on the 'admin/structure/feeds/edit/update_products/mapping' page.

The MAMP php error log shows: Fatal error: Call to undefined function _commerce_physical_feeds_processor_targets_alter() in ../sites/all/modules/contrib/commerce_feeds/commerce_feeds.module on line 75

I am no feeds code expert so some help to solve this would be greatly appreciated as this is vital functionality if you calculate shipping by weight on thousands of products.

Fatal error: Call to undefined function _commerce_physical_feeds_processor_targets_alter() in ../sites/all/modules/contrib/commerce_feeds/commerce_feeds.module on line 75

Interesting. The patch actually creates a mappers/commerce_physical.inc file, are you sure you've got that file?

I worked this issue out, running the patch in terminal was putting the 'commerce_physical.inc' file in the 'commerce_feeds/' folder and not 'commerce_feeds/mappers/' I do not know why, is there something you have to add to run the patch to make it place it in the correct sub-folder?

The feeds mappings page now works, thought I was home and dry, however, running the import does not update the weights. The log confirms that products were imported, however the product view shows no change to the weights for each product.

Any ideas?

Are you doing this for the patch?

patch -p1 < commerce_feeds_physical_weight_and_dimensions-1293820-17.patch

I've just tried it and I get the file correctly in mappers directory

I looked back through the terminal commands and I missed off the -p1, these things are usually my mistakes.

Much more importantly though, do you have any idea why the feed to the commerce product physical weight is not updating the stored weights?

Hey @andrewscullion. Can you export your feed mapper and attach it to this thread so we can help you troubleshoot?

$feeds_importer = new stdClass();
$feeds_importer->disabled = FALSE; /* Edit this to true to make a default feeds_importer disabled initially */
$feeds_importer->api_version = 1;
$feeds_importer->id = 'update_weight';
$feeds_importer->config = array(
  'name' => 'Update Weight',
  'description' => '',
  'fetcher' => array(
    'plugin_key' => 'FeedsFileFetcher',
    'config' => array(
      'allowed_extensions' => 'txt csv tsv xml opml',
      'direct' => FALSE,
    ),
  ),
  'parser' => array(
    'plugin_key' => 'FeedsCSVParser',
    'config' => array(
      'delimiter' => ',',
      'no_headers' => 0,
    ),
  ),
  'processor' => array(
    'plugin_key' => 'FeedsCommerceProductProcessor',
    'config' => array(
      'product_type' => 'rope_product',
      'author' => '1',
      'tax_rate' => TRUE,
      'mappings' => array(
        0 => array(
          'source' => 'SKU',
          'target' => 'sku',
          'unique' => 1,
        ),
        1 => array(
          'source' => 'Weight',
          'target' => 'field_physical_weight:weight',
          'unique' => FALSE,
        ),
      ),
      'update_existing' => '2',
      'input_format' => 'plain_text',
    ),
  ),
  'content_type' => '',
  'update' => 0,
  'import_period' => 1800,
  'expire_period' => 3600,
  'import_on_create' => TRUE,
  'process_in_background' => FALSE,
);

Thank you for the help.

Hey Andrew,
I didn't realize that my patch required you to name your weight field commerce_physical_weight. I'm working on a revised patch and will have it up shortly. Thanks for catching this!
Andy

@andrewscullion,
Give this patch a whirl. I tested with your feed importer and it appears to fix the problem. Roll back to the latest commit of the commerce_feeds module and then apply this patch. Let me know if you have any trouble.
Thanks for finding this!
Andy

Thanks for the rapid response, and it's nice to find out it is not me doing something stupid for a change. I will try the new one and let you know.

Andrew

That worked perfectly, thank you Andy.

Worked perfectly for me. Thanks.

It works very well for me. Thank you.

I didn't want to have a column for the units in the csv file I was importing so I modified commerce_physical_feeds_set_target( ) from the above patch. Additionaly it gives the correct defaults for empty cells. To do: Set numeric values to their defaults as well.

Will

function commerce_physical_feeds_set_target($source, $entity, $target, $value) {
  list($field_name, $sub_field) = explode(':', $target, 2);

  // Handle non-multiple value fields.
  if (!is_array($value)) {
    $value = array($value);
  }
  $info = field_info_field($field_name);
  $field = isset($entity->$field_name) ? $entity->$field_name : array();

  // Find the default unit. I imagine there is an easier way to do this...
  $entity_type = key($info['bundles']);
  $bundle_name = $info['bundles'][$entity_type][0];
  $instance_info = field_info_instance($entity_type, $field_name, $bundle_name);
  $default_unit = $instance_info['widget']['settings']['default_unit'];
  
   foreach ($value as $i => $v) {
	// always put the default units (same as in commerce_feeds/mappers/commerce_price.inc).
	$field[LANGUAGE_NONE][$i]['unit'] = $default_unit;
	if ('unit' == $sub_field) {
		if (!empty($v)) {
			$field[LANGUAGE_NONE][$i][$sub_field] = $v;
		}
	} else {
		$field[LANGUAGE_NONE][$i][$sub_field] = (!empty($v) && is_numeric($v)) ? $v : 0;
	}
	
    if ($info['cardinality'] == 1) {
      break;
    }
  }
  $entity->$field_name = $field;
}

@wgsimon,
Great idea about pulling in default values. I think I've got an idea to make this work based on what you've provided. It would include the numeric defaults as well. Hopefully, I can get an updated patch shortly.
Thanks,
Andy

Here's a patch that loads numeric defaults (if they exist) as well as the default unit for both weight and dimensions. The numeric defaults would be set automatically if they wern't included in the feed, but I don't think it hurts to add them in the patch since their values are already loaded in the $info_instance array. This also allows you to set specific dimension fields in a feed while others will pull their default value, if for some reason you wanted to do that. Thanks to @wgsimon for finding the default unit feature and submitting the code above. Needs review.

NOTE: Do not use this patch

Ok, a couple of thoughts on this, the patch looks really nice but after seeing this line:

$info_instance = field_info_instance('commerce_product', $field_name, $entity->type);

I just realized that the Physical fields could be attached to anything, not just products, maybe after all this patch belongs in there if we can figure out how to know the entity type in the callback without hardcoding it.

Looking into this.

Related #1372070: Integrate with Feeds (Patch Ready)

The entity type is not hardcoded in the suggestion in my last post (#32), although it may not be the best way of getting it.

Will

Right, I need to figure out if this is safe enough:

$entity_type = key($info['bundles']);

Ahh... good catch. I was following the conventions in the commerce_price.inc mapper. Is it possible that it needs to be updated as well, as to not limit price to 'commerce_product'? It looks like we can use $entity->feeds_item->entity_type instead. I realize today that the patch in #34 is crap. I thought I tested it thoroughly, but apparently not. Here is an updated patch that fixes a few problems in #34 and swaps the hard coded 'commerce_product' with $entity->feeds_item->entity_type. Its confusing to me that $entity->type references the bundle name instead of the entity type, but that's beside the point here.

If we leave out some but not all of the numeric values in the mapping then the defaults are not set correctly.
If Dimensions:Units doesn't come last in the mapping order then it will be overwritten with the default.

I suggest replacing

	$field[LANGUAGE_NONE][$i]['unit'] = $default_values['unit'];

with

	if ( !isset( $field[LANGUAGE_NONE][$i] ) ) {
		foreach ( $default_values as $default_sub_field => $default_value ) {
			$field[LANGUAGE_NONE][$i][$default_sub_field] = $default_value;
		}
	}

With this modification we can have any combination of missing mappings and missing import fields.

It may be more elegant if the defaults could to be initialised in a function higher up the call stack. This will avoid checking to see if the defaults have been set each time.

Will

Awesome Will. I've updated the patch with your suggestion. I tested adding length in the mapper and leaving the rest blank and it works like a charm.

Related: #1600818: Price:Currency mapping before Price:Amount mapping overwrites currency with default value

As discussed, the patch belongs to Physical module as you could add weight and dimensions to nodes, users or whatever entity you'd like to.

I've reviewed the patch, adapted it to physical and fixed the entity_type getting method.
Patch proposed in #1372070: Integrate with Feeds (Patch Ready)

Many many thanks to everyone here for the effort, patches and testing!!!

#41 worked for me.

#41 worked for me as well. Thanks to both andyg5000 and Will!!! -Frederico

#41 worked for me too. It updated the weights for ALL product variation types, even though I had specified the "Bundle" and "Product type". It was what I wanted to do, and I expected to need to specify quite a few "Bundles" and "Product Types". I was both shocked and happy. Thanks for the hard work.

For anyone needing to import 0 (zero) to the physical, install feeds tamper (if you aren't using it already) and make sure to add a plugin for "Format a Number" and set the decimals to 1 or more places.

Otherwise, if you have a 0 (zero) in your import data, this does not get carried through to the site and is instead left blank on required fields.

/sites/all/modules/commerce_feeds]$ git apply -v commerce_feeds_physical_weight_and_dimensions_with_defaults_1293820-40.patch
Checking patch commerce_feeds.module...
error: while searching for:
module_load_include('inc', 'commerce_feeds', 'mappers/commerce_product_reference');
_commerce_product_reference_feeds_processor_targets_alter($targets, $entity_type, $bundle_name);
}

error: patch failed: commerce_feeds.module:64
error: commerce_feeds.module: patch does not apply
Checking patch mappers/commerce_physical.inc...

have commerce_feeds (7.x-1.x-dev)

@brandonc503 are you patching against the stable or dev version?

@brandonc503 you were able to find a solution? Even I am getting the same error

@manglanis6 I found the ultimate "solution".

1) Don't apply the patch from #41. If you have, delete commerce_feeds and re-download it.

2) Download and use any version of the physical module that is released on or after November 26, 2016. As of right now, that means you need to use the dev version of physical because 1.0 does not contain the code for it.

#43 points out this functionality was removed from commerce_feeds module and placed within the physical module, making the patch in #41, unnecessary.

So, install the physical module to get this functionality, as long as the physical module is newer than 1.0.