Products standard

[kraftner]

As I'll soon start a promotional site where I'll need products I thought I'll chime in on this here.

Definition

From schema.org

Any offered product or service. For example: a pair of shoes; a concert ticket; the rental of a car; a haircut; or an episode of a TV show streamed online.

Thoughts

I just quickly note my initial thoughts to kick off the discussion:

1. Products can be meant to be used in a shop but also in a solely promotional website. Both are valid use cases but might mandate different structure/data
2. The definition above includes services which currently is a separate standard. Also Books, Vehicles and alike might be seen as sub-standards to this.
3. Some Products might have variations or even sub-products with those two blending into each other gradually. Should this hierarchy be inherent in the CPT? Or is it something to handle outside of the CPT hierarchy?
4. Products need a lot of metadata on specs. Schema.org even has a subtype ProductModel

   Post Type

product

Taxonomies

Product Category

This is a general-purpose, hierarchical taxonomy for products.

• _product_category

  Product Tag

This is a general-purpose, non-hierarchical taxonomy for products.

• _product_tag

  Meta

Again just an initial thought, mainly inspired by schema.org

• _product_brand
• _product_color
• _product_id
• _product_manufacturer
• _product_model
• _product_price
• _product_size (might be better split into depth/width/height)
• _product_weight
• _thumbnail_id

This is the most basic stuff I can think of. But of course this can be extended endlessly from _product_display_size to more and more generic stuff like product_spec_foo_bar_conformance. The question will be how far we'll go here.

Other Data

Product Title

Product titles should be saved in the standard post_title field.

Product Content

Product content should be saved in the standard post_content field. This may include text, images, and/or other media.

Product Excerpt

Plugins may optionally add support for excerpts. This data would be saved in the standard post_excerpt field.

Final notes

Concerning the use of Products for ecommerce maybe someone with more experience can add his thoughts as I do not feel competent enough myself.

[justintadlock]

I don't think I really belong in this particular discussion because I don't have the experience necessary. One of the things I encourage you all to look at is existing popular plugins such as WooCommerce, Easy Digital Downloads, and others. See what common ground you can find from each of them.

[kraftner]

Concerning the ecommerce stuff I'll have to say the same about me. As already said I'm coming from the other end of a purely presentational/promotional look on products. If that even is a valid use case or just an ignorable edge case might also be up for discussion.

[AlchemyUnited]

Also doesn't Google have a service where you can upload your products so it's listed somewhere. Sorry the name of that Google product escaped me at the moment.

That said, I would imagine eBay and Amazon have (XML based?) specs as well. It would seem those would be good places to start.

[hchouhan]

@AlchemyUnited that was Google Base.

[hchouhan]

@AlchemyUnited, now I understand why you asked. Google had a pretty good documentation somewhere on how the XML's should be structured. Maybe we could pick up from there.

[AlchemyUnited]

@hchouhan - yup. not need to re-invent the wheel. that's the whole point here eh :) i think it might be ok to extend the industry standard(s) but those should at least be a suitable subset of this whole. at least that what feels like the best sense to me.

i've been kinda tracking all this activity from the background (i.e., not my full attention). let me know if /. how ic can help.

[kraftner]

A link to to that Google XML thing would be great.

[hchouhan]

@kraftner here it is https://support.google.com/merchants/answer/188494?hl=en

[AlchemyUnited]

Amazon: http://www.amazon.com/gp/help/customer/display.html?nodeId=1161312

eBay: http://pages.ebay.com/turbo_lister/csv.html

How about the hosted / cloud ecomm solutions (e.g., Volusion). If ya can help me come up with a preferred short list I can track down their support pages.

p.s. That said, a universal cross platform standard for all these titans feels like an elephant that probably can't be eaten one bit at a time. So can I re-suggest a import / export "spec" / helper class? :).

[ascottmccauley]

Some Products might have variations or even sub-products with those two blending into each other gradually. Should this hierarchy be inherent in the CPT? Or is it something to handle outside of the CPT hierarchy?

My take on this is that there should definitely be a _product_options meta that can include whatever might be needed (and maybe move _product_color under _product_options).

As a photographer selling prints, I hate when variations are all auto-generated (since I'm selling the same 'products' for multiple images), so if you wanted to work out a method/function for allowing variations to be created, then great, but please don't make it an assumption for how _product_options would be used.

[georgestephanis]

Yo dawg, I heard you liked meta, so we put all your meta in a single meta, so you can meta while you meta?

So meta.

But srsly, why shove them all in one key, when this is what Meta is meant to handle?

[kraftner]

@ascottmccauley Not sure if I do follow, but if you are proposing to serialize multiple meta values in a single meta key I'm with @georgestephanis that this is a bad idea.

[ascottmccauley]

I don't see an issue with making a single hierarchical _product_options. I guess _product_color doesn't have to be an 'option' though, since it wouldn't be user-defined.

It just seems like most 'products' are going to have a set of 'options', but there is no way of knowing what they would be: T-shirts would have variations of 'size' and 'color', Guitars would have 'wood-type', 'string-type', 'paint-color', 'inlay-color'...

[kraftner]

@ascottmccauley There is no such thing as hierarchical post meta. The only way to achieve this is serializing multiple values under one key which leaves a mess behind. But I think you misunderstood something. _product_color doesn't have to be used. But if there is a color associated to the product the meta key has to be called product_color and nothing else.

[georgestephanis]

This does bring up the point of how to do options in products. If we have a product with three skus under it, one being each red, green, and blue, would each be an individual product, kitted together into a complex product? Or just option arguments passed through on the purchased version of the product in the data store?

[kraftner]

Good point. Might as well be worth looking at how the current solutions do it.

BTW: sku = Stock keeping unit Just in case any one else wasn't aware of that abbreviation.

[georgestephanis]

Further, should we store purchased instances of a catalog product archetype as a commonly defined standard as well? Or maybe the same CPT, but with a custom post status? Or should that be left unspecified for each ecomm system to do their own way?

[ascottmccauley]

There is no such thing as hierarchical post meta.

Sorry, not enough coffee this morning. I'm thinking of taxonomy.

[georgestephanis]

Also, then, be sure to check non-WP systems like Magento. I'll try to write a summary on it in a day or so, but it supports both ways, and is kind of a beast.

Part of me suspects that most of this should be spun off into a separate repository or just have a pin in it, so it doesn't become a sticking point, preventing progress on the rest. On Aug 18, 2014 4:14 PM, "kraftner" notifications@github.com wrote:

Good point. Might as well be worth looking at how the current solutions do it.

— Reply to this email directly or view it on GitHub https://github.com/justintadlock/content-type-standards/issues/16#issuecomment-52497526 .

[kraftner]

I've been thinking about this one more time and product seems to be one of the most complex items on our list.

Also the more I think about it I was wondering if a product in the context of e-commerce with stock, purchases and alike might just be something different than a simple list of products for a catalogue without any further features.

Maybe we can start with the simple one just listing products like in a catalogue and leave all the complexity of stock, ordering, payment,... for later. What do you think?

[AlchemyUnited]

fwiw, there's a WooComm group on FB. A couple days ago someone mentioned Woo, schema.org, etc. Maybe there's some knowledge in that thread?

[kraftner]

@AlchemyUnited I'd appreciate if anyone can check that and add relevant info here. I'm not going to get a FB account just for that. :smile:

[AlchemyUnited]

@kraftner - hehe. i don't blame you. i think the crux is how schema.org treats products. that's probably the gold - or at least silver - standard.