I posted this problem in another thread (717408) but will create a new one so it's visible :)

I recently mass uploaded 15000 or so products using node import, and now when I create a test order only the parent sku is showing when I review the order, when I need the adjusted sku to show. The way I have it set up is numerical, for instance I have a clothing item that has a sku of 736438 and has 3 variations in sizes. The adjusted sku then becomes (parentsku+childsku), or:

Small: 736438-55651
Medium: 736438-55652
Large: 736438-55653

So in the order, if someone bought a large, 736438 is showing up on their order.

I need 736438-55653 to show up.

I looked into the coding to see if I could manually display the products' full sku but it could get very messy as that data appears to be in a different table called uc_products_adjustments and I'm not really sure on how to manually get that to display.

Also, one note, is that I imported all the products with stock disabled, as inventory is not needed on the site. However, as a test, I enabled stock on both the child and parent skus on the test product and placed an order, and it still didn't show up correctly on the order form, so I'm guessing that that's not the issue. I also disabled the parent sku in a different order as done issue 717408 and that still didn't work. Though their issue was that the parent and child skus were the same, and mine should always be different because the child sku is unique.

I am also live so I'm a little nervous right now about making big changes like re-importing and such. Anything that you can do to help me out would be hugely appreciated!

Thanks!

Phoenixxx

Drupal 6.15 | Ubercart 6.x-2.x-dev | Node import 6.x-1.x-dev

CommentFileSizeAuthor
#3 order-form.png15.9 KBPhoenixxx
#3 product-edit-adjustments.png20.46 KBPhoenixxx

Comments

Phoenixxx’s picture

Phoenixxx commented

Can anyone point me in the right direction? Any experience/wisdom you have on this subject would be awesome!

Thanks!

-Phoenixxx

Andy_Lowe’s picture

Andy_Lowe commented

The first thing you need to do is setup a copy of your site to test fixes against if your site is already live. At the very least, make a good backup of the database. Try this: http://drupal.org/project/backup_migrate

It sounds to me like your import did not create sku modifications for your product attributes. For an example, look at the beanie product on http://demo.ubercart.org (specifically here: http://demo.ubercart.org/node/2/edit/uc-adjustments ) Do your products have different sku's listed for the different options?

If they don't, you have to figure out how to get that info into the database. Try entering the data by hand for a couple of products and then look in the uc_product_adjustments tables to see how it should look.

Phoenixxx’s picture

Phoenixxx commented
StatusFileSize
new product-edit-adjustments.png20.46 KB
new order-form.png15.9 KB

Hey Andy,

Thanks for the quick response! As it turns out I've got that module installed, and a sound backup of the site. I still get nervous though. :)

This is weird. I'm pretty sure I know exactly what you mean with the product attributes. I've attached a picture of the test product adjustment page (the alternate sku was inserted in the import, not by me manually), and a picture of the order form listing only the parent sku, not the sub-sku with it.

