Stock by Attribute v4.0 addon for v1.3.5-1.3.9

[mc12345678]

I've installed the plugin and everything seems to be working except for one minor issue I have no idea how to go about to fix it.

I have a product with two options, the full size and a sample on a pulldown menu. The full size accepts discounts, the sample does not.
For the full size product price appears right next to the attribute in parenthesis without a discount. The sample size product price and the discount price appear right next to the attribute both in separate parenthesis.

Shouldn't this be the other way around? full size - full price and discount, sample size - full price and no discount?

Any ideas how should I go about to fix this?

Thank you for the help.

Yes, the display should be opposing and I believe it has been an issue for a while. I've made an initial correction, though who knows what other outlier I need to consider, but I'm also trying to incorporate processing using the new Zen Cart 1.5.7 attributes file such that ideally, that file doesn't need to be touched going forwards.

I'll try to prep a commit just for this price display issue and reference it back here.

I don't know if this helps in any way but I was playing with the settings and when I turned off SBA Original Price Struck Through the sale price on the item that doesn't accept sales got removed. I have the feeling that setting isn't supposed to do that

Like I said and you identified, backwards. :) I have a feeling that I was trying to find when not to apply the extra price display and then forgot to negate it so that it would show the extra price only when the item was discounted. I did discover that when I did that, that I also had to account for display only, default type attributes, otherwise it added 0.00 to the selection which is undesirable in routine use. Like said, may have missed some "outlier". Think I can have that solution in a PR soon. Then I have a lot of other changes to incorporate as I said for Zen Cart 1.5.7 and in some cases just to align the code with the way I've been corrected for standard ZC code.

But, yes, if that feature is turned off then only the "final" price is displayed not the potential full price with the final price. Also, at the moment, dropdowns do not get the "strike-through" because standard dropdowns do not support html, have to use some sort of javascript based dropdown to do that, which is a desired feature not yet incorporated.

This appears to be resolved by the following Pull Request: https://github.com/mc12345678/Stock_.../pull/64/files

It does still apply the content to standard dropdowns which could be worked out; however, hasn't been removed (yet).

[mvstudio]

Like I said and you identified, backwards. :) I have a feeling that I was trying to find when not to apply the extra price display and then forgot to negate it so that it would show the extra price only when the item was discounted. I did discover that when I did that, that I also had to account for display only, default type attributes, otherwise it added 0.00 to the selection which is undesirable in routine use. Like said, may have missed some "outlier". Think I can have that solution in a PR soon. Then I have a lot of other changes to incorporate as I said for Zen Cart 1.5.7 and in some cases just to align the code with the way I've been corrected for standard ZC code.

But, yes, if that feature is turned off then only the "final" price is displayed not the potential full price with the final price. Also, at the moment, dropdowns do not get the "strike-through" because standard dropdowns do not support html, have to use some sort of javascript based dropdown to do that, which is a desired feature not yet incorporated.

LOL! I'm always identifying things opposite to everyone else I just didn't know that control would remove the weird behavior. I searched to see if someone else had reported it before I dare post, but I must have used the wrong keywords or something 'cause I didn't find any reference on it.
But of course you already knew what was happening, silly me For now at least the weird discount is out.

[mc12345678]

LOL! I'm always identifying things opposite to everyone else I just didn't know that control would remove the weird behavior. I searched to see if someone else had reported it before I dare post, but I must have used the wrong keywords or something 'cause I didn't find any reference on it.
But of course you already knew what was happening, silly me For now at least the weird discount is out.

Is it out because of turning off the option or modifying the code as referenced above?

It may not have been well documented, but when it was (again?) pointed out I at least remembered it was an area needing correction. I still prefer having the original price show before the discount price which would require a little more massaging to make it work out that way. May be easy through the use of some string replacements, but that's a topic of a different discussion.

