Advanced Content Bundle Laravel Package

Getting Started

First: this is a Symfony bundle, not a Laravel package. sherlockode/advanced-content-bundle ships a Bundle class, Symfony DI services, Doctrine ORM entities and a Twig extension — there is no ServiceProvider, no config publishing, no Blade integration. In a Laravel codebase the realistic paths are (a) don't use it, (b) build it as a sidecar Symfony admin app sharing the database, or (c) port the content/block entity model and reimplement rendering in Blade. Treat this assessment as "how a Laravel dev would evaluate and consume it", not "how to composer require it".

Minimal steps for the Symfony-side evaluation:

1. Read composer.json first — v0.10.0 moves to the Symfony 7.4 line, so confirm your host app's Symfony/PHP floor before anything else.
2. Register the bundle in config/bundles.php and load its config under config/packages/.
3. The bundle persists content via Doctrine entities, so run bin/console doctrine:schema:validate and generate a migration for its mapped entities before touching the admin.
4. First use case: define a content structure (block/widget types) in config, create a content item in the admin, then render it from Twig. That end-to-end loop is the fastest way to judge whether the data model suits you.

Implementation Patterns

• Content-as-entities, render-in-template. The bundle's core pattern is storing structured content (blocks/partials) in Doctrine and rendering it from Twig. If you're mirroring this in Laravel, the equivalent shape is an Eloquent model + polymorphic block table, with a Blade component or @renderBlock directive doing the dispatch the Twig extension does here.
• Config-driven block types. Extending content types is done through bundle configuration and tagged services rather than subclassing controllers. When mirroring in Laravel, keep the same split: a registry (service container bindings or a BlockTypeRegistry) so new block types don't require touching rendering code.
• Overriding templates, not forking. Use Symfony bundle template override paths (templates/bundles/<BundleName>/...) or twig.paths precedence. Do not patch vendor files — v0.10.0 contains a large internal refactor and your patches will evaporate.
• Decorate services for custom behaviour. Symfony's decorates: is the sanctioned extension point; if you need to change import/export or rendering logic, wrap the service rather than replacing it.
• Admin integration is the integration surface. Whatever admin layer you use, wire it against the bundle's form types rather than building parallel CRUD — the entity mapping is the contract you actually depend on.

Gotchas and Tips

• Doctrine ORM 3 listener changes are the highest-risk item in v0.10.0. PR #327 reworks the postLoad/prePersist/onFlush listeners for ORM 3 compatibility. ORM 3 dropped annotation-based listener registration, so if you have your own listeners or extend the bundle's, you likely need attribute-based (#[AsDoctrineListener]) or explicit doctrine.event_listener config. Verify events still fire with bin/console debug:event-dispatcher and a real flush.
• Symfony 7.4 migration (PR #326) plus Rector full-rules passes (PR #322/#323). Expect internal class signatures, return types and visibility to have shifted. Anything you subclass or type-hint from the bundle's internals can break even though the changelog frames these as tooling PRs.
• Strict types (PR #325). Files now declare strict typing — passing null or numeric strings into bundle methods that previously coerced will throw TypeError. This surfaces as a runtime error, not a deprecation, so smoke-test your content rendering after upgrade.
• Twig extension fix (PR #324). Templates or custom extensions that relied on attribute access within the bundle may render differently. Run bin/console lint:twig templates/ and diff rendered output for a couple of representative pages.
• Import path was optimised (PR #317). Behaviour should be equivalent, but if you have import fixtures or golden-file tests, re-run them — import code paths are exactly where silent ordering/dedup changes hide.
• 0.x means no BC promise. Pin the exact version ("sherlockode/advanced-content-bundle": "0.10.*") and read each changelog; the jump from 0.9.9 to 0.10.0 is a framework-major-aligned release, which historically is when this package breaks things.
• Debugging toolkit: debug:container --tag=twig.extension, doctrine:schema:validate, lint:twig, lint:container. Most "content won't render" issues trace back to a missing service tag or a stale Twig cache — clear it with cache:clear before deeper digging.