Wat is nieuw in PHP 7.4? (Functies, afschrijvingen, snelheid)

PHP 7.4 is de meest recente (minor) release en is voor algemene beschikbaarheid uitgegeven op 28 november 2019. Hoog tijd om eens goed te kijken naar een aantal van de meest interessante toevoegingen en nieuwe features die PHP sneller en betrouwbaar maken.

Update: PHP 8.1 (officiële release) is nu beschikbaar voor alle Kinsta klanten. PHP 7.4 wordt niet langer ondersteund door Kinsta. Houd er rekening mee dat we PHP versies 8.1, 8.2 en 8.3 ondersteunen.

PHP 7.4 geeft een enorme boost in performance en leesbaarheid van code en wordt beschouwd als een tussenstap naar PHP 8. Voor deze laatste versie zijn de verwachtingen hooggespannen, helemaal wat betreft performance, omdat de opname van JIT al is goedgekeurd.

Hoe dan ook, vandaag bespreken we meest interessante functies en veranderingen die we kunnen verwachten van PHP 7.4. Dit waren de belangrijkste datums voor versie 7.4:

• 6 juni 2019: PHP 7.4 Alpha 1
• 18 juli: PHP 7.4 Beta 1 – Feature freeze
• 28 november 2019: PHP 7.4 GA Release

De volledige lijst met features en toevoegingen kan je vinden op de officiële RFC-pagina vinden.

Wat is nieuw in PHP in PHP 7.4?

In dit artikel bespreken we een aantal veranderingen en features die aan de taal worden toegevoegd wanneer de definitieve versie van PHP 7.4 wordt uitgebracht:

Vergeet array_merge: PHP 7.4 introduceert Spread Operator in Array Expression

Argument unpacking is een syntax die sinds PHP 5.6 gebruikt kan worden om arrays en Traversables  uit te pakken in argumentlijsten. Om een array of een Traversable uit te pakken, moet deze worden voorafgegaan door … (3 punten), zoals je in het onderstaande voorbeeld kan zien:

function test(...$args) { var_dump($args); }
test(1, 2, 3);

In PHP 7.4 RFC staat het voorstel om deze feature uit te breiden naar array definitions

$arr = [...$args];

Het eerste voordeel van het gebruik van Spread Operator in array expression heeft te maken met de performance. Dit is wat het RFC-document vermeldt:

Spread operator zou voor betere prestaties zorgen dan array_merge. Dat is niet alleen omdat spread operator een taalstructuur is en array_merge een functie is, maar ook omdat de optimalisatie van compilatietijd kan worden gebruikt voor constant arrays.

Een belangrijk voordeel van Spread operator is dat deze alle verplaatsbare objecten ondersteunt, terwijl de array_merge functie alleen arrays ondersteunt.

Hier is een voorbeeld van argument unpacking in array expression:

$parts = ['apple', 'pear'];
$fruits = ['banana', 'orange', ...$parts, 'watermelon'];
var_dump($fruits);

Als je deze code uitvoert met PHP 7.3 of lager, dan krijg je een PHP Parse-error:

Parse error: syntax error, unexpected '...' (T_ELLIPSIS), expecting ']' in /app/spread-operator.php on line 3

In PHP 7.4 krijg je echter een array terug:

array(5) {
	[0]=>
	string(6) "banana"
	[1]=>
	string(6) "orange"
	[2]=>
	string(5) "apple"
	[3]=>
	string(4) "pear"
	[4]=>
	string(10) "watermelon"
}

De RFC meldt verder dat we deze array ook meerdere keren kunnen uitbreiden. We kunnen de Spread Operator-syntax overal binnen de array gebruiken, omdat normale elementen vóór of na de spread operator kunnen worden toegevoegd. Dus de volgende code werkt zoals we kunnen verwachten:

$arr1 = [1, 2, 3];
$arr2 = [4, 5, 6];
$arr3 = [...$arr1, ...$arr2];
$arr4 = [...$arr1, ...$arr3, 7, 8, 9];

Het is ook mogelijk om een array, die door een functie is geretourneerd, direct uit te pakken in een nieuwe array:

function buildArray(){
	return ['red', 'green', 'blue'];
}
$arr1 = [...buildArray(), 'pink', 'violet', 'yellow'];

In PHP 7.4 krijg je dan de volgende array:

array(6) {
	[0]=>
	string(3) "red"
	[1]=>
	string(5) "green"
	[2]=>
	string(4) "blue"
	[3]=>
	string(4) "pink"
	[4]=>
	string(6) "violet"
	[5]=>
	string(6) "yellow"
}

