Edit Orders v3.0 for ZC 1.3.9 [Support Thread]

[lhungil]

I'm currently working on the handling of attributes, not sure how far I will get in the process, but just wanted to let anyone else who may be working on these know. Maybe we can pool our efforts?

The first part of attribute handling I am tackling are improvements to filter out attributes not used for pricing. My current changes appear to be correctly filtering out read only attributes not used for pricing during "add products (step 3)". Still testing the changes and verifying it does not break anything in my test environments.

Next I will attempt to modify the pricing code to parse the submitted information, convert it to the format expected by Zen Cart 1.5 functions, and then use the pricing functions for products. This should hopefully provide a good starting point for further fixes and enhancements to the handling of product attributes.

As always, once I start posting more of my patches, I will welcome others to test the changes and provide constructive feedback.

[DivaVocals]

I'm currently working on the handling of attributes, not sure how far I will get in the process, but just wanted to let anyone else who may be working on these know. Maybe we can pool our efforts?

The first part of attribute handling I am tackling are improvements to filter out attributes not used for pricing. My current changes appear to be correctly filtering out read only attributes not used for pricing during "add products (step 3)". Still testing the changes and verifying it does not break anything in my test environments.

Next I will attempt to modify the pricing code to parse the submitted information, convert it to the format expected by Zen Cart 1.5 functions, and then use the pricing functions for products. This should hopefully provide a good starting point for further fixes and enhancements to the handling of product attributes.

As always, once I start posting more of my patches, I will welcome others to test the changes and provide constructive feedback.

You are my hero!!! Sounds like you are tackling some of the old attribute issues that have PLAGUED this add-on forever.. AWESOME... Gotta take a look at the changes you posted already and bundle them into the version available on my site.. I am hoping to kick loose some of the conversion work that has kept me tied up and finally get the readme updated and this version SUBMITTED officially..

[lankeeyankee]

I'm currently working on the handling of attributes, not sure how far I will get in the process, but just wanted to let anyone else who may be working on these know. Maybe we can pool our efforts?

The first part of attribute handling I am tackling are improvements to filter out attributes not used for pricing. My current changes appear to be correctly filtering out read only attributes not used for pricing during "add products (step 3)". Still testing the changes and verifying it does not break anything in my test environments.

Next I will attempt to modify the pricing code to parse the submitted information, convert it to the format expected by Zen Cart 1.5 functions, and then use the pricing functions for products. This should hopefully provide a good starting point for further fixes and enhancements to the handling of product attributes.

As always, once I start posting more of my patches, I will welcome others to test the changes and provide constructive feedback.

If you are going to filter out attributes not directly related to pricing you are still going to include them in the product addition? I am not sure that this is really necessary to get this working correctly and you want to include all attributes when adding a product. The sticking point here is in admin/edit_orders.php on line 1296:

if ($row10a[2] == 1 && $_POST[applyspecialstoprice])
                                            $newpricechange = zen_get_discount_calc($add_product_products_id, $row10a[3], $row10a[0], $add_product_quantity); 

Start making changes here and you change the pricing results for sales and specials prices. In looking at the rest of the code that includes this variable I haven't cracked the change to make it work right. What is happening is if you have a product priced by attributes and there are two or more attributes with contributing prices it will add the 1st attribute price, the 1st attribute price again with the 2nd and 3rd, 4th etc. If there are more than 1 attribute but the 2nd and on do not add to the price then my initial change works correctly and the sale price is displayed. So we need to just figure out why it's adding the 1st price twice when the 2nd and beyond contribute to the price and then we're sorted and everything is working fine.

I haven't had any free time lately to go back and look at this again since my last, fruitless stab. There is somewhere that is either adding $row10a[0] - which is the attribute price returned from the db array - as well as $newpricechange, or is calling $newpricechange twice and adding them together. I will have free time this weekend since my family will be out of town and I can work without distractions and I am determined to get this sorted since it's an enormous time waster the way it is and we use it daily.

[DivaVocals]

If I may interject here.. Given my skillset, I certainly can't contribute any code to this effort.. However, I do have some usability observations to make.. I think any code which affects attributes needs to be planned out so that one change doesn't have an inadvertent side effect for shop owners.

