Product pricing is missing when salemaker is applied to category

[PopularCrustacean]

I recently checked in on one of my SaleMaker sales and noticed the pricing is missing on the product display page.

The effected products are showing the discounted price from the admin page, as well as in the cart after selecting the product. However the price field is totally blank when browsing through products. The prices reappear when i disable the sale.

I have another sale in place on a different category that is working perfectly. When comparing the two categories and the products they contain from phpmyadmin, everything appears to be the same.

The effected products are within this category: http://populargreetings.com/index.ph...ndex&cPath=498

I have confirmed (via phpmyadmin) that the sale is applying to the right category ID's, and that the effected products are configure with a master category ID.

[mc12345678]

This appears that it could be related to more other factors than just the base category or product information (ie products table), in order to support a sale or a special, there are a number of other tables involved. Then also don't know if the WHOLESALE price is provided by a separate add-in or if it was just a modification of existing text. There is not really much information presented in the source code of the response page to be able to evaluate anything and there doesn't appear to be a way to identify where this other sale is at that is working perfectly in order to perform any type of a comparison such as does the other sale sell in quantities/units/minimums, etc...

Would suggest answering the questions related to the posting tips. Also to compare the products price manager (admin->Catalog->Products Price Manager) screen for each product/category comparing a functional product to one that is not to see if perhaps a setting is different between the two. And any additional information that can be provided about how to reproduce the issue would be of benefit.

[PopularCrustacean]

My site is 1.5.1, updated from 1.3.8 > 1.3.9 > 1.5.1. Updates installed with official procedure. I'm running PHP 5.6.29 and MySQL 5.6.33. The WHOLESALE PRICE is just a modification of text on the product page. Here is an example of a sale (created in salemaker) that is working correctly: http://populargreetings.com/index.ph...th=497_255_266

I'm not aware of an changes that would have caused this. The sale itself has not changed in some time. As for addons, im running salemaker and my own stock control plugin.

I took a look in the price manager, and everything appears to be the same between products that are working and those that are not, right down to where the sale is listed that the top. Both items show the correct sale with the original price crossed out and the sale price and percentage listed in red. The only difference is the sale quantity (changing this does not resolve the issue). The issue is specific to the category I linked in my first post for some reason. I've checked the category configuration as well, which appears to match. I have also updated my currencies.

You mention that there are other tables involved, perhaps i could check those as well? Let me know if there is any other information that would help. Thank you!

[mc12345678]

My site is 1.5.1, updated from 1.3.8 > 1.3.9 > 1.5.1. Updates installed with official procedure. I'm running PHP 5.6.29 and MySQL 5.6.33. The WHOLESALE PRICE is just a modification of text on the product page. Here is an example of a sale (created in salemaker) that is working correctly: http://populargreetings.com/index.ph...th=497_255_266

I'm not aware of an changes that would have caused this. The sale itself has not changed in some time. As for addons, im running salemaker and my own stock control plugin.

I took a look in the price manager, and everything appears to be the same between products that are working and those that are not, right down to where the sale is listed that the top. Both items show the correct sale with the original price crossed out and the sale price and percentage listed in red. The only difference is the sale quantity (changing this does not resolve the issue). The issue is specific to the category I linked in my first post for some reason. I've checked the category configuration as well, which appears to match. I have also updated my currencies.

You mention that there are other tables involved, perhaps i could check those as well? Let me know if there is any other information that would help. Thank you!

So, not sure if it is directly related, but ZC 1.5.1 was not designed to be operational with PHP 5.6 (highest of PHP 5.3 is supported, though changes could be made for it to work in PHP 5.6 which appear to have been the case here), real suggestion would be to upgrade to ZC 1.5.5e (current production release) and then try to address any issues that might exist (which in the upgrade process would be hammered out in the development location).

As to possibly tracking down the issue, two pronged approach somewhat. One would be to use the developers tool kit (admin->tools->developers tool kit) to try to work through the code and possibly identify why no price is shown on your category that has the sale, but is displaying on the other category that has the sale. Would suggest searching on the text: prodlisting_price as that appears to be the html tag that is applied just before the price is supposed to be displayed.

Does this category/product also have a special applied to it or anything? Is there a quantity discount associated with it?