We kunnen ook de generator syntax gebruiken:

function generator() {
	for ($i = 3; $i <= 5; $i++) {
		yield $i;
	}
}
$arr1 = [0, 1, 2, ...generator()];

Echter, het is niet toegestaan om arrays uit de pakken die zijn doorgegeven door een verwijzing. In het volgende voorbeeld leg ik het uit:

$arr1 = ['red', 'green', 'blue'];
$arr2 = [...&$arr1];

Als we nu een array willen uitpakken door te verwijzen, dan genereert PHP de volgende Parse-error:

Parse error: syntax error, unexpected '&' in /app/spread-operator.php on line 3

Als de elementen van de eerste array door verwijzing zijn opgeslagen, worden ze ook door verwijzing in de tweede array opgeslagen. Hier is een voorbeeld:

$arr0 = 'red';
$arr1 = [&$arr0, 'green', 'blue'];
$arr2 = ['white', ...$arr1, 'black'];

Dit is wat we krijgen met PHP 7.4:

array(5) {
	[0]=>
	string(5) "white"
	[1]=>
	&string(3) "red"
	[2]=>
	string(5) "green"
	[3]=>
	string(4) "blue"
	[4]=>
	string(5) "black"
}

Het voorstel om Spread operator toe te voegen was goedgekeurd met 43 stemmen voor en 1 stem tegen.

Arrow Functions 2.0 (Short Closures)

In PHP worden anonieme functies vaak beschouwd als moeilijk te begrijpen en lastig in te voeren en te onderhouden. Deze RFC stelt voor om de kortere syntax van de arrow functies (of short closures) te introduceren. Hiermee zou je je PHP-code flink kunnen opschonen.

In het volgende voorbeeld leg ik het uit:

function cube($n){
	return ($n * $n * $n);
}
$a = [1, 2, 3, 4, 5];
$b = array_map('cube', $a);
print_r($b);

PHP 7.4 maakt het gebruik van een meer beknopte syntax mogelijk en de bovenstaande functie kan als volgt worden herschreven:

$a = [1, 2, 3, 4, 5];
$b = array_map(fn($n) => $n * $n * $n, $a);
print_r($b);

Momenteel kunnen anonieme functies (closures) de variabelen die zijn gedefinieerd in de parent scope inheritten. Dit doen ze met behulp van de use taalconstructie, zoals je hieronder kan zien:

$factor = 10;
$calc = function($num) use($factor){
	return $num * $factor;
};

Echter, met PHP 7.4 worden de variabelen die zijn gedefinieerd in de parent scope, impliciet vastgelegd op waarde (implicit by-value scope binding). We kunnen dus de hele functie die je boven zag, als volgt schrijven:

$factor = 10;
$calc = fn($num) => $num * $factor;

De variabele die is gedefinieerd in de parent scope kan gebruikt worden in de arrow functie, alsof we gebruik maken van use($var) en het is niet mogelijk om een variabele van de parent scope te wijzigen.

De nieuwe syntax is een grote verbetering van de taal, omdat de code beter leesbaar en te onderhouden is. We kunnen ook parameter en return types gebruiken, standaard waarden, argumentlijsten met variabele lengtes (variadic functions), we kunnen pass en return door verwijzing, etc. Ten slotte kunnen short closures ook gebruikt worden in class methodes en maken ze net als normale closures gebruik van de $this variabele.

Deze RFC is goedgekeurd met 51 tegen 8 stemmen en kunnen deze daarom verwachten in de lijst met toevoegingen van PHP 7.4.

Null Coalescing Assignment Operator

De coalesce operator (??), toegevoegd met PHP 7, komt van pas wanneer we een ternary operator moeten gebruiken in combinatie met isset(). Het retourneert de eerste operand, mits deze bestaat en niet NULL is. Anders wordt de tweede operand geretourneerd. Hier is een voorbeeld:

$username = $_GET['user'] ?? 'nobody';

Wat deze code doet is redelijk eenvoudig: hij haalt de aangevraagde parameter op en stelt een standaardwaarde in als deze niet bestaat. De bovenstaande lijn met code is vrij eenvoudig, maar wat nou als we het voorbeeld van de RFC nemen, een die een veel meer variabele namen heeft?

$this->request->data['comments']['user_id'] = $this->request->data['comments']['user_id'] ?? 'value';

