Edit Orders v4.0 Support Thread

Hello!

I tried to Google to find something relevant in this thread but I didn't... so please let me ask here.

I finally updated my ZC to 1.5.6c with EO v4.5.5 + MariaDB 10.3.23.
I also updated to utf8mb4 to fix the problems with Emojis.

But when editing an order (just a comment + email sent) I got this:

Field 'updated_by' doesn't have a default value

Indeed orders_status_history.updated_by doesn't accept NULL (or default) in the Datase and EO SQL statement doesn't seem to populate 'updated_by' when making updates.

#5 zen_db_perform() called at [/var/www/XXX/admin-XXX/edit_orders.php:310]
--> PHP Fatal error: 1364:Field 'updated_by' doesn't have a default value :: insert into orders_status_history (orders_id, orders_status_id, date_added, customer_notified, comments) values ('2477', '4', now(), '1', 'FOOBARFOOBAR') ==> (as called by) /var/www/XXX/admin-XXX/includes/functions/database.php on line 51 <== in /var/www/lespoisplumes.fr_v1.5.6c/includes/classes/db/mysql/query_factory.php on line 171.

Did I forget to update an important file or is it the expected behavior, and it only worked so far because MySQL (before MariaDB) was less strict?

I just did this to allow empty/NULL values and it works again.

ALTER TABLE `orders_status_history` CHANGE `updated_by` `updated_by` VARCHAR(45) CHARACTER SET utf8mb4 COLLATE utf8mb4_general_ci NULL;

Julien

generikz:

Hello!

I tried to Google to find something relevant in this thread but I didn't... so please let me ask here.

I finally updated my ZC to 1.5.6c with EO v4.5.5 + MariaDB 10.3.23.
I also updated to utf8mb4 to fix the problems with Emojis.

But when editing an order (just a comment + email sent) I got this:

Field 'updated_by' doesn't have a default value

Indeed orders_status_history.updated_by doesn't accept NULL (or default) in the Datase and EO SQL statement doesn't seem to populate 'updated_by' when making updates.

#5 zen_db_perform() called at [/var/www/XXX/admin-XXX/edit_orders.php:310]
--> PHP Fatal error: 1364:Field 'updated_by' doesn't have a default value :: insert into orders_status_history (orders_id, orders_status_id, date_added, customer_notified, comments) values ('2477', '4', now(), '1', 'FOOBARFOOBAR') ==> (as called by) /var/www/XXX/admin-XXX/includes/functions/database.php on line 51 <== in /var/www/lespoisplumes.fr_v1.5.6c/includes/classes/db/mysql/query_factory.php on line 171.

