Shipping mods based on flat rate

Someone had written a shipping mod based on the flat rate module for Australia Post rates. After making template changes to the site, the customer reported that the shipping was no longer working correctly. There's a choice between post and express post and no matter what you chose on checkout shipping, the first of the 2 choices showed up on the payment page.

Looking at the mod, I thought that there was no way it ever worked before due to way the array or lack of array was written. I opted to write another module separating out the 2 choices. The flat module has the international shipping, domestic flat rate and book rate. The express module has only the express rate.

Went back and checked out and the same - but different - thing is still happening. Only the flat rate gets put in to the payment page where as before only the first rate got put in.

Any other module besides these two that is chosen works. I've looked at the two modules and checked the database for extra shipping configurations that shouldn't be there. But I can't see why this would be happening.

I've written new flat rate modules before so I'm not clueless but I'm definitely not seeing the problem.

The only difficulty I'm looking at is the zone. The flat domestic has an if statement for if international as follows and I'm wondering if this has anything to do with the problem. There's a dated comment where someone might have made a change last December that created this - maybe not.

 
if ( ($this->enabled == true) && ((int)MODULE_SHIPPING_FLAT_ZONE > 0) ) {
        $check_flag = false;
        $check = $db->Execute("select zone_id from " . TABLE_ZONES_TO_GEO_ZONES . " where geo_zone_id = '" . MODULE_SHIPPING_FLAT_ZONE . "' and zone_country_id = '" . $order->delivery['country']['id'] . "' order by zone_id");
        while (!$check->EOF) {
          if ($check->fields['zone_id'] < 1) {
            $check_flag = true;
            break;
          } elseif ($check->fields['zone_id'] == $order->delivery['zone_id']) {
            $check_flag = true;
            break;
          }
          $check->MoveNext();
        }

        if ($check_flag == false) {	//this order is international shipping
			// $this->enabled = false;
			
			$this->is_international = true;
			$this->enabled = false;	//12/18/2009, 17:52:43  by Hao to disable flat shipping when international is on
        }

You may not need to re-write anything...

If it was a TEMPLATE change, then you just need to go into the OLD template folders and make copies of modules that were used under that template, and put them (the relevant files) into the new template folders.

With SHIPPING, there are commonly TWO php files (usually with the same NAME). One file will be in the MODULES section. The other will be a LANGUAGE file in the LANGUAGE section.

(By "section" I mean folder/directory tree)

I doubt very seriously that the template changes could have done this. I'm not a newbie at this to put it mildly. My belief at this point is that this has not worked possibly ever or at least since the change was made in December. Too few people choose the express option to have it come up very often.

We're using the same modules / overrides as before. The only changes would be in the templates/domain/templates folder. My changes were made after someone tried to change the theme with very poor success in January. I don't know what the original theme was that did work. I did check the files to make sure that the form input fields are being named properly, etc.

I see the issue... The buffoon called Hao has introduced a conditional that is better governed by standard settings in the database zone definitions functionality. (Typical error made by someone with adequate PHP knowledge, but no understanding of how ZC works!)

You may be better of starting from scratch and configuring the modules according to standard protocol.

I would start by looking at the zones and zone definitions in the database. Make sure these are relevant to the intended shipping methods, then REMOVE old shipping modules and install new ones. (This will involve overwriting/disabling the duffy "Hao" files).

Thanks so much for the confirmation. Not hard to separate out the international shipping from all that!

I'm puzzled... how can the FLAT RATE module be configured for AusPost - where there are a considerable array of variables?

Have you looked at Rod_G's ozpost module?
http://www.zen-cart.com/index.php?main_page=product_contrib_info&cPath=40_51&products_id=1286

I would seriously start the "fix" from scratch...

Only worry is... what else did "Hao" mess up when he/she tried to adjust that conditional?

Yeah, they just want to charge flat rates for their shipping - the products are books and nothing else. I told them about the other options and they said it didn't for them.

You are not going to believe this but breaking up the module didn't fix the problem!

The FEC checkout mod is installed but I've not heard of any problems with that.

So the zone australian shipping has 2 choices, either flat or express shipping and from shipping to checkout_payment, that choice gets dropped and only the flat rate shows up - the express won't no matter what order the choices are.

Checking in the database, I've made a strange discovery. If I search the config table for shipping, the MODULE_SHIPPING_AUSTRALIA_EXPRESS_POST_COST does not show up in the results. Search by australia and it does. That makes no sense! All the other shipping results show up. What in the world could cause that?

I put that exact phrase into another database and the search finds it. Any guesses?

So it's only about 2 choices in the same zone. Not often done - most of the time when there are choices, it's for everybody with maybe the exception of international. I don't believe I've actually run into this type of choice before. Surely it should just work.

Delia... you have my sympathies...

When standard behaviour starts to go awry, you can be sure some geek has taken a jack-hammer to the underlying code in an effort to force behaviour that is normally a simple config in the shop admin.

What happens is that the geek edits a crucial line of code, and then sees that the behaviour is also influenced by other files, so he goes into those and edits them.

This process is akin to Hercules and the Lernaean Hydra (cut off one head and two new ones grow in its place), so the more files being hacked, the more need to be hacked.

I wish I could offer a simple solution, but can't ... other than to say "good luck".
*
(These geeks seldom offer an audit trail of changes. I once had a situation where upwards of 60 core files had been changed - just to add "additional images" behaviour - a setting that is turned on and off by one simple click in the admin panel. It cost the site owner nearly a grand to have me sort it out!)*

That sounds so familiar! I've seen many a horror tale. Just yesterday a new customer asked me if his googleanalyics code was working. Found his footer wasn't loading. Not surprisingly no new template had been installed and there are files all over the place. Unfortunately, this owner has less understanding of any of these processes than any I've ever had. He didn't understand my protest of allowing ftp access to SEO "pros". He may yet finance my next vacation no matter how hard I try to help him!