Christian WeiskeLaravel: Finding the route name (20.9.2020, 08:38 UTC)

Recently at work I had to analyze a problem in a Laravel application that I was not familiar with. The problem: When calling a specific URL, it wrongly redirected to another URL.

The route that I expected to be called was not, and routes/web.php was huge; too large to find the matching route quickly.

The solution was to adjust public/index.php and add the following line before the response was sent back to the browser:

$response->header('X-Route', Route::currentRouteName());

Now I could look at the redirect's HTTP headers to find the route that had been used:

$ curl -I
HTTP/1.1 302 Found
Date: Wed, 16 Sep 2020 11:45:26 GMT
Server: nginx/1.10.3 (Ubuntu)
Content-Type: text/html; charset=UTF-8
Cache-Control: no-cache, private
X-Route: en_product_detail
Derick RethansPHP Internals News: Episode 68: Observer API (17.9.2020, 08:31 UTC)

PHP Internals News: Episode 68: Observer API

In this episode of "PHP Internals News" I chat with Levi Morrison (Twitter, GitHub) and Sammy Kaye Powers (Twitter, GitHub, Website) about the new Observer API.

The RSS feed for this podcast is, you can download this episode's MP3 file, and it's available on Spotify and iTunes. There is a dedicated website:


Derick Rethans 0:15

Hi, I'm Derick, and this is PHP internals news, a weekly podcast dedicated to demystifying the development of the PHP language. This is Episode 68. Today I'm talking with Levi Morrison, and Sammy Powers, about something called the observer API, which is something that is new in PHP eight zero. Now, we've already passed feature freeze, of course, but this snuck in at the last possible moment. What this is observer API going to solve?

Levi Morrison 0:44

the observer API is primarily aimed at recording function calls in some way so it can also handle include, and require, and eval, and potentially in the future other things, but this is important because it allows you to write tools that automatically observe, hence the name, when a function begins or ends, or both.

Derick Rethans 1:12

What would you use that for?

Levi Morrison 1:13

So as an example, Xdebug can use this to know when functions are entered or or left, and other tools such as application performance monitoring, or APM tools like data dog, New Relic, tideways, instana so on, they can use these hooks too.

Derick Rethans 1:38

From what I understand that is the point you're coming in from, because we haven't actually done a proper introduction, which I forgot about. I've been out of this for doing this for a while. So both you and Sammy you work for data dog and work on their APM tool, which made you start doing this, I suppose.

Sammy Kaye Powers 1:54

Yeah, absolutely. One of the pain points of tying into the engine to to monitor things is that the hooks are insufficient in a number of different ways. The primary way that you would do function call interception is with a little hook called zend_execute_ex and this will hook all userland function calls. The problem is, it has an inherent stack bomb in it where if, depending on your stack size settings you, you're going to blow up your stack. At some point if you have a very very deeply deep call stack in PHP, PHP, technically has a virtually unlimited call stack. But when you use zend_execute_ex, it actually does limit your stack size to whatever your settings are your ulimit set stack size. One of the issues that this solves is that stack overflow issue that you can run into when intercepting userland calls but the other thing that it solves is the potential JIT issues that are coming with PHP eight, where the optimizations that it does could potentially optimize out a call to zend_execute_ex where a profiling or APM tracing kind of extension would not be able to enter set that call, because of the JIT. The Observer API enables to solve multiple issues with this. Not only that, there's more. there's more features to this thing, because zend_execute_ex by default will intercept all userland function calls, and you have no choice but to intercept every single call, whereas, this API is designed to also allow you to choose which function calls specifically you want to intercept, so there is on the very first call of a function call. And it'll basically send in the zend function. This is a little bit of a point we've been kind of going back and forth on what we actually send in on the initialis

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

PHP: Hypertext PreprocessorPHP 8.0.0 Beta 4 available for testing (17.9.2020, 00:00 UTC)
The PHP team is pleased to announce the seventh testing release of PHP 8.0.0, Beta 4. This point in the release cycle would normally be RC1, however we're still finalizing development of the JIT and squaring away named arguments, so we've opted for an extra beta release with plans to start the RC cycle in two weeks. At this time, we're not planning to adjust the GA date, however this may change during the course of the RC cycle. The updated release schedule can, as always, be found on the PHP Wiki. For source downloads of PHP 8.0.0 Beta 4 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 Release Candidate 1, planned for Oct 1 2020.The signatures for the release can be found in the manifest or on the QA site.Thank you for helping us make PHP better.
platform.shPHP 8.0 feature focus: <span>type improvements</span> (17.9.2020, 00:00 UTC)
PHP 8 is almost here, and with it a host of improvements, new functionality, and overall polish to make the web’s favorite server-side language even better. In this weekly series, leading up to the final release by the end of the year, we’ll cover what you need to know about PHP 8. It’s an exciting release, and we’re not even going to be covering all of it! There’s just that much going on.
Voices of the ElePHPantInterview with Dave Delaney (15.9.2020, 11:30 UTC) Link
Remi ColletPHP on the road to the 8.0.0 release (12.9.2020, 06:28 UTC)

Version 8.0.0 Beta 3 is released. It's now enter the stabilisation phase for the developers, and the test phase for the users.

RPM are available in the remi-php80 repository for Fedora 31 and Enterprise Linux 7 (RHEL, CentOS), or in the php:remi-8.0 stream,  and as Software Collection in the remi-safe repository (or remi for Fedora)


emblem-important-4-24.pngThe repository provides development versions which are not suitable for production usage.

Also read: PHP 8.0 as Software Collection

emblem-notice-24.pngInstallation : read the Repository configuration and choose installation mode.

