Sign up to access "Build an E-Commerce Platform" right now.

And in the next episode, we'll look at sending the email. Now, we're going to be triggering this when this is updated via Eloquent, not when it's just manually updated in the database. So if you eventually get to the point where you add an admin panel to this

and you physically change the order status and save it back to the database via Eloquent, that is when this is going to trigger. So to test this, what we're going to be doing is running phpartisan tinker to go ahead and grab out that particular order, update the status, and then see this trigger.

Now, the first thing that we want to do is attach an observer to our orders so we can detect when something changes. So to do this, we're going to go ahead and run phpartisan, make observer, and we're going to call this order observer.

And just before we dive into that, let's go ahead and register this. So we can do this over in our event service provider. If we come down to boot, let's go ahead and grab the model that we want to observe and just use the observe method here.

And then we just pass the observer in, which is our order observer that we just created. Great. Let's pull the model in for order. And we're done. Now, over in our order observer, we can basically pick up on

any of the eloquent events that we get. In our case, it's when the order is updated. So let's go ahead and just go and create our updated method. When that is updated, we'll get an order in.

So the order that is being updated. And then we can just do something in here. For now, let's just die dump on the order. And let's test this over in tinker just to see this work.

So let's pick one from the day space that we're going to be testing. Let's get rid of the packaged at date on this order. And let's go ahead and grab the ID of this, which happens to just be one. So we're going to go ahead and within tinker, say order find and one.

And then we're going to go ahead and say order update. And let's update one of these. So packaged at. So let's say packaged at.

And we'll set that to the current date and time. And there we go. That's died and dumped. So that is coming from here.

So we know that this is triggering properly. And now we need to do a few things. Now what we could do in here is say something like the following. I'll just roughly mock this out.

We could say order and get original, for example. Or we could even grab the dirty records from this, which are the ones that are being updated. And we could check what is being filled somehow. So we could say, well, is packaged at being filled?

Well, if it is, or changed rather, not necessarily filled. If it is, then we'll go ahead and send the email with a packaged at status. The only problem with this is if, for example, we had both of these filled and the status gets rolled back, this is being updated and set back to null.

So we would not want to trigger an email when shipped at is being set back to null, for example. So what we want to do is detect that something is being properly filled in the right order and not being set back to null. Now we'll go a kind of longer way around doing this like we have been for most things.

And then we can come back and refactor this a little bit later. So the first thing that we're going to do is create our filled statuses array, which is going to filter out anything that has been filled and that haven't been set back to null. So what we're going to do is collect up the order, and we're going to use getDirty here,

which is going to go ahead and grab the things that have been changed. Then we're going to go ahead and only pluck out the order statuses. So remember, we have this statuses property that we created earlier, which is a custom property on here.

We could actually set that to public, or you could create a getter for that. And then we want to go ahead and filter this. And we saw this earlier from the status where we actually used last later. But in this case, we're still using that filled helper method,

and we're filtering out everything that has been filled. So let's just die dump on these filled statuses and just see what we get. Let's call that statuses. Actually, that makes a little bit more sense.

OK, so we're going to come over to Tinker again. Let's just quit out of this and go back in. And let's again find that order. And we will update that order like we did before.

Let's find out where we did that. We don't have that in history, so let's just do this manually. So let's say package that. And we will set that to now.

Now let's just make sure that that's empty before we update it. And there we go. So that has now been filled. So we know which one is being filled.

If we do the same thing here and just grab that command again and do this in here with the shipped out, let's see what we get. And there we go, shipped out. So this is always going to give us back what we're updating

that is currently being filled with the things that are being updated. So as an example, and the reason that this is so important, what we could be doing is updating two things. So of course, we might think, well, we're just going to notify

based on the thing that is being updated. But if both of these are being updated at the same time, for example, if packaged out and shipped out are being updated, so let's just go ahead and add this in.

Packaged at now and shipped at now. We get both of these back because both of these are being filled out of what we've done. Now, that isn't terribly useful in our example, because what might also happen is, let's just discard that.

These might already be available. And then we might be filling, say, packaged at and getting rid of shipped at. So let's just pull back the command here. I don't know why that's not in history, but let's just copy and paste this back into here.

And let's go ahead and set packaged at to now and shipped out to null. Perhaps we're reverting this status back. Packaged at is in there. Even though we are updating null, we're filtering that out.

Hopefully that makes sense. These are just the filled statuses that we can use to compare. So what we want to do down here is basically check if the original order, so we'll grab that out in just a second,

status doesn't equal the current order status, e.g. using that status method that we implemented earlier over on our model, then we want to send the email. Now, the original order needs to kind of be mocked,

because the order that we've got here will have already had that status update, because when we get this through, this order represents what has been saved. So we're going to go ahead and say original order. And we're just going to create our new order model.

Bear with me. And into here, we're going to pass in the original properties of that order. And we're only going to fill that with the order statuses that we have and just cast that to an array.

So effectively, what we're doing is we're building up something that looks like the following. Packaged at etc. But we're just grabbing the originals in there and just creating

a kind of fake original order. So let's just go ahead and dump that out. Let's go back to here. And again, just grab this, paste this in.

And that's going to give us the original details back. So if we were to change this over and update just shipped out, for example, to now, that looks like it might have already been updated. So let's go and change that back to null.

We end up with a empty collection here. Let's just quit out of this, actually, and pull it back up. Because I have a feeling that that is not up to date. So let's go ahead and find order one again.

And let's go and just update this something different. So shipped out is null. So when we do update shipped out to now, that original order should contain shipped out as null.

So we're basically getting back the original order before the state has been changed. So now, after all that, we can go ahead and very quickly check the order status. So if the original order status doesn't equal the current order status, and really importantly, with the filled statuses,

we actually have something in there that has changed, then we can go and send the email. So hopefully that makes sense. If it doesn't, might need another rewatch.

So let's go over and just try this out. So I'm going to go ahead and just quit out of Tinker. Pull this back in. And let's go to our database.

Get rid of these two. And let's try this out. Let's just do a couple of example scenarios. OK, so let's go and find that order first.

Great. And we'll go ahead and say order update packaged at. And we'll set that to now. That should send an email.

If we go and, again, I don't know why the history is not here. Set the shipped at date to now. We send an email. However, if I get rid of the shipped at date.

So let's set that to null. That shouldn't trigger an email. And it doesn't. We just get true back because that's been completed.

Now, the reason that that happened is within our original order, the status doesn't match because it's been reverted back to packaged at. But we have no filled statuses, which we looked at earlier. So there wouldn't have been anything in there because we set this back to null.

And we're filtering that out. Hopefully that makes sense. That's as best I can explain it. But now this should trigger properly when an order status actually changes.