Trying to figure out why PRODUCTS ALSO PURCHASED is blank.

[Jeff_Mash]

This has to be something easy, right?

Our website is displaying the "Customers who bought this product also purchased..." box in the correct location. However, it's not displaying any products. It looks like this:



I am trying to figure out WHY it's not displaying the products.

1. I have tested it on a best selling product so I know there should be products being displayed.

2. This file exists: /includes/modules/responsive_classic/also_purchased_products.php

3. This file exists: /includes/templates/responsive_classic/templates/tpl_modules_also_purchased_products.php

I even went into the database to run the "Also Purchased" SQL query to verify that it returns values, and it does:



So any ideas what I can check to see why those results are not being displayed on the Product Info page?

[mc12345678]

Are you getting any debug logs on the topic? I don't see any additional html content being posted in that area, so its not like its a CSS thing:

<div class="centerBoxWrapper" id="alsoPurchased">
<h2 class="centerBoxHeading">Customers who bought this product also purchased...</h2></div>

Perhaps there is something turned off?

Why is there includes/templates/responsive_classic/templates/tpl_modules_also_purchased.php? What was modified about includes/templates/template_default/templates/tpl_modules_also_purchased.php that required a version in the responsive_classic template folder?

A default install does not include that file in the responsive_classic folder. Let's not even go through the discussion of why it is important to either clone an existing template or otherwise leave the default files alone... It would be at this point that normally would suggest to temporarily change templates to one of the default templates to see if the "feature" worked there and then troubleshoot... That said though, I suspect the problem is in the overridden version of the template file..

[Jeff_Mash]

Are you getting any debug logs on the topic? I don't see any additional html content being posted in that area, so its not like its a CSS thing:

<div class="centerBoxWrapper" id="alsoPurchased">
<h2 class="centerBoxHeading">Customers who bought this product also purchased...</h2></div>

Perhaps there is something turned off?

I was thinking something is turned off too......but the fact that the centerbox is being displayed makes me think that it's turned ON. My site is heavily modified so I'm positive this is something on my end which I'm overlooking.

Why is there includes/templates/responsive_classic/templates/tpl_modules_also_purchased.php? What was modified about includes/templates/template_default/templates/tpl_modules_also_purchased.php that required a version in the responsive_classic template folder?

No, it's not normally in this location. I actually put it there thinking it may fix something........but I have just removed it (keeping it only in the template_default location) and the behavior is the same.

A default install does not include that file in the responsive_classic folder. Let's not even go through the discussion of why it is important to either clone an existing template or otherwise leave the default files alone... It would be at this point that normally would suggest to temporarily change templates to one of the default templates to see if the "feature" worked there and then troubleshoot... That said though, I suspect the problem is in the overridden version of the template file..

Yeah, it looks like I may have to unzip some default ZC installations, do a WinMerge on things, and see what differences there are. I was just hoping it would be something easier to pinpoint before doing that since it may take me a while to walk through all the differences the WinMerge program is going to display.

Funny thing is that this used to work at some point, but I don't really know when it stopped. I just noticed it today and now it's become a nuisance to me! LOL

I appreciate you trying to help and offering things to help troubleshoot it.

[mc12345678]

Here's the 1.5.7 version of the template file: https://github.com/zencart/zencart/b...d_products.php

Thing is, the "meat" of what is displayed pretty much has nothing to do with that file specifically, but instead the then template file that is called to display "product" like information... so, again, off on another goose chase.

As far as being heavily modified, still can clone the current "rendition" of responsive_classic and then restore the responsive_classic folder(s) to original. As far as winmerge, well, likely issue to be seen is the line endings... I haven't used that one in a long while, but that was something that is an easy one to disable and then can also disable other "unimportant" characters, etc so that really only get bothered by the "real" changes.

[mc12345678]

And looking again at the two files involved based on the above response(s), I highly suspect it is something related to tpl_columnar_display.php or other "downstream" file. The modules file is outputting that there are results to be displayed, but the code that follows to actually put the content on the browser isn't working.

[Jeff_Mash]

I'm doing some digging, and here is what I'm seeing. Not sure what to make of it.

Specifically, I am focusing on the /modules/also_products_purchased.php file. I've narrowed down the reason (I think) why it's not displaying, but I still can't figure out why.

