It isn’t. PHP is not dead. It isn’t dying and it isn’t reaching “end-of-life”. That’s it. No matter how much some people want it to go away, it isn’t going away. At least, not for a long time.

Image for post
Image for post
Photo by Ian on Unsplash

I’ve been writing this for a while now. Tweaking here and there, but just couldn’t decide when to publish. With the recent release of PHP 8, “now” felt like the right time.

Every month I read an article, or a comment or tweet stating that PHP is dying and we should stop using it. If you see a question on some or other forum or on Stack Overflow about learning PHP, there is an almost 100% chance that there’s a response from someone saying something like: “why would you want to learn PHP? Learn something cool like <insert-cool-language-that-isnt-php-here>”.

I have spent close on 20 years writing stuff in PHP (actually, it might be more. I don’t truly remember when I started), among other languages, and, for the most part, I have simply ignored much of that side of the conversation. For almost all of those years, PHP has been “dying” and I should’ve stop using it years ago. I am by no means an expert in any of the languages I use, and I have plenty to learn about PHP, yet time and time again, I find myself coming back to it. …

Tired of those XMLHttpRequest CORS policy errors? Me too.

Image for post
Image for post
Photo by Andrea Palacios on Unsplash

Here’s a quick one on using Browsersync with Inertia. If you’ve ever tried and you got hung up on those pesky CORS errors that prevent redirects, then maybe I have a workaround for you.

The bit about Browsersync

Browsersync is one of those tools that just sticks. It has fantastic staying power. When I started building stuff for the web, LiveReload was all the rage. I loved that I could put my browser on one screen, my editor on another and not need to manually refresh every time I needed to see a change. It would just update whenever I saved stuff.

LiveReload eventually fell out of favour (is it even still a thing? I don’t know) and I went off to find an alternative. It didn’t take me long to come across Browsersync. It kinda did the same thing LiveReload did, but without the need to install that UI app. It’s a node dependency in the actual project, and it worked nicely with Webpack (also a recent discovery at the time). …

Permissions can be complex. Here’s an easy solution.

Image for post
Image for post
Photo by Rob King on Unsplash

tl;dr: If you’re not interested in setting this up yourself and would rather just install a package, I wrote one called Deadbolt. Check it out on GitHub.

I’ve built a number of Laravel applications over the years and most of them had some sort of authorisation requirement. Some users should have access to certain resources, while other users should not. It’s easy, right? Add a boolean column to your users table that gives users access to that resource if it’s set to true. Done!

Sure, that works. But it’s really not very flexible. What happens when you have lots of resources? What if you need to protect other parts of your application? That simple boolean “flag” is quickly going to show its shortcomings. This is where you quickly start to realise that you need some form of permissions system. Luckily there are quite a few really awesome solutions to choose from, but by far the most popular (for good reason) is the laravel-permission package from the guys at Spatie. It has everything you could possibly want out of a permissions package for Laravel. If you’re looking for a really flexible, feature-rich permissions package, then that is definitely the right way to go. But every now and again, you just don’t need all of that. Sometimes, all you really want sits somewhere between the boolean flags and the power of Spatie’s solution. …

I’ve grown, I’ve learned some stuff, I’ve broken some other stuff. So I think it’s about time I did…

My first attempt at zero downtime deployments was exactly what I needed a few years ago. But now, I have something better.

Image for post
Image for post
Photo by Hello I’m Nik 🇬🇧 on Unsplash

A few years ago, I wrote an article on how to use Envoy to run zero-downtime deployments. That article has been a somewhat popular one. It still gets around 100 reads a week, which I don’t think is all that bad considering I’m definitely NOT a professional writer. That approach to deployment was great and it’s a method I’ve used for quite some time. It has, however, started to show its limitations—especially since it’s not “just me” anymore.

I’ve always been a bit of a lone programmer. I studied graphic design many years ago, but it just wasn’t my cup-o-tea. I left design for web development in my 20s and basically taught myself everything I know (thanks to a decent collection of some well written books and some strategically placed people in my life), and I’ve never looked back. Like many who teach themselves, PHP and JavaScript quickly became my thing, and I’m now massive fan of Laravel with a fair amount of experience. …

2019/03/03: I recently updated this post, and there’s quite a number of changes I’ve made. The old post was fairly outdated and needed some attention.

I work on a lot of apps that load up an “organisation” or “client” profile based on a sub-domain slug. It’s quite common in multi-tenant applications. This is something we do on MotorPress ( and it works really well, so I’ll use that as an example.

Each publisher on MotorPress gets their profile. They can publish content to the main MotorPress feed, or exclusively to their own branded, public profile feed. We provide each publisher with their own sub-domain. …

Image for post
Image for post
Photo by Sam Xu on Unsplash

Update 2019–12–17: I’ve written a second version of this deployment process. This article is still entirely relevant, but if you want a slightly updated process, take a look here.

Envoy is one of the most useful tools in the Laravel ecosystem and I use it almost every day. Nearly every project I work on gets it’s own Envoy script to makes deployments super simple.

Envoy is a task runner, and a simple one at that. It’s not Laravel specific (it’s not even PHP specific) but does make use of the blade templating language as a way to script actions. So Laravel developers will feel immediately comfortable. Although you could use Envoy to write deployment scripts for pretty much any tech you happen to be using, I’m only going to deal with Laravel here. …

NOTE: 18 October 2017

So with the release of Laravel 5.5, this isn’t really needed anymore. Laravel 5.5 now has a package discovery feature so there is no need to add supported packages to your app.php config anymore. Simply install the package and you’re good to go.

Here’s a little snippit I use all the time. It allows you add packages to your Laravel installation selectively based on the environment you’re working in. There’s always those dev packages you don’t want, or shouldn’t have in production, so they get added to require-dev. Cool, but then you have non-production packages all over your app.php config file in production code. …

Image for post
Image for post
Photo by Nicolas Picard on Unsplash

Update 2019/01/15—With only minutes to spare, Hetzner have come to the party. PHP 7.1 and 7.2 are now available as options on all shared hosting packages. I can once again recommend Hetzner as a shared hosting provider. Exciting times.

Update 2018/11/20 —I am no longer recommending Hetzner as a shared hosting provider. This is simply due to the incredibly slow response to PHP upgrades. Hetzner currently offers PHP 5.6 and PHP 7.0 both of which will reach end-of-life in December this year. There has been no indication of any intention to upgrade to at least PHP 7.1. …


Warrick Bayman

Programmer, musician, cyclist (well... I own a bike), husband and father.

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store