IMHO using blanket methods to exclude attributes will lead to an undesired effect. To exclude attributes that are truly "optional" product attributes, I think there needs to be a means for a shopowner to explicitly flag/mark which attributes they want excluded from the add/edit products function.

One of my client's paid to have a v1.5 ready version of Stock by Attributes which includes a similar feature. This allows him to specify which attributes will be excluded from stock variants.

[lankeeyankee]

OK, I *think* I have the attributes issue sorted. If someone else would like to test it out in as many scenarios as possible to double check this works 100% correctly please let me know the results. I don't use one time charges, text attributes, price factors, or quantity discounts so I haven't tested for any of these.

In admin/edit_orders.php on line 1364 change:

$Query = "insert into " . TABLE_ORDERS_PRODUCTS . " set
                orders_id = $oID,
                products_id = $add_product_products_id,
                products_model = '$p_products_model',
                products_name = '" . str_replace("'", "'", $p_products_name) . "',
                products_price = '$product_price_woa',
                final_price = '" . ($product_price_woa + $AddedOptionsPrice) . "',
                products_tax = '$ProductsTax',
                products_quantity = $add_product_quantity,
                                onetime_charges = $AddedOptionsPrice_OneTime;"; 

to this:

if ($_POST[applyspecialstoprice] && zen_get_products_special_price((int)$add_product_products_id) && $AddedOptionsPrice != 0) {
            $Query = "insert into " . TABLE_ORDERS_PRODUCTS . " set
                orders_id = $oID,
                products_id = $add_product_products_id,
                products_model = '$p_products_model',
                products_name = '" . str_replace("'", "'", $p_products_name) . "',
                products_price = '$product_price_woa',
                final_price = '" . ($products_details["final_price"] + $AddedOptionsPrice) . "',
                products_tax = '$ProductsTax',
                products_quantity = $add_product_quantity,
                                onetime_charges = $AddedOptionsPrice_OneTime;";
                                } else {
            $Query = "insert into " . TABLE_ORDERS_PRODUCTS . " set
                orders_id = $oID,
                products_id = $add_product_products_id,
                products_model = '$p_products_model',
                products_name = '" . str_replace("'", "'", $p_products_name) . "',
                products_price = '$product_price_woa',
                final_price = '" . ($product_price_woa + $AddedOptionsPrice) . "',
                products_tax = '$ProductsTax',
                products_quantity = $add_product_quantity,
                                onetime_charges = $AddedOptionsPrice_OneTime;";
                                } 

So far, if something is on special the price is correct with multiple attributes selected. This is with some attributes being discounted when on sale/special and some not, all attributes being discounted, and even if it's on sale/special but you uncheck the "Use Specials/Sales Price" box in step 4 of adding the product then the non-discounted prices are used correctly.

Hopefully this won't need any more changes! But I am not holding my breath!!

[lhungil]

The code changes I'm working with are not to filter out based upon guesses. I'm using the existing functions (used by zen cart when adding a product to an order) and running the attributes through the same filters (which are based on if the product uses attributes for pricing, if the attribute is read only, settings in the admin configuration, and several other factors).

Pricing is currently handled by Zen Cart based upon the attributes added to an order. You can price products by attributes (no product price) or by a combination of base / special pricing and attribute pricing. To take all of this into consideration and have the pricing stay consistent with how Zen Cart handles pricing, we need to use the Zen Cart functions for pricing and attribute handling.

The current code in Edit Orders uses it's own custom code for pricing and order totals instead of integrating with the functions built into Zen Cart. I have already come to the conclusion I will need to remove all the existing attribute handling code from Edit Order and start over. I also want to remove all the direct MySQL calls, so future porting to MsSQL, PostgreSQL, or even SQlite is more feasible.

Doing a complete rewrite of the attribute and pricing code will also ensure anyone who has made changes (or has add-ons) to the Zen Cart pricing functions will have the correct prices used when adding a product via the administrative interface. This change should also make upgrading in the future far simpler, since the code will be using internal Zen Cart functions as much as possible.

[lhungil]

