The PHP team is pleased to announce the release of PHP 8.1.0, Beta 3. This is the third beta release, continuing the PHP 8.1 release cycle, the rough outline of which is specified in the PHP Wiki. For source downloads of PHP 8.1.0, Beta 3 please visit the download page. Please carefully test this version and report any issues found in the bug reporting system. Please DO NOT use this version in production, it is an early test version. For more information on the new features and other changes, you can read the NEWS file or the UPGRADING file for a complete list of upgrading notes. These files can also be found in the release archive. The next release will be the first release candidate (RC 1), planned for 2 September 2021. The signatures for the release can be found in the manifest or on the QA site. Thank you for helping us make PHP better.

For many years now, I’ve been using Matthew Weier O’Phinney’s changelog_generator script to generate an easy-to-read list of changes for a given milestone. Time has moved on; the Laminas project now uses Laminas Automatic Releases and Matthew hasn’t updated his script since 2013. Since PHP 8, warnings have started appear, so it’s clear updates were required. While I fully intend to see if I can use Automatic Releases on some projects, I have others where this is unlikely to happen and will continue to use changelog-generator.

Looking into it, I worked out that the warnings were from dependent packages. PHP has changed a bit since 2013. My first idea was to simply update to the latest Laminas versions of the dependencies, but I discovered that the Console and Http components are no longer actively maintained, so new components would be needed. I don’t particuarly want to have to do this all again in a few years time when the replacements that I pick don’t support PHP 8.4 or whatever, so I decided to remove the dependencies completely.

Looking at Console, I quickly realised that only one class was used by changelog-generator: Getopt, which worked fine under PHP 8. So, I copied that one class to src, changed the namespace and called it done. For Http, I wrote a new HttpClient class that only makes GET requests using PHP’s curl functions. I’m reasonably confident that the API to those functions won’t be changing signicantly.

While I was messing around, I also fixed a few bugs so that searching by title will look for closed milestones and it now lists the last 20 milestones if you don’t provide an argument. Just a couple of quality of life features to make make it easier for me to use.

My version is now up on Packagist if you need something like this. However, I strongly recommend looking at Laminas Automatic Releases as that automates all the work required for doing a release. If you just need a formatted list of closed issues though, grab this and see if it works for you.

Thoughts on dependencies

My general view is that if it’s not core to your application, then using a dependent package is the way forward. There’s rarely any benefit from spending time working on something that others have already built and to which you are not adding value. This is particularly true for applications where you are adding new features and have better things to do.

However, sometimes this isn’t the right choice. In this case, I need a very small subset of what a dependent package provides. I took the view that maintaining the dependencies would be more long-term work than writing the small components that I actually needed. Particularly, as this tool is stable.

Sometimes this is the right choice for a component in my big projects too.

Truncated by Planet PHP, read more at the original (another 1866 bytes)

The PHP team is pleased to announce the first beta release of PHP 8.1.0, Beta 2. This continues the PHP 8.1 release cycle, the rough outline of which is specified in the PHP Wiki. For source downloads of PHP 8.1.0, Beta 2 please visit the download page.Please carefully test this version and report any issues found in the bug reporting system.Please DO NOT use this version in production, it is an early test version. For more information on the new features and other changes, you can read the NEWS file, or the UPGRADING file for a complete list of upgrading notes. These files can also be found in the release archive. The next release will be Beta 3, planned for Aug 19 2021.The signatures for the release can be found in the manifest or on the QA site.Thank you for helping us make PHP better.

In this blog, we take a deep dive into container orchestration with Docker and related technologies, as well as provide resources to get you started orchestrating your applications using ZendPHP.

Truncated by Planet PHP, read more at the original (another 13299 bytes)

The PHP team is pleased to announce the first beta release of PHP 8.1.0, Beta 1. This continues the PHP 8.1 release cycle, the rough outline of which is specified in the PHP Wiki. For source downloads of PHP 8.1.0 Beta 1 please visit the download page.Please carefully test this version and report any issues found in the bug reporting system.Please DO NOT use this version in production, it is an early test version. For more information on the new features and other changes, you can read the NEWS file, or the UPGRADING file for a complete list of upgrading notes. These files can also be found in the release archive. The next release will be Beta 2, planned for Aug 5 2021.The signatures for the release can be found in the manifest or on the QA site.Thank you for helping us make PHP better.

