Edit Orders v4.0 Support Thread

Hello guys!
Using this thread for the first time. Please be kind to me if I make silly mistakes.

I have been trying to use EO (latest version from last week) with ZC1.5.6c and spotted something interesting. It is calculating VAT twice on postage (table rate). So, with 20% VAT (the only tax created/used in the site), if I set the postage to £10, then £4 gets added to the total tax and grand total of the order. I tried to figure the issue out and did not have much luck.

With EO V1.4.2, I do not experience this issue (with ZC1.5.6a). But in EO 1.3.5 (with ZC1.5.6a), I did experience the same issue. Not sure if I am setting something wrongly in my site.

The other issue I noticed (even though I did not worry too much about it as there is a work around) is, if you change the tax on postage to 0% using EO, the whole VAT calculation gets messed up and the modified order does not have VAT at all. To get back to the old state, I change the VAT back to 20% and save the order and then use the 'reset' feature to correct the numbers.

Has anybody else experience such a weird behavior? Any help will be much appreciated.

Kind regards,
Shahadat

Quote:

---

Originally Posted by shahadat9612

Hello guys!
Using this thread for the first time. Please be kind to me if I make silly mistakes.

I have been trying to use EO (latest version from last week) with ZC1.5.6c and spotted something interesting. It is calculating VAT twice on postage (table rate). So, with 20% VAT (the only tax created/used in the site), if I set the postage to £10, then £4 gets added to the total tax and grand total of the order. I tried to figure the issue out and did not have much luck.

With EO V1.4.2, I do not experience this issue (with ZC1.5.6a). But in EO 1.3.5 (with ZC1.5.6a), I did experience the same issue. Not sure if I am setting something wrongly in my site.

The other issue I noticed (even though I did not worry too much about it as there is a work around) is, if you change the tax on postage to 0% using EO, the whole VAT calculation gets messed up and the modified order does not have VAT at all. To get back to the old state, I change the VAT back to 20% and save the order and then use the 'reset' feature to correct the numbers.

Has anybody else experience such a weird behavior? Any help will be much appreciated.

Kind regards,
Shahadat

---

The first issue you noted (the double-tax on shipping) has been addressed for the next release. See this GitHub posting for the change needed.

I'll need some time to investigate the second issue you identified.

Quote:

---

Originally Posted by lat9

The first issue you noted (the double-tax on shipping) has been addressed for the next release. See this GitHub posting for the change needed.

I'll need some time to investigate the second issue you identified.

---

Thanks so much! I will try the fix soon! Great work!

Quote:

---

Originally Posted by lat9

The first issue you noted (the double-tax on shipping) has been addressed for the next release. See this GitHub posting for the change needed.

I'll need some time to investigate the second issue you identified.

---

Noting that I'm unable to reproduce the issue where setting the shipping tax-rate to 0 on a store that displays prices-with-tax causes the tax to be removed from products as well.

Quote:

---

Originally Posted by lat9

Noting that I'm unable to reproduce the issue where setting the shipping tax-rate to 0 on a store that displays prices-with-tax causes the tax to be removed from products as well.

---

I am sure, this only shows up under certain condition. I can replicate in my setup consistently. I will dig deeper to see if I can find the issue. Thanks for your help!

Another quick fix to include in the next version:

Code:

---

<!-- body_text_eof //-->
<script>
    <!--
    handleShipping();
    function handleShipping() {
        if (document.getElementById('update_total_code') != undefined) {
            if (document.getElementById('update_total_code').value == 'ot_shipping') {
                document.getElementById('update_total_shipping').style.display = 'table-cell';
            } else {
                document.getElementById('update_total_shipping').style.display = 'none';
            }
        }
    }
    if (document.getElementById('update_total_code') != undefined) {
        document.getElementById('update_total_code').onchange = function(){handleShipping();};
    }
    // -->
</script>

---

Without the 'undefined' check in each case, we end up getting a JS error while trying to edit orders.

Thanks!

Quote:

---

Originally Posted by shahadat9612

I am sure, this only shows up under certain condition. I can replicate in my setup consistently. I will dig deeper to see if I can find the issue. Thanks for your help!

---

You can try enabling EO's debug/trace logging via its configuration settings. That will create a per-order trace of the actions taken by EO for each edited order in your site's /logs/edit_orders sub-directory.

Once you've enabled debug and have recreated the issue, send me a PM and I'll let you know my direct email address (those trace-logs can get quite large).

Quote:

---

Originally Posted by shahadat9612

Another quick fix to include in the next version:

Code:

---

<!-- body_text_eof //-->
<script>
    <!--
    handleShipping();
    function handleShipping() {
        if (document.getElementById('update_total_code') != undefined) {
            if (document.getElementById('update_total_code').value == 'ot_shipping') {
                document.getElementById('update_total_shipping').style.display = 'table-cell';
            } else {
                document.getElementById('update_total_shipping').style.display = 'none';
            }
        }
    }
    if (document.getElementById('update_total_code') != undefined) {
        document.getElementById('update_total_code').onchange = function(){handleShipping();};
    }
    // -->
</script>

---

Without the 'undefined' check in each case, we end up getting a JS error while trying to edit orders.

Thanks!

---

What order-totals are defined/in-use for the order? I can't fathom a configuration where there are no order-totals to be displayed, which would be the basis for that element to not be present.

Quote:

---

Originally Posted by lat9

What order-totals are defined/in-use for the order? I can't fathom a configuration where there are no order-totals to be displayed, which would be the basis for that element to not be present.

---

OK, I think I see the issue.

I'm guessing that your store doesn't have any additional order-totals active (over and above the ot_tax, ot_subtotal, ot_shipping and ot_total values). Please verify.

I've just submitted EO v4.5.1 to the Zen Cart moderators for review; I'll post back here when it's available for download.

This release contains changes associated with the following GitHub issues:

#150: When Editing order its applying tax on shipping which is already taxed.
#153: Conditionally-load javascript for conditionally-rendered form fields.
#154: Correct ot_onetime_discount presence check.

Quote:

---

Originally Posted by gernot

Hi lat9,
I'm busy writing up my automatic install-upgrade check scripts, and notice that in the v4.5.0 documentation there are the following issues.

Typo in documentation (missing / delimiter in path):
/YOUR_ADMIN/includes/init_includes/init_eo_config.php

Incorrectly listed in documentation:
Current: /YOUR_ADMIN/includes/classes/EditOrdersAdminObserver.php
Should be: /YOUR_ADMIN/includes/classes/observers/EditOrdersAdminObserver.php

Not in documentation:
/YOUR_ADMIN/includes/modules/edit_orders/eo_addresses_cbs.php
/YOUR_ADMIN/includes/modules/edit_orders/eo_addresses_csb.php

Not in documentation, but noted in source as being for Edit Orders additional module (not sure what that implies though):
/YOUR_ADMIN/includes/auto_loaders/config.eo_cautions.php
/YOUR_ADMIN/includes/init_includes/edit_orders_cautions.php

