Wat is er nieuw in PHP 7.3?

Op 6 december werd PHP 7.3 vrijgegeven, de meest recente en beste versie van PHP! De nieuwe versie levert nieuwe handige features, functionaliteiten, afschrijvingen, een flink aantal bugfixes en verbeteringen in prestaties. PHP 7.3 is beschikbaar voor alle Kinsta-klanten in het MyKinsta dashboard. 🤘

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

In dit artikel geven we een overzicht van de features en veranderingen die ons het meest zijn opgevallen. Je kan natuurlijk altijd de volledige lijst met features, veranderingen en bugfixes bekijken in de PHP 7.3 upgrade notes en de PHP 7.3 Requests for Comments.

Bijwerken: PHP 7.4 (officiële release) is nu beschikbaar voor alle Kinsta clients.

Nieuw in PHP 7.3

In deze post behandelen we de volgende veranderingen in PHP 7.3:

• Flexibele heredoc- en nowdoc-syntax geïmplementeerd
• Een volgkomma in functie-aanroepen toestaan
• JSON_THROW_ON_ERROR
• list() referentieopdracht
• is_countable-functie
• array_key_first(), array_key_last()
• Verbeteringen aan de Argon2 wachtwoord-hash
• Deprecations

Flexibele heredoc- en nowdoc-syntax

Dit is waarschijnlijk een van de meest relevante verbeteringen van PHP 7.3, en we vinden dat het wat meer aandacht verdient. Dus, voordat je gaat duiken in PHP 7.3 Heredoc / Nowdoc-wijzigingen, bieden we een kort overzicht van deze nuttige kernfunctie. Als je al bekend bent van nowdoc en heredoc, ga dan gerust naar de wijzigingen in PHP 7.3.

• Een overzicht van heredoc- en nowdoc-syntax
• PHP 7.3: De afsluitende marker laten inspringen en de leidende witruimte verwijderen
• PHP 7.3: De nieuwe regel-eis na een afsluitende marker verwijderen
  

Een overzicht van heredoc- en nowdoc-syntax

De heredoc-syntax biedt een manier om een grote hoeveelheid tekst toe te voegen zonder dat je deze hoeft te includeren door bijvoorbeeld dubbele aanhalingstekens. . Een heredoc begint met <<< gevolgd door een marker, en eindigt met dezelfde marker gevolgd door een puntkomma. Hier is een voorbeeld:

print <<

Een nowdoc gedraagt zich veelal als een heredoc, met een paar uitzonderingen:

• De identificatiemarker is ingesloten in enkele aanhalingstekens (<<<'EOT')
• Er vindt geen parsing plaats in een nowdoc

Hier is een voorbeeld van nowdoc:

print <<<'EOT'
Nowdocs zijn voor strings in enkele aanhalingstekens wat heredocs zijn voor strings in dubbele aanhalingstekens.
EOT;

Heredocs en nowdocs delen dezelfde regels die het gebruik van de afsluitende marker reguleren:

1. De afsluitende marker moet beginnen in de eerste kolom van de regel
2. De marker moet dezelfde regels volgen voor namen als elk ander PHP-label: het mag alleen bestaan uit letters, cijfers en lage streepjes, en moet beginnen met een niet-numeriek karakter of een lage streep.

Het PHP-handboek waarschuwt:

Het is erg belangrijk om op te merken dat de regel met de afsluitende identifier geen andere tekens mag bevatten dan de puntkomma (;). Dat betekent met name dat de identifier niet mag worden ingesprongen, en dat er geen spaties of witruimtes voor of na de puntkomma mogen staan. Het is ook belangrijk om te beseffen dat het eerste teken voor de afsluitende identifier een nieuwe regel moet zijn, zoals gedefinieerd door het lokale besturingssysteem. Dit is \n op UNIX-systemen, inclusief macOS. Het afsluitende scheidingsteken moet ook worden gevolgd door een nieuwe regel.

