Dynamic Price Updater

[mc12345678]

Forgot to add that I wasn't sure if there was some sort of "security" concern or other tidbit that I wasn't aware of. I've got a post prepared at least to address that issue which may help others like the tidbits that I found in this forum to address errors encountered.

FWIW, generally speaking with addressing the few issues encountered, this code does/can be used with Stock By Attributes (specifically when using multiple attributes and dynamic dropdowns as implemented in the github version). I haven't worked through the initial display of a 0 price instead of starting at, but I think while reviewing the thread that it is addressed.

[Design75]

Forgot to add that I wasn't sure if there was some sort of "security" concern or other tidbit that I wasn't aware of. I've got a post prepared at least to address that issue which may help others like the tidbits that I found in this forum to address errors encountered.

FWIW, generally speaking with addressing the few issues encountered, this code does/can be used with Stock By Attributes (specifically when using multiple attributes and dynamic dropdowns as implemented in the github version). I haven't worked through the initial display of a 0 price instead of starting at, but I think while reviewing the thread that it is addressed.

It would be nice if this mod could be rebuild to work nice with SBA. I always cheated 0 price issue with setting the base price to 0.0001. Not a good solution (I know), but it worked).
I the new mod is written properly it may make a chance to get incorporated into the core code

[Kcin]

So what is the final consensus? Is that officially broken on 1.55a? Are there any alternatives? I'd rather have an updated price on the fly so I can get rid of hte (+3.00) in the attributes drop down.

[mc12345678]

So what is the final consensus? Is that officially broken on 1.55a? Are there any alternatives? I'd rather have an updated price on the fly so I can get rid of hte (+3.00) in the attributes drop down.

Functional with minor modification as either described in this thread or as identified through troubleshooting with browser's tools (F12).

There are some github forks with a few already included modifications to address some of the items/issues. But it does or relatively can work with ZC 1.5.5a.

[Kcin]

Functional with minor modification as either described in this thread or as identified through troubleshooting with browser's tools (F12).

There are some github forks with a few already included modifications to address some of the items/issues. But it does or relatively can work with ZC 1.5.5a.

I know just enough to get me by, I'm not sure I have it in me to trouble shoot and correct code. Oh well. Thanks!

[mc12345678]

I know just enough to get me by, I'm not sure I have it in me to trouble shoot and correct code. Oh well. Thanks!

Haven't fully tested all possibilities but I have done a little updating on github to at least address the code that breaks operation. It's not like a huge modification, but I'm using it on a test 1.5.5 site with success so far.

[mc12345678]

Internet service caused this to be double posted. Original duplicate removed.

[mc12345678]

So what is the final consensus? Is that officially broken on 1.55a? Are there any alternatives? I'd rather have an updated price on the fly so I can get rid of hte (+3.00) in the attributes drop down.

As to the (+3.00), I don't know why you wouldn't want to indicate to the customer that the option being chosen affects the price in some way rather than the possibility that if they 1) have javascript disabled or 2) fail to see the change in price upon selection for some other reason and then not realize how the prices play out.

[Kcin]

The prices are listed pretty large and noticeable. You would see it change, I have no doubt. The (+3.00) just looks jenky. Look at any large corporate website and show me one where the options change like that. I may just end up changing the code so it just has the price and remove the + and price everything by attribute.

Plus, I have some products that the attribute just increases the price, and I have other products that are priced by attribute. On those priced by attribute, the price is listed as the smallest amount from attributes. Lets say $5.00. So now the listing says "Starting at $5.00" and when you hit the list of drop down attributes, you have one attribute that sets the price to (+$10.00). I think to the average consumer, they are going to see the "starting at $5.00" and then see the (+$10.00) and assume it costs $15, when in fact it's just $10.00.

IMO, updating the price on the fly by attribute makes way more sense whether you keep the additional display in the attribute or not.

[mc12345678]

The prices are listed pretty large and noticeable. You would see it change, I have no doubt. The (+3.00) just looks jenky. Look at any large corporate website and show me one where the options change like that. I may just end up changing the code so it just has the price and remove the + and price everything by attribute.

Plus, I have some products that the attribute just increases the price, and I have other products that are priced by attribute. On those priced by attribute, the price is listed as the smallest amount from attributes. Lets say $5.00. So now the listing says "Starting at $5.00" and when you hit the list of drop down attributes, you have one attribute that sets the price to (+$10.00). I think to the average consumer, they are going to see the "starting at $5.00" and then see the (+$10.00) and assume it costs $15, when in fact it's just $10.00.

IMO, updating the price on the fly by attribute makes way more sense whether you keep the additional display in the attribute or not.

So you know the + in (+$10) is not required. Particularly isn't needed in such a price-by-attribute condition where the value of the entire product is based on the value of the attribute and not by some form of increase/decrease.

As to using the +$3 scenario for a product not priced by attributes, got ya thinking didn't I? So, I have seen a site that actually changes the option listings based on which attribute was selected, though I can't recall which it was. Basically, if starting at the "base" model, some attributes had +x, others might have -y, once one of them was selected say +x, then the -y value changed to the result of -y-x... this way one knew that based on selecting a particular value from the list the price would change by this much and in this direction.

As to the "big price change" again, I resort back to conditions where javascript is disabled or more rarely not available. It is advisable to ensure that the maximum audience can be reached without sacrificing the "needs" of the many.

Oh, and BTW, there is no code change needed to remove the +, simply don't put a negative or anything in the box to the left of the attribute price in the attributes controller.