- Is ongr/content-bundle a Laravel package?
- No. ongr/content-bundle is a Symfony bundle from the ONGR Elasticsearch ecosystem. It has no Laravel service provider, no publishable config, no facades, and no package discovery support. Dropping it into a Laravel application is a porting project, not an integration.
- Can I install ongr/content-bundle with Composer in a Laravel app?
- Composer may resolve the package, but the code will not run in a Laravel context. It expects Symfony's dependency injection container, ongr/elasticsearch-bundle, and the legacy elasticsearch-php client. There is no service provider to register, so nothing bootstraps automatically.
- What does ongr/content-bundle actually do?
- It manages and renders structured content such as pages and reusable blocks, and describes a document-oriented catalog model with Category, Product, and Content documents indexed into Elasticsearch. It provides content types, templates, and integration with the wider ONGR ecosystem. All of that is built around Symfony conventions, not Eloquent.
- Is ongr/content-bundle maintained or supported?
- No. The repository is archived under ongr-archive, the last release was 2015-05-19, and the project has roughly 2 stars and zero dependents. ONGR has explicitly stated that functionality from this bundle will not be supported. There is no upstream, no triage, and no security response process.
- Which Laravel and PHP versions does ongr/content-bundle support?
- None for Laravel. On the PHP side the code targets PHP 5.4 to 5.6-era language levels with ancient Symfony and PHPUnit pins. It will not autoload or run unmodified on PHP 8.1 or any currently supported runtime.
- Does ongr/content-bundle work with Elasticsearch 7 or 8?
- No. It relies on Elasticsearch 1.x/2.x semantics, most notably mapping types, which were removed in Elasticsearch 7 and are unavailable in Elasticsearch 8. The query DSL and mapping definitions would need a rewrite. If you are on a modern Elasticsearch cluster, none of the legacy mapping is salvageable as-is.
- Does ongr/content-bundle use Eloquent models or Doctrine entities?
- Neither, strictly speaking. The bundle models content as Elasticsearch documents rather than ORM entities, so there are no Eloquent models to reuse in Laravel. The document schema itself, including category and product relationships and content attachment points, is the only genuinely reusable asset.
- How do I migrate the ongr/content-bundle content model to Laravel?
- Reimplement the model rather than port the code. Extract the document schema, field definitions, and parent/child relationships, then rebuild against the current elasticsearch-php client or Laravel Scout with a custom driver. Expect roughly 2 to 4 engineer-weeks including tests and reindex tooling, and you end up with code you own and can maintain.
- What are the alternatives to ongr/content-bundle for a Laravel project?
- For a Laravel-native approach, use Laravel Scout with a custom Elasticsearch driver backed by your own index mappings. If you need a full catalog or PIM, evaluate Sylius, Pimcore, or Akeneo, noting they are Symfony or PHP applications rather than Laravel packages. A bespoke index is often the cheapest path when the catalog model is commodity rather than a differentiator.
- Should I fork ongr/content-bundle and modernize it?
- That is generally not recommended. Modernizing means replacing Symfony 2 DI with a Laravel service provider, converting annotations to attributes or array mappings, upgrading the Elasticsearch client, and rewriting the query DSL, realistically 6 to 10 weeks with wide variance. The fork becomes a permanent maintenance liability with no upstream to rebase onto. Reading the original architecture as a reference is the better use of the repository.