> ## Documentation Index
> Fetch the complete documentation index at: https://dokumentation.websale.de/llms.txt
> Use this file to discover all available pages before exploring further.

# Import file prod.cfg

> Structure and content of the import file prod.cfg: product data fields, category data, and other sections that WEBSALE V8s writes during the product data import, plus three practical cases for reference.

The import file `prod.cfg` is the only configuration file of the shop that you don't write, but only read. WEBSALE V8s generates it automatically with every product and category data import. It records which product data fields the shop knows, which categories exist, and how both are configured.

That's exactly why it's the most important reference when you, as a designer or partner, don't have access to the leading ERP system. Instead of asking the shop operator which data actually arrives, you can see it here directly.

You can find the file in the online service area (OSB) under the "Configuration" service, as a readable file per subshop.

> [!WARNING]
>
> Don't edit `prod.cfg` by hand. The next product data import overwrites the file completely.
>
> There is one exception: category fields that you have enabled for manual maintenance in the TopRank Manager are written back into the file by the import after writing. These fields therefore don't come from the ERP system and survive every import. You define which fields these are in the TopRank Manager.

Basics: Configuration basics · Guide: Category description, Display a category

> [!NOTE]
>
> The meaning of the individual product data fields is described in the separate interface documentation at [doku.websale.de/schnittstellen](https://doku.websale.de/schnittstellen). This page explains the structure of the file and the parameters the shop reads from it.

## Basic structure

`prod.cfg` is structured like the other configuration files of WEBSALE V8s. It is divided into sections that are opened with `<..>` and closed with `</..>`, and each section contains parameters in the form `Name = Value`.

Two peculiarities distinguish it from the manually maintained configurations:

The entire file is enclosed in a `<Prod>` to `</Prod>` bracket. This isn't mentioned in the previous documentation and is added here.

The category data always comes at the end. During import, WEBSALE V8s removes everything from the first `<Category>` onward and appends the newly generated category sections. Everything before that is preserved, everything after it is replaced.

These sections occur:

| Section | Content |
| - | - |
| `Cfg` | Base directories and default images |
| `InventoryCfg` | Default texts and reservation time for the stock level display |
| `DownloadCfg` | Default values for download products |
| `AttributeNames` | all product data fields, standard fields and custom fields |
| `GlobalCategoryFilterCfg` | globally valid filter criteria for categories |
| `AutoBasket` | Products that are automatically added to the cart |
| `Category` | one section per category |

> [!NOTE]
>
> The previous documentation only mentioned `AttributeNames` and `Category`. The shop also reads the other five sections from `prod.cfg`; they are added here.

## Product data fields: `AttributeNames`

The `AttributeNames` section contains all product data fields of the shop, both standard fields and custom fields.

> [!WARNING]
>
> This section is mandatory. If it's missing, the shop aborts with an error message. This isn't documented and is added here.

### Standard product data fields

Each standard product data field has its own section within `AttributeNames`. The section name is the internal field name and is fixed; `FieldName` is the externally visible name you use to address the field in tags.

Excerpt for the standard field `Name`, the product name:

```ini theme={"theme":{"light":"github-light","dark":"github-dark"},"languages":{"custom":["/languages/websale.json"]}}
<AttributeNames>

   ...

   <Name>
      FieldName      = Name
      DisplayName    = Name
      DepVar         = yes
      Visible        = yes
      Search         = y
      SearchSuffix   = q1
      Order          = 1
      Sort           = VARCHAR
   </Name>

   ...

</AttributeNames>
```

| Parameter | Meaning |
| - | - |
| `FieldName` | the external field name. You use it in templates and tags. If it's missing, the section name applies |
| `DisplayName` | the display name that the shop outputs, for example, via filter criteria |
| `BaseDir` | Base directory if the field content is a file name |
| `Search` | whether the field is searchable. `y` enables search |
| `SearchSuffix` | the suffix under which the field is stored in the search index |
| `Sort` | whether the field is sortable, and with which data type |
| `CatFilterOrder` | Sorting of the selection list when the field serves as a filter criterion at category level. `Int` sorts numerically, `list` according to a stored list |
| `CatFilterEmptyEntry` | Text for the empty entry of this selection list |

> [!NOTE]
>
> `BaseDir`, `CatFilterOrder`, and `CatFilterEmptyEntry` aren't described in the previous documentation and are added here.

Two behaviors are important when reading:

The shop only evaluates `SearchSuffix` if `Search = y` is set. If there's a different value, the suffix is ignored, even if it's in the file.

`Sort` makes a field sortable as soon as any value is set. The specific data type, `VARCHAR` in the example, plays no role in this decision.

### Custom product data fields

For each custom product data field, a `<UserField>` section is created within `AttributeNames`.

Excerpt for the custom product data field `Erscheinungstermin`:

```ini theme={"theme":{"light":"github-light","dark":"github-dark"},"languages":{"custom":["/languages/websale.json"]}}
<AttributeNames>

   ...

   <UserField>
      FieldName      = Erscheinungstermin
      DisplayName    = Erscheinungstermin
      DepVar         = yes
      Type           = 0
      OutPutType     = text
      Uid            = 2-5162
      SearchSuffix   = kz
      DepSearchOrder = 0
      Order          = 247
   </UserField>

   ...

</AttributeNames>
```

| Parameter | Meaning |
| - | - |
| `FieldName` | the external field name you use in tags |
| `DisplayName` | the display name |
| `BaseDir` | Base directory if the field content is a file name |
| `OutputType` | how the shop outputs the content. `list`, `file`, `meta`, otherwise text |
| `OutputStyleName` | Name of the output style |
| `Search` | whether the field is searchable. `y` enables search |
| `SearchSuffix` | the suffix in the search index |
| `DepSearchIdx` | Index of the field in the dependent search |
| `DepSearchOrder` | Sorting in the dependent search |
| `Sort` | whether the field is sortable |
| `CatFilterOrder` | Sorting of the filter selection list. `Int` or `list` |
| `CatFilterEmptyEntry` | Text for the empty entry of this selection list |

> [!NOTE]
>
> `BaseDir`, `OutputStyleName`, `DepSearchIdx`, `Sort`, `CatFilterOrder`, and `CatFilterEmptyEntry` aren't described in the previous documentation and are added here.

Here, too, it's worth looking at the actual behavior:

The order of the `<UserField>` sections in the file determines the internal numbering of the custom fields. The first custom field internally becomes `User1`, the second `User2`, and so on. If you want to know which custom field is behind `User7`, count the `<UserField>` sections from the top.

A filled `BaseDir` switches the output to file even if `OutputType` isn't set to `file` at all.

`DepSearchOrder = 2` requires a stored sort list. If it's missing, the value silently falls back to `0`.

The shop treats three field names like standard fields despite their custom definition: `GiftProduct`, `GiftProductSubTotal`, and `Glossary`.

> [!NOTE]
>
> The shop itself doesn't read the parameters `DepVar`, `Visible`, `Type`, `Uid`, and `Order` from the examples above from `prod.cfg`. The import writes them for other components, such as the interfaces in the online service area. They have no effect on the display in the shop.

## Category data: `Category`

A separate `<Category>` section is created for each category.

Excerpt for the category `Handschuhe`:

```ini theme={"theme":{"light":"github-light","dark":"github-dark"},"languages":{"custom":["/languages/websale.json"]}}
<Category>
   DataFile        = 01-aa_247398.wp5
   Index           = 247398
   Name            = Handschuhe
   Descr           = Handschuhe für jedes Wetter
   FreeField1      = Handschuhe für jedes Wetter
   FreeField3      = Modische Handschuhe aus hochwertigen Materialien.
   LongDescr       = Der Handschuh zählt unter anderem zur wichtigen Winterausrüstung.
   ImgAdvNav       = handschuhe.jpg
   ImgOverview     = handschuhe.jpg
   ProdTemplate    = ws_product_handschuh.htm
   Template        = ws_category_handschuh.htm
   Filter          = g
   ProdCount       = 0
   ProdCountChild  = 93
   RobotFollow     = y
   RobotIndex      = y
   RobotProdFollow = y
   RobotProdIndex  = y
</Category>
```

### Identity and content

| Parameter | Meaning |
| - | - |
| `Index` | the category index. It uniquely identifies the category and is used in tags |
| `Name` | the category name |
| `DataFile` | the product data file of the category |
| `Descr` | the short category description |
| `LongDescr` | the long category description |
| `FreeField1` to `FreeField30` | custom category fields |
| `TRSearch` | the category name for search engines |
| `RealIndex` | for virtual categories, the index of the real category whose data applies |

> [!NOTE]
>
> `Descr`, `TRSearch`, and `RealIndex`, as well as the full range `FreeField1` to `FreeField30`, aren't described in the previous documentation and are added here. The example in the source documentation didn't show `Descr`, although the practical case further below refers to it. The parameter has been added to the example here.

An index that starts with `cms-` identifies a CMS category. The index `autobasket` is reserved and doesn't appear in the navigation.

### Images

| Parameter | Meaning |
| - | - |
| `ImgClosed` | Image of the closed category in the navigation |
| `ImgOpen` | Image of the opened category |
| `ImgSelected` | Image of the selected category. If it's missing, the shop uses `ImgOpen` |
| `ImgAdvNav` | Image for the advanced navigation |
| `ImgOverview` | Image for the category overview |

> [!NOTE]
>
> `ImgClosed`, `ImgOpen`, and `ImgSelected`, including the fallback rule, aren't described in the previous documentation and are added here.

Guide: Category images

### Templates

| Parameter | Meaning |
| - | - |
| `Template` | custom template for the product overview page of this category |
| `ProdTemplate` | custom template for the product detail view of this category |
| `CMSTemplate-X` | Template of a CMS category |

Both template assignments are inherited by the subcategories. The practical case further below shows why this is crucial when troubleshooting.

### Visibility

These parameters determine whether a category appears in the shop at all. None of them is described in the previous documentation; all are added here.

| Parameter | Meaning |
| - | - |
| `Hide` | `y` hides the category from the navigation. It remains accessible via its index |
| `Test` | `y` makes the category visible only in the shop's test mode |
| `UserGroupProduct` | Customer groups allowed to see the category. All other customers don't see it |
| `ValidFrom`, `ValidUntil` | Validity period as a timestamp. Outside of it, the category behaves like a test category |
| `Type` | Special form of the category. `Link`, `Catalogue`, `Event`, or `Image`. Empty means a normal category |

> [!WARNING]
>
> Hiding and test mode are inherited downward. If a parent category is set to `Hide = y` or `Test = y`, all of its subcategories are hidden as well, even if nothing is set there.
>
> So if a category is missing in the shop, always check the parent categories too.

### Filter criteria

| Parameter | Meaning |
| - | - |
| `Filter` | where the filter criteria come from. `y` from this category, `g` from the global definition; any other value turns the filters off |
| `Filter1`, `Filter2`, … | the field names of the filter criteria when `Filter = y` is set |

With `Filter = g`, the shop takes the criteria from the `GlobalCategoryFilterCfg` section of `prod.cfg`, which contains the same parameters `Filter1`, `Filter2`, and so on. All categories with `Filter = g` then filter by the same fields.

The display name and sorting of a filter criterion don't come from the category section, but from the field definition in `AttributeNames`. The shop looks up the field name first among the custom fields, then among the standard fields.

> [!NOTE]
>
> The meaning of the values `y` and `g`, the parameters `Filter1` and following, and the `GlobalCategoryFilterCfg` section aren't described in the previous documentation and are added here.

### Product counts

| Parameter | Meaning |
| - | - |
| `ProdCount` | Number of products directly in this category |
| `ProdCountChild` | Number of products in this category and all subcategories |

> [!NOTE]
>
> Whether these two values are written at all is controlled by the `CatProdCount` section of `shop.config`. If it isn't enabled, the parameters are missing from `prod.cfg`, and the corresponding tags output nothing. This relationship isn't documented and is added here.

Reference: shop.config, products, catalog, and search

### Search engines

| Parameter | Meaning |
| - | - |
| `RobotIndex` | whether search engines may index the category page |
| `RobotFollow` | whether search engines may follow the links on the category page |
| `RobotProdIndex` | whether search engines may index the product pages of this category |
| `RobotProdFollow` | whether search engines may follow the links on these product pages |

All four parameters block on `n`. Any other value, including the `y` from the example, allows search engines.

## Other sections

The shop also reads the following sections from `prod.cfg`. They aren't described in the previous documentation and are added here.

### `Cfg`

| Parameter | Meaning |
| - | - |
| `DataFileBaseDir` | Base directory of the product data files |
| `NavImgBaseDir` | Base directory of the navigation images |
| `DefaultImage` | Default image if a product has no image of its own |
| `DefaultLargeImage` | Default image in the large view |
| `DefaultThumbnail` | Default thumbnail |
| `DefaultMiniThumbnail` | Small default thumbnail |
| `DefaultInsert` | Default value for inserts |

The base directory of the templates isn't in this file. The shop sets it to a fixed `benutzer/templates/<Sprache>/`.

### `InventoryCfg`

| Parameter | Meaning |
| - | - |
| `Green-Txt` | Default text for the green traffic light |
| `Yellow-Txt` | Default text for the yellow traffic light |
| `Red-Deliverable-Txt` | Default text for red but deliverable |
| `Red-SoldOut-Txt` | Default text for red and sold out |
| `ReservationTime-Value` | Reservation time in minutes. If the value is missing or set to `0`, 120 minutes apply |

### `DownloadCfg`

| Parameter | Meaning |
| - | - |
| `Duration` | Validity period of a download |
| `Downloads` | Permitted number of downloads |

### `AutoBasket`

Contains the products that the shop automatically adds to the cart.

> [!NOTE]
>
> The shop looks for this section first in the separate file `import-data-prod.cfg`. Only if it isn't there does it fall back to `prod.cfg`. If you change autobasket entries in `prod.cfg` and nothing happens, first check whether the other file contains an `<AutoBasket>` section.

Guide: Add products to the cart automatically

## Three practical cases

The following three cases show how you can answer typical questions by looking at `prod.cfg`. For each one, open the file in the online service area under the "Configuration" service.

### Determine the category index of a hidden category

The products of the hidden category `Handschuhe` should appear on the shop start page `ws_start.htm`. Without access to the ERP system, you don't know its category index, but you absolutely need it for the output.

Search `prod.cfg` for `Handschuhe`. In the `<Category>` section found with `Name = Handschuhe`, read the `Index` parameter, `247398` in the example.

With this index, you build the output on the start page:

```html theme={"theme":{"light":"github-light","dark":"github-dark"},"languages":{"custom":["/languages/websale.json"]}}
{CAT-AdvData(247398,99)}

   {@PR-Data}
      ~PR-Name~
   {/@PR-Data}

{/CAT-AdvData(247398,99)}
```

Reference: `CAT-AdvData()` · Reference: `DC-CompareStringInList()`

> [!NOTE]
>
> You can tell whether a category is actually hidden from the `Hide` parameter in the same section. If it's set to `y`, the category doesn't appear in the navigation but remains accessible via its index. If `Hide` is missing, check the parent categories, because hiding is inherited downward.

### Investigate a missing category description

A category shows no description in the shop, even though the shop operator says one has been entered.

Search `prod.cfg` for the category, for example `Handschuhe`. In the `<Category>` section with `Name = Handschuhe`, check the parameters `Descr` and `LongDescr`.

If both parameters are missing or there's no value after the `=`, no description has actually been entered for the category. In that case, talk to the shop operator. The category data may need to be transferred again.

If the parameters are filled, the issue lies in the templates. Check whether the output tags are present on the product detail view `ws_product.htm`:

```html theme={"theme":{"light":"github-light","dark":"github-dark"},"languages":{"custom":["/languages/websale.json"]}}
{CAT-Descr}
   ~Cat-Descr~
{/CAT-Descr}

{CAT-LongDescr}
   ~Cat-LongDescr~
{/CAT-LongDescr}
```

Reference: `CAT-Descr` · Reference: `CAT-LongDescr`

### Changes to the product overview page have no effect

You have changed the product overview page `ws_category.htm`, but nothing of it is visible in a particular category. In that case, this category has probably been assigned its own template.

Search `prod.cfg` for the category and check the parameters `Template` and `ProdTemplate` in the `<Category>` section.

```ini theme={"theme":{"light":"github-light","dark":"github-dark"},"languages":{"custom":["/languages/websale.json"]}}
<Category>
   ...
   Index         = 247398
   Name          = Handschuhe
   ProdTemplate  = ws_product_handschuh.htm
   Template      = ws_category_handschuh.htm
   ...
</Category>
```

In this example, the category `Handschuhe` uses its own template both for the product detail view `ws_product.htm` and for the product overview page `ws_category.htm`. Your changes then belong in these two files.

> [!WARNING]
>
> Special templates are inherited by all subcategories. So if `Template` and `ProdTemplate` are empty in the category itself, check the parent categories as well.

## When an expected value is missing

If a parameter doesn't appear in `prod.cfg`, this sequence helps:

First, check whether the value is imported at all. `prod.cfg` reflects what the ERP system delivered. Whatever doesn't arrive there isn't here either.

Next, check whether the field is enabled for manual maintenance in the TopRank Manager. Enabled fields don't come from the ERP system but from the online service area, and survive every import.

Finally, check whether the section is written at all. `ProdCount` and `ProdCountChild`, for example, are only created if the `CatProdCount` section of `shop.config` is enabled.


## Related topics

- [Configuration types](https://dokumentation.websale.de/en/v8s/grundlagen-konfiguration/konfigurations-typen.md)
- [Images of a category](https://dokumentation.websale.de/en/v8s/kategorien/bilder-einer-kategorie.md)
- [Display a category](https://dokumentation.websale.de/en/v8s/kategorien/kategorie-anzeigen.md)
- [Description of a category](https://dokumentation.websale.de/en/v8s/kategorien/beschreibung-einer-kategorie.md)
- [Configuration: fundamentals](https://dokumentation.websale.de/en/v8s/grundlagen-konfiguration/konfiguration-grundlagen.md)


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.