The other approach of the two pronged approach is to try temporarily switching to a different template to see how template related the issue is as compared to possibly one or more of the "constant" (core related) files.

Another question to help try to diagnose, when was this last seen as working as expected and what has changed since then?

[PopularCrustacean]

So, not sure if it is directly related, but ZC 1.5.1 was not designed to be operational with PHP 5.6 (highest of PHP 5.3 is supported, though changes could be made for it to work in PHP 5.6 which appear to have been the case here), real suggestion would be to upgrade to ZC 1.5.5e (current production release) and then try to address any issues that might exist (which in the upgrade process would be hammered out in the development location).

As to possibly tracking down the issue, two pronged approach somewhat. One would be to use the developers tool kit (admin->tools->developers tool kit) to try to work through the code and possibly identify why no price is shown on your category that has the sale, but is displaying on the other category that has the sale. Would suggest searching on the text: prodlisting_price as that appears to be the html tag that is applied just before the price is supposed to be displayed.

Does this category/product also have a special applied to it or anything? Is there a quantity discount associated with it?

The other approach of the two pronged approach is to try temporarily switching to a different template to see how template related the issue is as compared to possibly one or more of the "constant" (core related) files.

Another question to help try to diagnose, when was this last seen as working as expected and what has changed since then?

So I've done a fair bit of investigation using the developers tool kit, and the most relevant file where 'prodlisting_price' appears is 'product_listing.php'. I noticed the file was changed in April so i reverted to a backup but that did not resolve me issue.

Looking into the 'product_listing.php' file, the price appears to be coming from this section of code:

case 'PRODUCT_LIST_PRICE':
        if (zen_not_null($listing->fields['products_packedin_units'])) {
        $packedin = '<br />' . $listing->fields['products_packedin_units'] ; }
        else {
        $packedin = '';}
        $lc_price = '<span class="prodlisting_price">' . zen_get_products_display_price($listing->fields['products_id']) . '</span><br /><span class="prodlisting_itemnum">Sold in ' . zen_get_products_quantity_order_min($listing->fields['products_id']) . "'s". '</span>'; 
        $lc_align = 'right';
        $lc_text =  $lc_price; 

I've been staring at this code.. and i don't see any issues. Perhaps someone else can make sense of this?

[PopularCrustacean]

So, not sure if it is directly related, but ZC 1.5.1 was not designed to be operational with PHP 5.6 (highest of PHP 5.3 is supported, though changes could be made for it to work in PHP 5.6 which appear to have been the case here), real suggestion would be to upgrade to ZC 1.5.5e (current production release) and then try to address any issues that might exist (which in the upgrade process would be hammered out in the development location).

As to possibly tracking down the issue, two pronged approach somewhat. One would be to use the developers tool kit (admin->tools->developers tool kit) to try to work through the code and possibly identify why no price is shown on your category that has the sale, but is displaying on the other category that has the sale. Would suggest searching on the text: prodlisting_price as that appears to be the html tag that is applied just before the price is supposed to be displayed.

Does this category/product also have a special applied to it or anything? Is there a quantity discount associated with it?

The other approach of the two pronged approach is to try temporarily switching to a different template to see how template related the issue is as compared to possibly one or more of the "constant" (core related) files.

Another question to help try to diagnose, when was this last seen as working as expected and what has changed since then?

So I've done a fair bit of investigation using the developers tool kit, and the most relevant file where 'prodlisting_price' appears is 'product_listing.php'. I noticed the file was changed in April so i reverted to a backup but that did not resolve me issue.

Looking into the 'product_listing.php' file, the price appears to be coming from this section of code:

case 'PRODUCT_LIST_PRICE':
        if (zen_not_null($listing->fields['products_packedin_units'])) {
        $packedin = '<br />' . $listing->fields['products_packedin_units'] ; }
        else {
        $packedin = '';}
        $lc_price = '<span class="prodlisting_price">' . zen_get_products_display_price($listing->fields['products_id']) . '</span><br /><span class="prodlisting_itemnum">Sold in ' . zen_get_products_quantity_order_min($listing->fields['products_id']) . "'s". '</span>'; 
        $lc_align = 'right';
        $lc_text =  $lc_price; 

I've been staring at this code.. and i don't see any issues. I guess the 'lc_text' variable is null for some reason?

Perhaps someone else can make sense of this?

