undefined package weights

why is this status ignored? This just might make it work!

apparently i need git, and I don't have that right now... It's just a one line addition - see my ignored .diff file, anyone who knows what s/he's doing, and post a patch please!

Thanks for the response, TableRow. One day I'll get this open source thing down. :)

Yes, I am using the production server. Of course, now I get the same response from the USPS regardless of my patch:

    Please enter the package weight.

API=RateV4&XML=<RateV4Request USERID="SECRET"><Revision>2</Revision><Package ID="0"><Service>ALL</Service><ZipOrigination>19301</ZipOrigination><ZipDestination>08817</ZipDestination><Pounds>0</Pounds><Ounces>0.0</Ounces><Container>VARIABLE</Container><Size>REGULAR</Size><Value>7.99</Value><Machinable>FALSE</Machinable><ReturnLocations>TRUE</ReturnLocations><ShipDate Option="EMSH">02-Aug-2011</ShipDate></Package></RateV4Request>

<?xml version="1.0"?>
<RateV4Response><Package ID="0"><Error><Number>-2147219500</Number><Source>DomesticRatesV4;clsRateV4.ValidateWeight;RateEngineV4.ProcessRequest</Source><Description>Please enter the package weight.  </Description><HelpFile></HelpFile><HelpContext>1000440</HelpContext></Error></Package></RateV4Response>

However, from a computer-science perspective, please look at the code in uc_usps.module's uc_usps_quote function. All references to the $services variable are made inside for loops. It needs a scope outside those closures to have any lasting effect by the time it gets to line 408.

