The issue to which @Prabu refers will be seen on any site that uses multiple options with the same sort order when defining its products' attributes. I should have a correction available on GitHub within the next few days.
Printable View
The issue to which @Prabu refers will be seen on any site that uses multiple options with the same sort order when defining its products' attributes. I should have a correction available on GitHub within the next few days.
I've just submitted EO v4.2.3 to the plugins for review and will post back when it's available for download.
This version corrects the difference in attribute sorting between EO and the storefront (issue #49 in the plugin's GitHub repository).
Please check the readme; there's an additional edit required (up to ZC v1.5.5e anyway) to /includes/modules/attributes.php to make this work!
HiQuote:
Originally Posted by lat9
Thanks for the update. Now i've made some changes in YOUR_ADMIN/includes/classes/attributes.php using changes(Like upgraded version to 4.2.2) you did. But still no luck.
Same issues continues. Still option name and values were changed sort order after edit. Please see this small video http://recordit.co/W6RUrn8wjl
Please advice.
Did you also make the changes on the storefront? They're described in the readme under the Interaction with Other Modules tab; you need to make similar edits to your storefront /includes/modules/YOUR_TEMPLATE/attributes.php.Quote:
Originally Posted by Prabu
I realize now that I should have highlighted that within the change history.
HiQuote:
Originally Posted by lat9
Sorry I've not applied same changes in /includes/modules/YOUR_TEMPLATE/attributes.php file. But i can't find the changes of this file in github and readme file of the module. Could you please provide this /includes/modules/YOUR_TEMPLATE/attributes.php file alone?
Quote:
Originally Posted by lat9
The file's changes are not on GitHub, since EO supports multiple Zen Cart versions. The link in the first post I've quoted identifies the changes necessary to your template-override of the storefront attributes.php processing.Quote:
Originally Posted by Prabu
As mentioned before, that change is documented in the EO readme under the Interactions with Other Modules tab.
v4.2.3 is now available for download: https://www.zen-cart.com/downloads.php?do=file&id=1513Quote:
Originally Posted by lat9
hi,
when i look at ZC 1.5.5, it is supposedly compatible with php7.1.
has anyone tested the latest version of this module with php7.1?
the non-numeric arithmetic notices are now being reported in php7.1. see:
http://php.net/manual/en/migration71.other-changes.php
i'm curious before i consider upgrading various implementations of this module.
thanks.
I haven't (yet) validated on PHP 7.1; I'll get to that next week and get any updates required posted to the plugin's GitHub repo.Quote:
Originally Posted by carlwhat
This is a bug that might be too difficult to fix; I don't know, but I thought I'd report it anyhow so that at least people were aware of it.
If you have added fields to the orders_products table (as, for example, the dropship module does), edit orders will lose those fields. On an edit - even an edit as small as changing the order status - edit orders deletes and re-adds the orders_products table records. Since it is unaware that these additional fields exist, they are added back with their default values.
It's not a bug ... it's a feechur!:PQuote:
Originally Posted by swguy
Seriously, though, that's how the current versions of EO work. I've been working over the past couple of releases to migrate the separate extra_functions file into a class-based structure which, in turn, will lead to a new major version of EO that reuses any orders_products table entries, if possible.
Thanks Cindy. This is great news.
I'm using Zen Cart v1.5.1 and Edit Orders 4.1.4.
I get the following error in my log files:
PHP Warning: Invalid argument supplied for foreach() in my admin directory/includes/classes/mock_cart.php on line 151
I searched this thread but was unable to find any information. I can't seem to pin down when it's actually ocurring.
Just wondering if anyone has any tips for me to investigate. Thanks!
Perhaps the order was missing products? That's the line where the class iterates over the products in the order.
Thanks I'll go back and ensure I have products in the cart as that is likely what happened. Really appreciate the speedy reply!Quote:
Originally Posted by lat9
Suggestion on admin/includes/classes/editOrders.php
instead of
useCode:$ot_tax_class = constant ($ot_tax_class_name);
to prevent a PHP Warning in case the tax class doesn't exist.Code:$ot_tax_class = null;
if (defined($ot_tax_class_name)) {
$ot_tax_class = constant ($ot_tax_class_name);
}
Thanks @swguy; I've created an issue in the Edit Orders GitHub repository to track. Could you provide details regarding how to reproduce the error?Quote:
Originally Posted by swguy
1) Install Better Together and add a discount.
2) Run an order that gets this discount.
3) Edit that order.
Latest EO also has a bug which shows up editing an order which uses an order total module with recalculate taxes = Standard. You can dup with Group Pricing.
Original Order:
Sub-Total: $499.00
Shipping: $0.00
Group Discount: -$53.39
Tax 7.0%: $31.44
Total: $477.05
After EO:
Sub-Total: $499.00
Shipping: $0.00
Group Discount: -$53.04 (** error)
Tax 7.0%: $31.44
Total: $473.91 (** error)
@swguy, any idea where that trailing S on the sub-total is coming from? I'm guessing that that could be part of the issue.Quote:
Originally Posted by swguy
Sorry - that was copy & paste cruft. Fixed.
@swguy, would you enable EO debug, update that order and send me the generated EO log file via direct email?Quote:
Originally Posted by swguy
Just completed and sent.
... and I've replicated the issue locally. I'll post back when I've identified the root-cause.
Fix needed for virtual orders with no shipping address: such orders will show the message WARNING_ADDRESS_COUNTRY_NOT_FOUND
("Warning: One or more of the customer address fields contains a country name unknown to Zen Cart...")
edit_orders.php line ~ 677 change
toCode:if(!is_array($order->customer['country']) || !array_key_exists('id', $order->customer['country']) ||
!is_array($order->billing['country']) || !array_key_exists('id', $order->billing['country']) ||
!is_array($order->delivery['country']) || !array_key_exists('id', $order->delivery['country'])) {
$messageStack->add(WARNING_ADDRESS_COUNTRY_NOT_FOUND, 'warning');
}
Code:if(!is_array($order->customer['country']) || !array_key_exists('id', $order->customer['country']) ||
!is_array($order->billing['country']) || !array_key_exists('id', $order->billing['country'])) {
$messageStack->add(WARNING_ADDRESS_COUNTRY_NOT_FOUND, 'warning');
} else if ($order->delivery !== false && !empty($order->delivery['country'])) {
if (!is_array($order->delivery['country']) || !array_key_exists('id', $order->delivery['country'])) {
$messageStack->add(WARNING_ADDRESS_COUNTRY_NOT_FOUND, 'warning');
}
}
@swguy, what version of EO are you running? That message being displayed for virtual orders was corrected last year via this GitHub commit for EO 4.1.6.
The code segment that you refer to currently reads (edit_orders.php, line 623):
Code:if (!$eo->eoOrderIsVirtual ($order) &&
( !is_array($order->customer['country']) || !array_key_exists('id', $order->customer['country']) ||
!is_array($order->billing['country']) || !array_key_exists('id', $order->billing['country']) ||
!is_array($order->delivery['country']) || !array_key_exists('id', $order->delivery['country']) )) {
$messageStack->add(WARNING_ADDRESS_COUNTRY_NOT_FOUND, 'warning');
}
Ah ok thanks I have 4.1.5-beta2.
Current version is 4.2.3.Quote:
Originally Posted by swguy
I've just submitted v4.3.0 of Edit Orders to the Zen Cart plugins for review. That release contains changes associated with the following GitHub issues:
#50: Correct product.products_ordered calculation (thanks @siliconforks!).
#52: Correct PHP warning when an order-total doesn't include a "TAX_CLASS" setting.
#53: Additional notifiers for address-field insertions.
#54: Invalid value used in "Mock Cart" processing.
#55: Correct PHP "notify" issues.
#56: Correct order-total calculations when order-totals re-compute tax (e.g. group pricing), as reported by @swguy here.
#57: Properly report missing notifiers
I'll post back here once the download is available.
Note on #56: Users must remember to manually press the button.
Actually, it's changed from the prototype I sent you. The processing now has a checkbox field which, if set, causes the order's totals to be reset rather than a separate button. You can configure the default value for that checkbox field in Configuration->Edit Orders.Quote:
Originally Posted by swguy
:thumbsup:
That was quick! It's now available for download!Quote:
Originally Posted by lat9
Hi
Just updated to latest version. All works great (as expected!).
A wish list item for future versions/updates - not sure how hard it would be to incorporate - our site is UK based and we use 'state' (changed to 'County') as a dropdown which must be selected by a customer for UK Royal Mail shipping to be applied. Is it possible to have the 'state' field as a dropdown on the edit orders page so that we can ensure the correct state/county is selected?
Thanks
Mark www.johnwoodsmotorcare.co.uk/Shop | www.johnwoodsmotorcare.net
Sounds like a good idea; I've created an issue in Edit Orders' GitHub repository so that I don't lose the request!
@lat9 when i have some time, i will take a look at this new release, and compare it to all of the changes i have done over the years.Quote:
Originally Posted by lat9
without even thinking too much about it, i remember order total calculations, tax calculations (especially when using a different tax module) and changing line item quantities have been problematic. the last item caused me a bunch of grief, as the deletion of a record in orders_products and re-creation of a new record in that same table seems like overkill for changing the quantity from 2 to 3. and despite it being overkill, it overlooks the idea that a store owner could have additional fields in that table due to modifications, and that significant data gets lost. i am not sure if this version addresses that issue. but considering i do have clients using this add-on, and with your name on it, i will try and spend a bit of time on it.
if i find any issues that i think are of merit, lmk if you would prefer me to add something onto your github or if you would prefer to discuss them here.
best.
@carlwhat, this version still removes/recreates those orders_products and orders_products_attributes records. There are notifiers now issued by EO when it's preparing to remove and then re-instate those records, though, so an admin-level observer can keep those additional fields intact.
That said, I expect to have that processing changed in the next major release.
If you find any issues, please report them here since I think that this support thread has a wider audience.
FWIW, I've created this GitHub issue to track this request.Quote:
Originally Posted by lat9
ok... i have taken a cursory look, and i'll add a few comments and then i will move on.
first off, props to you @lat9 for taking this mess on! i appreciate all of the documentation you have added (not that i understand it..), and eventually this will possibly make more sense to me...
similar to you, i come from an old school background, learning old school procedural languages, before transitioning into OOP. unlike you, i have not picked it up nearly as well.... ;)
some of the things that i have been forced to focus on deal with totals, and how ot_* groups never add up.
let's look at ot_subtotal.
here is some code that i was forced to add:
i have ZERO confidence in the amount in ot_subtotal. in fact, i had to create a new function to recalculate the ot_subtotal! granted, i'm making assumptions based on my knowledge of the constants stored in the configuration table, but still...Code:function eo_update_order_subtotal($order_id, $product, $add = true) {
global $currencies, $db, $order;
// forget their stuff... just recalculate
$RunningSubTotal = 0;
$RunningTax = 0;
foreach($order->products as $products_details) {
$RunningSubTotal += $products_details["qty"] * $products_details["final_price"];
$RunningTax += (($products_details["tax"]/100) * ($products_details["qty"] * $products_details["final_price"]));
$TaxRate = $products_details["tax"]/100; // assume tax rate the same for all products
}
// Retrieve running subtotal
whether the ot_subtotal amount in your new version is correct now, i can not say.... but i swore off debugging this module! its just easier to recalculate it on my own.
with that said, i have made things work for my few ZC clients, without concern with how they will work for others.
another one of those things is taxes (you can see a little bit above). i make use of the ot_local_sales_tax which basically deals with 2 tax rates for orders. but more importantly, there is only ONE tax rate for any order. now, i am not sure how many ZC installs out there that have a different tax rate for different line items on the order, but i'm guessing they exist. i have non-ZC clients that is the case, although rare. mostly some items are for re-sale and not taxable and others are not. but there are no orders with 2 different non-zero rates.
if those exist, should ZC support those functions?
but i have never been able to get this add-on out of the box to calculate the tax correctly. especially when using a tax add-on module as the base ot_tax module does not work for my clients.
which is why i am forced to recalculate a tax rate above.
i hate the use of $GLOBALS. it would be great to eliminate all of those references.
ot_shipping, can include tax - although some times not.... depends on the store owners accountant (although they are no doubt interpreting tax law).... again, never got it to work.... and the same with ot_coupon. ot_coupon should reduce the tax amount of the order while a gift certificate should not.
i apologize. i suppose i am complaining more than doing anything constructive. if i get the energy to start with a vanilla install, add the ot_local_sales_tax module, then implement this edit_orders add-on and see how coupons and gift certificates work, how tax on shipping works, perhaps i can add more relevant information to the discussion.
at the end of the day, it just seems that there is too much reliant on numbers already stored in the DB as opposed to recalculating the numbers as they get done. whether that is the case in the new version i can not say... at least at this point.
again, i want to say that i appreciate all of your efforts, and i read all of your posts with interest as there is always the probability that i will learn something.
best.
Those pesky totals/taxes calculations were the reason for the addition of the additional configuration setting (and checkbox) in v4.3.0. When the checkbox is checked, EO's totals calculations are given a "restart" (i.e. setting the order's total and tax to 0).Quote:
Originally Posted by carlwhat
From what I remember from discussions with lhungil, the local_sales_tax plugin was always problematic for EO (it's even called out in the readme). Since I don't use that plugin with EO, I don't know if the "reset totals" processing will help or not.Quote:
Originally Posted by carlwhat
Actually, I'm going in the opposite direction. I find that (although it tends to uglify the code) using $GLOBALS helps me to remember that a value is being used and/or set outside the scope of a function or class. I agree that there's no need for the $GLOBALS within the procedural portions (i.e. /admin/edit_orders.php) of the processing!Quote:
Originally Posted by carlwhat
No apologies necessary, fresh ideas and discussion are always welcomed!Quote:
Originally Posted by carlwhat
Great mod!!
I was hoping I could get some direction with an issue I have. I have a field "products_description" that displays in orders.php, but after I modify the order, it no longer appears.
Thanks,
That behavior is due to the way that EO updates orders (currently), regenerating each product entry on each update.Quote:
Originally Posted by allmart
The current version of EO includes Zen Cart notifiers to let other code know that it's about to remove a product from (so you could grab its description with an observer-class module) and another when it's about to add a product to the order.
Thanks for the prompt reply and I apologize but it's over my head and don't understand.
No apologies necessary, here's a reply without the techno-babble ...Quote:
Originally Posted by allmart
In the current implementation of Edit Orders, each time you update an order, the order's products (and associated attributes) records are removed from the database and then (if appropriate) re-inserted. Edit Orders doesn't know that you've added the products_description field to each ordered-product's record so, when you update the order, that field is not included in the update and is set to the field's default value (for your case, most likely an empty string).
If you want/need that products_description value to "survive" an order-update using Edit Orders, you'll need some custom code developed.
Thanks again for your prompt reply. I was able to find the solution from another thread: https://www.zen-cart.com/showthread....ails-ect/page5, which worked perfectly. Sorry for not digging a little deeper before posting and thanks again for another great mod from you.
Cheers!
I've never installed an add on, but I'd love to try this one. Probably a dumb question, but is there a video that shows how to install this? Really would love to have the ability to edit orders... Thank you!
There's no video, but the installation might be really easy ... depending on whether you've installed other plugins in your store (which you say you haven't) and whether you're using the most recent Zen Cart version (v1.5.5e).Quote:
Originally Posted by cindygordon
How did you install your Zen Cart? Do you use an FTP (File Transfer Protocol) program to send files to your hosted site from your computer? Examples of these programs are WinSCP and FileZilla?
The answers to those questions will give me an idea of the best way to describe how to install the EO updates.
Thank you for the quick response! I have not installed other add ons, tho I would like to, but... same issue. Afraid to break it! Yes, I can use filezilla. If I recall, I think I actually set it up initially using godaddy's hosting interface, as there is a zencart icon in there. But I have logged in via filezilla to access files as well, that's no problem. I have set up other carts using ftp.Quote:
Originally Posted by lat9
Since you have no other changes to your cart, these instructions should get you going:
Download the plugin's zip-file from the Zen Cart downloads and unzip the Edit Orders plugin's zip-file into a directory on your computer. For the rest of these instructions, let's call that directory MyEditOrders.
- Rename the MyEditOrders/YOUR_ADMIN directory to match the name of your Zen Cart admin directory.
- Within that extracted file structure, create two subdirectories: MyEditOrders/includes/classes/saved and MyEditOrders/your-admin-directory/saved.
- Using FileZilla, download your current copy of /includes/classes/order.php into your local MyEditOrders/includes/classes/saved directory.
- Using FileZilla. download your current copy of /your-admin-directory/orders.php into your local MyEditOrders/your-admin-directory/saved directory.
Now that you have saved your current/backup copy of those two files, it's time to upload the Edit Orders files to your hosted site using FileZilla.
- Open FileZilla and log into your hosted site.
- On your FileZilla "Local site", navigate to your MyEditOrders/includes directory; on the "Remote site", navigate to your store's /includes directory.
- Upload the contents from the "Local" to the "Remote".
- On your FileZilla "Local site", navigate to your MyEditOrders/your-admin-directory; on the "Remote site", navigate to your store's /your-admin-directory.
- Upload the contents from the "Local" to the "Remote".
That should do it! Now, when you go to your admin's Customers->Orders, there's an additional link to "Edit Order". Happy editing!
Oh thank you!!! So excited, I will try this tonight, you rock!! :DQuote:
Originally Posted by lat9
well phooey, I tried it, and followed it very meticulously, but my site is down now. :(Quote:
Originally Posted by cindygordon
says "page isn't working"
Well, the ADMIN part of the site is down. The front end is still coming up, I can still browse, shop and checkout. Just can't get to the admin area. Or even the login page for it.
Check your logs directory for the most recent mydebug log(s).Quote:
Originally Posted by cindygordon
I see myDEBUG files there, but I don't really know what they mean.
Maybe I can try to do a fresh install in another directory? Is there a way I can transfer the products to the new store? And all of the user history? I do have access to the database. Ugh I'm sorry, this probably does not belong in this thread any longer. SOS for my site at this point.
Is there anyone who can help me get my site back up? Feeling very defeated, not sure what to do. I can offer to pay if needed.
Here is the debugging message: [19-Jul-2016 19:35:17 America/Phoenix] PHP Parse error: syntax error, unexpected T_STRING in /home/content/93/13964793/html/eureka/includes/languages/english/index.php on line 52
Interestingly, the path that it's specifying has an old filename. the site name "eureka" was renamed "rosswells" last spring.
That's weird, since that file isn't part of the Edit Orders distribution.Quote:
Originally Posted by cindygordon
The debug file is from July 2016 !!!!
There should be a newer one.
Quote:
Originally Posted by lat9
You're right!! I thought it was sorting by date, but it wasn't.
Here is the most recent one:
[12-Nov-2017 23:52:14 America/Phoenix] PHP Fatal error: Cannot redeclare class Vinos\VinosAutoload in /home/content/93/13964793/html/rosswells/includes/classes/VinosAutoload.php on line 19
Quote:
Originally Posted by Design75
@cindygordon granted me temporary FTP access to her site and I found a couple of things:Quote:
Originally Posted by cindygordon
- The storefront /includes directory had been mistakenly uploaded to the /admin/includes along with the /admin directory changes. I'll note that this is easy to do (I've only done it a gazillion times myself), especially when there are both storefront and admin changes associated with a plugin.
- The store's Zen Cart version is 1.5.1, which is not compatible with current versions of EO.:(
I simply removed the EO-related files and restored the (thankfully only 2) core-file overwrites to their ZC 1.5.1 version so she's back-in-business and now looking to upgrade prior to the EO installation.
Lat9, you are my hero, thank you SOOOOO much!!Quote:
Originally Posted by lat9
Obviously completely my fault, not a reflection on Edit Orders.
Looking forward to upgrading the cart and reinstalling EO properly. Thank you again!!
Hello,
I just discovered an issue with this great plugin that I was hoping for some guidance. I had to remove the shipping charge for one of my orders which is taxable and although it shows the shipping amount as zero, the invoice total still includes the original tax amount on shipping.
@allmart, Did you tick the "Recalculate Totals" box before updating?
i have the Reset Totals on Update ticked in configuration. see belowQuote:
Originally Posted by lat9
Attachment 17608
@allmart, please generate an EO debug-log for that order; I'll send you my direct email via PM.
- Navigate to your admin's Edit Orders page for the order in question.
- Make sure that the file /logs/edit_orders/debug_edit_orders_xx.log (where xx is the order-id) is deleted.
- Click the "Update" button on the EO screen.
- Grab that debug-log and email it to me for analysis.
Thanks, @allmart. I've created a tracking issue in EO's GitHub repository. It turns out that the issue surfaces when removing a shipping-cost (i.e. setting that value to 0) when that shipping is taxed.
I've just submitted EO v4.3.1 to the Zen Cart plugins for review; I'll post back here once it's available for download.
That version contains changes associated with the following issues, as identified on the plugin's GitHub repository:
#60: Correct totals' calculations when shipping is taxed and the store displays prices with tax.
#62: Correct multiple messages issued on initial plugin installation.
#63: Correct customer-information over-preparation.
#64: Correct totals' calculations when shipping is taxed, but none of the products are.
v4.3.1 is now available for download from the Zen Cart plugins: https://www.zen-cart.com/downloads.php?do=file&id=1513Quote:
Originally Posted by lat9
Just installed EO 4.3.1 on ZC 1.5.5e and starting to test. I'm not sure what should happen if a new product is added to the order wrt the shipping charge. Should the shipping charge be automatically updated? Or must it be manually updated? I'm using the Flat Rate shipping module and the EO recalculate totals checkbox is checked (default in config).
Also, if an order was created with another shipping module, store pickup in my case, should ALL other shipping methods that apply to that shipping zone be available in the shipping pull down menu? In my case, the Flat Rate module is not present.
Finally, I've noticed discussion of an edit orders log in other posts. How do you activate the edit orders logging process?
Thank you!
EO does not recalculate shipping; if the addition of a product to the order requires that shipping be updated, that's a manual process.Quote:
Originally Posted by Dave224
The shipping dropdown-selection "should" include all available shipping options.
To enable the EO debug, head over to your admin's Configuration->Edit Orders to change that setting. The debug creates file(s) in the /logs/edit_orders directory, one-per-order: debug_edit_orders_xx.log, where xx is the order number.
Thanks! When you said logging was a config item, I figured there was a problem in installation. All shipping modules now appearing in drop down.
Shipping tax is entered in percent (10.0 for 10%), correct?
What tax adjustments should EO make if a misc cost or a one time discount is applied and the order qualifies for tax?
Shipping tax is entered as a full value (as you indicated). EO makes no tax adjustments for misc-cost or one-time-discount additions, you've got to "bake" any tax-related updates into the addition/subtraction.Quote:
Originally Posted by Dave224
Hmmm. That's not what I'm seeing. I get a tax increase for a misc cost. No effect on tax for a one time discount. Can you suggest a place to look for the problem? ot_misc_cost??? OE somewhere?? ot_tax???
Thanks for your rapid responses!
I'll need to look at the innards ... tomorrow ... to give you an accurate answer.Quote:
Originally Posted by Dave224
Actually, the current code allows a lot of flexibility. The Misc Cost will accept positive and negative cost adjustments. When the cost adjustment is negative, a credit is applied, and the tax is reduced by the tax on the cost adjustment. For a positive cost adjustment, the total increases by the adjustment plus the tax on the adjustment. Neglecting quantity and group discounts, this behavior is the same as increasing or decreasing the price of a taxable product.
Unfortunately, the one-time discount adjustment always calculates a discount for both positive and negative adjustments. If the sign were honored, you could use one-time discount for after-tax (non-taxed) credits and after-tax costs.
Because I want the flexibility of both before and after tax credits and costs, I'm going to search for where the one-time discount input is processed and see if I can get it to honor the adjustment sign. Rewording some of the displayed text may also be helpful.
Dave
Well that was easy! Comment out one line in includes/modules/order_total/ot_onetime_discount.php. Enter a negative number for an after-tax discount; enter a positive number for an after-tax cost increase. Line 91 in EO v4.3.1 (shown below).
Text can be changed by overriding the file: includes/languages/english/modules/order_total/ot_onetime_discount.phpCode:// if($discount > 0) $discount = $discount * -1; edit to allow after-tax discount (-) or cost increase (+)
Do you see any problems with this change?
Dave
Dave, looks good. I'll consider perhaps an order-total customization switch (when it's enabled) to let store owners control what the onetime-discount does.
Thanks for the updates.
Update: GitHub issue created to track the change-request: https://github.com/lat9/edit_orders/issues/65
I'm now integrating the admin_new_order add-on with EO 4.3.1 and zc 155e. The add-on requires and uses EO. Attempting to add a new order from admin fails in a call to EO function eoOrderIsVirtual with a null $eo at edit_order_functions.php line 293. The full backtrace follows (edited to remove the beginning portion of paths):
A post in the admin_new_order support forum mentioned that the add-on works if the code that creates the order totals, including line 252 in new_order.php, is removed, the add-on appears to work. I'm not sure removing the code is the best approach. It seems to me that $eo needs to be established somewhere, but where? Perhaps in function zen_get_tax_locations in edit_orders_functions.php? Or in new_order.php? Should $eo be set to a new editOrders object?Quote:
[31-Jan-2018 16:25:36 America/New_York] PHP Fatal error: Call to a member function eoOrderIsVirtual() on null in admin/includes/functions/extra_functions/edit_orders_functions.php on line 293
[31-Jan-2018 16:25:36 America/New_York] PHP Stack trace:
[31-Jan-2018 16:25:36 America/New_York] PHP 1. {main}() .../admin/new_order.php:0
[31-Jan-2018 16:25:36 America/New_York] PHP 2. order_total->process() .../admin/new_order.php:252
[31-Jan-2018 16:25:36 America/New_York] PHP 3. ot_tax->process() .../includes/classes/order_total.php:68
[31-Jan-2018 16:25:36 America/New_York] PHP 4. zen_get_tax_locations() .../includes/modules/order_total/ot_tax.php:31
Also, are there other things that should be done if EO is entered through the order_totals path rather than at the beginning of edit_orders.php?
Thanks for any assistance you can provide.
Dave
Since the function zen_get_tax_locations doesn't normally exist on the admin side, EO creates its copy of those functions for its order-total processing to function ... and those EO-centric functions thus presume that the $eo class is loaded.
Let me ponder for a bit as to the best approach to handle this use-case.
Ah, coffee! Here's what I'll be using to update Edit Orders to correct this integration issue, adding the highlighted code-fragment:Quote:
Originally Posted by lat9
That will cause the remainder of that function-file to load only when on behalf of an Edit Orders request.Code:<?php
//
// +----------------------------------------------------------------------+
// |zen-cart Open Source E-commerce |
// +----------------------------------------------------------------------+
// | |
// | http://www.zen-cart.com/index.php |
// +----------------------------------------------------------------------+
// | This source file is subject to version 2.0 of the GPL license, |
// | that is bundled with this package in the file LICENSE, and is |
// | available through the world-wide-web at the following url: |
// | http://www.zen-cart.com/license/2_0.txt. |
// | If you did not receive a copy of the zen-cart license and are unable |
// | to obtain it through the world-wide-web, please send a note to |
// | license@zen-cart.com so we can mail you a copy immediately. |
// +----------------------------------------------------------------------+
// -----
// Since other plugins (like "Admin New Order") also provide some of these functions,
// continue this function-file "load" only if the current page-load is on
// behalf of "Edit Orders" processing.
//
if (basename($PHP_SELF) != FILENAME_EDIT_ORDERS) {
return;
}
// Include various Zen Cart functions (with any necessary changes for admin)
if(!function_exists('zen_get_country_id')) {
Well that didn't work. Order_total still wants to get to zen_get_tax_locations function. I'll need to see how this worked in zc 151. The function must have existed in admin then, maybe in EO 4.0.
In zc 151, the zen_get_tax_locations function is on the store side. Have there been any changes since v151 that prohibit admin from accessing functions on the store side? Looks like the (v151???) store-side version of these functions will need to be loaded if called from non-EO requests??? I'm tempted to establish $eo before call to order_total and see what happens. Ugh!!!
zen_get_tax_locations has never been available in an as-distributed Zen Cart installation. I'm not familiar with the "Admin New Order" plugin, so I don't know how it did its magic.Quote:
Originally Posted by Dave224
Hi lat9,
The Admin New Order plugin creates database entries for the order, orders_totals, and orders_status_history tables with an order that contains no products, and then redirects to edit_orders. I believe it does this since edit_orders does (or did) expect these tables to exist and uses them in editting orders created on the store_side.
As noted in earlier posts, new_order.php while creating the order totals, calls function zen_get_tax_locations. I believe that the author of the Admin New Order plugin intended that the store-side version of the function be used, but that version is not loaded in the admin. Your version of the function won't work because $eo has not been created. And even if the store-side version were loaded, edit_orders would fail because it tests for an existing loaded version of the function, and if found, exits with an error message.
so the only way I could figure to get the store-side version of the function loaded is to merge it into your version of the function, like so:
I did not include the protective code you posted earlier that prevents loading functions if called from other plugins. But, although the orders_total table was created without error in new_order.php, edit_orders.php didn't fare as well. Tax calculations were applied when they shouldn't, probably because I did something wrong in the merge. I think it should work, but I'm giving up on this approach.Code:if (function_exists ('zen_get_tax_locations')) {
trigger_error ('Pre-existing zen_get_tax_locations function detected.', E_USER_ERROR);
exit ();
} else {
function zen_get_tax_locations($store_country = -1, $store_zone = -1) {
if (basename($PHP_SELF) == FILENAME_EDIT_ORDERS) {
....contents of your version of the function
} else {
....contents of the store-side version of the function
}
}
}
Anyway, I'm back to commenting out the code in new_order.php that creates the orders_totals table. Edit orders appears to work. But I would really appreciate your opinion of any ramifications to EO if called without an orders_totals table in the database.
Thanks,
Dave
Dave, we're getting a tad off-topic here ... but, without those order-totals, neither EO nor the built-in Customers->Orders (or, for that fact, the storefront account_history_info page's) processing is going to display the order's details correctly.Quote:
Originally Posted by Dave224
FWIW, the author of the Admin New Order plugin was the previous author of EO ... so it doesn't surprise me that the handling is similar.
Sorry, let me clarify... I meant: "But I would really appreciate your opinion of any ramifications to EO if called from new_order.php without an orders_totals table entry in the database for the new order." I didn't mean to imply the table was not present.
Dave
Dave, EO's going to assume that, at a minimum, there's a sub_total and total entry (as there would be for an untaxed "virtual" product). It would take me a couple of hours to model and see with my own eyes what path EO will take if they're absent.Quote:
Originally Posted by Dave224
hey, i'm a little late to this party. and frankly i stay away from this necessary evil known as edit_orders; however i want to point something out that i saw here.
in the post a few above, this code will NOT do what i think was intended:
that code will ALWAYS return.Code:if (basename($PHP_SELF) != FILENAME_EDIT_ORDERS) {
return;
}
i think what you want is:
best.Code:if (basename($PHP_SELF, '.php') != FILENAME_EDIT_ORDERS) {
return;
}
Not true; FILENAME_EDIT_ORDERS is defined as 'edit_orders'.Quote:
Originally Posted by carlwhat
yes true. see:Quote:
Originally Posted by lat9
http://php.net/manual/en/function.basename.php
try for yourself:
test.php
Code:$PHP_SELF = $_SERVER['PHP_SELF'];
echo $PHP_SELF . '<----->';
echo basename($PHP_SELF) . '<----->';
echo basename($PHP_SELF, '.php') . '<---';
My apologies, @carlwhat, you're quite right. I'll get that update pushed to EO's repository.Quote:
Originally Posted by carlwhat
Providing EO with the minimum subtotal and total in the orders_total table appears to work well with my initial testing. I found a way to exclude ot_tax in the mix by removing ot_tax from the list of modules passed to order_totals in new_order.php, so no messing around with EO needed. But I wonder if the problem found by @carlwhat is the reason why merging the store-side get_zen_tax_locations with EO's version didn't work in my testing. I may try it again just to see what happens. But I'll be happy just the way it is (passing just ot_subtotal and ot_total in orders_total table to EO) if further testing works out well.
Further testing reveals a problem with the order total when subtotal, quantity discount, group discount, shipping, and tax ot_modules are exercised. Each line item is correct, but the total of each line item is too low. It's off by the tax on the sum of the discounts. Any suggestions would be appreciated.
Thanks!
Further testing show the problem appears only when quantity discount is used. If quantity discount is not applicable, and Group discount alone is exercised, the total is correct. If there is no tax, the total is correct. The problem appears only when quantity discount and tax is involved. I should add that everything is correct on the store side. Each line item and the total of all are correct if the same order is entered in the store.
A detailed example, with numbers and discounts would help me further diagnose the issue.Quote:
Originally Posted by Dave224
The following files are attached (the log file will be in the next post):
- debug_edit_orders_1222.txt (log file edited to change admin directory name and customer email address)
- Admin New Order Detail Page.jpg - screen shot of portion of orders details for order created with Admin New Order and Edit Orders with incorrect total
- Admin New Order after shipping update.jpg - screen shot of portion of edit orders screen after adding shipping charge and clicking update showing incorrect total
- Admin New Order after product add.jpg - screen shot of portion of edit orders screen after adding product with quantity discount
- Store order detail.jpg - screen shot of portion of store-side order confirmation page showing correct total
Zen Cart v155e, Quantity Discount v1.12.1, Edit Orders v4.3.1, Admin New Orders v1.4.1 (edited to delete ot_tax.php from list of order totals modules). The product has $1.00 off each item for 5 or more. The product cost is $6.00, on sale for 50% off or $3.00 per item. Tax rate is 6% on the product and shipping.
The subtotal, quantity discount, shipping, PA tax line items are all correct for the new order created in Admin New Order and Edit Orders, but the total line item is incorrect, being too low by an amount that equals the tax on the quantity discount ($0.30).
Attachment 17685
Attachment 17686
Attachment 17687
Attachment 17688
Here's the log file. See previous post.
Attachment 17689
Have you tried creating a "normal" order with the same products, totals, etc?