FWIW, I don't recall any integration between Dual Pricing and Edit Orders. I have used DP many times, but EO only rarely but in my usage and maintaining of DP was never aware of any. Just my $0.02

jeking:

FWIW, I don't recall any integration between Dual Pricing and Edit Orders. I have used DP many times, but EO only rarely but in my usage and maintaining of DP was never aware of any. Just my $0.02
Thanks for the confirmation, @jeking!

lat9:

I've taken that look and still don't understand how the dual-pricing ever worked with EO (v4.3.5 or whatever). Looking at the 2.1.7a version, its changes to the /admin/includes/functions/functions_prices.php look "off" to me, specifically zen_get_products_special_price which is used by EO:

//get specials price or sale price
function zen_get_products_special_price($product_id, $specials_price_only=false) {
global $db;
$product = $db->Execute("select products_price, products_model, products_priced_by_attribute from " . TABLE_PRODUCTS . " where products_id = '" . (int)$product_id . "'");

if ($product->RecordCount() > 0) {

// $product_price = $product->fields['products_price'];
$product_price = zen_get_products_base_price($product_id);
} else {
return false;
}

[B]// Dual Pricing start
if ($product->RecordCount() > 0) {
// $product_price = $product->fields['products_price'];
$product_price = zen_get_products_base_price_w($product_id);
} else {
return false;
}
// Dual Pricing end[/B]

$specials = $db->Execute("select specials_new_products_price from " . TABLE_SPECIALS . " where products_id = '" . (int)$product_id . "' and status='1'");
if ($specials->RecordCount() > 0) {

// if ($product->fields['products_priced_by_attribute'] == 1) {
$special_price = $specials->fields['specials_new_products_price'];
} else {
$special_price = false;
}

> If the specified product exists, that section of code will never execute, since its condition is satisfied by the if/else clause the precedes it.
Must be getting tired eyes or something.

If the product exists, then the base code will set $products_price to the base price for the product and then procede to the next grouping of code which is now the dual pricing if statement. Again, if the product exists (which it does at this point because this section of code has been reached), then the price is "reset" to what dual pricing wants it to be. Yes, if the product didn't exist, then the else of that statement won't exist and $products_price has been potentially set to two different values, but the price setting would be reachable. 

Not sure why the choice to leave the base code in operation was made, but at least removing the dual pricing code would be easy to identify, right? :).

You're correct, @mc12345678; I'm having a bad day!

lat9:

You're correct, @mc12345678; I'm having a bad day!
Sorry to hear, if it helps any, take an inventory: let's see pulse, check. No loss of appendages today, check. Haven't poked my eyes out, check. Whew, could be worse. :)

Now I can't speak to the interoperability, but like so many of the other things posted, I've been reading along and that one caught my eye. Not to mention that when I've merged that file on other's servers I always ask myself, why was it done that way?

Anyways, bound to get better. :)

Just wondering...has anyone figured this out yet? It seems as though the processing just gets cut off each time. Would it be a memory problem?

jvdd:

Can't seem to anyone with the same problem as I do.

I can normally edit an order (quantity, add new product, comment, status, etc.) with no problem. Recently a HUGE order came in with over 400 items and can't be edited. Clicking update gives me a blank page that has the all the admin header, nav and footer and nothing else. I can add an item and it updates but not edit existing items.

debug_edit _orders_xxx.log ends with just this:

2019-05-31 15:03:13, Edit Orders entered (4.3.4) action (update_order)
Enabled Order Totals: ot_subtotal.php;ot_misc_cost.php;ot_group_pricing.php;ot_tax.php;ot_shipping.php;ot_total.php

2019-05-31 08:58:11, Edit Orders entered (4.3.4) action (edit)
Enabled Order Totals: ot_subtotal.php;ot_misc_cost.php;ot_group_pricing.php;ot_tax.php;ot_shipping.php;ot_total.php
getOrderInfo, on entry: Called by /…/…/…/…/edit_orders.php on line #705
Subtotal: (not set), Shipping: (not set), Shipping Tax: (not set), Tax: XXXX.XX, Total: XXXXX.XX, Tax Groups: {"15.0000":"1"}
$_SESSION['shipping']: (not set)

