My talk “Slicing into Blade” from Laracon EU Online 2021 has just been made public on YouTube, so if you’re looking for an overview about how Laravel Blade’s internals works and want to take a dive into it, check it out!
In this short video series, I take you through Laravel Blade and some things I’ve picked up from using it extensively for a long time.
We’ll see how to make Blade work from plain PHP, the additional things it does under-the-hood, how to disable the view cache, extend Blade and write your own custom directives that work reliably and effectively. Come along for the ride and watch the series.
We use autoloaders in PHP all the time, but if you change your mindset a little, you’ll find they can do a lot more than you might’ve thought. We’ll be taking a look at using some unconventional techniques, we can use autoloaders to take PHP a step further, introducing interesting and exciting new functionality PHP natively doesn’t support.
You might be aware that one Gmail account could have an almost unlimited number of email addresses associated with it, to no effort of the user who owns the account. If you’re not aware of this, check out my post below explaining it:
If you’re thinking to yourself “how can I protect against users abusing this in my own applications?” - you’re in luck, because that’s exactly what we’ll be covering here.
Back in November 2019, I gave a lightning talk at the PHPSW meetup highlighting how to avoid a few of the pitfalls I often see people struggle with when they get started with localising web projects.
You can find the slides here: https://slides.com/liamhammett/avoiding-the-pain-of-localisation
You might think you know PHP, but if you dig below the surface you might find it can do more than you knew. Beyond the documented features, there lies a world of tricks, hacks and other techniques that can allow PHP to go a step further.
In this talk we’ll look outside the box at some things PHP provides like references, autoloading and magic methods and explore how using them in an unconventional way can benefit our own code.
“Static constructors” are a concept a lot of object-oriented programming languages support - although, unfortunately, PHP does not.
If you’re not familiar with the concept, a static constructor is just a method the developer can define on a class which can be used to initialise any static properties, or to perform any actions that only need to be performed only once for the given class. The method is only called once as the class is needed.
The C# guide about static constructors is a good resource to see how another language handles these, however we’ll cover the important bits below.
Private constructors are a pattern found in object-oriented programming languages that prevents the class from being instantiated, except by itself.
The first time I saw this pattern in my programming career, I was confused. It wasn’t immediately apparent why such a feature would ever be beneficial in the real world. How are you meant to use the class if it can’t be instantiated? Why even bother defining a constructor at all if it can’t be called?
It turns out there are a handful of uses that private constructors can lend themselves to. Here I’m going to go over a few purposes they serve. The examples are in PHP but should transfer to any language that supports this feature.
Back when I started using PHP properly in the early 5.0 days, it felt like the language was pretty basic. Other languages were making leaps and bounds every year, and as time went on, PHP seemed to have stagnated. The language wasn’t bad, but it wasn’t as good as it could’ve been.
That all changed this decade. PHP has come an awful long way in the last few years and is once again proving that it’s got what it takes to be a programming language people should take seriously, even outside the web. I’m hugely happy with the direction PHP has taken and the amazing work of the core contributors and the entire ecosystem.
That said, there are a handful of things I would love to see PHP implement at some point in the future. These are a few things that I would’ve liked to be able to use every now and again when the circumstances for them come up.
isset() is one of the most important tools at your disposal to validate data in PHP. Like the name implies, it is designed to verify if a variable given to it is set, returning a boolean value based on the result.
However, it has some quirks and behaviours that are very much worth knowing as they can easily catch out even experienced developers.
Let’s take a look through how it behaves and what’s so special about it. Even if you’re a veteran PHP developer, hopefully, you’ll pick up something new here.
PHP is a loosely typed language. It doesn’t care what types you throw around. Unless you want it to care.
The language has come a long way in the last several years to bring in a robust type system, allowing developers to enforce types in both function parameters and what a function’s return value is.
For everything else, there’s docblocks, ugly sanitisation and assertion code, and crossing your fingers to hope your function’s API holds up in practice.
Note: Since writing this post, I came across the
pecl-php-operator extension on GitHub that does exactly what I described in this post, it’s awesome!
What do you do when something goes wrong in your PHP application? Probably throwing an exception, so it can be caught at a higher level and handled appropriately.
What happens when instead of throwing an exception, an
exit(); is executed? Can you catch it?
PHP has a handful of core functions that can accept boolean arguments in the form of constants that have a binary value.
These can be combined together in a single function argument, essentially passing multiple boolean flags in a very compact manner.
They work a bit differently to how most people implement options in their userland functions, so let’s take a look at how they work.