Ahh, so that's the "can't get it to work" portion/idea.
Well, there are aspects of ZC that have changed from that point (2006); however, there are some core things that have not really changed. For example, the significant difference between those two portions of the code are that now a category image is returned by the query as compared to before when one was not... Otherwise, generally speaking the two sets of code are operationally equivalent.
While I can not claim to know the entire history of changes through ZC, but a majority of the changes even as of recent are more focused on the security of operations than they are on changing how things behave or possible results. There are a few things that are being discussed currently about a few "limitations" that have been seen, but they tend to only present themselves in more complex situations such as product priced-by-attributes, the attributes having a price factor and there being a special on the product where everything looks right on the shopping_cart page but then goes wrong on checkout and it has been identified as something with a long standing history of being this way. Perhaps someone has "fixed" it (and not shared the solution) or just worked around it, but it is something actively being discussed for operational improvement.
Okay, all that said, you should be able to apply the same query modification (modification not replacement) as was performed back in 2006 and get the desired result. BTW, if you take note of the file header information for that file as provided in ZC 1.5.5d, you will see that it has a date of 2006-02-15... So, that said, it almost appears as if the file from the provided post was actually from an older version of ZC than what was available February 15th, 2006... What that really says about the file? Well it was smartly removed from other files that may routinely change and that it has provided all/okay most of what anyone needs it to do... By that I mean, there haven't been any changes to the file as it appears that none have been needed to support normal operation. Okay, the multi-site mod chooses to modify it a little for each respective store, but it's not an extreme modification.
In fact, an example of the change for the two areas (not saying that more changes may be necessary elsewhere in the file), but this:
Code:
function zen_category_tree($product_type = "all") {
global $db, $cPath, $cPath_array;
if ($product_type != 'all') {
$sql = "select type_master_type from " . TABLE_PRODUCT_TYPES . "
where type_master_type = " . $product_type . "";
$master_type_result = $db->Execute($sql);
$master_type = $master_type_result->fields['type_master_type'];
}
$this->tree = array();
if ($product_type == 'all') {
$categories_query = "select c.categories_id, cd.categories_name, c.parent_id, c.categories_image
from " . TABLE_CATEGORIES . " c, " . TABLE_CATEGORIES_DESCRIPTION . " cd
where c.parent_id = 0
and c.categories_id = cd.categories_id
and cd.language_id='" . (int)$_SESSION['languages_id'] . "'
and c.categories_status= 1
order by sort_order, cd.categories_name";
} else {
$categories_query = "select ptc.category_id as categories_id, cd.categories_name, c.parent_id, c.categories_image
from " . TABLE_CATEGORIES . " c, " . TABLE_CATEGORIES_DESCRIPTION . " cd, " . TABLE_PRODUCT_TYPES_TO_CATEGORY . " ptc
where c.parent_id = 0
and ptc.category_id = cd.categories_id
and ptc.product_type_id = " . $master_type . "
and c.categories_id = ptc.category_id
and cd.language_id=" . (int)$_SESSION['languages_id'] ."
and c.categories_status= 1
order by sort_order, cd.categories_name";
}
Could be modified to:
Code:
function zen_category_tree($product_type = "all") {
global $db, $cPath, $cPath_array;
if ($product_type != 'all') {
$sql = "select type_master_type from " . TABLE_PRODUCT_TYPES . "
where type_master_type = " . $product_type . "";
$master_type_result = $db->Execute($sql);
$master_type = $master_type_result->fields['type_master_type'];
}
$this->tree = array();
if ($product_type == 'all') {
$categories_query = "select c.categories_id, cd.categories_name, c.parent_id, c.categories_image
from " . TABLE_CATEGORIES . " c, " . TABLE_CATEGORIES_DESCRIPTION . " cd
where c.parent_id = 0
and c.categories_id = cd.categories_id
and cd.language_id='" . (int)$_SESSION['languages_id'] . "'
and c.categories_status= 1
and cd.categories_name LIKE '%A1%'
order by sort_order, cd.categories_name";
} else {
$categories_query = "select ptc.category_id as categories_id, cd.categories_name, c.parent_id, c.categories_image
from " . TABLE_CATEGORIES . " c, " . TABLE_CATEGORIES_DESCRIPTION . " cd, " . TABLE_PRODUCT_TYPES_TO_CATEGORY . " ptc
where c.parent_id = 0
and ptc.category_id = cd.categories_id
and ptc.product_type_id = " . $master_type . "
and c.categories_id = ptc.category_id
and cd.language_id=" . (int)$_SESSION['languages_id'] ."
and c.categories_status= 1
and cd.categories_name LIKE '%A1%'
order by sort_order, cd.categories_name";
}
Or.. If you have/decide to use a file constant in each store to represent the value being searched/compared then you could do something like this:
Code:
function zen_category_tree($product_type = "all") {
global $db, $cPath, $cPath_array;
if ($product_type != 'all') {
$sql = "select type_master_type from " . TABLE_PRODUCT_TYPES . "
where type_master_type = " . $product_type . "";
$master_type_result = $db->Execute($sql);
$master_type = $master_type_result->fields['type_master_type'];
}
$this->tree = array();
if ($product_type == 'all') {
$categories_query = "select c.categories_id, cd.categories_name, c.parent_id, c.categories_image
from " . TABLE_CATEGORIES . " c, " . TABLE_CATEGORIES_DESCRIPTION . " cd
where c.parent_id = 0
and c.categories_id = cd.categories_id
and cd.language_id='" . (int)$_SESSION['languages_id'] . "'
and c.categories_status= 1
and cd.categories_name LIKE '%" . STORE_CATEGORY . "%'
order by sort_order, cd.categories_name";
} else {
$categories_query = "select ptc.category_id as categories_id, cd.categories_name, c.parent_id, c.categories_image
from " . TABLE_CATEGORIES . " c, " . TABLE_CATEGORIES_DESCRIPTION . " cd, " . TABLE_PRODUCT_TYPES_TO_CATEGORY . " ptc
where c.parent_id = 0
and ptc.category_id = cd.categories_id
and ptc.product_type_id = " . $master_type . "
and c.categories_id = ptc.category_id
and cd.language_id=" . (int)$_SESSION['languages_id'] ."
and c.categories_status= 1
and cd.categories_name LIKE '%" . STORE_CATEGORY . "%'
order by sort_order, cd.categories_name";
}
Where you could apply a define for STORE_CATEGORY in the includes/extra_configures directory such as for store A1, though likely will want something more "unique" than just A1:
example: includes/extra_configures/multi_site_site_category.php
Code:
<?php
define('STORE_CATEGORY', 'A1');
Then there are other "factors" that could be considered, such as placing the unique filter at the beginning of every associated category rather than somewhere in between... If you wanted to give yourself that type of "requirement", then you could move the percent symbols into the definition itself which may also benefit the database search engine by not having to parse the entire string, but just the beginning or end of it. So if it were to start with that key then the added line could generically be:
Code:
and cd.categories_name LIKE '" . STORE_CATEGORY . "'
and the define as:
Code:
<?php
define('STORE_CATEGORY', 'A1%');
again where A1 is the unique key perhaps being more unique but easy enough to remember to add into all of the category names that apply.
Now.. All that said, a simplification of your goal appears to be: on site B to apply this filter to only show the category that begins with your special character sequence, and technically on site A to show all categories that do not contain that particular character sequence. Also that there are only 2 sites in question (not expanding to 3 or more), therefore, could either add/modify all of the categories to contain the special sequence for site A (could be done with a single sql statement) and then add/apply the category for site B (which btw, you may just want to copy the category with product and then rename it) or could modify the sql for site A to have a NOT LIKE condition instead of LIKE such that site A shows all categories that are not specifically designated for site B... Could end up being harder to manage, but does limit the immediate modifications necessary to support site A displaying the categories.
You said though that Site A is to show all categories... If it is to also to contain the specific categories of site B (ie. not a copy of the category/having a different categories_id), then site A will have to know something about site B in order to remove the special character sequence when displaying the category name so that 1) the category is pulled from the database, but 2) it is not displayed to the customer...
My suggestion though generally speaking would be to just make the copy of the category and treat them as two independent categories... Otherwise, run the risk of applying a sale or something on one site that is then reflected on the other (un?)intentionally.
Bookmarks