Here are the messages i get when refreshing the checkout page after using the shipping quote, (post-patch; without the patch, there are the problems posted in #1):

Notice: Undefined property: stdClass::$weight_units in _uc_usps_package_products() (line 744 of .../sites/all/modules/ubercart/shipping/uc_usps/uc_usps.module).
Notice: Undefined property: stdClass::$pounds in uc_usps_rate_request() (line 484 of .../sites/all/modules/ubercart/shipping/uc_usps/uc_usps.module).
Notice: Undefined property: stdClass::$ounces in uc_usps_rate_request() (line 485 of .../sites/all/modules/ubercart/shipping/uc_usps/uc_usps.module).

And I have the weight of my product defined in its node.

Darn line endings.

I'll give you a tip! The tip of my boot.

tip of the code base? I guess that means the latest dev version - wherever I find that...

Thanks longwave! <3

Now I just have to figure out the problem with weights.

I get the same problem with only one item in the cart.

I'm not using funky modules. The optional ubercart modules I have enabled are: payment, reports, shipping and shipping quotes.

Under ubercart fufillment I have enabled: USPS and weight quote. I only recently enabled weight quote.

Right now I only have one product in my store, and I have filled in its weight of 3.3 ounces in the edit node dialog.

Under admin->store->config I have U.S. Postal Service (Parcel) checked. For the USPS quote settings, see attached .gif - nearly all the parcel checkboxes are checked.

I really have no idea what's going wrong if it's only configuration based. I'd have to strap on my snorkel and code dive at this point.

looking in my database, both tables uc_weightquote_methods and uc_weightquote_products have zero rows.

uc_products does have my singular product in it, and its weight. uc_packaged_products and uc_packages have nothing in them.

These empty tables seem like they should have something in them for this to work. I'm feeling the urge to uninstall ubercart and reinstall.

I have the default pickup address set to my home address.

For markup I have 0; tried it with 100% too, no change. Weight markup type is grayed out.

Default order fufillment type for products: small package.

Where do I find packaging settings?

In cart/checkout, when I check "My delivery information is the same as my billing information." It doesn't update the order total. When I click "Click to calculate shipping" however, it does update the order total, adding this table row: "U.S.P.S. First-Class Mail Parcel: $1.73," but also shows an error.

Here is the response from the USPS:

Please enter the package weight. 
API=RateV4&XML=<RateV4Request USERID="SECRET"><Revision>2</Revision><Package ID="0"><Service>ONLINE</Service><ZipOrigination>19301</ZipOrigination><ZipDestination>08817</ZipDestination><Pounds>0</Pounds><Ounces>0.0</Ounces><Container>VARIABLE</Container><Size>REGULAR</Size><Value>7.99</Value><Machinable>FALSE</Machinable><ReturnLocations>TRUE</ReturnLocations><ShipDate Option="EMSH">03-Aug-2011</ShipDate></Package></RateV4Request>

<?xml version="1.0"?>
<RateV4Response><Package ID="0"><Error><Number>-2147219500</Number><Source>DomesticRatesV4;clsRateV4.ValidateWeight;RateEngineV4.ProcessRequest</Source><Description>Please enter the package weight.  </Description><HelpFile></HelpFile><HelpContext>1000440</HelpContext></Error></Package></RateV4Response>

my server is using php 5. Thanks for your help so far.

I have "All products in one package" radio button checked. The three checkboxes below it are grayed out.

I'll do some more debugging and share my results.

Logging each $product in function _uc_usps_package_products with my hand-dandy beefzilla_log function:

...

  if (variable_get('uc_usps_all_in_one', TRUE) && count($products) > 1) {
    beefzilla_log('start product/package debugging all in one',1);
    // "All in one" packaging strategy
    // Only need to do this if more than one product line item in order
    $packages[$last_key] = array(0 => _uc_usps_new_package());
    foreach ($products as $product) {
      beefzilla_log($product,0,'product at start of foreach');

...

both $product->length_units and $product->weight_units are not defined. That's a problem! I search on.

I'm on a shared host with PHP Version 5.2.17.

And whoops, you're right. I copied the wrong block of logging code. But there were log statements in both sides of the if/else, so the results are still valid.

I used my trusty krumo hack to debug the $form that's passed by reference into the uc_quote_form_uc_cart_checkout_form_alter function before uc_quote.module's code alters it, and this is $form['cart_contents']['#value']:

a:1:{i:0;O:8:"stdClass":14:{s:12:"cart_item_id";s:2:"14";s:7:"cart_id";s:1:"1";s:3:"nid";s:2:"13";s:3:"qty";s:1:"1";s:7:"changed";s:10:"1312411519";s:4:"data";a:2:{s:9:"shippable";s:1:"1";s:6:"module";s:10:"uc_product";}s:5:"title";s:28:"Nifty product you must buy";s:3:"vid";s:2:"13";s:4:"cost";s:7:"2.50000";s:5:"price";s:7:"7.99000";s:6:"weight";s:3:"3.3";<strong>s:12:"weight_units";s:2:"oz";</strong>s:6:"module";s:10:"uc_product";s:5:"model";s:1:"2";}}

Though serialized, you can read in there that the weight units are indeed present. A text search through the entire ubercart folder only yields one match to "uc_cart_checkout_form_alter," this one. Where else could this information be altered?

Off-topic:

I noticed that the copy address box doesn't do what the calculate shipping box does. Line 253 of uc_quote.module - @todo: Figure out what needs to be done when the copy-address box is checked.

That checkbox probably already has ajax on it, and would need another function strapped onto it. How does drupal 7 handle multiple ajax callbacks? Does it?

I made a fresh install of drupal 7.7 and all the latest ubercart dependencies on a new subdomain, and I'm still gettting this error. That tells me this is not configuration based, unless I'm totally missing something. My product does have its weight listed in the node settings.

API=RateV4&XML=<RateV4Request USERID="SECRET"><Revision>2</Revision><Package ID="0"><Service>ALL</Service><ZipOrigination>19301</ZipOrigination><ZipDestination>08817</ZipDestination><Pounds>0</Pounds><Ounces>0.0</Ounces><Container>VARIABLE</Container><Size>REGULAR</Size><Value>7.99</Value><Machinable>FALSE</Machinable><ReturnLocations>TRUE</ReturnLocations><ShipDate Option="EMSH">11-Aug-2011</ShipDate></Package></RateV4Request>

<?xml version="1.0"?>
<RateV4Response><Package ID="0"><Error><Number>-2147219500</Number><Source>DomesticRatesV4;clsRateV4.ValidateWeight;RateEngineV4.ProcessRequest</Source><Description>Please enter the package weight.  </Description><HelpFile></HelpFile><HelpContext>1000440</HelpContext></Error></Package></RateV4Response>

Did some more testing today. Findings: in ubercart/shipping/uc_usps.module function _uc_usps_package_products with only one item in the cart, the foreach ($products as $product) { loop iterates twice when clicking the "Click to calculate shipping" button. The first time through $package->weight_units is defined, the second time, it is not. I find this a little strange because at the beginning of the function, the $products array only holds one item, and that item does not have a weight_units attribute...

Here is the var_dump of the $package object after the first switch($product->weight_units) in said function, on both 1st and 2nd iterations:

object(stdClass)#8 (18) {
  ["cart_item_id"]=>
  string(1) "2"
  ["cart_id"]=>
  string(32) "d0b8a6b98ada2ad50fb86a02bb17fead"
  ["nid"]=>
  string(1) "1"
  ["qty"]=>
  string(1) "1"
  ["changed"]=>
  string(10) "1313625415"
  ["data"]=>
  array(2) {
    ["shippable"]=>
    string(1) "1"
    ["module"]=>
    string(10) "uc_product"
  }
  ["title"]=>
  string(40) "Really Cool Product Name"
  ["vid"]=>
  string(1) "1"
  ["cost"]=>
  string(7) "3.17000"
  ["price"]=>
  string(7) "7.99000"
  ["weight"]=>
  string(3) "3.3"
  ["weight_units"]=>
  string(2) "oz"
  ["module"]=>
  string(10) "uc_product"
  ["model"]=>
  string(1) "1"
  ["pkg_qty"]=>
  int(1)
  ["description"]=>
  string(1) "1"
  ["pounds"]=>
  float(0)
  ["ounces"]=>
  float(3.3)
}

object(stdClass)#93 (14) {
  ["order_product_id"]=>
  string(2) "14"
  ["order_id"]=>
  string(1) "5"
  ["nid"]=>
  string(1) "1"
  ["title"]=>
  string(40) "Really Cool Product Name"
  ["manufacturer"]=>
  string(0) ""
  ["model"]=>
  string(1) "1"
  ["qty"]=>
  string(1) "1"
  ["cost"]=>
  string(7) "3.17000"
  ["price"]=>
  string(7) "7.99000"
  ["weight"]=>
  string(3) "3.3"
  ["data"]=>
  array(2) {
    ["shippable"]=>
    string(1) "1"
    ["module"]=>
    string(10) "uc_product"
  }
  ["order_uid"]=>
  string(1) "0"
  ["pkg_qty"]=>
  int(1)
  ["description"]=>
  string(1) "1"
}

Also of note, there is a lack of defensive code up in here:

        switch ($product->weight_units) {
          case 'g':
            // Convert to kg and fall through
            $weight = $weight * G_TO_KG;
          case 'kg':
            // Convert to lb and fall through
            $weight = $weight * KG_TO_LB;
          case 'lb':
            $package->pounds = floor($weight);
            $package->ounces = LB_TO_OZ * ($weight - $package->pounds);
            break;
          case 'oz':
            $package->pounds = floor($weight * OZ_TO_LB);
            $package->ounces = $weight - $package->pounds * LB_TO_OZ;
             break;
        }

Notice the lack of a default:. Whoever coded this didn't expect there to not be a weight_units attribute, so this fails gracelessly. So there's still room for improvement after I find this bug. The default could alert the watchdog with a notice.

I finally found the problem. Committing patch shortly. :)

Hmmm... test postponed. Should I worry about this?

BTW, this has perplexed me for a while now - citing TR:
Hundreds of other users are also running USPS quotes. There have been no previous reports that they are broken entirely.

Are all these sites using drupal 7? One of my coworkers uses drupal 6 with ubercart and it works masterfully. Ubercart 7 is still buggy. I considered porting my custom theme to drupal 6, but I figured that would be a step in the wrong direction, so here I am.

-_-

If you're interested in finding this unknown factor, I suggest a fresh install of drupal 7.7 with minimal requirements to get ubercart and usps shipping quotes working. That's what I'm testing on - a site with only one node, that's a product.

Heck, I've considered opening up a subdomain of my personal development domain to the drupal developer public just to test this issue. Does that sound like a bad idea?

And why has my patch not been tested yet?

The ajax call hits uc_usps_quote twice for some reason. The first time through it does the right thing. The second time through, weight_units is not present at the product level.

The backtrace for the second call runs 14 functions deep...

pictured is the diff between the two backtraces

It reads the product's weight just fine - that attribute never changes. However at some point before the second time uc_usps_quote is called, the weight_units attribute disappears from the product.

USPS doesn't recognize a weight without accompanying weight_units, hence the problem. My task is to determine where the weight_units are lost.

Apparently it's calling twice because the form needs to be rebuilt.

I have a patch above that worked for me - http://drupal.org/files/issues/1027554_2.patch but the purists want me to track down the source of the bug and kill it, as my patch is just a "hack."

Backup the file /sites/all/modules/ubercart/shipping/uc_usps/uc_usps.module

...and replace it with the contents of this zip file. Try it out. Worked for me. Good luck! :)

