which file calls tpl_index_product_list.php?

I am trying to create a separate product-listing display for the Documents General product type. My preferred method would be to copy the product-listing files (tpl_index_product_list.php, tpl_modules_product_listing, and if necessary even product_listing.php) and customize them to process Documents General requests in the particular way I want. That's easy enough, but for it to work I need to modify the file that calls them in the first place so that it redirects Documents General requests to the custom files. Unfortunately, in my ignorance, I just can't figure out which file calls tpl_index_product_list.php. I would expect it to be the same file in which the switch "Skip 1-prod Categories" get processed, since that switch performs a gate-keeper function similar to the one I want to add, but I can't manage to find that one, either, since I don't know what the switch is called outside of the Admin interface.

I've spent hours doing every search I can think of, both in Developers Tool Kit and on this site, without success, driving myself to such a point that I'm actually willing to ask for help (!).

So, to boil this down:

1. which file does call tpl_index_product_list.php;
2. is that even the file I need, and if not, which one is;
3. is there some handy online resource I have somehow overlooked that would have answered this question for me without bothering all of you?

Many thanks!

Try
/includes/modules/pages/index/main_template_vars.php

That's the one! Thanks, Kobra. I really appreciate it. Unfortunately, now that I'm there, I can't figure out the right formulation for the crucial if/then statement that distinguishes the product type. I know the product type id for Documents General is 3, and I've tried any number of formulations to get there, but none of them have worked. That leaves me with:

if [perplexing mystery variable] == 3 {

$tpl_page_body = 'tpl_index_document_list.php';

} else {
$tpl_page_body = 'tpl_index_product_list.php';
}

Any suggestions? Sorry to be so helpless. Actually, I do seem to be okay at figuring out existing code and tweaking it, but I don't know php and Zen Cart well enough to figure out how to do things I can't find a model to imitate. Thanks again.

Document-General is a "product type".
And the product-type is specific to each product, not to the list.

So then the question is ... what if the products in the list are of mixed product-types? Then what do you expect it to do?

Aside: what's this alternate product-listing "display" intended to look like? What are you doing unique with it?

Thank you for your reply, Dr. Byte. To answer your questions in reverse order:

My business, in addition to having a small online component, sells its products wholesale to something like 120 retail stores. Since I didn't need the Documents General product type for anything else, I decided to use it for the names and addresses of those stores (categorized by country and subcategorized by state and city), so that customers who wanted to go to a bricks-and-mortar store could easily determine if there was one near them. My product-listing display of actual physical products consists solely of product images, arranged in a grid. I want my new document-listing display for Documents General to consist solely of the "product" (i.e., document) descriptions, arranged in a single column.

I have been careful to prevent mixed results from occurring. I modifed both the categories sidebox and advanced search to exclude the retail store results. Then I created a separate categories sidebox exclusively for the retail stores. That was when I realized that displaying the results of the latter sidebox presented a problem, because I needed a very different layout for them.

I do understand your point about product type being specific to products rather than to group results, but since I had been able to deal with that issue up to now in modifying the category sideboxes and advanced search, I innocently assumed I would be able to cope with it here, too. Of course, that depended on my finding main_template_vars.php to see how it even worked -- hence my original question to this forum.

I do see two other possible ways of addressing my problem besides using "product type" as a filter, but they both present the same problem you raise. The way I excluded Documents General from the categories sidebox was first to disable all the categories that contained documents-general and then to limit the standard sidebox to enabled categories. Although a little strange, that seemed more efficient than letting the sidebox pull up all the categories and then screening the results by product type, and all I had to do to make my new documents-general sidebox work was to flip the toggle and tell it to pull up only DISabled categories (in four years of my old 1.3.8 site, I've never needed to disable an actual product category, so I don't anticipate that being a problem going forward). So, at least in theory, excluding products from enabled categories could be the filter here. Similarly, the way I excluded Documents General from advanced search was to debar my entire "retailers" root category and all its subcategories (countries, states, and cities) from the database query. So again, in theory, that would be another possible filter here. But neither of these cases gets around the individual vs. group issue you raise. Still, the problem doesn't seem insurmountable to me. Surely there must be a way to say, "if ANY of the products in this list is of the Documents General product type (or from a disabled category, or from a subcategory of category X) then go to tpl_index_document_list.php instead of tpl_index_product_list.php -- though it would be more efficient, I suppose, to ask instead "if the FIRST product in this list ... " since if it is, the rest of them will be, too.

I hope all of that is clear, even if it is a little discursive. Does it suggest any solutions beyond having me taken out and shot? Thanks again for your help!

Oh, forgot. To avoid mixed lists, I also modified New Products, so that it would pull up only physical products, not the retail stores. That one I did using product type. In each of these different cases, I filtered by whatever method seemed easiest to apply to the code I found in place.

Another aside: in your Admin, when you click the "e" to edit a given category, in there you can tell it which product-types to "limit" that category to. This presently only affects the list of product-types available in the pulldown next to the "New Product" button used to add a new product to that category. You might want to employ that setting to at least help prevent accidents when setting up new entries for those location products.

