PHP 7.2 har officiellt släppts den 30 november. Utgåvan har nya funktioner, finesser och förbättringar som gör det möjligt för oss att skriva bättre kod. I det här inlägget kommer jag att presentera några av de mest intressanta språkfunktionerna med PHP 7.2.

Uppdatering: PHP 8.0 är nu tillgänglig för alla Kinsta-klienter.

Du kan se hela listan med ändringar på Begäran om kommentarer-sidan.

Kärnförbättringar

Argumenttyp-deklarationer

Sedan PHP 5 får vi i en funktionsdeklaration ange den argumenttyp som förväntas bli godkänd. Om det angivna värdet är av en felaktig typ, visar PHP ett fel.

Argumenttyp-deklarationer (även kallade typtips) anger vilken typ av variabel som förväntas överföras till en funktions- eller klassmetod.

Här är ett exempel:

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

$myclass = new MyClass;

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

echo test($myclass);

I den här koden förväntar test-funktionen en instanceof MyClass. En felaktig datatyp skulle resultera i följande allvarliga fel:

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

Sedan PHP 7.2 kan typtips användas med objekt-datatypen, och denna förbättring gör det möjligt att deklarera ett generiskt objekt som argument för en funktion eller metod. Här är ett exempel:

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 det här exemplet har vi anropat testfunktionen två gånger och skickar ett annat objekt vid varje anrop. Detta var inte möjligt i tidigare PHP-versioner.

Testa typtips med PHP 7.0 och PHP 7.2 i Docker
Testa typtips med PHP 7.0 och PHP 7.2 i Docker

Returtypdeklarationer för objekt

Om argumenttypdeklarationer anger den förväntade typen för en funktions argument anger returtypdeklarationer den förväntade typen av returvärde.

Returtypdeklarationer anger vilken typ av variabel som förväntas returneras av en funktion.

Från och med PHP 7.2 får vi använda returtypdeklarationer för objekt-datatypen. Här är ett exempel:

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

$myclass = new MyClass;

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

echo test($myclass)->var;

Tidigare PHP-versioner ger följande allvarliga fel:

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

Naturligtvis returnerar denna kod i PHP 7.2 ”Hello World”.

Parametertypbreddning

PHP tillåter för närvarande inte någon varians av parametertyper mellan underordnade klasser och deras överordnade klasser eller gränssnitt. Vad betyder det?
Betrakta följande kod:

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

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

Här har vi utelämnat parametertypen i underklassen. I PHP 7.0 producerar denna kod följande varning:

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

Sedan PHP 7.2 får vi utelämna en typ i en underklass utan att bryta någon kod. Detta förslag gör det möjligt för oss att uppgradera klasser för att använda typtips i bibliotek utan att behöva uppdatera alla underklasser.

Avslutande kommatecken i listsyntax

Ett avslutande kommatecken efter det sista objektet i arrayen är giltig syntax i PHP, och ibland uppmuntras det för att enkelt lägga till nya objekt och undvika parsefel på grund av ett saknat kommatecken. Sedan PHP 7.2 får vi använda avslutande kommatecken i grupperade namnområden.

Se Avslutande kommatecken i Listsyntax för en närmare titt på denna RFC och några kodexempel.

Säkerhetsförbättringar

Argon2 i lösenord-hash

Argon2 är en kraftfull hashingalgoritm som valdes som vinnare av 2015 års Password Hashing Competition och PHP 7.2 kommer att ge oss den som ett säkert alternativ till Bcrypt-algoritmen.
Den nya PHP-versionen introducerar PASSWORD_ARGON2I-konstanten, som nu kan användas i password_*-funktioner:

password_hash('password', PASSWORD_ARGON2I);

password_hash(’password’, PASSWORD_ARGON2I);

Till skillnad från Bcrypt, som bara tar en kostnadsfaktor, tar Argon2 tre kostnadsfaktorer som särskiljs enligt följande:

  • En minneskostnad som definierar antalet kb som ska förbrukas under hashing (standardvärdena är 1<<10, eller 1024 kb, eller 1 mb)
  • En tidskostnad som definierar antalet iterationer av hashing-algoritmen (standard 2)
  • En parallellismfaktor, som anger antalet parallella trådar som ska användas under hashing (standard 2)

