Dynamic Price Updater

Can anyone provide a reason why this code should claim all onchange, onkeyup, and onselect javascript actions for applicable attribute types rather than sharing those actions with other javascript code or be required to be in some way loaded after the other javascript code?

mc12345678:

Can anyone provide a reason why this code should claim all onchange, onkeyup, and onselect javascript actions for applicable attribute types rather than sharing those actions with other javascript code or be required to be in some way loaded after the other javascript code?

Nope,

The code is ancient, and in the past there probaly was a reason, or the original coder did not now or had no better reason to do it another way. I have been planing on updating the codebase for a long tome, but am lacking the time. If you want to update this mod be my guest :D

Design75:

Nope,

The code is ancient, and in the past there probaly was a reason, or the original coder did not now or had no better reason to do it another way. I have been planing on updating the codebase for a long tome, but am lacking the time. If you want to update this mod be my guest :D

In a very small part that was something I was considering, but I'm truly just stepping into this game. :blush: Recalled maybe 2 years ago installing it somewhere and having to make a change so that the actions of this plugin and another would fire, but didn't remember that this last weekend when I was again trying to get it to play nice with another javascript action. Do you happen to have your code on github or otherwise available?

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.

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.

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

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.

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.

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:

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.

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:

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!

Kcin:

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.

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

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.

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.

mc12345678:

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.

Kcin:

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/Dynamic_Price_Updater/tree/mc12345678-sidebox-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.

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.

Design75:

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-cigarettes/for-advanced-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!

mc12345678:

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/Dynamic_Price_Updater/tree/mc12345678-sidebox-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.

Hey mc12345678,
I tried the latest fork from github: https://github.com/mc12345678/Dynamic_Price_Updater/tree/mc12345678-sidebox-possibly
However, the price always shows as $0... Using ZC 1.5.5a - will this work, or is there something extra I need to do?
Thanks,
Chris

clange:

Hey mc12345678,
I tried the latest fork from github: https://github.com/mc12345678/Dynamic_Price_Updater/tree/mc12345678-sidebox-possibly
However, the price always shows as $0... Using ZC 1.5.5a - will this work, or is there something extra I need to do?
Thanks,
Chris

How do you have your attributes setup? Product priced by attributes? Sample page of where this issue is occurring? (can obscure the address slightly if wish).

mc12345678:

How do you have your attributes setup? Product priced by attributes? Sample page of where this issue is occurring? (can obscure the address slightly if wish).

Here is an example page:
https://tacunasystems.com/zc/index.php?main_page=product_info&cPath=10_9_14&products_id=271

However, I've disabled the plugin as the site is live. Maybe I could PM you and enable the plugin so you can see it?
Thanks so much!
Chris