Adding Sub-Cat to Category that Contains Products?

So I want to add a subcategory to a category that has products. To see if it could be done, I created a top level category and moved it inside of a category that already contained products.

I received this warning in my admin:

Error Error: Category has Products!
While this can be done temporarily to build your Categories ... Categories hold either Products or Categories but never both!

Despite the warning, it appeared to work perfectly, exactly as I desired.

Now, I understand why––generally speaking––this is not a good idea. However, I have a very clever reason for wanting to tuck products away like this.

So my question is this: Is there some technical reason I shouldn't use this strategy? Will it somehow "break" the cart?

Thanks!

I've done it in the past and it seemed to work just fine. None of my current sites have this in place though. I'd love to know what is (technically) wrong with doing this.

hairydog:

I've done it in the past and it seemed to work just fine. None of my current sites have this in place though. I'd love to know what is (technically) wrong with doing this.

Wish there was a way to tag DrByte in on this... :D

Feznizzle:

Wish there was a way to tag DrByte in on this... :D

Maybe not a complete answer, but it was brought up in ZC 1.5.5 beta testing with this answer copied below.

Mixing products and categories at the same level can result in miscalculations of pricing and sale calculations, and other anomalies with product and category handling. (Most of those are inherited from the osC architecture, and can't be fully resolved without changing a lot of code, and breaking plugins. Planned for a future version.)
That's why those protections are there to make it difficult to break it. But, if you're really bent on breaking the site, you can still do it, as you just showed. Naturally we don't recommend doing that.

Thanks, Chad.

Bummer. That sounds pretty ominous.

That said, I really really want to be able to do it. Enough that I may simply take my chances, if I cannot come up with a better solution.

++++
EXAMPLE TO DEMONSTRATE WHY:
Many manufacturers make countless iterations of the same product, each with a unique model #. For instance, an IV Pole can be made of chrome or stainless steel. For hanging bags, the IV pole can have 2 hooks, 4 hooks, 8 hooks, or 24. There are 3 different base types to choose from and 5 color choices.

Now I can easily build a page that will allow my visitor to configure their IV Pole exactly how they want, rather than browsing thru a couple dozen product pages.

The problem boils down to SEO. If a potential client googles a specific model #? Or the specific configuration that they want? If I do not have a page for what they searched for, then I will not show up.

My thought was build one master page per manufacturer (I will have 3 mfgs for this category), per type of IV Pole (chrome or SS). Then hide all the clutter in a subcategory. So if you browse to my IV Poles, you will be presented with 6 products.

But if you google a specific configuration/model#, you will land on a page with exactly what you want... but then be presented with a link to the master page ("For other configurations of this product, go here").
++++

Does anybody know of a "better" solution? One that will allow me to list out every possible configuration as its own page, but without cluttering up my category listings?

So one thing that comes to mind is using SBA (Stock By Attrbutes) and it's ability to have a customid assigned to each "variant" (combination of option values to provide a unique product) in a way that the "page" is populated with the desired data...in ZC 1.5.5, the canoncal data collection/processing has been improved. Based on at least one posting by DrByte, the applicable code is backwards compatible. While this may not be the best place to capture the necessary data, it is one place to look and there have been notifiers added throughout that set of code that could be used to pull/provide anything applicable in that area, and then similar related data could be captured on page...

Just some thoughts. There may already be other software that has that "feature" captured whether commercial or not.

On the issue of displaying product in a category that has a subcategory, there is also a difference between the product being in the parent category as compared to being displayed in the category when the category is loaded.. Meaning that the contents of some other database populated category is presented when a particular category is displayed. The difference herei is that the database can be maintained "pure" regarding the discounts/sales identified by DrByte, but display can be made as "desired". Of course this involves touching/potentially touching a number of sub-areas so that the product to be displayed in the sub-category is present and the "fake" subcategory doesn't appear in any "listings" but it's product does (goal of this category). Just an alternate perspective to achieve the desired end state.

Mixing up the Products and Categories in the same category will result in errors on sales and other issues.

While you can do what you did to "force" the Products and Categories to be mixed that is there mainly for the purpose of helping organize the Categories but not there for final use ...

It is strongly recommended that you not leave Products and Categories mixed together in a Category ...

Ajeh:

Mixing up the Products and Categories in the same category will result in errors on sales and other issues.

While you can do what you did to "force" the Products and Categories to be mixed that is there mainly for the purpose of helping organize the Categories but not there for final use ...

It is strongly recommended that you not leave Products and Categories mixed together in a Category ...

mc12345678:

On the issue of displaying product in a category that has a subcategory, there is also a difference between the product being in the parent category as compared to being displayed in the category when the category is loaded.. Meaning that the contents of some other database populated category is presented when a particular category is displayed. The difference herei is that the database can be maintained "pure" regarding the discounts/sales identified by DrByte, but display can be made as "desired". Of course this involves touching/potentially touching a number of sub-areas so that the product to be displayed in the sub-category is present and the "fake" subcategory doesn't appear in any "listings" but it's product does (goal of this category). Just an alternate perspective to achieve the desired end state.

I just wanted to reiterate that what I describe above complies with the warning offered now by Ajeh and by DrNyte above (and from any/all of the ZC team). I say this because what I describe is a way to keep the database pure in relation to what product falls below what category and that display of the desired information is made by additional code to filter what is displayed in relation to where the customer is "looking". This way the standard operations, price calculations, etc. are not affected.

Ajeh:

It is strongly recommended that you not leave Products and Categories mixed together in a Category ...

I'm back in line, will not do that.

Currently looking into alternative methods.

The idea I'm leaning toward is to build a category called "Brands". Inside of "Brands", I will have a subcategory for each manufacturer with subcategories that match their products to the main categories. Inside of these categories, I'll dump all the clutter. Each "clutter" page will link to the master product page.

That's pretty much the only way I can think to do this w/o screwing around with code or adding more mods.

mc12345678:

I just wanted to reiterate that what I describe above complies with the warning offered now by Ajeh and by DrNyte above (and from any/all of the ZC team). I say this because what I describe is a way to keep the database pure in relation to what product falls below what category and that display of the desired information is made by additional code to filter what is displayed in relation to where the customer is "looking". This way the standard operations, price calculations, etc. are not affected.

I looked at what you said above and it does sound very interesting. Only, it's vague on detail. Can you flesh out this idea a little?

Feznizzle:

I looked at what you said above and it does sound very interesting. Only, it's vague on detail. Can you flesh out this idea a little?

So it's been a while since I have looked at how the data is filtered when looking at say a category page in order to show the product/categories to be presented. The thought would be on a "crude" level, if the current category is x, then show all sub-categories and the products of y, but when the parent of category y is displayed then ignore category y. Kinda seems like another table could be generated/related. Table contains, (field1) the category on which product are to be displayed cross referenced with (field2) the category to display containing all of the product. Then when displaying a category, include all sub-categories except those that have a reference in that table (field2) and all product that are referenced by the category in that table (product of field2 that are referenced by the current category (field1)).

The "hard" part becomes any type of "quality" check to prevent some form of cyclic loop or complete omission of product, though I guess it would still be considered acceptable for all product to end up under the root of the store, or to be at the end of a category tree, it's just some odd "situation" that I can't seem to determine at the moment that would need to be prevented or recognized.