PHP

Does your project use PHPStan? Then you really should be using the bleeding edge config, regardless of what level you are running. It will make transition to the newer version much easier. What is bleeding edge To preserve backwards compatibility as much as possible, new rules, and new settings are delayed until the next major version. For example, using null coalesce on a variable that can not be null will be an error in the next version.

Use a custom services file for your tests, to allow changing dependencies as needed.

Our code base has a lot of code that looks like this: <?php try { $this->doScaryThing(); } catch(Exception $e) { trigger_error("Downgraded: " . get_class($e) . ":" . $e->getMessage(), E_USER_WARNING); } Or sometimes trigger_error is used as a way to log other thigns. This makes it rather difficult to test. Thankfully PHPUnit 8.4 has the expectWarning method, that allows us to check this: <?php public function testItTriggersWarning(): void { $object = new Danger(); $this->expectWarning(); $object->doWarningThing(); } This does mean that the execution stops after the warning is triggered, so we can’t assert anything after that.

PHP is already strictly typed, in the same way that JavaScript is. Not through the language itself, but with the help of tooling. JavaScript achieves this through tools like Typescript. (I use typescript as an example, as that is what i normally use.) Typescript adds a lot of new syntax to tha language, which allows for type checking. The transpiler then simply won’t transpile if there are type errors( depending on your configuration).

The tools a modern PHP developer needs to strive.

When creating a PHP website, there is a good chance that you wish to use a virtual machine. This has many benefits, like managing multiple versions of php, or extensions etc. A lot of projects use vagrant in combination with virtual box. But nobody likes to set up a Vagrantfile every single time. Laravel created homestead, which deals with all the vagrant configuration for you. You can install it in your project with composer install laravel/homestead, and you got it.

What is a clean solution to display a ‘default’ message to the user, when something they try to access isn’t there (anymore)? We could let the our repository throw an exception, catch it somewhere, and then let our controller handle it. Maybe we could return null, and pass that all the way up and add a fall back message for the content in the view somewhere? Why not try a better solution and work with a default object.

A while ago a reddit post showed up, where someone installed version 9.99.99 of paragonie/random_compat. Seeing a package update from 2.* to 9.99.99 may be a bit confusing, but given how autolaoding, polyfills and composer work in php, this is actually quite a clever way of dealing with things. Lets take a look at version constraints, autoloading and composer to see why.

I wrote about infection a while ago, and not too long after that, 0.9.0 was released. Lets look at the new features, and how we can use them in our projects!

In about 5 months PHP 5.6 loses its security support. Which means that in 5 months, PHP loses its current Long Term Support(LTS) version. If you don’t count security only support as LTS, then PHP hasn’t had an LTS for the past 1.5 years. If your website can’t handle PHP 7 or higher, you may start finding it harder to get support for that, with hosting sites like acquia removing php 5.6 support We will look at the advantages, and disadvantages of LTS, and what it means for the PHP ecosystem.