Ezenhancedimageassetbundle Laravel Package

Product Decisions This Supports

• Editorial image quality (focus point). The enhancedimage field extends ezimage and lets editors set a focus point per image; variations are then cropped around the subject. This is a product decision about who owns cropping — editors instead of template hard-coding — and it directly reduces "the hero image is cutting off her head" tickets across breakpoints and content types.
• Performance budget / Core Web Vitals. Global (siteaccess-aware) defaults for image_default_post_processors (pngquant, jpegoptim, progressive JPEG) and image_default_config let you set quality/compression policy at platform level rather than per template. Lazy loading is a global default (enable_lazy_load) overridable per field. This turns "we should improve LCP" into a config change with a measurable before/after, not a frontend refactor.
• Build vs buy for the image pipeline. Focus-point UI + retina variants + WebP alternates + lazy loading + placeholder providers is realistically 4–8 engineer-weeks of design, build, and QA. MIT-licensed, zero license cost, one bundle registration plus two Encore entries. The buy case is strong if you accept maintenance ownership.
• Art direction and responsive strategy. alternativeAlias with media queries lets you declare mobile vs desktop assets in Twig parameters instead of bespoke conditional templates. That's a decision about how much art direction you support, made declaratively.
• Retina/WebP rollout policy. enable_retina and automatic _retina suffix resolution plus auto-generated WebP alternates are single toggles — you can ship WebP/retina as a phased rollout and A/B the impact on bytes and LCP, rather than committing to it wholesale.
• Migration sequencing and roadmap. Because enhancedimage subclasses ezimage, migration is a data_type_string column update, with a bundled ezenhancedimageasset:convert:field_to_imageasset command for image/relation → image asset conversion. This supports a per-content-type, incremental adoption decision instead of a re-platform or a DAM integration project — a big de-risking point for roadmap planning.
• Preview/placeholder behavior in non-production environments. The remote placeholder provider and chaining config mean editors and QA see meaningful imagery in staging without copying production binaries.
• Use cases it unlocks: multi-brand or multi-region Ibexa estates (siteaccess-aware config), media-heavy landing pages, editorial sites where photography subject position varies, and pre-DAM interim states.

When to Consider This Package

Consider it when:

• You are on Ibexa 4/5 with PHP 8.3, self-hosted, and image bytes, cropping quality, or LCP are already on the roadmap.
• Your editors upload heterogeneous photography (off-center subjects, portrait/landscape mixes) and you cannot enforce a crop rule in templates.
• You want WebP/retina/lazy-loading without a frontend rebuild and without buying a commercial image CDN.
• Your team is small enough that maintaining your own image field type is a distraction, and you're willing to fork, pin, and own the code.
• You can accept a field-type change per content type and can run the SQL migration against a verified staging dump with a rollback plan.
• You need an interim image story while a DAM decision is pending — the conversion command gives you a path to image assets later.

Look elsewhere when:

• You are not on Ibexa. This is entirely platform-coupled; there is no value outside the eZ/Ibexa field-type system.
• You need real DAM capabilities — renditions at scale, rights management, AI tagging, on-the-fly transforms, global CDN edge caching. Use an image CDN (Cloudinary, Imgix, Cloudflare Images, Fastly IO) and keep Ibexa as the source of record. This bundle does local post-processing on local storage.
• Your vendor-risk policy requires an SLA, security responsiveness, or a support contract. Signals are thin: 1 star, 0 dependents, a single-agency maintainer, README + releases as the only maturity markers, no visible test suite or CI, and a "subtree split" repo whose issues and contributions must go upstream to Novactive/Nova-eZPlatform-Bundles. Bus factor is effectively one organization.
• You cannot tolerate upgrade lag. The release history tracks Ibexa majors (v2 → Ibexa 3, v3 → Ibexa 4, v4 → Ibexa 5), which is reassuring, but each platform major means waiting for a bundle release before you can upgrade. If your upgrade cadence is aggressive, either budget to carry the patch yourself or don't adopt.
• You can't perform a direct data_type_string DB mutation in a maintenance window. The documented migration is raw SQL against ezcontentclass_attribute and ezcontentobject_attribute — effective and irreversible-ish. If that's not operationally acceptable, don't start.
• You need guaranteed multi-variation image-asset relations and rich asset workflows today; validate the convert:field_to_imageasset command against your data model before committing.

Adoption posture I'd recommend: treat this as "adopt with a fork" — pin a version, fork into your VCS, run your own regression on alias generation, and assign a named owner for upgrades. Do a spike on one content type first.

How to Pitch It (Stakeholders)

Executive summary (30 seconds). We have a well-understood gap in how our CMS handles images: editors can't control what gets cropped, and we serve oversized, uncompressed, non-WebP files. This is a free, MIT-licensed bundle from an established Ibexa agency that closes that gap — focus-point cropping, WebP and retina variants, lazy loading, and compression defaults — without a re-platform and without a paid CDN or DAM contract. The cost is one integration sprint plus validation, against roughly 4–8 engineer-weeks to build it ourselves.

To engineering. It's a field-type extension: enhancedimage extends ezimage, so the data-model change is one column value per field, with documented SQL for both the class attribute and existing content. Rendering is via ibexa_render_field with alias / alternativeAlias / lazyLoad / retina parameters; configuration is siteaccess-aware YAML; integration is a bundle registration plus two Encore entries (enhancedimage-css, enhancedimage-js). What we own: the fork, the alias-generation regression suite, the migration rehearsal on a production-shaped dump, and the upgrade path across Ibexa majors.

To finance/procurement. No license fee, no per-transformation or per-GB metering that a CDN contract would introduce. Budget instead for internal ownership — roughly a few days per quarter for upgrades and triage — and note the concentration risk: one maintainer organization, minimal community adoption. That risk is mitigated by the MIT license and the fork strategy, not by a contract.

Success metrics to commit to up front. Editorial "wrong crop" tickets trending down; average image bytes and LCP on top landing pages improving after the WebP/lazy rollout; reduction in ad-hoc Twig image helpers and one-off alias definitions; and a clean, rehearsed migration with zero content-type rollbacks.