PHP 7.2 ongeldige syntax:

class foo {
    public $bar = <<

PHP 7.2 geldige syntax:

class foo {
    public $bar = <<

In het kort, in PHP 7.2:

• De afsluitende marker mag niet worden ingesprongen
• De regel met de afsluitende marker mag geen karakters bevatten zoals spaties of witruimtes
• Het eerste karakter voor de afsluitende marker moet een nieuwe regel zijn
• De afsluitende marker moet gevolgd worden door een nieuwe regel

Het is duidelijk dat de syntaxis van heredoc en nowdoc behoorlijk restrictief zijn, maar PHP 7.3 kan dit een beetje versoepelen met de volgende verbeteringen.

1. De afsluitende marker laten inspringen en de leidende witruimte verwijderen

Met PHP 7.3 mogen we de afsluitende marker inspringen en kunnen we de volgende code veilig schrijven:

class foo {
    public $bar = <<

De inspringing van de afsluitende marker bepaalt de hoeveelheid witruimte (of tabs) die van elke regel van de wordt verwijderd. Maar let op: de afsluitende marker mag nooit verder worden ingesprongen dan een andere regel van de body.

Zie de onderstaande code:

class foo {
    public $bar = <<

De bovenstaande code geeft de volgende parsingfout:

Parse error: Invalid body indentation level (expecting an indentation at least ...) in %s on line %d

Het verwijderen van tabs en witruimtes stelt ons in staat om de body van de heredoc/nowdoc op hetzelfde niveau van de code te laten inspringen, en dat zonder onnodige witruimte voor elke regel van de body.

We kunnen zowel tabs als spaties gebruiken om in te springen, maar we mogen ze niet combineren. Dit betekent dat we dezelfde inspringingstekens moeten gebruiken voor de afsluitende marker en alle regels van de body. In het geval van verschillende inspringingstekens, verwachten we een ander soort parsingfout (ongeldige inspringing).

2. De nieuwe regel-eis na een afsluitende marker verwijderen

Momenteel moet een nieuwe regel de markering volgen om de heredoc/nowdoc syntax af te sluiten. PHP 7.3 zou dit veranderen en zou ons in staat stellen het heredoc/nowdoc op dezelfde regel te beëindigen. Hier is een voorbeeld uit de RFC:

PHP 7.2 geldige syntax:

$values = [<<

PHP 7.3 geldige syntax:

$values = [<<

Hoe dan ook, wees voorzichtig bij het kiezen van de naam van je marker, want “af en toe” verwacht je een fout als deze overeenkomt met een woord dat je in de body van de heredoc/nowdoc hebt gebruikt (lees hier meer over op de RFC en GitHub).

Beide voorstellen zijn aangenomen met meer dan twee derde van de stemmen.

PHP 7.3 RFC

• Flexibele heredoc- en nowdoc-syntax

Overige bronnen

• Heredoc string syntax
• Nowdoc string syntax

Een volgkomma in functie-aanroepen toestaan

Volgkomma’s (“trailing commas”) zijn komma’s die zijn toegevoegd aan een lijst met elementen, parameters of eigenschappen. Ze zijn handig in contexten waar nieuwe waarden vaak worden toegevoegd omdat ze fouten voorkomen als gevolg van een ontbrekende komma. In PHP zijn volgkomma’s toegestaan in arrays en vanaf PHP 7.2 zijn ze toegestaan in gegroepeerde namespaces.

Vanaf PHP 7.3 zouden volgkomma’s toegestaan zijn in functiedeclaraties. Variadische functies bieden een voorbeeld van context waarin volgkomma’s bijzonder nuttig zijn:

foo(
    $bar,
    $baz,
);

We kunnen een volgkomma gebruiken wanneer we een array maken met compact(), om een opgemaakte string terug te geven me sprintf(), of bij het samenvoegen van een array:

$newArray = array_merge(
    $arrayOne,
    $arrayTwo,
    ['foo', 'bar'],
);

Volgkomma’s zouden ook handig zijn bij het debuggen:

var_dump(
    $foo,
    $bar,
    $baz,
);

En ze zijn erg krachtig met unset() en isset():

unset(
    $foo,
    $bar,
    $baz,
);

isset(
    $foo,
    $bar,
    $baz,
);

Volgkomma’s worden ook toegestaan in methodeaanroepen en insluitingen.

Opmerking: deze wijziging zou alleen van invloed zijn op functieaanroepen. De syntax voor functiedeclaraties zal niet veranderen. Bovendien zijn vrijstaande komma’s, meerdere volgkomma’s en leidende komma’s niet toegestaan.

Extra voorbeelden zijn te vinden op de RFC-pagina. Deze RFC is aangenomen met een 30 stemmen voor en 10 stemmen tegen.

PHP 7.3 RFC

• Flexibele heredoc- en nowdoc-syntax

JSON_THROW_ON_ERROR

Een van de meest gewaardeerde functies van PHP 7.3 biedt een nieuwe manier om JSON-fouten af te handelen. Dit is geen kernfunctionaliteit, maar een toevoeging aan de JSON-extensie die het foutgedrag van json_decode() en json_encode() zal aanpassen.

Momenteel returnt, json_decode() een null bij een foutmelding, maar null kan ook een geldige uitkomst zijn. Dit kan verwarrend zijn, omdat het alleen mogelijk is om te weten of er een fout is opgetreden door

json_last_error() of json_last_error_msg() aan te roepen, welke de globale foutstatus in respectievelijk machineleesbare en door mensen leesbare vormen returnen. – PHP RFC

json_encode() returnt FALSE bij een foutmelding. Dit is duidelijker omdat er een specifieke foutwaarde is. Hoe dan ook, beide functies stoppen noch de uitvoering van het programma op fouten, noch geven ze een waarschuwing.

Dat gezegd hebbende, hier is het voorstel voor PHP 7.3:

Deze RFC stelt voor om in plaats daarvan een nieuwe flag-waarde voor json_decode() en json_encode(), toe te voegen, genaamd JSON_THROW_ON_ERROR. Wanneer deze flag wordt uitgevaardigd, verandert het foutgedrag van deze functies. De globale foutstatus blijft ongewijzigd, en als er een fout optreedt die deze in zou stellen, gooien deze functies in plaats daarvan een JsonException op met het bericht en de code die zijn ingesteld op wat json_last_error() en json_last_error_msg() in dat geval zouden zijn.

Hier is een voorbeeld van een eenvoudige manier om een JSON-foutmelding te genereren:

try {
    json_decode("{", false, 512, JSON_THROW_ON_ERROR);
}
catch (\JsonException $exception) {
    echo $exception->getMessage(); // echoot een "Syntax error"
}

Het opgooien van een uitzondering bij een fout zou verschillende voordelen opleveren die je op de RFC kunt vinden.

Let op: een ongeldige diepteparameter die is doorgegeven aan json_decode() geeft een waarschuwing en returnt NULL. Dit gedrag wordt niet beïnvloed door JSON_THROW_ON_ERROR. Op dezelfde manier worden parameterafstemmingsfouten niet beïnvloed door JSON_THROW_ON_ERROR en blijven ze waarschuwingen produceren.

Dit voorstel is aangenomen met 23 stemmen voor en 0 stemmen tegen.

PHP 7.3 RFC

• JSON_THROW_ON_ERROR

Overige bronnen

• JavaScript objectnotatie
• json_decode()
• json_encode()
• json_last_error()
• json_last_error_msg()
• PHP Language Exceptions

list() referentieopdracht

Wat is een referentieopdracht?

Let op de volgende regel:

$b = &$a;

Hier krijgt $b de waarde van $a, maar die waarde wordt niet gekopieerd van $a naar $b . In PHP kunnen we een waarde toewijzen met een verwijzing, wat betekent dat twee variabelen naar dezelfde gegevens kunnen verwijzen en elke wijziging aan een variabele de oorspronkelijke gegevens beïnvloedt. Hier is een voorbeeld uit de PHP-handleiding:

<?php
$a = 3;
$b = &$a; // $b is een referentie naar $a

print "$a\n"; // print 3
print "$b\n"; // print 3

En kijk nu wat er gebeurt wanneer we $averanderen:

$a = 4; // verander $a

print "$a\n"; // print 4
print "$b\n"; // print ook 4, omdat $b een referentie is naar $a, welke is aangepast

Het list()-element en hoe het verandert in PHP 7.3

Het list()-computertaalelement kan worden gebruikt om “variabelen toe te wijzen alsof ze een array zaten”, maar met list() kunnen we momenteel geen variabele waarden toewijzen met een verwijzing.

PHP 7.3 past dit aan, waardoor we variabelen kunnen toewijzen door te verwijzen naar de constructie list() zoals in het volgende voorbeeld:

$array = [1, 2];
list($a, &$b) = $array;

Wat functioneel hetzelfde is als:

$array = [1, 2];
$a = $array[0];
$b =& $array[1];

Het voordeel van dit voorstel is dat we nu meerdere variabelen met een verwijzing kunnen toewijzen, wat momenteel niet is toegestaan. Meer voorbeelden zijn beschikbaar op de RFC. Dit voorstel is aangenomen met 17 voor en 7 stemmen tegen.

PHP 7.3 RFC

• list() referentieopdracht

Overige bronnen

• PHP-handleiding – list()
• PHP-handleiding – References Explained
• Opdracht-operators – Assignment by Reference

is_countable functie

Een andere handige functie van PHP 7.3 is de functie is_countable(). Tot en me PHP 7.2, kregen we een foutmelding wanneer we de count()-functie probeerde toe te passen op iets dat ontelbaar is. Om deze reden genoodzaakt om de volgende code toe te voegen als we een waarschuwing willen voorkomen:

if (is_array($foo) || $foo instanceof Countable) {
    // $foo is telbaar
}

Deze RFC stelt de functie is_countable(), voor, waarbij true wordt gereturnd als de gegeven variabele een array is of als het een telbare variabele is, en in alle andere gevallen, false. De bovenstaande code kan dus als volgt worden gewijzigd:

if (is_countable($foo)) {
    // $foo is telbaar
}

Het voorstel is aangenomen met 25 stemmen voor en 0 stemmen tegen.

PHP 7.3 RFC

• is_countable

Overige bronnen

• The Countable interface
• count

array_key_first(), array_key_last()

Momenteel kunnen we de eerste en de laatste sleutel van een array ophalen met behulp van de functies reset(), end() en key() Helaas is het bij deze functies niet mogelijk om de eerste of de laatste index van een array te verzamelen zonder de interne status te wijzigen. Andere opties verminderen meestal de leesbaarheid en prestaties van de code.
Dit voorstel zou deze situatie veranderen door twee nieuwe functies toe te voegen aan de kern van PHP:

• array_key_first()
• array_key_last()

Vanaf PHP 7.3 staan array_key_first() en array_key_last() je toe om de eerste en de laatste sleutel van een gegeven array op te halen, zonder daarbij de interne array-aanwijzer te beïnvloeden. Met deze nieuwe functies kunnen we minder complexe code schrijven en in sommige gevallen zelfs fouten voorkomen. Raadpleeg de RFC voor meer informatie en verschillende voorbeelden.

array_key_first() en array_key_last() zijn goedgekeurd met 18 stemmen voor en 14 stemmen tegen.

Let op: de oorspronkelijke RFC stelde nog twee andere functies voor, array_value_first() en array_value_last(), waarvoor in een andere peiling is gestemd, maar nog niet zijn goedgekeurd en die zullen niet worden toegevoegd aan de kern van PHP.

PHP 7.3 RFC

• array_key_first(), array_key_last()

Extra bronnen

• array_key_first
• array_key_last

Verbeteringen aan de Argon2 wachtwoord-hash

Argon2 is een hash-algoritme geïmplementeerd in PHP 7.2 als alternatief voor het Bcrypt-algoritme. PHP 7.2 introduceerde de constante PASSWORD_ARGON2I beschikbaar voor gebruik in password_*-functies:

password_hash('password', PASSWORD_ARGON2I);

Sinds zijn eerste implementatie is er een nieuwe variant van Argon2 toegevoegd, dus op het moment van schrijven is Argon2 verkrijgbaar in drie varianten:

• Argon2d maximaliseert de weerstand tegen GPU-kraakaanvallen. Het is sneller en gebruikt data-afhankelijke geheugentoegang.
• Argon2i gebruikt data-onafhankelijke geheugentoegang, wat de voorkeur heeft voor wachtwoord-hashing. Het is langzamer omdat het meer passes over het geheugen maakt om te beschermen tegen tradeoff-aanvallen.
• Argon2id is een hybride versie die de Argon2i-benadering voor de eerste pass over het geheugen combineert met de Argon2d-benadering voor alle overige passes.

Argon2id wordt aanbevolen op internet, behalve wanneer er goede redenen zijn om de voorkeur te geven aan een andere variant.

De nieuwe RFC stelt de implementatie van Argon2id voor binnen de password_*-functies met de nieuwe constante PASSWORD_ARGON2ID constant:

password_hash('password', PASSWORD_ARGON2ID);

De implementatie is identiek aan de Argon2i-implementatie en accepteert dezelfde kostenfactoren:

• Een memory cost die het aantal KiB bepaalt dat moet worden verbruikt tijdens het hashen (standaardwaarden zijn 1 << 10 oftewel 1024 KiB oftewel 1 MiB)
• Een time cost die het aantal iteraties van het hash-algoritme definieert (standaard ingesteld op 2)
• Een parallelism factor, waarmee het aantal parallelle threads wordt ingesteld dat tijdens hashing wordt gebruikt (standaard ingesteld op 2)

Kijk naar de volgende code:

$options = ['memory_cost' => 1<<11, 'time_cost' => 4, 'threads' => 2];
password_hash('wachtwoord', PASSWORD_ARGON2ID, $options);

Meer informatie en voorbeelden kun je vinden op de RFC.

PHP 7.3 RFC

• Argon2 Password Hash Enhancements

Extra bronnen

• Argon2 (Wikipedia)
• Argon2: the memory-hard function for password hashing and other applications (PDF)

Deprecations

De volgende functies en functionaliteiten zijn verouderd met de komst van PHP 7.3, en worden in PHP 8.0 verwijderd.

image2wbmp()

De image2wbmp()-functie output of slaat een WBMP-versie van een bepaalde afbeelding op. Voor deze functie zijn drie argumenten nodig: een afbeeldingsresource, een bestandsnaam (het pad naar het opgeslagen bestand) en een voorgrondkleur.
Vanaf PHP 5.0 is het identiek aan imagewbmp(), dus deze RFC stelt voor om het te verwijderen.
Vanaf PHP 7.3 geeft elke aanroep van image2wbmp()een waarschuwing af. Na de verwijdering zal elke oproep een fatale fout veroorzaken.

PHP 7.3 RFC

• Deprecate and Remove image2wbmp()

Niet-hoofdlettergevoelige constanten

PHP ondersteunt momenteel zowel hoofdlettergevoelige als niet-hoofdlettergevoelige constanten. Hoe dan ook, niet-hoofdlettergevoelige constanten worden ondersteund, maar zijn onderhevig aan inconsistenties in functies en zijn complex in gebruik.
Dit voorstel begint met de volgende premissen:

• klasse constanten zijn altijd hoofdlettergevoelig
• globale constanten die gedeclareerd zijn met const zijn altijd hoofdlettergevoelig
• constanten die zijn gedefinieerd met define() zijn standaad hoofdlettergevoelig

Bovendien vermeldt de PHP Language Reference expliciet:

Een constante is standaard hoofdlettergevoelig. Volgens afspraak zijn identifiers van constanten altijd in hoofdletters.

Dat gezegd hebbende, stelt deze RFC de volgende wijzigingen voor:

• Markeer de aanroep naar define() met als derde parameter true alse verouderd – PHP 7.3
• Markeer de toegang tot niet-hoofdlettergevoelige constanten die niet dezelfde hoofd of kleine letters hebben als de declaratie (met uitzondering van true, false en null) als verouderd – PHP 7.3
• Verwijder de mogelijkheid om niet-hoofdlettergevoelige constanten te declareren – PHP 8.0
• Verander true, false en null van speciale constanten naar gereserveerde keywords – PHP 8.0

PHP 7.3 RFC

Deprecate and Remove Case-Insensitive Constants.

Aanvullende deprecations van PHP 7.3

Hier is een korte lijst van functionaliteiten die verouderd zijn in PHP 7.3. Het is niet uitputtend, het zijn slechts de afkeuringsvoorstellen die ik persoonlijk relevant vind. Zie Deprecations for PHP 7.3 voor een volledige lijst met voorgestelde deprecations.

Niet-gedocumenteerde mbstring-functiealiassen: er is een aantal niet-gedocumenteerde mbstring -functiealiassen die kopieën zijn van equivalente functies die de mb_-prefix gebruiken. Bijvoorbeeld, mbereg is een alias van mb_ereg.
Al deze functies zullen worden gemarkeerd als verouderd en een afkeuringskennisgeving zal worden gegenereerd wanneer ze tijdens het compilen worden aangetroffen.

String-zoekfuncties met een integer-needle: deze functies werken meestal op string-needles. Als een needle zonder needle wordt gegeven, wordt deze omgezet in een geheel getal en toegepast als de ordinale waarde van een teken (lees meer in de PHP-handleiding). Hier is een voorbeeld uit de RFC:

$str = "Er zijn 10 appels";
var_dump(strpos($str, "10")); // int(10)
var_dump(strpos($str, 10));   // bool(false)

Dit wordt als verwarrend beschouwd en veroorzaakt onvoorspelbare problemen, omdat het type kan veranderen met de gegevensbron van de gebruiker. Om deze reden stelt de RFC voor om een verouderingswaarschuwing af te geven als een niet-string-needle wordt doorgegeven aan een van de volgende functies:

• strpos
• strrpos
• stripos
• strripos
• strstr
• strchr
• strrchr
• stristr

In PHP 8.0 moet de verouderingswaarschuwing worden verwijderd en de needles automatisch worden omgezet in strings.

fgetss()-functie en de string.strip_tags stream-filter: fgetss() en string.strip_tags verwijderen tags van een stream terwijl ze hem lezen. Zowel de functie als het filter stellen de functie strip_tags() bloot, waardoor de implementatie van strip_tags() ingewikkelder wordt, omdat een machine met streamingstatus vereist is. Bovendien wijst de RFC op een ander nadeel van deze functies:

Aan de andere kant lijken deze functies van weinig nut te zijn. strip_tags() zelf heeft, vanwege zijn beperkingen en bekende bugs, al heel weinig legitieme applicaties. Het is niet nodig om native ondersteuning voor streaming-applicaties te bieden.

Daarom stelt de RFC voor om fgetss(), gzgetss() en SplFileObject::fgetss() als verouderd te markeren.

Wat betekent PHP 7.3 voor WordPress-gebruikers?

Volgens de officiële  WordPress-statisiekenpagina, is op het moment van schrijven slechts 32,9% van de WordPress-gebruikers geüpgraded naar PHP 7 of hoger. Slechts 4% gebruikt PHP 7.2. Je ziet dat een grote meerderheid van gebruikers, meer dan 38%, nog steeds op PHP 5.6 draait. Nog schrijnender is dat meer dan 28,5% van de gebruikers niet-ondersteunde PHP-versies gebruikt. Vanaf december 2016 heeft WordPress.org hun officiële aanbeveling voor gebruikers verhoogd van PHP 5.6 naar PHP 7 of hoger.

PHP 7 prestaties

De bovenstaande cijfers zijn vooral ontmoedigend vanuit het oogpunt van prestaties, omdat PHP 7 aanzienlijk sneller is gebleken. Hier zijn een paar statistieken:

• Officiële PHP-benchmarks  tonen aan 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.

We voerden onze eigen PHP-prestatiebenchmarks uit. Net als bovenstaande benchmarks zagen we dat WordPress 5.0 op PHP 7.3 drie keer zoveel transacties (requests) per seconde aankon dan PHP 5.6.

• 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 🏆

Een ander interessant gegeven is dat PHP 7.3 iets sneller was op WordPress 4.9.8 dan op WordPress 5.0.

• WordPress 4.9.8 PHP 5.6 benchmark: 97.59 req/sec
• WordPress 4.9.8 PHP 7.0 benchmarkresultaten: 221.42 req/sec
• WordPress 4.9.8 PHP 7.1 benchmarkresultaten: 233.78 req/sec
• WordPress 4.9.8 PHP 7.2 benchmarkresultaten: 250.36 req/sec
• WordPress 4.9.8 PHP 7.3 benchmarkresultaten: 276.31 req/sec 🏆

In veel 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. Als dit wel het geval is, dan bestaat de kans dat je de PHP-versie niet te zien krijgt. In dat geval kan je een gratis plugin installeren, zoals Version Info, die je de belangrijkste serverinformatie laat zien in de footer van je WordPress-beheerdersdashboard.

Een alternatieve oplossing om de PHP-versie te zien, is om een bestand te uploaden via FTP of om simpelweg je host te vragen.

Updaten naar PHP 7.3

De definitieve versie van PHP 7.3 is nog niet gereleased, maar als het eenmaal zover is kun je beginnen met testen met de pre-releaseversie. Je kunt je WordPress-site lokaal testen  of je scripts controleren in een omgeving zoals Docker, waarmee je verschillende versies van PHP kunt testen vanaf de command line.

Of je kunt een testomgeving gebruiken, omdat deze meer op een live-productiesite lijkt. Maak een testomgeving  aan met een paar eenvoudige klikken in het MyKinsta-dashboard.

We raden aan om altijd grondig te testen voordat je de nieuwe versie inzet op een live-website. Om dit te doen, hoef je alleen maar de PHP-engine van de site in de testomgeving te veranderen – onder ‘Tools’ – waarna je de compatibiliteit van de PHP-versie met externe plugins en thema’s kan testen.

Zodra je zeker weet dat alles werkt, kan je de PHP-versie van je live-website wijzigen naar 7.3 of, als je wijzigingen hebt aangebracht in de testomgeving, deze van de testomgeving naar de live-omgeving pushen.

Samenvatting

De nieuwste en beste PHP-versie is uitgebracht. Het geeft ons cadeautjes zoals flexibele heredocs en nowdocs, trailing commas in functie-aanroepen, list()-referentie-opdrachten en meer. In deze post hebben we een overzicht gegeven van onze favoriete verbeteringen en wijzigingen, maar we willen ook graag weten wat jouw favoriete verbeteringen zijn, en op welke manieren je hiervan kunt profiteren. Laat het ons weten in een reactie hieronder.

Je vindt de volledige lijst met PHP 7.3-voorstellen op de pagina RFC-pagina en GitHub’s PHP 7.3 Upgrade Notes.