Dynamic Price Updater

[mani]

I copied the contents of the file from classes/dynamic_price_updater.php from

https://github.com/mc12345678/Dynami...ce_updater.php

and now it doesnt create a log file
Is it the right approach?

Module version installed is downloaded from
https://www.zen-cart.com/downloads.php?do=file&id=1301

and only
classes/dynamic_price_updater.php has been updated from github!

[mc12345678]

Is this version of this module GitHub
https://github.com/Zen4All-nl/Zen-Ca...eases/tag/v3.1

Same as this one
https://www.zen-cart.com/downloads.php?do=file&id=1301 ?

In Github version there is no ajax folder in includes/classes

If I install GitHub version will it work with 1.5.5e?

No those two versions are no longer the same. While Design75 and I have been talking about moving forward with DPU, we haven't synced (yet) the two distributions. They remain linked however to be able to see the branch history and to locate an updated version.

I copied the contents of the file from classes/dynamic_price_updater.php from

https://github.com/mc12345678/Dynami...ce_updater.php

and now it doesnt create a log file
Is it the right approach?

Module version installed is downloaded from
https://www.zen-cart.com/downloads.php?do=file&id=1301

and only
classes/dynamic_price_updater.php has been updated from github!

After issue of 3.0.7, the bug described above was located and corrected on github in the master branch (similar location as identified above, but more "flexible" to reference because it would be up-to-date with the remainder of the software). Considering that for operations sake the only file really changed since 3.0.7 was the includes/classes/dynamic_price_updater.php file, updating the current install with that file is the way to go.

I am working on some additional functionality for the next ZC update such that the starting at: related text would/should be updated from say 'starting at:' (basically for the default values and/or no selections made) to 'at least:' (some selections have been made, but not all that are effectively required and based on attributes being included in the base price through the attributes controller) and then 'Your Price:' once all options have been selected, again somewhat based on the attribute(s) being identified as included in the base price. Still working through some of the "complexities" of options like check boxes (no requirement for one to be selected), text boxes that have pricing applied to the content, radio buttons that don't have a default value (potentially allowing submission of the product without having selected a radio button option which is a flexibility offered by the ZC software).

So yes, the action taken was a good approach to the issue identified in particular that the change(s) made to that file specifically were intended to address the issue observed here in post #1319. :) Had the solution not been there, then posting here about the issue or initiating an issue log on github should support getting the problem corrected once confirmed as an issue.

[Design75]

After i am back frommy summer holiday, I will update my repos to match the MC versoin

No those two versions are no longer the same. While Design75 and I have been talking about moving forward with DPU, we haven't synced (yet) the two distributions. They remain linked however to be able to see the branch history and to locate an updated version.



After issue of 3.0.7, the bug described above was located and corrected on github in the master branch (similar location as identified above, but more "flexible" to reference because it would be up-to-date with the remainder of the software). Considering that for operations sake the only file really changed since 3.0.7 was the includes/classes/dynamic_price_updater.php file, updating the current install with that file is the way to go.

I am working on some additional functionality for the next ZC update such that the starting at: related text would/should be updated from say 'starting at:' (basically for the default values and/or no selections made) to 'at least:' (some selections have been made, but not all that are effectively required and based on attributes being included in the base price through the attributes controller) and then 'Your Price:' once all options have been selected, again somewhat based on the attribute(s) being identified as included in the base price. Still working through some of the "complexities" of options like check boxes (no requirement for one to be selected), text boxes that have pricing applied to the content, radio buttons that don't have a default value (potentially allowing submission of the product without having selected a radio button option which is a flexibility offered by the ZC software).

So yes, the action taken was a good approach to the issue identified in particular that the change(s) made to that file specifically were intended to address the issue observed here in post #1319. :) Had the solution not been there, then posting here about the issue or initiating an issue log on github should support getting the problem corrected once confirmed as an issue.

[Calljj]

Firstly, many thanks for this mod, installed and worked straight away, can't believe its taken me so long to get around to using it!

A quick ask, incase i'm missing it, but when products are on discount (and priced by attributes) the discounted prices updates and displays all fine without error, but the "original" price (the one crossed out - reference span normalPrice) doesn't change to reflect the difference of original prices.

[mc12345678]

Firstly, many thanks for this mod, installed and worked straight away, can't believe its taken me so long to get around to using it!

A quick ask, incase i'm missing it, but when products are on discount (and priced by attributes) the discounted prices updates and displays all fine without error, but the "original" price (the one crossed out - reference span normalPrice) doesn't change to reflect the difference of original prices.

Glad that you found this then. :)

That is correct for the current operation, basically it updates the "bottom line" for the customer as determined by the shopping_cart class. At this time, it does not update each of the other associated price displays.

Edits can be made to modify what is displayed/replaced to support other presentations, but that is currently outside of the base coding of this module.

[Calljj]

That's a shame as it confuses the customers on sale items especially if there is a big price difference between the cheapest and the most expensive attribute- when for example the normal price of £5 is struck through, it says save 25% and then the 'sale' price says £100!

[mc12345678]

That's a shame as it confuses the customers on sale items especially if there is a big price difference between the cheapest and the most expensive attribute- when for example the normal price of £5 is struck through, it says save 25% and then the 'sale' price says £100!

Right, but the struck through price should say starting at. Now, you could also do other things with the code to have it simply replace the whole value once selections have begun to be made or not display the crossed through price, etc... right now though that's an extra feature that is not (yet) in my own priority list, unfortunately. It does strengthen my thought (if not already captured in say ZC 1.6.0) of a "price" function that returns all of the values associated with price display. Right now the vprice value returned is just the bottom line. Other prices could be determined, fed and then displayed. At the moment with this plugin id like the display to change as each priced by attribute attribute is selected or at least in the three conditions that the text is modified (starting at, at least, and your price).

[mc12345678]

@Calijj,

I created an issue on github: https://github.com/mc12345678/Dynami...ater/issues/10 to address/track this.

[Calljj]

@Calijj,

I created an issue on github: https://github.com/mc12345678/Dynami...ater/issues/10 to address/track this.

Thanks you for adding, i do feel like this would be a valid part of the module.

[Calljj]

on a tangent.. i have a finance calculator that uses the "base price" of a product when the products_page is loaded and gives payment information to the customer. lets call this finance_calc.php. Could you point me in the direction that i could tap into getting the current price of the option that is displayed to then pass across and reload the finance_calc.php.
This would enable the ultimate for me, which is the all the deposit ammounts, terms etc would all change to reflect the different attributes as they are selected. happy to fund this if that's what is required.