Op de lange termijn is deze lijn met code lastig te onderhouden. Met de introductie van de null coalescing assignment operator  (??=) wil deze RFC  het voor ontwikkelaars mogelijk maken om intuïtiever code te schrijven. Dus in plaats van de bovenstaande code te schrijven, kunnen we nu het volgende schrijven:

$this->request->data['comments']['user_id'] ??= 'value';

Als de waarde van de linker parameter null is, dan wordt de waarde van de rechter parameter gebruikt.
Let wel op: de coalesce operator is een comparison operator, ??= is een assignment operator.

Dit voorstel heeft het gehaald met 37 stemmen voor en 4 stemmen tegen.

Typed Properties 2.0

Argument type declarations, ook wel type hints genoemd, maken het mogelijk om het type van een variabele te specificeren, die naar verwachting wordt doorgegeven aan een functie of een class method. Type hints bestaan al sinds PHP 5 en sinds PHP 7.2 is het ook mogelijk om deze te gebruiken samen met het object data type. Type hints krijgen met PHP 7.4 een enorme boost door de support voor first-class property type declarations mogelijk te maken. Hieronder een erg simpel voorbeeld:

class User {
	public int $id;
	public string $name;
}

Alle typen worden ondersteund, met uitzondering van void en callable:

public int $scalarType;
protected ClassName $classType;
private ?ClassName $nullableClassType;

De RFC legt de reden uit waarom void en callable niet worden ondersteund:

Het void type wordt niet ondersteund, omdat dit niet zinvol is en een onduidelijke semantiek heeft.

Het callable type wordt niet ondersteund, omdat zijn gedrag contextafhankelijk is.

We kunnen dus veilig gebruiken: bool, int, float, string, array, object, iterable, self, parent, de naam van een class of interface, en nullable types (?type).

Types kunnen gebruikt worden op statische properties:

public static iterable $staticProp;

Ook is het mogelijk ze te gebruiken met de var notatie.

var bool $flag;

Het is mogelijk om standaard property values in te stellen, die natuurlijk overeen moeten komen met het gedeclareerde property type, maar alleen nullable properties kunnen een standaard null waarde hebben:

public string $str = "foo";
public ?string $nullableStr = null;

Hetzelfde type is van toepassing op alle eigenschappen binnen één enkele declaratie:

public float $x, $y;

Wat gebeurt er als je een fout maakt in het property type? Bekijk de volgende code:

class User {
	public int $id;
	public string $name;
}

$user = new User;
$user->id = 10;
$user->name = [];

In de code hierboven hebben we een string property type vastgelegd, maar een array als property value ingesteld. In een dergelijk scenario krijgen we de volgende Fatal error:

Fatal error: Uncaught TypeError: Typed property User::$name must be string, array used in /app/types.php:9

Deze RFC is goedgekeurd met 70 tegen 1 stemmen.

Weak References

Met deze RFC introduceert PHP 7.4 de class WeakReference, waarmee programmeurs een verwijzing naar een object kunnen behouden zonder dat die verhindert het object zelf wordt vernietigd.

Momenteel ondersteunt PHP Weak References door een extensie als pecl-weakref te gebruiken. De nieuwe API anders dan de gedocumenteerde WeakRef class.

Hier is een voorbeeld van de auteur van dit voorstel, Nikita Popov:

$object = new stdClass;
$weakRef = WeakReference::create($object);

var_dump($weakRef->get());
unset($object);
var_dump($weakRef->get());

De eerste var_dump print object(stdClass)#1 (0) {}, terwijl de tweede var_dump zorgt voor NULL,  omdat het object waarnaar verwezen wordt, is verwijderd.

Deze RFC is aangenomen met 28 tegen 5 stemmen.

Covariant Returns en Contravariant Parameters

Variance is een eigenschap van class hiërarchieën die beschrijven hoe de types van een type constructor subtypen beïnvloeden. Over het algemeen kan een type constructor het volgende zijn:

• Invariant: als het type van het super-type het type van het sub-type beperkt.
• Covariant: als de volgorde van typen wordt behouden (types worden van meer specifiek naar meer generiek gesorteerd).
• Contravariant: als het de volgorde omkeert (types worden geordend van meer generiek naar meer specifiek).

Momenteel heeft PHP vooral invariant parameters en return types, met enkele uitzonderingen. Deze RFC stelt voor om ook covariance en contravariance toe te staan op parameter types en return types, waarbij ze ook een aantal voorbeelden geven.

Hier is een voorbeeld van covariant return type:

interface Factory {
	function make(): object;
}

class UserFactory implements Factory {
	function make(): User;
}

