I was recently asked to code review a friend’s first Laravel app, and when I cloned the repository from GitHub I immediately noticed a few big, red flags. Many of these were common mistakes, so I thought I’d take a moment to discuss how we can safely handle credentials and/or sensitive information in our Laravel applications.
Category: Laravel
Though it’s far from the top of the list of most celebrated features, Laravel’s Blade templating engine makes it really nice to work with data on the front-end of our applications. With built-in helpers for handling loops, conditionals, and sub-views, Blade gives us a nice way to write dynamic templates that don’t feel like a bunch of PHP mixed in with HTML.
Were you aware you can author your own Laravel Blade directives? The syntax is probably a little under-documented, but it can be an incredibly useful tool if you find yourself applying the same patterns over and over. In this post, I want to show you a Blade directive I find myself using in pretty much every application I build: @activeIfInRouteGroup.
Despite working on Liquid Web’s Managed WordPress and Managed WooCommerce hosting products, a fair amount of the development work I do these days has very little to do with WordPress. In fact, my main project right now is using Laravel, and it’s the sixth Laravel application (depending on how you count projects) I’ve worked on in just under two years at the company.
Laravel’s an incredibly powerful application framework with a thriving ecosystem. Thanks to tools like Composer and Packagist, I have access to thousands of libraries, extensions, and utilities to help me build the best applications possible. Even out of the box, the framework has support for (among many other things) multiple database and caching engines, event-driven architecture, and websockets, giving me a strong foundation for building modern web applications.
Of course, incorporating multiple platforms and tools into a single application can make on-boarding new team members more difficult. How do you make sure they’re running the right versions of PHP, your RDBMS of choice, Redis, and more?
Years ago, a mentor of mine introduced me to a Ruby-based server automation tool called Capistrano, and I immediately fell in love. Ready to deploy a new release? Rungit push && cap production deploy, then you’re done. Even better, Capistrano introduced me to what’s colloquially known as “atomic deployments” — checking out a full copy of the codebase and using symlinks to point to the new release for a zero-downtime deployment — which has since been my gold standard for deployment methods.
I continued to use Capistrano for a few years, until I started working on projects (and teams) large enough to justify a proper continuous delivery (CD) tool. Suddenly, building the application locally and pushing up with Capistrano became more complicated; at the same time, services like DeployBot began offering atomic deployments right out of the box, so it was easy to get up and running.
What about services that don’t offer atomic deployments as a default? I recently deployed a Laravel application via Codeship, where atomic deployments to a VPS becomes more complicated; here’s how I approached it:
Today, Laravel Homestead maintainer Joe Ferguson tagged version 7.16.0 of the Laravel Homestead library. The announcement tweet includes “Adds support for user-customizations.sh” which, probably doesn’t mean much to anyone who hasn’t followed Pull Request #932 over the last few days. As the person who opened that particular PR, I figured it might be nice to document the motivations.
Out of the box, Laravel ships with a simple-but-intuitive localization system: when you call trans('some.key')and Laravel will automatically replace it with the value of “key” within resources/lang/{locale}/some.php. Laravel translations also accept placeholders and can handle pluralization, making it extremely easy to build applications that are localization-ready.
Of course, building an application that’s localization-ready means the Laravel translations need to be filled out to begin with. It’s far too easy to get on a role writing several views, then miss a string or two when creating the localization files. Heck, even the comments in the Translator class within Laravel itself doesn’t seem to think much of it:
If the line doesn’t exist, we will return back the key which was requested as that will be quick to spot in the UI if language keys are wrong or missing from the application’s language files. Otherwise we can return the line.
Unfortunately, I’ve had one too many apps go live (or in front of clients for demos) with a string or two missing a translation. Finally, I decided to do something about it.
Since joining Liquid Web, I’ve gotten to revisit Laravel, my favorite application framework for PHP. I’m still doing plenty of WordPress work, of course, but when building web applications — especially those with robust APIs — building atop Laravel makes so much more sense than shoehorning it into a WordPress environment.
In their mission to make application development delightful, Taylor Otwell and the other Laravel developers (including my friend Joe Ferguson) maintain Laravel Homestead, a pre-packaged Vagrant box for Laravel development. While the environment can be installed globally, Laravel Homestead can also be installed on a per-project basis, ensuring each application has its own, dedicated virtual machine.
In my role as Senior Software Engineer at Liquid Web, I’ve gotten to get back to my roots of not only doing WordPress, which has been great. In particular, I’m getting back into Laravel, getting to build real web applications in an environment that makes testing a breeze (aside: if you haven’t checked out Adam Wathan’s Test Driven Laravel course, I cannot recommend it enough!).
I ran into an interesting problem today, however, when I updated the APP_URL variable in my .env file: running my [previously 100% green] test suite, I was getting random errors and failures within my feature tests that I hadn’t been seeing before. Controller actions weren’t responding properly, model relationships weren’t always behaving, and redirects following actions were hit-or-miss.
Forgive me if this is old news, but hostname-based environment switching isn’t as nice as it could be; I like using *.dev for my development environments, but other people I know like *.development, *.local, etc. The truth of it is the more developers you have working on a project the higher chance you run of the application being run at a variety of hostnames, mucking up your bootstrap/start.php file.
Fortunately, Laravel doesn’t force us into using hostname-based environment switching. At work we’ve developed this little workflow, and it seems to be working really well.
