Content Bundle Laravel Package

Product Decisions This Supports

• Build vs. buy for content management. The package is a minimal, working demonstration of one modeling approach — content types as Doctrine2 Class Table Inheritance entities — and is most useful as a specification by example when your team debates whether to build a bespoke content model or license an existing CMS. Reading its schema is cheaper than a spike.
• Content model architecture (CTI vs. single-table vs. JSON columns). If your roadmap includes editorial content, product catalog entries, or polymorphic "blocks," this repo shows the CTI trade-offs concretely: clean per-type fields and typed queries, at the cost of table-per-type joins and awkward schema migrations when types multiply. That directly informs a decision you will otherwise make blind.
• MVP scoping for an internal CMS. It enumerates a defensible minimum surface — a content root with typed children — which helps a PM bound an MVP instead of letting scope drift into workflow, versioning, and localization on day one.
• Framework migration risk framing. Because it is Symfony2/Doctrine2, it is a useful artifact in any "should we port this idea to Laravel/Eloquent?" conversation: Eloquent has no first-class CTI, so the pattern does not transfer one-to-one. That is a real roadmap input, not a footnote.
• It does not support any ship decision. Nothing here is a dependency you can put in a composer.json today. Treat it as a document, not a component.

When to Consider This Package

Consider it only as read-only reference material, and only when all of the following hold:

• You are evaluating a Doctrine-based Symfony content model (legacy Symfony 2.x/3.x estate), not a Laravel application.
• Your team specifically wants to see Class Table Inheritance applied to CMS entities, and a two-hour code read is cheaper than an internal design spike.
• Someone owns the read: it is archived, unmaintained, last released December 2013, with no dependents and no security response path. It must never enter a production dependency graph.

Look elsewhere — in practice, always — when any of these are true:

• You are on Laravel. Symfony2 bundles do not install or function in Laravel; there is no Eloquent equivalent of CTI. The port cost exceeds the value of the idea.
• You need maintained code. No releases since 2013, no maintainer, no PHP 7/8 or modern Doctrine compatibility, no CVE process. Adopting it creates unowned supply-chain risk with zero upstream recourse.
• You need anything beyond a toy content model. No editorial workflow, versioning, permissions, localization, media handling, or admin UI of production quality.
• The real requirement is "we need a CMS." Evaluate a maintained Laravel-native option (Statamic, October CMS, Filament with custom content models), a maintained Symfony CMS/admin layer (Sulu, EasyAdmin), or a headless CMS (Contentful, Sanity, Strapi) against your content velocity and localization needs. Use this repo as a comparison point, not a candidate.
• You are tempted to fork it. A 13-star, decade-dormant repository is a rewrite, not a fork. Budget it as such or decline.

How to Pitch It (Stakeholders)

Bottom line: do not adopt. Use it once, as a design reference, and close the question.

For executives: this is a 2013 Symfony2 CMS bundle with 13 stars, zero dependents, and no release in over a decade. It has no security patching path and no maintainer. There is no version of "we depend on this" that survives a risk review, so it is not on the table as a purchase-substitute or a build accelerator. What it is good for is a short, cheap design read that sharpens our own content-model decision before we commit engineering time — roughly a day of one engineer's attention, no procurement, no license, no ongoing cost.

For engineering: the value is the pattern, not the code. It shows Doctrine2 Class Table Inheritance applied to content types — typed child entities under a shared content root — with the accompanying query and migration consequences made visible. If we pursue a bespoke content model on Doctrine, this is a useful prior art reference for that one decision. If we are on Laravel, note up front that Eloquent has no first-class CTI, so the pattern does not port; the reference still helps us reject CTI deliberately rather than by accident. Do not add it to composer.json, do not vendor it, and do not treat its API as a contract.

Recommendation: a one-day timeboxed read by the engineer who owns the content model, producing a short written comparison of CTI versus single-table versus JSON-column approaches. Decision output: build a thin, framework-native content model, or buy a maintained CMS/headless platform. Either way, this package informs the decision and ships nothing.