Dynamic Price Updater

[mc12345678]

i googled zen cart dynamic price update and found this

https://github.com/Zen4All-nl/Zen-Ca...-Price-Updater is it not the right one?

I'm not going to say no because Design75 stepped away from the code for a period of time during which I made modifications that "presumably" are incorporated into that version which at last look appeared to be being rewritten to consider installation to the oldest of either ZC 1.5.6 or ZC 1.5.7 (I don't recall). Initial transfer appeared to incorporate the latest that I had worked on as found at: https://github.com/mc12345678/Dynami...ter/tree/3.2.1 (Though I would recommend also incorporating https://github.com/mc12345678/Dynami...98e98562f548cb)

Ok the product is deffinately set to priced by attributes

Im not too sure what you meant by "For attributes, consider the settings for at least: Default and Base Price."

all the attributes in both colour and size are set to Display only X ,Free O, Default X, Discounted O ,Base Price O,Required X
(this where a screen shot would be handy if i could get one into the post)

I have tried turning the defaults on and off, setting all but one to either x or o,with and without setting free to x or o
I have also tried setting the priority of the options so that it did size first, with exactly the same result

Display only implies that the option should not be selected. Unfortunately I'm not sure I necessarily follow the meaning of X versus O. To me an X means that it is chosen and an O means that it is not. For a brief/quick explanation, default is intended to indicate that the attribute option will be marked for selection when the page is freshly loaded. There is a little bit of a caveat to that depending on the selection type. If it is a dropdown, then the last item marked for default is expected to be the active selection when the customer arrives at the product. If is a radio, then I believe the same is true (I've forgotten at the moment) of the last one or if made possible that all such radio buttons are selected, if it is a checkbox, then each item set as default is already selected for the customer.

If free is selected, then when the product is identified as being free (a priced-by-attributes product that has any attribute set to a non-zero price would not be considered free) then the attributes price is treated as free as well. The priority is a display situation not used to influence the "base" price. Discounted allows the discount applied to the product to also be applied to the attributes. Base Price supports identifying the lowest price of the product.

One thing identified by RixStix is that it is possible in some setups while using DPU that if a selection is not "pre-made" then the DPU response price is 0 until at least one selection is made. That said, I also just noticed that using 1.5.6c where the current released sub-version is 1.5.6f... There may be other issues in play as a result of not being up-to-date at least within the 1.5.6 series (1.5.7 has been issued as well).

All that said, for understanding, what happens with this plugin is basically, the page is displayed, the product is effectively added to the shopping cart with the "lowest priced" selections made, the price that results is returned for evaluation. At least in the work I did, there are multiple "conditions" evaluated. If no selections are made, then the customer is to basically be notified of what the smallest price expected would be, until all selections are made the customer is provided slightly different text intended to indicate that the final price hasn't been determined is provided, and once all selections have been made the "final" price of the product is displayed. Certainly the text variations can all be made the same if so desired, but I wanted to offer an opportunity to improve the customer experience in understanding their selections before attempting to add the selection(s) to the cart. I don't know if such is being carried over/on. I am sure that Design75 would appreciate more information about how to reproduce the issue so that it may be corrected, though also in looking at the github site I see that there is a development version that is being identified as 4.0.0 b4 I believe.

[torvista]

@mc12345678: your pm message quota is full, preventing more being received.

Just to let you know I am working on this (with ZC158). I have used the Zen4All develop branch as a starting point.
What put me off previously was the two repositories for reporting issues, each with it's own branches...but since he has consolidated fixes between three sources I'm just going to report issues on Erik's and PR my changes to that one.

When I have finished my fettling for my purposes I'll let you know so you can check out unresolved issues that may have been fixed on the way.
This is a very complicated mod to test as it can/should handle so many eventualities.....

[mc12345678]

@mc12345678: your pm message quota is full, preventing more being received.

Just to let you know I am working on this (with ZC158). I have used the Zen4All develop branch as a starting point.
What put me off previously was the two repositories for reporting issues, each with it's own branches...but since he has consolidated fixes between three sources I'm just going to report issues on Erik's and PR my changes to that one.

When I have finished my fettling for my purposes I'll let you know so you can check out unresolved issues that may have been fixed on the way.
This is a very complicated mod to test as it can/should handle so many eventualities.....

Thanks for the heads up on all fronts.

[torvista]

I'm looking at an issue to do with restricting its operation, and I must clarify for my own sanity that this should be processing the price only:

a) if a product has attributes that contain pricing data. So if all are zero, no need for DPU.
b) for any product on a cart quantity box change. So if no quantity box (or order quantity maximum is 1), no need for DPU.

Any other situations?