En hier is een voorbeeld van contravariant parameter type:

interface Concatable {
	function concat(Iterator $input); 
}
 
class Collection implements Concatable {
	// accepts all iterables, not just Iterator
	function concat(iterable $input) {/* . . . */}
}

Lees de RFC voor een nadere beschouwing van covariance en contravariance in PHP 7.4.

Deze RFC is aangenomen met 39 tegen 1 stemmen.

Preloading

Het voorstel van Dmitry Stogov is een van onze favorieten, omdat het voor een aanzienlijke performanceboost zal zorgen. Preloading is het proces van het laden van bibliotheken en frameworks in de OPCache bij module-initialisatie (lees hier meer over de PHP lifecycle)

Dit is hoe preloading werkt – in de woorden van Dmitry:

Bij het opstarten van de server – voordat de eerste applicatiecode wordt uitgevoerd – kunnen we een bepaalde reeks PHP-bestanden in het geheugen laden – en de inhoud ervan “permanent beschikbaar” maken voor alle volgende aanvragen die door die server worden geleverd. Alle functies en classes die in deze bestanden zijn gedefinieerd, zijn direct beschikbaar voor verzoeken, precies zoals interne entiteiten.

Deze bestanden worden bij het opstarten van de server geladen, worden nog vóór de eerste applicatie uitgevoerd en blijven beschikbaar voor elk toekomstig verzoek. Voor prestaties is dit geweldig.

Preloading wordt beheerd door een specifieke php.ini richtlijn: opcache.preload. Deze richtlijn specificeert een PHP-script dat moet worden gecompileerd en uitgevoerd bij het opstarten van de server. Dit bestand kan ook worden gebruikt om extra bestanden te preloaden, door ze toe te voegen of via de functie opcache_compile_file () (lees meer in de PHP-documentatie).

Er is echter wel een nadeel. Deze wordt ook duidelijk vermeld in de RFC:

De voorgeladen bestanden blijven voor altijd in het opcache-geheugen opgeslagen. Het wijzigen van hun bijbehorende bronbestanden zal geen effect hebben zonder het opnieuw opstarten van de server.

Alle functies die zijn gedefinieerd in vooraf geladen bestanden worden echter permanent geladen in PHP function en class tables en blijven beschikbaar voor elk toekomstig verzoek. Dit zal ongetwijfeld leiden tot significante prestatieverbeteringen, zelfs al zijn deze verbetering aanzienlijk variabel.

Je kan in de officiële Preloading RFC-pagina meer lezen over de beperkingen en uitzonderingen van preloading.

Nieuwe aangepaste Object Serialization Mechanism (SPL)

Er is nog een ander voorstel van Nikita Popov die met een overweldigende meerderheid is aangenomen.

Momenteel hebben we twee verschillende mechanismen voor aangepaste serialisatie van objecten in PHP:

• De __sleep() and __wakeup() magic methods
• De Serializable interface

Volgens Nikita kennen beide opties problemen die leiden tot complexe en onbetrouwbare code. Je kan meer lezen over dit onderwerp in het RFC. In dit geval wil ik alleen vermelden dat het nieuwe serialisatiemechanisme deze problemen zou moeten voorkomen door twee nieuwe magic methods aan te bieden die de twee bestaande mechanismen combineren: __serialize() en __unserialize().

Dit voorstel werd aangenomen met 20 tegen 7 stemmen.

Afschaffingen

De volgende functies/functionaliteiten worden afgeschreven in PHP 7.4. Raadpleeg de PHP 7.4 Upgrade Notes voor een uitgebreidere lijst met afschrijvingen.

De precedence van de concatenation operator wijzigen

Momenteel zijn in PHP de “+” en “-” arithmetic operators en kent de “.” string operator dezelfde prioriteit  (lees hier meer over Operator Precedence).

Bekijk de volgende regels eens:

echo "sum: " . $a + $b;

In PHP 7.3 geeft deze code de volgende waarschuwing:

Warning: A non-numeric value encountered in /app/types.php on line 4

Dit omdat de aaneenschakeling van links naar rechts wordt geëvalueerd. In principe had je dus net zo goed de volgende code kunnen schrijven:

echo ("sum: " . $a) + $b;

Deze EFC stelt voor om de voorrang van operatoren te wijzingen, waardoor “.” een lagere voorrang heeft dan de “+” en “-” operatoren, zodat toevoegingen en aftrekkingen altijd uitgevoerd worden vóór de tekenreeksaaneenschakeling. Die regel code moet gelijk zijn aan het volgende:

echo "sum: " . ($a + $b);

Dit is een voorstel in twee stappen:

• Vanaf versie 7.4 stuurt PHP een afschaffingsnotificatie wanneer een unparanthesized expression wordt aangetroffen met “+”, “-” en “.”.
• De daadwerkelijke verandering in prioriteit volgt vanaf PHP 8.

Beide voorstellen zijn met een ruime meerderheid aangenomen.

Afschaffing van de left-associative ternaire operator

In PHP is de ternaire operator, in tegenstelling tot veel andere talen, links-associatief. Volgens Nikita Popof kan dit verwarrend zijn voor programmeurs die tussen verschillende talen schakelen.

Momenteel is in PHP de volgende code correct:

$b = $a == 1 ? 'one' : $a == 2 ? 'two' : $a == 3 ? 'three' : 'other';

Dit wordt geïnterpreteerd als:

$b = (($a == 1 ? 'one' : $a == 2) ? 'two' : $a == 3) ? 'three' : 'other';

En dit kan leiden tot foutmeldingen, omdat het net doet wat we willen dat het doet. Deze RFC stelt voor om het gebruik van linkse associativiteit voor ternaire operatoren af te schaffen en ontwikkelaars te dwingen om haakjes te gebruiken.

Ook dit is een voorstel in twee stappen:

• Vanaf PHP 7.4 zullen ternaries zonder expliciet gebruik van haakjes een afschaffingsnotificatie ontvangen.
• Vanaf PHP 8.0 zal er een runtime-fout optreden.

Dit voorstel heeft het gehaald met 35 stemmen voor en 10 stemmen tegen.

Wat betekent PHP 7.4 voor WordPress-gebruikers?

PHP is de meest gebruikte server-side programmeertaal op het web. Volgens W3Techs gebruikt 78,9% van alle website PHP – gemeten op 2 december 2019 en op sites waarvan ze de programmeertaal van de server konden vaststellen.

Helaas gebruikt nog steeds 44,0% van alle websites PHP 5 (waarvan de server-side programmeertaal bekend is). Als je het aantal gebruikers toevoegt dat nog steeds PHP 7.0 en 7.1 gebruikt, blijkt dat een grote meerderheid van websites niet-ondersteunde versies van PHP gebruikt.

Volgens de officiële WordPress Stats-pagina gebruikt maar liefst 64% van alle WordPress-websites niet-ondersteunde PHP-versies. Slechts iets meer dan 13% gebruikt PHP 7.3. En de nieuwste versie, PHP 7.4, heeft nog niet eens een verschijning gemaakt. Je ziet dat een grote meerderheid van de gebruikers, meer dan 23%, nog steeds op PHP 5.6. loopt.

We raden je ten zeerste aan om je host te vragen om een ondersteunde versie van PHP, bij voorkeur volgens de officiële vereisten van WordPress. Op moment van schrijven, mei 2019, vereist WordPress:

• PHP-versie 7.3 of hoger.
• MySQL versie 5.6 of hoger OF MariaDB versie 10.1 of hoger.
• HTTPS-ondersteuning

PHP 7 prestaties

Uit het oogpunt van performance zijn bovenstaande cijfers voornamelijk ontmoedigend, simpelweg omdat PHP 7 aanzienlijk sneller is. Dit zeggen de statistieken:

• Officiële PHP-benchmarks laten zien dat PHP 7 het systeem in staat stelt om tweemaal zoveel verzoeken per seconde uit te voeren in vergelijking met de PHP 5.6, met bijna de helft van de latency.
• Christian Vigh publiceerde ook een PHP-prestatievergelijking waarin hij ontdekte dat PHP 5.2 400% langzamer was dan PHP 7.
• Andrei Avram zag snellere uitvoeringstijden en minder geheugengebruik in PHP 7.4 verzen die van PHP 7.3
• Phoronix heeft een aantal vroege benchmarktests uitgevoerd met PHP 7.4 Alpha en concludeerde dat deze versie iets sneller was dan PHP 7.3.

We hebben onze eigen PHP-prestatiebenchmarks met PHP 7.3 uitgevoerd. We zagen dat WordPress 5.0 op PHP 7.3 bijna drie keer zoveel transacties (verzoeken) per seconde kon uitvoeren als PHP 5.6. We zullen binnenkort PHP 7.4 benchmarks vrijgeven!

