Blog Sections Open

Using CsvPort as a Starting Point for Catalog Imports

Catalog imports were a recurring problem in Evolution CMS projects long before modern package workflows became common. One practical answer was CsvPort , a module that provided a reusable basis for CSV-driven imports. Ty

Catalog imports were a recurring problem in Evolution CMS projects long before modern package workflows became common. One practical answer was CsvPort, a module that provided a reusable basis for CSV-driven imports.

Typical Include

require $modx->config['base_path'] . 'assets/modules/csvport/csvport_module.inc.php';

That simple line hints at the real value: import logic was moved into a dedicated module instead of being buried in one-off snippets.

Why It Was Useful

  • repeatable imports for product or directory data
  • clearer separation between source file parsing and resource creation
  • easier maintenance when import format changed

Modern Reading

Even if you no longer use CsvPort itself, the pattern still holds. Imports should live in a dedicated workflow layer: module, package command, or background job. Treating them as content operations inside templates quickly becomes unmaintainable.

Source: original community announcement.

Newer post

Why PSR Standards Matter to CMS Integrators Too

A short ecosystem note on PSR-0, PSR-1, PSR-2, and why PHP standards matter even in CMS-heavy projects.

Older post

Fixing MODX Revolution Parse Errors on Denwer

A quick orientation guide for local MODX Revolution installs on Denwer that fail with a parse error in config.inc.php.