thinking out loud, as usual. There's a problem with uc_order_load($order->order_id, TRUE), as that does not add the weight_units attribute along with everything else. Essentially it calls entity_load($entity_type = 'uc_order', $ids = array($order_id), $conditions = array(), $reset = TRUE)

This happens in uc_cart_pages.inc, at the bottom of function uc_cart_checkout_form_validate.

Found the problem. The solution is not a one-liner. -_-

See line 1303 of uc_order.module:

$result = db_query("SELECT * FROM {uc_order_products} WHERE order_id = :id ORDER BY order_product_id", array(':id' => $order->order_id));

That query should also fetch the weight_units for that product, because without units, a number is meaningless!

I recommend an INNER JOIN to get the product's weight and weight units. Heck the uc_order_products table shouldn't even hold fields such as weight and weight_units, as those should be held solely by the uc_products table. We're just duplicating data here. To fix this, change the query above to:

      $result = db_query(
      "SELECT o.*, p.weight_units
      FROM {uc_order_products} AS o
      INNER JOIN {uc_products} AS p
      	ON o.nid = p.nid
      WHERE order_id = :id
      ORDER BY order_product_id",
      array(':id' => $order->order_id));

Ideally, it should instead read:

      $result = db_query(
      "SELECT o.*, p.weight, p.weight_units
      FROM {uc_order_products} AS o
      INNER JOIN {uc_products} AS p
      	ON o.nid = p.nid
      WHERE order_id = :id
      ORDER BY order_product_id",
      array(':id' => $order->order_id));