---

@gernot, I missed these corrections in v4.5.1 but have the changes staged for the next EO release, see this GitHub issue for details.

Quote:

---

Originally Posted by lat9

I've just submitted EO v4.5.1 to the Zen Cart moderators for review; I'll post back here when it's available for download.

This release contains changes associated with the following GitHub issues:

#150: When Editing order its applying tax on shipping which is already taxed.
#153: Conditionally-load javascript for conditionally-rendered form fields.
#154: Correct ot_onetime_discount presence check.

---

Now available for download: https://www.zen-cart.com/downloads.php?do=file&id=1513

Bugs found in 1.55f install:

Duplicate edit button remains...

This bit of code:
<td class="dataTableContent" align="center"><?php echo (zen_get_orders_comments($orders->fields['orders_id']) == '' ? '' : zen_image(DIR_WS_IMAGES . 'icon_yellow_on.gif', TEXT_COMMENTS_YES, 16, 16)); ?></td>
<td class="dataTableContent noprint" align="right"><?php // echo '<a href="' . zen_href_link(FILENAME_ORDERS, zen_get_all_get_params(array('oID', 'action')) . 'oID=' . $orders->fields['orders_id'] . '&action=edit', 'NONSSL') . '">' . zen_image(DIR_WS_IMAGES . 'icon_edit.gif', ICON_EDIT) . '</a>'; ?><?php // if (isset($oInfo) && is_object($oInfo) && ($orders->fields['orders_id'] == $oInfo->orders_id)) { echo zen_image(DIR_WS_IMAGES . 'icon_arrow_right.gif', ''); } else { echo '<a href="' . zen_href_link(FILENAME_ORDERS, zen_get_all_get_params(array('oID')) . 'oID=' . $orders->fields['orders_id'], 'NONSSL') . '">' . zen_image(DIR_WS_IMAGES . 'icon_info.gif', IMAGE_ICON_INFO) . '</a>'; } ?>&nbsp;</td>
<?php
//-bof-edit_orders-lat9 *** 8 of 8 *** (Add content based on previous notification + new zc156 notification)
// -----
// A watching observer can provide an associative array in the form:

needs to look like this:
<td class="dataTableContent" align="center"><?php echo (zen_get_orders_comments($orders->fields['orders_id']) == '' ? '' : zen_image(DIR_WS_IMAGES . 'icon_yellow_on.gif', TEXT_COMMENTS_YES, 16, 16)); ?></td>
<!-- Twitch remove for edit orders 4.51 duplication - <td class="dataTableContent noprint" align="right"><?php // echo '<a href="' . zen_href_link(FILENAME_ORDERS, zen_get_all_get_params(array('oID', 'action')) . 'oID=' . $orders->fields['orders_id'] . '&action=edit', 'NONSSL') . '">' . zen_image(DIR_WS_IMAGES . 'icon_edit.gif', ICON_EDIT) . '</a>'; ?><?php // if (isset($oInfo) && is_object($oInfo) && ($orders->fields['orders_id'] == $oInfo->orders_id)) { echo zen_image(DIR_WS_IMAGES . 'icon_arrow_right.gif', ''); } else { echo '<a href="' . zen_href_link(FILENAME_ORDERS, zen_get_all_get_params(array('oID')) . 'oID=' . $orders->fields['orders_id'], 'NONSSL') . '">' . zen_image(DIR_WS_IMAGES . 'icon_info.gif', IMAGE_ICON_INFO) . '</a>'; } ?>&nbsp;</td> -->
<?php
//-bof-edit_orders-lat9 *** 8 of 8 *** (Add content based on previous notification + new zc156 notification)
// -----
// A watching observer can provide an associative array in the form:



Second critical bug was a problem since version 4.3.5 - 4.51...

Editing an order in admin - edit_orders.php will erase the delivery selection and all associated values.

In 4.3.5 - order details above the delivery line can be changed and do pass to the updated order.
In 4.5.1 - order details are not changed and delivery selection and values are lost.

Editing an order will corrupt the data and overwrite it in the database.

1.55f running on PHP 7.1 and the errors occur on PHP 7.3

For the first issue (it would have helped if you'd highlighted the changes), I'm (a) assuming that these are the changes to the zc155f admin/orders.php and (b) the only 8 of 8 that I found in the EO distribution was down towards the status-history section. Here's that section from the EO distribution; the comment looks the same as that you posted, but the code leading into it doesn't:

Code:

---

                <td class="dataTableContent" align="center"><?php echo (zen_get_orders_comments($orders->fields['orders_id']) == '' ? '' : zen_image(DIR_WS_IMAGES . 'icon_yellow_on.gif', TEXT_COMMENTS_YES, 16, 16)); ?></td>
<?php
//-bof-edit_orders-lat9  *** 8 of 8 *** (Add content based on previous notification + new zc156 notification)
  // -----
  // A watching observer can provide an associative array in the form:
  //
  // $extra_data = array(
  //    array(
  //      'align' => $alignment,    // One of 'center', 'right', or 'left' (optional)
  //      'text' => $value
  //    ),
  // );
  //
  // Observer note:  Be sure to check that the $p3/$extra_data value is specifically (bool)false before initializing, since
  // multiple observers might be injecting content!
  //
  $extra_data = false;
  $zco_notifier->notify('NOTIFY_ADMIN_ORDERS_LIST_EXTRA_COLUMN_DATA', (isset($oInfo) ? $oInfo : array()), $orders->fields, $extra_data);

---

For the second issue, I'm unable to replicate on a fresh zc155f/eo451 installation ... but maybe I don't understand what "the delivery line" means. If you're talking about the product pricing, there are now settings that control EO's pricing calculation method, as identified in the readme.

The default is to automatically (i.e. based on database settings) calculate; perhaps you haven't updated that setting?

The first issue needs the <td> extra edit button removed/hidden out of the gate or your 8 of 8 will duplicate the button.

Second the loworderfee, product name, product model will not update changes in 4.51 it will retain the data - NOT the changes - for product name, model if anything is changed the delivery low order fee will be removed and any other relative order totals are also changed/removed or not included.

After reviewing the code and the settings in config it appears the updates are not being considered correctly or accounted for in the 'matrix' these settings create. Meaning - one setting for auto pricing might work great to calculate the new prices/changes but neglects to include the low order fee during the update.

Oddly if I manually enter in a delivery fee amount to replace the 'automatically reset' $0.00 values - it will update and retain the manually entered data - only after it has deleted the original values an overwritten the master order data thus corrupting it.

As a result there is no backup for these lost order details less the order emails from admin - to the customer.

Quote:

---

Originally Posted by twitchtoo

The first issue needs the <td> extra edit button removed/hidden out of the gate or your 8 of 8 will duplicate the button.

Second the loworderfee, product name, product model will not update changes in 4.51 it will retain the data - NOT the changes - for product name, model if anything is changed the delivery low order fee will be removed and any other relative order totals are also changed/removed or not included.

After reviewing the code and the settings in config it appears the updates are not being considered correctly or accounted for in the 'matrix' these settings create. Meaning - one setting for auto pricing might work great to calculate the new prices/changes but neglects to include the low order fee during the update.

Oddly if I manually enter in a delivery fee amount to replace the 'automatically reset' $0.00 values - it will update and retain the manually entered data - only after it has deleted the original values an overwritten the master order data thus corrupting it.

As a result there is no backup for these lost order details less the order emails from admin - to the customer.

---

For the first, I'm not seeing that on a "fresh" zc155f /admin/orders.php. I'll note (again) that the code that you posted is different from the zc155f version distributed by EO.

For the second, I'll look into the integration with the loworderfee (presuming that you're using that built into Zen Cart) and will note initially that the order-total is using the shopping-cart values to do its calculations instead of the information stored in the order itself.

