PHP 7.2 er officielt frigivet den 30. november. Udgivelsen har nye funktioner, funktioner og forbedringer, der giver os mulighed for at skrive bedre kode. I dette indlæg introducerer jeg nogle af de mest interessante sprogfunktioner med PHP 7.2.

Opdatering: PHP 8.0 er nu tilgængelig for alle Kinsta-klienter.

Du kan se den fulde liste over ændringer på siden Requests For Comments

Kerne forbedringer

Argumenttype deklarationer

Siden PHP 5 har vi tilladt at specificere i en funktionserklæring for den argumenttype, der forventes bestået. Hvis den givne værdi er af en forkert type, smider PHP en fejl.

Argumenttype deklarationer (også kendt som type hints) angiver typen af en variabel, der forventes overført til en funktion eller klassemetode.

Her er et eksempel:

class MyClass {
	public $var = 'Hello World';
}

$myclass = new MyClass;

function test(MyClass $myclass){
	return $myclass->var;
}

echo test($myclass);

I denne kode forventer test funktionen en instans af MyClass. En forkert datatype ville resultere i følgende fatale fejl:

Fatal error: Uncaught TypeError: Argument 1 passed to test() must be an instance of MyClass, string given, called in /app/index.php on line 12 and defined in /app/index.php:8

Da PHP 7.2 type hints kan bruges med objekt datatypen, og denne forbedring gør det muligt at erklære et generisk objekt som argument for en funktion eller metode. Her er et eksempel:

class MyClass {
	public $var = '';
}

class FirstChild extends MyClass {
	public $var = 'My name is Jim';
}
class SecondChild extends MyClass {
	public $var = 'My name is John';
}

$firstchild = new FirstChild;
$secondchild = new SecondChild;

function test(object $arg) {
	return $arg->var;
}

echo test($firstchild);

echo test($secondchild);

I dette eksempel har vi kaldt testfunktionen to gange, og sendt et andet objekt ved hvert opkald. Dette var ikke muligt i tidligere PHP-versioner.

Docker commands
Test af type hints med PHP 7.0 og PHP 7.2 i Docker

Deklarationer af objektets returneringstype

Hvis argumenttype deklarationer specificerer den forventede type for en funktionsargumenter, angiver returnerings type deklarationer den forventede type af returneringsværdien.

Returtype deklarationer specificerer typen af en variabel, der forventes at blive returneret af en funktion.

Fra PHP 7.2 har vi tilladelse til at bruge returtype deklarationer til objektdatatypen. Her er et eksempel:

class MyClass {
	public $var = 'Hello World';
}

$myclass = new MyClass;

function test(MyClass $arg) : object {
	return $arg;
}

echo test($myclass)->var;

Tidligere PHP-versioner kaster følgende fatale fejl:

Fatal error: Uncaught TypeError: Return value of test() must be an instance of object, instance of MyClass returned in /app/index.php:10

I PHP 7.2 er denne kode naturligvis ‘Hello World‘.

Udvidelse af parametertype

PHP tillader i øjeblikket ingen varians af parametertyper mellem underordnede klasser og deres overordnede klasser eller grænseflader. Hvad betyder det?

Overvej følgende kode:

<?php
class MyClass {
	public function myFunction(array $myarray) { /* ... */ }
}

class MyChildClass extends MyClass {
	public function myFunction($myarray) { /* ... */ }
}

Her har vi udeladt parametertypen i underklassen. I PHP 7.0 producerer denne kode følgende advarsel:

Warning: Declaration of MyChildClass::myFunction($myarray) should be compatible with MyClass::myFunction(array $myarray) in %s on line 8

Siden PHP 7.2 har vi lov til at udelade en type i en subclass uden at bryde nogen kode. Dette forslag giver os mulighed for at opgradere klasser til at bruge type hints i biblioteker uden at være påkrævet at opdatere alle underklasser.

Efterfølgende kommaer i list syntax

Et trailing coma efter det sidste punkt i arrays er gyldig syntaks i PHP, og det opfordres undertiden til let at tilføje nye elementer og undgå analysefejl på grund af et manglende komma. Siden PHP 7.2 har vi tilladelse til at bruge trailing commas i grupperede navneområder.

Se Trailing Commas In List Syntax for at se nærmere på denne RFC og nogle eksempler på kode.

Forbedringer af sikkerhed

Argon2 i hash med password

