Proxicms Content Bundle Laravel Package

Getting Started

This is the first tagged release (0.1.0) of a content-management add-on built for Symfony 6 + EasyAdmin 4. That framing matters before anything else: it is not a Laravel package, so there is no service provider, config publish tag, or facade to reach for.

Minimal path to a first look:

1. composer require the package into a throwaway Symfony 6 skeleton, not a Laravel app. The symfony/*: ^6.0 and easycorp/easyadmin-bundle: ^4.0 constraints in its composer.json will fight a Laravel install, and Laravel's Illuminate stack does not satisfy them.
2. Read composer.json first — it is the most informative file in a 0.1.0 release. Confirm the PHP floor (Symfony 6 implies PHP 8.1+), the EasyAdmin major, and whether Doctrine ORM is a hard or soft dependency.
3. Then read DependencyInjection/Configuration.php. In a Symfony bundle this is the real "config file" — it tells you every knob the package exposes, which is what config/packages/*.yaml in the README is documenting.
4. Skim for src/Controller/ or src/Admin/ — EasyAdmin packages usually ship ready-made AbstractCrudController subclasses or field configurators, and those are the intended entry point.

First use case to validate: register the bundle in config/bundles.php, point one EasyAdmin CRUD controller at a content entity, and confirm the index/detail/edit pages render. If that works, the rest of the package is usually field and template polish.

If your actual target is a Laravel application, treat this release as not yet usable. The realistic options are an API/sidecar deployment of a Symfony admin, or waiting for a Laravel-targeted release. Do not plan a bridge around a 0.1.0.

Implementation Patterns

CRUD-controller inheritance. The dominant pattern in EasyAdmin 4 packages is extending a shipped base controller and overriding configureFields(). Expect to subclass rather than configure declaratively, and expect the parent to already wire up the repository and permissions.

Field configurators over form types. EasyAdmin 4 moved field definition onto Field objects (Field::new('title'), TextField, CollectionField, custom FieldConfiguratorInterface implementations). If the package ships custom fields, register them through the field factory rather than hardcoding form types — that keeps configureFields() readable and overridable.

Service decoration for behaviour changes. Because there is no Laravel-style container binding with $app->bind(), the idiomatic override is decorates: in services.yaml on whichever service handles the content logic. This is the extension seam to look for when a default does not fit.

Doctrine repository as the query seam. For list views with filtering or per-role scoping, override the controller's createIndexQueryBuilder() and push the logic into a repository method. Keeping it out of the controller makes it testable without booting EasyAdmin.

Config-first, template-second. Anything visual that config cannot express should be handled by overriding the bundle's Twig templates via templates/bundles/<BundleName>/... rather than forking. This is the upgrade-safe path and is worth establishing as a team convention on day one.

Version pinning as a workflow. For a 0.1.0 dependency, use an exact version ("vendor/pkg": "0.1.0") and read the diff on every bump. A caret range on a pre-1.0 package will happily hand you breaking changes.

Gotchas and Tips

Pre-1.0 semantics. Under semver, 0.x minors are breaking by convention. 0.1.1 may rename a method you override. Pin exactly and treat upgrades as reviewable changes, not composer update background noise.

The Laravel-shaped trap. The instinct to look for config/pkg.php, a publishable migration set, or Pkg:: facade will produce nothing but wasted time. Everything here is Symfony bundle conventions: Configuration.php, services.yaml, config/bundles.php. Budget for that context switch if you are normally in Laravel.

EasyAdmin 4 is not EasyAdmin 3. Field configuration, the dashboard API, and menu builders changed materially between majors. Any blog post or Stack Overflow answer referencing EA3 field syntax will mislead you. Filter your search results by version.

No release notes to speak of. "Manage the content with the support of Symfony 6 and EasyAdmin4!" tells you the target platform and nothing about features, database schema, or BC promises. Since there is no prior assessment and no documentation surfaced in this review, verify behaviour from source, not from the description — the release text is a platform-compatibility statement, not a feature list.

Debugging the wiring. bin/console debug:config <alias> shows the resolved config tree and defaults; debug:container --tag=… confirms whether custom field configurators actually registered. Most "the package does nothing" reports are an unregistered bundle or a config key placed under the wrong root alias.

Watch the Doctrine surface. Content management means schema. Check whether the package ships entities/mappings or expects yours. If it ships migrations, reconcile them with your existing migration history before running doctrine:migrations:migrate — you do not want its tables appearing inside an unrelated migration batch.

Extension points to confirm early. Three things determine long-term maintainability on a 0.1.0 package: whether the bundle's services are public/private in a way that allows decoration, whether templates are namespaced (@BundleName/...) so they can be overridden, and whether custom fields go through the field factory. If any of those is closed off, plan to vendor the code rather than depend on it.

Treat this release as an evaluation, not an adoption. One tag, one vague line of notes, and a platform constraint that excludes Laravel is not enough to justify a production dependency in a Laravel codebase. Prototype in a Symfony 6 sandbox, confirm the CRUD loop works, and reassess when the package publishes real documentation or reaches 0.2+.