Tre nya konstanter definierar standardkostnadsfaktorer:

  • PASSWORD_ARGON2_DEFAULT_MEMORY_COST
  • PASSWORD_ARGON2_DEFAULT_TIME_COST
  • PASSWORD_ARGON2_DEFAULT_THREADS

Här är ett exempel:

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

Se Argon2 Password Hash för mer information.

Libsodium som en del av PHP-kärnan

Från och med version 7.2 innehåller PHP Sodium Library i kärnan. Libsodium är ett plattformsoberoende och språkoberonde bibliotek för kryptering, dekryptering, signaturer, lösenordshashing och mer. Biblioteket var tidigare tillgängligt via PECL. För en dokumenterad lista över Libsodium funktioner, se bibliotekets Snabbstartsguide.

Se även PHP 7.2: Det första programmeringsspråket för att lägga till Modern kryptografi till sitt standardbibliotek.

Avvecklingar

Här är en lista över PHP 7.2s avveklade funktioner som kommer att tas bort senast till PHP 8.0:

Funktionen __autoload har ersatts av spl_autoload_register i PHP 5.1. Nu skulle ett avvecklingsmeddelande skapas om det uppstår under kompileringen.

Variabeln $php_errormsg skapas i det lokala tillämpningsområdet när ett icke-allvarligt fel förekommer. Sedan PHP 7.2 ska error_get_last och error_clear_last användas istället.

create_function () gör det möjligt att skapa en funktion med ett genererat funktionsnamn, en lista över argument och kropp-kod som tillhandahålls som argument. På grund av säkerhetsproblem och dålig prestanda har den markerats som avvecklad och användningen av kapslingar uppmuntras istället.

mbstring.func_overload ini-inställning inställd på ett icke-nollvärde har markerats som avvecklad.

(unset) cast är ett uttryck som alltid returnerar null och anses vara värdelöst.

parse_str() parsar en frågesträng till en array om det andra argumentet tillhandahålls, eller till den lokala symboltabellen om den inte används. Eftersom dynamisk inställning av variabler i funktionens omfattning avrådes av säkerhetsskäl, kommer användningen av parse_str() utan det andra argumentet att visa ett avvecklingsmeddelande.

gmp_random() anses vara plattformsberoende och kommer att avvecklas. Använd istället gmp_random_bits() och gmp_random_rage().

each() används för att iterera över en array ungefär som foreach(), men foreach() är att föredra av flera skäl, inklusive att det är 10 gånger snabbare. Nu kommer ett avvecklingsmeddelande skapas på det första anropet i en slinga.

Funktionen assert() kontrollerar det angivna påståendet och vidtar lämpliga åtgärder om resultatet är FALSE. Användningen av assert() med strängargument är nu avvecklad eftersom det öppnar en RCE-sårbarhet. Zend.assertion ini-alternativet kan användas för att förhindra utvärdering av assertion-uttryck.

$errcontext är en array som innehåller de lokala variabler som finns när ett fel genereras. Det har blivit godkänt som det sista argumentet som ger fel för hanterare som ställts in med set_error_handler()-funktionen.

Vad Betyder PHP 7.2 för WordPress-Användare?

Enligt den officiella WordPresstatistik-sidan, har i skrivande stund endast 19,8% av WordPressanvändare uppgraderat till PHP 7. Och endast 5% använder PHP 7.1. Du kan se att en stor majoritet av användarna, över 40%, fortfarande kör PHP 5.6. Vad som är ännu läskigare är att över 39% av användarna använder PHP-versioner som inte längre stöds. I December 2016 höjde faktiskt WordPress.org sin officiella rekommendation för användare från PHP 5.6 till PHP 7 eller högre.

WordPress PHP 7.1 statistik
WordPress PHP 7.1 statistik