If the uc_order_products table had the redundant weight field removed from it.

More testing and patch to follow (hopefully). It's nearly midnight over here.

@gmopinillosv

Ok, good to know. Thanks for giving that a try. That's why I asked you to backup the original file! :P

Hopefully i will have a better fix soon. My website needs this to work too.

OK, I uploaded another patch,

For you, @gmopinillosv, try the contents of that zip file in ubercart/uc_order/uc_order.module - please backup first! :) It works on my site, but I only do domestic shipping.

@TR and @longwave, the uc_orders table should drop the weight column.

whoops - now with unix line endings!

@gmopinillosv

I did some more testing and got the same error you did. I will continue debugging this week and keep you informed.

Testing with 3 items in the cart. 2 are the same product, 1 is a different product. Request/response to/from USPS:

API=RateV4&XML=<RateV4Request USERID="SECRET"><Revision>2</Revision><Package ID="0"><Service>ALL</Service><ZipOrigination>19301</ZipOrigination><ZipDestination>90210</ZipDestination><Pounds>0</Pounds><Ounces>0.0</Ounces><Container>VARIABLE</Container><Size>REGULAR</Size><Value>0</Value><Machinable>FALSE</Machinable><ReturnLocations>TRUE</ReturnLocations><ShipDate Option="EMSH">25-Aug-2011</ShipDate></Package></RateV4Request>

<?xml version="1.0"?>
<RateV4Response><Package ID="0"><Error><Number>-2147219500</Number><Source>DomesticRatesV4;clsRateV4.ValidateWeight;RateEngineV4.ProcessRequest</Source><Description>Please enter the package weight.  </Description><HelpFile></HelpFile><HelpContext>1000440</HelpContext></Error></Package></RateV4Response>


API=RateV4&XML=<RateV4Request USERID="SECRET"><Revision>2</Revision><Package ID="0"><Service>ALL</Service><ZipOrigination>19301</ZipOrigination><ZipDestination>90210</ZipDestination><Pounds>0</Pounds><Ounces>9.9</Ounces><Container>VARIABLE</Container><Size>REGULAR</Size><Value>23.97</Value><Machinable>TRUE</Machinable><ReturnLocations>TRUE</ReturnLocations><ShipDate Option="EMSH">25-Aug-2011</ShipDate></Package></RateV4Request>

Notice that the first package has nothing in it; the second package has all three items in it. That tells me there is something wrong with the packaging logic.

I think I discovered why this happens around line 673 of uc_usps.module:

    [0] => UcAddress Object
        (
            [first_name] => Jo
            [last_name] => Momma
            [company] => JM Inc.
            [street1] => 420 Paper St
            [street2] =>
            [city] => Wilmington
            [zone] => 69
            [country] => 840
            [postal_code] => 90210
            [phone] => 
            [email] => jm@example.com
        )

    [1] => stdClass Object
        (
            [first_name] => Jo
            [last_name] => Momma
            [company] => JM Inc.
            [street1] => 420 Paper St
            [street2] =>
            [city] => Wilmington
            [zone] => 69
            [country] => 840
            [postal_code] => 90210
            [phone] => 
        )

The two objects are not equal because one doesn't have an email address and the other does. When testing address equality that shouldn't matter. Therefore the UcAddress class should have a "equalPhysicalLocation($obj)" method that would return TRUE in this case.

also uc_quote_get_default_shipping_address($nid) spits out stdClass objects instead of UcAddress objects.

@gmopinillosv I have a fix. See the attached .zip file to backup and replace the 3 files listed in updated.txt:

shipping/uc_usps/uc_usps.module
shipping/uc_quote/uc_quote.module
uc_store/classes/address.inc

I just now posted a patch to http://drupal.org/node/405678 for the issue gmopinillosv discovered. The .zip files are only for his benefit, as he is not as tech savvy.

TR, please check my attempt at a multi-file patch there; is that the proper format?

All I can recommend is that you use my latest patches, in this bug and the referenced one, as those make it work on my site... Unless there's a new version out.

the patch above works - do I just set this issue to fixed?