numberninecms/faker
Faker integration for NumberNine CMS: generate realistic fake data for seeding, testing, and development. Convenient helpers and Laravel-friendly configuration make it easy to populate content and models with believable sample records.
Install and confirm the provider is live. The package is a Laravel library, so the first step is composer, then verifying that Faker inside the container actually has the CMS providers attached.
composer require numberninecms/faker:0.1.6
Pin the exact version — this is a 0.x package and patch releases are allowed to break. Do not use ^0.1.
Publish and read the config before writing any seeders.
php artisan vendor:publish --provider="NumberNineCMS\Faker\FakerServiceProvider"
If the package relies on extra.laravel.providers for auto-discovery, no manual registration is needed; if it doesn't, add the provider to config/app.php. Verify with php artisan about or by checking that the config file appears in config/.
Discover the actual API rather than guessing at method names. There is essentially no documentation, and at 0.1.6 the provider method names are not stable across releases. The fastest reliable first step is reflection against the container-bound generator, because that is the instance the service provider decorated:
// php artisan tinker
$methods = get_class_methods(fake());
sort($methods);
// look for blog/page/block-shaped names, e.g. blogTitle, blogBody, pageMeta, ...
Do this once and save the output in your team notes. It is your de facto API reference until the README catches up.
First use case: a demo seeder for pages and posts. The intended workflow is a DatabaseSeeder (or a dedicated DemoContentSeeder) that creates NumberNine CMS nodes with believable content. Resolve Faker only through the helper or container so you get the decorated instance:
// database/seeders/DemoContentSeeder.php
public function run(): void
{
$faker = fake(); // NOT new \Faker\Generator(...)
foreach (range(1, 25) as $i) {
Page::create([
'title' => $faker->blogTitle(),
'body' => $faker->blogBody(),
]);
}
}
If the seeder runs clean with realistic titles and bodies, integration is confirmed and you can move on to factories and custom providers.
Seeder-level usage (the primary pattern). This package exists to populate a CMS. The natural shape is a seeder that is environment-guarded and idempotent-ish:
public function run(): void
{
if (! app()->environment(['local', 'testing'])) {
return; // never generate demo content in production
}
Schema::disableForeignKeyConstraints();
// seed parents first, then children
Schema::enableForeignKeyConstraints();
}
Wrap the whole thing in a transaction when seeding small datasets, and use truncate/delete explicitly before a re-run so you can iterate on seed data without duplicate rows.
Factory usage (the secondary pattern). For model factories used in tests, delegate content fields to the provider and keep structural fields explicit. The package gives you realistic prose; your test should still control relationships:
public function definition(): array
{
return [
'title' => fake()->blogTitle(),
'body' => fake()->blogBody(),
'status' => 'draft',
];
}
Never assert on the generated strings. Assert on structure (row exists, slug is non-empty, relationship resolves). Anything string-comparison-based will break the next time the provider's word lists change.
Deterministic fixtures via seeding. When you need reproducible demo data (screenshots, onboarding datasets, snapshot tests), seed the generator:
fake()->seed(20240210);
Because Laravel binds the generator as a singleton, fake()->seed(...) affects every subsequent call in the same process. That is fine inside a single seeder or test, but it is global state — don't seed mid-suite if other tests depend on variety, and re-seed at the start of each seeder that requires determinism.
Locale-aware generation for multilingual sites. The description advertises locale support. In practice this means either resolving a locale-specific generator (fake('fr_FR')) or configuring the package's locale before generating content. The pattern that holds up: generate each locale's content in its own loop with its own generator instance, then attach translations to the page in your application's normal translation workflow. Don't mix locales within one generator.
Custom providers for your own content types. The advertised extension point is Faker's addProvider. Add your provider in a dedicated service provider's boot, resolving the Faker instance from the container:
public function boot(): void
{
if (! app()->environment(['local', 'testing'])) {
return;
}
$faker = $this->app->make(\Faker\Generator::class);
$faker->addProvider(new \App\Support\Faker\ProductProvider($faker));
}
Because the container binding is a singleton, providers added here are available to every later fake() call. This is the cleanest place to add domain-specific formatters that the package doesn't ship.
Wrap behind an internal adapter. Given the pre-1.0 status and empty release notes, treat the package as a swappable implementation. A one-file adapter — App\Support\DemoContentGenerator with methods like title(), body(), mediaRef() — that internally calls fake()->blogTitle() etc. means a 0.2.0 rename is a one-file edit. Do this now; it is much more expensive to retrofit after twenty seeders and factories call Faker directly.
Always go through the container-bound generator. This is the single most common failure. new \Faker\Generator() produces a bare generator with no CMS providers. Use fake() or app(\Faker\Generator::class). If a formatter "doesn't exist," the first thing to check is whether you constructed a fresh generator somewhere.
unique() state leaks and grows. fake()->unique()->blogTitle() keeps a set of every value it has produced for the lifetime of the process. Seed 50,000 posts and you get either an OverflowException or runaway memory. Use unique() only on small, bounded fields (slugs, emails) and chunk large seeds.
Don't let demo media eat your disk. If the package generates media references, check whether it fetches real images or returns URLs/placeholders. Remote fetches make seeders network-dependent and fragile in CI; local copies balloon the storage directory. Prefer placeholder URLs, or write to a storage/app/demo folder you can rm -rf and gitignore.
Guard production and CI. Demo-content seeders should be environment-gated (local, testing) and should never be the default in DatabaseSeeder for a deploy pipeline. If your DatabaseSeeder calls the demo seeder unconditionally, a careless db:seed on a staging environment is a real incident.
Foreign keys and ordering. CMS seeders create taxonomy, pages, then blocks/media. Schema::disableForeignKeyConstraints() around the block is fine locally, but it will hide genuine constraint bugs in package-adjacent migrations. Prefer correct ordering; fall back to disabling only when the package itself requires it.
Locale fallback is silent. Faker's locale providers fall back to en_US when a formatter is missing in the requested locale. A "French" seed can therefore silently emit English filler. Spot-check output per locale rather than trusting the locale string.
Config keys are undocumented. Read the published config file end to end. It likely controls locale and content-type lists; unknown keys in the config do nothing, and the package may ship with no config at all, in which case vendor:publish succeeds but writes nothing. Confirm the file exists afterwards.
Debugging checklist for "formatter not found":
get_class_methods(fake()) — is the method there at all?php artisan about or log in boot().)fake() instance, or a manually constructed generator?Long-running processes (Octane, queue workers) and boot-time provider registration. If you register providers in boot(), an Octane or queue worker that boots once keeps the registration — that's fine — but a worker started before you added the provider won't pick it up. Restart workers after any change to Faker providers.
Upgrade discipline given empty release notes. Before any version bump, diff the provider classes between tags to see whether formatter names changed. At 0.1.x, treat every release as potentially breaking and check your seeders and factories against the diff. Keep the exact pin in composer.json and the lockfile committed.
Extension point worth knowing: formatter-level overrides. Because Faker lets you addProvider, you can shadow a package formatter by registering your own provider after the package's — providers are consulted in registration order. This is a cheap way to fix a locale quirk or a word list you don't like, without forking, provided you register after the package boots (i.e., in a lower-priority or later-booted provider).
How can I help you explore Laravel packages today?