cPath for Dummies - I want a totally different layout

Hello Everyone,

Could someone please explain how the 'cPath' works?
I'm doing my homework, reading and studying all that jazz, but finally decided to verbalize it and post the question (no matter how trivial...)

I'm not sure how is this all related, but after reading the thread: 'Switching templates at run time,' it got me going...

Here is my scenario:
Product examples (where '' represent subcategories and '*' product):
[categories] - [*subcategories...] - [**product]:
[properties(description)]

Papers - *Decorative Papers - *Thai Papers -
**Unryu Paper: Model (unique SKU nos.): Color (beige, black, green...): Size (20x30)

Papers - *Printmaking Papers -
**Somerset Velvet Paper: Model (unique SKU nos.): Color (black, antique...): Size (20x30, 30x40...)

Papers - *Printmaking Papers -
**Rives Papers: Model (unique SKU nos.): Color (cream, grey...); Style (BFK, Light, Heavy...): Size (20x30, 30x40...)

These products have common name (respectivelly, Unryu Paper, Somerset Paper, Rives Paper), description, image, and some other properties, but differ from each other by color, size, price, etc.

Using the standard process, the product listing will look like this:
Papers - *Printmaking Papers - *Somerset Paper:
** M001: Somerset Paper, beige, 20x30
** M002: Somerset Paper, beige 30x40
** M003: Somerset Paper, black 20x30 etc.

However, this can be presented in the following way, by using the category description and image, (watch for the *, **):
Papers - *Decorative Papers - *Thai Papers - *Unryu Paper -
**Model (unique SKU nos.): Color (beige, black, green...): Size (20x30)

Papers - *Printmaking Papers - *Sommerset Velvet Paper -
**Model (unique SKU nos.): Color (black, antique...): Size (20x30, 30x40...)

Papers - *Printmaking Papers - *Rives Papers -
**Model (unique SKU nos.): Color (cream, grey...); Style (BFK, Light, Heavy...): Size (20x30, 30x40...)

In other words, if I'm correct, the last category level will be in fact a combination of category and product page, containing the description, image (etc.) of product, and, in tabular format, products listings.

The image is better than 1000 words so here are visuals:
Paper Category level

Subcategories > Products
Decorative Papers > Unryu Paper
Printmaking Papers > Sommerset Velvet Paper