Thanks for the info, one of the problems is that the order total modules/classes are not being considered when recalculating the proper order total.

From what I can see they are hard coded filters. So, when an order is processed if there are any name changes or variations or alternate values in the class beyond what EO has written they will not be included but what's worse is the code will erase the entire 'old' data and only add the new.

For example: Reward Points class = ot_reward_points_display will not be recognized as there is no code identifying what is in the order data dynamically then deciding what to do with it without just bulldozing the new data in.

That explains also why reward points is not being recalculated during EO updates.

Quote:

---

Originally Posted by twitchtoo

Thanks for the info, one of the problems is that the order total modules/classes are not being considered when recalculating the proper order total.

From what I can see they are hard coded filters. So, when an order is processed if there are any name changes or variations or alternate values in the class beyond what EO has written they will not be included but what's worse is the code will erase the entire 'old' data and only add the new.

For example: Reward Points class = ot_reward_points_display will not be recognized as there is no code identifying what is in the order data dynamically then deciding what to do with it without just bulldozing the new data in.

That explains also why reward points is not being recalculated during EO updates.

---

FWIW, I just verified that the ot_loworder fee is added/subtracted when the order is updated on a fresh zc155f/eo451 installation.

From what I've seen of the Reward Points plugin, it's got too many tentacles into the cart-related processing to allow it to interoperate with Edit Orders.

I'm not sure what you mean by "hard coded filters"; there are some processing variations for some order-totals but for the most part, if an order-total is installed it's given the opportunity to run and make its changes to the order itself.

Thanks lat9, I'll get them all working together later today.

Quote:

---

Originally Posted by twitchtoo

Thanks lat9, I'll get them all working together later today.

---

Excellent. If you want to share your changes, I'll be happy to include them in a future EO release.

EO 4.5.0
When I attempt to add "Edit Orders" to non-SuperUser admin profiles, the non-SuperUser Admin user gets the message

If I missed the fix or setting, it's ok to tell me to look a bit harder. :-)

Quote:

---

Sorry, your security clearance does not allow you to access this resource.


Please contact your site administrator if you believe this to be incorrect.


Sorry for any inconvenience.

---

Another myDEBUG. Sorry, I can find all the lines mentioned but it is mostly cross-eyed visions.

Code:

---

[06-Apr-2020 13:09:46 America/Los_Angeles] Request URI: /greeN-JdH-shruB/edit_orders.php?selected_box=customers&status=5&page=1&oID=920110&action=edit, IP address: 98.146.164.107
#1  usps->usps_translation() called at [/home/chainwea/public_html/includes/modules/shipping/usps.php:159]
#2  usps->__construct() called at [/home/chainwea/public_html/includes/classes/shipping.php:63]
#3  shipping->__construct() called at [/home/chainwea/public_html/greeN-JdH-shruB/includes/functions/extra_functions/edit_orders_functions.php:1635]
#4  eo_get_available_shipping_modules() called at [/home/chainwea/public_html/greeN-JdH-shruB/edit_orders.php:1555]
--> PHP Warning: Illegal string offset 'iso_code_2' in /home/chainwea/public_html/includes/modules/shipping/usps.php on line 1991.

[06-Apr-2020 13:09:46 America/Los_Angeles] Request URI: /greeN-JdH-shruB/edit_orders.php?selected_box=customers&status=5&page=1&oID=920110&action=edit, IP address: 98.146.164.107
#1  usps->usps_translation() called at [/home/chainwea/public_html/includes/modules/shipping/usps.php:159]
#2  usps->__construct() called at [/home/chainwea/public_html/includes/classes/shipping.php:63]
#3  shipping->__construct() called at [/home/chainwea/public_html/greeN-JdH-shruB/includes/functions/extra_functions/edit_orders_functions.php:1635]
#4  eo_get_available_shipping_modules() called at [/home/chainwea/public_html/greeN-JdH-shruB/edit_orders.php:1555]
--> PHP Warning: Illegal string offset 'iso_code_2' in /home/chainwea/public_html/includes/modules/shipping/usps.php on line 2005.

[06-Apr-2020 13:09:46 America/Los_Angeles] Request URI: /greeN-JdH-shruB/edit_orders.php?selected_box=customers&status=5&page=1&oID=920110&action=edit, IP address: 98.146.164.107
#1  freeoptions->__construct() called at [/home/chainwea/public_html/includes/classes/shipping.php:63]
#2  shipping->__construct() called at [/home/chainwea/public_html/greeN-JdH-shruB/includes/functions/extra_functions/edit_orders_functions.php:1635]
#3  eo_get_available_shipping_modules() called at [/home/chainwea/public_html/greeN-JdH-shruB/edit_orders.php:1555]
--> PHP Warning: Illegal string offset 'id' in /home/chainwea/public_html/includes/modules/shipping/freeoptions.php on line 35.

[06-Apr-2020 13:09:47 America/Los_Angeles] Request URI: /greeN-JdH-shruB/edit_orders.php?selected_box=customers&status=5&page=1&oID=920110&action=edit, IP address: 98.146.164.107
#1  usps->usps_translation() called at [/home/chainwea/public_html/includes/modules/shipping/usps.php:159]
#2  usps->__construct() called at [/home/chainwea/public_html/includes/classes/shipping.php:63]
#3  shipping->__construct() called at [/home/chainwea/public_html/greeN-JdH-shruB/includes/functions/extra_functions/edit_orders_functions.php:1635]
#4  eo_get_available_shipping_modules() called at [/home/chainwea/public_html/greeN-JdH-shruB/edit_orders.php:1613]
--> PHP Warning: Illegal string offset 'iso_code_2' in /home/chainwea/public_html/includes/modules/shipping/usps.php on line 1991.

