- Can I use fsi/news-bundle in a Laravel application?
- There is no practical integration path. It is a Symfony 2 bundle built on Symfony's HttpKernel, EventDispatcher, DependencyInjection, Forms, Twig and Doctrine ORM, and Laravel offers no bundle system or equivalent service-container tagging to hang those pieces on. A runtime bridge would mean running one framework inside another, so the realistic option is to harvest the content model and rewrite it as an Eloquent model plus a migration.
- How do I install fsi/news-bundle with Composer?
- Historically you would run composer require fsi/news-bundle and register the bundle in AppKernel, which has no equivalent in Laravel. Its releases date to 2015 with PHP constraints of that era, so expect Composer to fail dependency resolution against PHP 8.x and modern Laravel or Symfony packages. Installing it into a current application is not recommended.
- Does fsi/news-bundle support Laravel 10 or Laravel 11?
- No. The package predates modern Laravel entirely and ships no service provider, no Eloquent integration, no Blade or Livewire views and no Laravel routes. Laravel 10 and 11 require PHP 8.1+, while the bundle's 2015 constraints will conflict with that dependency graph long before anything runs.
- Which Symfony versions does fsi/news-bundle target?
- It is a Symfony 2-era bundle that bundles entities, Doctrine mappings, controllers and admin UI hooks into one drop-in package. Symfony 2 is end-of-life, and that bundle-as-mini-application pattern has been out of favour since Symfony 4's recipe-based structure. Even inside a maintained Symfony app it would clash with attribute routing, autowiring and migrations-as-code.
- Is fsi/news-bundle still maintained?
- Effectively no. The last release was March 2015, the repository has one star and zero dependents, and FSi Open appears defunct with no maintainer to escalate to. That means no incidental bug reports, no security review and no community patches, so treat the package as abandoned.
- What are good alternatives to fsi/news-bundle for a Laravel news or article module?
- Build a small first-party package instead: one migration with title, slug, body, status, published_at and author_id, one Eloquent model, one public controller and route group, and an admin resource in Filament, Nova or Backpack. That covers the same domain concepts with a fraction of the machinery and full framework support. It also keeps schema ownership and upgrades under your control.
- Is fsi/news-bundle safe to run in production?
- Treat it as high risk. A 2015 admin CRUD bundle implies request handling, form submission, media upload paths and possibly a WYSIWYG field, none of which has seen a CVE process or dependency audit since 2015. Its transitive dependencies from that era are a known supply-chain hazard, so it should not go into production without a full audit, and realistically not at all.
- Does fsi/news-bundle manage its own database schema and migrations?
- Expect Doctrine entity mappings to be shipped inside the bundle, and older bundles of this generation often relied on doctrine:schema:update rather than versioned migrations. Owning schema outside your migration-as-code workflow is a hard blocker in a Laravel codebase. Verify this before adopting anything, and plan to write your own migration regardless.
- Can I extract just the content model from fsi/news-bundle?
- Yes, and that is the recommended approach. Read the bundled entity and repository to identify non-obvious fields such as SEO metadata, publish windows, ordering and taxonomy, then reimplement them as a Laravel migration and Eloquent model. Reimplementing that model takes hours, whereas bridging Symfony into Laravel would take weeks and leave you maintaining a dead dependency.
- How should I evaluate or test fsi/news-bundle before deciding?
- You cannot meaningfully test it inside a Laravel test suite, because none of its Symfony dependencies will boot there. The cheapest evaluation is static: read the entity, repository and routing files, and run composer why-not to see which PHP and framework constraints block it. If you must execute it, budget a throwaway Symfony 2 container on an old PHP runtime as research only, never as a staging environment.