Jump to:
| Project: | Ubercart |
| Version: | 7.x-3.x-dev |
| Component: | Code |
| Category: | feature request |
| Priority: | normal |
| Assigned: | Island Usurper |
| Status: | closed (won't fix) |
Issue Summary
So I sat staring at the product classes page scratching my head for a million years until I accidentally deleted one and it said it was reverting back to a regular node type. If product classes are simply node types that have a special option flagged so that Ubercart recognizes them as "product" nodes and adds the various fields, then why not do away with the concept of "Product class" altogether, in favour of just using regular old node types, which Drupalers already understand. The product association could be done by:
1. A checkbox on the node type form to declare "This content type is an Ubercart product."
2. A settings page under Administer >> Store administration >> Products someplace that lists all the node types in the system with checkboxes next to them to declare them as product types.
3. Make the product settings a CCK field that can be added to any node type.
etc.
A plethora of options available ;) any one of them less confusing than the concept of "Product Classes."
Comments
#1
hah, sounds like a very reasonable idea to me. : )
The only other caveat is having default attributes/options, but those can also easily be applied to "node types".
So, a tentative +1 barring any strong reasons against.
(On a side note - thanks soooo much for checking things out and pitching in!)
#2
Hey, np! I'm trying to get this chapter of the book out the door, so just making notes as I find things. :)
#3
Ahh, cool. I did give it a read through earlier, and I'm happy to do once more... but it looks like you're being just as thorough (if not more) than I would be. : )
If you need to chat about the conditional actions stuff, I'd be happy to demo where it's going and fill in any holes with what I expect to happen.
#4
You don't necessarily need to change the way in which product classes are created and managed.
The concept would be much simpler to grasp if the terminology were consistent.
Call them "Product types" or "Product content types" and it becomes much clearer what they are.
#5
I need product classes. keep them, who cares what the name is though
#6
I'm going to let this stew for a while. If we're going to make big changes to how products are handled, that should happen in the 3.x branch. But if it's just a terminology change, then that could possibly go into the 2.x branch.
Feel free to discuss the idea, though I imagine most people won't find this issue until it gets activated again.
#7
Makes sense to wait for 3.x to redo it, and I'd also like to see the same thing working for product kits too.
But in the meantime, let's just do the terminology change, switch the menu title to 'Product Content Types'.
I honestly in all this time using Ubercart just found out about this 'product classes' thing, and a change in terminology would make a big difference.
#8
Yeah to be honest, we use classes all the time. The concept is still the same - classes are just different node types that are sort of "auto-populated" with product-specific fields such as SKU and Price, along with allowing them to associate with attributes etc. So I think the inner workings don't need to change much if at all, but perhaps their usage and need could be made a bit more clear.
I'm not 100% sure on how to accomplish THAT part of things, but I wanted to chime in, as it could be considered part of the larger goal to make Products and their Attribute/Option combos part of a more general "Product Variations" or "Sub-Products" system; likewise, Product Types and their derivatives.
#9
I agree with this. I found the idea of Product classes confusing as well to begin with. Once I grasped it, I completely abandoned them and just used the default Product node-type that gets generated when activating the module, and just 'catalog' my products accordingly.
#10
That's not quite what I agree with. The beautiful thing about product classes IMO, is the ability to say in Views for instance to filter all nodes that "are products". If you just go in and create a bunch of node types that you consider products, but Drupal doesn't, then your job to filter them becomes increasingly difficult, and you'd have to update your Views every time you add a new node type that is considered a product by you (but not Drupal).
With regard to using taxonomy only, I did that for a while but found issues again with taxonomy as things became more complicated. Also, using product classes allows you to theme your products differently using node-product.tpl.php, node-producttypetwo.tpl.php, etc. Otherwise you're left with just using the default product template and that makes life much, much harder.
#11
The issue here is not to ditch the feature, just improve the way it's presented both as a concept and in the UI.
Whether you use different node types or taxonomy to create different kinds of products really depends on what your products are.
With node types you get different node templates, different CCK fields, different permissions: whether these are good or bad depends entirely on what your products are.
For example, if you're selling DVDs and t-shirts then you probably want a size field and an age rating field and so different nodes would be the way to go.
You might even want to combine the two systems, and have node types THEN a taxonomy.
As for the problem with views described by torgosPizza, it would probably be possible to add a filter to view that checks whether a node is considered as a product by Ubercart, rather than having to choose all the product node types.
#12
This late in the game, I'm going to second Lyle's postponement, even though I wish we could change it. We'll be sure to address this early in 3.x. : )
#13
Can't you just change 'product classes' to 'product types'? That alone would be a big leap forwards in usability.
#14
Usability for new users arguably, but not for the hundreds who have been using product classes and reading / writing about them on the forums and docs. Also, this would still require a schema change to update class language to type language, so I don't think it's worth it atm.
(In case that sounds like a silly reason, the thought there is to make sure we aren't introducing dissonance between the user interface/what all the docs say and what developers and modules actually have to work with. Think Taxonomy -> Categories -> Taxonomy.)
#15
I think this is a required feature, but with an ambiguous name. It should be Product type, not class.
1. "Product type" is more like "Content type", and is merely a way to define different kinds of products with different characteristics. eg. A "Book product type" would have a Title, author and ISBN field, whereas a "Cheese product type" would have just a name (Title). This is analogous to how Drupal deals with content types.
2. I think "Classes" leads to confusion with taxonomy (ie class-ification), and CSS classes.
3. And then it would make sense that the Drupal Content Type page includes a link to the Ubercart Product Type.
#16
Yes; this issue was only ever about what these things are called, not about the feature itself.
#17
#18
I know it's a pain but I also agree with changing the "product class" name to something more semantic like "product type" or "product category".
#19
Ultimately, perhaps product classes/types can be done away with altogether, if #525612: Allow any node type to become a product is implemented.
#20
How do I activate the Multilingual feature of created Product Classes?
Currently it´s being displayed, but everthing is greyed out.
The new Product in its classes are now defined as anguag nutrual.
#21
Please do not hijack existing issues. You have already asked this question at #1324866: New product classes are not translatable and it will be dealt with there eventually.
#22
...and back on topic, should we change this terminology now before 7.x-3.0, or is it too late for that?
#23
I also think that a Product class isn't exactly a node type, so it might be just as confusing, or even more confusing, to name them as if they were. My desired solution is one where we can make any node type (not just a "CCK "type) into a Product, in which case product classes will no longer be needed because they truly will be just node types.
I'd rather not change something substantial like this at the last minute.
#24
So let's mark this won't fix, in favour of implementing #525612: Allow any node type to become a product at some point.