Four Key Reasons to Learn Markdown
Back-End Leveling UpWriting documentation is fun—really, really fun. I know some engineers may disagree with me, but as a technical writer, creating quality documentation that will...
Years ago, before joining Big Nerd Ranch, I worked primarily in PHP, but for the last five years, my day-to-day web development stack has been Ruby on Rails. As a team, we’ve enjoyed the productivity boost that it provides and have been really happy with it.
That said, as consultants, it’s important for us to stay on top of new technologies that could help us provide the best solution for our clients. One that we’ve been hearing a lot about is Laravel, a popular PHP framework.
In the last few years, PHP has experienced a bit of a renaissance; the language got some significant upgrades and the community has adopted some new software engineering practices. In fact, many successful sites and services are powered by PHP.
I decided that it would be interesting to see how PHP has evolved since the last time I worked with it. Some folks refer to Laravel as being like Rails, but for PHP. I figured that this is a good place for me to start rediscovering the PHP ecosystem.
My two main sources of information were the Laravel Documentation and Laracasts, which offers excellent screencast tutorials for Laravel.
If you’re already a backend web developer, you are used to having to do a bit of setup. Fortunately, the requirements for working with Laravel are fairly straightforward.
If you’d like to follow along, I’ve outlined the steps for installing the following:
Note: I’ve documented the setup process for macOS. You can also work with PHP and Laravel on Windows or Linux, but you will need to look up setup instructions for those platforms separately.
It’s been a few years since I worked with PHP, so I didn’t even have it installed on my machine. Fortunately homebrew
has PHP in its recipes. (homebrew
is a package manager for macOS, and is often much more convenient than installing software by hand. Installation instructions are at the top of the page at brew.sh.)
To install PHP via homebrew
, type the following in the Terminal:
brew tap homebrew/dupes
brew tap homebrew/versions
brew tap homebrew/homebrew-php
brew install php71
After running those commands, you can verify that PHP was installed successfully by running php -v
.
Composer is a dependency manager for PHP, similar to Bundler in Ruby. Without it, we’d have to individually download and install numerous other dependencies just to run Laravel. Composer will install most of these dependencies for us, including Laravel itself!
We’ll need to download it from getcomposer.org and install it locally. I grabbed the latest snapshot instead of running the installation commands. This provided me with a file named composer.phar
To make Composer available globally, you will need to move that file to a location on your $PATH
:
mv composer.phar /usr/local/bin/composer
Open a new Terminal tab and enter composer
. If it has been installed correctly, it should show a list of available commands.
Finally, you get to install Laravel! Run composer global require "laravel/installer"
in your Terminal.
You will now have a laravel
executable in your home directory under .composer/vendor/bin
. Depending on your OS, you may need to add $HOME/.composer/vendor/bin
to your $PATH
in your login script.
After you make that change, the laravel
executable will be available in any new Terminal tab or window from now on. Make sure it is installed correctly by opening a new Terminal and typing laravel
at the prompt.
Cool, our dependencies are all in place—we’re through the most tedious part. Now let’s write some actual code: change directories to wherever you keep your project code, e.g. cd /Users/charlie/Projects
.
We’ll build the classic, time-tested example app: a blog. And we’ll even name the project blog
.
Execute laravel new blog
. If you’re used to Rails, this is the equivalent of running rails new blog
.
Whoa, according to our Terminal output, that did a lot. Let’s slow down for a second and take a look at what just got created.
Open the contents of the /blog
directory with your preferred text editor. You will see a set of folders and files which are typical of the Laravel framework and not unlike the structure of a freshly generated Rails project. There are directories called app/
, config/
, database/
, routes/
, tests/
, and public/
which all have counterparts in Rails. Frameworks in general have abstracted these concepts out into organized and recognizable conventions. So even without knowing much about Laravel, we can find our way around by looking for conventions we recognize from Rails.
Artisan is Laravel’s command line utility and comes packaged with the Laravel installation. When I run php artisan -V
from within my /blog
directory, it returns Laravel Framework 5.4.8
, which means I’m working with version 5.4.8 of Laravel at the time of this writing.
By running the new
command in Laravel for our blog app we’ve created the entire directory structure required by the framework for our app, and it’s a lot of files. We don’t have to learn what all of them do right away – we’ll focus on the default welcome screen and how it gets served in the browser.
With that in mind, we want to view the app in our browser, so we need a server to be running locally. Open a new Terminal tab, make sure you’re in the /blog
directory, and execute php artisan serve
to start a server at http://localhost:8000
, which is port 8000 on your local computer.
This page is comparable to the default public/index.html
file in a freshly generated Rails project.
OK nice! Now we have a web page. So where is the code for this page coming from?
To find out, open the file /routes/web.php
in your text editor. This is the file which controls the web request routing for the app. Rails users should be quite familiar with the concept of a Routes file, as Rails uses one too.
It will look like this:
<?php
Route::get('/', function () {
return view('welcome');
});
I haven’t read much PHP lately, but fortunately this is pretty clear about what it does: It builds a route which responds to any GET request to the root directory using a function which returns a view named welcome
. That means the HTML being shown in the browser is contained within a view named “welcome” – more specifically, it’s in the file /resources/views/welcome.blade.php
. We can omit the full path of the file from the route thanks to helpers built into Laravel – it knows when we define views to return that it should look for files with the extension .blade.php
in the /resources/views
directory.
Blade is the templating engine for Laravel which makes it easier to work with PHP in HTML views. Think of it like ERB or slim – it’s an additional layer of tools and shortcuts that makes writing HTML with embedded PHP more convenient. As you work with Blade, you’ll become familiar with more of its helpers, but you don’t need to know anything to get started with it.
Open /resources/views/welcome.blade.php
in your text editor. Notice how even though this is a .blade.php
file, it’s all just HTML code. That’s because this page is static. You’ll notice a good bit of CSS in the header block of the HTML code. Scroll past this to find the <body>
of the HTML which contains the page’s content.
Now that we know where the content is coming from, let’s experiment with changing it. Look for this block of code:
<div class="content">
<div class="title m-b-md">
Laravel
</div>
<div class="links">
<a href="https://laravel.com/docs">Documentation</a>
<a href="https://laracasts.com">Laracasts</a>
<a href="https://laravel-news.com">News</a>
<a href="https://forge.laravel.com">Forge</a>
<a href="https://github.com/laravel/laravel">GitHub</a>
</div>
</div>
Change the “Laravel” copy in the title
div to “Hello World”. Then reload the page in your browser.
Change the HTML in the view so that it contains no CSS or default templating. For now we just want to start with some very simple HTML we can edit and see our changes in the browser.
<!DOCTYPE html>
<head>
<title>Hello Laravel</title>
</head>
<body>
<h1>Hello World!</h1>
</body>
</html>
Then reload the page in your browser:
So far we’ve only modified the default page found at the root of the app’s URL. Let’s experiment with adding a new custom route. Imagine we want to add another page called “About Us.” Add a second route to /routes/web.php
so that it looks like this:
<?php
Route::get('/', function () {
return view('welcome');
});
Route::get('/about', function () {
return view('about');
});
Now we should be able to navigate to http://localhost:8000/about
in the browser, and it will serve our new custom route.
Oh no! We forgot to create the view for that route. That’s okay, because this error screen is helpful and reminds us of what’s missing: View [about] not found.
Let’s fix that now by creating a new file under /resources/views
called about.blade.php
which has the following content.
<!DOCTYPE html>
<head>
<title>Hello Laravel - About Us</title>
</head>
<body>
<h1>About Us</h1>
</body>
</html>
Much better! Now we have a root path and a custom path. If we add a link to the “About” path to our root page HTML, the user could navigate from the Default page to the About page. We can build a whole static website this way, and we’ve only just gotten started! But our ambitions are higher than a static website…
As the wise ones say: you gotta crawl before you can walk. Hopefully this post was helpful in showing how to get Laravel set up and create a static site. In my next post, I’ll take you through the steps of making Laravel push out dynamic content.
At this point, Laravel is proving to be very similar to Rails. It’s clear that PHP has come a long way, and thanks to its Rails-like conventions, I see a good opportunity to use my existing Rails experience and port it over to the PHP world. And I’m confident that my team could provide an excellent Laravel-based solution for a client who has already invested significantly in PHP for their business.
If you are looking to grow your web presence or build a new web app, definitely drop us a line. We can work with you to help figure out your best options, no matter what your current tech stack is.
Writing documentation is fun—really, really fun. I know some engineers may disagree with me, but as a technical writer, creating quality documentation that will...
Humanity has come a long way in its technological journey. We have reached the cusp of an age in which the concepts we have...
Go 1.18 has finally landed, and with it comes its own flavor of generics. In a previous post, we went over the accepted proposal and dove...