It doesn't directly help elsewhere, but ... you could potentially use that same restriction value elsewhere on the storefront where your queries are related to categories, and take action based on that information.

Yes, I had noticed that Admin setting. It certainly is a welcome help in making sure that new database entries correspond to the desired default.

I'm not sure I follow you about the possibility of using the restriction value elsewhere, though. Searching the Developers Tool Kit, I find variables called $restrict_types and $product_restrict_types_array in the Admin files categories.php and category_product_listing.php, but as far as I can tell they would only have values within the context of the database queries carried out by those files. Are you suggesting that those queries or similar ones could be replicated elsewhere? Or is there some value that I'm missing that has wider validity?

Any further thoughts on how to solve my specific problem? I've clearly gotten in over my head, but having made it this far I'm reluctant to give up the ghost.

Thanks again!

Okay, thinking further about your second aside, Dr. Byte, I see that the Admin setting means that there has to be a field somewhere in the database indicating what product-type setting has been selected as the default for each category. Presumably for Documents General, the value assigned to it would be 3. Since I'm not deviating from the product types I have designated for each category, the database could be queried for that value. So, now we're up to four possible variables, any of which should serve the purpose of determining whether the "products" returned are real products or documents instead (the four being category status, root category id, product type, and default product type assigned to the category). The problem is that while I understand theoretically what I want to do with this information, I don't have a clue how to implement it in practice in main_template_vars.php. Any suggestions would be gratefully received.

have you tried the plugin hideCategories

with the following option all you need is a direct link to the category

o Hidden (Direct-link only)
+ The "Hidden (Direct-link only)" option hides your hidden categories from searches and the "All", "Featured" and "New" listings as well as search results. This is similar to disabling the product/category except that it can still be seen if the customer has a direct link.

Thanks for the suggestion, rbarbour, but it doesn't look like that plugin will help me (though it might well have saved me some work at an earlier stage in the proceedings). What I am trying to do now is re-direct result sets belonging to one product type to an alternative "product listing" for display. To do that, I need to render any ONE of the following four ideas into php:

1. if the product type of any of the results is Documents General (product_type = 3) then ...
2. if the subcategory from which any of the results derive is disabled (status = 0) then ...
3. if the top-level category from which any of the results derive is X (in this case, 35) then ...
   OR
4. if the subcategory from which any of the results derive is flagged as "Documents General" by default then ...

I was assuming that these "products" retail stores where assigned to 1 category and that you did not want them searched in the traditional way. hense the plugin suggestion

Now using a category specific stylesheet you could alter that categories "product listing page" without reinventing one.

then in the modules product_listing.php file you could add statement if cat_35 //do nothing else show price

prob should have read entire thread

archelaus:

Thanks for the suggestion, rbarbour, but it doesn't look like that plugin will help me (though it might well have saved me some work at an earlier stage in the proceedings). What I am trying to do now is re-direct result sets belonging to one product type to an alternative "product listing" for display. To do that, I need to render any ONE of the following four ideas into php:

1. if the product type of any of the results is Documents General (product_type = 3) then ...
2. if the subcategory from which any of the results derive is disabled (status = 0) then ...
3. if the top-level category from which any of the results derive is X (in this case, 35) then ...
   OR
4. if the subcategory from which any of the results derive is flagged as "Documents General" by default then ...

If it doesn't involve search, then you could do the following:

a) clone /includes/modules/pages/main_template_vars.php to main_template_vars_docgeneral.php
b) insert code at the top of the original main_template_vars.php to do the detection you're talking about, and if true then redirect to the docgeneral version of the file instead
c) then also clone the 3 tpl_index_xxxxxx files, if they need changing, and optionally also clone any subtemplate files which they might call, again only if they need changing.

Of course, in all cases where you're cloning, the main intention is to specify different output templates, assuming that's really what your desired end result is.
If your desired end result has always just been some simple CSS styling, then most of this entire discussion is moot because you could have used category-specific stylesheets to take care of everything.

The detection code for #2 could look like this:

$flag = FALSE;
switch (TRUE) {
  // is cPath 35?
  case ($cPath == 35):
    $flag = TRUE;
    break;
  // is current category 35? 
  case ($current_category_id == 35):
    $flag = TRUE;
    break;
    
  // check whether any of the "products" in the results is type 3
  // NOTE: This puts a huge duplicate load on the database just to find out this information
  case ($category_depth == 'products'):
    $new_products_category_id = $cPath;
    $typefilter = 'default';
    if (isset($_GET['typefilter'])) $typefilter = $_GET['typefilter'];
    require(zen_get_index_filters_directory($typefilter . '_filter.php'));
    $result = $db->Execute($listing_sql);
    $prods = array();
    while (!$result->EOF) {
      $prods[] = $result->fields['products_id'];
      $result->MoveNext();
    }
    if (sizeof($prods > 0)) {
      $sql = "SELECT products_type from " . TABLE_PRODUCTS . " WHERE products_id in (" . implode(",", $prods) . ") and products_type = 3 LIMIT 1";
      $result = $db->Execute($sql);
      if ($result->RecordCount() > 0) $flag = TRUE;
    }
    break;
}
if ($flag == TRUE) require ('includes/modules/pages/index/main_template_vars_docgeneral.php');