[06-Apr-2020 13:09:47 America/Los_Angeles] Request URI: /greeN-JdH-shruB/edit_orders.php?selected_box=customers&status=5&page=1&oID=920110&action=edit, IP address: 98.146.164.107
#1  usps->usps_translation() called at [/home/chainwea/public_html/includes/modules/shipping/usps.php:159]
#2  usps->__construct() called at [/home/chainwea/public_html/includes/classes/shipping.php:63]
#3  shipping->__construct() called at [/home/chainwea/public_html/greeN-JdH-shruB/includes/functions/extra_functions/edit_orders_functions.php:1635]
#4  eo_get_available_shipping_modules() called at [/home/chainwea/public_html/greeN-JdH-shruB/edit_orders.php:1613]
--> PHP Warning: Illegal string offset 'iso_code_2' in /home/chainwea/public_html/includes/modules/shipping/usps.php on line 2005.

[06-Apr-2020 13:09:47 America/Los_Angeles] Request URI: /greeN-JdH-shruB/edit_orders.php?selected_box=customers&status=5&page=1&oID=920110&action=edit, IP address: 98.146.164.107
#1  freeoptions->__construct() called at [/home/chainwea/public_html/includes/classes/shipping.php:63]
#2  shipping->__construct() called at [/home/chainwea/public_html/greeN-JdH-shruB/includes/functions/extra_functions/edit_orders_functions.php:1635]
#3  eo_get_available_shipping_modules() called at [/home/chainwea/public_html/greeN-JdH-shruB/edit_orders.php:1613]
--> PHP Warning: Illegal string offset 'id' in /home/chainwea/public_html/includes/modules/shipping/freeoptions.php on line 35.

---

Quote:

---

Originally Posted by RixStix

EO 4.5.0
When I attempt to add "Edit Orders" to non-SuperUser admin profiles, the non-SuperUser Admin user gets the message

If I missed the fix or setting, it's ok to tell me to look a bit harder. :-)

---

Dummy here looked a bit harder. Found the 2nd "edit orders" checkbox under CUSTOMERS which had not yet been checked in the non-superuser admin profile. The one under Configuration had been checked in the non-superuser admin profile.

Edit an order

Click update (not sure if there is a difference dependent upon which of the 2 Update buttons are clicked)
Green banner that order has been edited.
Return to order
Edited fields (product name and model) are not changed

the myDebug file is generated

Order had been in a 'cancelled' status (5)
Edited status back to 'processing' prior to making any order edits.

Quote:

---

Originally Posted by RixStix

Edit an order

Click update (not sure if there is a difference dependent upon which of the 2 Update buttons are clicked)
Green banner that order has been edited.
Return to order
Edited fields (product name and model) are not changed

the myDebug file is generated

Order had been in a 'cancelled' status (5)
Edited status back to 'processing' prior to making any order edits.

---

There's now a configuration setting that controls EO's product-handling. That defaults to automatic, where the product-related information is gathered 'automatically' and overrides the manual entry. Sounds like you want to change the default from "Automatic" to "Manual".

In EO Configuration, I see what appears to be related to automatic price calculations, but nothing related to not allowing the editing of a product description or model number.

Maybe I am misunderstanding the intended functionality. If a product has attributes, the attribute has a pulldown box which can be changed. Product name and model only appears as a text box. I can edit/change an attribute. I cannot type a different product name or model number. Not all products have product numbers.

Quote:

---

Originally Posted by RixStix

In EO Configuration, I see what appears to be related to automatic price calculations, but nothing related to not allowing the editing of a product description or model number.

Maybe I am misunderstanding the intended functionality. If a product has attributes, the attribute has a pulldown box which can be changed. Product name and model only appears as a text box. I can edit/change an attribute. I cannot type a different product name or model number. Not all products have product numbers.

---

The product-pricing (automatic vs manual) also affects the product name and model. When automatic, the name/model is pulled from the database; when manual, input is accepted and stored.

I'm just going to remove EO

That is the only thing that I can do within my current skillset to prevent the debug files from being generated and hopefully removing it will also restore functionality to Square. I am not saying there is a problem with EO because it is probably something that I did or didn't do.

you should change your admin directory name since you've put it out there for all to see

Ooops

thanks

Next to the update button on the left, we have

Reset totals prior to update? (checkbox) Note: Pricing for products will be automatically calculated without "specials" pricing.

I wonder if it would be better to put each of these on a separate line? The current layout could be confusing for new people.

Hi, using Edit Orders 4.5.1 on Zen Cart 1.5.6c, at
https://www.proteawines.jp
with Paypal Express Checkout enabled and working fine.
My store and I are both based in Tokyo, Japan.

I have edited my first order, the payment is on hold pending delivery courtesy of Paypal (since the payer is in Japan, outside the US).
This has always worked before, so this is not a problem, payment goes through after delivery (I supply tracking information).

I added a miscellaneous item (small addition for refrigerated shipping requested by customer after she placed the order).
However, this does not seem to change the pending payment amount from Paypal for the order.
So the customer now has an order in Zen Cart not matching what Paypal says will be paid.
Or will Paypal do an update on the order when they fulfill their payment after delivery?

If there order had been changed materially (i.e., changes to the products, or a completely different shipping method), would that update Paypal right away?

Sorry for the questions, I could not find an answer searching this thread, reading the docs, or via Google.

Changes to an order that result in a difference in payment are the responsibility of the store-owner to rectify. Edit Orders has no 'play' in updating the payment-provider to refund or collect additional funds based on the order's value changing.

Thanks for clearing that up, much appreciated.
I guess in Zen Cart the way to do that with the Express Checkout module is to give a refund, and ask the buyer to make the new payment.
Presumably that works for Square as well and other card processors.
If there is another way that people tend to use, I would love to know also.

Hello!

After I edit one order all prices in my Zencart admin backend are shown without taxes.

If I logout and then login taxes are back.

I believe this is something related to session.

Where could be the problem?

Quote:

---

Originally Posted by jeanjean88

Hello!

After I edit one order all prices in my Zencart admin backend are shown without taxes.

If I logout and then login taxes are back.

I believe this is something related to session.

Where could be the problem?

---

You haven't given me much to work with. What's the Zen Cart version, the EO version and other plugins in use on the admin?

What are your store's settings for My Store->Display prices with tax and Display prices with tax in admin?

Zencart v1.5.1

EO 4.1.4

I don't have related plugins in the admin

Display Prices with Tax: true
Display Prices with Tax in Admin: true

The only thing I did notice is that if I comment the following line in functions/edit_orders_functions.php the error doesn't happen anymore, unless I add a product (so if I simply update address or prices it doesn't happen)

PHP Code:

---

function eo_get_order_by_id($oID) {
    global $db, $order;

    // Retrieve the order
    $order = new order($oID);

    // Add some required customer information for tax calculation
    // The next method has been modified to add required info to the
    // session and global variables.

    // zen_get_tax_locations();   <============================= THIS COMMENTED 


---

Quote:

---

Originally Posted by jeanjean88

Zencart v1.5.1

EO 4.1.4

I don't have related plugins in the admin

Display Prices with Tax: true
Display Prices with Tax in Admin: true

The only thing I did notice is that if I comment the following line in functions/edit_orders_functions.php the error doesn't happen anymore, unless I add a product (so if I simply update address or prices it doesn't happen)