The downside to the changes I am working on... Well a complete rewrite of the sections used to handle attributes is not a small undertaking... It will take some time and testing... I will not be able to release portions of the fixes to someone running on a different code base, since changes impact other areas of the code. What I am doing is pretty much a fork of the existing (and very awesome) Edit Orders 4.x code base.

It may be best (leaving the decision up to DivaVocals of course), to release 4.x before any of my attribute based changes are complete.

The portion of the code I started with (display and selection of attributes when adding a product) are close to complete. I've added integration with existing Zen Cart configuration variables, filtering based upon the same code used by Zen Cart (when adding a product to an order and fields used on the add product page), and handling for attributes of types: checkbox, radio, text / textarea, dropdown, and readonly (user-added are treated as readonly). I've not added support for "file" attribute types at this point.

Once I'm done with the display and selection portion, I will be moving into the "price calculation, product price adjust, and adding the product to an order" section. I plan to utilize existing Zen Cart functions as much as possible in this section, and may be including classes from the non admin site to accomplish the end goal - consistent and accurate pricing of the product including attributes.

Now before anyone starts complaining they need to be able to adjust prices... You still will be able to by directly editing the product price, tax, etc AFTER the product is added to the order. Just the "add products" pricing will be consistent with adding a product to the shopping cart or order.

Another aspect I have been tackling is optimization of SQL calls... The old code used a large number of SQL calls to pull in and change information. The same could be accomplished with far less calls. While minor, some of my clients are on hosting which rate limits SQL calls... so changes to lower the number of SQL calls and utilization of caching where appropriate are changes I will be adding (and yes, caching can be turned off). This code should also integrate well with QueryCache, which all of my clients (but not all my test environments) utilize.

[lhungil]

OK, I *think* I have the attributes issue sorted. If someone else would like to test it out in as many scenarios as possible to double check this works 100% correctly please let me know the results. I don't use one time charges, text attributes, price factors, or quantity discounts so I haven't tested for any of these.

Looks like an improvement to me, thank you for submitting. I like the use of one of the built-in Zen Cart pricing functions ;)

I am not going to be able to test, as the attribute / pricing code I'm working with no longer looks vaguely similar (and utilizes more of the built-in pricing functions - and the pricing_prefix).

[DivaVocals]