Pay attention to the comment alerting you to the fact that doing the detection of product-type based on any of the entries in the output is AN EXTREME WASTE OF RESOURCES, because it duplicates the queries doing the lookup of available results, and then re-queries the database for all of those yet again looking to see if their product-type meets your criteria ... and then gets redirected to the cloned main_template_vars_docgeneral to have it do all the (nearly) original work all over again.
This is complicated because what you're asking it to do is assess all the output results before they're even obtained, then take action to do something different based on whatever those results contain, before actually doing the real output. Doing it differently (more efficiently) requires a re-architecting of the code to abstract things into more layers, which isn't available in v1.x; it is however going to be a benefit of the v2 code (not available at this time).
Of course, if your detection can be based solely on whether the cPath is 35 or starts with 35, then the extra query load mentioned above won't fire, so it won't drag things down. So, if you can accurately rely on simply detecting cPath starting with "35" or "35_" then the first 2 "case" statements above will suffice, and you can remove the 3rd one that uses so many extra resources.

Okay, fantastic: Dr. Byte has set me on the True Path!

The solution is really quite simple, as I suspected it would be. In place of the original line 196 of includes/pages/index/main_template_vars.php, which reads:

$tpl_page_body = 'tpl_index_product_list.php';

I have substituted:

$flag = FALSE;
switch (TRUE) {
case ($cPath == 35):
$flag = TRUE;
break;
}
if ($flag == TRUE) {
$tpl_page_body = 'tpl_index_document_list.php';
} else {
$tpl_page_body = 'tpl_index_product_list.php';
}

And it works perfectly. I admit I don't quite know why it works, because when I put a debug line into tpl_index_document_list.php that reads "echo '$cPath';" it tells me, as I would have predicted, that $cPath is in fact 35_36_63_64. I had therefore thought I would need to put substr($cPath,0,3) into my new code to isolate just the 35_, but for some reason it works without that.

Thanks Dr. Byte, rbarbour, and Kobra for taking the time to help me. I am deeply grateful.

I think your statement

case ($cPath == 35):

inadvertently did the trick. It is wanting to compare the value of $cPath (stored as a string) with a numeric integer value, so the variable is converted by PHP to an integer before comparing. This a result of PHP being a "loosely-typed" language, where variables are used as whatever type is relevant to the task being asked of them. When a string like '35_47' is converted to integer, the _ and whatever follows are dropped to yield an integer, 35.

The normal method for doing this would be to say
case ((int)$cPath == 35):
to explicitly reduce the string to the desired kind of value.

I would simplify your code to```php
if ((int)$cPath == 35) {
$tpl_page_body = 'tpl_index_document_list.php';
} else {
$tpl_page_body = 'tpl_index_product_list.php';
}

Simplicity is beautiful. Thank you, gjh42! Also for the explanation of why $cPath was truncating.

Ironically in my first prototype I had used (int) ... but forgot it in my second round which I posted :(
Thanks for pointing it out Glenn!

Hi

I know this thread is pretty old now but I hope someone could help

gjh42:

I think your statement

case ($cPath == 35):

inadvertently did the trick. It is wanting to compare the value of $cPath (stored as a string) with a numeric integer value, so the variable is converted by PHP to an integer before comparing. This a result of PHP being a "loosely-typed" language, where variables are used as whatever type is relevant to the task being asked of them. When a string like '35_47' is converted to integer, the _ and whatever follows are dropped to yield an integer, 35.

The normal method for doing this would be to say
case ((int)$cPath == 35):
to explicitly reduce the string to the desired kind of value.

I would simplify your code to```php
if ((int)$cPath == 35) {
$tpl_page_body = 'tpl_index_document_list.php';
} else {
$tpl_page_body = 'tpl_index_product_list.php';
}

Is there a way to use the cpath of a subcategory??  I have managed to get this to work and it is what I am after but I only want the product listing of a subcategory different, the cPath=7_10.

Thanks

enochian:

Hi

I know this thread is pretty old now but I hope someone could help

Is there a way to use the cpath of a subcategory?? I have managed to get this to work and it is what I am after but I only want the product listing of a subcategory different, the cPath=7_10.

Thanks

I think you just answerd your own question, wouldn't the code be```php
if ((int)$cPath == 7_10) {
$tpl_page_body = 'tpl_index_document_list.php';
} else {
$tpl_page_body = 'tpl_index_product_list.php';
}

When I use cpath=7_10 none of my products show. If I use cpath=7 my products show but it changes the category and the subcategory product listing. I only want to change the subcategory product listing.

Thanks