Help: Invalid Master Category

Just did this -- twice, just to be certain. Products to Multiple Categories Link Manager shows 177's master category as 74, linked category 73 -- yet catalog still acts as if master category were 73.> Ajeh:

Click on the C for Copy on this product and select the button for Multiple Categories Link Manager ...

Uncheck the Category that is NOT the master_categories_id ...

Click Update Category Links ...

Now re-select the Category you just unchecked ...

NOTE: only Categories with at least 1 product will show on this listing ...

I turned off your SEO add on ...

Appears to be working correctly now ... :smile:

Check products_id 173 and 178 ... I might of kinda sorta messed up who is who there ... :cry:

Thanks Linda! I made the fix on 178, and 173 was fine as you left it.

I'll run down the SEO URLs bug momentarily. A new beta for that one was just released today, so I'll try it on a test site and submit a bug report if the master categories problem isn't fixed.

I would never have suspected that as the culprit ... you rock! :D

Ajeh:

I turned off your SEO add on ...

Appears to be working correctly now ... :smile:

Check products_id 173 and 178 ... I might of kinda sorta messed up who is who there ... :cry:

Look, if you access the product's page without the cPath in the url, then it still shows Category 73 as the master category, so whatever is going on, it is not SEO's fault.

http://shedkitstore.com/index.php?main_page=product_info&products_id=177

Just a quick follow up. The problem stems from Zen Cart not using the master category id when looking up a product's category path (when there is no cPath given). Instead, it uses the first category it comes across in the products_to_categories table.

I won't pretend to understand the mechanics of any of this, but I'd like to learn what makes this tick.

As Joshua points out, the url sans-cPath puts the product info page back into pre-master-category-change mode. And when the cPath is included in the url, the catalog behaves as it should, recognizing the current and correct master category.

And none of this changes the fact that the problem exists when SEO URLs is enabled, and goes away when SEO URLs is disabled. Somehow, the two appear to be connected.

Or is there some other factor that could create the illusion of causality?> dreamscape:

Look, if you access the product's page without the cPath in the url, then it still shows Category 73 as the master category, so whatever is going on, it is not SEO's fault.

http://shedkitstore.com/index.php?main_page=product_info&products_id=177

Good point -- Linda had mentioned this earlier, and I had already forgotten it. :P

dreamscape:

Just a quick follow up. The problem stems from Zen Cart not using the master category id when looking up a product's category path (when there is no cPath given). Instead, it uses the first category it comes across in the products_to_categories table.

tvadpro:

Or is there some other factor that could create the illusion of causality?

Yes, SEO URLs doesn't put the cPath in product urls, so zen cart uses its lookup function, which does not use the master category id. This may give the appearance that SEO URLs is to blame. However, this is not the case. Perform a search for the product with SEO URLs turned off, and you will see the same problem of the incorrect lookup.

As for why the lookup function doesn't use the master id, I haven't the slightest idea, other than the issue and suggested change was pointed out as far back as Dec. 2005, and it still hasn't been changed to use the master id. As for why, that is something only the Team can answer.

It would however be an easy enough change for you to make yourself if you wanted your store to use master category in the lookup process.

And by the way, I appreciate both of you taking the time to look into this, and doing it with a sense of urgency I have seldom noticed elsewhere. Cheers to Ajeh and Dreamscape! :D

Seems a fair question: can anyone enlighten us with regard to lookup omitting the master category ID?> dreamscape:

Yes, SEO URLs doesn't put the cPath in product urls, so zen cart uses its lookup function, which does not use the master category id.

As for why the lookup function doesn't use the master id, I haven't the slightest idea, other than the issue and suggested change was pointed out as far back as Dec. 2005, and it still hasn't been changed to use the master id. As for why, that is something only the Team can answer.

master_categories_id are only used for limited features as many need to be specific to the categories_id ... $current_category_id or $cPath ...

master_categories_id is used for pricing for things like SaleMaker and speed on things like the admin listing of Products area ...

It is not used for everything or the usefulness of Categories and Linked Products etc. would be destroyed because the master_categories_id would take precidence over the current category ...

I can't pretend to understand the lookup function, but I can say it sounds like there was good reason for omitting master categories from lookup. So, without impairing existing Zen-Cart functionality, how might one work around the master categories issue when running SEO URLs?

It occurs to me that I could create a new category, move the linked products there, and disable the original category. This would create a linked category ID > master category ID, hence the master category would be recognized by default.

That's far from an ideal solution, so I'm interested in how to make SEO URLs work without master category problems with linked products. > Ajeh:

master_categories_id are only used for limited features as many need to be specific to the categories_id ... $current_category_id or $cPath ...

master_categories_id is used for pricing for things like SaleMaker and speed on things like the admin listing of Products area ...

It is not used for everything or the usefulness of Categories and Linked Products etc. would be destroyed because the master_categories_id would take precidence over the current category ...

Ajeh:

It is not used for everything or the usefulness of Categories and Linked Products etc. would be destroyed because the master_categories_id would take precidence over the current category ...

Actually in the case of looking up the product's category that is not true. The lookup is only done if the $cPath is not set... in such cases, IMO, and as others have voiced in the past, the returned category should be the master_categories_id, and that is what one would expect to be the case.

We're not talking about cases when the $cPath or current category are know. Only cases when it is not known, ie, not given in the URL as is the case when searching for an item.

dreamscape:

Actually in the case of looking up the product's category that is not true. The lookup is only done if the $cPath is not set... in such cases, IMO, and as others have voiced in the past, the returned category should be the master_categories_id, and that is what one would expect to be the case.

We're not talking about cases when the $cPath or current category are know. Only cases when it is not known, ie, not given in the URL as is the case when searching for an item.

Ajeh and I had a lengthy chat about this and have agreed that there is a problem that needs fixing here. Yes, the lookup should be changed to default to the master_categories_id if no cPath is supplied.

This change will not happen in "core" until the v1.4.x series. In investigating the code, there are a number of additional places which will be impacted by changing this behaviour and will require extensive testing to be sure other things are not broken. Things like coupon-restrictions, prev/next navigation, category-icon selection, not to mention sales issues, and so on.

This is encouraging, to say the least. :smile:

If there's anything one might do to help get through that extensive testing, I'm all ears. Having the beta for the new SEO URLs running on another site, I'm anxious to see the integration of the mod perfected.

DrByte:

Ajeh and I had a lengthy chat about this and have agreed that there is a problem that needs fixing here. Yes, the lookup should be changed to default to the master_categories_id if no cPath is supplied.

This change will not happen in "core" until the v1.4.x series. In investigating the code, there are a number of additional places which will be impacted by changing this behaviour and will require extensive testing to be sure other things are not broken. Things like coupon-restrictions, prev/next navigation, category-icon selection, not to mention sales issues, and so on.