Quote Originally Posted by lat9 View Post
"The Book" discusses identifying that the product is priced by attributes (note that the product's base price doesn't have to be 0.00) and then to use the attributes' settings to identify what each attribute "contributes" to the price.

I've got a test install of ZC1.5.5e and I'll give your suggested changes a try.

For your solution to @balihr's issue, is there any way to provide the proper result without using that constant definition? That's what threw me for a loop initially because it looks more like a band-aid than a programmatic solution.

So someone, at one point at or before ZC 1.5.0 decided that the calculated price when using the price factor should *possibly* be based on the provided $special value or perhaps not depending on whether the constant is defined as '1' or not... The reason provided by the blame history was that the constant may already be defined before its use in the shopping_cart class function calculate...

Thing is, that currently the only place in which the constant is defined is during the use of the calculate function of the shopping_cart class.. So, perhaps in say the checkout_payment area, if the shopping_cart class were called and either the calculate function was used or any of the show_total related functions, and then the order class was created, the solution wouldn't involve editing the shopping_cart class to add the constant test in the attributes_price function. This would instead modify the order of operations in order to ensure that an obscure constant was set in advance/outside the need of it really being set and almost "by accident". This would be a real PATCH/BAND-AID as compared to the constant being addressed in the code where it might actually apply. Further such a sequencing/resequencing would not yet assign the constant as might be needed for when other code tried to use the attributes_price function of the shopping_cart class.

Another solution relates back to the function that uses that constant (similar on both store and admin side) in any number of the below suggested ways:
the function zen_get_attributes_price_factor to always use $special if it is non-zero:
seems that there was a historical reason to have it pre-determined to need to be used as such. The other "parts" I was looking at in my previous (accidentally duplicated) post was a way to add a parameter to the function, which when defined/set would override the test within the function and blanketly apply the $special when the $special was non-zero (ie. remove dependency on the constant being defined/set).

Current function starts like:
Code:
// return attributes_price_factor 
   function zen_get_attributes_price_factor($price, $special, $factor, $offset) { 
     if (ATTRIBUTES_PRICE_FACTOR_FROM_SPECIAL =='1' and $special) {        // calculate from specials_new_products_price 
       $calculated_price = $special * ($factor - $offset); 
     } else {
No use of the constant:
Code:
// return attributes_price_factor 
   function zen_get_attributes_price_factor($price, $special, $factor, $offset) { 
     if (/* ATTRIBUTES_PRICE_FACTOR_FROM_SPECIAL =='1' and */$special) {        // calculate from specials_new_products_price 
       $calculated_price = $special * ($factor - $offset); 
     } else {
Keep the constant but add a parameter that must be set to true in order to calculate the price factored price based off of the provided $special price and the $special price not evaluating to false. This solution requires additional coding to provide/identify where this function should use the price factor/factor offset against the special price (if it exists) or not which likely would require a field off of the product's information page more than anything, or perhaps on the special's page, though that also seems a little buried:

Code:
// return attributes_price_factor 
   function zen_get_attributes_price_factor($price, $special, $factor, $offset, $attributes_price_factor_from_special = false) { 
     if ((ATTRIBUTES_PRICE_FACTOR_FROM_SPECIAL =='1' || $attributes_price_factor_from_special == true) and $special) {        // calculate from specials_new_products_price 
       $calculated_price = $special * ($factor - $offset); 
     } else {
Similar, but automatically considers all provided values to use the $special value until told otherwise, which is somewhat like what is happening in the calculate function of the shopping_cart, that until someone adds some software, codes a constant, etc, then the attributes' price_factor will be calculated from the special if there is one, if not then use the $price value.

Code:
// return attributes_price_factor 
   function zen_get_attributes_price_factor($price, $special, $factor, $offset, $attributes_price_factor_from_special = true) { 
     if ((ATTRIBUTES_PRICE_FACTOR_FROM_SPECIAL =='1' || $attributes_price_factor_from_special == true) and $special) {        // calculate from specials_new_products_price 
       $calculated_price = $special * ($factor - $offset); 
     } else {
Regarding the priced-by-attributes base price being zero or not, besides a number of postings indicating that other price "adjustments" don't fair well if a price other than zero is entered, found that the shopping_cart class doesn't do well/as might have been expected for this situation if a price is entered on the product page as well as in the attribute's value and a price factor applied... Somewhere in the process the attribute's price doesn't get factored like might be expected or at least differently than when the product's price is zero.