Answers.Body: <ol>
  <li><p>Hard to say if they're the 'best' tool, but I don't see anything here you can't do with Craft categories and they seem the logical and built in way to go about it.  In essence you simply look at your url segments and use these as category filters when retrieving the products</p></li>
  <li><p>I think so.  It keeps the two separate data concerns nicely separated - but do be aware from a UI point of view, separate category groups are very separate things - you can't use one field to select from both groups (quite a surprise to me the first time I implemented this!)</p></li>
  <li><p>I think you really only need one template here that simply inspects the url segments and builds the products query from whatever is there.  This part of the question reads a little as if you're confusing the presentation concerns and the data holding concerns (which is not criticism - it's very easy to do!) - your products will live as products over in Commerce, but your actual url routing and display of those at the category level (i.e. the product listing level) - can probably be handled by just one display template.  .  You don't need a 'channel' for these pages as such (they're not pages, rather filtered views).  So probably just a route that points, say, <code>/catalogue/*</code> -> to your one product listing template.  (The actual individual product pages (if they have significantly different displays) - can use multiple templates if need be (or again, conditional logic within the one template)).</p></li>
  <li>There's really no reason that you could not use a route to point say  <code>/products/new</code> to the same template and again inspect the url to build your products query, showing only the newer products.  There's no need per se for a single here unless you want other content on the page or something.</li>
  </ol>
  
  <p>While you described this on slack as a 'noob' question it's not, and it's good to think it through - in some ways this stuff is the hardest part to get your head around with Craft/Commerce.  Once you actually get to implementing it you'll find this bit was actually a lot harder than making it work (well, I did!).</p>
  
  <p>The fact you're using separate urls for everything probably makes it a lot easier than some approaches I think, so nothing in your message really strikes me as unachievable.  The point to understand is that you don't need a channel or section to hold all of these <code>pages</code> - they aren't really pages as such, really they are all views on the same data (all, or some subsets thereof) - you simply have route(s) which point to a single template with logic that inspects the url and filters the products based on that.</p>
  
  <p>More than happy to chat this through more on Slack if that would help.</p>
  
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2016-07-27T04:55:14.377Z
Answers.Text: This answer was very helpful, especially after reading it again post-vacation! You're absolutely right that I was "confusing the presentation concerns and the data holding concerns." Using routes with one template that inspects the URL segments makes perfect sense. I still might pester you on Slack at some point, but this is enough to get me started on this template. Thanks!
Answers.UserDisplayName: Todd Prouty
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2016-07-27T05:25:17.830Z
Answers.Text: One follow-up question. I'm leaning toward using one category group to contain both Product Categories and Shop by Use, with a prefix in the category title that will distinguish them. One less field will speed up loading/modifying the content. I can't think of any way this would complicate matters, can you?
Answers.UserDisplayName: Todd Prouty
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2016-07-27T05:29:36.647Z
Answers.Text: No not really although I think the difference of one field vs. two will be negligible from a performance point of view.  Your way will at least mean you can always choose from either of your pseudo 'groups' with that field, which may be handy.  I've kept mine separate though just because in practise it's mostly nicer to have a shorter list to choose from.
Answers.UserDisplayName: Jeremy Daalder
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2016-07-27T14:00:26.310Z
Answers.Text: Makes sense. This won't go beyond 10 categories any time soon so I think it should work.
Answers.UserDisplayName: Todd Prouty
Answers.ContentLicense: CC BY-SA 4.0
Answers.CreationDate: 2019-10-02T11:47:27.993Z
Answers.Text: Very helpful and polite answer.
Answers.UserDisplayName: nitech
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2016-07-16T08:24:31.237Z
Answers.LastActivityDate: 2016-07-27T05:11:11.640Z
Answers.LastEditDate: 2016-07-27T05:11:11.640Z
Answers.UserDisplayName: Jeremy Daalder
Body: <p>The Commerce site I'm working on (my first Craft project) will have a product listing page with filters. These will function as you would expect, but clicking a filter name will link to another version of the product listing page with another set of products, as opposed to updating the page via AJAX. I'm doing the content modeling now and am wondering if Craft categories are the best way to structure this or if there is a better way. I see it working somewhat like the <a href="http://www.patagonia.com/shop/mens-jackets-vests" rel="nofollow noreferrer">Patagonia product page</a> (click through the categories toward the top of the sidebar and note the URI change). However, unless there's an advantage to doing otherwise, I was just going to use categories for both of the filter sets below. Patagonia uses query string parameters when filtering by sport, whereas this site would have a unique slug(s) for each combination of filters.</p>
  
  <p>Here's what the filters look like. A checkbox or some other visual indication would be given when a filter is selected:</p>
  
  <p><strong>Product Categories</strong></p>
  
  <ul>
  <li>Category 1 (slug: <code>category-1</code>)</li>
  <li>Category 2</li>
  <li>Category 3</li>
  <li>New Products</li>
  </ul>
  
  <p><strong>Shop by Use</strong></p>
  
  <ul>
  <li>Use A (slug: <code>use-a</code>)</li>
  <li>Use B</li>
  <li>Use C</li>
  <li>Use D</li>
  </ul>
  
  <p>The selection options are:</p>
  
  <ul>
  <li>Only one Product Category can be selected at a time (choosing another deselects the previous selection), but a selection is not required.</li>
  <li>Only one Use can be checked at a time (choosing another deselects the previous selection), but a selection is not required.</li>
  <li>A selected filter can be unselected by clicking it.</li>
  <li>With the Product Category and Use options unselected, a page with ALL products is displayed.</li>
  </ul>
  
  <p>A few more notes:</p>
  
  <ul>
  <li>Every product will belong to at least one Product Category but can belong to multiple.</li>
  <li>Every product has at least one Use and most have multiple.</li>
  <li>'New Products' is a unique category that would ideally expire based on a date chosen when adding a product.</li>
  <li>I was picturing the URIs being something like the following:
  
  <ul>
  <li>Category selected: <code>domain.com/products/category-1</code></li>
  <li>Use selected: <code>domain.com/products/use-a</code></li>
  <li>Category and Use selected: <code>domain.com/products/category-1/use-a</code> or <code>domain.com/products/category-1-use-a</code></li>
  </ul></li>
  </ul>
  
  <hr>
  
  <h2>Questions</h2>
  
  <ol>
  <li>Are categories the best tool for this job? If not, what would work better? If so:</li>
  <li>Would it make sense for Product Categories and Shop by Use to be their own category groups?</li>
  <li>Creating category pages is simple enough, but I'm not sure how best to create a page that represents a combination of categories / selected filters (e.g. Category 2 + Use A). I know I can use <code>relatedTo</code> to list products from multiple categories, but what is the best Craft element to use as a container for these pages? <a href="https://craftcms.stackexchange.com/a/14915/4748">This answer</a> was helpful, but it's not quite the same (for one thing, it's not Commerce-specific; it refers to products but I believe they are just standard channel entries). Should the combined-category pages be in their own channel?</li>
  <li>New Products: I'm thinking this should be a static link, possibly to a single (<code>/products/new</code>) that lists products whose "newness" has not expired. Is there a better way?</li>
  </ol>
  
  <p>I'm probably overthinking this! I mainly want to know if I'm heading in the right direction.</p>
  
Tags: <categories><structure><plugin-craftcommerce><contentmodel>
Title: Are categories the best way to organize Commerce product filters?
ThreadText: # Are categories the best way to organize Commerce product filters?
  
  (Asked by: username_0 on 2016-07-15)
  
  The Commerce site I'm working on (my first Craft project) will have a product listing page with filters. These will function as you would expect, but clicking a filter name will link to another version of the product listing page with another set of products, as opposed to updating the page via AJAX. I'm doing the content modeling now and am wondering if Craft categories are the best way to structure this or if there is a better way. I see it working somewhat like the [Patagonia product page](http://www.patagonia.com/shop/mens-jackets-vests) (click through the categories toward the top of the sidebar and note the URI change). However, unless there's an advantage to doing otherwise, I was just going to use categories for both of the filter sets below. Patagonia uses query string parameters when filtering by sport, whereas this site would have a unique slug(s) for each combination of filters.
  
  Here's what the filters look like. A checkbox or some other visual indication would be given when a filter is selected:
  
  **Product Categories**
  
  * Category 1 (slug: `category-1`)
  * Category 2
  * Category 3
  * New Products
  
  **Shop by Use**
  
  * Use A (slug: `use-a`)
  * Use B
  * Use C
  * Use D
  
  The selection options are:
  
  * Only one Product Category can be selected at a time (choosing another deselects the previous selection), but a selection is not required.
  * Only one Use can be checked at a time (choosing another deselects the previous selection), but a selection is not required.
  * A selected filter can be unselected by clicking it.
  * With the Product Category and Use options unselected, a page with ALL products is displayed.
  
  A few more notes:
  
  * Every product will belong to at least one Product Category but can belong to multiple.
  * Every product has at least one Use and most have multiple.
  * 'New Products' is a unique category that would ideally expire based on a date chosen when adding a product.
  * I was picturing the URIs being something like the following:
    + Category selected: `domain.com/products/category-1`
    + Use selected: `domain.com/products/use-a`
    + Category and Use selected: `domain.com/products/category-1/use-a` or `domain.com/products/category-1-use-a`
  
  ---
  
  ## Questions
  
  1. Are categories the best tool for this job? If not, what would work better? If so:
  2. Would it make sense for Product Categories and Shop by Use to be their own category groups?
  3. Creating category pages is simple enough, but I'm not sure how best to create a page that represents a combination of categories / selected filters (e.g. Category 2 + Use A). I know I can use `relatedTo` to list products from multiple categories, but what is the best Craft element to use as a container for these pages? [This answer](https://craftcms.stackexchange.com/a/14915/4748) was helpful, but it's not quite the same (for one thing, it's not Commerce-specific; it refers to products but I believe they are just standard channel entries). Should the combined-category pages be in their own channel?
  4. New Products: I'm thinking this should be a static link, possibly to a single (`/products/new`) that lists products whose "newness" has not expired. Is there a better way?
  
  I'm probably overthinking this! I mainly want to know if I'm heading in the right direction.
  
  **Tags:** categories, structure, plugin-craftcommerce, contentmodel
  
  
  ---
  
  ## 1 answers
  
  ### Answer by username_1 on 2016-07-16. Score: 4 | Accepted answer
  
  1. Hard to say if they're the 'best' tool, but I don't see anything here you can't do with Craft categories and they seem the logical and built in way to go about it. In essence you simply look at your url segments and use these as category filters when retrieving the products
  2. I think so. It keeps the two separate data concerns nicely separated - but do be aware from a UI point of view, separate category groups are very separate things - you can't use one field to select from both groups (quite a surprise to me the first time I implemented this!)
  3. I think you really only need one template here that simply inspects the url segments and builds the products query from whatever is there. This part of the question reads a little as if you're confusing the presentation concerns and the data holding concerns (which is not criticism - it's very easy to do!) - your products will live as products over in Commerce, but your actual url routing and display of those at the category level (i.e. the product listing level) - can probably be handled by just one display template. . You don't need a 'channel' for these pages as such (they're not pages, rather filtered views). So probably just a route that points, say, `/catalogue/*` -> to your one product listing template. (The actual individual product pages (if they have significantly different displays) - can use multiple templates if need be (or again, conditional logic within the one template)).
  4. There's really no reason that you could not use a route to point say `/products/new` to the same template and again inspect the url to build your products query, showing only the newer products. There's no need per se for a single here unless you want other content on the page or something.
  
  While you described this on slack as a 'noob' question it's not, and it's good to think it through - in some ways this stuff is the hardest part to get your head around with Craft/Commerce. Once you actually get to implementing it you'll find this bit was actually a lot harder than making it work (well, I did!).
  
  The fact you're using separate urls for everything probably makes it a lot easier than some approaches I think, so nothing in your message really strikes me as unachievable. The point to understand is that you don't need a channel or section to hold all of these `pages` - they aren't really pages as such, really they are all views on the same data (all, or some subsets thereof) - you simply have route(s) which point to a single template with logic that inspects the url and filters the products based on that.
  
  More than happy to chat this through more on Slack if that would help.
  
  > **Comments:**
  > **username_0**: This answer was very helpful, especially after reading it again post-vacation! You're absolutely right that I was "confusing the presentation concerns and the data holding concerns." Using routes with one template that inspects the URL segments makes perfect sense. I still might pester you on Slack at some point, but this is enough to get me started on this template. Thanks!  
  > **username_0**: One follow-up question. I'm leaning toward using one category group to contain both Product Categories and Shop by Use, with a prefix in the category title that will distinguish them. One less field will speed up loading/modifying the content. I can't think of any way this would complicate matters, can you?  
  > **username_1**: No not really although I think the difference of one field vs. two will be negligible from a performance point of view.  Your way will at least mean you can always choose from either of your pseudo 'groups' with that field, which may be handy.  I've kept mine separate though just because in practise it's mostly nicer to have a shorter list to choose from.  
  > **username_0**: Makes sense. This won't go beyond 10 categories any time soon so I think it should work.  
  > **username_2**: Very helpful and polite answer.  
  
  ---
  
  