edit orders 4.1
zencart 1.5.1
mrrp module installed
installed successfully message was displayed
no error logs
Regards
Phil
Quote:
Originally Posted by lhungil
Printable View
edit orders 4.1
zencart 1.5.1
mrrp module installed
installed successfully message was displayed
no error logs
Regards
Phil
Quote:
Originally Posted by lhungil
Effectively I fount, inside log folder, some mydebug.log files, with the following maessage:Quote:
Originally Posted by lhungil
(/..../myadmin/includes/auto_loaders/config.eo.php): Permission denied in /..../myadmin/includes/init_includes/init_eo_config.php on line 84
The file /.../myadmin/includes/auto_loaders/config.eo.php has been manually deleted after installation.
Something wrong during the installation ?
Thans for help
MSRP does make some changes to the the Zen Cart pricing functions. At a quick glance it makes the changes on the catalog side to functions_prices.php, but not the admin side of the same file (Edit Orders uses the Zen Cart functions on the admin side). Can you try removing MSRP and see what happens?
Also can you tell us which Order Total Modules you have installed + enabled? "admin" -> "modules" -> "order total".
Example List of Modules:
Gift Certificates sort_order: 840
Low Order Fee sort_order: 400
Shipping sort_order: 200
Sub-Total sort_order: 100
Tax sort_order: 300
Total sort_order: 999
All this indicates is the user your webserver runs as did not have permission to delete the file, so the installation script could not delete the file.Quote:
Originally Posted by nannid
If you go back through the installation and login to your admin before uploading and then click on "Admin Home" right after uploading, you should see some messages at the top of the browser. If the only message indicates you need to manually delete this file, you can probably safely delete the indicated file. If there are other messages you should address those first.
Can you also answer the questions posted here.
In the previous installation, I deleted by hands the file config.eo.php
After your reply, I recharged that file declaring 777 all autoloader folder and subfolder. In this case the message was: Edit Orders v4.1 install completed!
But the problem persists.
I have to said that I have excluded the sending mail, in my installation.
(The objective is simply to provide the admin to make quotation).
The other caractheristics, as per your require, are:
What version of Edit Orders? Edit Orders 4.1
What version of Zen Cart? 1.5.1
What order total modules do you have installed?
COD Fee ot_cod_fee
Discount Coupon ot_coupon
Group Discount ot_group_pricing 290
Gift Certificates ot_gv
Low Order Fee ot_loworderfee
Shipping ot_shipping
Sub-Total ot_subtotal 100
Tax ot_tax 300
Total ot_total 999
What order total modules do you have enabled?
Group Discount ot_group_pricing 290
Sub-Total ot_subtotal 100
Tax ot_tax 300
Total ot_total 999
What message did you see at the top of the screen after installing Edit Orders and clicking "Admin Home"?
Edit Orders v4.1 install completed!
What if any Zen Cart error logs exist (/cache/ in 1.5.0 and /logs/ in 1.5.1 - use FTP to look)?
None
What other modifications (plugins, add-ons, etc) have been done?
None
Thank You nannid and Phil Lomas for your feedback. I believe I have now narrowed down the cause.
Can you please try the following fix and let me know if it works in your environments?
- Remove all products from the affected order (or cancel the order). Make sure the Order Total is Zero (the bug should cause this to be true).
- Make the code change listed below.
- Add the products back to your order (or to a new order).
Edit "/admin/includes/functions/extra_functions/edit_orders_functions.php" as follows:
Starting at line 1134 replace:
With the following code:Code:// Remove order totals already present in the order
$module_list = explode(';', (str_replace('.php', '', MODULE_ORDER_TOTAL_INSTALLED)));
$order_totals = eo_get_order_total_by_order($oID);
if($order_totals !== null) {
foreach($order_totals as $class => $total) {
$keys = array_keys($module_list, $class);
foreach($keys as $key) {
if($key != 'ot_local_sales_taxes') unset($module_list[$key]);
}
}
}
Code:// Remove order totals already present in the order
$module_list = explode(';', (str_replace('.php', '', MODULE_ORDER_TOTAL_INSTALLED)));
$order_totals = eo_get_order_total_by_order($oID);
if($order_totals !== null) {
foreach($order_totals as $class => $total) {
if($class == 'ot_local_sales_taxes') continue;
$keys = array_keys($module_list, $class);
foreach($keys as $key) {
unset($module_list[$key]);
}
}
}
The module only sends an email when the status has changed (or a comment is added) and "Notify Customer" is set to "Email". You may want to consider just changing the default to either "No Email" or "Hide" depending upon if you want your customer's to be able to see the comments in their order history.Quote:
Originally Posted by nannid
Most of my clients have an additional "order status" called "quoted" or "freight quoted". When they are done editing an order they simply change the status (and type in an appropriate statement in the comments) - and select Notify Customer by Email. The stock Zen Cart email (modified for my client's of course) will then notify the customer their order has been "Quoted". I typically recommend my clients also follow up with a phone call when possible to ensures the customer knows they need to contact the store to finish placing the order.
But in the end, it is all about what works for you :)
Solved !!!
I applied your suggested modifications and your sw runs correctly.
I tried both with an admin order and with an order produced by the front end.
Many thanks for your fundamental help.
Hi Lungil
Yes works for me too.
Thanks
Phil
Hi,
A different problem, with a brand new installation. When I click the "edit" icon or button for any order, I get this error:
===Server error
The website encountered an error while retrieving SITE/ADMIN/edit_orders.php?page=1&oID=(order id #)&action=edit. It may be down for maintenance or configured incorrectly.
HTTP Error 500 (Internal Server Error): An unexpected condition was encountered while the server was attempting to fulfill the request.===
I followed the install readme to a t with 1 exception: I did *not* overwite ZC's icon_edit.gif in ADMIN/images. I actually uninstalled and re-installed just to make sure, with the same result both times. So far I have *not* modified any of the EO code.
Answers to questions asked of other users with problems:
What version of Edit Orders?
4.1 (release dated April 12, 2013)
What version of Zen Cart?
1.5.1
What order total modules do you have installed/enabled?
INSTALLED BUT NOT ENABLED (came with ZC):
COD Fee ot_cod_fee
Discount Coupon ot_coupon
Group Discount ot_group_pricing
Low Order Fee ot_loworderfee
INSTALLED & ENABLED:
Gift Certificates ot_gv
Shipping ot_shipping
Sub-Total ot_subtotal
Tax ot_tax
Discount Coupon ot_taxcloud_coupon
Exemption Certificates ot_taxcloud_exemption
Total ot_total
What message did you see at the top of the screen after installing Edit Orders and clicking "Admin Home"?
Edit Orders v4.1 install completed!
What if any Zen Cart error logs exist (/cache/ in 1.5.0 and /logs/ in 1.5.1 - use FTP to look)?
None related to EO
What other modifications (plugins, add-ons, etc) have been done? (zip file names)
ceon_uri_mapping_4.4.1_for_zc
ckeditor-for-zencart
column_layout_grid_2_3_1
confirm-email-double-entry
Contact Us - Add Subject
EasyPopulate-4.0-master
Frontpage_Slideshow.v2.0.2
new-msrp-display_for_1.5
Return Authorization 3.0.0
taxcloud_1.5.2_for_zc_151
USPS v15 Ratev4 2013_0127 R2013_0327
(Bolded those that have anything to do with orders, but none appear to have modified any of the files changed by EO.)
At this time I have not installed ty_package_tracker yet, but it's on my list of possibilities.
I'll appreciate any insight/assistance. Thank you!
Magz
and you know this for sure because????????? After clicking the edit button you SHOULD see SOMETHING in the error logs.. To alleviate any possibility that it's NOT an Edit Orders error, please clear your error logs. Then try again to do what you were doing when you got the issue.. and check the logs again.. I'm pretty sure something will be there.. Please post that error log..Quote:
Originally Posted by magz
Hi DivaVocals - I looked at all logs generated on 4/30 after I re-installed EO, and none mentioned EO. But I did what you said, and here's the error log that got generated after I clicked the edit icon again (in addition to the server error 500 mentioned earlier):
PHP Fatal error: require_once() [<a href='function.require'>function.require</a>]: Failed opening required 'includes/modules/TaxCloud/func.taxcloud.php' (include_path='.:/usr/lib/php5') in /SITE/includes/classes/order.php on line 21
Line 21 in that particular order.php is indeed: require_once DIR_WS_MODULES . 'TaxCloud/func.taxcloud.php';
func.taxcloud.php is present in the location specified above.
I hope it's an easy fix. I'd really like to use your plugin, it sounds very promising...
Thank you!
Magz
The error message wouldn't say "Hey this is an EDIT ORDERS error" persay:laugh:.. it would give you an indication as to where the issue might be coming from. Which is why I questioned you dismissing the error logs as not relevant..Quote:
Originally Posted by magz
That said.. as you can see this is not an issue cause by Edit Order, but by your Tax Cloud add-on. So you are going to have to troubleshoot what's going on with your Tax Cloud add-on.. You will need to post your issue on the Tax Cloud support thread.. suggest you check your install before posting your question.. are you SURE that there is a file called func.taxcloud.php in your includes/modules/TaxCloud/ folder?? (the SHOP side not the ADMIN side..
Wish I could help, but the issue is NOT with Edit Orders..
You have an error with tax cloud in the orders class file. That's what the error message is telling you, it's not finding the required file from the orders class file. And since edit orders also has to do with orders you need to fix one to fix the other since taxes are involved with orders. It could be a case-sensitive error. In php TaxCloud is not the same as taxcloud or Taxcloud. I would check that first and make sure the directory that func.taxcloud.php is located is spelled that way.
Quote:
Originally Posted by magz
And I just did a quick check.. Tax Cloud actually has NO FILES in common with Edit Orders.. so something is amiss in one or both of your installations of these modules..Quote:
Originally Posted by DivaVocals
I suggest installing ONE at a time and test test test to ensure one is working before installing the other.. Would suggest rolling back to the state your store was before installing EITHER modules.. (not just do an uninstall I mean restore your store and DB to a state it was BEFORE you installed these modules) Then start by installing Edit Orders.. Make SURE it works before you move on to install Tax Cloud.. Either way the issue is NOT Edit Orders, but something amiss with regards to your Tax Cloud add-on.. You will need to post questions relating to Tax Cloud issues in the support thread for Tax Cloud..
Thanks for your pointers, DivaVocals and lankeeyankee. Will research/test/retest/post/etc., and report back IF I find anything relevant to EO in the process...
Thanks for your many contributions as well!
Magz
Mystery solved thanks to RCwebdev. It was indeed an issue with TaxCloud code, so for anyone trying to use both TC 1.5.2 and EO 4.1 (with ZC 1.5.1), to fix the error change the following code in YOUR-SITE/includes/classes/order.php (on whatever line # your error log gives you).
Find:
require_once DIR_WS_MODULES . 'TaxCloud/func.taxcloud.php';
and try replacing it with:
require_once(DIR_FS_CATALOG . DIR_WS_MODULES . 'TaxCloud/func.taxcloud.php');
For me this solved the problem - no more server error 500 or error logs mentioned in my previous post, and now I can finally use Edit Orders 4.1!
Want to make sure it's clear.. this error has NOTHING to do with Edit Orders.. Edit Orders only helps to uncover an error created by Tax Cloud.. this would be an issue regardless as to whether or not you have Edit Orders installed.. It's purely a Tax Cloud issue..Quote:
Originally Posted by magz
Hi lhungil - thank you, this code change did fix the subtotal issue in EO 4.1 for me, as well. However, it seems to be causing another issue with Ty Package Tracker 3.1.3. I posted on TPT thread about this, but have been directed here.Quote:
Originally Posted by lhungil
With version 1 of the above code, TPT works great. With version 2, however, after the tracking # is added to an order, the email sent to the customer includes a list of all shippers, even those that are turned off. I only have USPS turned on, and only the USPS tracking # field appears on my Edit Orders page, but here's the list customers get in their emails (the bolded part is the only one that should appear):
====
Your FedEx Tracking ID is
Click here to track your package.
If the above link does not work, copy the following URL address and paste it
into your Web browser.
http://www.fedex.com/Tracking?action...&tracknumbers=
It may take up to 24 hours for the tracking information to appear on the
website.
Your UPS Tracking ID is
Click here to track your package.
If the above link does not work, copy the following URL address and paste it
into your Web browser.
http://wwwapps.ups.com/WebTracking/p...nquiryNumber1=
It may take up to 24 hours for the tracking information to appear on the
website.
Your USPS Tracking ID is 9000000000000000000000
Click here to track your package.
If the above link does not work, copy the following URL address and paste it
into your Web browser.
https://tools.usps.com/go/TrackConfirmAction!input.action?tLabels=#9000000000000000000000
It may take up to 24 hours for the tracking information to appear on the
website.
Your Tracking ID is
Click here to track your package.
If the above link does not work, copy the following URL address and paste it
into your Web browser.
It may take up to 24 hours for the tracking information to appear on the
website.
Your Tracking ID is
Click here to track your package.
If the above link does not work, copy the following URL address and paste it
into your Web browser.
It may take up to 24 hours for the tracking information to appear on the
website.
====
I noticed your snippet mentions ot_local_sales_taxes - I don't have that module installed, I use TaxCloud instead. No idea if that could be related to the issue, what are your thoughts? Can the snippet be adjusted to work with TaxCloud, or another one added someplace to fix the TPT issue? (I'm not a programmer, wouldn't know where to start.)
Thank you!
Magz
It's not that I don't want to help.. it's that I CAN'T help you with a problem that is not caused by a defect with the Ty Package Tracker code.. I directed you here because the issue you are having is not with the Ty Package Tracker code, but rather with the code you used to modify the Edit Order files which has caused the issue you are reporting.. The Edit Orders code is the cause.. not the Ty Package Tracker code.. This support thread is where you got the code from. lhungil wrote the code and is probably the BEST person to direct you as to how to fix it.. so this is where you must come for the solution..Quote:
Originally Posted by magz
I understand, DivaVocals, no hard feelings. :smile: I hope lhungil can help.... I'm impressed with how much effort so many different people are putting into the core program and all the plugins, not to mention all the different fixes, and I understand no one can predict all possible interactions between the pieces created by so many different programmers.
I salute you all, and thank you!
Magz
Update to my earlier post - I just discovered that all shippers are listed in the email to customer even when NO tracking number is uploaded, just a comment is made OR order status is changed. On the other hand, when the Append Comments checkbox is UNchecked, no shippers are listed even when a tracking number was added. (The last one might be the expected behavior for all I know, I'm just describing my observations; perhaps shipper info is regarded as part of the comment.)
Hope this can help find a solution...
Thanks,
Magz
Not necessarily a problem, but as outlined in the readme.html some modules may need to be modified to correctly load from the admin side of Zen Cart (many make assumptions about paths and GLOBAL variables).Quote:
Originally Posted by magz
If you are using a 3rd party tax software to calculate and store tax records... You may want to check with TaxCloud about how to update the stored order and tax information in their database... Otherwise you could end up with records on your end which do not match the records stored by TaxCloud. I'd expect there to be a special call needed to update order and tax records sent to (and stored by) any 3rd party tax software.
This is unrelated to the code changes mentioned earlier.Quote:
Originally Posted by magz
The code for TPT was for the most part left alone between version 4.0 and 4.1 (I do not use TPT so have been relying on others for feedback). Thank You for finding something and reporting. The changes will most likely need to be made to "/admin/edit_orders.php" as this is where the integration code is. When I get back from vacation (no place with stable internet here) and get some time, I'll take a deeper look at the TPT integration code.Quote:
Originally Posted by magz
Thanks lhungil - enjoy your vacation and return safely!
zencart 1.5.1
ty tracker v3.1.3
edit Orders 4.1
I am puzzled by the behavior or edit orders. The subtotal amount becomes $0.00 after changing and updating the quantity in the quantity box for a item. No matter what you do or how many times you update the quantity for one or more items on the list, the subtotal is still $0.00 instead reflecting the updated total. Why is that? Is there something wrong with the installation?
:(
Please read the previous post in this thread regarding how to fix this behavior.Quote:
Originally Posted by twi
Thank you very much. I read the previous post concerning this problem and it fixed the error.
The only difference is that I make the changes to the file mentioned to the source files to be uploaded, then do a clean install using the edit orders installation instructions. (Note: I already have ty package tracker installed. no file merging was performed)
:clap:
Thank you all very much for the hard work involved in making all this possible.
Hi twi - glad you have both EO and TyPT - I wonder if you're having the same problem now with TyPT (after you updated the EO code to fix $0 subtotal) that I've been having - when you edit an order in any way AND notify the customer, is the customer's email listing all 5 shippers (even those that you have not enabled and even when you don't add any tracking #)? Oh, and are you using TaxCloud as your sales tax plugin?
Thanks,
Magz
No problem and I'm glad to have another verification of the fix working :)
Now just to look into the Ty Tracker integration code in Edit Orders 4.1 and make some needed fixes to the emails...
Can I send both of you ("magz" and "twi") some BETA code with the changes for Ty Tracker (when I make them) so we can more fully test any changes before releasing a new version of Edit Orders?
I'll be looking out for the fix and update our sites as well.
I haven't notice this yet. I am still waiting for the email to come in to see if I have the same problem and keep you posted concerning the shipping emails.
Sure lhungil, I'll gladly be your beta tester. ;-) Thanks for working on this, hope you had a wonderful vacation... ~magz
I have a clean install of v1.5.1 and ty tracker then edit orders just now.Quote:
Originally Posted by magz
I got an order confirmation as customer and one as store admin. but so far still no tracking email.
I have updated the order and inserted comments, and an ups tracking number for the purpose and update it all at once.
will keep you posted.
all three functions worked. I will have to see it tracking or update email comes in with the same problem you have.
Default Re: Edit Orders v4.1 Released
No problem and I'm glad to have another verification of the fix working :)
Now just to look into the Ty Tracker integration code in Edit Orders 4.1 and make some needed fixes to the emails...
Can I send both of you ("magz" and "twi") some BETA code with the changes for Ty Tracker (when I make them) so we can more fully test any changes before releasing a new version of Edit Orders? Last edited by lhungil; 15 May 2013 at 06:16 PM. Reason: clarification
Yes you can. I will be glad to test it since my installs are all brand new (new test store for update) and not a live store.
Maybe a bit off topic. by the way. I just noticed the UPS and Usps etc shipping modules are not in the shipping modules area like it was in 1.3.9h. do I have to download and install these separately?Quote:
Originally Posted by magz
WAAAAAAY off topic.. and yes.. (you should have asked this question seperately or searched the plugins first..)Quote:
Originally Posted by twi
Yes. It is confirmed that I know have the same problem.Quote:
Originally Posted by magz
Thanks twi...I'm sure lhungil will be able to help us... ~magzQuote:
Originally Posted by twi
I would like to thank everyone that have been supporting us in this thread, i have resolved one issue but have not found my other fix, When editing my order if it has an attribute option i cannot select one :(
I am using
zen-cart-v1.5.1zen-cart-v1.5.1
ceon_uri_mapping_4.4.1_for_zc
stock_by_attribute
Most of this work i have done by myself and not an experience programmer but knowledgeable :)
edit_orders_4.1
From the INSTALLATION section of the Readme.
followed shortly byQuote:
AUTO INSTALLER!! No more external SQL files needed to install/upgrade Edit Orders.. Yep that's right.. The Edit Orders install/upgrade is easier than ever!!! Whether you are upgrading from a previous Super Orders install or doing a vanilla Edit Orders install, the newauto installer has got you covered. Please note: Uninstall is not automated. So to uninstall you will still need to use an external SQL file.
Quote:
DO NOT RUN OLDER VERSIONS OF THE INSTALL/UPGRADE SQL FILES when installing/upgrading!!!!!! Doing so will cause issues with your Edit Orders v4.0 install.
In upgrading to Edit Orders 4.1 from Edit Orders 4.04, and with SuperOrders 4.0.5 already installed, I understand that the two (2) orders.php in 2_Modified_Core_Files are not to be uploaded.
Also that admin\includes\functions\extra_functions\common_orders_functions.php is identical to that in EO 4.04, both essentially blank files and deprecated, so it makes no real difference whether the EO 4.1 version of this file is uploaded or not.
However, it is not clear from the instructions whether the EO 4.04 edit_orders_uninstall.sql file needs to be run, and all or any EO 4.04 files need to be removed, prior to uploading the EO 4.1 fileset.
Clarity appreciated.
ps if EO 4.1 is about to revised, the Readme could do with less hype and clearer instructions.
Not sure what you mean by "hype", but the current readme included information based on several thingsQuote:
Originally Posted by dw08gm
- Community suggestions/contributions to the readme
- Frequently asked questions in the support thread
Inclusion of these elements in the readme have lead to fewer issues except in cases when the install instructions aren't followed.. Call it hype if you like, but it stopped most questions around these two areas of concern (the install SQL files). that said if you have more specific ideas for further improvements they are welcome.. (as they were before.. hence the current readme and it's contents)
From the README under "Installation" tab: DO NOT RUN THE UNINSTALL SQL when upgrading!!!!!!.Quote:
Originally Posted by dw08gm
Step 5 of the "Installation" tab addresses what needs to be done when "upgrading" from earlier versions (mostly 3.x/4.x).
These still hold true for EO 4.1 even though the readme may in some places still reference the "current version" as Edit Orders 4.0. I'm thinking about removing all version number references (other then the title at the top and the credits page) - as I feel they are confusing - and not needed. Thoughts?
Any constructive contribution to the readme (and related files) is welcome! I would not expect a new public release for at least a month - possibly longer... So definitely some time for people to contribute with specific changes :)Quote:
Originally Posted by dw08gm
with regards to the uninstall SQL the readme text is as follows:Quote:
Originally Posted by lhungil
May seem like "hype" but it was a FREQUENT issue that came up after the introduction of the auto-installer, and the community members who contributed suggestions to the readme contents felt it was important to highlight this.. Given some of the support question being fielded I agreed and included the suggested edits..Quote:
DO NOT RUN THE UNINSTALL SQL when upgrading..
Let me repeat..
DO NOT RUN THE UNINSTALL SQL when upgrading!!!!!!
DO NOT RUN OLDER VERSIONS OF THE INSTALL/UPGRADE SQL FILES when installing/upgrading!!!!!! Doing so will cause issues with your Edit Orders v4.0 install.
Sometimes some level of "hype" is needed to make sure something is communicated clearly to all levels of users.. Given that the inclusion of this text reduced the number of questions in this area, and the intent behind it's inclusion, it appears to have had the desired effect..
Agree.. some of this version specific text was included because of the transformation from prior versions of Edit Orders (v1.x-3.x) and wanting to make sure that end users understood that this was indeed a very different version of Edit Orders.. They've probably outlived their usefulness..Quote:
Originally Posted by lhungil
**nods in agreement**:yes:Quote:
Originally Posted by lhungil
Not sure what exactly you are asking / stating... Here is a screen shot from a clean ZC 1.5.1 + EO 4.1 installation showing an order with attributes. You will note there are selectable dropdown options, checkboxes, and editable text fields. After making any needed changes to the attributes and clicking "update" the changes are saved (and the order updated).Quote:
Originally Posted by gromit1977
Attachment 12504
Please read the first page of the readme... In particular make note of the "Potential Future Enhancements" and "Known Issues".Quote:
Originally Posted by gromit1977
Because in the readme the upgrade only refers to EO 4.0.3, not EO 4.0.4, it was unclear to me whether upgrading from EO 4.0.4 to EO 4.1 could be considered a "vanilla" install. And "upgrading from a previous Super Orders install" left me wondering.Quote:
Originally Posted by lhungil
FWIW Hype is what I expect from salespeople. Clear and concise is what I expect from installation instructions.
Happy to help in tidying the readme, although I only have the next two weeks to do so.
Right.. just typos and leftovers from previous versions of the readme.. The "upgrading from a previous Super Orders install" text is leftover from the v3.0 changes.. I expect it will all be cleaned up in the next release.. I trust you are all straight now though.. right??Quote:
Originally Posted by dw08gm
Right.. respectfully I don't agree.. I don't see any part of the readme as "hype".. I see it as relaying an important change to the Edit Orders makeup which generated a TON of "where is the install SQL" questions.. The "hype" sorta squashed those questions.. It was a suggestion of a community member, and given that it stopped stopped some of the most frequently asked questions from being asked, then I'd say the "hype" was effective especially for novice shopowners (for whom these instructions were largely crafted to cover)..Quote:
Originally Posted by dw08gm
That said, if you can provide constructive/explicit suggestions for the readme, then just as the suggestions of other community members are reflected in the current readme, then perhaps some of your suggestions could also be included..
Thank you for your reply i have attached some screen shots for you
when adding an item you can see that step three does not allow me to select option :(
Attachment 12507
once saved the attribute change to - :
Attachment 12508
i have fixed the pricing error from an earlier post #106
You will want to check your debug / error logs to make sure no errors are being generated by the code on your site. If there are any errors you will want to address them first (I did see one missing language key - do not remember which one and your site is down for maintenance now).Quote:
Originally Posted by gromit1977
The cause could be a large number of things. Thoughts off the top of my head: something not quite right with the installation / merging of EO 4.1 + "Stock by Attributes" into your Zen Cart installation, corrupted / Not correctly imported attributes and / or product options, the product option type does not allow selection (such as file, readonly, and custom types), or a compatibility issue with "Stock by Attributes" (as mentioned in the readme).
If you end up adding the needed code to allow the correct handling of various aspects of "Stock by Attributes", please post the code changes :)
I seem to have found another problem with attributes, I've searched the thread but can't see anyone else has noticed it.
If I have an order with two different products, which both have the same set of attributes available, but none selected (for example with checkboxes) and then check one box on the first product but leave all on the second product unchecked. When I then save the order, it checks the boxes for that attribute for all subsequent items in the order. It's not just the way it's displayed, it's actually modified the order itself.
I'm now looking in to it to see if I can see what's going on - does anyone have any ideas?
Sorry - I realise I didn't really provide much information about my set up.
Zen Cart 1.5.1 (Upgraded over time from 1.2.0 or something)
Edit Orders 4.1 (Installed successfully)
PHP 5.3.21
Other mods:
VAT-mod (doesn't affect Edit Order files)
Initial investigation shows that the attribute form fields seem to overwrite each other (for example if one uses just text fields). I am thinking that an extra layer to the Attributes form element array needs to be added which either corresponds to the order product id or the order row number.
Ok - I think I have come up with a solution to this now. I have done as I suggested and added an extra dimension to the front of the id array which is the $orders_products_id value.
For example - Line 903 in edit_orders.php
becomesCode:echo '<textarea class="attribsTextarea" name="id[' .$optionID[$j] . '][value]" rows="' . $optionInfo['rows'] .
'" cols="' . $optionInfo['size'] . '" id="attrib-' .
$optionID[$j] . '" >' . $text . '</textarea>' . "\n";
and then, when this array is read from $_POST on line 276Code:echo '<textarea class="attribsTextarea" name="id['.$orders_products_id.'][' . $optionID[$j] . '][value]" rows="' . $optionInfo['rows'] .
'" cols="' . $optionInfo['size'] . '" id="attrib-' .
$optionID[$j] . '" >' . $text . '</textarea>' . "\n";
becomesCode:zen_db_prepare_input($_POST['id']),
I have had a quick (but not thorough!) test of this, and it seems to work - can anyone see any reasons as to why this might cause problems elsewhere?Code:zen_db_prepare_input($_POST['id'][$orders_products_id]),
I now seem to have a problem in that the Sub-Total and hence, the Total never update, and they can't be modified manually, so the order totals cannot be changed, only by adding additional total lines (but then these get removed again upon updating the order). Is this expected functionality, have I missed something or is this a bug?
Cheers,
Scott
Sorry for the quadruple post, but I think I have solved the above issues, and possibly fixed some bugs along the way. The sub total was updating, it was just me not noticing. There was a problem with the VAT calculation though, it didn't seem to be including the onetime charge VAT. This was due to a stray semi-colon, took me a while to notice that one!
In edit_orders_functions.php around line 818 in eo_get_product_taxes()
has an extra ; on the first line, and should instead beCode:$taxAdd = zen_calculate_tax($product['final_price'], $product['tax']) * $product['qty'];
+ zen_round(zen_calculate_tax($product['onetime_charges'], $product['tax']), $decimals);
I then found that there was a problem with the subtotal not being calculated correctly when adding and removing a onetime charge. This may have been a known issue, I think I have fixed it, but wanted to see if anyone knows what knock on effects this might have.Code:$taxAdd = zen_calculate_tax($product['final_price'], $product['tax']) * $product['qty']
+ zen_round(zen_calculate_tax($product['onetime_charges'], $product['tax']), $decimals);
Also in edit_orders_functions.php around line 747 in eo_update_order_subtotal()
I have wrapped the $shown_price calculation in a check for whether prices are displayed with tax, and removed the tax calculation accordingly so it is now:
Code:if (DISPLAY_PRICE_WITH_TAX == 'true') {
$shown_price = zen_round(zen_add_tax($product['final_price'], $product['tax']), $decimals) * $product['qty'];
$shown_price += zen_round(zen_add_tax($product['onetime_charges'], $product['tax']), $decimals);
} else {
$shown_price = zen_round($product['final_price'], $decimals) * $product['qty'];
$shown_price += zen_round($product['onetime_charges'], $decimals);
}
The next problem that I have found is that I seem to be able to add lines of order total amounts with any name and value, but these do not get added onto the order total, and then get removed upon update. Is this what this point in the readme is referring to?
- Add option to disable automatic order total calculations. This would allow the use of lines which do not have a corresponding order_total.
Cheers
Good eye. I originally planned to wrap the attributes inside the "product_updates" array. So instead of just "id[...]" you would have product_updates[orders_products_id][attr][...]. This requires making sure things are changed for all the product_option_types contained in the switch statement starting on line 845 'switch($optionInfo['type']) {'.Quote:
Originally Posted by Gadgit
And then before the new product is created for the order we pull "$attrs = $product_update[attr]; unset($product_update[attr]);" and instead of "zen_db_prepare_input($_POST['id'])" you have "$attrs". Doing it this way instead would lend itself to readability :)
This would also mitigate most of the problems with EO 4.1 not generating uprids for products with attributes (and probably fix another known bug). I'd still like a future version to actually generate uprids, but at least everything would be more functional with this change. Thanks for catching this!
After a more indepth look, this appears to be caused by some differences between Zen Cart 1.5.0 and 1.5.1. Most of the code was originally targeted to Zen Cart 1.5.0 (I remember seeing some reported bugs with VAT / Tax calculation on the forums for ZC 1.5.0). Guess these changes were missed :blush: Take a look at the differences found in 'includes/order.php' (especially the cart() function) between 1.5.0 and 1.5.1... I would highly recommend adjusting your changes to the code to match the code in ZC 1.5.1 (the version you have installed) of orders.php. This will keep things consistent w/ the customer side of the cart.Quote:
Originally Posted by Gadgit
Do you think we can get away with just changing to the updated ZC 1.5.1 code (both in edit_orders.php and edit_orders_functions)? Or will this throw off people running 1.5.0 (and require us to include ZC version checks w/ different running code)?
Exactly the point the README is referring to. In EO 4.1 (unline previous versions), it is not sufficient to simple type in an arbitrary name / value. In EO 4.1 a dropdown was added to "select the order total module" (installed, enabled, not already in use for the order). This solved a number of problems present in EO 4.0 with regards to invalid order_total lines in the database.Quote:
Originally Posted by Gadgit
The more I think about changing EO to add the option to add arbitrary order total lines, the more I dislike the idea (it sets off some warning bells in my head). I really have not seen any compelling need for such a feature... Allowing such behavior will always break automatic calculations... Doing so may encourage people to edit closed / delivered orders (not desirable for many reasons)... Etc...
If you need additional lines for some reason I would recommend adding / enabling an appropriate "order total module". If you find / feel a custom order total line is absolutely necessary... Please let me know what the purpose of such a line would be and if compelling we could look at including an optional order total module to fit the need (and of course if you want to contribute such an order total module - it would be appreciated). :)
I agree, this would be a better way of doing it, as you say, it would provide better readability and encapsulation.Quote:
Originally Posted by lhungil
Yeah - I did this with my modifications, although I haven't fully tested yet.Quote:
Originally Posted by lhungil
I'm not sure why you need the uprids, as far as I can see at the moment, with these fixes everything seems to work pretty well. Which known issue are you referring to here?Quote:
Originally Posted by lhungil
Not sure exactly which file you mean here - my /ADMINAREA/orders.php and /admin/includes/classes/order.php show the same across 1.5.0 and 1.5.1. The only changes appear to be in /includes/classes/order.php and these are tax related, and I've got the latest version in my cart, so should be ok.Quote:
Originally Posted by lhungil
Hmm, I'm not sure about this, although as far as I can see, the onetime price tax calculations in 1.5.0 (line 530 in /includes/classes/order.php) were just wrong so, surely using the correct ones from 1.5.1 couldn't hurt (I assume these are the ones you mean).Quote:
Originally Posted by lhungil
Probably not really, I just thought that this may be something that my client would like to be able to do perhaps for example if they want to subtract a 'goodwill gesture' type discount, or an additional fee for arbitrary order additions (not likely).Quote:
Originally Posted by lhungil
I think then, perhaps without that functionality then the field should be hidden if there are no options available in the select. This shouldn't be too hard to do.
I'm happy to do a bit of testing/dev on the module if you like, would perhaps be easier to PM?
Cheers again
Without the uprids some catalog side functionality (such as the links to products) will not contain the extra data which is required by some other plugins... More of a detail to be consistent with the catalog side of the cart (for example what a customer sees on the order history pages)...Quote:
Originally Posted by Gadgit
I was referring to issues when a product is added more than once w/ different attributes to the order (this fix should fix that one as well).
Similar to my thoughts... (I typically say '/includes/' for stuff on the catalog side and '/admin/includes' when on the admin side, so guessed right).Quote:
Originally Posted by Gadgit
Yeah, I originally thought about the extra line as well for those two purposes... But then remembered they can always just modify the product / shipping prices and add a comment to the order status (history)... But I could see the possibility of a "dummy" order total module or two...Quote:
Originally Posted by Gadgit
I also agree with your thought of hiding these fields when no additional order total lines are available. As you can tell EO 4.1 still needs to add some UI touches :) (for example javascript to toggle the display of the shipping module selection when the "shipping" is selected for addition).
My PM inbox is mostly full here... But the help is definitely welcome as is another pair of eyes :)Quote:
Originally Posted by Gadgit
Can't help a LICK with coding :laugh:, but you know as always I am happy to help you with testing and user docs.. So if you need another "set of eyes" from this perspective ya know how to find me.. :smile:Quote:
Originally Posted by lhungil
I got lost when they started talking about uprids.
Uh huh..:laugh: So I'm sticking with what I DO know.. :laugh:Quote:
Originally Posted by dw08gm
Updated Installation Page in readme.
cheers
Found some other potential issues related to the tax calculations. As a temporary work around (until I can dig into the needed changes more extensively) you will also want to make sure DISPLAY_PRICE_WITH_TAX and DISPLAY_PRICE_WITH_TAX_ADMIN are both set to the same value ('True' or 'False').Quote:
Originally Posted by Gadgit
Should I hold off on QA testing and wait for an update?? Also it would help if you could give me (at high level) the test case/scenario I should be running in order to confirm the fast and furious changes coming.. :laugh:Quote:
Originally Posted by lhungil
Also I am going to test a bug Ajeh reported to me a while back that I could NOT address because.. well because I am not a PHP developer that's why..:laugh:
If I discover that this old bug is still an issue, is NOW the time to raise/report this??
Ah yes - I did notice that it uses the define for the front end, I wasn't sure whether that was by design or not. I have got the ADMIN set to true, and the front end one set to False, since that's the way I need it set up. It doesn't seem to cause any major issues though..Quote:
Originally Posted by lhungil
This is the reason your calculations was off for VAT and taxes. Certain functions in the admin are hard coded to use DISPLAY_PRICE_WITH_TAX_ADMIN and the order total code and modules (we call these to calculate totals) are hard coded to use DISPLAY_PRICE_WITH_TAX. So if both values are not the same, the calculations get off :PQuote:
Originally Posted by Gadgit
I do not want to modify the Zen Cart functions directly as it will impact many other pages... So we will probably need to duplicate some of the code from the catalog side functions... And when the values are not the same on both sides add a warning to the top of the page in the admin to let users know calculations shown in Edit Orders are based upon the catalog side settings.
The "quick" fix for most people running EO 4.1 to address the calculations being off is make sure both these settings are the same.
ZC1.5.1
TY PACKAGE 3.1.3
EDIT ORDERS 4.4.1-B1
SUPER ORDERS 4.XXX (latest VERSION)
RECOVER CART SALES 1.5
UPS SHIPPING MOD
There are 3 problems with my super order batch form printing functions:
1. traditional menu printing invoices yield a http 500 Internal server error
2 traditional menu printing packing slips yield a http 500 Internal server error
3. PDF Packing slip printing works but display a browser tab heading of "503 Service Temporary Un.....
Looking in my logs I find:
[22-May-2013 10:17:43] PHP Fatal error: Cannot redeclare class base in /htdocs/myzencart/includes/classes/class.base.php on line 17
[21-May-2013 16:07:50] PHP Warning: Invalid argument supplied for foreach() in /htdocs/myzencart/admin/super_batch_pages.php on line 37
What does this mean? Can anyone help?
Would be a good time. I'd like input on any "known bugs" so even if they are not fixed we can at least add them to the readme :)Quote:
Originally Posted by DivaVocals
The 500's may be coming from the FATAL error... You can double check your webserver / php_error logs if your hosting provider has them enabled to double check.Quote:
Originally Posted by twi
I'd guess the first one is coming from code somewhere using include(class.base.php) or require(class.base.php) when the file already has been included (or required). Edit Orders does not manually call any includes for these... So you might check the Super Orders code...
The second is most likely caused by the variable being passed to the foreach on line 37 not being initialized or not being an iterable object.
@lhungil
there are no log in the hosting server logs. guess the host didn't enable them.
As far as coding goes, I am illiterate. Hope someone here can help.
thanks
Also posted the info at Super orders for help.
Double posting the SAME problem on two threads is generally frowned upon in this forum.. Not to mention your issue (as you reported it) is not with Edit Orders, but with SUPER ORDERS.. the fact that integration between these modules is possible doesn't mean that issues with one relate tothe other.. Super Orders, Ty Package Tracking and Edit Orders are still three distinct modules with different purposes/functions (Order Management, Shipping, and order Editing). So unless an issue is SPECIFIC to the integration of these modules, you should be reporting functional issues in the specific support thread for the module where the problem exists.. (in this case Super Orders batch printing is NOT in any way affected by Edit Orders)Quote:
Originally Posted by twi
problem is reported at super orders. happens to be on the wrong forum. Though it might have something to do with testing the edit order 4.1.1b1. that's why its here.
Does not as there is no batch forms printing function with Edit Orders.. That said, are you saying you DID NOT get the error before installing the BETA version of Edit Orders??Quote:
Originally Posted by twi
BTW, if this is your LIVE store you SHOULD NOT be installing or testing a beta version of any add-on on your LIVE store..
Thank you for your info, over the weekend i did test install on another site, everything is working correctly files have been modified right, it when i import my Mysql database it gets broken, unfortunately editing the database is not my area of expertise, as far as my log file does not report any errors.
If everything worked before you imported your database (using Zen Cart's "test" data)... Sounds like something in the data you are importing may be causing some problems...Quote:
Originally Posted by gromit1977
Things you can check:
- How was the data imported? phpMyAdmin restore? Database Backup Manager plugin? Easy Populate? Other?
- For the product option which is not working: What did you enter in the "options name manager" and "options values manager"?
- What is entered into the "attributes controller" for the product?
- You could add some debug code to "Step 3" of the code for adding a product (in edit_orders.php) to output the attributes / options data associated with the product (assigned to the variable $attrs).
Unfortunately without knowing what data you are using for the product (and what differs in your Zen Cart installation / data from a clean Zen Cart installation) it is going to be difficult to help you further. Specifically we would need an example product containing all the related data from within the following database tables: product, product_description, product_options, product_options_types, product_options_values, products_options_values_to_products_options, and products_attributes.
Quote:
Originally Posted by DivaVocals
Does not as there is no batch forms printing function with Edit Orders.. That said, are you saying you DID NOT get the error before installing the BETA version of Edit Orders?? YES
solution: SO was simply reinstalled over EO beta & SO and TY. Now the problems mentioned in SO for batch forms works.
all is done on brand new site for upgrade. not live store.
ty for the reminder.
@lhungil and others- there's a small interoperability with Edit Orders and my discounting mods (Better Together, Quantity Discounts, etc.)
You'll get a white screen and an error log that looks like this:
[01-Jun-2013 06:53:00 UTC] PHP Fatal error: Call to undefined function zen_get_tax_rate_from_desc() in /var/www/html/demo_151/includes/modules/order_total/ot_giftwrap_checkout.php on line 184
The issue is that on the admin side, the function zen_get_tax_rate_from_desc() is not included. So a simple fix would be to pull this function (from includes/functions/functions_taxes) and put it into admin/includes/functions/extra_functions/edit_orders_functions.php.
The code you need is
Code:// Get tax rate from tax description
function zen_get_tax_rate_from_desc($tax_desc) {
global $db;
$tax_rate = 0.00;
$tax_descriptions = explode(' + ', $tax_desc);
foreach ($tax_descriptions as $tax_description) {
$tax_query = "SELECT tax_rate
FROM " . TABLE_TAX_RATES . "
WHERE tax_description = :taxDescLookup";
$tax_query = $db->bindVars($tax_query, ':taxDescLookup', $tax_description, 'string');
$tax = $db->Execute($tax_query);
$tax_rate += $tax->fields['tax_rate'];
}
return $tax_rate;
}
Thank You for reporting (and posting a quick solution). I'll include a copy of this function in the next release.Quote:
Originally Posted by swguy
The first release candidate for Edit Orders 4.1.1 is now available.
A few of the changes present in the release candidate include: some bug fixes, interoperability changes, a shiny new install / upgrade / remove process, some feature requests, and new documentation. For a full list of changes please reference the readme included with Edit Orders 4.1.1 RC1.
Anyone who wishes to tryout the release candidate should send me a PM (private message).
I will not post Edit Orders 4.1.1 RC1 publicly (for various reasons). If you want to try the release candidate you must send me a PM or email.
You know how to find me.. **LOL**Quote:
Originally Posted by lhungil
and let me add this..Quote:
Originally Posted by lhungil
<rant>
Folks who are just looking to get their hands on what they think is the latest and greatest version of Edit Orders should simply just wait.. This is supposed to be a serious testing effort which will ultimately benefit the community.. It is not useful for the active maintainers of add-ons to ask for testers only to have folks "participating" who aren't REALLY participating in the testing effort..
</rant>
Hello
I have edit orders 4.1 installed on Zen Cart 1.5.1,
I followed the installation in the exact order stated in the instructions file. I'm having a problem in the adding products.
When I add a product, or change qty. and click the update button the Sub-Total and Tota are changed to 0.00 after the page refreshes. Even the order in the client site is set to 0.
A quick search of this thread found the following: Edit Orders 4.1 subtotal is 0 and Edit Orders 4.1 subtotal is 0 fix.Quote:
Originally Posted by mcelmac
Used the fix zero subtotal copy/paste. THANKS !!. I have Ceon Manual CC installed with a surcharge. The edit order doesn't include the CC surcharge after an edit. I may be able to fix but suggestions welcome. I can take screen shot of the results I'm getting.
Check your debug logs. I've going to "guess" the CEON code when written did not take into consideration the module being loaded from the Zen Cart admin. Make sure any calls to "include", "include_once", etc include the prefix DIR_FS_CATALOG (going to guess they do not). There may be some other things which meed to be modified as well.Quote:
Originally Posted by Angry Bill
I have 'kind of' the same problem with totals.....
ZenCart 1.5.1
Edit Orders 4.1
Admin New Orders 1.3
2Checkout module
My issue is I installed the 3 modules 1st week in June, and seems to be working OK, however I just noticed that whenever I update and order to 'Shipped' the total goes to $0.00. Will this fix possibly correct this issue?
Thanks
It should.Quote:
Originally Posted by rod44
As many of you probably know the next release of Edit Orders is just around the corner. With the next release comes some updated documentation. While still a Work In Progress, feel free to peruse the readme and provide constructive feedback.
Thank You!
If the order grand total was an editable box, just like all the rest of the boxes, the problem would be solved. I don't have to edit the totals often (less than 10%) and I certainly can be trusted to so math !! Thanks, Bill.Quote:
Originally Posted by lhungil
This field is calculated by Zen Cart in the same manner as during checkout. This field is not editable because it is always recalculated (any changes to the subtotal / total one might want to make would be erased). Also if one just edited the total the surcharge would not show up on a customer's invoice or history.Quote:
Originally Posted by Angry Bill
Background
Edit Orders DOES let you add / remove / edit order total modules (which add the order total lines to the database). It does this by first loading the order information from the database into the same locations used by the Zen Cart checkout process. Then "Edit Orders" loads each corresponding order total modules (based upon sort order) and calls the "process" method (same as the checkout process). It is up to the order total module to return the correct value based upon the order information.
The "CEON Payment Surcharges/Discounts" module makes the assumption it will only be loaded from the catalog side of Zen Cart. It does not take into consideration one might wish to load the order total module from the admin side of Zen Cart and make modifications. This is an issue with the "CEON Payment Surcharges/Discounts" module.
How to Fix
One would need to remove the assumption made by the "CEON Payment Surcharges/Discounts" module.
A brief look through the "process()" code indicates this specific order total module expects the "payment" module to load surcharge information and call "setTablesOfRatesAndLongDescriptions()". If this has not been done the process method does nothing (never sets the order total line output).
One could add a block of code to the "process" method (If in the admin side of Zen Cart and existing order data is present in the database, set the order total line output to be the surcharge data stored in the database). There are some other ways as well, but this is one of the simplest solutions providing a long term fix (as a bonus it would allow one to edit the surcharge).
Quote:
Originally Posted by Angry Bill
Quote:
Originally Posted by Angry Bill
If I may add this.. Translated another way..Quote:
Originally Posted by lhungil
- If Angry Bill wants Edit Orders to display the CC surcharge from the Ceon Manual CC module, he will need to modify the Ceon Manual CC module so that the surcharge can be picked up and edited by Edit Orders.
- Modifying the grand total is not a feature that will be added to Edit Orders, but if Angry Bill wants this feature he can certainly make these changes to his store.. (it's not a recommended change which is why it will not be included in the Edit Orders module)
Does anyone have a merged version of /YOUR_ADMIN/orders.php that includes the changes for Edit Orders 4.1 and Ty Package Tracker 3.13?
Never mind on the merge; I finally got that sorted out.Quote:
Originally Posted by lat9
Running Edit Orders 4.1 w/ Ty Package Tracker on Zen Cart v1.5.1, PHP v5.4.8.
Whenever I click on the Edit button in the Customers->Orders display, I receive the following debug log:
The two shipping modules that I've got enabled are (you guessed it), Free Shipping and USPS. The issue is that when the shipping modules are loaded under edit_orders, the global variable $order->delivery['country'] is a string containing the country's name. When the shipping modules are loaded from the store-front, $order->delivery['country'] is an array:Code:[06-Jul-2013 14:32:15 Europe/Berlin] PHP Warning: Illegal string offset 'id' in C:\xampp\htdocs\zc_151\includes\modules\shipping\freeshipper.php on line 32
[06-Jul-2013 14:32:15 Europe/Berlin] PHP Warning: Illegal string offset 'iso_code_2' in C:\xampp\htdocs\zc_151\includes\modules\shipping\usps.php on line 1248
[06-Jul-2013 14:32:15 Europe/Berlin] PHP Warning: Illegal string offset 'iso_code_2' in C:\xampp\htdocs\zc_151\includes\modules\shipping\usps.php on line 1262
[06-Jul-2013 14:32:15 Europe/Berlin] PHP Warning: Illegal string offset 'id' in C:\xampp\htdocs\zc_151\includes\modules\shipping\freeshipper.php on line 32
[06-Jul-2013 14:32:15 Europe/Berlin] PHP Warning: Illegal string offset 'iso_code_2' in C:\xampp\htdocs\zc_151\includes\modules\shipping\usps.php on line 1248
[06-Jul-2013 14:32:15 Europe/Berlin] PHP Warning: Illegal string offset 'iso_code_2' in C:\xampp\htdocs\zc_151\includes\modules\shipping\usps.php on line 1262
I'm not sure if the following is the 'best' way to correct the problem ... but it works! Changes made to \YOUR_ADMIN\includes\functions\extra_functions\edit_orders_functions.php:Code:country (array)
id (string) => 223
title (string) => United States
iso_code_2 (string) => US
iso_code_3 (string) => USA
Code:function eo_get_available_shipping_modules() {
$retval = array();
if(defined('MODULE_SHIPPING_INSTALLED') && zen_not_null(MODULE_SHIPPING_INSTALLED)) {
//-bof-a-lat9-illegal-string-offset
global $order, $db;
if (!isset($order)) {
error_log('/includes/functions/extra_functions/edit_orders_functions.php (eo_get_available_shipping_modules()): global $order not set');
die();
}
$country_info = $db->Execute('SELECT countries_id as id, countries_name as name, countries_iso_code_2 as iso_code_2, countries_iso_code_3 as iso_code_3 FROM ' . TABLE_COUNTRIES . " WHERE countries_name = '" . $order->delivery['country'] . "'");
$order->delivery['country'] = $country_info->fields;
unset($country_info);
//-eof-a-lat9-illegal-string-offset
if(!isset($_SESSION['cart'])) {
require_once(DIR_FS_CATALOG . DIR_WS_CLASSES . 'shopping_cart.php');
$_SESSION['cart'] = new shoppingCart();
}
// Load the shipping class into the globals
require_once(DIR_FS_CATALOG . DIR_WS_CLASSES . 'shipping.php');
$shipping_modules = new shipping();
for($i=0, $n=count($shipping_modules->modules); $i<$n; $i++) {
$class = substr($shipping_modules->modules[$i], 0, strrpos($shipping_modules->modules[$i], '.'));
if(isset($GLOBALS[$class])) {
$retval[] = array(
'id' => $GLOBALS[$class]->code,
'text' => $GLOBALS[$class]->title
);
}
}
unset($shipping_modules, $class, $i, $n);
//-bof-a-lat9-illegal-string-offset
$order->delivery['country'] = $order->delivery['country']['name'];
//-eof-a-lat9-illegal-string-offset
}
return $retval;
}
Code:function eo_get_order_by_id($oID) {
global $db, $order;
// Retrieve the order
$order = new order($oID);
// Add some required customer information for tax calculation
// The next method has been modified to add required info to the
// session and global variables.
zen_get_tax_locations();
// Cleanup tax_groups in the order (broken code in order.php)
// Shipping module will automatically add tax if needed.
$order->info['tax_groups'] = array();
foreach($order->products as $product) {
eo_get_product_taxes($product);
}
// Correctly add the running subtotal (broken code in order.php)
if(!array_key_exists('subtotal', $order->info)) {
$query = $db->Execute(
'SELECT value FROM `' . TABLE_ORDERS_TOTAL . '` ' .
'WHERE `orders_id` = \'' . (int)$oID . '\' ' .
'AND `class` = \'ot_subtotal\''
);
if(!$query->EOF) {
$order->info['subtotal'] = $query->fields['value'];
}
}
// Handle shipping costs (module will automatically handle tax)
if(!array_key_exists('shipping_cost', $order->info)) {
$query = $db->Execute(
'SELECT value FROM `' . TABLE_ORDERS_TOTAL . '` ' .
'WHERE `orders_id` = \'' . (int)$oID . '\' ' .
'AND `class` = \'ot_shipping\''
);
if(!$query->EOF) {
$order->info['shipping_cost'] = $query->fields['value'];
$_SESSION['shipping'] = array(
'title' => $order->info['shipping_method'],
'id' => $order->info['shipping_module_code'] . '_',
'cost' => $order->info['shipping_cost']
);
if(!isset($_SESSION['cart'])) {
require_once(DIR_FS_CATALOG . DIR_WS_CLASSES . 'shopping_cart.php');
$_SESSION['cart'] = new shoppingCart();
}
//-bof-a-lat9-illegal-string-offset
$country_info = $db->Execute('SELECT countries_id as id, countries_name as name, countries_iso_code_2 as iso_code_2, countries_iso_code_3 as iso_code_3 FROM ' . TABLE_COUNTRIES . " WHERE countries_name = '" . $order->delivery['country'] . "'");
$order->delivery['country'] = $country_info->fields;
//-eof-a-lat9-illegal-string-offset
// Load the shipping class into the globals
require_once(DIR_FS_CATALOG . DIR_WS_CLASSES . 'shipping.php');
$shipping_modules = new shipping($_SESSION['shipping']);
//-bof-a-lat9-illegal-string-offset
$order->delivery['country'] = $order->delivery['country']['name'];
//-eof-a-lat9-illegal-string-offset
}
}
return $order;
}
FWIW, a combination of the changes suggested in the referenced post plus the SQL update provided here (http://www.zen-cart.com/showthread.p...ag-not-working) allowed a client's upgraded site to be able too fully edit the attributes in an order.Quote:
Originally Posted by Gadgit
Quote:
Originally Posted by lat9
You may wish to join the BETA testing team (and would be most welcome). A number of bugs have been squashed, new enhancements added, and better interoperability with existing Zen Cart and 3rd party (shipping and order total) modules. Take a peek at the current list of changes (they are listed in the Edit Orders 4.1.1 readme).Quote:
Originally Posted by lat9
Thanks, lhungil, I'll give it a spin!Quote:
Originally Posted by lhungil
Zen v1.5.1
I just did a new installation of edit orders but I'm still having a problem with the sub-total being -0- when I change the quantity. I have made the changes recommended in the previous post but it hasn't fixed my problem.
I am running only the Tax Exempt plugin in addition to EO.
Also, my install file did not include anything for SQL, only the uninstall SQL.
Because as the readme indicates, the auto installer manages the SQL changes/execution..Quote:
Originally Posted by Shara
How about the ability to edit "low order fee" for orders close to the limit?
Bill
Changing the behavior of an order total module in the admin sounds a little too much like bait and switch to me.Quote:
Originally Posted by Angry Bill
I strongly believe order total modules should act the same for both customers making an order online and when an admin adds / edits an order from the Zen Cart admin. This makes processing orders easier, ensures a seamless customer experience, and ensures anyone editing / adding an order does not "forget" rules imposed by order total modules.
I do understand a limited number of order total modules currently exist. But if one needs different functionality, one should create a new order total module (or modify the order total module) to fit their needs. New (or modified) order total modules should be posted to (or updated in) the plugin section. This would directly benefit the Zen Cart community in general and not just users of "Edit Orders".
Note: I see the potential need for an "Onetime Order Discount" order total module. This would provide an easy way to record and audit how many times an order is discounted. Using such an order total module would also ensure invoices, reports, and the customer's order history reflect the customer was given a one time order discount. If anyone else is interested or plans to build such a module... Feel free to send me a PM or email!
lol ok. "bait and switch". I appreciate the effort put into this code A LOT and I use it quite a bit real time. I also equally find he responses here equally amusing :smile:. I will continue to use my Microsoft access back door to REALLY edit the orders as I need to edit them.Quote:
Originally Posted by lhungil
I agree with the "bait and switch" characterization.. If an order total module has rules associated with it it would see more prudent to adjust the rules than the order total on the back end.. If the rules of say the "low order total" module aren't calculating as the shopowner thinks they should this is the RIGHT solution.. Anything else feels a tad.. ummm... dare I say "shady"...Quote:
Originally Posted by lhungil