Hidden Entity Bundle Laravel Package

Getting Started

Read this first: the package is a Symfony 2 bundle, not a Laravel package. It ships an AbstractType that renders an entity reference as a hidden input, plus a Doctrine DataTransformer that resolves the submitted scalar back into a managed entity. It is hard-coupled to symfony/form (pre-3.0 API — setDefaultOptions, not configureOptions) and Doctrine ORM. There is no Laravel form factory, no data-transformer pipeline, and no container hook for it to plug into. Composer resolution will fail against PHP 8.1+ / modern Laravel constraints, and even on Symfony it fatals at container boot because the Form API it targets was removed years ago.

So "getting started" splits into two realistic paths.

Path A — you actually inherited a Symfony 2.x app. Then:

composer require gibilogic/hidden-entity-bundle

Register it manually in app/AppKernel.php (no Flex auto-discovery in Symfony 2):

new Gibilogic\Bundle\HiddenEntityBundle\GibilogicHiddenEntityBundle(),

Clear the cache (php app/console cache:clear) — form-type registration compiles into the container and a stale cache is the #1 reason the type "doesn't exist." Then open Form/Type/ and read the DataTransformer first; that class is the contract. Everything else is a thin HiddenType wrapper.

Path B — you're a Laravel developer, which the brief assumes. The honest answer is you don't install anything. You extract the pattern in under a day: a hidden Blade input carrying the ID, a Rule::exists() or custom rule for resolution, an authorization gate for ownership, and findOrFail in the controller. That's 50–100 lines, it gives you the security controls this bundle lacks, and it removes a zero-star, zero-dependent, EOL-framework dependency from your composer.json. Treat the repo as a design reference only.

Implementation Patterns

Route-derived value vs. round-tripped value — pick deliberately. The bundle makes an entity convenient to carry through a form, not trustworthy. In Symfony you'd write either:

// A) Trust the hidden field — only safe when the user is permitted to reference any entity
->add('post', HiddenEntityType::class, ['class' => 'AppBundle:Post'])

// B) Ignore the submitted ID and resolve from the route in the controller
$post = $this->getDoctrine()->getRepository('AppBundle:Post')->findOrFail($request->get('post_id'));

Pattern B is almost always what you actually want.

The Laravel equivalent of Pattern B — route binding + FormRequest + Policy:

// routes: Route::post('/posts/{post}/comments', ...)
// controller
public function store(StoreCommentRequest $request, Post $post)
{
    $this->authorize('comment', $post);
    $post->comments()->create($request->validated());
}

Route model binding gives you the entity for free, 404s cleanly on missing IDs, and keeps the ID out of the request body entirely.

The Laravel equivalent of Pattern A — when the user genuinely picks the entity and you must round-trip it:

class StoreWidgetRequest extends FormRequest
{
    public function rules(): array
    {
        return [
            'post_id' => [
                'required', 'integer',
                Rule::exists('posts', 'id')->where('tenant_id', $this->user()->tenant_id),
            ],
        ];
    }
}
// then: $post = Post::findOrFail($this->validated('post_id')); $this->authorize('view', $post);

Bake tenant/ownership scoping into the rule, not into an optional follow-up check.

Multi-step wizard / edit-form pattern. This is the legitimate use case the bundle was built for — carrying an ID across steps without exposing a full selector. In Laravel, prefer server-side session carry-over or signed IDs (URL::signedRoute) over a bare hidden field when the value influences ownership, pricing, or authorization state. Keep that logic first-party.

Integration tip: enforce authorization on submit, not just on render. Rendering a hidden input proves nothing about what comes back.

Gotchas and Tips

• Hidden ≠ trusted. The dominant risk is IDOR: the ID is fully user-controlled, so a request edited in devtools can reference another tenant's record. The package name invites the opposite assumption. Every hidden-ID field needs an exists check and an ownership/tenant/role check on submit.
• API drift is a hard failure, not a soft one. The bundle targets setDefaultOptions; the replacement configureOptions landed in Symfony 2.7/3.0. Attempting to install it on anything current fails at container boot — loud, but it means there's no incremental migration path, only reimplementation.
• Stale or deleted IDs surface as 500s. The transformer will blow up on a missing entity. Wrap resolution in findOrFail/firstOrFail (Laravel) or an explicit null check (Symfony) so you return 404/422 rather than a stack trace. Test soft-deleted IDs specifically — exists: rules catch them, find() may not behave as you expect.
• Mass-assignment footgun. Resolving an entity and then passing it into fill()/update() can write columns the form never intended to expose. Use validated()/only(), never request()->all().
• Silent fallback to "create new". A null-resolution path that defaults to creating a record produces orphans and duplicates. Make null resolution an explicit error.
• Stale container cache in Symfony 2 is the most common "the form type doesn't exist" cause. Always cache:clear after registering a bundle or editing a form type.
• No maintenance signal. Zero stars, zero dependents, single maintainer, no release cadence. There are no security advisories to subscribe to and no community to escalate to. If you must keep it on a legacy Symfony 2 app you can't migrate this quarter, pin or vendor it, assign an internal owner, and log it as tech debt with a removal date.
• Extension point if you're stuck on Symfony 2: don't patch the vendor. Subclass or wrap the type in a first-party HiddenEntityAuthorizedType that layers a voter check into the transformer, so the authorization precondition is enforced by the type itself rather than by convention across every form that copies the pattern.
• Team convention worth adopting regardless of stack: add a review checklist item for any hidden-ID field — "where is existence validated, and where is access authorized?" A convention adopted without a mandatory authorization check propagates an IDOR pattern, and the blast radius grows with every tenant and entity added.