Content Bundle Laravel Package

Getting Started

Treat ongr/content-bundle as a legacy Symfony 2.x / Elasticsearch 1.x–2.x asset, not a greenfield dependency. It was the domain layer of the ONGR e-commerce stack and it was built to be paired with ongr/elasticsearch-bundle, ongr/router-bundle, and ongr/filter-manager-bundle — all of which are equally archived.

Minimal steps:

1. Verify the toolchain before writing code. You realistically need PHP 5.6–7.x and Symfony 2.7/2.8 (or early 3.x). Installing it on PHP 8 / Symfony 5+ will fail at the dependency-resolution stage, not at runtime.
2. Read the bundle's Document/ namespace first. That is the actual public API: Category, Product, and Content Elasticsearch document classes with their properties, relations, and mapping annotations. Everything else (controllers, repositories, DI) hangs off those documents.
3. Read DependencyInjection/ and Resources/config/ to see how the ES manager, repositories, and routers are wired. Since there is no Packagist documentation to lean on, the service definitions are your spec.
4. Install the companion bundles at compatible versions (they are the reason this works at all): ongr/elasticsearch-bundle for the manager/repositories, ongr/router-bundle if you want URL→document resolution, ongr/filter-manager-bundle if you want faceted category listings.
5. First use case: index a handful of Category and Product documents into ES via the ES bundle's ongr:es:index:create / bulk-index commands, then wire the bundle's category controller (or a thin subclass) to render a category page with its products. That exercises document mapping, relations, repository lookup, and rendering in one loop — which is the entire bundle in miniature.

Expect no changelog, no upgrade path, and no support. Budget for vendoring or forking if you commit to it.

Implementation Patterns

Extend the documents, don't edit the vendor ones. The intended workflow is to create your own AppBundle\Document\Product extends Ongr\ContentBundle\Document\Product, add fields (attributes, pricing, media), and remap the index in your config.yml under the ES manager's indexes key. This is how you customize mapping without forking.

Two indexing modes, use both. For day-to-day admin edits, register a Doctrine listener / ES event subscriber that reindexes a document when the underlying entity is persisted — cheap and immediate. For bulk backfills or mapping changes, use the ES bundle's console commands over the whole set. Never assume the index is current; the bundle does not enforce consistency.

Repositories are thin ES wrappers. Category/product lookup (find, bulk findByIds, and filter-manager-driven search) goes through the ES bundle's repository layer. For anything beyond ID lookup — pagination, sorting, aggregations — push the query down into ongr/filter-manager-bundle rather than hand-rolling ES queries in your controller.

Controller subclassing over reimplementation. The bundle ships controllers that resolve a document from the request (via the router bundle) and hand it to a template. Subclass them and override the template variable assembly if you need custom rendering. This keeps routing, locale handling, and 404 behavior intact.

Relationships are ID references, not object graphs. Categories reference parent categories; products reference categories; content references placement. Hydrate deliberately: a category listing page needs a second ES call (or a filter-manager aggregation) to load its products. Don't expect lazy loading.

Integration tip — route resolution is the connective tissue. If you use ongr/router-bundle, a URL resolves to an ES document, and the bundle's controllers consume that. If you don't, you'll be manually mapping slugs to documents, which is where most of the "why doesn't this feel like a CMS" friction comes from.

Gotchas and Tips

• Dead ecosystem, not just a dead bundle. Zero dependents and a 2015 release mean there is no reference implementation to copy from. The bundle's own test fixtures are the best usage examples you'll find — read them.
• Elasticsearch version lock-in is the hard blocker. The mapping and client code target ES 1.x/2.x semantics. Modern ES (7/8) clients and mapping types are incompatible. Plan to run a pinned, containerized old ES, or accept that you're maintaining a fork.
• No migrations. Changing a document's mapping requires creating a new index and reindexing; there is no schema-diff tooling here. Wire that into your deploy pipeline from day one or you'll be manually rebuilding indexes in production.
• Silent index staleness. Listeners fire on entity persist, but bulk imports and direct DB writes bypass them. Debugging "the product exists but the page 404s" almost always means a stale ES document — inspect the index with curl/Kibana before touching PHP.
• Override services, don't fork. The bundle uses compiler passes and service IDs; you can replace repositories, controllers, and listeners via your app config. Forking the vendor copy makes future (hypothetical) patches impossible to track.
• Watch for orphaned relations. Deleting a product from the DB doesn't remove it from ES or purge its category reference. Add explicit delete listeners.
• Extension points worth knowing: document classes (extend + remap), controllers (subclass), repositories (swap service), and the ES event subscribers (add your own for custom sync logic). Those are the four seams that make daily work tolerable.
• Set expectations with stakeholders. This is a maintenance-mode dependency with a 2015 release date and a two-star archival repo. If the goal is a new build, evaluate a maintained Symfony e-commerce/CMS stack (Sylius, Pimcore) before committing to this.