PHP Code:

---

function eo_get_order_by_id($oID) {
    global $db, $order;

    // Retrieve the order
    $order = new order($oID);

    // Add some required customer information for tax calculation
    // The next method has been modified to add required info to the
    // session and global variables.

    // zen_get_tax_locations();   <============================= THIS COMMENTED 


---

---

That's a very old and unsupported version of both Edit Orders and Zen Cart.

If it was easier to upgrade I would have =)

Thanks for your (NON) help.

Staying up to date is part of your responsibility as a storeowner. If you can't do it yourself, place an ad in the Commercial Help Wanted forum and hire it done.

Please remember that the people answering questions on the forum are volunteers. Be nice.

Honestly being nice was to give an HINT on how to solve the problem...

I don't need a ready-to-go solution. Just an opinion.

Unfortunately for my store upgrading is not an option, otherwise I would not be here asking for that.

Forgive me if this has been addressed before but the instructions state "We do not recommend clicking "edit" on completed orders." So exactly what is meant by completed? Final status change / actual payment taken? The cart is using the old CEON cc mod on purpose so that the owner can edit the order and add charges for shipping and discounts. So in his mind the order isn't completed until he does exactly that and then he changes the order status to shipped. What is the reality?

Quote:

---

Originally Posted by delia

Forgive me if this has been addressed before but the instructions state "We do not recommend clicking "edit" on completed orders." So exactly what is meant by completed? Final status change / actual payment taken? The cart is using the old CEON cc mod on purpose so that the owner can edit the order and add charges for shipping and discounts. So in his mind the order isn't completed until he does exactly that and then he changes the order status to shipped. What is the reality?

---

That wording is carry-over from the v4.1.4 version of EO that I started with. I suppose that DivaVocals was just being cautious in her wording.

Things that can go wrong:
- A product in an old order is no longer stocked by the store.
- A product-option in an old order is no longer available for a product in the order.

so in other words, the longer you wait to edit an order, the more problematic it could possibly be. Perhaps changing the wording in the instructions? Is this in github?

Quote:

---

Originally Posted by delia

so in other words, the longer you wait to edit an order, the more problematic it could possibly be. Perhaps changing the wording in the instructions? Is this in github?

---

You bet: https://github.com/lat9/edit_orders

EO 4.5.0, Zen Cart 1.5.6. It appears that orders with a tax line item have the tax order total entry removed after an order update.
Is this an integration problem on my end or have others seen it?

Quote:

---

Originally Posted by swguy

EO 4.5.0, Zen Cart 1.5.6. It appears that orders with a tax line item have the tax order total entry removed after an order update.
Is this an integration problem on my end or have others seen it?

---

zc156, no suffix? What are you using for the product-pricing method?

I'm not seeing this on zc156c/eo450.

Sorry, 156c. Product Pricing - tested manual and auto, both had the same issue. OK I will dig in on my side.

Investigating ...

admin/includes/functions/extra_functions/edit_orders_functions.php lines 1429-1445 you are referencing $order->totals[$i]['class'].
This should be $order->totals[$i]['code'] shouldn't it?

(lines are same between EO 4.5.0 and 4.5.1)

The root cause of the deleted tax line is in the block that handles the "rogue" ot_tax value.
(Around 1449 of ./includes/functions/extra_functions/edit_orders_functions.php).

My tax title is Sales tax (if any) + Shipping Tax (0.0000%) + Tax:

which does not work for the clause

`title` NOT IN ($tax_groups)

Perhaps a LIKE would be better - something like

Code:

---


foreach ($tax_groups as &$tax_group) {
  $tax_group = '%' . $db->prepareInput($tax_group) .'%'. ':';
}
$tax_groups = "'" . implode("', '", $tax_groups) . "'";
...
$query =
                "DELETE FROM " . TABLE_ORDERS_TOTAL . "
                  WHERE orders_id = $oID
                    AND `class` = 'ot_tax'
                    AND `title` NOT IN ("; 
for ($i = 0; $i < count($tax_groups); $i++) {
  if ($i > 0) $query .= ",";
  $query .= $tax_groups[$i];
}
$query .= ")";

---

admin/includes/classes/editOrders.php lines 270, 274: should $this->shipping_tax_rate be cast as a float in case it's null?
(Getting SQL error on line 270)

Quote:

---

Originally Posted by swguy

Investigating ...

admin/includes/functions/extra_functions/edit_orders_functions.php lines 1429-1445 you are referencing $order->totals[$i]['class'].
This should be $order->totals[$i]['code'] shouldn't it?

(lines are same between EO 4.5.0 and 4.5.1)

---

Nope, the $order->totals array is 'indexed' by its class element.

The $order_total_modules, just to make life interesting, returns each module's entry with a reference to its code (aka the order's class) element.

As created by the class, yes - but by the time it gets to eo_update_database_order_totals, the array entries have been changed. See screenshot.

Quote:

---

Originally Posted by swguy

The root cause of the deleted tax line is in the block that handles the "rogue" ot_tax value.
(Around 1449 of ./includes/functions/extra_functions/edit_orders_functions.php).

My tax title is Sales tax (if any) + Shipping Tax (0.0000%) + Tax:

which does not work for the clause

`title` NOT IN ($tax_groups)

Perhaps a LIKE would be better - something like

Code:

---


