Edit Orders v4.0 Support Thread

dw08gm:

From the INSTALLATION section of the Readme.

followed shortly by

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 things

1. Community suggestions/contributions to the readme
2. 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)

dw08gm:

... 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. ...
From the README under "Installation" tab: DO NOT RUN THE UNINSTALL SQL when upgrading!!!!!!.
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?

dw08gm:

if EO 4.1 is about to revised, the Readme could do with less hype and clearer instructions.
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 :)

lhungil:

From the README under "Installation" tab: DO NOT RUN THE UNINSTALL SQL when upgrading!!!!!!.
Step 5 of the "Installation" tab addresses what needs to be done when "upgrading" from earlier versions (mostly 3.x/4.x).
with regards to the uninstall SQL the readme text is as follows:
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.
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..

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..

lhungil:

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?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..

lhungil:

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 :)nods in agreement:yes:

gromit1977:

... When editing my order if it has an attribute option i cannot select one :( ...
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).

[Attachment no longer available]

gromit1977:

I am using
zen-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
Please read the first page of the readme... In particular make note of the "Potential Future Enhancements" and "Known Issues".

lhungil:

From the README under "Installation" tab: DO NOT RUN THE UNINSTALL SQL when upgrading!!!!!!.
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 :)

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.

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.

dw08gm:

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.

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??

dw08gm:

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.. 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)..

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 :(

once saved the attribute change to - :

i have fixed the pricing error from an earlier post #106

gromit1977:

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 :(
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).

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

echo '<textarea class="attribsTextarea" name="id[' .$optionID[$j] . '][value]" rows="' . $optionInfo['rows'] .
	'" cols="' . $optionInfo['size'] . '" id="attrib-' .
	$optionID[$j] . '" >' . $text . '</textarea>' . "\n";

becomes

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";

and then, when this array is read from $_POST on line 276

zen_db_prepare_input($_POST['id']),

becomes

zen_db_prepare_input($_POST['id'][$orders_products_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?

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()

$taxAdd = zen_calculate_tax($product['final_price'], $product['tax']) * $product['qty'];
	+  zen_round(zen_calculate_tax($product['onetime_charges'], $product['tax']), $decimals);

has an extra ; on the first line, and should instead be

$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.

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:

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

Gadgit:

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?
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']) {'.

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!

Gadgit:

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!
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.

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)?

Gadgit:

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.
  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.

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). :)

lhungil:

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][...]. 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 :)

I agree, this would be a better way of doing it, as you say, it would provide better readability and encapsulation.

lhungil:

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']) {'.

Yeah - I did this with my modifications, although I haven't fully tested yet.

lhungil:

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!

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?

lhungil:

Take a look at the differences found in 'includes/order.php' (especially the cart() function) between 1.5.0 and 1.5.1...

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.

lhungil:

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)?

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).

lhungil:

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). :)

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).

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

Gadgit:

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? ...
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)...

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).

Gadgit:

... 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 ...
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).

Gadgit:

... 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).

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.
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...

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).

Gadgit:

I'm happy to do a bit of testing/dev on the module if you like, would perhaps be easier to PM?
My PM inbox is mostly full here... But the help is definitely welcome as is another pair of eyes :)

lhungil:

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)...

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).

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...

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 :)

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:

I got lost when they started talking about uprids.

dw08gm:

I got lost when they started talking about uprids.Uh huh..:laugh: So I'm sticking with what I DO know.. :laugh:

Updated Installation Page in readme.

cheers

Gadgit:

...
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 ...
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').