Ezpublish Legacy Installer Laravel Package

Technical Evaluation

What this package is. ezsystems/ezpublish-legacy-installer is a Composer plugin (type: composer-plugin) that registers a custom installer so that packages of type: ezpublish-legacy-extension land in the legacy eZ Publish extension directory rather than vendor/. It is not a Laravel package: there is no service provider, config publish, facade, or framework coupling. Any Laravel relevance is incidental — it exists to keep a Composer build working for teams whose stack still includes eZ Publish Legacy (4.x/5.x).

Architecture fit.

• Direct fit for Laravel applications: effectively none. Do not add this to a Laravel service unless the same repository/composer root also builds a legacy eZ Publish tree.
• Indirect fit: plausible in a strangler/coexistence pattern where a Laravel app is being built alongside, or replacing, a legacy eZ Publish site, and both share Composer tooling, CI, or a monorepo. Even then, the correct pattern is a separate Composer root for the legacy tree; sharing one composer.json across both is not advisable.
• Boundary fit is clean when isolated: the plugin only affects install paths for one package type, so it will not perturb Laravel's autoloading or vendor layout — provided it is not installed into the Laravel root.

Integration feasibility. High, and materially improved by this release. Composer 2 support was the single blocking constraint for any team that had modernized its Composer toolchain; without it, the legacy tree pinned the whole build to Composer 1. Two caveats to confirm on the diff:

1. Plugin API declaration. The plugin must declare composer-plugin-api ^2.0 (or ^1.1 || ^2.0) in extra. If the constraint was replaced rather than widened, v2.1.0 is effectively a Composer-1 drop, and mixed estates must pin v2.0.x for Composer 1 roots. A minor version bump doing this is a real (if intentional) break for some consumers.
2. allow-plugins. Composer 2.2+ blocks plugins unless allowlisted. Any project upgrading will also need config.allow-plugins entries, or installs will be skipped with a warning. This is an operational step, not a package defect, but it is the most common way this upgrade will appear to "fail."

Technical risk. Low in code surface (the plugin is small and event-driven), high in ecosystem context:

• eZ Publish Legacy is end-of-life; upstream maintenance, security patching, and PHP 8.x compatibility of the host application are the dominant risks, not this plugin.
• Composer 2's plugin API changed method signatures/event semantics versus 1.x; community plugins that were "silently working" on 1.x sometimes needed adjustments. v2.1.0 addresses this for this plugin, but sibling legacy plugins in the same root (installers, scripts, patches) may still be Composer-1-only and will surface as a second, later blocker.
• No security surface: the plugin resolves paths and copies files; it is not network- or request-facing.

Key questions.

1. Does v2.1.0 widen the composer-plugin-api constraint or replace it? Determines whether Composer 1 roots must pin.
2. Are all other plugins and Composer scripts in the legacy root Composer-2-ready? This release removes one blocker, not necessarily the last.
3. PHP version matrix actually exercised in CI for this release?
4. Is this the last planned release, and who owns the fork/patch path if a Composer 3 or PHP 8.4 incompatibility appears?
5. Are install paths (extension directory) unchanged between Composer 1 and 2 — i.e., does an in-place composer update risk orphaning previously installed extensions?

Integration Approach

Stack fit. PHP 7.x is the realistic floor for a Composer 2 toolchain; the host eZ Publish Legacy application is the binding constraint, not this plugin. Treat the legacy tree as a bounded context: its own composer.json, its own lockfile, its own CI job. Laravel and legacy roots should not share a lockfile.

Migration path (per legacy root).

1. Inventory: list all composer-plugin packages and all Composer scripts/patchers in the legacy root; confirm which declare Composer 2 support.
2. Bump Composer binary to 2.x in the build image only (not yet on developer machines' paths for other repos).
3. Add config.allow-plugins entries for every required plugin, including ezsystems/ezpublish-legacy-installer.
4. Require ezsystems/ezpublish-legacy-installer:^2.1; run composer update in a scratch clone with a warm cache.
5. Verify install paths for a sample of ezpublish-legacy-extension packages; diff the resulting extension/ tree against the Composer 1 baseline.

Compatibility. Confirm the composer-plugin-api constraint (see question 1). Check composer/installers coexistence if both are present, since overlapping installer priorities are the usual cause of extensions landing in vendor/ instead of extension/. Plugin event ordering changed subtly in Composer 2 — the post-autoload-dump/install lifecycle is fine, but anything hooking pre-package-install should be smoke-tested.

Sequencing. Inventory → allowlist config → toolchain bump in CI → package bump → path verification → developer machine rollout → remove Composer 1 from the legacy build path. Do not combine the Composer binary bump with unrelated dependency updates in the same change; the failure signature (plugins silently skipped) is otherwise hard to attribute. Keep v2.0.x pinned in any root that must stay on Composer 1.

Operational Impact

Maintenance. Low ongoing effort for the plugin itself; effectively zero if the legacy tree is in maintenance-only mode. The real cost is the EOL host application: unscheduled work when a PHP runtime, base image, or CI runner drops support. Budget for a maintained fork rather than upstream responsiveness.

Support. Upstream is community-maintained around an EOL product; expect slow review on future PRs and no security guarantee. Internal ownership should be explicit — one named maintainer with commit rights to a vendored patch, or an accepted-risk note in the register.

Scaling. Negligible. This is a build-time installer; it does not touch request-path performance. The only scale dimension is CI: Composer 2 is materially faster and more memory-efficient than 1.x, so this upgrade is a small net win for large legacy dependency graphs.

Failure modes.

• Silent skip: plugin not in allow-plugins → extensions not installed, build appears to succeed, deploy fails at runtime. Add a post-install assertion that the expected extension directories exist.
• Misplaced extensions: installer priority conflict → files in vendor/ rather than extension/; application boots with missing modules.
• Composer 1 regression: if the plugin API constraint was replaced, a Composer 1 root pulling latest will fail resolution; pin explicitly.
• Partial upgrade: Composer 2 on the binary but a Composer-1-only sibling plugin → resolution error that reads as a package problem rather than a toolchain gap.
• Orphaned files: in-place composer update across the major toolchain may leave stale extension directories; prefer clean installs in CI.

Ramp-up. Low for anyone familiar with Composer plugins; the concepts (installer paths, plugin allowlisting) are standard. The learning curve is domain-specific, not technical: engineers need to understand that eZ Publish Legacy has a non-PSR-4, non-vendor/ layout and that this plugin is the adapter. That knowledge is scarce and mostly tribal — document the Composer root layout and the allowlist rationale before the person who set it up moves on.

Recommendation. Adopt v2.1.0 for the legacy root only. It removes the last common blocker to a Composer 2 toolchain and is worth taking, but scope it as an isolated maintenance change with path verification, not as a modernization milestone. Confirm the plugin-API constraint before rollout, and keep a v2.0.x pin documented for any Composer 1 consumer.