- Is fsi/doctrine-extensions-bundle a Laravel package?
- No. It is a Symfony bundle that ships a Bundle subclass, a DependencyInjection extension, a Configuration tree, and compiler passes, none of which Laravel's service-provider model consumes. It exists to turn a config block into service definitions and listener registration for the FSi Gedmo fork. In a Laravel application it provides essentially no value because you would have to author the equivalent event-manager wiring yourself. If your target is Laravel, treat this as a category error and look at Eloquent-based alternatives instead.
- How do I install fsi/doctrine-extensions-bundle?
- Run composer require fsi/doctrine-extensions-bundle, then register the bundle in config/bundles.php alongside DoctrineBundle. Add an fsi_doctrine_extensions block to your Symfony configuration to enable the listeners your entities need. On Symfony 4.4 or 5.x this is a low-effort setup; on newer Symfony or Doctrine versions verify the resolved constraints first, because the bundle has not been released since 2021.
- Which Symfony and PHP versions does this bundle support?
- The realistic compatibility envelope is PHP 7.4 through 8.0, Symfony 4.4 and 5.x, and doctrine/orm 2.x. The bundle is roughly two major Symfony releases behind current, and its Composer constraints likely pin those older versions. Anything newer requires checking the actual composer.json constraints before you plan it into a roadmap, since a hard pin can block your whole application upgrade.
- Does it work with Doctrine ORM 3 and Symfony 6 or 7?
- Almost certainly not without constraint overrides. Doctrine ORM 3 removed the annotation metadata driver in favour of attributes, and several Gedmo-lineage extensions changed listener signatures, while this bundle's last release predates both. Symfony's bundle API has also shifted repeatedly across 5.3, 6.0, and 7.x, so an unmaintained bundle is a common source of works-on-5.4-but-fatal-on-6.4 incidents. Test in a throwaway branch before assuming it installs.
- What is the difference between fsi/doctrine-extensions-bundle and stof/doctrine-extensions-bundle?
- Both wrap the Gedmo DoctrineExtensions family, but stof/doctrine-extensions-bundle is actively maintained with roughly 1.7k stars and tracks current Symfony and Doctrine releases. This FSi bundle wraps fsi/doctrine-extensions, which is itself a fork of the upstream library, so you inherit two layers of divergence. Unless you need a specific FSi extension that upstream lacks, stof is the safer default choice.
- Which Gedmo extensions can I enable with this bundle?
- The bundle exposes configuration for Timestampable, Sluggable, Tree and NestedSet, Translatable, Blameable, Loggable, SoftDeleteable, and Sortable. Each listener is toggled per entity manager in configuration, so you can enable only what your entities actually use. Keep in mind the bundle is only a wiring layer; all runtime behaviour such as listeners, SQL filters, and metadata drivers comes from the underlying extension library.
- How do I configure soft deletes and timestamps with this bundle?
- Add an fsi_doctrine_extensions block with an orm section keyed by entity manager, for example default: { timestampable: true, softdeleteable: true }. Your entities still need the corresponding Gedmo annotations or attributes such as Gedmo\Mapping\Annotation\Timestampable and SoftDeleteable. The bundle registers the listeners and the soft-delete SQL filter, but it does not add the mapping metadata for you.
- Is fsi/doctrine-extensions-bundle actively maintained?
- No. The last release was 2021-07-26, the repository has around 3 stars and no dependents, and there is no evidence of CI, a security policy, or issue triage. It reads as a single-vendor internal bundle that happened to be published. If you adopt it, plan to fork and own it, or migrate to a maintained alternative.
- How do I test entities that use these Doctrine extensions?
- Use a functional test that boots a Symfony kernel with the bundle registered and a lightweight database such as SQLite, then create and persist entities through the real EntityManager. Remember that the soft-delete filter hides rows by default, so disable or configure the filter explicitly when asserting deleted records. Reset the EntityManager between test cases, and assert on listener-driven fields like createdAt and slug rather than mocking the event system.
- What are Laravel-native alternatives to Gedmo DoctrineExtensions?
- In Laravel you would normally use Eloquent, which already provides timestamps and soft deletes out of the box. Slugs are typically handled by spatie/laravel-sluggable, translations by spatie/laravel-translatable, and tree structures by kalnoy/nestedset or staudenmeir/laravel-adjacency-list. Blameable behaviour maps cleanly to model events or a trait that fills created_by and updated_by. There is no reason to port this Symfony bundle when the Eloquent ecosystem covers the same use cases.