Argon2 er en kraftig hash-algoritme, der blev valgt som vinderen af 2015 Password Hashing Competition, og PHP 7.2 bringer den til os som et sikkert alternativ til Bcrypt-algoritmen.

Den nye PHP-version introducerer PASSWORD_ARGON2I-konstanten, der nu kan bruges i password_* -funktioner:

password_hash('password', PASSWORD_ARGON2I);

I modsætning til Bcrypt, der kun tager en cost faktor, tager Argon2 tre omkostningsfaktorer, der adskilles som følger:

  • En memory cost, der definerer antallet af KiB, der skal forbruges under hashing (standardværdier er 1 << 10 eller 1024 KiB eller 1 MiB)
  • En time cost, der definerer antallet af iterationer af hash-algoritmen (standard til 2)
  • En parallelisme factor, der indstiller antallet af parallelle tråde, der skal bruges under hashing (standardindstillinger til 2)

Tre nye konstanter definerer standardomkostningsfaktorer:

  • PASSWORD_ARGON2_DEFAULT_MEMORY_COST
  • PASSWORD_ARGON2_DEFAULT_TIME_COST
  • PASSWORD_ARGON2_DEFAULT_THREADS

Her er et eksempel:

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

Se Argon2 Password Hash for mere information.

Libsodium som en del af PHP Core

Fra version 7.2 inkluderer PHP Sodium library i kernen. Libsodium er tværplatform og bibliotek på tværs af sprog til kryptering, dekryptering, underskrifter, hash-kode for hashing og mere.

Biblioteket var tidligere tilgængeligt via PECL.

For en dokumenteret liste over Libsodium-funktioner, se bibliotekets hurtig startguide.

Se også PHP 7.2: Det første programmeringssprog til at tilføje moderne kryptografi til dets standardbibliotek.

Deprecations

Her er en liste over PHP 7.2 forældede funktioner og features, der ikke senere fjernes som PHP 8.0:

Funktionen __autoload er blevet erstattet af spl_autoload_register i PHP 5.1. Nu ville der blive kastet en meddelelse om værdiforringelse, når den støder på under udarbejdelsen.

Variablen $php_errormsg oprettes i det lokale omfang, når en ikke-dødelig fejl kastes. Da PHP 7.2 skal error_get_last og error_clear_last bruges i stedet.

create_function() tillader oprettelse af en funktion med et genereret funktionsnavn, en liste over argumenter og koden, der leveres som argumenter. På grund af sikkerhedsproblemer og dårlig ydeevne er det blevet markeret som forældet, og brugen af ​​skabe opmuntres i stedet.

mbstring.func_overload ini-indstilling indstillet til en ikke-nul-værdi er markeret som forældet.

(unset) cast er et udtryk, der altid returnerer nul og betragtes som ubrugelig.

parse_str() analyserer en forespørgselsstreng i en matrix, hvis det andet argument leveres, eller i den lokale symboltabel, hvis den ikke bruges. Da dinamisk indstilling af variabler i funktionsomfang af sikkerhedsmæssige årsager frarådes, vil brugen af ​​parse_str() uden det andet argument kaste en meddelelse om afskrivning.

gmp_random() betragtes som platformafhængig og vil blive udskrevet. Brug i stedet gmp_random_bits() og gmp_random_rage().

each() bruges til at iterere over en matrix, der ligner foreach(), men foreach() foretrækkes af flere grunde, herunder at være 10 gange hurtigere. Nu kastes en afskrivning på det første opkald i en løkke.

Funktionen assert() kontrollerer den givne påstand og træffer passende handlinger, hvis resultatet er FALSE. Brugen af ​​assert() med string argument udskrives nu, da det åbner en RCE-sårbarhed. Indstillingen zend.assertion ini kan bruges til at forhindre evaluering af påståelsesudtryk.

$errcontext er en matrix, der indeholder de lokale variabler, der eksisterede på det tidspunkt, hvor en fejl genereres. Det sendes som det sidste argument til fejlhåndterere, der er angivet med funktionen set_error_handler().

Hvad betyder PHP 7.2 for WordPress-brugere?

I henhold til den officielle WordPress Stats-side er det kun ved skrivning af dette, at kun 19,8% af WordPress-brugere har opgraderet til PHP 7. Og kun 5% bruger PHP 7.1. Du kan se, at et stort flertal af brugere, over 40%, stadig kører på PHP 5.6. Hvad der er endnu skræmmende er, at over 39% af brugerne bruger ikke-understøttede PHP-versioner. Fra december 2016 fik WordPress.org faktisk deres officielle anbefaling til brugere fra PHP 5.6 til PHP 7 eller større.

