Edit Orders v4.0 Support Thread

Well that was easy! Comment out one line in includes/modules/order_total/ot_onetime_discount.php. Enter a negative number for an after-tax discount; enter a positive number for an after-tax cost increase. Line 91 in EO v4.3.1 (shown below).

// if($discount > 0) $discount = $discount * -1;  edit to allow after-tax discount (-) or cost increase (+) 

Text can be changed by overriding the file: includes/languages/english/modules/order_total/ot_onetime_discount.php

Do you see any problems with this change?

Dave

Dave, looks good. I'll consider perhaps an order-total customization switch (when it's enabled) to let store owners control what the onetime-discount does.

Thanks for the updates.

Update: GitHub issue created to track the change-request: https://github.com/lat9/edit_orders/issues/65

I'm now integrating the admin_new_order add-on with EO 4.3.1 and zc 155e. The add-on requires and uses EO. Attempting to add a new order from admin fails in a call to EO function eoOrderIsVirtual with a null $eo at edit_order_functions.php line 293. The full backtrace follows (edited to remove the beginning portion of paths):

[31-Jan-2018 16:25:36 America/New_York] PHP Fatal error: Call to a member function eoOrderIsVirtual() on null in admin/includes/functions/extra_functions/edit_orders_functions.php on line 293
[31-Jan-2018 16:25:36 America/New_York] PHP Stack trace:
[31-Jan-2018 16:25:36 America/New_York] PHP 1. {main}() .../admin/new_order.php:0
[31-Jan-2018 16:25:36 America/New_York] PHP 2. order_total->process() .../admin/new_order.php:252
[31-Jan-2018 16:25:36 America/New_York] PHP 3. ot_tax->process() .../includes/classes/order_total.php:68
[31-Jan-2018 16:25:36 America/New_York] PHP 4. zen_get_tax_locations() .../includes/modules/order_total/ot_tax.php:31

A post in the admin_new_order support forum mentioned that the add-on works if the code that creates the order totals, including line 252 in new_order.php, is removed, the add-on appears to work. I'm not sure removing the code is the best approach. It seems to me that $eo needs to be established somewhere, but where? Perhaps in function zen_get_tax_locations in edit_orders_functions.php? Or in new_order.php? Should $eo be set to a new editOrders object?

Also, are there other things that should be done if EO is entered through the order_totals path rather than at the beginning of edit_orders.php?

Thanks for any assistance you can provide.

Dave

Since the function zen_get_tax_locations doesn't normally exist on the admin side, EO creates its copy of those functions for its order-total processing to function ... and those EO-centric functions thus presume that the $eo class is loaded.

Let me ponder for a bit as to the best approach to handle this use-case.

lat9:

Since the function zen_get_tax_locations doesn't normally exist on the admin side, EO creates its copy of those functions for its order-total processing to function ... and those EO-centric functions thus presume that the $eo class is loaded.

Let me ponder for a bit as to the best approach to handle this use-case.
Ah, coffee! Here's what I'll be using to update Edit Orders to correct this integration issue, adding the highlighted code-fragment:

<?php
//
// +----------------------------------------------------------------------+
// |zen-cart Open Source E-commerce                                       |
// +----------------------------------------------------------------------+
// |                                                                      |
// | http://www.zen-cart.com/index.php                                    |
// +----------------------------------------------------------------------+
// | This source file is subject to version 2.0 of the GPL license,       |
// | that is bundled with this package in the file LICENSE, and is        |
// | available through the world-wide-web at the following url:           |
// | http://www.zen-cart.com/license/2_0.txt.                             |
// | If you did not receive a copy of the zen-cart license and are unable |
// | to obtain it through the world-wide-web, please send a note to       |
// | [email protected] so we can mail you a copy immediately.          |
// +----------------------------------------------------------------------+

[B]// -----
// Since other plugins (like "Admin New Order") also provide some of these functions,
// continue this function-file "load" only if the current page-load is on
// behalf of "Edit Orders" processing.
//
if (basename($PHP_SELF) != FILENAME_EDIT_ORDERS) {
    return;
}[/B]

