That "Reset Totals" checkbox is a way to kick EO in the arse and have it "do-over" the totals. Sometimes the order_total/order_tax element(s) in the base orders table get out-of-sync with the values recorded in the orders_total table.
Printable View
That "Reset Totals" checkbox is a way to kick EO in the arse and have it "do-over" the totals. Sometimes the order_total/order_tax element(s) in the base orders table get out-of-sync with the values recorded in the orders_total table.
so there is no harm with having it always checked, and ignoring it when not checked? ie the only penalty is a little processing time and perhaps some DB hits?Quote:
Originally Posted by lat9
i have tracked down this bug to ot_tax. ot_tax is hard coded into EO. if you have a store that does NOT make use of the ot_tax orders total module, and you do not have the checkbox checked, you will get PHP notices as such:
i believe i am using the latest version with an alpha or beta designation (call me a radical), and 1499 corresponds to here:Code:[08:10:05 US/Great_State_of_Los_Angeles] PHP Notice: Undefined offset: 2 in /admin/includes/functions/extra_functions/edit_orders_functions.php on line 1499
[08:10:05 US/Great_State_of_Los_Angeles] PHP Notice: Trying to access array offset on value of type null in /admin/includes/functions/extra_functions/edit_orders_functions.php on line 1499
[08:10:05 US/Great_State_of_Los_Angeles] PHP Notice: Undefined offset: 2 in /admin/includes/functions/extra_functions/edit_orders_functions.php on line 1500
[08:10:05 US/Great_State_of_Los_Angeles] PHP Notice: Trying to access array offset on value of type null in /admin/includes/functions/extra_functions/edit_orders_functions.php on line 1500
[08:10:05 US/Great_State_of_Los_Angeles] PHP Notice: Undefined offset: 2 in /admin/includes/functions/extra_functions/edit_orders_functions.php on line 1505
[08:10:05 US/Great_State_of_Los_Angeles] PHP Notice: Trying to access array offset on value of type null in /admin/includes/functions/extra_functions/edit_orders_functions.php on line 1505
[08:10:05 US/Great_State_of_Los_Angeles] PHP Notice: Undefined offset: 2 in /admin/includes/functions/extra_functions/edit_orders_functions.php on line 1509
[08:10:05 US/Great_State_of_Los_Angeles] PHP Notice: Trying to access array offset on value of type null in /admin/includes/functions/extra_functions/edit_orders_functions.php on line 1509
https://github.com/lat9/edit_orders/...ions.php#L1499
personally, i am not a fan of hard coding anything (despite doing it all the time); but if i can override that checkbox to have it always checked using your provided observer with no ill effect, that's fine with me.
thanks in advance!
@carlwhat, I'll give that a look-see over the next week.
Update: What is it that's removing element [2] from that array without re-indexing?
:thumbsup:Quote:
Originally Posted by lat9
with regards to your update, i suppose that is the million $ question.
i have yet to dig in any further than i have already posted.
Do I get the million or do I have to pay when you get that answer?:PQuote:
Originally Posted by carlwhat
P.S. You're a radical!
gee thanks.Quote:
Originally Posted by lat9
this is the code that is removing the index:
in fact it is not removing it, it is re-arranging it.PHP Code:// Process the order totals
$order_totals = $GLOBALS['order_total_modules']->process();
it looks like the problem resides elsewhere; in the tax module that the client uses.
thanks for the help.
guess the million will now have to go unclaimed!
:P
@carlwhat, I believe that I can provide a work-around for the issue you've identified (order_totals not re-indexed after removal). I could use a foreach loop instead of a for-loop to prevent those 'missing indices' notices.Quote:
Originally Posted by carlwhat
@lat9, thanks for the help in pinpointing where the problem might be as well as thinking about solutions. i want to be clear about what is happening, prior to you making a determination as to what you may want to do.Quote:
Originally Posted by lat9
i think i was incorrect in my expression of what the tax module did in my last post. it is not a rearrangement as i suggested; it removes its element (in all observed cases, that was element [2]), and then adds a new one to the end of the array. i have now modified that code to use the removed index if removed, or just add it to the end of the array if not removed (loving the new coalesce operator in php7+). that seems to have addressed the problem with no ill consequences that i have seen.
in addition, i am still unclear if one can safely remove the reset_totals checkbox from user choice with no ill consequences. i initially did that approach (using the observer which again addressed the issue), and again with no ill consequences. i understand a bit of a processing penalty; but i can easily live with that.
i also think there are shops out there that may experience this problem, that if it can be solved within EO, it would be of value. not every shop will have the IT techno expertise to figure this out, and as php progresses i think some of these notices could turn into warnings, then errors, etc.
i can test your solution later today if you would like. i would hesitate for you to commit to anything un-tested; and unless you are so inclined to set up your env to mimic this behavior, i could easily do it later today.
best.
@lat9, tested and seems to work.
seems like a good approach.
thanks.
... and thanks back to you for the validation. I thought that I'd gone through and changed those for() loops to foreach() wherever there wasn't a possible need to update a loop-element. I'll go through EO's processing to make sure that I've 'hit' all those!Quote:
Originally Posted by carlwhat