Attribute pricing display all fouled up

[mc12345678]

We're not getting anywhere here since I cannot make heads or tails out of your novel; I'm not a coder and don't speak code. I'm not sure that you can condense those words down to the Cliff Notes version, here is what I see:

My cart has been functioning as expected for 8+ years. Back in the zc1.3.8a days, there was a book that explained everything in minute detail. I might be able to resurrect the outdated copy and see what it says about this since that book is what I used to initially set everything up. There's a whole chapter dedicated to attribute functionality.

Now, since the 1.5.6a update, the product pricing is significantly different. Actually, it is not the pricing, it IS the display of the attribute. (and unusable from my perspective)
You say that you recoded the attribute pricing to make it more friendly to future users.
My interpretation is the unsaid, existing users were not necessarily a consideration.

After several pages of words, you now say that I am at fault and there is no problem with your code changes. The pricing is functioning as you expected.
So you think that now, after 8+ years, I have a problem to fix on my own. I am not saying that my setup is incorrect, I am saying that the pre-156a pricing displayed to the consumer is correct.

Can you please provide me step by step instructions on what I need to do in order to have the product pricing displayed as it has been displayed for 8+ years. Not 150% higher than it should be displayed.

I am not sure you really comprehend my question, since I don't remember seeing any response that addresses/mentions a displayed attribute price.

I can do that if you can clearly provide me the setup of a product that is setup the way you are seeing the problem. I have not been provided all of the characteristics that you have setup and you have not disagreed with the conditions I have stated as testing. This change ONLY affected the displayed attribute price and that is the only thing that we have been working to address.

Note, while I had begun a response to the previous discussion, I can tell you that no the prices did not consistently show up correctly as stated several times in conditions that are supported and expected to be supported by ZC. More discussion is at: https://github.com/zencart/zencart/pull/1404

[RixStix]

My first post has the example of current and upgraded.
Post number 4 shows the parameters for pricing
I can't disagree with anything you have typed if I cannot comprehend what you are saying in the novel.

I can make what I consider the correct price happen in 156a but you said my way was incorrect, so I am asking you to show me how to make the display proper. That was before I saw that the Fuschia button has also been affected.

Nothing I have said has anything to do with discounting, sales or salemaker at the moment. That bridge can be crossed after the correct price is displayed on the product page prior to being added to the cart.

I'll have a look at the link you provided while sitting on the couch in a few minutes.

[mc12345678]

My first post has the example of current and upgraded.
Post number 4 shows the parameters for pricing
I can't disagree with anything you have typed if I cannot comprehend what you are saying in the novel.

I can make what I consider the correct price happen in 156a but you said my way was incorrect, so I am asking you to show me how to make the display proper. That was before I saw that the Fuschia button has also been affected.

Nothing I have said has anything to do with discounting, sales or salemaker at the moment. That bridge can be crossed after the correct price is displayed on the product page prior to being added to the cart.

I'll have a look at the link you provided while sitting on the couch in a few minutes.

How are you "applying" 15%? are you using a price_factor of 0.15 and an offset of 0, or some other variation (say as 1 and 0.85 respectively?)

[RixStix]

How are you "applying" 15%? are you using a price_factor of 0.15 and an offset of 0, or some other variation (say as 1 and 0.85 respectively?)

Currently, I am using price factor alone but that should not be a limitation. Just tell me step by step how to configure attribute pricing so that the display to a paying customer will not be confusing as the current change has made it, while maintaining functionality.

I did peruse the github notes but I didn't see any discussion there related to changing the functionality of the day to day, routine use of the attributes function. ie: regular pricing without sale or discounts. I going out on a limb when I say most purchases are using day-to-day, regular prices and sales/discounts are the lesser case.

All I saw was how can we change the code to allow for sales and discounts and not caring about how the 90% of the time use will be impacted. Nothing was mentioned about ensuring existing functionality was a consideration. Looked like the OP of the thread went along his/her merry way after the thread progressed past the first reply or two.

I do realize that things have been changed up so much that restoring original functionality is extremely unlikely. Something was fixed that wasn't broken. I see that in other applications that I use when the new coders come in and start making changes/fixing things without the background of how things were laid out originally. They fix things for a few people without thinking about the affects on existing users.

[mc12345678]

Currently, I am using price factor alone but that should not be a limitation. Just tell me step by step how to configure attribute pricing so that the display to a paying customer will not be confusing as the current change has made it, while maintaining functionality.

I did peruse the github notes but I didn't see any discussion there related to changing the functionality of the day to day, routine use of the attributes function. ie: regular pricing without sale or discounts. I going out on a limb when I say most purchases are using day-to-day, regular prices and sales/discounts are the lesser case.

All I saw was how can we change the code to allow for sales and discounts and not caring about how the 90% of the time use will be impacted. Nothing was mentioned about ensuring existing functionality was a consideration. Looked like the OP of the thread went along his/her merry way after the thread progressed past the first reply or two.

I do realize that things have been changed up so much that restoring original functionality is extremely unlikely. Something was fixed that wasn't broken. I see that in other applications that I use when the new coders come in and start making changes/fixing things without the background of how things were laid out originally. They fix things for a few people without thinking about the affects on existing users.