// Include various Zen Cart functions (with any necessary changes for admin)
if(!function_exists('zen_get_country_id')) {

That will cause the remainder of that function-file to load only when on behalf of an Edit Orders request.

Well that didn't work. Order_total still wants to get to zen_get_tax_locations function. I'll need to see how this worked in zc 151. The function must have existed in admin then, maybe in EO 4.0.

In zc 151, the zen_get_tax_locations function is on the store side. Have there been any changes since v151 that prohibit admin from accessing functions on the store side? Looks like the (v151???) store-side version of these functions will need to be loaded if called from non-EO requests??? I'm tempted to establish $eo before call to order_total and see what happens. Ugh!!!

Dave224:

In zc 151, the zen_get_tax_locations function is on the store side. Have there been any changes since v151 that prohibit admin from accessing functions on the store side? Looks like the (v151???) store-side version of these functions will need to be loaded if called from non-EO requests??? I'm tempted to establish $eo before call to order_total and see what happens. Ugh!!!
zen_get_tax_locations has *never *been available in an as-distributed Zen Cart installation. I'm not familiar with the "Admin New Order" plugin, so I don't know how it did its magic.

Hi lat9,

The Admin New Order plugin creates database entries for the order, orders_totals, and orders_status_history tables with an order that contains no products, and then redirects to edit_orders. I believe it does this since edit_orders does (or did) expect these tables to exist and uses them in editting orders created on the store_side.

As noted in earlier posts, new_order.php while creating the order totals, calls function zen_get_tax_locations. I believe that the author of the Admin New Order plugin intended that the store-side version of the function be used, but that version is not loaded in the admin. Your version of the function won't work because $eo has not been created. And even if the store-side version were loaded, edit_orders would fail because it tests for an existing loaded version of the function, and if found, exits with an error message.

so the only way I could figure to get the store-side version of the function loaded is to merge it into your version of the function, like so:

if (function_exists ('zen_get_tax_locations')) {
    trigger_error ('Pre-existing zen_get_tax_locations function detected.', E_USER_ERROR);
    exit ();
} else {
    function zen_get_tax_locations($store_country = -1, $store_zone = -1) {
         if (basename($PHP_SELF) == FILENAME_EDIT_ORDERS) {
              ....contents of your version of the function
         } else {
              ....contents of the store-side version of the function
         }
    }
}

I did not include the protective code you posted earlier that prevents loading functions if called from other plugins. But, although the orders_total table was created without error in new_order.php, edit_orders.php didn't fare as well. Tax calculations were applied when they shouldn't, probably because I did something wrong in the merge. I think it should work, but I'm giving up on this approach.

Anyway, I'm back to commenting out the code in new_order.php that creates the orders_totals table. Edit orders appears to work. But I would really appreciate your opinion of any ramifications to EO if called without an orders_totals table in the database.

Thanks,

Dave

Dave224:

Hi lat9,

The Admin New Order plugin creates database entries for the order, orders_totals, and orders_status_history tables with an order that contains no products, and then redirects to edit_orders. I believe it does this since edit_orders does (or did) expect these tables to exist and uses them in editting orders created on the store_side.

As noted in earlier posts, new_order.php while creating the order totals, calls function zen_get_tax_locations. I believe that the author of the Admin New Order plugin intended that the store-side version of the function be used, but that version is not loaded in the admin. Your version of the function won't work because $eo has not been created. And even if the store-side version were loaded, edit_orders would fail because it tests for an existing loaded version of the function, and if found, exits with an error message.

so the only way I could figure to get the store-side version of the function loaded is to merge it into your version of the function, like so:

if (function_exists ('zen_get_tax_locations')) {
trigger_error ('Pre-existing zen_get_tax_locations function detected.', E_USER_ERROR);
exit ();
} else {
function zen_get_tax_locations($store_country = -1, $store_zone = -1) {
if (basename($PHP_SELF) == FILENAME_EDIT_ORDERS) {
....contents of your version of the function
} else {
....contents of the store-side version of the function
}
}
}

> I did not include the protective code you posted earlier that prevents loading functions if called from other plugins. But, although the orders_total table was created without error in new_order.php, edit_orders.php didn't fare as well. Tax calculations were applied when they shouldn't, probably because I did something wrong in the merge. I think it should work, but I'm giving up on this approach.
> 
> Anyway, I'm back to commenting out the code in new_order.php that creates the orders_totals table. Edit orders appears to work. But I would really appreciate your opinion of any ramifications to EO if called without an orders_totals table in the database.
> 
> Thanks,
> 
> Dave
Dave, we're getting a tad off-topic here ... but, without those order-totals, neither EO nor the built-in Customers->Orders (or, for that fact, the storefront account_history_info page's) processing is going to display the order's details correctly.

