Maker Bundle Laravel Package

Getting Started

This bundle extends Symfony's MakerBundle with elasticms-specific generators, so the setup is the familiar maker workflow: install it as a dev dependency, confirm it's registered, and then discover its commands.

composer require --dev elasticms/maker-bundle

Flex will normally register it in config/bundles.php. If it doesn't, add it under a dev/test-only environment key:

EMSMakerBundle\EMSMakerBundle::class => ['dev' => true, 'test' => true],

Prerequisites you should have in place before using it:

• A working elasticms application (this bundle is meant to support an elasticms project, not to stand up a CMS on its own).
• symfony/maker-bundle installed, since the EMS makers are layered on top of it.
• A reachable Elasticsearch cluster for any command that produces or validates content-type/environment configuration.

Look first at what the bundle actually exposes rather than guessing command names:

php bin/console list make

Filter that output for the EMS-prefixed commands (naming varies by version, so trust the list over any README snippet), then read the help for the ones that match your task:

php bin/console help make:<whatever-ems-command-appears>

The first meaningful use case is bootstrapping: run the demo-site generator, let it lay down content types and baseline configuration, then open git status to see exactly what it created. That diff is the fastest way to learn the bundle's conventions — directory layout, config format, and which classes it expects you to fill in.

Implementation Patterns

Scaffold → diff → edit → commit. Treat every maker run as a code-generation PR. Run it on a clean working tree, inspect the diff, fill in the generated TODOs, and commit in a single reviewed change. This keeps a clean history and makes it obvious which files the generator owns versus which you hand-edited.

Demo site as a starting template, not a permanent fixture. The demo-site generator is most useful early in a project: generate it, run the app, exercise the sample content, then delete what you don't need. Don't let the generated demo artifacts drift into production code — copy the patterns into your real content types and remove the originals.

Generate default configs once, then customize. The "default configurations for website creators" capability is essentially a baseline. Run the generator, capture the resulting definitions as your project's starting config, then evolve them by hand. If you need a second variation later, re-run the generator into a scratch branch to compare against your customized version rather than overwriting live config.

Pair with core MakerBundle. Use EMS makers for elasticms artifacts (content types, environments, site scaffolding) and stock MakerBundle commands for Symfony plumbing (controllers, services, migrations). They share the interactive prompt UX, so the mental model is identical.

Keep it strictly dev-only. These are authoring-time tools. Nothing in your runtime request path should depend on this bundle. Verify with:

composer why elasticms/maker-bundle
composer show --direct | grep maker

If it shows up in a production dependency tree, move it to require-dev and confirm the bundle registration is gated to dev/test.

Script the interactive runs. For repeatable setups (fresh clone, CI smoke test, another developer's machine), prefer non-interactive execution where the command supports it:

php bin/console make:<command> --no-interaction

If a specific generator doesn't support non-interactive mode, capture the required inputs in a short setup script so every team member produces the same scaffold.

Gotchas and Tips

• Very low community signal. With essentially no stars or dependents, expect sparse documentation and no Stack Overflow coverage. Pin the version in composer.json and be prepared to read the bundle source directly — the command classes are the real documentation.
• Register in dev only. A common mistake is letting the bundle auto-register into all environments. Check config/bundles.php after install; a bundle that's active in prod adds boot overhead and, worse, can expose generator endpoints in the wrong place.
• Elasticsearch connection failures look like generic errors. Generators that touch content types will fail opaquely if ES is unreachable. Re-run with -vvv and check env vars (ELASTICSEARCH_* or whatever your project uses) before assuming the bundle is broken.
• Interactive prompts are easy to mis-answer. The generated config may be silently wrong (empty content type, wrong field mapping) if you accept defaults carelessly. Read each prompt; then validate by running the app rather than trusting the exit code.
• Generators may overwrite existing files. Some will refuse, some will clobber. Always start from a clean git status so a bad run is a one-command git checkout . away.
• Convention coupling. Generated configs assume elasticms' expected directory structure and service identifiers. If your project has customized paths, expect to hand-fix references after generation and consider that divergence a signal to keep generation minimal.
• Debugging extension points. Overridden stubs/templates are the first place to look when generated output doesn't match your needs. Locate the bundle's Resources/templates directory (or equivalent) and check whether your app can override them locally before forking the bundle.
• PHP/Symfony compatibility. Verify the bundle's composer.json constraints against your Symfony version before committing. On a new project this is usually fine; on an upgrade it's a frequent blocker since niche bundles lag behind.
• Don't run generators in CI builds. They belong in developer setup and one-off scaffolding, not in a pipeline that ships artifacts. A generator accidentally wired into a deploy step can rewrite config in production.