Assign maximum order weight for UPS

I need to hide UPS in the checkout whenever total order weight exceeds 800 pounds. (I already have customized shipping modules already in place for orders whose total weight exceeds 800, but are hidden when total weight < 800.)

So before I start hacking, I thought I'd ask if anyone else has already customized their UPS module in similar fashion. If it works with ZC 1.3.7 and the price isn't too steep, I would probably purchase the file modifications.

The url is ShedKitStore.com, for those who want to see what I'm talking about. It's a working store, so if you test the shipping methods, please include the word TEST in your name when setting up a customer account.

Thanks,
Sean

I've been trying all afternoon to hardwire a conditional statement into ups.php that will trigger the UPS-can't-quote-shipping error if $shipping_weight >= 800 -- but so far no luck.

Can anyone familiar with the UPS module tell me which line you would modify?

Sean

I haven't given up yet. In my latest attempt (doesn't work; can anyone tell me why?) I replaced

PHP Code:

---

 if ($this->tax_class > 0)  {
        $this->quotes['tax'] = zen_get_tax_rate($this->tax_class, $order->delivery['country']['id'], $order->delivery['zone_id']);
      }
    } else {
      $this->quotes = array('module' => $this->title,
                            'error' => 'UPS cannot quote a shipping cost for this order. Choose another shipping method, or contact the ShedKitStore if no other shipping method is displayed.');
    } 


---

with this:

PHP Code:

---

      if ($ups_shipping_weight >= 800)  {
      $this->quotes = array('module' => $this->title,
                            'error' => 'UPS cannot quote a shipping cost for this order. Choose another shipping method, or contact the ShedKitStore if no other shipping method is displayed.');
    }
      
      elseif ($this->tax_class > 0)  {
        $this->quotes['tax'] = zen_get_tax_rate($this->tax_class, $order->delivery['country']['id'], $order->delivery['zone_id']);
      }
    } else {
      $this->quotes = array('module' => $this->title,
                            'error' => 'UPS cannot quote a shipping cost for this order. Choose another shipping method, or contact the ShedKitStore if no other shipping method is displayed.');
    } 


---

Yet another failed attempt. Replaced

PHP Code:

---

    if (empty($returnval)) $returnval = $errorret;

    return $returnval; 


---

with

PHP Code:

---

    if ( (empty($returnval)) || ($shipping_weight >= 800) ) $returnval = $errorret;

    return $returnval; 


---

I can't afford to waste any more time on this. Does anyone have a clue what I'm missing?

A little desperate,
Sean :lookaroun

This is not the most elquent method ... and should be fully tested ...

Find line 185:

PHP Code:

---

      $this->quotes['methods'] = $methods; 


---

Replace with:

PHP Code:

---

    if ($ups_shipping_weight >= 800) {
    // no ups
    } else {
      $this->quotes['methods'] = $methods;
    } 


---

Thanks Linda. Doesn't work yet though. I still have a UPS quote when total order weight is over 800 lbs. Is $ups_shipping_weight the combined weight of the order (all packages) or just one package?

I have maximum package weight set at 70 lbs in Admin/Shipping -- dunno if that's relevant or not.

Quote:

---

Originally Posted by Ajeh

This is not the most elquent method ... and should be fully tested ...

Find line 185:

PHP Code:

---

      $this->quotes['methods'] = $methods; 


---

Replace with:

PHP Code:

---

    if ($ups_shipping_weight >= 800) {
    // no ups
    } else {
      $this->quotes['methods'] = $methods;
    } 


---

---

I just triple-checked to make sure the modified file is in place and the modification at 185 is the only deviation from the original. I really need to get better acquainted with PHP so I can answer a few of these questions for myself.

Is it possible there is something missing in the first half of that replacement code?

Sean <--( clueless )

Fussy fussy fussy ... :rolleyes:

Add a blank Line a line 90 and put in this code instead:

PHP Code:

---

    if (IS_ADMIN_FLAG === false && $_SESSION['cart']->weight > 800) $this->enabled = false; 


---

Thanks Linda -- before I post, did you mean IS_ADMIN_FLAG === false or IS_ADMIN_FLAG == false? I'll assume it's the latter & try == first -- I'll post a reply in a few minutes.

Sean

I really mean what I wrote ... :cool:

Brava! Your insertion at 90 worked like a charm, Linda. And for the record, I went with

PHP Code:

---

if (IS_ADMIN_FLAG == false && $_SESSION['cart']->weight > 800) $this->enabled = false; 


---

Time for me to drop a few dollars in the donation box! :yes:

It is important for safety to use the triple equal sign ...

Thanks! appreciate the support!

Thanks for clarifying that, Linda. I changed the == back to your original === and added the triple-equals to my "how do comparison operators work" list. :P

G'nite! :sleepy:

Quote:

---

Originally Posted by Ajeh

It is important for safety to use the triple equal sign ...

Thanks! appreciate the support!

---

With a slightly-modified ups.php (disabled when order >=800 lbs) and a cloned freeoptions module ("flatoptions" -- flat rate conditioned on order >=800 lbs and shipping address in contiguous U.S.), I am experiencing a checkout glitch where a customer can apply a coupon and have the cost of UPS shipping deducted unintentionally. Don't worry -- I'm convinced this is unique to my Zen-Cart, and I just need to track down my own mistake; this is not something you'll find in standard Zen-Cart 1.3.7 installations.

The explanation is tedious, so please bear with me.

A customer has a coupon code -- if you want to test it, try coupon code ZCZCZC. (I created this coupon code for community testing; it's only $5 off, but it illustrates my problem to anyone who feels like testing it.) Customer puts an allowed-for-coupon product (e.g. shed kit) in the cart and goes to checkout. Customer selects shipping method, e.g. free options AKA pickup at terminal. Customer enters redemption code when prompted, and the success text is displayed. Customer continues shopping and adds product that is denied-for-coupon to cart. Customer then removes allowed-for-coupon product from cart, leaving product that is denied-for-coupon. Customer goes back to checkout and selects new shipping method (e.g. UPS). Are you still with me?

The resulting order total credits the customer on the coupon redemption in the exact amount of the UPS shipping, up to the face value of the coupon, making UPS shipping unintentionally free whenever the coupon's face value >= the shipping fee.

I tried switching to the Classic template to see if the problem is template-related, but I get

Quote:

---

Fatal error: Call to a member function on a non-object in ... /shedkitstore.com/includes/classes/category_tree.php on line 135

---

when trying to checkout -- perhaps an overridden file or two eliminating the Classic option.

Something tells me I'll be working on this one all weekend ... :huh:

Definitely bad, missing, out of date or corrupt files on the server ...

Beyond Compare from scootersoftware.com is your friend ... :smile:

You can use this to do nice FTP compares of files and directories or things like the default files and templates to your template and overrides etc. to see where things are out of date ...

I have had Dreamweaver botch the synchronization of remote and local files too often. I'll try Beyond Compare and let you know what happens.

Thanks for the suggestion. :smile:

Quote:

---

Originally Posted by Ajeh

Definitely bad, missing, out of date or corrupt files on the server ...

Beyond Compare from scootersoftware.com is your friend ... :smile:

You can use this to do nice FTP compares of files and directories or things like the default files and templates to your template and overrides etc. to see where things are out of date ...

---

After 10 hours conforming my files to Zen-Cart 1.3.7 core, I know now that I have no missing or corrupted files. But I don't know why a non-allowed discount coupon remains in force after the coupon-allowed product is removed from the cart.

I'm back to wondering whether any of my shipping module customizations would influence the discount coupon behavior in the order total ... :blink:

Is that possible?

What are your restrictions settings?

Do you have Category Top deny turned on?

This forces a proper test on other Categories and Products when there are limitations ...

I didn't have Category Top deny at first, so I tried just now -- no change.

Original restrictions are Category 20 allow and Category 74 allow. That's it.

FYI, I tested this with identical restrictions on another 1.3.7 site (standard shipping modules) and it worked properly -- that is, discount coupon redemption went away when allowed category product was removed from the cart.

Quote:

---

Originally Posted by Ajeh

What are your restrictions settings?

Do you have Category Top deny turned on?

This forces a proper test on other Categories and Products when there are limitations ...

---

Beyond Compare rocks, by the way. Does the job of two aps, and twice as well.

There is something a bit strange here ...

When you remove the Product from the cart that allowed the Discount Coupon ...

1 How many Products and what Quantity are in the cart?

2 What does the Discount read in the checkout_payment page?

1. A. Starting from an empty cart, add any product from C-20 or C-74 to cart -- for example, a Riviera shed kit.
1. B. Add products from C-65 to cart -- for example, 7 windows.
1. C. Go to checkout and redeem discount coupon.
1. D. Redemption code appears in order total on confirmation page.
1. E. Go to shopping cart and remove all products except C-65 (non-allowed) product(s).
1. F. Go to checkout, pick UPS shipping (only method available) and proceed to payment page.
2. Discount on checkout_payment page remains, e.g. "Redemption code: ZCZCZC : -$5.00"

Also, it just dawned on me that category 65 is a different product type than 20 and 74. The comparison I ran using the other 1.3.7 ZC utilized only one product type, not 2 as in the case of ShedKitStore.com. Could this matter?

Quote:

---

Originally Posted by Ajeh

There is something a bit strange here ...

When you remove the Product from the cart that allowed the Discount Coupon ...

1 How many Products and what Quantity are in the cart?

2 What does the Discount read in the checkout_payment page?

---

Note that this example is just a $5 coupon. If you try it with a $400 coupon, the discount is exactly equal to the amount of the shipping. (If UPS shipping = $78.39, discount = -$78.39.)

I am looking into this ...

Meanwhile you still appear to have issues on the address book ...

If I go to edit my account I have to reselect my state ...

I am not sure if this is a template or code issue on there ... but one of the two is not correct ...

I thought the address book issues stemmed from something getting imported wrong when I migrated the database a few months ago. Had you created a new user account recently, or is it possible the customer or address book data was fuzzy?

Quote:

---

Originally Posted by Ajeh

I am looking into this ...

Meanwhile you still appear to have issues on the address book ...

If I go to edit my account I have to reselect my state ...

I am not sure if this is a template or code issue on there ... but one of the two is not correct ...

---

Sorry -- dumb question on my part. I looked at your customer data & I see you were ported in during the migration. Let me check the address book and customers tables.

I could very well be missing the data but it should of fixed it when I edited ... and either it is not holding my state data or the code/template is not filling it in right when I edit ...

Check the address_book for the fields:
entry_country_id 223
entry_zone_id 47

I have both 223 for your entry_country_id and 47 for your entry_zone_id, but the state field is blank for all customers. Probably has to do with a modification I made to the state portion of the account forms. At the time, there was a grey input appearing with the state select dropdown, hence the modifications -- but I may have botched the way state values get to the address book in the process.

I won't torture either of us with any more of this tonight -- my brain is turning into a pumpkin and I'm going to bed before I break anything else. :sleepy:

Thanks for helping me get closer to functional, Linda. You rock!

Quote:

---

Originally Posted by Ajeh

Check the address_book for the fields:
entry_country_id 223
entry_zone_id 47

---

The entry_state is only needed sometimes ... not always ...

The problem is the edit address is not listening to the setting so it is not selecting ...

This means either missing files or old files or template issue ...

Does a switch to Classic fix the edit?

Thanks Linda --

I tested using Classic template on a less productive site with similar address book files in its custom template. On that one, adding a new address in My Account with custom template gave

Quote:

---

Warning: Cannot modify header information - headers already sent by (output started at /home/jjh/public_html/includes/languages/english/hd/address_book_process.php:75) in /home/jjh/public_html/includes/functions/functions_general.php on line 44

---

. I then switched to Classic template, hit the back button on the catalog page and the new address was entered successfully. No data in the address book State field, but entry_zone_id and entry_country_id are correct.

I'll take another look at my template's account files versus template_default in Beyond Compare right now.

Quote:

---

Originally Posted by Ajeh

The entry_state is only needed sometimes ... not always ...

The problem is the edit address is not listening to the setting so it is not selecting ...

This means either missing files or old files or template issue ...

Does a switch to Classic fix the edit?

---

After conforming all of those HardwareDog.com custom template files to match the template_default code, I then tried the address book again -- and again I got

Quote:

---

Warning: Cannot modify header information - headers already sent by (output started at /home/jjh/public_html/includes/languages/english/hd/address_book_process.php:75) in /home/jjh/public_html/includes/functions/functions_general.php on line 44

---

-- and when backed up one page, the new address was entered. Apparently the error I got was not affected by the changes I made, and all it took to get the address into the database was backing up.

So I tried it again, a little different this time -- switched to Classic template, THEN went to address book and added a new address. Two things worth noting:

1. The ghost state input noted earlier wasn't there, unlike my custom template without the modified account files.
2. The address addition went through just fine.

Knowing this, I'm looking at the modules now to see which file(s) overriding the default are blowing my address book.

Edit the language file and remove all the space(s) and blank line(s) at the end of the file that are immediately to the right of the php closing tag:
?>

Looks like the file is also double spaced or you have a heck of a lot of text in there ... mine is 38 lines long ... :cool:

Thanks! That fixed the language file problem. And I finally figured out the reason for the ghost input in the address book forms. My custom stylesheet was missing

Code:

---

.hiddenField {
        display: none;
}

---

The modifications that were breaking my states weren't necessary at all. As soon as I added the hiddenField style, the ghost input stopped haunting me.

Now back to the screwy checkout issue with denied discount coupons negating my shipping fees. ...

Quote:

---

Originally Posted by Ajeh

Edit the language file and remove all the space(s) and blank line(s) at the end of the file that are immediately to the right of the php closing tag:
?>

Looks like the file is also double spaced or you have a heck of a lot of text in there ... mine is 38 lines long ... :cool:

---

Still chasing down my bug in which checkout fails to remove discount coupon when allowed products are removed from cart after redemption code is accepted.

The bug manifests regardless whether allowed and denied products are different product types -- I tested for this just now.

It only happens when the shipping fee > 0. When free options shipping is selected, the discount is removed. Switch back to paid shipping, and the discount returns.

See for yourselves at ShedKitStore.com. I created a new coupon with redemption code EST5OFF ... it's for $5 off Estate shed kit. Add Estate to cart, then add a different shed kit to cart. (All shed kits are the same product type.) Go to checkout, redeem the EST5OFF code, then return to the cart and remove the Estate. Go back to checkout, select home delivery for $125, and proceed to billing page. Note the $5 discount is still applied in the order total, even though Top category is denied in the coupon's restrictions and only the Estate is allowed.

If anyone needs to create a new user account, please include the word TEST in the name.

Sean

As I stated before ... we are looking into this as this appears to be our bug not necessarily your's ...

Check your current settings before trying this ...

What happens if on the Modules ... Order Totals ... Discount Coupons ot_coupon ... if you edit that and set everything to:

Quote:

---

This module is installed
true

Sort Order
280

Include Shipping
false

Include Tax
false

Re-calculate Tax
Standard

Tax Class
--none--

---

Fascinating -- and a little troubling.

1. I changed ShedKitStore ot_coupon as suggested, and that fixed it! :happy:
2. Further, I changed HardwareDog ot_coupon settings, which originally had Include Shipping set to false. After I changed it to true, I finally reproduced the problem in another Zen-Cart.

I guess this means ot_coupon is a bit vulnerable in that customers who do a post-redemption cart revision can apply coupons toward shipping denied products, contrary to store owners' intent. :shocking:

THANK YOU, Linda, for greatly accelerating the solution to my problem. In the process, you have also discovered information that may help others prevent shipping mishaps due to an obscure Achilles' heel.

Quote:

---

Originally Posted by Ajeh

Check your current settings before trying this ...

What happens if on the Modules ... Order Totals ... Discount Coupons ot_coupon ... if you edit that and set everything to:

---

NOTE: a Discount Coupon is for 1 of the following 3 things and you cannot combine them together:

1 Discount Amount

2 Discount Percentage

3 Free Shipping

You cannot combine Free Shipping with the discounts at this time ...

Just pointing out that any customer can cheat their way out of paying for shipping on item(s) whose discount (amount) coupon status is Deny -- providing the ot_coupon Include Shipping = true (in Modules/Order Total).

Or are mine the only sites with this vulnerability?

Quote:

---

Originally Posted by Ajeh

NOTE: a Discount Coupon is for 1 of the following 3 things and you cannot combine them together:

1 Discount Amount

2 Discount Percentage

3 Free Shipping

You cannot combine Free Shipping with the discounts at this time ...

---

there is some issue here on this setting we are looking into it ... thanks ... :smile: