- Is mkietlinski/doctrine-extensions-bundle a Laravel package?
- No. It is a Symfony bundle: its code is a Bundle class plus a DI extension that registers Gedmo Doctrine event subscribers from configuration. Laravel does not discover or boot Symfony bundles, so that glue layer does nothing in a Laravel application. The underlying capability lives in gedmo/doctrine-extensions, which is framework-agnostic.
- Can I use this package in a Laravel application with Doctrine ORM?
- Only by effectively removing it. The working path is to require gedmo/doctrine-extensions directly, resolve your EntityManager in a service provider, grab its EventManager, and call addEventSubscriber for the behaviors you need. That is a few lines of code you control, without pulling Symfony's DI and config machinery into a Laravel stack. If your persistence layer is Eloquent instead, skip Gedmo entirely.
- How do I install and configure mkietlinski/doctrine-extensions-bundle?
- In a Symfony app you would require the package with Composer, enable the bundle in bundles.php (or config/bundles.php for Symfony Flex), and configure each extension under the bundle's configuration key, which mirrors the upstream Stof key, stof_doctrine_extensions. Each extension block takes an orm or dbal key listing the entity managers it should be enabled for, plus per-extension options such as sluggable fields. Verify the exact key and option names against the fork's own docs, since fork drift is unmapped.
- Which Gedmo extensions does the bundle register automatically?
- It auto-registers listeners and subscribers for Timestampable, Sluggable, SoftDeleteable, Tree, Translatable, and Blameable, and the same pattern covers Loggable and Sortable from gedmo/doctrine-extensions. It also handles tagging of entity managers and listener priorities so you do not wire services by hand. Defaults are sensible, but every setting can be overridden for advanced cases.
- Does it support multiple Doctrine connections and entity managers?
- Yes. Configuration is per extension and per entity manager, so you can enable timestampable on one manager and soft deletes on another within the same application. The bundle tags the relevant listeners against each configured manager rather than assuming a single default one. Custom service definitions are also supported if you need to replace a listener.
- What are the Laravel equivalents if I am using Eloquent instead of Doctrine?
- Most Gedmo behaviors have mature first-party or established Laravel equivalents: soft deletes and timestamps are native, spatie/laravel-sluggable covers slugs, spatie/laravel-translatable covers translations, kalnoy/nestedset covers tree structures, and spatie/laravel-activitylog covers logging. Blameable is usually a model observer or a creating hook that stamps the authenticated user. Mapping behaviors this way avoids dragging Doctrine into an Eloquent codebase.
- Which PHP, Doctrine ORM, and Symfony versions does this bundle support?
- The fork publishes no compatibility statement, so you have to establish the matrix empirically. Gedmo is tightly coupled to Doctrine ORM internals and has a history of breaking on minor ORM upgrades, so pin and test ORM 2.x versus 3.x, your PHP minor version, attribute versus annotation metadata drivers, and Symfony 5, 6, or 7 if applicable. The upstream stof bundle has a documented, actively maintained matrix if you need a known-good baseline.
- What is the difference between this fork and stof/doctrine-extensions-bundle?
- This package is a downstream fork of stof/doctrine-extensions-bundle, and the mismatch between the Composer name and the repository name makes that provenance hard to see at a glance. It has no dependents, no stars, and a single maintainer, and the patches that justify the fork are not published as a diff. If you are in Symfony, adopt upstream stof unless this fork fixes a specific bug you can name and own.
- How do I migrate from this fork to the maintained upstream bundle?
- Migration is mechanical: pin stof/doctrine-extensions-bundle at the matching major, port your extension configuration block across, remove the fork from composer.json, and clear the container cache. Then verify every entity mapping loads and every listener still fires, because the real risk is registrations disappearing silently rather than code volume. Budget about half a day per environment for verification.
- Is this bundle maintained and safe to run in production?
- The technical risk is high, driven by provenance rather than code quality: a single maintainer, zero dependents, and no signal of testing against Doctrine ORM 3.x, PHP 8.3+, or Symfony 7. The Composer name mismatch with the repository name also makes security review of the delta against upstream harder than it should be. If you must use it, pin exact versions, read the source, and keep a fork you can patch yourself. Also confirm whether the project should be Symfony at all, and whether persistence is Doctrine or Eloquent, since that answer changes the recommendation.