Attribute pricing display all fouled up

[RixStix]

156a install w/demo data
drop tables
import db backup from live site
run db cleanup mySQL
run zc_install
install zca_bootstrap template


Something has changed in how attribute pricing is displayed and/or calculated. It's all fouled up compared to the past 8 years.
It's easier to show on the live and sandbox sites than to try to put it entirely into words. Links below.

Is this expected functionality or a hiccup? If expected, then I have a LOT of product work to do.

154 and below: Our products ADD a dollar amount based upon attributes which is a percentage of the base price. The adder is displayed preceded by a + or - sign.
156a, the total is displayed preceded by a + or - sign which indicates that amount is in addition to the base price. A 15% adder is now displayed as 115%.

If you have multiple attributes with adders, the first choice may present the total price including base + attribute. the second choice may present the base + attribute.

Link to live site example:
https://chainweavers.com/index.php?m...products_id=11

Link to sandbox 156a site:
http://chainweavers.info/156/index.p...products_id=11

The example being
Wire Shape: SQUARE
Mandrel Size: 3.00mm

Based upon the display to the customer, How much will a quantity of 1.0 cost?
154 live site: base price plus square adder plus 3.00mm adder YES
156a sandbox: I dunno. Base price plus square adder plus 3.00mm adder? NOPE.

Admin side is equally changed. Looking for the price ADDER and the TOTAL is displayed.

ALSO: WireShape: Diamond is "Ask for Quote" but the base price is displayed on that line.

[RixStix]

Sorry, fouled was a poor choice of words.

[mc12345678]

What settings are used to generate say the first price showing set of attributes? I just used the default install and of the prices selected for display, I didn't see any issues especially where the full price got determined with the partial price to follow.

[RixStix]

Both setups are identical so I do not understand your question.

Live site shows the SQUARE example as +$5.98 added to the base price. ie: add 15% to base
Sandbox shows the SQUARE example as +$45.85 added to the base price. ie: add 15% to base but 115% is displayed

Choose the the option 3.00mm in the second option choice
Live site shows to add an additional $2.79 to the base price ie: add 7% to base
Sandbox shows to add an additional $42.88 to the base price ie: add 7% to base but 107% is displayed

From that, you are saying that in 156a, displaying 115% and 107% is expected functionality difference between 154 and 156a?
Sandbox site indicates that the price to the customer will be $128.60
Real, live indicated price to the customer $48.68

[mc12345678]

I'm asking, how can I setup something to reproduce what is displayed on your site?

I haven't seen similar responses looking at demo product of a vanilla ZC 1.5.6a site where product are set up to demonstrate one aspect or another. Of course I didn't go through every possible product, thinking that the associated configuration may be provided here where the problem was identified.

[RixStix]

Setup is to import functional database from live site to 156a site.
Do you expect me to use a setup identical to one of the demo examples?

Can you not see there is a difference in functionality because the display is different?

Am I not to expect a functional, live database to function in 156a?
Surely, you don't expect a user to recreate every product from scratch when updating from one version to another?

I'll see what I can do after breakfast to satisfy your request.

Setup product to be priced by attributes
Setup product's base price $100
Setup product attribute NameA, Option 1 to add 5% to the base price when selected. All other options add 0%
Setup product attribute NameB, Option 1 to add 10% to the base price when selected. All other options add 0%

Expected display is the $5 and $10 respectively shown to the customer. NOT $105 and $110

That should show you the same thing (except percentages different) that you cannot seem to see when viewing the live site and sandbox site. Both setups being IDENTICAL.

[mc12345678]

Setup is to import functional database from live site to 156a site.
Do you expect me to use a setup identical to one of the demo examples?

Can you not see there is a difference in functionality because the display is different?

Am I not to expect a functional, live database to function in 156a?
Surely, you don't expect a user to recreate every product from scratch when updating from one version to another?

I'll see what I can do after breakfast to satisfy your request.

Setup product to be priced by attributes
Setup product's base price $100
Setup product attribute NameA, Option 1 to add 5% to the base price when selected. All other options add 0%
Setup product attribute NameB, Option 1 to add 10% to the base price when selected. All other options add 0%

Expected display is the $5 and $10 respectively shown to the customer. NOT $105 and $110

That should show you the same thing (except percentages different) that you cannot seem to see when viewing the live site and sandbox site. Both setups being IDENTICAL.

So if we could take a little breath. I understand the frustration. I personally do not expect things to have to be redone. I don't expect that a store is setup to match some sample data.

