Fixtures Booster Bundle Laravel Package

Getting Started

This bundle is the fixture layer of Elcodi's e-commerce stack: it seeds your database with the entity graph Elcodi expects (currencies, languages, tax zones, categories, products, variants, customers when applicable) so you can boot a working storefront instead of hand-writing dozens of Doctrine fixtures.

Minimal steps (Symfony 2.x/3.x era, matching the 2016 EOL):

1. Install — pin explicitly, since the package is archived and the read-only mirror on this repo will never receive fixes:

   composer require elcodi/fixtures-booster-bundle:^1.0 --dev
   

   Prefer the stable tag over dev-master; there is no maintainer to unbreak a master-tracking install.

2. Register in app/AppKernel.php (dev/test only):

   if (in_array($this->getEnvironment(), ['dev', 'test'])) {
       $bundles[] = new Elcodi\Bundle\FixturesBoosterBundle\ElcodiFixturesBoosterBundle();
   }
   

3. Load the fixture set:

   php app/console doctrine:fixtures:load --no-interaction
   

   On Elcodi-based apps the Doctrine fixtures bundle plus this booster is normally all you need; no extra config is required beyond the Elcodi core bundles.

Where to look first: the bundle's Resources/config/ for the service definitions that register each fixture, and its DataFixtures/ORM/ directory for the concrete classes. Because this repo is read-only, treat github.com/elcodi/elcodi as the real source of truth for issues, docs, and the matching Bundle versions — the README explicitly redirects there.

First use case: a fresh dev database with a browsable catalog. Load fixtures, then point your storefront at the seeded category/product IDs and verify a cart flow end-to-end before you write a single line of your own domain code.

Implementation Patterns

Extend, don't edit. Each booster fixture is a normal Doctrine\Common\DataFixtures\FixtureInterface. Subclass the ones you need and override the data-producing method rather than copying:

namespace Acme\AppBundle\DataFixtures\ORM;

use Elcodi\Bundle\FixturesBoosterBundle\DataFixtures\ORM\ProductFixture as BaseFixture;

class ProductFixture extends BaseFixture
{
    protected function getProductData()
    {
        return array_merge(parent::getProductData(), [
            ['name' => 'Acme T-Shirt', 'sku' => 'ACME-001', 'price' => 1999],
        ]);
    }
}

Register your override as a service with the same ID as the original to replace it via the container, or simply omit the base class from your loader and use yours.

Mind the ordering. Elcodi's entity graph is deeply dependent (Currency → Language → Tax → Category → Product → Variant). Use DependentFixtureInterface or the fixtures loader's ordering to guarantee parents exist before children. If the booster already declares dependencies, keep them intact in subclasses.

Use groups for environment separation. Tag fixtures and load subsets:

php app/console doctrine:fixtures:load --group=base          # currencies, languages, tax
php app/console doctrine:fixtures:load --group=dev --append  # catalog sample data

The --append flag matters in dev: without it, every load purges the schema and you lose any manually created test accounts.

Reference-based composition. Booster fixtures typically call $this->addReference('elcodi.category.root', $category). In your own fixtures, resolve them with $this->getReference(...) instead of re-querying the repository — it survives flushes and avoids ID drift between fixture runs.

Test harness integration. For functional tests, load only the minimal groups in setUp inside a transaction, and roll back. This is dramatically faster than a full load and keeps tests isolated:

protected function setUp()
{
    $this->fixtures = ['base'];
    $this->loadFixtures(); // wraps doctrine:fixtures:load in a transaction
}

Custom data via config. Where the booster exposes parameters (locales, currency codes), set them in parameters.yml rather than forking the fixture — it keeps upgrades (such as they are) and diffing painless.

Gotchas and Tips

• EOL and read-only. No PRs, no issue tracker here, no updates since 2016. Expect zero fixes for PHP 7.2+ deprecations or Symfony 4/5 compatibility. If you adopt it, fork it into your vendor namespace or accept that you own the code. Budget for that in any adoption decision — with 0 dependents, there is no community shimming around breakage.
• Version alignment. This bundle is tightly coupled to the Elcodi Bundle versions in the main repo. Mixing dev-master here with tagged Elcodi packages is the most common source of "class not found" and service-not-registered errors. Pin everything from the same release.
• Purge vs. append. Default doctrine:fixtures:load purges. On databases with FKs across many tables, purge can fail — try --purge-with-truncate. In dev workflows, default to --append.
• Memory and flush batching. The full Elcodi fixture set is large. If it OOMs, raise memory_limit for the CLI or override fixtures to flush in batches ($em->flush(); $em->clear();). Clearing detaches managed entities — your getReference calls still work, but object identity checks in custom fixture code won't.
• Locale/currency prerequisites. Many Elcodi entities require a locale and currency to exist before they'll persist. If you write a custom fixture and hit integrity-constraint errors, verify the base group ran first.
• Service override collisions. Because the bundle registers services with canonical IDs, overriding by ID works but is order-sensitive — your bundle must be registered after the booster in AppKernel for the override to stick. Confirm with php app/console debug:container <service.id>.
• Debugging. Run with -vvv; when a fixture fails silently, check whether the fixture is registered at all (debug:container --tag=doctrine.fixtures) before suspecting data.
• Extension points. In practice there are only two reliable ones: subclassing the fixture classes and overriding container service definitions. There is no active plugin architecture to hook into, so keep customizations in your own bundle rather than patching vendor code — that's the only path that survives a reinstall.
• Test-only installation. Keep it in require-dev. Shipping e-commerce sample data (products, categories, prices) to production is both a data-integrity and an SEO liability.