Configuring catalogFill Columns from TV Sources in Evolution CMS

catalogFill becomes much easier to reason about once you treat its config as a structured field map instead of a magic import file.

A practical example of this pattern points straight at a practical configuration problem inside assets/modules/catalogFill/config/default.php: how to map imported columns to TV-backed product fields cleanly.

Example mapping

3 => array('', array(1, 'tv')),
4 => array('Brand', array(7, 'tv')),
5 => array('Model', array(4, 'tv')),
6 => array('Price', array(2, 'tv'))

Why this matters

On catalog-heavy sites, import configuration quickly becomes part of the content model. If the field map is unclear, every importer update becomes a guess, and editors stop trusting the resulting product data.

Good practice

keep the mapping readable and documented
treat TV IDs as infrastructure, not as the only human-readable source of truth
store environment-specific adjustments outside the base config when possible

In other words: for catalogFill, the configuration file is not just setup. It is part of the data pipeline, and it deserves the same care as templates or snippets.

Newer post

Filtering Ditto Output with Checkbox TV Values

How checkbox TVs interact with Ditto filters and what to watch for when the stored values do not behave like a simple one-value field.

Older post

Using DocLister with INNER JOIN Queries for Rich Catalog Data

How to think about DocLister when the listing needs data from multiple related tables instead of only resource fields and TVs.