FWIW, the author of the Admin New Order plugin was the previous author of EO ... so it doesn't surprise me that the handling is similar.

Sorry, let me clarify... I meant: "But I would really appreciate your opinion of any ramifications to EO if called from new_order.php without an orders_totals table entry in the database for the new order." I didn't mean to imply the table was not present.
Dave

Dave224:

Sorry, let me clarify... I meant: "But I would really appreciate your opinion of any ramifications to EO if called from new_order.php without an orders_totals table entry in the database for the new order." I didn't mean to imply the table was not present.
Dave
Dave, EO's going to *assume *that, at a minimum, there's a sub_total and total entry (as there would be for an untaxed "virtual" product). It would take me a couple of hours to model and see with my own eyes what path EO will take if they're absent.

hey, i'm a little late to this party. and frankly i stay away from this necessary evil known as edit_orders; however i want to point something out that i saw here.

in the post a few above, this code will NOT do what i think was intended:

if (basename($PHP_SELF) != FILENAME_EDIT_ORDERS) {
    return;
}

that code will ALWAYS return.

i think what you want is:

if (basename($PHP_SELF, '.php') != FILENAME_EDIT_ORDERS) {
    return;
}

best.

carlwhat:

hey, i'm a little late to this party. and frankly i stay away from this necessary evil known as edit_orders; however i want to point something out that i saw here.

in the post a few above, this code will NOT do what i think was intended:

if (basename($PHP_SELF) != FILENAME_EDIT_ORDERS) {
return;
}

> 
> that code will ALWAYS return.
> 
> i think what you want is:
> ```
if (basename($PHP_SELF, '.php') != FILENAME_EDIT_ORDERS) {
    return;
}

best.
Not true; FILENAME_EDIT_ORDERS is defined as 'edit_orders'.

lat9:

Not true; FILENAME_EDIT_ORDERS is defined as 'edit_orders'.

yes true. see:

http://php.net/manual/en/function.basename.php

try for yourself:

test.php

$PHP_SELF = $_SERVER['PHP_SELF'];

echo $PHP_SELF . '<----->';

echo basename($PHP_SELF) . '<----->';

echo basename($PHP_SELF, '.php') . '<---';

carlwhat:

yes true. see:

http://php.net/manual/en/function.basename.php

try for yourself:

test.php

$PHP_SELF = $_SERVER['PHP_SELF'];

echo $PHP_SELF . '<----->';

echo basename($PHP_SELF) . '<----->';

echo basename($PHP_SELF, '.php') . '<---';

My apologies, @carlwhat, you're quite right.  I'll get that update pushed to EO's repository.

Providing EO with the minimum subtotal and total in the orders_total table appears to work well with my initial testing. I found a way to exclude ot_tax in the mix by removing ot_tax from the list of modules passed to order_totals in new_order.php, so no messing around with EO needed. But I wonder if the problem found by @carlwhat is the reason why merging the store-side get_zen_tax_locations with EO's version didn't work in my testing. I may try it again just to see what happens. But I'll be happy just the way it is (passing just ot_subtotal and ot_total in orders_total table to EO) if further testing works out well.

Further testing reveals a problem with the order total when subtotal, quantity discount, group discount, shipping, and tax ot_modules are exercised. Each line item is correct, but the total of each line item is too low. It's off by the tax on the sum of the discounts. Any suggestions would be appreciated.
Thanks!

Further testing show the problem appears only when quantity discount is used. If quantity discount is not applicable, and Group discount alone is exercised, the total is correct. If there is no tax, the total is correct. The problem appears only when quantity discount and tax is involved. I should add that everything is correct on the store side. Each line item and the total of all are correct if the same order is entered in the store.

Dave224:

Further testing show the problem appears only when quantity discount is used. If quantity discount is not applicable, and Group discount alone is exercised, the total is correct. If there is no tax, the total is correct. The problem appears only when quantity discount and tax is involved. I should add that everything is correct on the store side. Each line item and the total of all are correct if the same order is entered in the store.
A detailed example, with numbers and discounts would help me further diagnose the issue.