I could see the end results that were being shown, but there are basically 8 pricing options on the attributes screen alone, with 3 radio button selections on how the attribute can be affected by other settings, then add in a base price and price by attribute. Blindly applying those settings made it difficult to determine what was going on and what was causing the issue. Having some "raw" data to support the configution/duplication of the issue helps to resolve the situation.

Restoring the includes/modules/atributes.php file at lines 130 and 131 to what was in ZC 1.5.5x would return operation to what was previously provided if this is a stop sales situation. That would be accomplished by removing the 5th element from the function zen_get_attributes_price_final and uncommenting the zen_get_discount_calc function call. Doing so will return the problem seen in display of pricing/attributes for product that are priced-by-attribute, have a price factor and a special or sale. I am testing one other change right now to see its impact.

[RixStix]

I do appreciate the help. The last thing I want to do is to downgrade files to a previous version or to have core customizations. I have learned that lesson the hard way and have little desire to repeat it.

The change to cripple/remove existing functionality (if intentional) must have been made for some strategic reason which I did not read in any document. I do read a lot.

If you still need it, I will generate a step-by-step to duplicate the setup.

Currently, it is not a stop sales event because I am nowhere close to putting a 156a site live. It's not there yet with the basic functionality, much less any addon.

[mc12345678]

I do appreciate the help. The last thing I want to do is to downgrade files to a previous version or to have core customizations. I have learned that lesson the hard way and have little desire to repeat it.

The change to cripple/remove existing functionality (if intentional) must have been made for some strategic reason which I did not read in any document. I do read a lot.

If you still need it, I will generate a step-by-step to duplicate the setup.

Currently, it is not a stop sales event because I am nowhere close to putting a 156a site live. It's not there yet with the basic functionality, much less any addon.

There was a changed proposed (by me) to address the problem I described above; however, as you can see the multitude of options available, I don't think I got to this one aspect, especially considering having multiple option names in play. I think I may have a solution which will maintain the capability expressed by the problem function (if one were to desire it) but also provide the desired display for situations like this.

Basically, if I understand correctly, if the base product price were removed from the attribute's listed price, then the + numbers would come out correct, am I right?

The thought being, if the product is priced-by-attributes, then subtract the price of the product from the attribute's price...

[mc12345678]

Okay, so I made the following modifications which seem to restore previous operation/output but still keep the improvements that were applied. I will be proposing the changes made here for incorporation. May need to apply similar changes to an admin side function; however, for the store side:
includes/functions/functions_prices.php file as provided in ZC 1.5.6a beginning at line 1217:

function zen_get_attributes_price_final($attribute, $qty = 1, $pre_selected, $include_onetime = 'false', $prod_priced_by_attr = false, $attributes_discounted = 0, $include_products_price_in = false) {
    global $db;
    $attributes_price_final = 0;
    if ($pre_selected == '' or $attribute != $pre_selected->fields["products_attributes_id"]) {
      $pre_selected = $db->Execute("select pa.* from " . TABLE_PRODUCTS_ATTRIBUTES . " pa where pa.products_attributes_id= '" . (int)$attribute . "'");
    } else {
      // use existing select
    }
    // normal attributes price discounted by sales/specials or not discounted if neither a sale nor a special
    if ($pre_selected->fields["price_prefix"] == '-') {
//      $attributes_price_final -= $pre_selected->fields["options_values_price"];
      $attributes_price_final -= zen_get_discount_calc($pre_selected->fields["products_id"], $pre_selected->fields["products_attributes_id"], ($prod_priced_by_attr ? zen_products_lookup($pre_selected->fields["products_id"], 'products_price') : 0) + ($prod_priced_by_attr ? -1 : 1) * $pre_selected->fields["options_values_price"]) + ($prod_price_by_attr && !$include_products_price_in ? zen_products_lookup($pre_selected->fields["products_id"], 'products_price') : 0);
    } else {
//      $attributes_price_final += $pre_selected->fields["options_values_price"];
      $attributes_price_final += zen_get_discount_calc($pre_selected->fields["products_id"], $pre_selected->fields["products_attributes_id"], $pre_selected->fields["options_values_price"] + ($prod_priced_by_attr ? zen_products_lookup($pre_selected->fields["products_id"], 'products_price') : 0)) - ($prod_price_by_attr && !$include_products_price_in ?  zen_products_lookup($pre_selected->fields["products_id"],  'products_price') : 0);
    }

I may propose some rewriting for clarity, but the above functionality is what it seems like is expected, unless others find problem with the resulting displayed values.

EDIT: I would actually like to resequence the parameters; however, one of those things where others may have built off of the originally provided function and changing parameters would have an undesirable effect, unfortunately.