3.3 Sending Emails
1.Introduction2 lessons, 04:03
2.Laravel Website Basics3 lessons, 11:34
3.Create a Contact Page3 lessons, 22:34
4.Conclusion1 lesson, 02:44
3.3 Sending Emails
Since we're now able to determine if the data that was submitted is valid, then we can now look into actually sending out an email. During development because we don't actually want to send out emails, we're going to be using a service known as, Mailtrap. To use Mailtrap we have to sign up for an account. But don't worry because it's free and it's really easy. Simply head over to Mailtrap.io and click the sign up button. I already have an account, so I'm going to proceed to sign in. When you first sign in, you should be presented with a dashboard which has a single inbox. We're going to need the settings for this inbox, so we'll click on it and we'll be taken to the settings page. The important pieces of information here are the username and password. Don't give these out as they're secret, but you can reset them if you need. And don't worry, I'll be resetting mine after I finish this course. First let's copy the username and then, back in our project, we'll open up the .emb file in the root of our project. This file lets us define configuration on a per environment basis. Now, I don't really wanna get into them too much in this course, but basically instead of having to save our secret information in the actual mail.php configuration file, we can define them in this environment file. Now this environment file should already have most of the mail trap default settings for us. We just need to copy and paste our username and password. So we'll paste in the username and then we'll head back over to mail track website and we'll grab the password to do the same. We've now configured Mailtrap to handle all of our emails, and it's important that if you have a running PHP server by the php outer in serve command, then you must restart it, so the updated configuration values from this environment file are pulled in. Right, so now we can go ahead and we have the view for our email and actually send it out, when we sending our contact request. In our resources/views folder, let's create new folder called emails and inside that folder we'll create a new file called contact.blade.php. Unlike our other views we don't need to extend the template in this one. We can simply write raw HTML since this will only be used to send out emails. However, you could set up an emails template, and extend that if you really wanted to. So let's just quickly throw something together. Once again, this is available in the final card repository for this course. So all we're going to be doing in this view is displaying the data that will submitted from our form which we're pulling from a request instance. Now, we're actually going to send the email. In Laravel 5.3, this is done through what's called a mailable. And it's a bit of a silly name. But the idea behind it is so that it simplifies how we send emails. Quite simply, a mailable is just a PHP class. So this class is going to define who the email would be from, the subject, the view, any attachments and so on and so forth. So, how are we actually going to make one of this classes? Well, Laravel has a generator for us. So let's open up a terminal and we'll make sure that we're in our project's working directory. From here we can run the PHP artisan make mail command. And we'll pass in contact as the name of our class. This command will create a new contact.php file in a new mail folder within the app folder. So let's take a look at this file. Out of the box, this class extends the base mailable class. And it will use a couple of traits for queueing and serializing in the class when it's queued. But we don't need to worry about any of that. This class also has a constructor which we can use for any dependency injection. And it will also have a build method, which is what we're going to be using to actually build the email. So by default, this build method will return a view which is what we're going to be doing. But we also want to set a subject and who the email is from. So before the view method, let's make a call to the from method. And in here we're going to need to somehow get the email address that the user entered in our form. Now, you'll remember that this is part of the request data that we were dumping earlier. So we could simply use the request helper function. And then we could grab the email from the input. But that's not exactly the best way of going about it. So instead, how about we use a request object that we pass into the contact class? So this is what's call dependency injection and if you ever you ever get to the stage where you ever want to be unit testing a lot of your code. Then ensuring you're injecting your dependencies like this is important what we'll do is we'll move up to the constructor and we'll type in the request class and then we'll define the request property. Then we can set the property on our contact class. We're also going to make sure that we define this property as public on our class and I'll explain that in a minute. We also need to make sure that we are importing the request class properly. All right, so we're now able to use this injected instance to fetch the email from the submitted data. Inside the from method, we can now call this request input with email as the argument. Notice that we can chain a call to the subject method and we'll set it to Someone Has Made Contact. Finally, we can go ahead and change the name of the view to emails.contact because if you remember we stored our email within the emails folders. Now, all that is left to do is to actually inject the data into the view and if you remember we actually needed the request instance. With mailables there is a few ways of doing it. One way is to chain a call to the width method and then define an array of keypad values of data. The other is to define public properties on a mailable class which we can then refer to it in our view. And you may remember I said I was going to talk about while we made our property public. And this is why, if we've made that request properly protected then it wouldn't be available within the view, but because it's public, Laravel will automatically inject it into our view for us. So all that's left to do is to actually send this e-mail after the user has submitted the form and we have validated the data. In our routes file we can now remove the dd once validation passes. Instead, we're going to want to send our email and then redirect to some sort of success page. To send an email we can use the to method on the mail facade. The first argument to this method is the email address we wish to send to, so we'll put our email address in here, and then we need to chain a call to the send method. This method takes an instance of our mailable class that we just created. So all we need to do is new app an instance of app, mail contact. And make sure that we pass in the request helper function as the parameter, because that's what we defined as a dependency on the class. All that's left to do is now redirect to a success route that we've yet to create. So we just quickly go ahead and set that out now by copying and pasting the contact route and changing what we need. Then we can create a new view in our resource/views folder, extend the template, and we'll open up the content section. For this page all we'll have is a heading saying that your message has been sent. Nothing fancy. Right, so we're pretty much ready to test this out. So how about we refresh our contact form and fill it out with some test user information and then we'll submit it. After a few seconds we should be taken to our success page, which should mean that the email was sent out. So if we head over to the Mailtrap tab we can now see that we have an email waiting for us, how easy was that? Now all you have to do to actually send out emails is to use a service such as or hook up the Google Mail API and you'll be on your way. We now have fully functional contact form with data validation, and it was actually really easy to do.