Weave Code
Extensions Laravel Package
laravel-doctrine/extensions
Adds common Doctrine behavioral extensions to Laravel Doctrine, including soft deletes, timestamps, blameable, sortable, sluggable, tree, loggable and more, with config and service provider wiring so these behaviors work smoothly in your Laravel models.
Extensions integration for Laravel and Doctrine
Frequently asked questions about Extensions
- How do I install laravel-doctrine/extensions in a Laravel app?
- Install it with Composer using composer require laravel-doctrine/extensions. It is an integration layer rather than a standalone ORM, so laravel-doctrine/orm and doctrine/orm must already be installed and bootstrapped in the application. Laravel package discovery registers the service provider in most setups, and you can publish the config if you need to control which extension listeners are active. After that, enable the individual behaviors on the entities that need them.
- What Doctrine behavioral extensions does this package include?
- It bundles the common Doctrine behavioral extensions used in Laravel Doctrine: soft deletes, timestamps, blameable, sortable, sluggable, tree, loggable and more. Each one is wired through configuration and a service provider so the listeners and filters are registered without manual Doctrine event-manager plumbing. That is the main value: you get the behaviors working smoothly inside a Laravel application instead of assembling them yourself.
- Does laravel-doctrine/extensions support Laravel 13?
- Yes. Version 2.0.3 is a compatibility release whose only listed change is Laravel 13 support, with no new features, deprecations or intentional public API changes. Because this is a bridge package, support is only actionable if laravel-doctrine/orm, doctrine/orm and doctrine/dbal resolve for Laravel 13 as well. Confirm that full chain by resolving constraints in your own application rather than reading the changelog alone.
- How do I enable soft deletes on a Laravel Doctrine entity?
- Declare the soft delete behavior on the entity mapping (attribute or annotation, depending on your Doctrine version) and make sure the SoftDeleteable filter is enabled so normal queries exclude trashed rows. You can toggle the filter at runtime when you genuinely need to read deleted records, for example in admin screens or restore routines. Remember the deleted-at value is a real column, so schema changes still go through your migrations or the Doctrine schema tooling.
- How do I configure Timestampable, Sluggable or Blameable behaviors?
- The extension listeners are registered by the package service provider and driven by configuration, so you can enable or disable individual behaviors and adjust their defaults without patching vendor code. Per-entity behavior is declared in the entity mapping itself, such as which fields are timestamped or which property holds the slug source. Blameable depends on the package resolving the current Laravel user, so verify authentication wiring is correct before relying on it in production.
- Can I use laravel-doctrine/extensions alongside Eloquent in the same Laravel app?
- Yes. It coexists with Eloquent using dual connections, which lets you migrate parts of a domain to a data-mapper model without a big-bang rewrite. It is a strong fit when your domain layer already expects entities, repositories and an EntityManager. It is a poor fit for a heavily Eloquent-idiomatic codebase, because running two persistence paradigms carries a real cognitive tax for the team.
- What is the upgrade path to laravel-doctrine/extensions 2.0.3?
- From 2.0.x on Laravel 12 this is a routine patch bump: widen the constraint, run composer update, and verify the EntityManager still boots and your integration suite is green. From 1.x or Laravel 11 and earlier, treat it as two steps: land the framework upgrade on a branch against the existing package line first, then move to 2.0.3. Keep 2.0.2 documented as the rollback until the branch is proven.
- How do I test entities that use soft deletes, tree or sluggable behaviors?
- Run a real integration suite against a database rather than mocking the EntityManager, because these behaviors are filter and listener driven and only show up end to end. Enable or disable the relevant filters explicitly in test setup so assertions match what production queries actually return. A doctrine:schema:validate run in CI is worth adding, as it catches mapping drift early and is a common hidden breakage when upgrading bridge packages.
- Is laravel-doctrine/extensions actively maintained and safe for production?
- It is community open source with no vendor SLA, a small maintainer pool and a low release cadence, and it has historically lagged new Laravel majors. The 2.0.3 release is positive evidence the maintainers are keeping pace, but it also means you depend on them doing so every year. The package itself is thin and stable, so budgeting for the annual framework-bump coordination and assuming you can fork or patch it internally is a realistic posture for business-critical use.
- What are the alternatives to laravel-doctrine/extensions?
- The behaviors originate in the Doctrine extensions ecosystem, so you could wire those listeners and filters into Doctrine manually. Doing that means rebuilding exactly the service provider and config layer this package exists to provide, which is rarely a good use of time. On the Laravel side the usual alternative is Eloquent plus separate packages for soft deletes, slugs and nested sets, but that gives up the data-mapper and unit-of-work model. Note that this package is not the ORM itself: adopting laravel-doctrine/orm is the real architectural decision, and this library only smooths it out.
Weaver
How can I help you explore Laravel packages today?