Replacement of default PHP by version 8.0 installation, module way (simplest way on Fedora and EL-8):

dnf module disable php
dnf module install php:remi-8.0
dnf update

Replacement of default PHP by version 8.0 installation, repository way (simplest way on EL-7):

yum-config-manager --enable remi-php80
yum update php\*

Parallel installation of version 8.0 as Software Collection (recommended for tests):

yum install php80

emblem-important-2-24.pngTo be noticed :

  • EL8 rpm are build using RHEL-8.2
  • EL7 rpm are build using RHEL-7.8
  • lot of extensions are also available, see the PECL extension RPM status page
  • follow the comments on this page for update until final version.

emblem-notice-24.pngInformation, read:

Base packages (php)

Software Collections (php74)

Cees-Jan KiewietBuilding the next generation react/http PSR-15 adapter (11.9.2020, 00:00 UTC)

Two and a half years ago I wrote how to use RecoilPHP to create a PSR-15 middleware adapter for react/http using coroutines, monkey patching, and autoloader hijacking. Today there is a followup on that without any coroutines, monkey patching, and autoloader hijacking. But using ext-parallel instead, react-parallel/psr-15-adapter was created.

Needle Threads Sewing Thread Eye Of A Needle

Evert PotKetting v6: Using Hypermedia APIs with React (9.9.2020, 20:30 UTC)

We just released Ketting 6. This is the accumulation of about a year of learning on how to better integrate REST APIs with frontend frameworks, in particular React.

It’s packed with new features such as local state management, new caching strategies, (client-side) middleware support and change events. It’s also the first release that has some larger BC breaks to make this all work.

Releasing Ketting 6 is a big personal milestone for me, and I’m really excited to unleash it to the world and see what people do with. A big thank you to all the people that beta tested this in the last several months!

What’s Ketting?

In short: Ketting is a generic REST client for Javascript. You can use it for pushing JSON objects via HTTP, but the richer your API is in terms of best practices and standard formats, the more it can automatically do for you.

It has support for Hypermedia formats such as HAL, Siren, Collection+JSON, JSON:API and can even understand and follow links from HTML.

It’s often said that REST (and Hypermedia APIs) is lacking a good generic client. GraphQL has a lot of advantages, but a major one is tooling. Ketting aims to close that gap.

More information can be found on Github.

React support in Ketting 6

Ketting now has a separate react-ketting package that provides React bindings to Ketting. These bindings should look very familiar if you’ve used Apollo Client in the past.

Lets dive into an example:

Lets assume you have a REST api that has an ‘article’ endpoint. This returns something like:

  "title": "Hello world",
  "body": "..."

This article is retrieved with GET, and updated with PUT, this is how you would display it:

import { useResource } from 'react-ketting';

export function Article() {

  const { loading, error, data } = useResource('https://api.example/article/5');

  if (loading) {
    return <div>Loading...</div>;

  if (error) {
    return <div class="error">{error.message}</div>;

  return <article>

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

Voices of the ElePHPantInterview with Olatunbosun Egberinde (9.9.2020, 11:30 UTC) Link
Matthias NobackA simple recipe for framework decoupling (9.9.2020, 10:30 UTC)

If you want to write applications that are maintainable in the long run, you have to decouple from your framework, ORM, HTTP client, etc. because your application will outlive all of them.

Three simple rules

To accomplish framework decoupling you only have to follow these simple rules:

  1. All services should get all their dependencies and configuration values injected as constructor arguments. When a dependency uses IO, you have to introduce an abstraction for it.
  2. Other types of objects shouldn't have service responsibilities.
  3. Contextual information should always be passed as method arguments.


Rule 1

Following rule 1 ensures that you'll never fetch a service ad hoc, e.g. by using Container::get(UserRepository::class). This is needed for framework decoupling because the global static facility that returns the service for you is by definition framework-specific. The same is true for fetching configuration values (e.g. Config::get('email.default_sender')).

Sometimes a dependency uses IO, that is, it talks to the database, the filesystem, etc. In that case you should introduce an abstraction for the dependency. If you depend on a concrete class, that class will work only with the specific library or framework that you're working with right now, so in order to stay decoupled you should use your own abstraction, combined with an implementation that uses your current library/framework.

Rule 2

Aside from services there will be several other types of objects like entities, value objects, domain events, and data transfer objects, all of which don't have service responsibilities. None of them should have service responsibilities, because that means they will either invoke services via some global static facility, or they need special framework/ORM-specific setup meaning they can't be used in isolation and won't survive a major framework upgrade or switch. An example of an object that doesn't follow rule 2 is an active record model, which may look like an entity, but is able to save itself, which is in fact a service responsibility.

Rule 3

Contextual information is usually derived from the current web request or the user's session, e.g. the ID of the user who is currently logged in. Instead of fetching this data whenever you need it (like Auth::getUser()->getId()) you should pass it from method to method as a regular argument.

Combined, rule 1, 2, and 3 ensure that for every method it's totally clear what it's doing, what data it needs, and on what service dependencies it relies to do its work. On top of that, none of the dependencies or method arguments will be framework or library-specific, meaning your application code will be effectively be decoupled from the framework.


If you ask me, these rules are very simple indeed, and they don't require a lot of extra work compared to tightly coupling everything to your project's current set of installed packages. So, why not follow them if you know that your project should still be up-to-date with current standards 3 years from now?

P.S. Following these rules gives you much more than framework decoupling: everything becomes testable in isolation, the tests are fully deterministic and therefore very stable, and they are really fast to run.

LinksRSS 0.92   RDF 1.
Atom Feed   100% Popoon
PHP5 powered   PEAR
ButtonsPlanet PHP   Planet PHP
Planet PHP