Content Models (Shopify customers)

overview our performance starters (applicable in cases when chord is using shopify as an oms) use existing content models that have been provisioned by the team at chord commerce when we bootstrapped your cms environment you can use the (simplified) diagram below to learn more about how core models are interconnected diagram of content models on chord with shopify e commerce content models when starting with chord performance, your initial cms space will come with more cms types than what are listed here you are free to remove/edit content types that are not listed here the content types listed here are all required for chord's to function properly with that said, you are free to add whatever fields you would like to the following content types, so long as they do not clash with the fields explicitly listed common required fields most of chord's content types have a set of required fields across them that are required for chord to properly function these fields are frequently used so that our oms / cms sync docid\ nfucokbs dskcw 99m41 can sync changes between the cms and shopify you should not remove these fields from content types as it will break syncing from the cms to shopify and vice versa name the name for an item that may or may not be displayed to your customers in the storefront's ui in chord's performance starters we note cases where the name is displayed to customers in specific content types in this document it will be shown in the cms as the title for a given entry and it may be synced to shopify, in the case of content types like products and variants generally, the name for an item should make sense from an operational standpoint and not a marketing standpoint it is a required field and should not be removed from a content type if it's provided to you as a part of your initial cms space some examples of the name format are the plant store colorado blue spruce poplar tree it is recommended that you add a name field to all custom content types that you end up creating, even if you do not display the name to a customer slug the slug field is a slugified string that is unique to that content type and is the human readable identifier for a given item this field can be used in urls to route to the item some examples of the slug format are the plant store colorado blue spruce poplar tree if this field is present in a content type provided to you in our initial cms space, you should not remove it from the content type , as that will break elements of our oms / cms sync docid\ nfucokbs dskcw 99m41 from the cms to shopify it is recommended that you add a slug field (or something like it) to each custom content type that you end up creating in the cms, even if you don't plan to route to it initially having a unique, stable, human readable identifier can be very helpful when querying for a single record changing the slug after it has been set can lead to some syncing issues with shopify for certain content types when changing it for types like products or variants, you should check shopify afterwards to see if duplicate items were created use case to illustrate the content models used by chord performance, we are going to imagine a store that sells a variety of plants called "the plant store " the plant store is an established business that sells houseplants, shrubs, flowers, trees, and plant supplies, like soil and plant food the plant store currently has a single storefront located at https //theplantstore com catalog the catalog is the top level taxonomy for the items in a store for most performance based storefronts, there will be one catalog for all items in the store required fields field name field description content models (shopify customers) docid\ ep9fwknbrovjspjlkpx5w the name for an item that may be displayed to your customers content models (shopify customers) docid\ ep9fwknbrovjspjlkpx5w a slugified string that is unique to that content type and is the human readable identifier for a given item collections a many to many reference of collections in this catalog use case the plant store is coming to chord with an existing storefront that sells houseplants, shrubs, flowers, and plant accessories the plant store should create multiple collections corresponding to their verticals ( houseplants , shrubs , flowers , etc ) and associate them with the singular catalog record with the slug of catalog collection a collection is a grouping of items for sale in a storefront in the performance default content model, a collection is a grouping of products and kits it should be noted that products and kits can exist in multiple collections required fields all of these fields are required for chord's do not remove them from the collection content type field name field description content models (shopify customers) docid\ ep9fwknbrovjspjlkpx5w the name of the collection by default, in our starters, this is not shown to the customer and is used as an internal identifier content models (shopify customers) docid\ ep9fwknbrovjspjlkpx5w the slugified https //en wikipedia org/wiki/clean url#slug identifier of the collection products a many to many reference to the products content type that represents all the products in this collection kits a many to many reference to the kits content type that represents the kits in this collection use case the plant store sells many plant accessories, such as soil, pots, vases, plant food, and everything in between they would like to have all these accessories in an "accessories" collection on the site, and they would also like some of their vases to show up with their flowers in order for the plant store to do this, they would create their "accessories" collection along with their other plant focused collections , like "flowers " add all their accessory products to the "accessories" collection add some of the vases to the "flowers" collection product a product is an item for sale in a storefront it contains information about the product, like the name, description, ingredients, and other metadata products can be managed in both the cms and shopify (if you have bi directional syncing enabled, otherwise only cms > shopify works) an important fact to know is that the product content type itself does not have information like the price, sku , weight, and other pricing/shipping information, nor should it contain this information this information will be set in one or more of the product's variants required fields all of these fields are used by the chord's and should not be removed from the product content type field name field description content models (shopify customers) docid\ ep9fwknbrovjspjlkpx5w the name of the product in our starters, by default, this name is shown to customers, both in the store's ui and in the \<title> tag of the document content models (shopify customers) docid\ ep9fwknbrovjspjlkpx5w the slugified identifier of the product in our starters, by default, this is used in the path portion of the url to route to the product display page main image the primary image to be shown for this product it is used not only on your website, but also in the google search results for this product (through the product feed https //github com/chordcommerce/chord ui/tree/main/packages/product rss feed ) and other metadata about this product it is also synced to shopify through our oms / cms sync docid\ nfucokbs dskcw 99m41 and will show up in that ui it may be shown in shopify's checkout and in their shop app for shipping updates option types option types are modifiers for a product if you were to sell a t shirt, the size of the shirt for sale would an option type and the sizes (small, medium, large) would be option values variants a product is required to have at least one variant which represents a sku, which is an item type in your warehouse there must be a variant for each combination of the product's option values the variant contains data for the product for pricing, shipping, discounts, and more subscription the subscription field allows this product to be purchased by customer on a recurring basis by adding a reference to an instance of the subscription content type use cases to help illustrate some of the finer points of the product content type, consider the following use case the plant store sells red, yellow and purple tulips the customer can purchase these tulips in a size of small (5 tulips), medium (10 tulips), or large (30 tulips) in this use case, we are going to model the plant store's content to work with chord's performance starters, which have product display pages with select menus for all possible variants for the product there is nothing stopping you from having variant display pages where customers can buy specific variants there are two ways that the plant store could model their products and variants all tulips on a single page in this use case, the plant store would like all tulips for sale on a page with the url of https //theplantstore com/products/tulips in order to do this with chord's performance starters, they do the following create a product named "tulips" create the option types for the "size" and "color" create the option values for the "size" option type ("small, "medium", "large") and "color" option type ("red", "yellow", "purple") add a variant for each combination of of the option types/values with names like "red small tulips", "purple medium tulips", "yellow large tulips" and so on (there will be 9 variants attached to the "tulips" product) the biggest advantage to this approach is that you get a single logical product to manage all the skus in the cms each color of tulip has its own page in this use case, the plant store would like for each color of tulip to have its own page to do this, they would create a product for "red tulips", "yellow tulips" and "purple tulips" on each product , they add an option type for the size of the order and create three variants on each tulip product corresponding to the size ( small , medium and large ) the advantages of this solution include better search engine optimization, in the default product display page setup in our starters, as it's more likely to catch specific queries like "red tulips" with this approach easier top level product management in the cms, as the individual colors are easier to view at a product level than they are at a variant level variant the variant content type corresponds to a type of item in your warehouse and contains all the pricing, discounting, shipping, and warehouse metadata for a product all products must have one variant per combination of option types attached to it if there are no option types on the product , the product must still have one variant record that represents its only variation to reuse an analogy from the product section, if you are selling a "t shirt with the chord logo," a variant of it would be a "medium t shirt with the chord logo " if your customer is on a product page, they can be presented multiple variants of that product the customer is able to select that variant by making selections of that product's option types which will map to option values placed upon the variant if you were selling a "medium t shirt with the chord logo," you would create a product named "chord t shirt" add a variants to that product named "small medium chord t shirt," "medium chord t shirt," and "large chord t shirt" add an option type named "t shirt size" to the "chord t shirt" product add option values to the "t shirt size" option type named "small," "medium," and "large" add the option values to the variants ("medium" option type to "medium chord t shirt" variant , repeat for the "small" and "large" option types) the starters provided by chord have product pages and checkouts already set up to work perfectly with this product/variant/option type/option value setup required fields all fields listed here are required and should not be removed from the variant content type field name field description content models (shopify customers) docid\ ep9fwknbrovjspjlkpx5w the name of the variant in the performance starters, this name is displayed to the customer when the variant of a product is selected shopify id the id of the variant in shopify this id is mainly managed by the oms / cms sync docid\ nfucokbs dskcw 99m41 to shopify for example, when publishing a new variant in the cms, this id is returned by the shopify api and set in the cms you shouldn't need to set this field manually, except in exceptional cases main image the primary image of this sku this image may be shown in shopify's checkout and for shipping updates in their shop app price the price of this variant of the in the currency defined in shopify for this storefront if you are thinking about setting up your storefront for multiple currencies, reach out to the chord team for further discussions regular price if the product is on sale (or you want it to appear as if it's on sale), this is where you would set the regular price, non "discounted" price if it is not on sale, this field should equal the value in the price field weight & total packaging weight this is the weight of the product variant without packaging and with packaging these fields can be used to calculate how much shipping might be for some shipping services in shopify sku the internal identifier for this product variant it is used by chord's oms / cms sync docid\ nfucokbs dskcw 99m41 to sync pricing and shipping information to shopify, so the sku shouldn't change and should be considered stable this field can functionally serve the same purpose as the slug on other content types global trade item number the upc /barcode for this product variant vendor the name of the product's vendor this field is required for shopify and our oms / cms sync docid\ nfucokbs dskcw 99m41 option values a many to many reference to the option values content type it is used to match the variant to what the user wants to purchase on a product page use case the plant store sells sunflowers they sell them in bunches of 6 (small, $20), 12 (medium, $40), and 20 (large, $65) sunflowers are in season right now and they have a surplus of them in stock and have to move them quickly to do so, they are going to offer a discounted price when customers purchase larger sizes, discounting a medium order of sunflowers to $30 and a large order to $50 in order for the plant store to offer sunflowers in such a fashion, they would create a product named "sunflowers " create an option type named "size " create option values that reference the option type "size," named "small", "medium," and "large " create variants for the product "sunflowers" named "small sunflowers," "medium sunflowers," and "large sunflowers " set the option values on the variants to match their size through the "size" option type set the prices and regular prices on the variants to match the one described in the use case option type the option type content type represents an option for the customer to pick when adding a product to their cart imagine the option type as a dropdown in a form and the values in the dropdown would be option values if you were selling t shirts, the size of the shirt would be an option type with option values for "small," "medium," and "large " option types are part of the glue that binds a product to a variant to make an analogy to html (and how it might show up in the chord ui), the option type is a \<select> element and the option value is the \<option> element for that \<select> it is encouraged that you reuse option types (where it makes sense) across your products required fields all of these fields are required for chord's to work properly do not remove them from the option type content type field name field description content models (shopify customers) docid\ ep9fwknbrovjspjlkpx5w the name of the option type this is primarily used as an internal identifier in the cms interface to describe the option type and is not displayed to customers in the chord performance starters by default content models (shopify customers) docid\ ep9fwknbrovjspjlkpx5w the slugified identifier of this option type to continue the html \<select> analogy from above, this field maps to the name attribute on the \<select> element option values a many to many reference to the option value content type presentation the human readable description of this option type to continue the html \<select> element analogy from above, this would be the \<label> for the \<select> use case for a detailed use case of how to use option types , please refer to the content models (shopify customers) docid\ ep9fwknbrovjspjlkpx5w option value the option value content type represents an option for an option type if you were selling t shirts, the size of the shirt would be an option type and "medium" or "large" would be an option value option values are part of the glue that binds a product to a variant through option types to make an analogy to html (and how it might show up in the chord ui), the option value is an \<option> element to a \<select> represented by the option type content type required fields all of these fields are required for chord's to work properly do not remove them from the option value content type field name field description content models (shopify customers) docid\ ep9fwknbrovjspjlkpx5w the name of the option value this is primarily used as an internal identifier in the cms interface to describe the option value and is not displayed to customers in the chord performance starters by default content models (shopify customers) docid\ ep9fwknbrovjspjlkpx5w the slugified identifier for this option value to continue the html analogy from above, this would be the value attribute for the \<option> element presentation the human readable description of this option value to continue the html analogy from above, this would be the text inside of an \<option> tag use case for a detailed use case of how to use option values , please refer to the content models (shopify customers) docid\ ep9fwknbrovjspjlkpx5w