I'm working on an ecommerce site following Helix principles.

Is it OK to store product data on (or under) the product page items?

The project layer page template could inherit a data template from a feature module.

 - Home
  - Products
   - Product XYX
    - Local Content
     - Product Data (could do this, or make product page inherit this item's template)


  • Simple IA and easy for content editors to manage


  • Product pages can grow quite large with many fields
  • Restricted to using a 1:1 relationship between products and pages. (difficult to show same product in two different places).

Another other approach is for product pages to reference items under a separate branch of the tree e.g. a data folder.

 - Home
  - Products
   - Product XYZ (links to Data/Products/Product XYZ)
 - Data
  - Products
   - Product XYZ


  • Easy to share product data between different pages


  • Harder for content editors to manage. New product, means new page item and new data item plus needing to establish link between the two.

To summarise my question:

Is it within Helix principles to have product data on product page items?

Are there other benefits or drawbacks of these approaches I need to consider?

1 Answer 1


This is a similar discussion I've been considering on something we are currently building. Typically another scenario is adding data directly to the Product item for them to configure and then you would pull using the context item. Although in that approach you would also still want a datasource reference, so that things could be personalized or A/B tested etc.

Which approach you end up taking depends on a lot of factors and doesn't necessarily relate to a good question on Stack Exchange because its opinion based. However that's not exactly what you asked. So the question is can you add product data to product page item (I'm assuming you mean a page type template called product page). Absolutely, but not directly. You should define interface templates (which are defined in the foundation/feature layer) which then your page type templates would inherit from.

Also if you went with your first approach where you have datasources that are specific to a product, then there again you would define a datasource template (at the project layer only) and optionally you could also define folder templates (any layer) to organize your datasource templates. Those datasource templates just like page type templates wouldn't contain any fields directly, but instead inherit from interface templates which would be defined in the various modules in helix based on their functionality.

The only issues with this approach that I can see, is if you have renderings that might have datasources located in multiple locations, you would either have to customize where it pulls those datasources from or just not specify a datasource location on the rendering.

The second approach you described benefits because you can have one data source shared across multiple renderings. The only issue which you need to decide based on your architecture, is if it even makes sense to do that. Example, a product model number shared across multiple renderings, probably doesn't make much sense. Whereas a Section Title or some form of Ad, very well might make sense. You could always vary and do both approaches as well. Using this approach for the datasources that are shared, and then renderings that are specific to products, to use the local children data source approach.

Also one thing to note, is yes your content tree shouldn't be extremely confusing for content editors, but it should always be logical, so yes it might require editing items in another part of the tree with the content editor, but I wouldn't base this decision just on that. Especially if your content editors are using the experience editor, they wouldn't really know where all of the datasources exist inside of the content tree.

You should follow Helix best practices with template types and how each type inherits or is used in specific places in your solution: http://helix.sitecore.net/principles/templates/template-types.html


Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

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