Order Totals
ot_subtotal. Text: $XX,XXX.XX, Value: XXXXX.XXXX
ot_tax. Text: $X,XXX.XX, Value: XXXX.XXXX
ot_shipping. Text: $0.00, Value: 0.0000
ot_total. Text: $XX,XXX.XX, Value: XXXXX.XXXX

Checking whether the product's attribute is a download, option_id = 14, value_id = 196: (1)
…..… LONG LIST……..

Checking order for virtual status. Order contains 453 unique products, 0 of those are virtual

getProductTaxes(15.0% HST)
{"products_tax_class_id":"1"}{"qty":2,"id":"653","name”:”Product Name”,”model”:”XXX-XX”,”tax":"15.0000","price”:”XX.XXXX”,”final_price”:”XX.XXXX”,”onetime_charges":"0.0000","products_priced_by_attribute":"1","product_is_free":"0","products_discount_type":"0","products_discount_type_from":"0","attributes":[{"option":"Color","value":"Amber","option_id":"1","value_id":"16","prefix":"+","price":"0.0000"}]}
getProductTaxes, returning 8.1.
…..… LONG LIST……..

Checking whether the product's attribute is a download, option_id = 14, value_id = 196: (1)
…..… LONG LIST……..

Checking order for virtual status. Order contains 453 unique products, 0 of those are virtual
calculateOrderShippingTax returning 0.
getOrderInfo, on exit:
{"code":"delivertocustomer","title":"Delivery","description":"Deliver to Customer","icon":"","enabled":true,"sort_order":"0","tax_class":"0","tax_basis":"Shipping"}
Subtotal: XXXXX.X, Shipping: 0, Shipping Tax: 0, Tax: XXXX.XX, Total: XXXXX.XX, Tax Groups: {"15.0% HST”:XXXX.XX}
$SESSION['shipping']: {"title":"Delivery (Shipping costs will be calculated for final invoice)","id":"delivertocustomer","cost":0}

Order Totals
ot_subtotal. Text: $XX,XXX.XX, Value: XXXXX.XXXX
ot_tax. Text: $X,XXX.XX, Value: XXXX.XXXX
ot_shipping. Text: $0.00, Value: 0.0000
ot_total. Text: $XX,XXX.XX, Value: XXXXX.XXXX

Checking whether the product's attribute is a download, option_id = 14, value_id = 196: (1)
…..… LONG LIST……..

Checking order for virtual status. Order contains 453 unique products, 0 of those are virtual

============================================================
= Creating display of Order Product #2311

Product Details:
{"qty":2,"id":"653","name”:”Product Name”,”model”:”XXX-XX,”tax":"15.0000","price”:”XX.XXXX”,”final_price”:”XX.XXXX”,”onetime_charges":"0.0000","products_priced_by_attribute":"1","product_is_free":"0","products_discount_type":"0","products_discount_type_from":"0","attributes":[{"option":"Color","value":"Amber","option_id":"1","value_id":"16","prefix":"+","price":"0.0000"}]}

Options ID #1
Product Attribute:
["2682"]
Options Info:
{"options":{"2219":"Assorted","2218":"Amber","2214":"Black","2216":"Blue","2215":"Green","2217":"Pink"},"name":"Color","type":"6","length":"32","size":"32","rows":"0"}

…..… LONG LIST……..

2019-05-31 08:58:54, Edit Orders entered (4.3.4) action (update_order)
Enabled Order Totals: ot_subtotal.php;ot_misc_cost.php;ot_group_pricing.php;ot_tax.php;ot_shipping.php;ot_total.php

> 
> In a successful edit case, it would have the regular product and details populated after that. Help?!
> 
> ZC 1.5.5f
> EO 4.3.4
> Group Pricing (per Item) 155
> Stock by Attributes" (version 1.5.3)
> Admin New Order 1.4
> Add Customers From Admin 2.0.9

@jvdd, a memory issue would be my guess. Check your store's /logs directory for some myDEBUG-adm-*.log file(s) on/around the time you attempted to update that order.

My greetings to the edit orders team.

I just changed of server my website with zen cart. These are the data of my instalation and server:
Zen Cart 1.5.1
Data Base: MySQL 5.5.30
Versión PHP: 5.3.3 (Zend: 2.3.0)

The problem is when I am adding products to an order already placed since the admin page, I get the next error shown in the log:

[19-Jun-2019 19:00:46] PHP Fatal error: 1364:Field 'products_prid' doesn't have a default value :: insert into
zen_orders_products_attributes set

The table zen_orders_products_attributes has the same parameters in my previous server, and never appeared that error. I checked it. "products_prid" had no default value and it still worked. So what is the cause of this error now? Any advice?

Thanks in advance.

armytags.com:

My greetings to the edit orders team.

I just changed of server my website with zen cart. These are the data of my instalation and server:
Zen Cart 1.5.1
Data Base: MySQL 5.5.30
Versión PHP: 5.3.3 (Zend: 2.3.0)

The problem is when I am adding products to an order already placed since the admin page, I get the next error shown in the log:

[19-Jun-2019 19:00:46] PHP Fatal error: 1364:Field 'products_prid' doesn't have a default value :: insert into
zen_orders_products_attributes set

The table zen_orders_products_attributes has the same parameters in my previous server, and never appeared that error. I checked it. "products_prid" had no default value and it still worked. So what is the cause of this error now? Any advice?

Thanks in advance.
You don't say which version of Edit Orders that you're using, but given that you're running on zc1.5.1 it's most likely a no-longer-supported version.

My best guess is that your new server has a more strict version of MySQL installed as that's where the fatal error you identified will come from.

My apologies:

Edit Orders 4.0.4.

"My best guess is that your new server has a more strict version of MySQL installed as that's where the fatal error you identified will come from."

Ok, and how can I solve it? upgrading edit orders?

Thanks for your answer.

Check your store's /logs directory for myDEBUG-adm-*.log files created on/about the time that the EO order-update failed. Post the contents of the file located using 'CODE' tags (the big # in the menu-bar when you're writing a post) and be sure to xxx-out the name of your admin sub-directory as I'm sure that it's part of the debug-log.

