- Can I install ezsystems/ezpublish-legacy in a Laravel application with Composer?
- Direct Composer inclusion in a Laravel app is not recommended. The package is the legacy eZ Publish CMS kernel with its own bootstrap, MVC stack, templating layer, extension model, database schema, and global runtime assumptions. It is likely to conflict with Laravel autoloading, error handling, sessions, and superglobals. Treat it as a separate legacy application behind a boundary instead of an in-process Laravel dependency.
- What is ezsystems/ezpublish-legacy used for?
- It is the legacy PHP CMS/CMF codebase behind eZ Publish 4.x and 5.x. It provides the kernel, content model, templating, core extensions, and admin interfaces needed to run and maintain older eZ Publish sites. Its practical role is maintenance and migration of existing installations, not greenfield development.
- Does ezsystems/ezpublish-legacy support Laravel 10 or Laravel 11?
- No. This is not a Laravel package and it does not have Laravel version support. It is archived, last released in 2020, and succeeded by eZ Platform with no further feature releases planned. Expect runtime constraints around older PHP and MySQL stacks rather than compatibility with current Laravel and PHP 8.x expectations.
- Is ezsystems/ezpublish-legacy still maintained?
- No. The package is archived, last released in 2020, and explicitly succeeded by eZ Platform with no further feature releases planned. That means no upstream security patches, bug fixes, or compatibility roadmap. Any continued use should be treated as a fork or maintenance commitment owned by your team.
- How do I integrate a legacy eZ Publish site with a Laravel application?
- Use isolation patterns rather than shared runtime state. Run eZ Publish in a separate vhost or container and integrate through HTTP/content APIs, reverse proxy routes, read-only database views, or ETL into Laravel. Keep Laravel as the presentation or back-office layer and bridge authentication at the edge with OIDC, SAML, or a reverse proxy rather than sharing sessions.
- What PHP and database versions does eZ Publish Legacy require?
- The legacy stack is expected to be constrained to older PHP and MySQL versions, but you must validate the exact PHP version, database version, required PHP extensions, Composer constraints, and hosting assumptions for your installation. In practice, plan for a containerized older PHP image rather than running it on the same runtime as a modern Laravel app. Do not promise compatibility before that validation is complete.
- How should I test or evaluate ezsystems/ezpublish-legacy for a migration?
- Start with an architecture spike that proves isolated deployment and one read-only content path into Laravel or another target. Then inventory extensions, content types, templates, workflows, users, URLs, and integrations, and run a migration pilot with representative content. License review and security scanning should be gates before the pilot expands.
- What are the alternatives to ezsystems/ezpublish-legacy for a Laravel project?
- For greenfield Laravel work, use a Laravel-native CMS, a modern headless CMS, or custom Laravel content services instead of adopting the legacy eZ kernel. eZ Platform is the named successor to eZ Publish, but it is still not a Laravel package and should be evaluated as a separate platform. For existing sites, use a strangler pattern to migrate low-risk sections first and keep legacy only for unresolved workflows.
- What license does ezsystems/ezpublish-legacy use, and can I redistribute it?
- The license status is reported as NOASSERTION, so legal review is required before redistribution, embedding, or other use. Do not assume the terms are acceptable for your intended deployment. Treat license review as a gate before integration or migration commitments are made.
- What are the production risks of running ezsystems/ezpublish-legacy?
- Risk is high because the package is archived with no upstream security or compatibility roadmap. You must own patching, dependency updates, runtime images, and security scanning, and the legacy runtime may require an older PHP/MySQL stack. If the goal is only to keep an existing site alive, run a containment plan with an explicit exit date rather than treating the legacy stack as a routine dependency.