foreach ($tax_groups as &$tax_group) {
  $tax_group = '%' . $db->prepareInput($tax_group) .'%'. ':';
}
$tax_groups = "'" . implode("', '", $tax_groups) . "'";
...
$query =
                "DELETE FROM " . TABLE_ORDERS_TOTAL . "
                  WHERE orders_id = $oID
                    AND `class` = 'ot_tax'
                    AND `title` NOT IN ("; 
for ($i = 0; $i < count($tax_groups); $i++) {
  if ($i > 0) $query .= ",";
  $query .= $tax_groups[$i];
}
$query .= ")";

---

---

Hmm, looks like you've got My Store::Show Split Tax Lines set to false. Let me investigate further.

Quote:

---

Originally Posted by swguy

As created by the class, yes - but by the time it gets to eo_update_database_order_totals, the array entries have been changed. See screenshot.

---

You're displaying the contents of the $order_totals array, as returned by $order_total_modules->process, not the contents of $order->totals.

Aside: sorry, that suggested code didn't come out quite right - I was thinking a LIKE with all strings concatenated with % between strings (and before and after).

Quote:

---

Originally Posted by lat9

You're displaying the contents of the $order_totals array, as returned by $order_total_modules->process, not the contents of $order->totals.

---

CRAP! You are correct, sorry for the false report.

Quote:

---

Originally Posted by swguy

admin/includes/classes/editOrders.php lines 270, 274: should $this->shipping_tax_rate be cast as a float in case it's null?
(Getting SQL error on line 270)

---

It's taken a long time to get all those other float-casts out of EO (trying to get rid of those penny-off calculations), but I'll update this section of the class' initializeOrderShippingTax method:

Code:

---

        switch ($action) {
            case 'update_order':
                $this->shipping_tax_rate = $_POST['shipping_tax'];
                $order->info['shipping_tax'] = $this->calculateOrderShippingTax(true);
                break;
            case 'add_prdct':
                $this->shipping_tax_rate = $tax_rate->fields['shipping_tax_rate'];
                $order->info['shipping_tax'] = $this->eoRoundCurrencyValue(zen_calculate_tax($order->info['shipping_cost'], $this->shipping_tax_rate));
                break;
            default:
                $this->shipping_tax_rate = $tax_rate->fields['shipping_tax_rate'];
                $order->info['shipping_tax'] = $this->calculateOrderShippingTax(false);
                break;
        }

---

to sanitize that value on entry.

See this GitHub issue for follow-on: https://github.com/lat9/edit_orders/issues/157

As an alternative, you could not do the update when the value is null. But I'm ok with either solution. Thanks!

Quote:

---

Originally Posted by lat9

It's taken a long time to get all those other float-casts out of EO (trying to get rid of those penny-off calculations), but I'll update this section of the class' initializeOrderShippingTax method:

Code:

---

        switch ($action) {
            case 'update_order':
                $this->shipping_tax_rate = $_POST['shipping_tax'];
                $order->info['shipping_tax'] = $this->calculateOrderShippingTax(true);
                break;
            case 'add_prdct':
                $this->shipping_tax_rate = $tax_rate->fields['shipping_tax_rate'];
                $order->info['shipping_tax'] = $this->eoRoundCurrencyValue(zen_calculate_tax($order->info['shipping_cost'], $this->shipping_tax_rate));
                break;
            default:
                $this->shipping_tax_rate = $tax_rate->fields['shipping_tax_rate'];
                $order->info['shipping_tax'] = $this->calculateOrderShippingTax(false);
                break;
        }

---

to sanitize that value on entry.

See this GitHub issue for follow-on: https://github.com/lat9/edit_orders/issues/157

---

Update provided; see that issue for the change required.

Quote:

---

Originally Posted by lat9

Hmm, looks like you've got My Store::Show Split Tax Lines set to false. Let me investigate further.

---

The work-around for this issue is to update the above setting to true, so that each tax-type's value is recorded as a separate ot_tax order-total.

The underlying cause of the issue is that the order's shipping-tax's "Tax Group" isn't captured as part of the order's processing so that reconstructing the order's taxes when all the taxes are bundled into a single, overall value is 'difficult'.:(

Quote:

---

Originally Posted by lat9

The work-around for this issue is to update the above setting to true, so that each tax-type's value is recorded as a separate ot_tax order-total.

The underlying cause of the issue is that the order's shipping-tax's "Tax Group" isn't captured as part of the order's processing so that reconstructing the order's taxes when all the taxes are bundled into a single, overall value is 'difficult'.:(

---

GitHub issue created for tracking: https://github.com/lat9/edit_orders/issues/158

Quote:

---

Originally Posted by lat9

The underlying cause of the issue is that the order's shipping-tax's "Tax Group" isn't captured as part of the order's processing so that reconstructing the order's taxes when all the taxes are bundled into a single, overall value is 'difficult'.:(

---

I quite agree. Perhaps something involving LIKE (but perhaps excluding default strings like "Tax" or "Sales Tax"?) might work. I can see how this block was created in response to an edge case.

Quote:

---

Originally Posted by swguy

I quite agree. Perhaps something involving LIKE (but perhaps excluding default strings like "Tax" or "Sales Tax"?) might work. I can see how this block was created in response to an edge case.

---

It's actually not an edge case, that shipping-tax handling was created based on various uses where (as in your case) the tax on shipping is different than that associated with the various products in the order.

Finally got around to trying to upgrade my site from 1.3.9h to the latest version, 1.5.7. Love Super Orders and Edit Orders. My Faves for sure. For some reason I cant get edit orders to work and Im thinking its a simple workaround, but I haven't found it yet. I get this error when trying to edit or delete an order

The store's zen_add_tax function must be updated to enable Edit Orders' use.

I see a file with the same name, but opening it did not provide any clues to how to remove it and I have been through every admin tab available with no luck...

My admin log has this message

#1 sizeof() called at [/admen/orders.php:1110]
#2 require(/admen/orders.php) called at [/admen/index.php:11]
--> PHP Warning: sizeof(): Parameter must be an array or an object that implements Countable in /admen/orders.php on line 1110.

Any idea how to squash this message and let edit orders do its work?

Quote:

---

Originally Posted by johnniejetski2

Finally got around to trying to upgrade my site from 1.3.9h to the latest version, 1.5.7. Love Super Orders and Edit Orders. My Faves for sure. For some reason I cant get edit orders to work and Im thinking its a simple workaround, but I haven't found it yet. I get this error when trying to edit or delete an order

The store's zen_add_tax function must be updated to enable Edit Orders' use.

I see a file with the same name, but opening it did not provide any clues to how to remove it and I have been through every admin tab available with no luck...

My admin log has this message

#1 sizeof() called at [/admen/orders.php:1110]
#2 require(/admen/orders.php) called at [/admen/index.php:11]
--> PHP Warning: sizeof(): Parameter must be an array or an object that implements Countable in /admen/orders.php on line 1110.

Any idea how to squash this message and let edit orders do its work?

---

Arggh, that's still not fixed in zc157? Anyway, the Installation :: Changes to zen_add_tax tab in the EO readme identifies the changes needed to the admin's /includes/functions/general.php that are required for EO to do its thing.

That definitely made it better, however when I went to DELETE an order I get this
This page isn’t working
www.MY-SITE. is currently unable to handle this request.
HTTP ERROR 500

Quote:

---

Originally Posted by johnniejetski2

That definitely made it better, however when I went to DELETE an order I get this
This page isn’t working
www.MY-SITE. is currently unable to handle this request.
HTTP ERROR 500

---

... and in your site's /logs sub-directory will be a myDEBUG-adm-{something}.log file containing details as to what that underlying issue is. Remember that since it's an admin log-file, it will contain a reference to your admin directory's name, so you need to xxx-that out prior to posting back.

Lat9 - Can you tell me where the zen_get_countries_name() function is defined at?

I thought i had the module working, but now I am getting an error: PHP Fatal error: Uncaught Error: Call to undefined function zen_get_countries_name() in /home/userdir/public_html/store/admin/includes/functions/extra_functions/edit_orders_functions.php:586

I looked online but I am not seeing the function in any of the ZenCart documentation.

Quote:

---

Originally Posted by Jeff_Mash

Lat9 - Can you tell me where the zen_get_countries_name() function is defined at?

I thought i had the module working, but now I am getting an error: PHP Fatal error: Uncaught Error: Call to undefined function zen_get_countries_name() in /home/userdir/public_html/store/admin/includes/functions/extra_functions/edit_orders_functions.php:586

I looked online but I am not seeing the function in any of the ZenCart documentation.

---

looks like a typo. use:

PHP Code:

---

'name' => zen_get_country_name($country_info->fields['countries_id']), 


---

Yep, that's it.:clap:

Quote:

---

Originally Posted by carlwhat

looks like a typo. use:

PHP Code:

---

'name' => zen_get_country_name($country_info->fields['countries_id']), 


---

---

That was it! Good catch, and thanks for the help!

Thanks, @dbltoe and @carlwhat, for the support! Changes are staged for the v4.5.2 release of EO.

Quote:

---

Originally Posted by Jeff_Mash

That was it! Good catch, and thanks for the help!

---

Quote:

---

Originally Posted by lat9

Thanks, @dbltoe and @carlwhat, for the support! Changes are staged for the v4.5.2 release of EO.

---

:thumbsup:

I've just submitted v4.5.2 of EO to the Zen Cart moderators for review and will post back here when it's available for download.

This release contains changes associated with the following GitHub issues:

#151: Use CSS buttons during Edit Orders processing for zc156 and later.
#157: Correct MySQL error when empty shipping-tax value is entered.
#160: Correct integration for product-addition of SBA-managed product.
#163: Use zen_output_string_protected instead of to-be-deprecated zen_db_output.
#165: Correct function name (zen_get_country_name) to prevent PHP fatal error.

Thanks to @proseLA and @mc12345678 for their contributions!

Quote:

---

Originally Posted by lat9

I've just submitted v4.5.2 of EO to the Zen Cart moderators for review and will post back here when it's available for download.

This release contains changes associated with the following GitHub issues:

#151: Use CSS buttons during Edit Orders processing for zc156 and later.
#157: Correct MySQL error when empty shipping-tax value is entered.
#160: Correct integration for product-addition of SBA-managed product.
#163: Use zen_output_string_protected instead of to-be-deprecated zen_db_output.
#165: Correct function name (zen_get_country_name) to prevent PHP fatal error.

Thanks to @proseLA and @mc12345678 for their contributions!

---

Now available for download: https://www.zen-cart.com/downloads.php?do=file&id=1513

i get this error when i try to add the admin menu
In the attachment you will see what i added and the error i got

thank you
noppie

@noppie - You should not be having to do anything other than loading the files and logging into the admin. The rest should be done automatically.

You don't mention the version of ZC you are using but, with 1.5.7 AND a pre-existing version of EO, we have found that running the uninstall_eo.sql file located in docs/edit_orders/uninstall and then logging back into admin (refreshing the home page) will properly load the mod.

SO....If you had EO before, loaded the new files, and the mod did not "do it's thing"; try running the uninstall_eo.sql file and clicking admin home when you're through.

i am on 156f because that works with the multil-site. and that is what i thought,
thank you for answering but now i dont know what to do.

Well, here's how you have US confused.

The domain in your sig tells us it doesn't exist although it is registered. It was either just registered or just renewed. You're registered with wild west but there's no way to purchase a domain from them. They are a subsidiary of GoneDaddy.

And, there is no Zen Cart version 156f. 1.5.5 went to f but, 1.5.6 only went to c. 1.5.7 is not quite to a.

Someone has a redirect on your site sending everything to herasonlinemarket.com/shop/index.php

Perhaps you can take the time to open a separate thread as there is far more going on here than Edit Orders. In that new thread, PLEASE answer ALL the Posting Tips questions that come up when you start the new thread.

Quote:

---

Originally Posted by dbltoe

Well, here's how you have US confused.

The domain in your sig tells us it doesn't exist although it is registered. It was either just registered or just renewed. You're registered with wild west but there's no way to purchase a domain from them. They are a subsidiary of GoneDaddy.

And, there is no Zen Cart version 156f. 1.5.5 went to f but, 1.5.6 only went to c. 1.5.7 is not quite to a.

Someone has a redirect on your site sending everything to herasonlinemarket.com/shop/index.php

Perhaps you can take the time to open a separate thread as there is far more going on here than Edit Orders. In that new thread, PLEASE answer ALL the Posting Tips questions that come up when you start the new thread.

---

it is because of the multi site mode that is acting up.
and i think i got that working now.

so i still get the error above..
thank you
noppie

Quote:

---

Originally Posted by dbltoe

Perhaps you can take the time to open a separate thread as there is far more going on here than Edit Orders. In that new thread, PLEASE answer ALL the Posting Tips questions that come up when you start the new thread.

---

Or don't. Your choice.

as i said it is working now.. it was not working because of a mis configuration of the multi site. the admin no problems
but i dont really need this that much.. i will try another day.
noppie

When I edit an order it is basing the product tax on a rounded unit value. Example:

My customer changed their quantity of cheques to 1000 forms. The unit cost for the new quantity is $0.176 which I input in the "Unit price" box. When I hit update, it changes the Unit Price to $0.80 (not a big deal really for display), the "Total" changes to the correct price of $176.00. Down in the tax section, however it is calculating the tax on the rounded value of $0.80, not the subtotal value of $176.00. (see attached EO1.jpg).

Is there an easy fix to have it calculate the tax off the subtotal?

Attachment 19201
Attachment 19202

Colleen, thanks for the report. I'll see what's up in the morning.

I've just submitted v4.5.3 of Edit Orders.

This release contains changes associated with the following GitHub issues:

#158: Document the configuration required for stores with separate tax-rates on shipping.
#167: Early rounding causes products' pricing errors when prices have more significant digits than the currency supports.
#169: Use 'floatval' instead of a float-cast to reduce penny-off calculations.
#170: Correct PHP warning when shipping is removed from an order.

Now available for download: https://www.zen-cart.com/downloads.php?do=file&id=1513

I have a rough solution to the edit buttons becoming blue circles and duplication of the edit buttons.

In admin | includes | classes | observers |EDitOrdersAdminObserver.php on line 83 (approx) I changed

Quote:

---

p4 .= $this->createEditOrdersLink($p2['orders_id'], zen_image(DIR_WS_IMAGES . EO_BUTTON_ICON_DETAILS, EO_ICON_DETAILS), EO_ZC156_FA_ICON, false);

---

to

Quote:

---

p4 .= $this->createEditOrdersLink($p2['orders_id'], zen_image(DIR_WS_IMAGES . EO_BUTTON_ICON_DETAILS, EO_ICON_DETAILS), ' ', false);

---

The original edit button (white e on green circular background) remains with the blue triangle on the right.


Environment Test: Zen Cart 157; Apache 2.4.46; PHP 7.3.21; MySQL 5.7.31; Linux 4.15.0

I've got an update posted on the EO GitHub repository that corrects that wonky display: https://github.com/lat9/edit_orders/...9276987f05c60d

plugin for a plugin!

if you have additional fields added to your orders_products table, and have been frustrated by those fields not being there when adjusting quantities, be frustrated no longer!

plugin:
https://www.zen-cart.com/downloads.php?do=file&id=2292

its own support thread:
https://www.zen-cart.com/showthread....il-record-copy

best.

Quote:

---

Originally Posted by lat9

I've got an update posted on the EO GitHub repository that corrects that wonky display: https://github.com/lat9/edit_orders/...9276987f05c60d

---

Nice... I just added a color style to the stack overlay which worked for the round circle.. I like the square, but now I have to fix the old edit icon in orders.php to match.. I Switched back.. That didn't look so well, so went back to the round buttons by adding a white font color to the stack overlay and matching the size of the edit icon.

What's going to happen if admin ever jumps to version 6 of Font Awesome! My catalog side at 5 soon to be 6 and admin at 4, I have to keep 2 sets of reference tables handy... With everyone stuck at home, seems versions of everything is running wild right now... Thanks for your work on this mod.

Hello. I use a screen reader with Zencart and Edit Orders. Because of the current table layout, the address items are reading across for me instead of down - in other words, all of the name fields, followed by all of the address fields, etc.


There's a couple of ways to fix this. The prefered method would be to start using CSS for the layout of the page instead of a lot of nested tables. I realize this may be a larger task however.


The short-term fix would likely be putting each of the address types in its own single-column, vertical nested table. This should allow for proper display order while not changing the visuals.


I'm happy to work on this and submit a PR, but wanted to seek some guidance first. There are other accessibility things that could be done as well, including adding labels to the form fields.


Thanks for your work on the add-on. I appreciate the modern add-ons that use the override system and are much easier to maintain.

Quote:

---

Originally Posted by jsquared

Hello. I use a screen reader with Zencart and Edit Orders. Because of the current table layout, the address items are reading across for me instead of down - in other words, all of the name fields, followed by all of the address fields, etc.


There's a couple of ways to fix this. The prefered method would be to start using CSS for the layout of the page instead of a lot of nested tables. I realize this may be a larger task however.


The short-term fix would likely be putting each of the address types in its own single-column, vertical nested table. This should allow for proper display order while not changing the visuals.


I'm happy to work on this and submit a PR, but wanted to seek some guidance first. There are other accessibility things that could be done as well, including adding labels to the form fields.


Thanks for your work on the add-on. I appreciate the modern add-ons that use the override system and are much easier to maintain.

---

I understand the issue. That 'funky' address layout has been with Edit Orders since I 'inherited' the plugin.

Unfortunately, there's more to the change than simply re-formatting those address areas. There are other plugins (e.g. VAT for EU Countries) that make use of EO-issued notifications to add their extra fields to those address blocks.

I'll create an issue in EO's GitHub repository so that this request isn't lost; it'll be considered in a future EO version.

Issue created: https://github.com/lat9/edit_orders/issues/175

Ah, I see the hooks that are being used for other plugins so that indeed will take more work. I submitted a very small PR to add a role of table to the address table so at least screen readers will recognize the table as a data table and not presentation and let users move around it more easily.

Quote:

---

Originally Posted by lat9

Arggh, that's still not fixed in zc157? Anyway, the Installation :: Changes to zen_add_tax tab in the EO readme identifies the changes needed to the admin's /includes/functions/general.php that are required for EO to do its thing.

---

I don't know if its because I'm using a mac, or if it was left out of the 1.5.7 release... but I cannot locate any instructions on what needs to be modified in the file to activate the edit orders mod with the error: The store's zen_add_tax function must be updated to enable Edit Orders' use.


What needs modified below?

/** * Add tax to a products price
*/
function zen_add_tax($price, $tax, $force = false) {
global $currencies;


if (DISPLAY_PRICE_WITH_TAX_ADMIN == 'true' || $force) {
return zen_round($price, $currencies->currencies[DEFAULT_CURRENCY]['decimal_places']) + zen_calculate_tax($price, $tax);
} else {
return zen_round($price, $currencies->currencies[DEFAULT_CURRENCY]['decimal_places']);
}
}


/**

Quote:

---

Originally Posted by Carbonless

I don't know if its because I'm using a mac, or if it was left out of the 1.5.7 release... but I cannot locate any instructions on what needs to be modified in the file to activate the edit orders mod with the error: The store's zen_add_tax function must be updated to enable Edit Orders' use.


What needs modified below?

/** * Add tax to a products price
*/
function zen_add_tax($price, $tax, $force = false) {
global $currencies;


if (DISPLAY_PRICE_WITH_TAX_ADMIN == 'true' || $force) {
return zen_round($price, $currencies->currencies[DEFAULT_CURRENCY]['decimal_places']) + zen_calculate_tax($price, $tax);
} else {
return zen_round($price, $currencies->currencies[DEFAULT_CURRENCY]['decimal_places']);
}
}


/**

---

In EO's readme, click the Installation tab, then the Changes to zen_add_tax tab.

I tried installing this mod on my new 1.5.7 install on Friday evening (have it on my old 1.3.7h working fine for years) with the Westnminster-new template and it didn't like it at all. Followed all the steps in order, did the tax changes, etc. It didn't activate in the admin area, and then when I went to the storefront, no products were showing. Went through all the files again to make sure I hadn't missed one... nope, all there, So i uninstalled it and will hope that one day it actually becomes a built in feature as it is a very handy tool to have when clients want to add to their order.

Quote:

---

Originally Posted by lat9

In EO's readme, click the Installation tab, then the Changes to zen_add_tax tab.

---

From the downloads the zip did not contain a readme file... these instructions are what i'm looking for..

Quote:

---

Originally Posted by Carbonless

From the downloads the zip did not contain a readme file... these instructions are what i'm looking for..

---

Yes it does.

See the zip's /docs/edit_orders/readme.html file. Double-click to open it with your browser.


https://p176.p0.n0.cdn.getcloudapp.c...bf1e07f20bf629

Quote:

---

Originally Posted by Elemi

I tried installing this mod on my new 1.5.7 install on Friday evening (have it on my old 1.3.7h working fine for years) with the Westnminster-new template and it didn't like it at all. Followed all the steps in order, did the tax changes, etc. It didn't activate in the admin area, and then when I went to the storefront, no products were showing. Went through all the files again to make sure I hadn't missed one... nope, all there, So i uninstalled it and will hope that one day it actually becomes a built in feature as it is a very handy tool to have when clients want to add to their order.

---

"it didn't like it at all" doesn't tell me much. Were there debug-logs generated?

THANK YOU! for whatever reason, when i opened the zip, my mac wasnt uncompressing that file, but i could open it from within the zip...

That is what I was looking for.