In March, news broke that two malicious commits were introduced onto the in-development PHP 8.1 branch by perpetrators pretending to be Rasmus Lerdorf and Nikita Popov. The response by the PHP community to this attack was a shining example of the openness and transparency of the open-source world.
We’re going to take a closer look at the PHP 8.1 story to uncover what lessons there are to be learned on the value of visibility in coding.

One thing that’s quite convenient is to be able to throw an exception with a valid HTTP code set and have that code sent to the client.

For example, you may have:

throw new \RuntimeException("Not Found", 404);

With the standard Slim 4 error handler, this response is sent to the client:

$ curl -i -H "Accept:application/json" http://localhost:8888
HTTP/1.1 500 Internal Server Error
Host: localhost:8888
Content-type: application/json { "message": "Slim Application Error"
}

Ideally we want the status code to be 404.

Option 1: Use an HttpException

The simplest solution is to use one of Slim’s HttpException classes:

use Slim\Exception\HttpNotFoundException; ... throw new HttpNotFoundException($request);

This is only useful in a Request Handler as you need a Request object, but the expected response is sent to the client:

$ curl -i -H "Accept:application/json" http://localhost:8888
HTTP/1.1 404 Not Found
Host: localhost:8888
Content-type: application/json { "message": "404 Not Found"
}

Simple and easy!

Option 2: Override the ErrorMiddleware

There are situation when you can’t simply replace the exception thrown. For example, you’re updating an application from Slim 3 and you have hundreds of customised exceptions already throwing, or you throw from a class that doesn’t have a Request object instance available.

In these cases, the easiest solution is to extend the Slim ErrorMiddleware to wrap the exception in an

HttpException

and then the standard error handling and rendering will “just work”.

I’m feeling a little lazy, so let’s use an anonymous class to do replace the call to $app->addErrorMiddleware():

$container = $app->getContainer(); $logger = $container->has(LoggerInterface::class) ?$container->get(LoggerInterface::class) : null; $errorMiddleware = new class ( callableResolver: $app->getCallableResolver(), responseFactory: $app->getResponseFactory(), displayErrorDetails: false, logErrors: true, logErrorDetails: true, logger: $logger ) extends \Slim\Middleware\ErrorMiddleware { public function handleException( ServerRequestInterface $request, Throwable $exception ): \Psr\Http\Message\ResponseInterface { // determine that this exception should be wrapped. I'm checking for code between 400 & 599 if ($exception->getCode() >= 400 && $exception->getCode() < 600) { // wrap the exception in an HttpException $exception = new \Slim\Exception\HttpException( $request, $exception->getMessage(), $exception->getCode(), $exception ); $exception->setTitle($exception->getMessage()); } return parent::handleException($request, $exception); } }; $app->addMiddleware($errorMiddleware);

Behind the scenes of $app->addErrorMiddleware(), the \Slim\Middleware\ErrorMiddleware is constructed and then added to the middleware stack. We replicate that we an anonymous class that overrides handleException() to wrap the thrown exception if required.

Looking at the code in detail

There’s quite a lot going on here, so let’s break it down into parts.

$container = $app->getContainer(); $logger = $container->has(LoggerInterface::class) ?$container->get(LoggerInterface::class) : null; $errorMiddleware = new class ( callableResolver: $app->getCallableResolver(), responseFactory: $app->getResponseFactory(), displayErrorDetails: false, logErrors: true, logErrorDetails: true, logger: $logger ) extends \Slim\Middleware\ErrorMiddleware {

The constructor to \Slim\Middleware\ErrorMiddleware takes 6 parameters, so when we instantiate, we have to pass them all in though it’s not unusual for the $logger parameter to be left off in the call to $app->addErrorMiddleware(). The easiest way to get a logger instance if there is one, is to grab it from the container where it should be registered under the \Psr\Log\LoggerInterface key which is imported into the file with a use statement.

I’ve used PHP 8’s named arguments as this constructor takes three booleans and it’s easier to remember what they do if they are label

Truncated by Planet PHP, read more at the original (another 2865 bytes)

Truncated by Planet PHP, read more at the original (another 20645 bytes)