Website specific product fields

[daniel.rebane]

Hi,
Our customer has multiple websites and requires website-specific product fields. For instance, the description must differ between website A and website B. We aim to avoid the addition of separate fields such as ‘Description A’ and ‘Description B,’ as our customer may add more websites in the future, leading to an unwieldy list of product fields. Are there alternative approaches we have not considered?

Litium version: 8.12

[Martin.Brandt]

You have the possibility of creating a custom field in Litium.
You could in theory build a field where user first select website from a dropdown of all current websites, then selects language (if necessary), then adds description.
As part of building a new field, you build an Angular panel that Backoffice loads when the field is displayed, there you control how the customer enters data (its in the guide below).

You build the logic in Litium how the field stores and retrieves its own data from the Product.VariantFieldData table (its in the guide below how to do that), it can store many rows of data for one field. And since “Guid” is a standard field on those rows, you could stick the website system id in that field.

So you’d end up with somethign like this in the database table for Variant.ProductFieldData:

FieldDefinitionId = ‘DanielsCustomField’
Culture = ‘sv-SE’
TextValue = ‘the text customer wants’
GuidValue = ‘the website system id’
ChildIndex = 0 (=for each value/website it will be a new index)

Your code will instruct the platform on how to store and retrieve this data, and the guide below explains how:

I leave it up to you to decide if this is the way you want to go, check: How to create custom field types

[felixfroberg]

If using culture is not possible I’d probably use different fields for each website, separated into field groups (one per website). You could build logic to find the correct field based on field group or field id, and if the extra field groups are colapsed by default it wouldn’t bother any BO users to much.