Conflict with mutator on attribute when a Trait setter is being also used

I think there is a better solution for your problem. Laravel uses Model Events to handle these kind of cases. Everything that you need to know can be found in the documentation, but let me give you a small example

class SomeModel extends Model
{
    protected static function boot()
    {
        parent::boot();

        // This event will be called when you save or update the model
        static::saving(function ($model) {
            // Encrypt the fields here

            // An example would be creating a slug
            $model->slug = str_slug($model->title);
        });
    }
}

Documentation: https://laravel.com/docs/5.3/eloquent#events

Note: I showed you an example that you can use in your model. The documentation shows an example where you register the event in a ServiceProvider. It's up to you how to handle this ;)

Awesome, that looks a lot more flexible than mutators. However I'm going to see how it works using events with traits as the encrypt trait is considerably less overhead and coding than writing an event for each model. The events you showed me have lots of hooks of when they are run so I should be able to use it instead of mutators for items that are unique to that model. I'll do some testing and see how that goes.

When I did my initial reading of the docs to get into Laravel I read the events section https://laravel.com/docs/5.3/events but on my quick read it that seemed more like general housekeeping tasks that I assumed would run after everything else was done. So I never went back to looking at them. I admit that I completely missed seeing the events within the Eloquent section of the documentation where it shows all the hooks too allow you to access it at different stages. Pretty cool.

Thanks.

Okay, got a bunch of time trying different things. At first I thought your method breaks the SoftDeletes trait but then as I worked my way backwards I realized I forgot the parent::boot() call. Oops. But now it works great.

However digging around I see conflicting info on where to put the listener. Some say it is to be in the model's static boot() method as you have it. Others say to put it in EventServiceProvider boot method. Does it just boil down to preference as I see benefits to both places. Or is one method preferred to keep the system more compatible. I'm leaning towards putting it in the EventServiceProvider as then at a glance I can see all events happening.

Thanks for getting me pointed in the right direction. These event listeners are really great.

It's all preference I guess. I like to keep them in my model. In your example you can also have an extra array property on your model that keeps a list of fields you want to encrypt and then use that in your boot method.

Hello, you can also use "Laravel's bootable eloquent traits" if you want to use Model Events in a trait.

There is an example on how you can use it : https://laravel-news.com/booting-eloquent-model-traits