[mc12345678]

So I've done a fair bit of investigation using the developers tool kit, and the most relevant file where 'prodlisting_price' appears is 'product_listing.php'. I noticed the file was changed in April so i reverted to a backup but that did not resolve me issue.

Looking into the 'product_listing.php' file, the price appears to be coming from this section of code:

case 'PRODUCT_LIST_PRICE':
        if (zen_not_null($listing->fields['products_packedin_units'])) {
        $packedin = '<br />' . $listing->fields['products_packedin_units'] ; }
        else {
        $packedin = '';}
        $lc_price = '<span class="prodlisting_price">' . zen_get_products_display_price($listing->fields['products_id']) . '</span><br /><span class="prodlisting_itemnum">Sold in ' . zen_get_products_quantity_order_min($listing->fields['products_id']) . "'s". '</span>'; 
        $lc_align = 'right';
        $lc_text =  $lc_price;

I've been staring at this code.. and i don't see any issues. I guess the 'lc_text' variable is null for some reason?

Perhaps someone else can make sense of this?

Actually, $lc_text is not null, because at least once one gets down to a category that has product, the text: Sold in X's is displayed which is the second part of $lc_price as highlighted in red above. The part that is "null" is from the section of code in blue assuming that it is only provided/used in that override file. I say this because, when looking at the current source code of the problem link above, there are two entries of class="prodlisting_price" for a product such as can be seen for Anniversary with the url parameter of: &cPath=498_429_432

The function in blue: zen_get_products_display_price is typically located in includes/functions/functions_price.php and is a non-overrideable file, but perhaps it has been modified. It or one of the files called by that function could also have been modified to support some other customization.

Something off the bat in review of the ZC vanilla code for that function is if the product type of the products is set to 3 (would have to evaluate in phpMyAdmin or similar) then the "price" is blank. The product type of 3 is typically associated with a product being assigned as a document general product type, but modifications in the code could be made to have that value serve as something else. Unfortunately though it seems that if it were a product type of 3, then the individual product info page should reflect that it was a document general product unless something else has been modified to make this product type "act" like a product general product.

[PopularCrustacean]

Actually, $lc_text is not null, because at least once one gets down to a category that has product, the text: Sold in X's is displayed which is the second part of $lc_price as highlighted in red above. The part that is "null" is from the section of code in blue assuming that it is only provided/used in that override file. I say this because, when looking at the current source code of the problem link above, there are two entries of class="prodlisting_price" for a product such as can be seen for Anniversary with the url parameter of: &cPath=498_429_432

The function in blue: zen_get_products_display_price is typically located in includes/functions/functions_price.php and is a non-overrideable file, but perhaps it has been modified. It or one of the files called by that function could also have been modified to support some other customization.

Something off the bat in review of the ZC vanilla code for that function is if the product type of the products is set to 3 (would have to evaluate in phpMyAdmin or similar) then the "price" is blank. The product type of 3 is typically associated with a product being assigned as a document general product type, but modifications in the code could be made to have that value serve as something else. Unfortunately though it seems that if it were a product type of 3, then the individual product info page should reflect that it was a document general product unless something else has been modified to make this product type "act" like a product general product.

I ended up pulling a backup of my functions_price.php file from prior to its last modified date, and ended up resolving my issue. It looks like one of the sites co-contributors added some code here that caused this issue. Not sure if it was a direct edit or a plugin install, but i'm on the case.

Thank you very much for pointing me in the right direction mc12345678! I wouldn't have solved the problem without your help.

[mc12345678]

I ended up pulling a backup of my functions_price.php file from prior to its last modified date, and ended up resolving my issue. It looks like one of the sites co-contributors added some code here that caused this issue. Not sure if it was a direct edit or a plugin install, but i'm on the case.

Thank you very much for pointing me in the right direction mc12345678! I wouldn't have solved the problem without your help.

Well, glad you figured it out. Unfortunate that a problem was introduced, but I can recall at one point or another that some plugin or another caused a price display issue by not considering some feature/aspect of possible pricing. If you kept a copy of the broken file you could always do a comparison of it to a default version and figure it out, of course also talking with the coeditor could help determine the origin of the issue. :) but glad that the issue has been corrected. :)

Remember that having a development site on which such changes could first be tested before placing live online makes life easier. :)