Download the PHP package basilicom/pimcore-fixtures without Composer

Pimcore YML Fixtures

Export your Pimcore content to YAML files, then load it back into any environment.

Point the bundle at a folder in your Pimcore tree and it writes everything it finds — data objects, documents, assets, plus the system config they depend on — to plain YAML files. Commit those files, and any teammate or CI environment can recreate the exact same Pimcore state with a single command.

Typical use cases:

• Seed dev environments with a realistic baseline of content
• Ship a demo/staging dataset alongside your code
• Snapshot a customer's content for local debugging
• Keep system-level config (sites, roles, glossary, units, classification stores) in version control

Works with Pimcore 12 / PHP 8.3 / Symfony 7.

Installation

Register the bundle in config/bundles.php:

Optional config in config/packages/basilicom_pimcore_fixtures.yaml:

Defaults are sensible — path falls back to var/bundles/PimcoreFixtures. Empty values (null, '', []) and inherited values are skipped during generation to keep files clean.

ignored_properties matches on Property::getName() and applies wherever Pimcore properties are exported (document YAML, asset _metadata.yaml, and dataObject property holders). ignored_website_settings matches on WebsiteSetting::getName() and filters entries before they are written to pimcore/website_settings.yaml.

How it works

The bundle has two sides:

• Generate — read live Pimcore content and write YAML fixture files.
• Load — read those YAML files and recreate the content in another Pimcore instance.

Loading is idempotent: re-running won't duplicate content, it updates existing entries by fixture key.

Below is a tour of the main commands. Run any of them with --help to see all options.

What gets exported

Data objects

The main generation command. Without arguments it opens an interactive picker (filter, ↑/↓, space, enter) to choose one or more folders from your data object tree. Pass --folder=/products to skip the picker, or --all to export everything.

By default it also follows cross-domain references: if a Product points to a Category, a hero image, and a landing page, all four are pulled into the same export — including parent folders so paths resolve cleanly on load. Disable with --no-follow-refs.

Re-running merges new entries into existing fixture files. Pass --force to overwrite from scratch.

Documents

Same flags as generate. Exports pages, snippets, links, emails, and folders to {path}/documents/. Includes title, description, pretty URL, controller, template, editables, link targets, properties, and the original sibling index so loaded documents keep their Pimcore tree order. Reference following pulls in any data objects and assets the documents link to.

Not yet supported: hardlinks.

Assets

Copies asset binaries into {path}/assets/, mirroring the Pimcore asset tree. On load, files are restored to their original Pimcore paths. Same flag set as the other generators (interactive picker, --folder, --all, --levels, --force, …).

You can also drop replacement files into fixtures/assets/ manually — merge mode leaves existing binaries untouched.

Per-asset metadata that can't be expressed by the binary itself (currently own Pimcore properties) is written to {path}/assets/_metadata.yaml. The asset seeder reads this sidecar after creating the binaries and applies the properties.

System configuration

A few Pimcore-wide settings travel with your fixtures, written as single files under {path}/pimcore/:

Most are emitted automatically when you run generate. Classification stores, roles, and translations have their own dedicated commands if you want to regenerate just one:

Translation file format — each top-level key is a translation key, each value is a locale → text map:

On load, missing keys are created and existing keys updated; locales not configured in Pimcore are skipped with a warning. Pass --skip-translations to generate or load to opt out entirely.

File-based config that already lives in var/config/ — static routes, predefined properties, document types — isn't fixturized. Commit those files directly.

Loading fixtures

Loads everything in the fixtures folder back into Pimcore in the right order: units and classification config first, then assets, document shells, data objects (in two passes so circular relations work), document content, sites, glossary, website settings, and finally roles.

Useful options:

Resetting

Truncates Pimcore content tables before a fresh load. The --force flag is mandatory to avoid accidents.

Scope it with --types (objects, documents, assets), --classes, --exclude, or --drop-folder. Some shared tables (notes, edit_lock, search_backend_data, recyclebin) are always truncated.

Fixture file format

Fixtures are plain YAML keyed by class and fixture id, with @key references between entries.

Data object example:

Document example:

Classification store field values on a data object are nested by groupName → keyName → language:

Extending

You can teach the bundle about new Pimcore field types or custom load behaviour without forking it.

• Custom field type — add a transformer in src/Generation/DataTransformer/ for export, and a hydrator implementing ChainedPropertyHydratorInterface for load. Tag the hydrator service with basilicom_pimcore_fixtures.property_hydrator and a priority.
• Custom property hydrator — same tag, used as a fallback when none of the built-in hydrators match.
• Pre/post processors — extend AbstractProcessor and tag with basilicom_pimcore_fixtures.pre_processor or basilicom_pimcore_fixtures.post_processor to run code around each object save.

See AGENTS.md for architectural details.

Contributing

You don't need a local PHP or Composer install — everything runs in Docker via make.

Common tasks:

Run make lint && make test-unit before opening a PR. Architecture and conventions are documented in AGENTS.md.