*update* - It is now working, though not in the way I had hoped, lol. I found out that if I go to the product adjustments page at node/%/edit/adjustments and click 'submit' at the bottom (without having to enter the adjusted sku, because it's already there), after I make a purchase on that product the adjusted sku comes up correctly! So that is good, but how can I get it to update on all 15,000 skus without having to go to each product and submit manually?

Phoenixxx’s picture

Phoenixxx commented

It seems to be an issue with the uc_products_adjustments table, where the products adjustments'* I submit manually have this for their info:

*Notice I'm not adding the adjusted sku. The info is already there in the field, all I have to do is click submit and then the attribute works for that product.

nid combination model
2163 a:1:{i:1;s:2:"13";} 17771-126818
2977 a:1:{i:1;s:3:"155";} 61732-178767

while the products imported have this for their info:

nid combination model
7250 a:1:{i:1;i:112;} 6849-104856
7251 a:1:{i:1;i:451;} 6897-108665
7251 a:1:{i:1;i:7;} 6897-108710
7251 a:1:{i:1;i:6;} 6897-108711

Notice the change in the manually submitted products, in their combination? If I were to bet I'd say they were referencing the options for the product, where the rest of the products are not. I'm wondering why these values didn't get entered right away during product creation/import and what, if anything, I did to break it. Any help in getting this to update automatically is much appreciated!!

tr’s picture

tr commented

Yeah, that would do it. When you save it manually your attribute-option array has an integer index and a string value. However, when you import it, you have an integer index and an *integer* value. When Ubercart looks for an alternate SKU in the adjustments table, it doesn't see any matching combinations so it uses the default base SKU. This is definitely a problem with your import - you inserted bad data into the table so naturally it doesn't work as expected. To fix it you could write a simple script to read in the combination, cast the array value to a string, then write it back out.

Phoenixxx’s picture

Phoenixxx commented

Hey TR,

Thanks for the advice! Unfortunately I am not much of a php programmer - I looked into the ubercart code to try to use the form-submit code to use as a sample script, but I couldn't locate it. I also tried different test imports with different variations of node import to see if I could successfully import the adjustments, but with no luck there, either. The data IS being loaded into the database, just not the correct way. I have thought about just exporting/re-importing the data into an csv format, adding the s:x:"xxx", which IS possible, the only problem there is the 's'. I also can't figure out where the 's:x' is coming from, it doesn't seem to be related to an option, taxonomy, etc - even so it seems to be referencing something outside of the table.

TR, would you be able to help me out with writing the script, or is that even possible with the unknown s:x value? Otherwise I fear I may be going through each product one by one... LOL!

Thanks again for your help!

tr’s picture

tr commented

a:1:{i:1;i:112;} is a serialized array. Format is a:n:{$key1;$value1;$key2;$value2; ... $keyn;$valuen;} where n is the number of elements in the array and the $key, $value are the keys and values for each array element. $key and $value are also encoded by type.

So in this case "a" is a 1-element array, key is an integer equal to "1" (i:1), value is an integer equal to "112" (i:112).
In PHP this would be $combinations = array(1 => 112);

What you want is a:1:{i:1;s:2:"13";}
In this case "a" is a 1-element array, key is an integer equal to "1" (i:1), value is a string with 2 characters equal to "13" (s:2:"13").
In PHP this would be $combinations = array(1 => "13");

Phoenixxx’s picture

Phoenixxx commented
Status: Active » Fixed

TR -

Thanks a TON for your help! I wasn't sure how exactly to use the $combinations - array code to change the data in the database, but once you showed me how the array worked, I had enough information to form a solution. I ended up exporting the data from the database, editing the structure of the existing array, adding in the letter 's' and the quotations, then separated the data into different cells, used a blank column for a calculation determining the number of characters in the last string, then combined the data back together and imported. Probably wasn't as simple as just creating the script, but hey, it works now! Better than about sixty straight hours of repeatedly clicking 'submit.' LOL!

Thanks again TR and Andy for your help!

Status: Fixed » Closed (fixed)

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

nathan.bolin’s picture

nathan.bolin commented

TR does a good job of explaining in #7. To add to that . . .

In the node import module, the file responsible for importing attributes is supported/ubercart/uc_attribute.inc which stores data in the uc_product_adjustments table incorrectly. When manually entering and saving adjustments, the serialized array will look like:

a:1:{i:1;s:2:"13";}

However, when importing products with attributes using node_import, the serialized array stored in the DB looks like:

a:1:{i:1;i:112;}

What this means is that node_import is using integers in the key and value of the attributes array, The value needs to be a string so to resolve this, all you need to do is modify uc_attribute.inc around line 238:

$attrs_present[$aid] = $valid_option;

Change to:

$attrs_present[$aid] = strval($valid_option);

I hope this helps someone, and saves the headache. (Using node_import 6.x-1.1 and Drupal 6.22)