- How do I install jeffersongoncalves/laravel-created-by in a Laravel app?
- Install it with Composer using composer require jeffersongoncalves/laravel-created-by. Laravel's package auto-discovery registers the service provider, so no manual provider entry is needed. If you want to change column names or the guard used, publish the package config file and adjust it there.
- Which Laravel versions does laravel-created-by support?
- Version 2 of the package requires laravel/framework ^12.61.1 or ^13.12.0, so it will not install on Laravel 11 or on early 12.x patch releases. The strict patch-level floor is deliberate, because those framework versions contain fixes for known security advisories. If you are stuck on an older framework version, you would need to upgrade Laravel before upgrading the package.
- How do I automatically set created_by and updated_by on an Eloquent model?
- Add the trait provided by the package to any model you want tracked, and make sure that model's table has the created_by and updated_by columns. From then on the package listens to the Eloquent creating and updating events and fills those attributes from the currently authenticated user, so you never assign them in your controllers or services. No other wiring is required.
- Can I change the created_by and updated_by column names?
- Yes. The package ships with a configuration file where you can set the exact column names it should write to, so you can match an existing schema that uses names like creator_id or editor_id. Update the config values once and the trait will use them everywhere. This keeps the package usable on legacy tables without renaming columns.
- What happens when there is no authenticated user, like in a seeder or Artisan command?
- The package is designed to be safe in console commands, seeders, queue workers, and unauthenticated requests. When no user is resolved from the configured guard, it simply skips stamping the audit columns instead of throwing an exception or writing a bogus ID. That means your existing seeding and background job flows keep working unchanged.
- Can I use a different auth guard or a custom user resolver?
- Yes. The package reads the authenticated user through Laravel's auth guards, and the guard it uses is configurable, which is useful if your app authenticates admins or API clients on a non-default guard. You can also supply your own resolution logic when the current user is not simply the default guard's user. This makes it adaptable to Sanctum, Passport, or multi-guard setups.
- Why do I get a Composer conflict about laravel/framework when installing version 2?
- Version 2 declares a minimum framework version of 12.61.1 (or 13.12.0), so Composer refuses to install it alongside an older laravel/framework constraint. That is intentional: the maintainers pin to patched patch levels rather than masking an unpatched framework. The fix is to upgrade Laravel to at least that patch release, then install the package, or stay on the previous package major while you schedule the framework upgrade.
- Do I need to create the created_by and updated_by columns myself?
- Yes. The package does not ship migrations, because it does not know your table names or whether the columns should be foreign keys. Add nullable columns, typically foreignId(...)->nullable()->constrained('users'), to each table you want tracked, then add the trait to the matching models. Keeping the schema in your own migrations also lets you choose whether to cascade or null on user deletion.
- How do I test that the trait stamps the audit columns correctly?
- Use Laravel's actingAs helper to authenticate a user in your test, then create and update a model that uses the trait and assert the created_by and updated_by attributes. Also test the unauthenticated case to confirm the package skips stamping rather than failing, which mirrors real console and seeder behaviour. Because the logic runs on Eloquent events, standard feature tests against your models cover it without extra setup.
- How is this different from an activity log package like spatie/laravel-activitylog?
- This package does one narrow job: it writes the creating and updating user IDs into two columns on the model's own row. Activity log packages instead record a separate history of every change, with subjects, causes, and properties, which is more powerful but heavier. Choose laravel-created-by when you only need last-touched audit fields and want zero boilerplate; choose an activity log when you need a full audit trail.