- What is aerni/statamic-factory used for?
- It brings Laravel-style factories to Statamic so you can define reusable templates for fake content instead of hand-writing arrays of field values. Each factory describes the fields of an entry, term, or asset and fills them with Faker-generated data. That makes test fixtures and seeders much shorter and more expressive, especially on sites with large blueprints or many collections.
- How do I install aerni/statamic-factory?
- Install it with Composer, normally as a dev dependency: composer require --dev aerni/statamic-factory. The package targets Statamic applications, so your project needs a compatible Statamic and PHP version already in place. Commit the updated composer.json and lockfile so CI and other developers resolve the same version.
- How do I define a factory for a Statamic entry?
- Create a factory class and implement a definition method that returns an array of field handles mapped to Faker values, mirroring Laravel's database factories. You then call make() to build an unsaved instance or create() to persist it through Statamic. Most teams keep these classes in a dedicated tests or database/factories directory so they are easy to find.
- Can I customize the fake data, locales, or add variations?
- Yes. Factories follow Laravel conventions, so you can override individual attributes at call time and define state methods for common variations such as a draft entry or an unpublished term. Faker's locale is configurable, which matters for realistic names, addresses, and phone numbers on non-English sites. That keeps one factory reusable across many test scenarios instead of duplicating definitions.
- Does it support terms and assets, or only entries?
- The package covers the main Statamic content types: entries, terms, and assets. Term factories are handy for exercising taxonomy listings and filters, while asset factories let you test image or file fields without uploading real media. Check the README for the exact factory classes and options available in your installed version.
- Can I use these factories in seeders as well as tests?
- Yes, the same factories work in both places: inside PHPUnit or Pest tests for fixtures, and inside seeders to populate a development site with realistic demo content. Because the data comes from Faker, a seeded site looks natural rather than repetitive. Just keep the package in require-dev so it never lands in production dependencies.
- Which Laravel and Statamic versions does it support?
- Support tracks Statamic releases, so match the package version to your Statamic major and to the PHP and Laravel floors Statamic itself requires. Confirm this against the composer.json constraints and release notes before bumping, since even a patch release can adjust transitive constraints such as stillat/primitives. Teams still on Statamic 4 should verify dual compatibility rather than assuming an upgrade is harmless.
- How is this different from Laravel database factories?
- The API feels familiar, but Statamic content is not Eloquent, so these factories write through Statamic's own repositories, blueprints, and multi-site handling instead of PDO. That is exactly the point: your fake content respects fieldtypes and localization the way real content does. Use Laravel factories for your Eloquent models and this package for your Statamic entries, terms, and assets.
- Is aerni/statamic-factory safe to run in production?
- Keep it in require-dev. It exists to generate placeholder content for tests, local development, and seeding, so it adds nothing useful to a production runtime and only widens your dependency surface. Review it as part of routine dependency updates rather than shipping it to live environments.
- What are the alternatives if I do not want this dependency?
- You can build the same arrays by hand in tests or seeders using Statamic's APIs plus Faker directly, which is perfectly fine for a handful of fixtures. The factory pattern pays off once you have many collections, blueprints, or multi-site setups to cover. Committing static fixture files is another option, though they tend to drift as your blueprints evolve.