Siffrorna ovan är särskilt skrämmande från en prestandasynpunkt, eftersom PHP 7 har visat sig vara betydligt snabbare. Här är lite statistik:

  • Officiella PHP-riktmärken visar att PHP 7 tillåter systemet att utföra dubbelt så många förfrågningar per sekund jämfört med PHP 5.6, med nästan hälften så mycket latens.
  • Christian Vigh publicerade också en PHP prestandajämförelse där han fann att PHP 5.2 var 400% långsammare än PHP 7.

Vi körde också våra egna prestanda-benchmarks år 2018 med PHP 5.6 vs PHP 7 vs HHVM. Och som mätvärdena ovan såg vi att PHP 7.2 kunde exekvera nästan tre gånger så många transaktioner (förfrågningar) per sekund jämfört med PHP 5.6.

WordPress benchmarks
WordPress benchmarks
  • WordPress 4.9.4 PHP 5.6 benchmark-resultat: 49.18 förfrågningar/s
  • WordPress 4.9.4 PHP 7.0 benchmark-resultat: 133.55 förfrågningar/s
  • WordPress 4.9.4 PHP 7.1 benchmark-resultat: 134.24 förfrågningar/s
  • WordPress 4.9.4 PHP 7.2 benchmark-resultat: 148.80 förfrågningar/s?
  • WordPress 4.9.4 HHVM benchmark-resultat: 144.76 förfrågningar/s

Många är långsamma att uppdatera helt enkelt på grund av den tid som är involverad i att testa alla sina tredjeparts plugins och teman för att säkerställa att de fungerar korrekt. Men många gånger, handlar det om att de helt enkelt inte satt igång. Inte säker på vilken version av PHP du kör? Ett av de enklaste sätten att kontrollera är att använda ett verktyg som Pingdom eller Google Chrome Devtools. Den första HTTP-rubriken visar vanligtvis versionen.

Kontrollera PHP-version
Kontrollera PHP-version

Detta bygger på att värden inte ändrar X-Powered-By header-värdet. Om de gör det kanske du inte ser din PHP-version, i vilket fall du skulle behöva ladda upp en fil via FTP. Eller så kan du nå ut till din värd och fråga.

Uppdatering till PHP 7.2

PHP 7.2 är inte riktigt ute ännu, men när det är kan du börja testa. Du kan testa din WordPresswebbplats lokalt eller kontrollera dina skript i en miljö som Docker, vilket gör att du kan testa olika versioner av PHP från kommandoraden.

Eller så kan du använda en stagingmiljö, eftersom detta närmare kommer liknar en live-produktionsplats. Kinsta gjorde PHP 7.2 tillgänglig för alla kunder den 4 December. Du kan enkelt skapa en stagingmiljö med ett enda klick.

Testa PHP 7.2 i en stagingmiljö
Testa PHP 7.2 i en stagingmiljö

Med ett enkelt klick kan du ändra PHP-motorn för staging-webbplatsen under ”Verktyg” och du kan börja testa för att säkerställa kompatibiliteten hos dina tredjepartsplugin och teman. När du bekräftat att allt fungerar kan du antingen ändra din produktionsplats till PHP 7.2 eller ta din staging-webbplats live.

Byt till PHP 7.2
Byt till PHP 7.2

Slutsats

Är du redo att byta till PHP 7.2? Förhoppningsvis har du nu åtminstone gjort övergången till PHP 7. Om du inte har det är nu en bra tidpunkt att börja testa. Så, uppgradera dina skript, kontrollera din kod och låt oss få höra dina första intryck av PHP 7.2.

Rekommenderad läsning: Är PHP dött?

Carlo Daniele Kinsta

Carlo är en passionerad älskare av webbdesign och frontend-utveckling. Han har sysslat med WordPress i över 10 år, även i samarbete med italienska och europeiska universitet och utbildningsinstitutioner. Carlo har dessutom skrivit dussintals artiklar och guider om WordPress, som är publicerade både på italienska och internationella webbplatser, samt på tryckta tidskrifter. Du hittar Carlo på X och LinkedIn.