Ezenhancedimageassetbundle Laravel Package

Technical Evaluation

Architecture fit. The package is mislabeled in our intake as a "Laravel/PHP package." It is a Symfony bundle for Ibexa DXP (formerly eZ Platform), registered in the kernel bundle array and coupled to Ibexa internals: the field type registry (enhancedimage extends ezimage), the image variation handler and filter pipeline, siteaccess-aware parameters, and the platform's Encore/Webpack asset entries under the ibexa namespace. On a Laravel codebase the fit is zero — there is no service provider, no publishable config, and the data model lives in ezcontentclass_attribute / ezcontentobject_attribute. Value exists only where the estate already runs Ibexa 5 on PHP 8.3.

Integration feasibility. Moderate for an Ibexa estate. Composer install plus bundle registration is trivial (hours). The real effort is configuration and data change: rewriting image variation config to use the focusedThumbnail filter, wiring the enhancedimage-css / enhancedimage-js Encore entries into the admin theme, provisioning post-processor binaries (pngquant, jpegoptim, cwebp) on every image node, and migrating data_type_string from ezimage to enhancedimage via raw SQL. Because the new type extends the old one, underlying storage stays byte-compatible and the change is reversible.

Technical risk.

• Read-only subtree split. This repo is a mirror of one directory of Novactive/Nova-eZPlatform-Bundles; issues and PRs must go upstream. Any fix we need depends on the vendor monorepo's cadence, and we cannot ship a patch here.
• Near-zero adoption. 1 star, 0 dependents. We would be effectively an early adopter and de facto co-maintainer; there is no community signal that these code paths are exercised outside the vendor's own projects.
• Opaque release history. Release notes are stubs (changelog links only). The new v3.0.7 follows the same pattern — its entire body is a compare/v3.0.6...v3.0.7 link, with no summary of what changed. We cannot assess the risk delta between any two releases from the notes alone, and we still cannot diff v3.0.5 → v4.0.0 from documentation.
• Branch topology now partially clarified, still unverified. v3.0.7 was published after v4.0.0, which confirms the vendor is running parallel maintenance lines rather than having cut over to 4.x. That is mildly reassuring for the project's health, but it raises a new question for us: whether fixes land on the 4.x line first and are back-ported to 3.x, or the reverse. If substantive work is happening on the 3.x (Ibexa 4) line, our 4.x pin may be the less-exercised branch. We still need the actual tag diff before pinning.
• Raw SQL schema migration. The documented migration is two UPDATE statements against Ibexa core tables, with no idempotency, no transaction wrapper, and no rollback script. This is the highest-consequence step in the whole integration.
• Historical correctness bugs. Prior releases fixed "focuspoint not applied when having retina variation" (v1.1.1) and "saving focuspoint without modifying the image" (v1.6.2), and a placeholder-generation failure with no post-processors (v1.0.1). Interaction between focus, retina, and WebP is the area to test hardest. A 3.x-only patch release does not exercise the 4.x code paths we would depend on, so it is not evidence that our pin is stable.
• Alias fan-out. Each alias can spawn a _retina variant and a WebP variant — up to 4× storage and cache entries per image per alias, and focus-point crops defeat cross-image alias reuse.

Key questions.

1. Does the target application run Ibexa 5 on PHP 8.3, or is this a mismatch with a Laravel roadmap (in which case reject and evaluate Intervention Image/Glide with a custom focus-point crop)?
2. What is the vendor relationship with Novactive — is there any commercial support or escalation path, or are we relying on public GitHub issues?
3. Which tag do we pin, and can we obtain the real diff between it and the previous release — including whether the v3.0.6...v3.0.7 changes have equivalents on the 4.x line, and which line is the vendor's primary development branch?
4. Are pngquant/jpegoptim/cwebp guaranteed present on every app and image worker, and are they invoked synchronously on upload?
5. Does our theme own build control of the ibexa Encore entries, or will we need to add them?
6. What is the acceptable variation fan-out and CDN offload assumption for the asset library size?

