Ezpublish Legacy Laravel Package

Technical Evaluation

Architecture fit: Poor for a modern Laravel application. ezsystems/ezpublish-legacy is not a Laravel package or a lightweight Composer library; it is the legacy eZ Publish CMS kernel plus core extensions, with its own MVC stack, templating layer, extension model, database schema, bootstrap, and global runtime assumptions. It should be treated as a separate legacy application, not as an in-process Laravel dependency. A TPM should frame it as a maintenance/migration asset for existing eZ Publish estates, not a component to adopt in greenfield Laravel work.

Integration feasibility: Feasible only through isolation patterns: separate vhost/container, reverse proxy, HTTP/content APIs, read-only database views, or ETL into Laravel. Direct Composer inclusion into a Laravel app is likely to create bootstrap, autoloading, dependency, error-handler, session, and superglobal conflicts. If integration is unavoidable, the safest initial pattern is Laravel as the presentation/back-office layer and legacy eZ Publish as a content source behind a boundary.

Technical risk: High. The package is archived, last released in 2020, and explicitly succeeded by eZ Platform with no further feature releases planned. That implies no upstream security or compatibility roadmap. The NOASSERTION license status requires legal review before any redistribution or embedding. Runtime compatibility is likely constrained to older PHP/MySQL stacks and may conflict with current Laravel versions and PHP 8.x expectations.

Key questions: Are we maintaining an existing eZ Publish site or considering it for new Laravel functionality? What content/API surface must Laravel consume? Which PHP/runtime and database versions are in production? Is the license acceptable for the intended use? Who owns security patching after archive? What is the migration budget and deadline? Is there a hard requirement to preserve legacy templates/workflows, or can content be migrated to a modern CMS/headless service?

Integration Approach

Stack fit: Weak for a Laravel-native stack. Use Laravel for new product surfaces and isolate eZ Publish as a legacy content service. Do not make the eZ kernel a first-class Laravel dependency. Prefer HTTP contracts, content export jobs, or read-only data replication over shared runtime state. Authentication should be bridged at the edge via OIDC/SAML or reverse proxy rather than by sharing sessions.

Migration path: Start with an inventory of extensions, content types, templates, workflows, users, URLs, and integrations. Freeze nonessential feature work on legacy. Build a content model mapping and migration rehearsal into Laravel or a modern headless CMS. Use a strangler pattern: route low-risk sections through the new stack first, keep legacy for unresolved workflows, then retire modules in waves. Preserve redirects and SEO behavior from day one.

Compatibility: Validate PHP version, database version, required PHP extensions, Composer constraints, and hosting assumptions before promising integration. Expect the legacy runtime to need a containerized older PHP image rather than the same runtime as Laravel. Treat license review and security scanning as gates, not backlog items. Any “upgrade” of the legacy stack should be considered a fork/maintenance commitment, not a routine dependency bump.

Sequencing: 1) legal/license and security review; 2) architecture spike proving isolated deployment and one read-only content path; 3) content and URL inventory; 4) migration pilot with representative content/workflows; 5) Laravel integration through stable boundary contracts; 6) phased cutover and redirects; 7) decommission legacy. If the goal is only to keep an existing site alive, skip integration and run a containment/maintenance plan with an explicit exit date.

Operational Impact

Maintenance: High. Archived status means no upstream bug fixes, security patches, or compatibility work. The team must own patching, dependency updates, runtime images, and regression testing. Budget for a named maintainer or legacy specialist; “community support” is not an operational plan.

Support: Weak. Vendor support is unlikely unless a third-party legacy provider is contracted. Knowledge is scarce, and modern Laravel developers will not have eZ Publish template/extension experience. TPM should plan documentation capture, runbooks, and knowledge transfer before key personnel leave.

Scaling: Legacy monolith scaling is typically vertical plus caching and database tuning. It is not cloud-native and will not scale elastically like a Laravel service. Keep it on separate infrastructure with clear capacity limits. Scaling Laravel independently is feasible only if the boundary is HTTP/data-level rather than shared runtime.

Failure modes: PHP/runtime incompatibility after host upgrades; unpatched security vulnerabilities; dependency conflicts if forced into Laravel; database schema coupling; session/auth conflicts; extension or template breakage; content migration loss or SEO regressions; proxy/routing misconfiguration during dual-run; license constraints discovered late; and performance degradation when both stacks serve overlapping traffic.

Ramp-up: Steep. Expect weeks, not days, for a Laravel team to become productive in eZ Publish internals, and longer for safe migration work. Start with a time-boxed discovery spike covering runtime, content model, license, and one integration path. Define exit criteria up front: no new features on legacy, a migration owner, a security patch owner, and a decommission date. Without those, the package becomes an indefinite operational liability rather than a leveraged asset.