It sounds like the shortfalls of edit orders that I could never address (don't have the skillset to tackle) with regards to pricing, attributes are FINALLY being properly addressed. I'm assuming that the long standing issues with taxes will be "fixed" as a by-product of the pricing changes?? That would be awesome if it was..

The code changes I'm working with are not to filter out based upon guesses. I'm using the existing functions (used by zen cart when adding a product to an order) and running the attributes through the same filters (which are based on if the product uses attributes for pricing, if the attribute is read only, settings in the admin configuration, and several other factors).

Pricing is currently handled by Zen Cart based upon the attributes added to an order. You can price products by attributes (no product price) or by a combination of base / special pricing and attribute pricing. To take all of this into consideration and have the pricing stay consistent with how Zen Cart handles pricing, we need to use the Zen Cart functions for pricing and attribute handling.

The current code in Edit Orders uses it's own custom code for pricing and order totals instead of integrating with the functions built into Zen Cart. I have already come to the conclusion I will need to remove all the existing attribute handling code from Edit Order and start over. I also want to remove all the direct MySQL calls, so future porting to MsSQL, PostgreSQL, or even SQlite is more feasible.

Doing a complete rewrite of the attribute and pricing code will also ensure anyone who has made changes (or has add-ons) to the Zen Cart pricing functions will have the correct prices used when adding a product via the administrative interface. This change should also make upgrading in the future far simpler, since the code will be using internal Zen Cart functions as much as possible.

Understood and did not mean to imply that's the direction you were taking at all.. My concern was that filtering needed to not be based on a single setup tis all. I think what you are doing is WONDERFUL!! There was a volunteer who offered to make these fixes, but they dropped out of the scene leaving me with half working code that I ended up with the unenviable task of having to remove just to get things at least working with the old (albeit flawed) functionality.. So I am happy to see someone taking on these sections of Edit Orders.. It was on my wishlist, but outside of my skillset to complete..

The downside to the changes I am working on... Well a complete rewrite of the sections used to handle attributes is not a small undertaking... It will take some time and testing... I will not be able to release portions of the fixes to someone running on a different code base, since changes impact other areas of the code. What I am doing is pretty much a fork of the existing (and very awesome) Edit Orders 4.x code base.

It may be best (leaving the decision up to DivaVocals of course), to release 4.x before any of my attribute based changes are complete.

The portion of the code I started with (display and selection of attributes when adding a product) are close to complete. I've added integration with existing Zen Cart configuration variables, filtering based upon the same code used by Zen Cart (when adding a product to an order and fields used on the add product page), and handling for attributes of types: checkbox, radio, text / textarea, dropdown, and readonly (user-added are treated as readonly). I've not added support for "file" attribute types at this point.

Once I'm done with the display and selection portion, I will be moving into the "price calculation, product price adjust, and adding the product to an order" section. I plan to utilize existing Zen Cart functions as much as possible in this section, and may be including classes from the non admin site to accomplish the end goal - consistent and accurate pricing of the product including attributes.

Now before anyone starts complaining they need to be able to adjust prices... You still will be able to by directly editing the product price, tax, etc AFTER the product is added to the order. Just the "add products" pricing will be consistent with adding a product to the shopping cart or order.

Another aspect I have been tackling is optimization of SQL calls... The old code used a large number of SQL calls to pull in and change information. The same could be accomplished with far less calls. While minor, some of my clients are on hosting which rate limits SQL calls... so changes to lower the number of SQL calls and utilization of caching where appropriate are changes I will be adding (and yes, caching can be turned off). This code should also integrate well with QueryCache, which all of my clients (but not all my test environments) utilize.

Based on all the changes you've made, I think that the Edit Orders v4.0 release should be YOUR code with all the RIGHT changes for pricing and attributes in place, and consider the Edit Orders on my site a working beta release.. I'll be happy to update the readme file if you like, but your code is JUST what Edit Orders has needed for a while..

Looks like an improvement to me, thank you for submitting. I like the use of one of the built-in Zen Cart pricing functions ;)

I am not going to be able to test, as the attribute / pricing code I'm working with no longer looks vaguely similar (and utilizes more of the built-in pricing functions - and the pricing_prefix).

OK, I *think* I have the attributes issue sorted. If someone else would like to test it out in as many scenarios as possible to double check this works 100% correctly please let me know the results. I don't use one time charges, text attributes, price factors, or quantity discounts so I haven't tested for any of these.
So far, if something is on special the price is correct with multiple attributes selected. This is with some attributes being discounted when on sale/special and some not, all attributes being discounted, and even if it's on sale/special but you uncheck the "Use Specials/Sales Price" box in step 4 of adding the product then the non-discounted prices are used correctly.

Hopefully this won't need any more changes! But I am not holding my breath!!

Very excited to finally see some improvements for the better happening here!!

[countrycharm]

It sounds like the shortfalls of edit orders that I could never address (don't have the skillset to tackle) with regards to pricing, attributes are FINALLY being properly addressed. I'm assuming that the long standing issues with taxes will be "fixed" as a by-product of the pricing changes?? That would be awesome if it was..



Understood and did not mean to imply that's the direction you were taking at all.. My concern was that filtering needed to not be based on a single setup tis all. I think what you are doing is WONDERFUL!! There was a volunteer who offered to make these fixes, but they dropped out of the scene leaving me with half working code that I ended up with the unenviable task of having to remove just to get things at least working with the old (albeit flawed) functionality.. So I am happy to see someone taking on these sections of Edit Orders.. It was on my wishlist, but outside of my skillset to complete..



Based on all the changes you've made, I think that the Edit Orders v4.0 release should be YOUR code with all the RIGHT changes for pricing and attributes in place, and consider the Edit Orders on my site a working beta release.. I'll be happy to update the readme file if you like, but your code is JUST what Edit Orders has needed for a while..






Very excited to finally see some improvements for the better happening here!!

Very excited to finally see some improvements for the better happening here!!
**nods in agreement**