Integration Approach

Stack fit. Symfony 6/7 as packaged by Ibexa 5; PHP 8.3. Not usable in Laravel. If any part of the portfolio is Laravel, scope this evaluation strictly to the Ibexa DXP footprint and treat the Laravel mention as an intake error to correct.

Migration path. Staged and reversible:

1. Sandbox spike — install bundle, register in kernel, add Encore entries, apply the focus-point field to a scratch content type. Confirm the admin UI actually renders the focus selector (this fails silently without the assets).
2. Variation config — author focusedThumbnail aliases plus paired _retina aliases, and confirm WebP generation against one test image set.
3. Pilot content type in staging — run the two UPDATE statements inside an explicit transaction, capture affected row counts, verify front-end rendering and that pre-existing aliases still resolve.
4. Alias regeneration — backfill variations with existing Ibexa tooling, watching disk and cache growth; throttle.
5. Per-type production rollout — one content type at a time, each with a documented reverse UPDATE ready to execute.

Compatibility. Pin v4.x for Ibexa 5, v3.x for Ibexa 4, v2.x for Ibexa 3 — the major version tracks the platform major, so platform upgrades force a bundle upgrade. v3.0.7 is the current tip of the Ibexa 4 line and does not change our pin; it is only useful as a signal that the project is still actively released. Storage-level downgrade is feasible by reverting data_type_string; template-level downgrade is not, since alternativeAlias / lazyLoad / retina parameters are bundle-specific.

Sequencing. Bundle install → asset entries → variation config → pilot type migration → QA matrix across focus × retina × WebP × lazy-load → production rollout per content type → theme templates updated to pass alternativeAlias, lazyLoad, and retina parameters last, so front-end changes land only after the data is correct.

Operational Impact

Maintenance. Effectively self-supported. Budget for a fork of either the split repo or the parent monorepo so we can carry local patches, and maintain a person responsible for diffing upstream tags before each upgrade — the empty changelogs make blind upgrades unacceptable, and the v3.0.7 stub is the third consecutive release to arrive without usable notes. Note that the vendor is actively releasing (including on the older 3.x line), so the upgrade treadmill is live and will require attention rather than benign neglect. Also budget for re-running the data_type_string updates if a platform upgrade re-installs or re-imports content class definitions.

Support. MIT licensed, community only. The vendor is the de facto maintainer via the parent monorepo; there is no stated SLA. Escalation is a public GitHub issue, which for a 1-star package means we should assume we drive most fixes ourselves. Active release cadence shows the maintainer is engaged but does not translate into support obligations.

Scaling. The dominant cost is variation fan-out: base alias plus retina plus WebP per image, times the number of aliases, with focus-point crops preventing alias reuse across images. Storage grows roughly linearly with the asset library and must be planned, not discovered. Post-processing is CPU-heavy on the upload path — put it on async workers, not web nodes. CDN offload moves from "nice to have" to "required" at any meaningful traffic level.

Failure modes.

• Missing post-processor binaries → variation generation errors or silently degraded output; historically has also broken placeholder generation.
• Missing Encore entries → focus-point UI non-functional in admin with no server-side error; editors produce un-focused images without knowing.
• data_type_string drift after a platform upgrade or content-class re-import → focus points orphaned, images fall back to plain ezimage behavior.
• enable_retina on while a paired _retina alias is absent → broken or oversized image references in the field template.
• Incomplete WebP config → no <source> fallback, degraded rendering on unsupported clients.
• Alias explosion → disk exhaustion or cache eviction storms on the image tier.

Ramp-up. Low for a developer already fluent in Ibexa field types and variation config — one to two days for the sandbox spike and config. Moderate for the editorial team: selecting a focus point is a new step in the image workflow and needs an explicit content-modeling guideline, otherwise contributors leave defaults and the feature delivers nothing. Non-trivial for ops: binary provisioning, alias regeneration jobs, disk and cache monitoring, and a runbook for the SQL migration and its reverse.