- Is presta/cms-sandbox a Laravel package?
- No. presta/cms-sandbox is a Symfony 2.x sandbox application for PrestaCMS, which is itself built on the Symfony CMF content stack. It ships no Laravel service provider, no package manifest, no config publishing convention, and no autoload shape that Laravel's package discovery would recognize. Any assumption of a Laravel integration path is invalid.
- Can I install presta/cms-sandbox in a Laravel app with Composer?
- Realistically, no. The package pins Symfony 2.x, Sonata Admin of that era, Doctrine PHPCR-ODM, Jackalope, Twig 1.x and Assetic, all of which are end of life. Composer resolution against modern Packagist will typically fail on abandoned or removed constraints before you ever reach runtime. Even if it resolved, there is nothing for Laravel to boot.
- What is PrestaCMS Sandbox actually used for?
- It is a ready-to-run demonstration project for PrestaCMS, containing fixtures, demo templates and a sample content tree so you can explore the CMS features. It is a demonstration skeleton, not a library intended to be required into another application. Even inside a Symfony project the consumable artifacts would be presta/cms-core-bundle and its siblings, which are equally abandoned.
- Which Laravel and PHP versions does presta/cms-sandbox support?
- None, because it is not a Laravel package at all. On the PHP side it targets PHP 5.3 through 5.5, versions that have been unsupported for over a decade. Modern PHP will hit fatal errors on removed language features long before a kernel boots.
- Is PrestaCMS still maintained?
- No. The repository is archived, the last release was 2014-03-04, and it has roughly 40 stars with zero Packagist dependents. Zero dependents is the strongest signal available: no public production system is validating this code path. Symfony 2.x itself reached end of life in November 2018.
- What dependencies does presta/cms-sandbox pull in?
- It pulls Symfony 2.x, Sonata Admin from that era, Doctrine PHPCR-ODM, Jackalope (with a Java-based Jackrabbit backend in the reference setup), Assetic and Twig 1.x. Every one of those transitive packages is end of life and unpatched. There is no incremental upgrade path; Symfony 2 to Symfony 6 or 7 plus CMF plus Sonata is a rewrite.
- Is it safe to run presta/cms-sandbox in production?
- No, the technical risk is critical. The maintainers have archived the repository, so roughly 15 abandoned transitive packages carry unpatched CVEs with no upstream remediation path, and you inherit 100 percent of that exposure. Running Symfony 2.x in production is not defensible; the only defensible use is reference reading.
- Can I reuse any of the sandbox code or content model in a Laravel project?
- Only as archaeology, not as a dependency. The sensible approach is to read the fixtures and templates to extract the content model, meaning how pages, blocks and reusable content areas were composed, then reimplement that model natively in Laravel. That is a design-input exercise measured in days, not an integration measured in months. Building a bridge between Laravel and Symfony 2 is far more work than reimplementing the model.
- What Laravel-native CMS alternatives should I evaluate instead?
- Before proceeding, clarify whether the driver is a CMS requirement, a Symfony CMF requirement, or simply a repository that looked close. If the target is Laravel, evaluate Statamic, Winter CMS, October CMS, or a headless CMS behind an API against the same requirements. Also ask whether the sandbox page and block hierarchy represents a genuine requirement or just the shape of the demo.
- How would I test or try the sandbox if I still wanted to?
- You would need a PHP 5.3 to 5.5 environment, a Symfony 2.x kernel, and a Jackrabbit backend for the reference PHPCR setup, which is effectively a period-correct virtual machine. That effort buys you a demo, not a foundation. If the goal is to understand the content model, reading the fixtures and templates is faster and safer than booting it.