Ezloremipsumbundle Laravel Package

Getting Started

First, the framing correction. This is not a Laravel package. kaliop/ezloremipsumbundle is a Symfony bundle built for eZ Publish 5 / eZ Platform (the Ibexa predecessor), and eZ Platform is itself a Symfony application. There is no service provider, no config/loremipsum.php, and no php artisan entry point. If you are a Laravel developer, you will be working inside a Symfony/eZ codebase to use it — treat this as a one-off seeding tool you borrow, not a dependency you install into a Laravel app. Mapping the concepts helps: Symfony bundle ≈ package + service provider, bin/console ≈ artisan, bundle YAML config ≈ config/*.php, eZ content types/attributes ≈ Eloquent models/columns (but with a CMS schema layered on top).

Minimal steps in an eZ Platform project:

1. composer require --dev kaliop/ezloremipsumbundle:^1.6
2. Register the bundle in app/AppKernel.php (Symfony 2/3 era, which eZ Platform 1.x/2.x uses) or config/bundles.php for later Symfony versions — add it under the dev/test environment block so production never loads it.
3. Clear the cache (php bin/console cache:clear --env=dev) and run php bin/console list | grep -i lorem to discover the actual command name and its options — the command surface is small and the README is the authoritative reference for flags.
4. Ensure a valid eZ user/permission context exists for content creation (an admin user or a role with content/create on the target subtree), and that the target content types are already defined in your eZ schema.

Where to look first: the bundle's Command/ directory (the console command and its options), the Resources/config/ YAML (the content-type → attribute mapping), and DependencyInjection/. The config YAML is where 90% of your day-to-day work will happen.

First use case: you have a fresh dev database and need 300 published "Article" objects under a "News" folder so that listing pages, pagination, faceted search, and Solr indexing can be exercised realistically. Instead of hand-writing fixtures, you describe the Article content type's attributes once in config, point the command at a parent location, set a count and a language, and run it. That is the entire value proposition: structured, volume-scale content through the real eZ content API rather than raw SQL inserts.

Implementation Patterns

Declarative attribute mapping (the core pattern). The bundle's real interface is a config block that maps each eZ content type identifier to the attributes you want populated, and to the generator that should fill each attribute. Typical shape:

# app/config/config_dev.yml
kaliop_loremipsum:
    content_types:
        article:
            attributes:
                title:       { generator: sentence }
                short_title: { generator: words, params: { count: 5 } }
                body:        { generator: paragraphs, params: { count: 4 } }
                publish_date:{ generator: date }

Check the bundle's own README for the exact key names — they changed across versions — but the pattern is stable: content type identifier → attribute identifier → generator. Attribute identifiers must match the eZ content class attribute identifiers exactly (snake_case, as defined in the CMS admin), not the display names.

Drive it from an eZMigrationBundle migration (new, and probably your default now). As of 1.6.0 the bundle declares compatibility with kaliop/ezmigrationbundle 5.13+. Both come from the same vendor, so the intended composition is: define your content types and locations as migrations, then invoke lorem-ipsum generation as a migration step. This gives you one reproducible, version-controlled description of "what a seeded environment looks like" instead of a shell script plus a hand-run command — the closest analogue to php artisan migrate:fresh --seed you will get in this stack. If you are on an older eZMigrationBundle, stay on the pre-1.6 line or upgrade the migration bundle first; the compatibility claim is against 5.13+ only.

Seeding as a repeatable dev/CI step. If you are not using migrations, wrap the bundle command in your own thin Symfony command or shell script so the invocation (count, parent location, language, content type) is checked into the repo and identical for every developer and every CI run. This mirrors what you would do with a Laravel seeder — the bundle is the factory, your wrapper is the seeder.

Environment-gating. Register the bundle only in dev and test environments. This is the single most important integration tip: a content-mass-creation tool that is reachable in production is a foot-gun, especially given that eZ content creation fires workflow events, notifications, and search index updates.

Composing with test fixtures. In Behat/Codeception or functional-test setup, run the command before the scenario suite to guarantee a known corpus, then assert on counts and listing behaviour. Because generation happens through the eZ content API, the objects are indistinguishable from editor-created content — which is exactly what you want for realistic integration tests, and exactly what you don't want if you need deterministic values (see Gotchas).

Bulk-then-index workflow. Generate content first, then explicitly reindex (php bin/console ezplatform:reindex or the Solr bundle's equivalent). Do not interleave: indexing per-object during generation is the main performance cliff at volume.

Layered generation via your own generator class. The bundle exposes generator extension points (custom generator services). If your content types need domain-specific data — a SKU, a price band, a relation to an existing "Brand" object — write a small generator service implementing the bundle's interface and reference it from config, rather than post-processing objects with a second pass.

Gotchas and Tips

The faker conflict is fixed — update your pins accordingly. Pre-1.6, the bundle pulled fzaninotto/faker, which is abandoned and will collide with the fakerphp/faker that modern Laravel/Symfony apps depend on. 1.6.0 switches to fakerphp/faker with a minimum of 1.9.1. Two consequences: (a) the old "two faker packages in one lockfile" hazard is gone, and this is the single best reason to upgrade; (b) if your project already pins fakerphp/faker below 1.9.1, composer will now refuse to resolve — bump it. After upgrading, run composer why fzaninotto/faker and confirm it returns nothing; stale lockfiles and transitive dev deps are how the old package lingers.

Branch rename: master → main. If anything in your composer.json, CI matrix, or deployment scripts references dev-master, it breaks silently (the constraint simply stops matching). grep your repo for dev-master and switch to dev-main. Same applies to any docs or scaffolding templates you maintain internally.

Licensing is GPL-2.0, and that matters more than usual here. Linking this bundle into your application is fine for internal/dev use, but if you distribute the resulting application, GPL-2.0 obligations attach. This is a real difference from the MIT/Apache packages you are used to in Laravel land. Keep it require-dev so it is unambiguously absent from production artifacts and from anything you ship.

Still a low-adoption, single-maintainer bundle — a maintenance release is not a support contract. 1.6.0 is housekeeping: dependency bumps, CI via GitHub Actions, branch rename, and the eZMigrationBundle compatibility statement. There is no new generation feature and no visible signal of ongoing feature work. The underlying platform (eZ Publish 5 / eZ Platform) has been rebranded to Ibexa and iterated substantially; the eZ content API has moved on. Expect breakage on anything newer than the Symfony 3/4 era it was written for, keep it require-dev, pin your platform version, and budget for reading the source rather than trusting the README.

Non-determinism is baked in — but now tractable. Lorem-ipsum generators are random by design. The faker upgrade to a maintained fakerphp/faker means seed() is available and supported again, so the practical route to reproducible fixtures is a custom generator service that calls $faker->seed(<fixed>) (or returns stable values from a fixed dataset) and referencing it from config. Do not build assertions on generated titles from the stock generators.

Contributor-only detail: PHPUnit 5.x/8.x. The test suite now runs on PHPUnit 5 or 8 depending on the PHP version matrix. This only matters if you are running the bundle's own tests (e.g. patching it, or vendoring a fork); 8.x implies PHP 7.2+. It does not change your application's test tooling. GitHub Actions now runs the suite, so if you fork, check CI before assuming a local green run means anything.

Attribute coverage is not automatic. Attributes you omit from config are left empty. Attributes you misspell silently produce nothing — there is typically no schema validation against the content class, so the failure mode is "content created, field blank." Cross-check identifiers against php bin/console ezplatform:content-type:debug (or the admin UI) before debugging anything else.

Binary/image attributes need real files. Generators produce text; they do not synthesize images. Image and media attributes will be empty unless you supply a source path or write a custom generator that inserts an existing binary. Do not expect placeholder images.

Permissions and ownership. Content is created as whoever the command authenticates as. If the target parent location is in a subtree where that user lacks create, you get a partial or wholly empty run. Likewise, generated objects are owned by that user — mass-transfers/deletes later need the same privilege level.

No transactional rollback. Each object is a separate API write. A run that fails halfway leaves partial content behind. For repeatability, scope runs to a dedicated, throwaway parent location that you can delete wholesale (php bin/console ezplatform:content:delete style, or via a small custom command) between runs.

Volume is O(n) against the content API — it is slow. Hundreds is fine; tens of thousands is not. Each create triggers events, version bookkeeping, and possibly search indexing. Batch in the low hundreds per invocation and let the indexer catch up; also be aware Solr is typically near-real-time, not real-time, so freshly generated content may not appear in search assertions immediately.

Debugging playbook: confirm the bundle is loaded (php bin/console debug:container | grep -i lorem), confirm the command exists (php bin/console list), run with -vvv, and check the eZ logs (var/logs/dev.log) — failures surface as content API exceptions rather than friendly messages. If content is created but fields are blank, the problem is config mapping, not the bundle. If composer resolution fails after upgrading, check the fakerphp/faker 1.9.1 floor and any lingering dev-master constraints first.

Best extension point: a custom generator service. It lets you keep domain logic — including RNG seeding — in your app (versioned, testable, PSR-4 autoloaded) while the bundle stays a disposable dependency — the same instinct that keeps Laravel apps from forking vendor packages.