Anyways, when I saw the code area and operation it reminded me again also of how it would be nice to implement an improved presentation for dropdown like attributes and I think that was something of the last straw that drove me to look for a couple (found two where one seemed a little better than the other) that supported html style code in the dropdown feature. Unfortunately they use javascript so still wanted to have a "plain text" offering for when javascript wasn't made available for one reason or another. Anyways, that meant that the issue didn't get resolved, though it at least should be better now.

[mvstudio]

Oh!!! I didn't see your post above. Sorry!

Turning off the option is what removed the discount appearing in the wrong place.

I'll download the update you posted, install it and let you know what I find.

Thank you!!

[mc12345678]

Oh!!! I didn't see your post above. Sorry!

Turning off the option is what removed the discount appearing in the wrong place.

I'll download the update you posted, install it and let you know what I find.

Thank you!!

Thank you for identifying the issue(s). Can't fix something that isn't identified. :) Look forwards to the feedback and any healthy discussion that may follow. :)

[mvstudio]

This appears to be resolved by the following Pull Request: https://github.com/mc12345678/Stock_.../pull/64/files

It does still apply the content to standard dropdowns which could be worked out; however, hasn't been removed (yet).

I made the changes and turned on SBA Original Price Struck Through. Here is what happened:

1) Items for which discounts do not apply show their regular price and no other price is displayed.
2) Items for which discounts do apply show their regular price and a (+$0.00) is displayed right next to it. No discounts displayed at all.

[mc12345678]

I made the changes and turned on SBA Original Price Struck Through. Here is what happened:

1) Items for which discounts do not apply show their regular price and no other price is displayed.
2) Items for which discounts do apply show their regular price and a (+$0.00) is displayed right next to it. No discounts displayed at all.

OK. Going to need to do a little sleuthing.
1) good. That is/was expected.
2) curious. Do you mind identifying the discount? Along with that the version of ZC (including sub-version as applicable)? I ask, because I did my test using a sale and the sale price showed along side the original price. I also thought this point in the code was where the final price was identified. Unfortunately, the final price as displayed at the product page is calculated a different way than when calculated on the shopping cart page and beyond.

[mvstudio]

OK. Going to need to do a little sleuthing.
1) good. That is/was expected.
2) curious. Do you mind identifying the discount? Along with that the version of ZC (including sub-version as applicable)? I ask, because I did my test using a sale and the sale price showed along side the original price. I also thought this point in the code was where the final price was identified. Unfortunately, the final price as displayed at the product page is calculated a different way than when calculated on the shopping cart page and beyond.

Not at all! You can see the behavior following this link https://www.byvalenti.com/index.php?...&products_id=4

I'm running ZC1.5.6c. I'm going to double check all the files just to make sure I didn't miss anything when I installed the pluggin that could possibly be the problem. I don't think, but just to make sure.

[mc12345678]

Not at all! You can see the behavior following this link https://www.byvalenti.com/index.php?...&products_id=4

I'm running ZC1.5.6c. I'm going to double check all the files just to make sure I didn't miss anything when I installed the pluggin that could possibly be the problem. I don't think, but just to make sure.

Is there a reason the "default" option (select Size) Isn't set as display only, default, and have a sort order of 0?

I'm guessing that the product is priced by attribute, that the product's price is 0 and that each of the attributes have a price applied to them, though if that were the case, then I would expect something other than 0 to be displayed in the second value field, So perhaps a price factor is being used and there is a base price applied to the product? That type of information would help to address/narrow down how to try to make the value(s) properly display if at all possible without JavaScript type code.

[mikebr]

zc 155e
Installed SBA 1.5.4 (github)
Weird problem surfaced
Three Attributes for (Product A)
1) style: radio button list
2) color: drop down
3) size: drop down

ISSUES

a)Using these attributes the first style attribute appears as a drop down not a radio button list?
b) If an additional attribute is added ( 4 attributes now) such as a text input the 1st style radio button list appears correct?

Configuration:
Dynamic drop downs
The first three options:

1) 2
2) sequenced drop downs
3) SBA sequenced Drop downs

Thanx
any help would be appreciated