Fixtures Bundle Laravel Package

Getting Started

This is a legacy Symfony 2–era bundle that wires Doctrine data fixtures to the kernel environment, so the fastest path is to treat it as reference plumbing rather than a modern dependency. Before anything else, confirm it installs against your stack:

composer require --dev widop/fixtures-bundle

Then register it in app/AppKernel.php (Symfony 2 style — there is no Flex recipe):

$bundles = array(
    // ...
    new Widop\Bundle\FixturesBundle\WidopFixturesBundle(),
);

You also need doctrine/doctrine-bundle and doctrine/data-fixtures. The bundle's job is to let you point at different fixture sets per environment so a dev load doesn't dump demo data into test (and vice versa).

Where to look first in the repo:

1. DependencyInjection/Configuration.php — the actual config tree. This tells you the real option names (paths, groups, environment keys) faster than the README.
2. Command/ — the load command signature and whether it wraps or replaces doctrine:fixtures:load.
3. Resources/config/ — service IDs, so you know what to override.

A minimal config.yml block typically looks like:

widop_fixtures:
    # map each kernel environment to a directory of fixture classes
    environments:
        dev:  "%kernel.root_dir%/../src/Acme/AppBundle/DataFixtures/ORM/Dev"
        test: "%kernel.root_dir%/../src/Acme/AppBundle/DataFixtures/ORM/Test"

Write a normal Doctrine fixture and run the load command with the environment flag:

namespace Acme\AppBundle\DataFixtures\ORM\Dev;

use Doctrine\Common\DataFixtures\AbstractFixture;
use Doctrine\Common\DataFixtures\FixtureInterface;
use Doctrine\Common\Persistence\ObjectManager;

class LoadUserData extends AbstractFixture implements FixtureInterface
{
    public function load(ObjectManager $manager)
    {
        $user = new User();
        $user->setEmail('[email protected]');
        $manager->persist($user);
        $this->addReference('demo-user', $user); // usable by later fixtures
        $manager->flush();
    }
}

php app/console widop:fixtures:load --env=dev

First real use case: seeding a local/dev database with believable demo content while keeping a separate, minimal test set for CI — the exact problem the bundle exists to solve.

Implementation Patterns

Environment-scoped directories, mirrored structure. Keep DataFixtures/ORM/Dev and DataFixtures/ORM/Test with identical class names where possible. Shared fixtures (roles, countries, reference data) go in a Common directory that both environment configs include, so you only specialize what differs.

Order matters; be explicit. Implement OrderedFixtureInterface and return a numeric order rather than relying on filesystem load order. If you need a fixture to depend on another, use getReference():

class LoadOrderData extends AbstractFixture implements OrderedFixtureInterface
{
    public function getOrder() { return 20; }

    public function load(ObjectManager $manager)
    {
        $order = new Order();
        $order->setUser($this->getReference('demo-user'));
        $manager->persist($order);
        $manager->flush();
    }
}

Container-aware fixtures. For data that needs real services (password encoders, slug generators, mailer stubs), implement ContainerAwareInterface and pull services from the container. This keeps fixtures honest about what production code actually produces.

Faker for volume. Wrap fzaninotto/faker in a base fixture so you can generate N records cheaply; seed the generator per environment so dev data is reproducible.

CI workflow. In your test bootstrap (or a setUpBeforeClass), purge and load the test environment set once, then wrap each test in a transaction rollback. Avoid reloading fixtures per test — it's the usual cause of slow suites.

Config layering. Put the base mapping in config.yml, then override only the test key in config_test.yml. This is the cleanest way to keep environments in sync.

Idempotency for repeated loads. Decide up front whether your dev command purges (safe, destroys local edits) or appends (fast, risks duplicates). For most local workflows a purge + reload on demand is cleaner.

Gotchas and Tips

• Adoption is effectively zero (3 stars, 0 dependents). Treat every behavior as potentially unmaintained. Pin the version, and be prepared to fork or copy DependencyInjection/ into your own bundle.
• Symfony/Doctrine drift is the big one. The bundle predates autowiring, Flex, and modern doctrine/data-fixtures. On Symfony 4+ you will likely fight service definitions; on modern PHP you may hit deprecations in transitive deps. The ObjectManager namespace in older fixtures (Common\Persistence) has also moved to Persistence\ObjectManager — keep fixtures aligned with the installed Doctrine version.
• Environment is resolved from the kernel, not the shell alone. --env=dev on the console sets it, but if you invoke loading from application code, make sure the kernel booted with the intended environment before the bundle's config is read; otherwise you silently get the prod (usually empty) mapping.
• Purge vs. append and FK constraints. A purge that deletes in arbitrary order will blow up on foreign keys. Disable FK checks for the purge window or order deletions child-first. --append skips this but leaves stale rows.
• EntityManager state between fixtures. Long runs accumulate managed entities and memory. Call $manager->clear() between large fixtures and re-fetch references if needed. Watch for flush() called per-record — batch it.
• Debugging load issues. Run with -vvv to see which directory the bundle resolved; a wrong %kernel.root_dir% relative path is the most common failure and fails quietly (zero fixtures loaded, no error).
• Extension points. The cleanest way to alter behavior is to override the bundle's loader service or the command class in your app's service config, rather than editing vendor code. If you need per-group loading, decorate the command instead of reimplementing it.
• Migration path. If you're on a modern stack, native doctrine:fixtures:load --group=dev plus doctrine/data-fixtures groups gives you the same environment split with active maintenance. Alice/nelmio/alice is the better fit if your fixtures are data-heavy YAML. Consider this bundle a pattern to copy, not a long-term dependency.