Printable View
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:Quote:
Originally Posted by lat9
That will cause the remainder of that function-file to load only when on behalf of an Edit Orders request.Code:<?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. |
// +----------------------------------------------------------------------+
// -----
// 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;
}
// Include various Zen Cart functions (with any necessary changes for admin)
if(!function_exists('zen_get_country_id')) {
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!!!
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.Quote:
Originally Posted by 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:
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.Code: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
}
}
}
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.Quote:
Originally Posted by Dave224
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
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.Quote:
Originally Posted by Dave224
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:
that code will ALWAYS return.Code:if (basename($PHP_SELF) != FILENAME_EDIT_ORDERS) {
return;
}
i think what you want is:
best.Code:if (basename($PHP_SELF, '.php') != FILENAME_EDIT_ORDERS) {
return;
}