Edit Orders v4.0 Support Thread

I've posted about this issue last year and it's still present because this is only the second time I had to do this with a huge order and it doesn't work:

Editing a large order (100+ items) results in a blank page after updating, meaning the edit order module is missing. Just the admin screen menu, etc. with a blank page.
All editing functions work with a smaller order. Has anyone else encountered this problem? Is it a memory issue and if so, is it a zc or server problem? How can I resolve this?

EO 4.3.4
ZC 1.5.5f

Thanks.

jvdd:

I've posted about this issue last year and it's still present because this is only the second time I had to do this with a huge order and it doesn't work:

Editing a large order (100+ items) results in a blank page after updating, meaning the edit order module is missing. Just the admin screen menu, etc. with a blank page.
All editing functions work with a smaller order. Has anyone else encountered this problem? Is it a memory issue and if so, is it a zc or server problem? How can I resolve this?

EO 4.3.4
ZC 1.5.5f

Thanks.
There should be a myDEBUG-adm-*.log file present in your store's /logs directory that identifies what happened. I'm guessing an out-of-memory condition, but the log will tell the story.

Remember that the admin-level logs contain your site's admin-directory name, so be sure to xxx that name out prior to posting the contents of the log.

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

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

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.

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!

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.

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:

<!-- 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!

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

shahadat9612:

Another quick fix to include in the next version:

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

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.

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.

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>'; } ?> </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>'; } ?> </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:

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

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.