In that file, on Line #15, there is the following code:

$also_purchased_products = $db->ExecuteRandomMulti(sprintf(SQL_ALSO_PURCHASED, (int)$_GET['products_id'], (int)$_GET['products_id'], (int)MAX_DISPLAY_ALSO_PURCHASED));

To troubleshoot, I did a var_dump($also_purchased_products); to see what I was getting back from the query. This is what I was getting:

object(queryFactoryResult)#200 (9) { ["EOF"]=> bool(true) ["cursor"]=> int(0) ["fields"]=> array(0) { } ["is_cached"]=> bool(false) ["result"]=> array(0) { } ["result_random"]=> NULL ["limit"]=> int(0) ["resource"]=> object(mysqli_result)#205 (5) { ["current_field"]=> int(0) ["field_count"]=> int(3) ["lengths"]=> NULL ["num_rows"]=> int(3) ["type"]=> int(0) } ["link"]=> object(mysqli)#7 (19) { ["affected_rows"]=> int(3) ["client_info"]=> string(79) "mysqlnd 5.0.12-dev - 20150407 - $Id: 3591daad22de08524295e1bd073aceeff11e6579 $" ["client_version"]=> int(50012) ["connect_errno"]=> int(0) ["connect_error"]=> NULL ["errno"]=> int(0) ["error"]=> string(0) "" ["error_list"]=> array(0) { } ["field_count"]=> int(3) ["host_info"]=> string(25) "Localhost via UNIX socket" ["info"]=> NULL ["insert_id"]=> int(0) ["server_info"]=> string(6) "5.7.34" ["server_version"]=> int(50734) ["stat"]=> string(149) "Uptime: 986809 Threads: 1 Questions: 501126970 Slow queries: 0 Opens: 533363 Flush tables: 1 Open tables: 2000 Queries per second avg: 507.825" ["sqlstate"]=> string(5) "00000" ["protocol_version"]=> int(10) ["thread_id"]=> int(825040) ["warning_count"]=> int(0) } }

You can see that it returns the correct number of rows (3).....but also the EOF is true when I think it should be false.

So for good measure, I did a var_dump(SQL_ALSO_PURCHASED); in order to see what the database query looks like, and this is what is returned:

string(658) "SELECT p.products_id, p.products_image, max(o.date_purchased) as date_purchased FROM zen_orders_products opa, zen_orders_products opb, zen_orders o, zen_products p WHERE opa.products_id = %u AND opa.orders_id = opb.orders_id AND opb.products_id != %u AND opb.products_id = p.products_id AND opb.orders_id = o.orders_id AND p.products_status = 1 GROUP BY p.products_id, p.products_image ORDER BY date_purchased desc, p.products_id LIMIT %u"

So it seems to me like MAYBE something is wrong in the $db->ExecuteRandomMulti() on Line #15 which is causing the EOF to be true? I am clueless but I think I'm onto something.

On Line 32 where it enters the while (!$also_purchased_products->EOF), it doesn't go into that loop because of the TRUE EOF condition.



So it would seem like EOF needs to be FALSE in order to display the products, but it's returning EOF = True in the SQL results.

Any ideas on what else to do? The WinMerge test seems to show that my files are identical to the 1.5.7 release files.

[mc12345678]

I'm doing some digging, and here is what I'm seeing. Not sure what to make of it.

Specifically, I am focusing on the /modules/also_products_purchased.php file. I've narrowed down the reason (I think) why it's not displaying, but I still can't figure out why.

In that file, on Line #15, there is the following code:

$also_purchased_products = $db->ExecuteRandomMulti(sprintf(SQL_ALSO_PURCHASED, (int)$_GET['products_id'], (int)$_GET['products_id'], (int)MAX_DISPLAY_ALSO_PURCHASED));

To troubleshoot, I did a var_dump($also_purchased_products); to see what I was getting back from the query. This is what I was getting:



You can see that it returns the correct number of rows (3).....but also the EOF is true when I think it should be false.

So for good measure, I did a var_dump(SQL_ALSO_PURCHASED); in order to see what the database query looks like, and this is what is returned:



So it seems to me like MAYBE something is wrong in the $db->ExecuteRandomMulti() on Line #15 which is causing the EOF to be true? I am clueless but I think I'm onto something.

On Line 32 where it enters the while (!$also_purchased_products->EOF), it doesn't go into that loop because of the TRUE EOF condition.



So it would seem like EOF needs to be FALSE in order to display the products, but it's returning EOF = True in the SQL results.

Any ideas on what else to do? The WinMerge test seems to show that my files are identical to the 1.5.7 release files.

I thought I had looked over this section of code close enough that what I am now seeing wouldn't/couldn't happen, but have you happened to check in admin->configuration->Maximum Values for the value of Also Purchased Products? Is it empty or 0? I ask, because the value of 'limit' in the results is 0... Limit is expected to be set to the integer of `MAX_DISPLAY_ALSO_PURCHASED`...

My mistake around that area was that I thought the constant above (`MIN_DISPLAY_ALSO_PURCHASED`) was the same constant. Because above required it to be greater than 0, that to me meant that at least the minimum would be displayed... Those two values are in a way discrete and different. I don't mean different because they have different names, but from the concept of: must have at least this many also purchased product to consider presenting information. When looking at a list of presented information, only show this many... So on one hand could have umpteen thousand associated product but only show 3 or in a weird reverse way could have just one to show but want to be sure that no more than 6 are shown (when/if additional associated product become identified).



Hmmm... But that too doesn't make much sense, because the text that we are seeing is only supposed to appear if RecordCount > 0.... That would mean that there are supposed to be records to be shown... And the results are not cached...

What version of 1.5.7 are you using again?

[Jeff_Mash]

I thought I had looked over this section of code close enough that what I am now seeing wouldn't/couldn't happen, but have you happened to check in admin->configuration->Maximum Values for the value of Also Purchased Products? Is it empty or 0? I ask, because the value of 'limit' in the results is 0... Limit is expected to be set to the integer of `MAX_DISPLAY_ALSO_PURCHASED`...

The value I have in this variable is 3.

My mistake around that area was that I thought the constant above (`MIN_DISPLAY_ALSO_PURCHASED`) was the same constant. Because above required it to be greater than 0, that to me meant that at least the minimum would be displayed... Those two values are in a way discrete and different. I don't mean different because they have different names, but from the concept of: must have at least this many also purchased product to consider presenting information. When looking at a list of presented information, only show this many... So on one hand could have umpteen thousand associated product but only show 3 or in a weird reverse way could have just one to show but want to be sure that no more than 6 are shown (when/if additional associated product become identified).


Hmmm... But that too doesn't make much sense, because the text that we are seeing is only supposed to appear if RecordCount > 0.... That would mean that there are supposed to be records to be shown... And the results are not cached...

What version of 1.5.7 are you using again?

I am using the base 1.5.7. I haven't yet merged any of the minor release changes.

[Jeff_Mash]

I just wonder if the EOF value should be returning FALSE, and if not, why?

I mean, here is the SQL statement that is run:

SELECT p.products_id, p.products_image, max(o.date_purchased) as date_purchased FROM zen_orders_products opa, zen_orders_products opb, zen_orders o, zen_products p WHERE opa.products_id = %u AND opa.orders_id = opb.orders_id AND opb.products_id != %u AND opb.products_id = p.products_id AND opb.orders_id = o.orders_id AND p.products_status = 1 GROUP BY p.products_id, p.products_image ORDER BY date_purchased desc, p.products_id LIMIT %u

If I go to MySql Admin and manually run that command (replacing the %u with an actual product id and the LIMIT number 3), it works and I get three rows returned to me.

But when it's run in the PHP file, it is returning EOF = TRUE which causes it not to enter the While Loop.

[mc12345678]

Honestly, I haven't read the most recent (yet) but I will. Reason I haven't is because this is a known issue with ZC 1.5.7 (pre some sub-version) and is shown as corrected at this post: https://www.zen-cart.com/showthread....00#post1371700

Note, that is a "long" way down the list of the known issues and is a reason that should apply the latest at any/all opportunities. For info, won't *have* to run zc_install to do an in version upgrade, just have to apply the file changes... further a reason that a template being used be independent of the core version of that template so that the changes are "easier" to see and can be understood.