Dynamic Price Updater

[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.

[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]

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.

[Kcin]

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.

Ahhh. Very nice.

I changed my approach after our exchange. I just defaulted what I believe to be the "main" variant, and then price goes up and down from there. So I'm okay with leaving the additional info, but I would still love to have the price update on the fly, because for instance, the product I just listed it's primary price is $27, it's sample price is 1/5th of that, so $5.40, and the attribute pricing for that is (-$21.60). When you select that though, the customer won't know the price until they add it to their cart or do the math. It would be nice if they could quickly see the price change, and then the attribute is there for backup in the scenario you detailed where the updater might not work.

Did you already post the link in this thread to your tweaked version? I'd like to give it a try.

[mc12345678]

Ahhh. Very nice.

I changed my approach after our exchange. I just defaulted what I believe to be the "main" variant, and then price goes up and down from there. So I'm okay with leaving the additional info, but I would still love to have the price update on the fly, because for instance, the product I just listed it's primary price is $27, it's sample price is 1/5th of that, so $5.40, and the attribute pricing for that is (-$21.60). When you select that though, the customer won't know the price until they add it to their cart or do the math. It would be nice if they could quickly see the price change, and then the attribute is there for backup in the scenario you detailed where the updater might not work.

Did you already post the link in this thread to your tweaked version? I'd like to give it a try.

Something to keep in mind with your attribute pricing seeing as you offer a sample of a product is the effect of any pricing "arrangement" on "published" pricing and others searching for that product based on the "base" price.

As to posting the link, I had not. Partially because although I was trying to get everything modified merged into one branch and tested a few additional things about it. I was able to update the changes onto a test site and didn't get JS errors but I didn't totally have a chance to compare the code at that state with the original code to see if one of the issues had really been corrected or just simply "ignored".

Anyways, I have a forked copy of what looks like the current version found at:
https://github.com/mc12345678/Dynamic_Price_Updater
with all of the changes I have made found at:
https://github.com/mc12345678/Dynami...debox-possibly

The changes include a little data sanitization and then action taken to permit "fair play" with other javascript code affecting the product_info page, and I think I have prevented one of the objSB errors related to the sidebox from becoming an issue with a default install, but could still be implemented with an appropriate code change where some additional comment was added to describe what may be necessary to use that feature.

[strelitzia]

Is it possible to make this work in conjunction with the inc/ex vat mod?
With the VAT mod installed it displays both prices on the product page but adding DPU it replaces that with a single price only.
I know that the price output on the product info page uses get_products_display_price instead of zen_get_products_display_price so I tried changing that in jscript_dynamic_price_updater.php but it didn't work.
I'm assuming that something will need to be coded into the function prepareOutput() found in the class file.

[strelitzia]

For DPU to work on the product listing you would have to rewrite the whole DPU mod

I've seen it working on the product listing pages. I coded this site so I know it can be done.
Go to https://www.liberro.co.uk/electronic...dvanced-vapers and then look at product Aspire Plato All in One Kit. Click the Select Options button and the attributes will pop up. Select the option to add a Mains Charger and you will see the listing price updates after you click the Finished button.
I can't remember how much I had to do on DPU to get it working as that site has had a LOT of customisation to get attributes to display on listings.
Slightly off the DPU topic, but it's so heavily modified that it even displays all products within sub categories on a single page, as can be seen here https://www.liberro.co.uk/ecig-liquid-uk. That took a fair bit of work too!