2

I'm currently building a site using Craft and Craft Commerce. And when working between the two, I'm looking to make a page that shows all the products from a product-type, and have the header image change to reflect whichever product-type it is.

I know it is currently possible to make a category, assign an image to the category, and then add a category entry field to a product, allowing to organize products that way, but it seems terribly redundant, having to both put a product in a product-type, and then to also assign a category.

Is there any way to simply assign an image to the product type?

| improve this question | |
  • I assume you want those product type images to be managed through the CP and not just hard-coded into the template? – Brad Bell Jan 20 '17 at 20:58
  • I've been wondering this same thing. I've got 5 product types (although some have the same fields etc) so maybe I should look at generalising the names and using Categories instead? @BradBell I'd want to be able to manage the images through the CP though, yes. – Tom Feb 16 '17 at 22:06
1

I would say it's intended that you use Craft's in-built system for product classification/hierachy/taxonomy - i.e. Categories.

Categories have support for custom fields of course, thus you can add backend manageable category images easily using an assets field, and you can also leverage all the things categories can offer without requiring anything extra from Commerce. And any plugins etc. that work with Categories then work out of the box with your products, too. Indeed, with Craft's neat separation of Category Groups, this still allows for good separation of your products from the rest of your data (whatever that might be, blogs etc).

I would recommend Product Types instead for managing separation of data concerns more so than product classification. That is to say, if you have products requiring clearly different data (e.g. your sell monitors, and printers - these clearly require different lists of specifications) - that's a good use of Product Types allowing you to have the specific fields you need for these things nicely separated.

In addition to specific product types where your data determines you need them, we find it handy to have generic product and product with variant types to cover those sundry things that don't fit neatly into the various data separations we've made - with these things having just the core fields that all your products share.

| improve this answer | |
  • I appreciate that perspective but I disagree with it. From a dev perspective I can see that but from an editor end user perspective I think its confusing. A "normal" user when selecting a new product to add (and seeing a list of product types) is going to think of that as categorization. If they are adding a new "printer" product type then they probably assume it would fall under a "printers" category on the site. I agree with the original poster that having to add category fields to handle this seems redundant - but also unintuitive. Product types should have their own attached fields. – Mike Mar 9 '17 at 10:13
  • Well, in this case I'm both the dev & the "normal" user - as are my direct staff. I can't say it's confused any of them in practise - if you set up the content entry form for product types clearly, the categorisation using a categories field is clear & easy, and considerably more powerful using 'real' categories & their advantages rather than just fields on the type which would only handle simple scenarios in comparisons. The categories approach is universal to the other element types too, so I'd argue its more consistent this way and in my experience consistency is good for 'normal' users. – Jeremy Daalder Mar 9 '17 at 22:35
  • Well, we'll have to agree to disagree on this one. =) Even on the admin side, this is going to be a bit of UX nightmare. We have dozens of categories across many thousands of products but when it comes to a user making sense of these in the admin, the right side column which shows Product Types will feel to users as if this is what should be used to quickly jump between those logical groups (in my experience end users think about their products as per their companie's catalogue - and other "categorization" (which is what Products Types will be to an end user) just confusing the issue). – Mike Mar 10 '17 at 8:20
  • Yep, agree to disagree :) Just again - It's far from a 'UX nightmare' in practise with our large, complex site. Perhaps think of the 'right side' i.e. product types as a major grouping and categories as the full taxonomy. Adding fields to product types won't solve what you're asking, you'd basically need taxonomy support again w. Product Types - which is precisely what categories gives you in a consistent way for all element types. I guess all I am saying is that once it's in practise, and show it to editors, it's really not a major issue. Not saying things can't be improved, of course. – Jeremy Daalder Mar 11 '17 at 0:36

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.