Laraboot Laravel 5 Bonus Material Released

November 22, 2015 By Bill Keck

Laraboot: Laravel 5* For Beginners Bonus Material Released.

Just a quick post today to let everyone know that I’ve added the first bonus chapter to Laraboot.  With this chapter, it brings the total page count up to 433.

In this bonus chapter, we work with image management and build a dynamically populated bootstrap carousel, also known as a slider.

Working with images can be a bit of a pain, you have to deal with the file management as well as the models in the DB. Fortunately, we get some great help with this within the Laravel framework as well as from the Intervention Image package.

The Laraboot template is straight bootstrap, which means its easy to work with and modify to suit your needs. We use a bootstrap carousel as a slider, and then populate it with images that are managed from the backend admin dashboard. That means you can hand to your clients the ability to manage their own marketing images, which is something they will love.

Thanks to everyone who is supporting this blog and the book with positive comments, I really appreciate it.

Laravel Forge is a Great Tool for Deploying your Application

Access all tutorials in sprocket icon.

October 24, 2015 from author Bill Keck.

Laravel Forge

One of the truly amazing things about the Laravel Framework is the amount of supporting products that are out there in addition to the wonderful free Laravel php framework. I had some interesting insight and discovery with Laravel Forge that I would like to share.

So, I developed my first production app with Laravel,, which is a fairly simple tool for finding “key” comic books, those worth investing in. Yes, people invest in comic books, but let’s not get into that, you can check out the site if you want to know more about that. It’s actually a fun little site.

Now to deploy it, I had some choices available to me that a lot of people don’t have. I went to our company’s network specialist, the one in charge of provisioning servers, and asked him if he could allocate the necessary resources and show me how to deploy my site. He told me he could do it, but that it would have to wait behind some other priorities. Another programmer at work chimed in and suggested I try Digital Ocean in combination with Forge.

I said, “You want me to do it myself?”

It’s one of those moments when you realize you are about to jump into the deep end, without really knowing how to swim. I think that’s an appropriate metaphor considering the name of the hosting company, Digital Ocean.

So just to be clear, Digital Ocean is a cloud hosting platform and Forge is Laravel’s deployment tool. I didn’t have any prior hands-on experience working with production environments, so this just seemed like it was going to be a grind. On the other hand, I could see the wisdom in jumping in full force, there really is no better way to learn. So that time had come.

I created my Digital Ocean account within about 2 minutes, there wasn’t much to it. I went for the $20 per month plan, which was sufficient for my needs, probably more than sufficient, but I always like to leave room in the resources. So getting that setup was a snap, but then the idea of provisioning everything I needed, PHP, MySql, Composer, Apache (in this case ngnix), node and whatever else just seemed way over my head.

So I opted to try Laravel Forge, which builds and helps you manage your server. Just a quick note, I’m going more in the review direction with this post as opposed to a step by step tutorial. I’m not authoritative enough at this point to give you that. But I can describe the process and tell you how it went for me, and I have to say up front, it was fairly smooth and I love Forge. It is well worth the $10 per month in saved time.

Once you signup for Forge, you link it to your Digital Ocean account, which is fairly simple. It’s a few fields in a form with placeholders that make it intuitive. Then you push a button and it configures your server. This is just awesome.

Next you have to link it to your repository, which again is very simple, but to get it to work, you do have to provide a public key for access from your terminal. I had no idea how to do this, but a little Googling got me on the right path. I was able to generate a public key from my mac and provide that to Forge.

In reality, as a complete newbie, this took about 20 minutes, the most time being spent away from Forge and working on the public key generation, and making the typical mistakes, like copying the private key instead of the public one. But once I cleared that hurdle, I was able to deploy my code to the server.

Did the site function out of the box? No. I had to run the migrations. This means you have to ssh into your server and get into the correct directory and run php artisan migrate. So it took me a few minutes to figure out how to do that the first time.

Then that failed because I didn’t have my server environment file set, so no DB connection. Your .env file does not get uploaded into your repository, so the application has no knowledge of the DB. Luckily, the .env file on the server is really easy to edit via Forge, and it only took a minute to update the DB info.

So then I tried my site and of course uncovered a few bugs I didn’t anticipate. I had an error in my navigation bar that was testing for the presence of a profile, but of course while I was coding I had a profile, but now, with a fresh install, I did not, so this was an untested and overlooked problem. It was a simple fix, and again, pulling in the latest code via Forge is a one click prospect. It’s an awesome flow.