It's unfortunate that you have the perspective that you do as no where was it described to change/disable the existing functionality; however, please revisit https://github.com/zencart/zencart/pull/2075/files. My latest update to that has resolved this discussion as well as the two other thread to which I referred as existing where it was identified that the system was broken. May not have been something used at your site, but it didn't work as expected/intended and yet on checkout everything (well the v154 problem required a modification seen in v155 and beyond) flowed like it should:
https://www.zen-cart.com/showthread....correct-totals (2 issues identified in this thread)
https://www.zen-cart.com/showthread....not-attributes

The modification sustains what is described as expected setups for products priced-by-attributes, using price_factor, sales, and specials (provided the discount is not a straight subtraction of a quantity instead of say a percentage of a value.

As to those using this or that, I rarely see questions related to using price factor, doesn't mean it isn't used, but doesn't mean that it is either. Apparently it has become a desired setting for the site discussed here, but your expression of frustration was the first to have identified the issue. Ajeh has been asked to review the changes and hopefully from a functionality stand point it will be found to be sound and correct the problems that have been seen for ages. Further while it doesn't completely fix all attribute related things, it seems to at least make the visitor's display show the proper information.

[RixStix]

Further while it doesn't completely fix all attribute related things, it seems to at least make the visitor's display show the proper information.

To me, changing the visitor's display to make it confusing while using the same database results in a change in functionality between the setup in 154 and 156a. If that is not a difference in functionality, then I am sorry that I chose the wrong terminology. Your choice of words sounds like you cannot see a difference in the visitor's display that I pointed out in the first post.

Currently, the 154 site provides visitor's display correctly. 156a uses the same database and makes the visitor's display show incorrect, confusing information. Frustration level is so high that I am planning to do whatever I need to make things work.

I have not questioned the calculations related to specials, sales and discounts and that seems to be what you are stuck on debating and I have said that I cannot debate something that I do not understand. We have been using our own work-around for 8 years knowing that sales and discounts didn't function as we had expected.

I only asked what can I do so that the visitor's display is not confusing while stating something has changed. I told you what I could do and you said that might not be a proper remedy. Frustration level is so high that I am planning to do whatever I need to make things work since I am not sure you can provide the settings for which I asked but you say it works.

[RixStix]

So, for anyone in the future reading this thread, I am inserting screenprints of the links used in Post #1.

I just realized that as soon as I resume working on the 156 upgrade, the links in post #1 would no longer be valid.

To use DrByte's words:

explain the symptom and what you'd like it to do instead and why.

My first post explained the symptom showing differences between a zc154 and zc156a setup using the same database.
My first post explained why the display to the visitor was correct OR if nothing else, less confusing to the visitor.
Why, because the displayed price (using 154db imported into 156a) to the visitor is seemingly more than double the actual price which will be added to the shopping cart.

Now, after 46 posts, we have several chapters added to the novel on how to calculate sales prices, salemaker and discounts when attributes are involved and nothing specific on what I need to do to modify the imported 154 database display the same, correct, not confusing prices to the visitor. I'm sorry, I am not a coder and am not overly concerned about how the calculations are performed and really don't understand what the calculations have to do with a simple display to the visitor though I am sure they are important to the functionality.

I'm sure I will figure out some combination of clicks, radio buttons, checkboxes etc but will grumble the whole time modifying each affected product.
Heck, it may be something I did years ago during setup but it is unlikely that I edited the code without guidance from the community.

[mc12345678]

So, for anyone in the future reading this thread, I am inserting screenprints of the links used in Post #1.

I just realized that as soon as I resume working on the 156 upgrade, the links in post #1 would no longer be valid.

To use DrByte's words:


My first post explained the symptom showing differences between a zc154 and zc156a setup using the same database.
My first post explained why the display to the visitor was correct OR if nothing else, less confusing to the visitor.
Why, because the displayed price (using 154db imported into 156a) to the visitor is seemingly more than double the actual price which will be added to the shopping cart.

Now, after 46 posts, we have several chapters added to the novel on how to calculate sales prices, salemaker and discounts when attributes are involved and nothing specific on what I need to do to modify the imported 154 database display the same, correct, not confusing prices to the visitor. I'm sorry, I am not a coder and am not overly concerned about how the calculations are performed and really don't understand what the calculations have to do with a simple display to the visitor though I am sure they are important to the functionality.

I'm sure I will figure out some combination of clicks, radio buttons, checkboxes etc but will grumble the whole time modifying each affected product.
Heck, it may be something I did years ago during setup but it is unlikely that I edited the code without guidance from the community.

As said over the last several posts, keep an eye on https://github.com/zencart/zencart/pull/2075/files (provided in post #10).

That fileset has been incorporated for the next distribution and restores the operation that was expected to be seen which means that you should not have to do anything with your imported data. Especially since the shopping cart results have not been modified.

The changes made there are based on the information you have provided as to how the original issue could be observed. Again, as best could be understood by the information provided was that the issue was observed on the product information page when a product was priced-by-attribute, had a base price entered (supports using the price factor) and an attribute had information filled into the price_factor field only (stated that only using the price_factor, although the price_factor and the price_factor_offset fields work together to provide the difference.)

That said, the revision did take into account the price_factor_offset, sales, specials, and combination of a sale and special as well. Note, no additional action was taken for a sale/special that reduces the price by a specific quantity as compared to a percentage.