• WordPress 5.0 PHP 5.6 benchmark: 91,64 req/sec
• WordPress 5.0 PHP 7.0 benchmarkresultaten: 206,71 req/sec
• WordPress 5.0 PHP 7.1 benchmarkresultaten: 210,98 req/sec
• WordPress 5.0 PHP 7.2 benchmarkresultaten: 229,18 req/sec
• WordPress 5.0 PHP 7.3 benchmarkresultaten: 253,20 req/sec  🏆

In sommige gevallen valt het traag bijwerken van PHP te wijten aan het moeten testen van de compatibiliteit met externe plugins   en thema’s, zodat deze goed blijven functioneren.  Echter, in veel gevallen is het   simpelweg een kwestie van er nog niet aan toegekomen zijn.

Checken welke PHP-versie jij hebt

Weet je niet zeker welke PHP-versie jij gebruikt? Het makkelijkste is om hiervoor een tool als   Pingdom of   Google Chrome Devtools te gebruiken. De eerste HTTP-requestheader   laat je normaal gesproken de PHP-versie zien.

Hierbij is het wel belangrijk dat de host geen wijzigingen heeft aangebracht in de waardes van de header X-Powered-By. Veel doen dit echter om veiligheidsredenen (inclusief Kinsta). Als dit het geval is, wordt je PHP-versie mogelijk niet weergegeven. In dat geval is er een nieuwe Site Health-tool die je kan gebruiken als je WordPress 5.2 of hoger gebruikt. Ga naar “Tools” → “Site Health” → “Info” en onder de sectie “Server” vindt je de PHP-versie van jouw server.

Als alternatief kan je ook een gratis plugin installeren, zoals Version Info, die je de basisinformatie van je server laat zien in de footer van het WordPress-beheerdersdashboard. Een paar andere manieren om achter de PHP-versie van jouw server te komen, zijn onder andere het uploaden van een bestand via FTP of simpelweg contact opnemen met je host en het vragen.

Updaten naar PHP 7.4

De definitieve versie van PHP 7.4 is nu beschikbaar binnen Kinsta. Als alternatief kan je je WordPress site ook lokaal testen of je scripts controleren in een omgeving als Docker, waarmee je verschillende versies van PHP kan testen via de command line.

De makkelijkste manier om te beginnen met testen is door een testomgeving aan te maken aangezien deze voor het grootste deel overeenkomt met je live productiesite. In het MyKinsta-dashboard klik je op je site en verander je je omgeving naar de testomgeving.

Vervolgens kan je in het Tools-menu je PHP-engine wijzigen naar PHP 7.4. Nu kan je beginnen met het testen van de compatibiliteit met je code, externe plugins en thema’s.

Net als bij eerdere versies van PHP, ondersteunt onze zelfherstellende PHP functie PHP 7.4 volledig. Als PHP om welke reden dan ook uitvalt, zullen we het automatisch opnieuw opstarten. Als het opnieuw opstarten het probleem niet oplost, zal ons bewakingssysteem ons sysadmin-team waarschuwen om de oorzaak van het probleem te onderzoeken.

Zie alle gegevens over de PHP 7.4 release bij Kinsta.

Installeren en uitvoeren van PHP 7.4 op Docker

Wil je op Docker testen? Gelukkig hoef je PHP 7.4 niet handmatig te compileren en te configureren. Als Docker al op je systeem is geïnstalleerd, hoef je alleen de niet-officiële PHP-FPM 7.4 Docker Image te installeren om je tests vanuit de opdrachtregel uit te voeren.

Als je liever de PHP 7.4-code vanuit je browser gebruikt, dan moet je ook een Nginx of Apache image installeren. Maar geen zorgen! Volg gewoon de aanwijzingen van de ontwikkelaar. Kopieer en plak de opdrachten van de Docker Image-pagina naar de commandline-tool van jouw keuze en je kan beginnen.

Samenvatting

In dit artikel hebben we een groot aantal wijzigingen en toevoegingen behandeld die we kunnen verwachten met de release van PHP 7.4. Als je op zoekt bent naar de volledige lijst met features, samen met de officiële RFC-documentatie, bekijk dan de volgende bronnen:

• PHP 7.4 Requests for Comments
• PHP 7.4 Upgrade Notes
• PHP 7.4 Preparation Tasks

We houden je op de hoogte met de laatste informatie over PHP 7.4. Als je klant bent van Kinsta, kan je meteen beginnen met het verhuizen van je WordPress sites naar de nieuwste versie.

Ben je klaar om de features van deze nieuwe versie van PHP te testen? Op welke feature kan jij niet wachten? Laat het ons weten in de reacties hieronder.