Cms Sandbox Laravel Package

Product Decisions This Supports

• Reference-model validation for CMS architecture — with a caveat. The 2014 full-application sandbox has been refactored into a standalone bundle intended to be included in the separate symfony-prestacms project. It is still not a library you install and use; it is now a fragment of a Symfony CMS rather than a runnable whole. Its value remains as reading material for how block-based, page-oriented content composition is modeled in Symfony — not as something you boot up on its own.
• Build vs. buy framing for CMS. Reviewing the page/block abstraction still gives a concrete baseline to compare against commercial and headless CMSes — it answers "what does page composition actually cost us to build?" rather than "which vendor do we sign?" Note that the refactor removes the "just clone and run the demo" path; getting this running now implies also standing up symfony-prestacms.
• Prototype/demo fodder for stakeholder alignment — downgraded. Previously a lightweight way to show block-based page composition to design and editorial stakeholders. The split into a bundle-plus-parent means demoing now costs more setup for less coherence. Prefer a maintained demo app for this purpose; keep this only as a fallback if you specifically want the PrestaCMS model.
• Do not treat as a roadmap dependency. No change to the adoption signals: no maintainers of record, no downstream users of note, a decade-old lineage. A repo-structure refactor is maintenance hygiene, not a revival, and it does not create a support commitment. No roadmap item should be blocked on it.
• Flag the stack mismatch early — now doubly so. The brief frames this as a Laravel/PHP package; PrestaCMS is Symfony, and this release makes the package explicitly a sub-bundle of a Symfony application. Any assumption of Laravel compatibility, or even of independent reuse, should be corrected before it reaches a spec.

When to Consider This Package

Consider it only when:

• You are running architectural discovery for a content-managed product and want to read a reference implementation of page/block composition — accepting that you are reading a bundle in the context of its parent project, not a self-contained app.
• You are explicitly evaluating PrestaCMS or the Symfony CMF lineage, and are prepared to work within the symfony-prestacms project rather than with this package alone.
• You want to see how a legacy Symfony codebase decomposed a monolithic sandbox into a distributable bundle — marginally useful as an example of that refactor pattern.

Look elsewhere when:

• You need anything in production. Still archived-lineage, decade-old, no security response, and now additionally coupled to a parent project. This is a liability, not a dependency. The refactor does not change that verdict.
• You are on Laravel. No fit. The refactor reinforces the gap: this is Symfony-specific by design and now by packaging.
• You wanted a runnable sandbox. The standalone-bundle change means the demo path requires assembling multiple repositories. Use a current, maintained CMS demo app instead — it will be faster and will encode modern practices this cannot.
• The question is "what should we buy?" A bundle does not evaluate vendors, licensing, or support SLAs. That remains a separate exercise.

How to Pitch It (Stakeholders)

To executives: Nothing material has changed. A decade-old PrestaCMS demo repository was refactored into a standalone bundle to be consumed by the separate symfony-prestacms project. That is housekeeping inside a project we do not use — not a new capability, not a revival, not a support commitment. Our earlier read holds: it is free research material on how block-based content editing is modeled, worth a few engineering hours of skimming, and worth no commitments. If anything, the split slightly reduces its convenience, since the demo now depends on a parent project.

To engineering: Treat it as read-only reference. The release converts the repo from a full application into a bundle consumed by symfony-prestacms; there are no new features and nothing that lifts into a Laravel codebase. If you want to run it, budget for wiring up the parent project and expect stale dependency resolution. Read the page/block abstraction and the admin editing flow, not the implementation. Do not add it to a manifest and do not let it anchor an estimate.

Bottom line: Low adoption value, moderate research value (now slightly harder to access), zero operational value. Budget hours, not sprints.