Ok. I think I got it. My apologies if I don't follow well your requests.

This was the first one (I' ll explain later) when I tried to add an item to an order:

[20-Jun-2019 03:37:33] PHP Fatal error:  1364:Field 'products_prid' doesn't have a default value :: insert into zen_orders_products set
                orders_id = 12094,
                products_id = 3,
                products_model = '',
                products_name = 'Order Pair of Silencers Black',
                products_price = '1.5000',
                final_price = '1.5',
                products_tax = '0',
                products_quantity = 1,
                                onetime_charges = 0; in /storage/xxxx/xxxx/xxxxxxx/public_html/xxxxx/includes/classes/db/mysql/query_factory.php on line 120

After doing some research, and reading some posts about that error 1364, I went to the DB with PHP admin, located the table "zen_orders_products_attributes", changed the default value of "products_prid" to NULL and tried again. Then it gave me an error message again, but this time I checked the order and the product was added to the order. I checked the myDEBUG log and found this message:

[20-Jun-2019 03:40:32] PHP Fatal error:  1364:Field 'products_prid' doesn't have a default value :: insert into zen_orders_products_attributes set
						orders_id = 12094,
						orders_products_id = 2731,
						products_options = 'Silenciadores',
						products_options_values = 'Negro',
						options_values_price = '0.0000',
                                                products_options_id = '2',
                                                products_options_values_id = '4',
						price_prefix = '',
                                                product_attribute_is_free = '0',
                                                products_attributes_weight = '0',
                                                products_attributes_weight_prefix = '',
                                                attributes_discounted = '0',
                                                attributes_price_base_included = '0',
                                                attributes_price_onetime = '0.0000',
                                                attributes_price_factor = '0.0000',
                                                attributes_price_factor_offset = '0.0000',
                                                attributes_price_factor_onetime = '0.0000',
                                                attributes_price_factor_onetime_offset = '0.0000',
                                                attributes_qty_prices = '',
                                                attributes_qty_prices_onetime = '',
                                                attributes_price_words = '0.0000',
                                                attributes_price_words_free = '0',
                                                attributes_price_letters = '0.0000',
                                                attributes_price_letters_free = '0'; in /xxxxxx/xxxx/xxx/xxxxxxx/public_html/xxxxx/includes/classes/db/mysql/query_factory.php on line 120

After receiving that message I changed the default value to NONE again, because I wasn't sure if that change could affect the normal placing of orders by the website. Should I change it back to some value to avoid this problem?
The options are: NONE, PERSONALIZED, NULL and CURRENT TIMESTAMP.

Thanks again for your answers.

@armytags.com, I'd thought that your posting of EO 4.0.4 was a typo as EO's current version is 4.4.0!

If you are you ***really ***running on Zen Cart 1.5.1 with EO 4.0.4, you'll need to update your Zen Cart so that you can have the benefit of all the changes and corrections over the past 7 years and then also update your Edit Orders installation to use the current version.

Although changing the database schema might get you past the symptom of the error you're experiencing, it's not addressing the root-cause of the issue (code should, and now does, set that required field) and has the possibility of causing follow-on issues when you do upgrade.

lat9:

@jvdd, a memory issue would be my guess. Check your store's /logs directory for some myDEBUG-adm-*.log file(s) on/around the time you attempted to update that order.

I also believe that may be the cause of the page/log not populating after clicking update. Thanks, I'll try to dig deeper.

If it was a memory issue, how do I increase it?

jvdd:

If it was a memory issue, how do I increase it?

Talk with your hosting company about this.

Hi,
I've been ill for the past couple of weeks with a cold/flu. Tonight I did some more investigating, and found that I had missed one small change in admin/includes/functions/extra_functions/edit_orders_functions.php.
Dual pricing requires the following change, which I had missed.

if (!$query->EOF) {
// Handle common fields
$retval = array_merge($retval, array(
'name' => $query->fields['products_name'],
'model' => $query->fields['products_model'],
'price' => $query->fields['products_price_w'],

I appreciate your time and help.

lat9:

@armytags.com, I'd thought that your posting of EO 4.0.4 was a typo as EO's current version is 4.4.0!

If you are you ***really ***running on Zen Cart 1.5.1 with EO 4.0.4, you'll need to update your Zen Cart so that you can have the benefit of all the changes and corrections over the past 7 years and then also update your Edit Orders installation to use the current version.

Although changing the database schema might get you past the symptom of the error you're experiencing, it's not addressing the root-cause of the issue (code should, and now does, set that required field) and has the possibility of causing follow-on issues when you do upgrade.

Yes, you are right. The thing is that the cart was working well with the old server for our modest needs, and I let me guide for the old saying: "if it is not broken, don't fix it". It is time for an update. Thanks for your time.

I'm currently having an issue with this plugin. The unit price is not updating when changes are made, yet the success message after hitting "update" still appears.
We updated from Zen Cart 1.5.1 to 1.5.6f a few days ago. We use PHP 7.3 and MySQL 5.7.26. I've looked at the edit_orders error log but was unable to notice anything too out of the ordinary. All other edits made through this plugin are working fine such as quanitity, status, and attributes/pricing. It just isn't letting me update a unit price of a product. Let me know if there is any other information you need. The error log is quite long but if anyone knows an easy way to make that viewable I can follow steps to upload it somewhere.

Paste error log contents into the tags. I can confirm this same behavior in 1.5.6b and EO 4.4.0. I can update shipping and it does stay at the new value. But items with or without attributes cannot have the price updated. Items that are on special have the price reverted to the non-special price once the order is saved after changing the price to something else. PHP 7.1.30. No error logs.

Which "Price Calculation Method" are each of you using?