But I still had another problem. I ran into the dreaded token mismatch error. This happens when inside the session.php file, which is in the config directory, the domain is not set to the current url. It took me a while to track that down. I felt really dumb because I had run into this before and forgot about it. So I was covering ground I should have already been aware of. This is one reason why I document so much, I just can’t remember everything, and chasing down bugs like that can consume a lot of time.

I also ran into problems where I had to clear my cache for my routes. So once I got all that done, I had a working site. But there was just one more problem. I did not have access to the backend, and since I could only sign up as a regular user, there was no way for me to create an admin user. One way to handle that might be to create a migration that creates the user with admin status.

But I figured I needed to understand how to interact via Mysql directly on the server anyway, so I updated the user record directly from my terminal. So I had to learn how to access MySql from the command line as opposed to using PhpMyAdmin, which is how I typically work with it. None of that has anything to do with Forge. I’m only mentioning these things because you need to have realistic expectations when deploying. You will probably have to do some refining with your app as well.

After getting my install operating correctly, I started reviewing the site and found things that weren’t right. So now I was changing code, pushing it to the repository, then deploying via Forge. Well Forge had one more feature that made this even easier. It can listen for changes to your repository and automatically push them for you. So I switched that on and it works beautifully.

The automatic update did fail for a period, and I imagine behind the scenes that either BitBucket was having problems, which would not surprise me because that has happened before or Forge’s node server quit or something. Anyway, the problem was temporary and I love how it pulls the code automatically. I just push from my IDE, which is PHP Storm, and in less than a minute the code is both in the repository and live on the server. Very cool.

From my personal experience with Forge, I can say it has been extremely positive. I would be hopelessly lost without it, and at a minimum, it would take a lot of work to learn how to provision manually. There’s wisdom in learning how to do it manually, but my focus is not on environments, and I just don’t have the time now to commit to it. For beginner to intermediate programmers, Forge is just a great tool to work with. Eventually I’ll get some feedback from advanced environment guys to see what they think of it as well.

There’s an indicator button in Forge that shows you the status of deployment. Sometimes deployment can take a few minutes, so it’s really cool to be able to see the progress. I love watching it kick over and show me that my changes are live. It’s a good feeling.

In conclusion, I’m giving Laravel Forge the highest possible recommendation. I don’t feel like I’m drowning any more. I’m actually having fun deploying the application. It doesn’t get any better than that.

How to Use @inject in Blade in Laravel 5.1

Access all tutorials in sprocket icon.

June 12, 2015 from author Bill Keck.

In a previous tutorial, we looked at creating a laravel service provider for Laravel. A service provider is a beautiful aspect of the Laravel architecture, but in some cases, when you want to re-use a class in your views, you don’t need it.

Instead, you can use the @inject method in blade. It could work like this:


@inject('boom', 'App\Helpers\Contracts\RocketShipContract')

    {{ $boom->blastOff() }}


Ok, so @section and @endsection are typical blade syntax to define where in the master page the ‘content’ will be placed. Then we can see we have the @inject method. The first parameter is the name of the local variable to hold the object, in this case I called it boom. You can call yours any name that falls within variable naming rules.

The next parameter is the class or contract you are instantiating. In this case, I’m calling a contract, because I have a service provider binding the contract to a concrete class. You can refer to that service provider tutorial for the exact reference.

Then in the dual curly brackets, which is again blade syntax to echo php, you see we are calling the blastOff method from the object instance variable $boom. The blastOff method simply returns a string of text. If you are curious why I chose boom, blastOff, and RocketShipContract, these were examples I was using in my service provider tutorial, which is a related subject. Check that out when you have a chance.

There’s an interesting example of @inject in a Laracast’s video where they use stats as an example, which is perhaps a closer to a real-world example.

Anyway, @inject offers you an easy alternative to service providers, allowing you to bring in reusable code that is not tied to a controller. As I’ve explained above, you can also use @inject in tandem with a service provider, when you want to call a contract instead of a concrete class.

Also note that you can place @inject outside of the @section where the object is being used. So if you want to perhaps place it at the top of the file, above the @extends line, you could do so. That might be more intuitive.

@inject('boom', 'App\Helpers\Contracts\RocketShipContract')



    {{ $boom->blastOff() }}


This looks really clean to me. That kind of flexibility is yet another reason to love the Laravel Framework.

I hope you have enjoyed this tutorial and found it useful. Click on the sprocket icon at the top of the page to see all tutorials. Please comment, share, and like if you can, thanks!

I don’t have a donate button, but If you would like to support my work and learn more about Laravel, you can do so by buying one of my books, Laraboot: laravel 5* For Beginners, I really appreciate it.