- Can I install liip/magento-bundle in a Laravel application?
- No. It is a Symfony 2 bundle that pins symfony/* to the 2.x line and targets PHP 5.3–5.5 semantics, so Composer will not resolve it alongside a modern Laravel application. Laravel also has no equivalent bundle lifecycle, AppKernel registration, or dependency-injection compiler passes. Making it work would mean rewriting it as a Laravel service provider plus a Magento bootstrap shim.
- What does liip/magento-bundle actually do?
- It bootstraps Magento 1 from inside a Symfony 2 kernel so a legacy Magento storefront and a Symfony application can run side by side in one stack. It shares configuration, session and authenticated user state, and exposes Symfony services to Magento code. The goal was to support incremental migration of Magento modules without a full rewrite.
- Does liip/magento-bundle support Laravel 10 or Laravel 11?
- No. The package has never supported any Laravel version and contains no Laravel service provider or facade. It was built specifically for Symfony 2 and its bundle conventions. Modern Laravel releases are not compatible with its Symfony 2 dependency constraints or its PHP 5.x assumptions.
- Is liip/magento-bundle still maintained?
- No. The repository is archived and deprecated, with no version tags, no maintainer, and no security disclosure channel. It is best treated as a proof of concept rather than installable code. Any reuse would be a fork-and-own decision with an unbounded maintenance burden.
- What PHP version does liip/magento-bundle require?
- It targets PHP 5.3–5.5-era semantics and Symfony 2 dependencies. PHP 5.x has been end-of-life for years and receives no vendor security support. This alone makes it unsuitable for any current Laravel stack, which requires supported PHP versions.
- Can I share sessions and logged-in users between Magento 1 and Laravel with this bundle?
- No. It shares session and authentication state between Magento 1 and Symfony 2 inside the same PHP process, not with Laravel. For Laravel, use a separate identity boundary such as OIDC, SSO, or a token-based bridge rather than shared PHP session storage. Sharing a container or session store creates a large blast radius when either side fails.
- How do I integrate Magento 1 with a Laravel application?
- Use a service boundary instead of a shared runtime. Put Magento 1 or OpenMage behind a reverse proxy or API gateway and consume it from Laravel with an HTTP client plus queue jobs for writes. Keep autoloaders, sessions, and processes separate. The bundle is useful only as a reference for where the anti-corruption seams should sit.
- Is liip/magento-bundle safe to run in production?
- No, it carries critical and unbounded risk. Magento 1 has been end-of-life since June 2020 with a history of RCE and payment-data CVEs, and only the OpenMage fork receives patches. PHP 5.x is also unsupported, and the bundle's shared container and session coupling means a Magento bootstrap fault can surface as a 500 on application routes. There is no security advisory process and no active maintainer.
- Does liip/magento-bundle work with Magento 2?
- No. It specifically bootstraps Magento 1 via Mage::app() inside a Symfony 2 kernel. Magento 2 has a different architecture and would not work with this integration pattern. The package is also archived, so even Magento 1 support is frozen.
- What are the alternatives to liip/magento-bundle for a Laravel team?
- The defensible path is a strangler-fig migration: expose Magento 1 or OpenMage behind an API gateway, sync catalog and orders through APIs and queues, and use OIDC for shared identity. If the commerce core must remain in PHP, evaluate modern options such as Sylius behind an API or a headless commerce platform. Read the bundle's source for anti-corruption layer ideas, but do not depend on it.