> 
> Did I forget to update an important file or is it the expected behavior, and it only worked so far because MySQL (before MariaDB) was less strict?
> 
> I just did this to allow empty/NULL values and it works again.
> 
> ```
ALTER TABLE `orders_status_history` CHANGE `updated_by` `updated_by` VARCHAR(45) CHARACTER SET utf8mb4 COLLATE utf8mb4_general_ci NULL;

Julien
What's the site's history? In the 'original' osh_updated_by plugin and for the zc156+ upgrade, the SQL used to create the updated_by field has a default value:

ALTER TABLE orders_status_history ADD updated_by varchar(45) NOT NULL default '';

lat9:

What's the site's history?

Oh it's an old dinosaur getting a transfusion now and then!

v1.5.6c [2021-01-07 15:05:13] (Version Update 1.5.5->1.5.6c)
v1.5.5e [2017-03-19 17:11:48] (Version Update 1.5.4->1.5.5e)
v1.5.4 [2017-03-19 17:11:44] (Version Update 1.5.3->1.5.4)
v1.5.3 [2017-03-19 17:11:40] (Version Update 1.5.2->1.5.3)
v1.5.2 [2017-03-19 17:11:34] (Version Update 1.5.1->1.5.2)
v1.5.1 [2017-03-19 17:11:28] (Version Update 1.5.0->1.5.1)
v1.5.0 [2017-03-19 17:11:20] (Version Update 1.3.9->1.5.0)
v1.3.9h [2010-11-04 22:35:18] (Version Update 1.3.9g->1.3.9h)
v1.3.9g [2010-10-01 12:17:54] (Version Update 1.3.9f->1.3.9g)
v1.3.9f [2010-09-10 23:38:40] (Version Update 1.3.8->1.3.9f)
v1.3.8 [2009-07-04 20:22:05] (Fresh Installation)

I guess the database structure is obsolete and somehow ZC SQL updates missed that one while MySQL would fail gracefully when MariaDB just won't now?

Julien

generikz:

Oh it's an old dinosaur getting a transfusion now and then!

I guess the database structure is obsolete and somehow ZC SQL updates missed that one while MySQL would fail gracefully when MariaDB just won't now?

Julien
Nope, I'm guessing that one of your now-obsolete plugins made that change to the database, but I'm having a hard time determining where the issue was sourced.

Hello,

I'm trying to understand what is the reason behind edit orders removing the product and attributes from the database and assigning new ids? what is the reason for this behaver, is it to maintain sort order?

jacobsh:

Hello,

I'm trying to understand what is the reason behind edit orders removing the product and attributes from the database and assigning new ids? what is the reason for this behaver, is it to maintain sort order?

wow. 1 post and already jumping into some nitty-gritty.... :thumbsup:

i have no good answers on that one; the current maintainer of the plugin has done an excellent job of straightening this plugin and making it workable. why the original author choose to do it that way is another question.... but addressing that issue seems to be a massive amount of refactoring and the potential for bugs is great...

there is a plugin to address some extra fields you may have added to the orders_products table here:

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

i do not remember if i did something as well to address the attributes for products.

best.

I'd asked the previous maintainer the same question and, unfortunately, didn't bookmark his response.

As @carlwhat indicated, the re-structuring of EO to not regenerate those orders_products_id is going to be a fairly complicated exercise, since there are plugins that currently 'plug into' EO to manage the product variants ... and keeping downward compatibility is one of my 'hot buttons'.

thank you both of you! @carlwhat i'm working with zencart the whole day :smile:

I've just submitted v4.5.6 of Edit Orders for the Zen Cart moderators' review; I'll post back here when it's available for download.

 This release contains changes associated with the following GitHub issues:

#182: Refactor to ensure that the price-calculation method is defined.
#183: Use foreach instead of for (where possible) in loops processing the updated order-totals.
#186: Correct missing constants in HTML email messages when updating orders (zc157+ interoperation).

Note: Subsequent releases of Edit Orders will support Zen Cart v1.5.7 (with applied bugfixes) and later only.

lat9:

I've just submitted v4.5.6 of Edit Orders for the Zen Cart moderators' review; I'll post back here when it's available for download.

 This release contains changes associated with the following GitHub issues:

#182: Refactor to ensure that the price-calculation method is defined.
#183: Use foreach instead of for (where possible) in loops processing the updated order-totals.
#186: Correct missing constants in HTML email messages when updating orders (zc157+ interoperation).

Note: Subsequent releases of Edit Orders will support Zen Cart v1.5.7 (with applied bugfixes) and later only.
Now available for download: https://www.zen-cart.com/downloads.php?do=file&id=1513

Sorry for the churn, but I've just submitted v4.5.7 of EO for the Zen Cart moderators' review and will post back here when it's available for download.

This release corrects GitHub issue #188 (Adding a product with a TEXT attribute causes a MySQL error).

"Sorry for the churn"...lol.

Your the last individual here who has to apologize for anything lat9. While some of the options with SuperOrders were nice to have, and a couple needed, most of us could not do without EditOrders which you have graciously stepped in and kept up for us. We need a link to donate to you.

Approved.

swguy:

Approved.
Thanks, @swguy, for the quick turn-around.

I'm looking to make changes to the way that EO renders the customer/billing/shipping addresses in support of screen readers. See this GitHub issue for details and progress: https://github.com/lat9/edit_orders/issues/175

Making that change will result in the dropping of the EDIT_ORDERS_ADDITIONAL_ADDRESS_ROWS notification, which allows customizations to add additional content to those addresses.

Other than ***VAT4EU ***(https://www.zen-cart.com/downloads.php?do=file&id=2164), I'm not aware of other plugins that make use of that notification. I'm willing to work with authors of other plugins that use that notification, just post back here with details.

If the desire is to keep the same visual format, I'm sure a way could be figured out to make it all work for screen readers while maintaining that functionality. I need to dive a bit further into the plugin to see how it is working.

jsquared:

If the desire is to keep the same visual format, I'm sure a way could be figured out to make it all work for screen readers while maintaining that functionality. I need to dive a bit further into the plugin to see how it is working.
Thanks for that extra set of eyes, @jsquared!

After editing the math getting messed , can you please help us please . zencart version is 157c and edit order version is 457
the total is not sum of others ( no code added , default edit order running)

diptimoy:

After editing the math getting messed , can you please help us please . zencart version is 157c and edit order version is 457
the total is not sum of others ( no code added , default edit order running)

is your processing and handling fee taxable? edit orders says that it is not, while your sales tax module says that it is.

(175 x 1.08125) + 5.25 = 194.47

180.25 * .08125 = 14.65

diptimoy:

After editing the math getting messed , can you please help us please . zencart version is 157c and edit order version is 457
the total is not sum of others ( no code added , default edit order running)

Where did that "Processing and Handling Fee" order-total come from? I'm guessing that it's the culprit in the miscalculation.