Entity Hidden Type Bundle Laravel Package

Product Decisions This Supports

• Wizard / multi-step form flows where a related entity (e.g., Order, Company, Post) must persist across steps. The conventional EntityType renders a <select> of every row and re-queries the whole table on each step; a hidden entity type carries the reference as an ID instead. That is a performance and UX decision, not a feature.
• Locked relationships on edit forms — a comment always belongs to its post, a line item always belongs to its invoice. The user should never see or pick the parent. This bundle is one implementation of "the client sends back the ID it was given; the server trusts nothing."
• Parent-context creation flows — "Add a contact" launched from a Company detail page pre-binds company_id without exposing a picker.
• Build vs. buy: build. The package is a ~30–40 line custom form type plus a data transformer. Adoption cost (vendoring an unmaintained Symfony 2 bundle, auditing it, owning it forever) exceeds the cost of writing it in an afternoon. The correct decision is to treat this repo as a reference pattern, not a dependency.
• Roadmap signal, not a roadmap item. A zero-star, zero-dependent Symfony 2 bundle is a marker: if any part of our roadmap still targets Symfony 2, the real decision on the table is the framework upgrade (Symfony 2 reached end-of-life in January 2019 and receives no security patches). This package should never appear on a forward-looking roadmap.
• Reusability scope — the underlying need ("carry an entity reference through a form by ID") recurs across at least three of our form flows. That justifies building one internal EntityHiddenType with tests, rather than per-feature one-offs.

When to Consider This Package

Consider only if all of the following hold:

• The application is on a frozen Symfony 2.x codebase in maintenance-only mode (no upgrade planned within the next 12+ months), on PHP 5.x/7.0-era constraints.
• Doctrine ORM is already in use and the composer/vendor workflow already accepts third-party Symfony 2 bundles.
• The need is immediate and the alternative is genuinely blocking a release — and even then, writing the type in-house is likely faster than the audit.
• Someone accepts ongoing ownership: no maintainer, no releases, no CI, no tests, no issue triage.

Look elsewhere (or build in-house) when:

• You are on Symfony 3, 4, 5, 6, or 7. Every modern version handles this natively with HiddenType + a DataTransformer (entity → ID on submit, ID → entity on render), roughly 40 lines. There is no reason to carry a legacy bundle across a major upgrade.
• You need maintained code, security patching, a release cadence, or community support. 0 stars and 0 dependents is the absence of an adoption signal — no peer has validated it, there is no fork ecosystem to inherit, and no one to escalate to.
• The field carries authorization meaning. A hidden input is client-controlled; any "the user can't change this" assumption must be enforced server-side by re-loading the entity and checking ownership/permission. This package cannot do that for you, and if a team believes it does, that is a security incident waiting to happen.
• You want the entity rendered but not selectable — EntityType with a disabled/read-only choice, or a plain hidden field plus server-side hydration, is clearer and better supported.

Bottom line: treat this repository as documentation of a pattern. Do not add it to a dependency manifest.

How to Pitch It (Stakeholders)

For executives (one paragraph): We found a small open-source component that solves a narrow, recurring form problem: passing a database record from one screen to the next without forcing the user to re-select it from a long dropdown. It is a Symfony 2 artifact with zero adopters, last relevant years ago, and the framework version it targets no longer receives security fixes. The recommendation is not to adopt it. The capability it represents is worth roughly one engineering day to build and own internally, and doing so removes a dependency we would otherwise have to maintain indefinitely. The more important finding is organizational: this component only exists in our world if we still run Symfony 2, which should sharpen the priority of the framework upgrade conversation.

For engineering (talking points):

• The mechanism is small: a FormType whose getParent() returns HiddenType::class, a model/view transformer mapping entity ↔ identifier, and a PRE_BIND/POST_SUBMIT listener to hydrate the entity. Modern Symfony implements this with HiddenType + DataTransformer in about 40 lines.
• The real value being bought is the removal of the EntityType choice query on high-cardinality relations — worth measuring, not assuming. If the dropdown has 12 options, use EntityType and move on.
• Non-negotiable invariant: hidden fields are user input. The submitted ID must be re-validated for existence and for the current user's right to reference that entity. Build the validator as part of the same internal package so no team can ship the type without it.
• Recommendation: build one internal, tested form type, publish it to the team's shared bundle, and link this repository as prior art in the README rather than pulling it in.