But wait, here is more :D
(I guess, this is where I'm getting confused): When adding a 'sub-category' in admin>catalog (etc.), am I in fact creating a 'category' that has a 'parent_id' linking it to the parent category. So that will explain the numbers after cPath:

• first number = category (index.php?main_page=index&cPath=4)
• second number = sub-category (index.php?main_page=index&cPath=4_9)
• third number = sub-sub-category (index.php?main_page=index&cPath=4_9_3) etc.

But how then create different looks for different levels... including the last one (which in fact is some sort of category-product hybrid)?
And, no, I guess, this is not about css changes...

That leads me to another question: if in fact there is an override possible -
I'm having a little 'steaming' when it comes to scope the whole modular design: I think, I understand that the page we see in a browser, in fact is composed not with one standard template, but with tiny segments that are grouped into 'larger components,' that finally give the five major parts (header, footer, left side box, right side box, body)... I read couple of times the "Zen Cart Program Flow", but I will very much appreciate if someone could please visually verbalize it for me (and others)...

Thanks for reading - hope this will trigger some brainstorming - best,

0101101011:

So that will explain the numbers after cPath:

• first number = category (index.php?main_page=index&cPath=4)

• second number = sub-category (index.php?main_page=index&cPath=4_9)

• third number = sub-sub-category (index.php?main_page=index&cPath=4_9_3) etc.

Yes, that is what the cPath denotes.

0101101011:

I think, I understand that the page we see in a browser, in fact is composed not with one standard template, but with tiny segments that are grouped into 'larger components,' that finally give the five major parts (header, footer, left side box, right side box, body)...Yes, things are assembled modularly from many components, as you mention.

0101101011:

But wait, here is more :D
(I guess, this is where I'm getting confused): When adding a 'sub-category' in admin>catalog (etc.), am I in fact creating a 'category' that has a 'parent_id' linking it to the parent category. So that will explain the numbers after cPath:

• first number = category (index.php?main_page=index&cPath=4)

• second number = sub-category (index.php?main_page=index&cPath=4_9)

• third number = sub-sub-category (index.php?main_page=index&cPath=4_9_3) etc.

But how then create different looks for different levels... including the last one (which in fact is some sort of category-product hybrid)?
And, no, I guess, this is not about css changes...

clarification re: "But how then create different looks for different levels... including the last one (which in fact is some sort of category-product hybrid)?"

No, cPath is never a hybrid of category and product ... it is only the nesting of categories.

But how then create different looks for different levels... including the last one (which in fact is some sort of category-product hybrid)?
And, no, I guess, this is not about css changes...

When you say ***"different looks for different levels .... not with css" ***... what exactly do you have in mind?

DrByte - thanks for replying.
Re: 'different looks' - This is what happens when brainstorming late in night... I guess, I didn't express myself clearly: In Switching templates... thread, eccentric was up to creating a templates based on category selection (men's clothing, women's clothing etc.). Among others you suggested using the css - I guess, my comment was related to this - in my exercise, I'm trying to figure out the design behind the file organization, to be able to achieve the desired look using overrides...

My goal is to understand how the looks of attached above web samples can be achieved with ZC.

After studying these examples, I think, that when using the standard process of adding products, will end up with visual duplicates (many fields will be redundant across the products).

So if I decide to 'group' the products based on common properties, the products will be in fact 'elevated' to a category level, and only the unique properties will be then listed as a product. (please see the web samples - it makes sense).

Let's assume, that I want the product page look like this example.: It looks like it is composed of two sectors: the top one: has a title, description and image common to all grouped products (etc.), and the bottom one listing the products (its unique properties) in spreadsheet format, allowing customers to add the items to the cart.

The problem I have is to actually grasp the logic. If you follow the process of adding the product as a category, you end up with last category level showing you the list of available products, but then if you click on each product, you will end up in the actual product page... I would like that the last category level is your final destination.

In ZC:
When clicking on category you are send to category page (cPath=[number])
Within that category, you see subcategories - clicking on one sends you to category page level 2 (cPath=[number]_[number])

Let's assume that the level 3 (sub-sub-category) is your product, so you will see on the level 2 page (cPath=[number]_[number]) list of products with images (remember, you added an image and description to that category-product hybrid).

The level 3 (cPath=[number][number][number]) will have title, description (no image, but I guess this is admin customization thing) and list of products below. That level also have 'add selected products to cart' button on top and bottom of the product list.

At this point - veni, vidi, visa :D - I came, saw, and I'm buying... (well, visa does not mean 'buying' in latin - this is from their ad) - If I can present all the properties I want on that level, theoretically, I don't need the link to a product page anymore.

Allright - but what if I need to cross-link the products: remember, my product is actually the very bottom category, which contains the 'products.' I only can link products, not categories...

That means, I will have to create categories manually, and then link the products.... but wait - I'm duplicating entries (categories) in database!!! - unless there is a way that I don't see...

Please help... I'm overheating... and it's cold outside...bzz bzz...

Thanks, a bunch

Eliminating the "product" page is not within the normal workings of the current Zen Cart infrastructure.
You can do it, but not without a lot of code changes.
And if you intend to use attributes with your products, you'll be quite awhile adding attribute-selection logic to your category+product listings, as that code hasn't been written yet.

By 'attribute' you mean the attribute controler, right? So, you think of Option Name/Value managers... (right?)
Well, I think here we are touching the point. But first, let's organize thoughts (at least it helps me to say what I want to say... - did I mention I'm new to ZC?):

1. It seems to me that the product_attributes table primarily addresses the pricing issue (by combining data from products_options and products_options_values tables)

2. What if the 'product attributes' are not really 'attributes' (as ZC 'thinks') but more likely a description of the product? What if I don't want to show dropdown/checkbox/radio button on the product page, but instead show the 'attributes' (descriptions) as a spreadsheet?

The point is, someone presented an alternative way of showing products, and I like it (for its efficiency, and customer friendly concept). Let's figure it out how could we do that with ZC...

DrByte - I just thought about something: my question about cPath wasn't rethoric - could you please point me to the files/modules where the looks of each category is generated? Thanks,

Interjecting here..."Categories" are not basically items that are displayed and therefore have no styling.

Categories are groups of products, or groups of sub-categories that are groups of proucts. You really do not get to looking at a display for this until you get to the 2 main types of representations that ZenCart has. Those being;

Product Listing - a selection of products under a Cat or sub-cat, by default displayed in row format with specific info about each and much of this display is controllable through the admin(but not every thing one might like)

Product Info - One specific class of product with additional details about it. This can include optional values i.e. color, size, etc. as attributes.

These are by default, specific to this single product; such as your Somerset Velvet Printmaking Paper. and all the various colors and sizes can be added as attributes.

Now this is where I think the hang is, With the above default, a shopper can select from the attributes and enter a qty offered and make the purchase. What is not provided for is the multiple selection of each variety and qty of each. If I am not mistaken, this is not a current function of ZenCart as distributed.

What you should do, as you stated that you are new, is install ZenCart with the Demo DB of items. This will present you the many variations that are built in and hints as to how to set them up. I think that you will still be lacking the functionality that you have posted.

Kobra - thanks for the reply.

By saying I'm new, I don't mean I'm completlly ignorant! You know, I probably don't know as you pro-guys, but I've been around... ;) - of course I have installed the ZC -- I thought, it will be good to prompt some discussion and get some answers/confirmations - you know, the wall doesn't talk back... Besides, all the pro-guys could really benefit by listening to the newbies - they come with fresh point of view...

Back to the point - Kobra, your posting helps, thanks a lot - I'm just studying the categories functions and digging through modules and templates - I'll be back...

Your walls don't talk?? Mine do!!!! But I don't like what theya are saying about me...

In a binary world there are only two answers...0 and 1. which one are you?

OK Kobra, here is a thought:

I hear and read over and over about 'selecting from the attributes.' - What if this is not a good option? What if, each product, with its attributes is priced differently? You cannot go to product page and select from attributes (like color, size, etc.), because that particular product, with its attributes is unique (incl. unique SKU, UPC, etc.) -

and because the pricing is so random, you cannot just use price by attributes... it doesn't work that way...

It's clever to design separate tables that holds option names and values - it seems like every ZC user can create it's own fields as they need (either it is color and size and its values). But this seems to be very tight design... -- I mean, how it is related to pricing and the 'attributes layout' (dropdown, checkbox...).

Well, since data are in database, it should be a no-brainer to pull these out into desired places, right? So what do I need to know? I believe that the data are first 'pulled out' from database and 'translated' into variables, and then placed in template - am I correct? Either way, I appreciate your feedback,
Thanks,

An example of a real product that fits your requirements might be helpful.

0101101011:

Well, since data are in database, it should be a no-brainer to pull these out into desired places, right? So what do I need to know? I believe that the data are first 'pulled out' from database and 'translated' into variables, and then placed in template - am I correct?
Yes -- you can see how it pulls the data for display, via the /includes/modules/attributes.php script.
You can see how it stores the data for purchase via the includes/classes/order.php class.
And you can see how it receives data to add to cart via the various elements of the shopping_cart.php class.

Hello everyone,

Kim - the URL's to samples are on the first page of this thread.

After some time spent inside the zen cave :smartass: , I came up with a theory, and more questions :D

But first -

1. Topic One:
   Could you please tell me is it possible to link CATEGORIES? Theoretically, the database can be setup to reflect such relation, but there may be stuff in code I'm not aware of, so I'm humbly passing the question to you.

2. Topic Two:
   Remember, I'm trying to find out best way to display the products as per example.

So far, without much of messing around, the product listing page in zen cart looks pretty close to the sample provided above (here you can see on a testing platform) - title, picture below (this is a 'category picture'), description, filter and otional (which is desirable in this situation) 'add selected products to cart' button.

The lower, tabular part shows the actual products that are within the category. I entered them with read-only attributes to better visualize (you can see it, once you click on the product link). The title in this case is represented by number (indicating series), since we have the tilte above already.

The table header shows: Model, Item Name and Price - all of these variables are located in Admin>Configuration>Product Listing.
I switched off image and manufacturer. There are some few more.

NOW, bare with me: theoretically, I could add (code) to Product Listing the items I desire to show in the table, i.e. Color, Size, Weight (! - this is not a shipping related weight - it is another field representing paper 'thickness'), etc.

This will be at least the minimum to achieve the desired look (there is howerver more, but let's leave it for another discussion).
The link on the product title (in tabular product display) could be disabled, so there is no need to go into product page...

(opinion of experts highly desired at this point - mucho thanks)

This brainstorm is triggered to identify the possibility of displaying products the 'other way.' In my opinion, the way how attributes work now, is only beneficial to businesses who actually can take advantage of pricing possiblility of attributes. Clean and solid example could be Apple store: you select an iMac (starting at $$$) and then you add/remove components (or, attributes - better graphic card and processor [+$$], smaller HD[-$$],more memory[+$$], etc.).

However, if your product's attributes (let's call them descriptive properties of product) are not benefit from pricing functions; and on top of that, their price is random, regardless of their attributes (descriptive properties), then an optional way of showing product may be more than functional: it will benefit customers (i.e. saving them extra clicks).

Questions:

1. Did I explain the situation clearly?
2. If in a theory, adding additional 'variables' to Admin>Product Listing page to display extra fields (in this exercise are the option names/values/attributes) is possible (is it? zen guru's, please elaborate), would it affect the admin structure (since admin is not overrideable)?
3. My theory omits the product page - anyone else have other suggestions/solutions?

Thanks,

Hello 0101101011 vbmenu_register("postmenu_299288", true); ,

I dont' have the time to read all the posts on this thread, just as I would prefer to read a reference book on Zen-Cart that was written by a tech-writer/programmer rather than have to sift thru this muck to get some answers.

I sort of understand what your looking for, and I believe that it would require a script that targets the <head></head> portion of the webpage.

That script would have to inspect the category of item that needs to be displayed, and echo a stylesheet link on that basis.

This way the browser is told which stylesheet to use based on the product category that's being displayed.

You or someone who knows how will have to code that into the page building PHP, which ever that is. Finding the right one is like sexing baby chicks, you have to find the little nub on the males.

I'm not a PC programmer, it's way too cryptic for me, but I have a pretty grasp of the concepts.

Please let me know if this was of any help.