WordPress PHP 7.1 statistik
WordPress PHP 7.1 statistik

Ovenstående tal er især nedslående fra et performance-synspunkt, da PHP 7 har vist sig at være betydeligt hurtigere. Her er et par statistikker:

  • Officielle PHP-benchmarks viser, at PHP 7 giver systemet mulighed for at udføre dobbelt så mange anmodninger pr. sekund i sammenligning med PHP 5.6, næsten halvdelen af forsinkelsen.
  • Christian Vigh offentliggjorde også en PHP-præstations sammenligning, hvor han fandt, at PHP 5.2 var 400% langsommere end PHP 7.

Vi kørte også vores egne præstations benchmarks i 2018 med PHP 5.6 vs PHP 7 vs HHVM. Og på samme måde som benchmarkene ovenfor, så vi, at PHP 7.2 kunne udføre næsten tre gange så mange transaktioner (anmodninger) i sekundet sammenlignet med PHP 5.6.

WordPress benchmarks
WordPress benchmarks
  • WordPress 4.9.4 PHP 5.6 benchmarkresultater: 49,18 req / sek
  • WordPress 4.9.4 PHP 7.0 benchmarkresultater: 133,55 req / sek
  • WordPress 4.9.4 PHP 7.1 benchmarkresultater: 134,24 req / sek
  • WordPress 4.9.4 PHP 7.2 benchmarkresultater: 148,80 req / sek 👑
  • WordPress 4.9.4 HHVM benchmarkresultater: 144,76 req / sek

Mange er langsomme med at opdatere, bare på grund af den tid, der er involveret i at teste nye alle deres tredjeparts plugins og temaer for at sikre, at de fungerer korrekt. Men mange gange kommer det ned, at de simpelthen ikke har gjort det endnu. Ikke sikker på, hvilken version af PHP du kører? En af de nemmeste måder at kontrollere er at bruge et værktøj som Pingdom eller Google Chrome Devtools. Den første HTTP-anmodnings header vil typisk vise dig versionen.

Tjek version af PHP
Tjek version af PHP

Dette er afhængig af, at værten ikke ændrer X-Powered-By-headerværdien. Hvis de gør det, kan du muligvis ikke se din PHP-version, i hvilket tilfælde du bliver nødt til at uploade en fil via FTP. Eller du kan altid nå ud til din vært og spørge.

Opdatering til PHP 7.2

PHP 7.2 er ikke helt ude endnu, men når det først er tilfældet, kan du begynde at teste. Du kan teste dit WordPress-site lokalt eller tjekke dine scripts i et miljø som Docker, som giver dig mulighed for at teste forskellige versioner af PHP fra kommandolinjen.

Eller du kan bruge et scenemiljø, da dette mere ligner et levende produktionssted. Kinsta stillede PHP 7.2 til rådighed for alle klienter den 4. december. Du kan nemt oprette et scenemiljø med et enkelt klik.

Test PHP 7.2 i scenemiljø
Test PHP 7.2 i scenemiljø

Du skal blot med et enkelt klik ændre PHP-motoren til scene sitet under “Værktøjer”, og du kan starte test for at sikre kompatibilitet af dine tredjeparts plugins og temaer. Når du har bekræftet, at alt fungerer, kan du enten ændre dit produktionssite til PHP 7.2 eller skubbe dit scenesite live.

Skift til PHP 7.2
Skift til PHP 7.2

Konklusioner

Er du klar til at skifte til PHP 7.2? Forhåbentlig har du i det mindste lavet overgangen til PHP 7. Hvis du ikke har det nu, er det et godt tidspunkt at begynde at teste. Så opgrader dine scripts, kontroller din kode og fortæl os om dine første indtryk af PHP 7.2.

Anbefalet læsning: Er PHP død?

Carlo Daniele Kinsta

Carlo er en passioneret elsker af webdesign og frontend udvikling. Han har arbejdet med WordPress i over 10 år, også i samarbejde med italienske og europæiske universiteter og uddannelsesinstitutioner. Han har skrevet snesevis af artikler og guides om WordPress, udgivet både på italienske og internationale hjemmesider samt på trykte magasiner. Du kan finde Carlo på X og LinkedIn.