Results 1 to 6 of 6
  1. #1
    Join Date
    Feb 2009
    Posts
    88
    Plugin Contributions
    1

    Default 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:

    PHP Code:
        $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:

    PHP Code:
          $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:

    PHP Code:
                $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:

    Code:
    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).

    Thanks :)
    Nick

  2. #2
    Join Date
    Feb 2009
    Posts
    88
    Plugin Contributions
    1

    Default 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.

  3. #3
    Join Date
    Nov 2007
    Location
    Essex, UK
    Posts
    137
    Plugin Contributions
    1

    Default 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?

  4. #4
    Join Date
    Feb 2009
    Posts
    88
    Plugin Contributions
    1

    Default 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:
    Code:
    define('MODULE_PAYMENT_PROTX_DIRECT_VERSION_NO', '3.4.1');

  5. #5
    Join Date
    Nov 2007
    Location
    Essex, UK
    Posts
    137
    Plugin Contributions
    1

    Default 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.

    Quote Originally Posted by neekfenwick View Post
    PHP Code:
                $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.

  6. #6
    Join Date
    Feb 2009
    Posts
    88
    Plugin Contributions
    1

    Default 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

 

 

Similar Threads

  1. v153 Install Fails without mysqli enabled
    By dbltoe in forum Installing on a Linux/Unix Server
    Replies: 10
    Last Post: 14 Jul 2014, 11:01 PM
  2. Replies: 1
    Last Post: 20 Jun 2011, 05:34 PM
  3. Enabled SSL now store doesn't show
    By rfresh in forum General Questions
    Replies: 16
    Last Post: 12 Jan 2009, 05:45 AM
  4. Zones module: Can I create shipping zones for different states?
    By Lisa in Vermont in forum Built-in Shipping and Payment Modules
    Replies: 6
    Last Post: 31 Dec 2008, 06:35 AM
  5. SQL error when using Protx module and zones
    By ECM in forum Addon Payment Modules
    Replies: 5
    Last Post: 30 Mar 2008, 10:08 AM

Bookmarks

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •  
disjunctive-egg
Zen-Cart, Internet Selling Services, Klamath Falls, OR