Forums / Addon Payment Modules / Enabled zones for protx module, now admin fails to show order

Enabled zones for protx module, now admin fails to show order

Locked

Views: 1,407

Results 1 to 6 of 6
This thread is locked. New replies are disabled.
29 Aug 2009, 10:22 AM
#1
neekfenwick avatar

neekfenwick

New Zenner

Join Date:
Feb 2009
Posts:
101
Plugin Contributions:
0

Enabled zones for protx module, now admin fails to show order

Hi all,

I'm running zen cart 1.3.8a, and protx module 3.4.1 (according to its source).

Just wondered if this sounds sensible. I've searched the forum but can't see anything obviously related. I'm not familiar with why includes/classes/order.php is different to admin/includes/classes/order.php.

I'm supporting a site that, until the other day, has never needed any real geo zone setup. There was a single UK zone defined, but the single payment module, protx, was set to not bother with it ("Payment Zone"="None").

Having defined an EU payment zone and told protx to use the UK zone only, I am finding I cannot view orders using the admin interface. This seems to boil down to a difference between includes/classes/order.php and admin/includes/classes/order.php, the way they fill in $this->billing['country'].

When a customer places an order, the $order object has its 'cart' method called, which fills in $this->billing['country'] like this:

    $this->delivery = array('firstname' => $shipping_address->fields['entry_firstname'],
[cut]
                            'country' => array('id' => $shipping_address->fields['countries_id'], 'title' => $shipping_address->fields['countries_name'], 'iso_code_2' => $shipping_address->fields['countries_iso_code_2'], 'iso_code_3' => $shipping_address->fields['countries_iso_code_3']),

When the admin page wants to view an order, it calls the $order method 'query', which does this:

      $this->delivery = array('name' => $order->fields['delivery_name'],
[cut]
                              'country' => $order->fields['delivery_country'],

The protx module has an update_status method, only called when the protx module is configured to use a zone, that has an SQL statement like this:

			$sql = "
				SELECT
					zone_id
				FROM
					" . TABLE_ZONES_TO_GEO_ZONES . "
				WHERE
					geo_zone_id = " . $this->zone . "
				AND
					zone_country_id = " . $order->billing['country']['id'] . "
				ORDER BY
					zone_id
				";

When the admin page tries to retrieve an order, the use of $order->billing['country']['id'] in the protx module results in the value "U" when the $order->billing['country'] field is "United Kingdom" (fetched from the 'orders' table). This leads to an SQL error such as:

1054 Unknown column 'U' in 'where clause'
in:
[ SELECT zone_id FROM zen_zones_to_geo_zones WHERE geo_zone_id = 2 AND zone_country_id = U ORDER BY zone_id ]

So there seem to be two options.

1/ Would you advise I leave the two order.php classes alone, despite their differences, and fix the protx code to handle the two possible values of $order->billing['country']? i.e. assume this is a bug in the protx module.

2/ Or, should I 'fix' one of the order.php classes so $order->billing['country'] is defined the same by each, and deal with the likely chaos that would ensue throughout the rest of the zen cart codebase?

Inherent in these questions is the question of whether the 'client' code (includes/classes) is really supposed to be generating different data structures to the 'admin' code (admin/includes/classes). :unsure:

Thanks :)
Nick

31 Aug 2009, 2:47 AM
#2
neekfenwick avatar

neekfenwick

New Zenner

Join Date:
Feb 2009
Posts:
101
Plugin Contributions:
0

Re: Enabled zones for protx module, now admin fails to show order

Whoops, I seem to have pasted the $this->delivery sections from the order.php files.. the $this->billing sections are the same. I've ended up hacking the protx code, of course. It struck me that I'm probably using a pretty old version of protx (it's just what was installed when I took over maintenance of this site), which seems to have been re-branded. As it's essentially a protx module incompatibility, you Zen Cart folk might feel support rests with the protx people.

31 Aug 2009, 10:33 AM
#3
nixak avatar

nixak

Zen Follower

Join Date:
Nov 2007
Location:
Essex, UK
Posts:
137
Plugin Contributions:
1

Re: Enabled zones for protx module, now admin fails to show order

The protx module you are using, is it protx form, direct or server?

1 Sep 2009, 5:43 AM
#4
neekfenwick avatar

neekfenwick

New Zenner

Join Date:
Feb 2009
Posts:
101
Plugin Contributions:
0

Re: Enabled zones for protx module, now admin fails to show order

Direct. It's includes/modules/payment/protx_direct.php, with this version string line:

define('MODULE_PAYMENT_PROTX_DIRECT_VERSION_NO', '3.4.1');
4 Sep 2009, 10:45 AM
#5
nixak avatar

nixak

Zen Follower

Join Date:
Nov 2007
Location:
Essex, UK
Posts:
137
Plugin Contributions:
1

Re: Enabled zones for protx module, now admin fails to show order

Hi, I have compared the coding you quoted below to other payment module coding and I think that it's old and out of date, although i'm no expert lol.

neekfenwick:

		$sql = "
			SELECT
				zone_id
			FROM
				" . TABLE_ZONES_TO_GEO_ZONES . "
			WHERE
				geo_zone_id = " . $this->zone . "
			AND
				zone_country_id = " . $order->billing['country']['id'] . "
			ORDER BY
				zone_id
			";

I don't know where you got the payment module from but you could try contacting the person who wrote that module.
4 Sep 2009, 11:01 AM
#6
neekfenwick avatar

neekfenwick

New Zenner

Join Date:
Feb 2009
Posts:
101
Plugin Contributions:
0

Re: Enabled zones for protx module, now admin fails to show order

Hi Nixak,

Yes, I agree. I was already pretty sure that the protx module I'm using is quite out of date. I'm still curious as to why the two Zen Cart order.php implementation set up their internal data differently. It seems a perfect example of how loosely typed systems breed bad habits, where you can have two classes identically named setting up almost identical data with a few crucial differences that trip up client code when used in the two situations (i.e. a user gets an includes/classes/order.php instance, an admin gets an admin/includes/classes/order.php object, and the poor protx code shouldn't have to be coded to cope with either).

However, like most of us, I'm a busy developer, and I haven't had time to have a good look at why, especially as the protx module is so out of date. The guy who owns the site I'm working on doesn't want anything touched if it's already working, so I'm not going to upgrade the protx module without a better reason than this one :)

Thanks
Nick