- Is ibrows/simplecms-bundle compatible with Laravel?
- No. It is a Symfony bundle, not a Laravel package, and it depends on Symfony's bundle contract, DependencyInjection extensions, Doctrine entity mappings, Twig templates and Sonata Admin wiring. None of those map onto Laravel's service providers, Eloquent, Blade or Filament. Treat it as prior art for a pages-plus-content-blocks domain model rather than something you can install into a Laravel app.
- Can I just run composer require ibrows/simplecms-bundle in a Laravel project?
- Realistically no. The package is Symfony 2-era, so expect PSR-0 autoloading, annotation readers and PHP 5.x conventions that will not resolve against PHP 8 with Laravel 10 or 11. Dependency resolution is likely to fail on the first require, and you should confirm that with a short spike rather than assume it. Even if it resolves, there is no bundle registration path in Laravel.
- What does the iBrows SimpleCMS bundle actually do?
- It adds lightweight content management to a Symfony application: simple page management, structured content blocks, and an editorial admin surface. It is aimed at small sites that need editable pages without adopting a full CMS. The reusable ideas are the page and block entity relationships and the editorial workflow patterns visible in the admin templates.
- What is the license for ibrows/simplecms-bundle and can I use it commercially?
- The package declares NOASSERTION, which means no recognized open-source grant is attached. Under default copyright that implies all rights reserved, so commercial use and derivative works are legally ambiguous until counsel clears it. This is a stop-the-line item and should gate anything beyond reading the source. Do not ship it into a commercial Laravel codebase without a legal decision.
- Is ibrows/simplecms-bundle still maintained?
- No. It shows zero stars, zero dependents and no active maintainer, and the codebase is roughly a decade old. Adopting or forking it means becoming the sole maintainer of legacy Symfony 2 code with no upstream patch path. For a Laravel team that is an open-ended maintenance liability rather than a dependency.
- How much work is it to port the bundle to Laravel?
- It is a port, not an installation. The realistic workstreams are Doctrine entities to Eloquent models and migrations, Symfony Forms and Sonata Admin to Filament or similar, Twig templates and extensions to Blade, and the DI extension to service providers. A full fork and port is roughly 3 to 6 weeks plus permanent fork maintenance, whereas a native Laravel build of pages plus polymorphic blocks with a Filament admin is about 1 to 2 weeks.
- What are the best alternatives to this bundle for a Laravel CMS?
- For a narrow pages-and-blocks requirement, native Eloquent models with a Filament admin panel and Blade rendering is the cheapest and safest route. If you want a packaged CMS, evaluate Statamic, Twill, or Filament with custom resources against your actual editorial requirements. All of these avoid the license ambiguity and abandoned-code exposure that come with this Symfony bundle.
- Does the bundle support drafts, publishing workflows, localization or permissions?
- Expect it to be limited. A bundle described as a simple CMS typically lacks versioning, draft and publish workflow, localization and role-based access control, and discovering those gaps mid-build forces scope expansion. Confirm the exact feature list before committing to any porting effort. If you need those capabilities, a native Laravel implementation or a mature CMS is the better starting point.
- How should I test or spike ibrows/simplecms-bundle before deciding?
- Spend one to two days attempting a Composer resolve in a throwaway Laravel 10 or 11 project on PHP 8 and record the failure output rather than assuming it. In parallel, read the entity mappings and admin templates to extract the schema and feature list you would rebuild. The spike is about confirming breakage and gathering design input, not about getting it running.
- Is there a safe way to reuse this bundle in production without forking it?
- You could run the bundle in its own Symfony container and consume it from Laravel over HTTP or a shared database, which preserves the code without a rewrite. That sidecar approach still inherits every operational and security liability, including unpinned Symfony 2-era transitive dependencies with no patch path. It is only defensible if the CMS must ship this quarter and the surface is read-mostly, and it does not resolve the NOASSERTION license question.