Hvad er nyt i PHP 7.4 (funktioner, afskrivninger, hastighed)

PHP 7.4, den næste PHP 7 mindre udgivelse, er blevet frigivet til General Disponibilitet den 28. november 2019. Så det er tid for os at dykke ned i nogle af de mest spændende tilføjelser og nye funktioner, der vil have gjort PHP hurtigere og mere pålidelige.

Opdatering: PHP 8.1 (officiel udgivelse) er nu tilgængelig for alle Kinsta-klienter. PHP 7.4 understøttes ikke længere hos Kinsta. Bemærk venligst, at vi understøtter PHP-versioner 7.4, 8.0, 8.1, 8.2, 8.3 og 8.4.

Faktisk, selvom PHP 7.4 signifikant øger ydeevnen og forbedrer kodelæsbarheden, vil PHP 8 være den rigtige milepæl for PHP-ydeevne, da forslaget til JIT-integration allerede er godkendt.

Anyway, i dag går vi igennem nogle af de mest interessante funktioner og ændringer, vi forventer med PHP 7.4. Bare for lige at oplyse, var dette de vigtige datoer for 7.4-versionen:

• 6. juni 2019: PHP 7.4 Alpha 1
• 18. juli 2019: PHP 7.4 Beta 1 – Funktion fryser
• 28. november 2019: PHP 7.4 GA Udgivelse

Du kan tjekke den fulde liste over funktioner og tilføjelser på den officielle RFC-side.

Hvad er nyt i PHP med PHP 7.4?

I dette indlæg dækker vi flere ændringer og funktioner, som skal tilføjes til sproget med den endelige udgivelse af PHP 7.4:

Glem array_merge: PHP 7.4 Brings Spread Operator i Array Expression

Tilgængelig siden PHP 5.6, er argumentet udpakning en syntaks for udpakning af arrayer og Traversables i argumentlister. For at udpakke et array eller en Traversable, skal det udfyldes af … (3 prikker), som vist i følgende eksempel:

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

Nu foreslår denne PHP 7.4 RFC at udvide denne funktion til array definitioner:

$arr = [...$args];

Den første erklærede fordel ved Spread Operator i array-udtryk handler om præstation. Faktisk siger RFC doc:

Spread operatør bør have bedre ydeevne end array_merge. Det er ikke kun fordi sprednings operatøren er en sprogstruktur, mens array_merge er en funktion, men også fordi kompilering tidsoptimering kan være effektiv for konstante arrayer.

En væsentlig fordel ved Spread operatør er, at den understøtter alle traversable objekter, mens array_merge-funktionen kun understøtter arrays.

Her er et eksempel på argument udpakning i array udtryk:

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

Hvis du kører denne kode med i PHP 7.3 eller tidligere, kaster PHP en Parse-fejl:

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

I stedet ville PHP 7.4 returnere en matrix:

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

RFC angiver, at vi kan udvide det samme array flere gange. Desuden kan vi bruge Spread Operator-syntaxen overalt i arrayet, da normale elementer kan tilføjes før eller efter spredningsoperatøren. Så følgende kode vil fungere som vi måtte forvente:

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

Det er også muligt at udpakke arrayer, der returneres af en funktion direkte til et nyt array:

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

PHP 7.4 udsender følgende 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"
}

Vi kan også bruge generatorsyntaxen:

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

Men vi har ikke lov til at udpakke arrays, der er vedtaget som reference. Overvej følgende eksempel:

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

Hvis vi ville forsøge at udpakke et array ved reference, kaster PHP følgende Parse-fejl:

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

I hvert fald, hvis elementerne i den første matrix lagres ved reference, gemmes de som reference også i den anden matrix. Her er et eksempel:

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

Og her er hvad vi får med 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"
}

Spread operatør forslaget bestået med 43 til 1 stemmer.

Pilfunktioner 2.0 (korte lukninger)

I PHP anses anonyme funktioner for at være ret verbose og vanskelige at implementere og vedligeholde. Denne RFC foreslår introduktion af den kortere og klarere syntaks af pilfunktionerne (eller korte lukninger), som skal gøre det muligt for os at rense vores PHP-kode betydeligt.

Overvej følgende eksempel:

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

PHP 7.4 tillader at bruge en mere kortfattet syntaks, og ovenstående funktion kan omskrives som følger:

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

I øjeblikket kan anonyme funktioner (lukninger) arve variabler defineret i forælderens omfang takket være sprogkonstruktionen, som vist nedenfor:

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

Men med PHP 7.4 er variabler defineret i parentes omfanget implicit fanget af værdi (implicit bindingsværdi bindende). Så vi kan skrive hele funktionen set ovenfor på en enkelt linje:

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

Den variable, der er defineret i parentesområdet, kan bruges i pilfunktionen nøjagtigt som om vi brugte use ($ var), og det er ikke muligt at ændre en variabel fra parentesområdet.

Den nye syntaks er en stor forbedring af sproget, da det giver os mulighed for at bygge mere læsbar og vedligeholdelig kode. Vi kan også bruge parameter og returtyper, standardværdier, argumentlister med variabel længde (variadiske funktioner), vi kan videregive og returnere ved reference osv. Endelig kan korte lukninger også bruges i klassemetoder, og de kan gøre brug af $ this variabel ligesom regulære lukninger.

Denne RFC er godkendt med 51 til 8 stemmer, så vi kan forvente, at det er en del af PHP 7.4 tilføjelser.

Null Coalescing Assignment Operator

Tilføjet med PHP 7, kommer coalesce operatøren (??) til nytte, når vi skal bruge en ternær operatør i forbindelse med isset (). Den returnerer den første operand, hvis den eksisterer og ikke er NULL. Ellers vender den tilbage til den anden operand. Her er et eksempel:

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

Hvad denne kode gør er ret retfærdig: den henter anmodningsparameteren og angiver en standardværdi, hvis den ikke findes. Betydningen af ​​denne linje er klar, men hvad nu hvis vi havde langt længere variable navne som i dette eksempel fra RFC?

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

I det lange løb kan denne kode være lidt svært at vedligeholde. Så, med det formål at hjælpe udviklere med at skrive mere intuitiv kode, foreslår denne RFC indførelsen af ​​null coalescerings operatøren (?? =). Så i stedet for at skrive den forrige kode kunne vi skrive følgende:

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

Hvis værdien af ​​den venstre parameter er null, bruges værdien af ​​den højre parameter.

Bemærk, at mens coalesceoperatøren er en sammenligningsoperatør, er ??= en assignment operator.

Dette forslag er godkendt med 37 til 4 stemmer.

Typede Egenskaber 2.0

Argument type erklæringer eller type tip, tillade at angive typen af ​​en variabel, der forventes at blive videregivet til en funktion eller en klassemetode. Type tip er en funktion tilgængelig siden PHP 5, og siden PHP 7.2 kan vi bruge dem med object datatypen. Nu PHP 7.4 bringer type hinting et skridt fremad ved at tilføje støtte til førsteklasses ejendomstype erklæringer. Her er et meget grundlæggende eksempel:

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

Alle typer understøttes, med undtagelse af void og callable:

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

RFC forklarer årsagen til, at void og callable ikke understøttes:

Ugyldigtype understøttes ikke, fordi det ikke er nyttigt og har uklar semantik.

Den kaldbare type understøttes ikke, fordi dens adfærd er kontekstafhængig.

Så vi kan sikkert bruge bool, int, float, string, array, object, iterable, self, parent, enhver klasse eller interface navn og nulstillede typer (?type).

Typer kan bruges på statiske egenskaber:

public static iterable $staticProp;

De er også tilladt med var notationen:

var bool $flag;

Det er muligt at angive standard egenskabsværdier, som selvfølgelig skal matche den deklarerede egenskabstype, men kun nulstillingsegenskaber kan have en standard null værdi:

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

Den samme type gælder for alle ejendomme i en enkelt erklæring:

public float $x, $y;

Hvad sker der, hvis vi gør en fejl på ejendomstype? Overvej følgende kode:

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

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

I koden ovenfor erklærede vi en streng-egenskabstype, men vi angiver en matrix som egenskabsværdi. I et sådant scenario får vi følgende fatale fejl:

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

Denne RFC er blevet godkendt med 70 til 1 stemmer.

Weak References

Med denne RFC introducerer PHP 7.4 klassen WeakReference, som gør det muligt for programmører at beholde en reference til et objekt, der ikke forhindrer selve objektet i at blive ødelagt.

I øjeblikket understøtter PHP svage referencer ved at bruge en udvidelse som pecl-weakref. ALtså, den nye API er forskellig fra den dokumenterede WeakRef klasse.

Her er et eksempel fra forfatteren af ​​dette forslag, Nikita Popov:

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

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

Det første var_dump-udskriftsobjekt object(stdClass)#1 (0) {}, mens den anden var_dump udskriver NULL, da det refererede objekt er blevet ødelagt.

Slides for my PHP 7.4 talk at #PHPRussia2019. Was a great conference!https://t.co/zLr9Bj2aKl

— Nikita Popov (@nikita_ppv) May 19, 2019

Denne RFC bestod med 28 til 5 stemmer.

Covariant returns og contravariant parametre

Variance er en egenskab af klassehierarkier, der beskriver hvordan typer af en konstruktør påvirker undertyper. Generelt kan en type konstruktør være:

• Invariant: Hvis typen af super-typen begrænser typen af subtypen.
• Covariant: Hvis bestillingen af typer er bevaret (typer bestilles fra mere specifikke til mere generiske).
• Contravariant: hvis det vendes ordren (typer bestilles fra mere generisk til mere specifik).

I øjeblikket har PHP for det meste invariant parameter og returtyper med få undtagelser. Denne RFC foreslår at tillade kovarians og modsvar på parametertyper og returtyper, der også giver flere eksempler på kode.

Her er et eksempel på kovariant returtype:

interface Factory {
	function make(): object;
}

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

Og her er et eksempel på contravariant parameter type:

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

Se RFC for at se nærmere på kovarians og modsvar i PHP 7.4.

Denne RFC bestod med 39 til 1 stemmer.

Preloading

Dette forslag fra Dmitry Stogov er en af vores foretrukne, fordi det burde bringe et betydeligt løft i præstationen. Preloading er processen med at indlæse biblioteker og rammer i OPCache ved modulinitialisering (læs mere om PHP livscyklus).

Sådan virker preloading i Dmitrys ord:

Ved server opstart – inden der køres en applikationskode – kan vi indlæse et bestemt sæt PHP-filer i hukommelsen – og gøre deres indhold “permanent tilgængelig” til alle efterfølgende forespørgsler, som serveres af den pågældende server. Alle de funktioner og klasser, der er defineret i disse filer, vil være direkte tilgængelige for forespørgsler, ligesom interne enheder.

Disse filer er indlæst ved server opstart, udføres før enhver applikation og forbliver tilgængelig for fremtidige anmodninger. Det er godt med hensyn til ydeevne.

Preloading styres af et specifikt php.ini-direktiv: opcache.preload. Dette direktiv angiver et PHP script, som skal udarbejdes og udføres ved server opstart. Denne fil kan bruges til at forudindlæse yderligere filer, enten med dem eller via funktionen opcache_compile_file () (læs mere på PHP-dokumentation).

Men der er en ulempe. Faktisk siger RFC udtrykkeligt:

forudindlæste filer forbliver cached i opcache-hukommelsen for evigt. Ændring af deres tilsvarende kildefiler vil ikke have nogen virkning uden en anden server genstart.

Alle funktioner, der er defineret i forudindlæste filer, indlæses dog permanent i PHP-funktion og klassetabeller og forbliver tilgængelige for hver fremtidig anmodning. Dette vil medføre gode præstationsforbedringer, selv om disse forbedringer kan være betydeligt variable.

Du kan læse mere om begrænsningerne og undtagelserne fra forudindlæsning på den officielle Preloading RFC-side.

Ny tilpasset objekt serialiserings-mekanisme

Dette er et andet forslag fra Nikita Popov godkendt med stort flertal af stemmerne.

I øjeblikket har vi to forskellige mekanismer til brugerdefineret serialisering af objekter i PHP:

• __sleep () og __wakeup () magiske metoder
• The Serializable interface

Ifølge Nikita har begge disse muligheder problemer, der fører til komplekse og upålidelige kode. Du kan dykke dybt ind i dette emne i RFC. Her nævner jeg bare, at den nye serialiserings-mekanisme bør forhindre disse problemer ved at give to nye magiske metoder, __serialize () og __unserialize (), der kombinerer de to eksisterende mekanismer.

Dette forslag bestod med 20 til 7 stemmer.

Deprecations

Følgende funktioner / funktionaliteter fjernes med PHP 7.4. For en mere omfattende liste over afskrivninger, så tjek PHP 7.4 opgraderings-noter.

Ændre præcedens for samkøringsoperatøren

I PHP er “+” og “-” aritmetiske operatører og “.” Strengoperatøren for tiden forbundne og har samme prioritet (læs mere om Operator Precedence).

F.eks. Overvej følgende linje:

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

I PHP 7.3 producerer denne kode følgende advarsel:

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

Dette fordi sammenkoblingen evalueres fra venstre mod højre. Det er det samme som at skrive følgende kode:

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

Denne RFC foreslår at ændre operatørernes forrang, idet “.” Der er lavere prioritet end “+” og “-” operatører, således at tilføjelser og subtraktioner altid vil blive udført før strengforbindelsen. Denne linje af kode skal svare til følgende:

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

Dette er et to-trins forslag:

• Fra og med version 7.4 skal PHP udsende en meddelelse om deprecation, når der opstår et uhæmmet udtryk med “+”, “-” og “.”.
• Den faktiske forandring af forrang for disse operatører skal tilføjes med PHP 8.

Begge forslag er godkendt med stort flertal af stemmerne.

Deprecate venstre-associative ternær operatør

I PHP er den ternære operatør, i modsætning til mange andre sprog, venstreforbundende. Ifølge Nikita Popof kan dette være forvirrende for programmører, der skifter mellem forskellige sprog.

I PHP er følgende kode korrekt:

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

Det fortolkes som:

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

Og det kan føre til fejl, fordi det måske ikke er, hvad vi har til hensigt at gøre. Så denne RFC foreslår at deprecere og fjerne brugen af venstre-associativitet for ternære operatører og tvinge udviklere til at bruge parenteser.

Dette er et andet to-trins forslag:

• Fra PHP 7.4 vil indlejrede ternarer uden eksplicit brug af parenteser kaste en deprecationsadvarsel.
• Fra PHP 8.0 vil der være en kompilering runtime fejl.

Dette forslag er godkendt med 35 til 10 stemmer.

Hvad betyder PHP 7.4 for WordPress-brugere?

PHP er det mest udbredte programmeringssprog på serversiden på nettet. Ifølge W3Techs bruges PHP-brug pr. 2. december 2019 af 78,9% af alle websteder, som har programmeringssprog på serversiden, som de kan registrere.

Desværre anvendes PHP 5 stadig af 44,0% af alle websteder med et kendt programmeringssprog på server-side. Hvis du tilføjer antallet af brugere, der stadig bruger PHP 7.0 og 7.1,  viser det sig, at et stort flertal af websteder kører ikke understøttede versioner af PHP.

I henhold til den officielle WordPress Stats-side kører 64% af alle WordPress-websteder med ikke-understøttede versioner af PHP fra skrivning af dette. Kun lidt over 13% bruger PHP 7.3. Og den nyeste version, PHP 7.4, dukker ikke engang op endnu. Du kan se, at et stort flertal af brugere, over 23%, stadig kører på PHP 5.6 .

Vi anbefaler stærkt at spørge din vært for en understøttet version af PHP, helst i henhold til de officielle krav fra WordPress. Som dette skrives, maj 2019 kræver WordPress:

• PHP version 7.3 eller nyere.
• MySQL version 5.6 eller nyere ELLER MariaDB version 10.1 eller nyere.
• HTTPS-support

PHP 7 Performance

Tallene ovenfor er især nedslående kommer fra et præstationssynspunkt, da PHP 7 har vist sig at være betydeligt hurtigere. Her er et par statistikker:

• Officielle PHP-benchmarks viser, at PHP 7 gør det muligt for systemet at udføre dobbelt så mange anmodninger pr. sekund i sammenligning med PHP 5.6 ved næsten halvdelen af ​​latens.
• Christian Vigh offentliggjorde også en PHP præstations sammenligning, hvor han fandt ud af at PHP 5.2 var 400% langsommere end PHP 7.
• Andrei Avram så hurtigere eksekveringstider og mindre hukommelsesforbrug i PHP 7,4 vers, nemlig PHP 7.3
• Phoronix løb nogle tidlige benchmark-test med PHP 7.4 Alpha og så, at det var lidt hurtigere end PHP 7.3.

Upgraded my @kinsta site to PHP 7.4 and it is like 10x faster. Woot!

— Ronald Huereca (@RonaldHuereca) December 2, 2019

Vi kørte vores egne PHP performance benchmarks med PHP 7.3. Vi så, at WordPress 5.0 på PHP 7.3 kunne udføre næsten tre gange så mange transaktioner (anmodninger) pr. sekund i forhold til PHP 5.6. Vi frigiver PHP 7.4 benchmarks snart!

• WordPress 5.0 PHP 5.6 benchmark: 91,64 req / sek
• WordPress 5.0 PHP 7.0 benchmark resultater: 206.71 req / sek
• WordPress 5.0 PHP 7.1 benchmark resultater: 210.98 req / sek
• WordPress 5.0 PHP 7.2 benchmark resultater: 229.18 req / sek
• WordPress 5.0 PHP 7.3 benchmark resultater: 253.20 req / sek 🏆

Mange er langsomme til at opdatere på grund af den tid, der er involveret i testning af nye alle deres tredjeparts plugins og temaer for at sikre, at de fungerer korrekt. Men mange gange kommer det ned til, at de simpelthen ikke har gjort det endnu.

Kontrol af din PHP-version

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-anmodningsoverskrift viser typisk versionen.

Dette afhænger af, at værten ikke ændrer X-Powered-By header-værdien. Men mange gør af sikkerhedsmæssige grunde (herunder Kinsta). Hvis det er tilfældet, kan du muligvis ikke se din PHP-version. I så fald, hvis du kører WordPress 5.2 eller nyere, er der et nyt websteds-sundhedsværktøj, du kan bruge. Gå over til “Værktøjer” → “Site Health” → “Info” og under “Server” sektionen finder du din servers PHP-version.

Alternativt kan du installere et gratis plugin som Version Info, som viser dig nogle grundlæggende serveroplysninger i foden af dit WordPress admin dashboard. Et par andre måder at se din PHP-version på er at uploade en fil via FTP, eller blot nå ud til din vært og spørge.

Opdatering til PHP 7.4

Den endelige version af PHP 7.4 er tilgængelig lige nu på Kinsta. Alternativt kan du teste dit WordPress-sted lokalt eller kontrollere dine scripts i et miljø som Docker, som giver dig mulighed for at teste forskellige versioner af PHP fra kommandolinjen.

Den nemmeste måde at starte test er at skabe et scenemiljø, da dette ligner dit live produktionssted meget. Klik på dit websted i MyKinsta-betjeningspanelet og skift miljøet til scene. .

Skift derefter din PHP-motor under “Værktøjer” -menuen over til PHP 7.4 (Beta). Du kan derefter begynde at teste for at sikre kompatibiliteten af din kode, tredjeparts plugins og temaer.

Som med tidligere versioner af PHP understøtter vores selvhelende PHP-funktion PHP 7.4 fuldt ud. Hvis PHP falder af en eller anden grund, genstarter vi det automatisk. Hvis genstarten ikke løser problemet, advarer vores overvågningssystem vores sysadmin-team om at undersøge årsagen til problemet.

Se detaljer vedrørende PHP 7.4 frigivelse på Kinsta.

Installation og kørsel af PHP 7.4 på Docker

Vil du teste det på Docker? Heldigvis behøver du ikke at kompilere og konfigurere PHP 7.4 manuelt. Hvis du allerede har Docker installeret på dit system, skal du bare installere det uofficielle PHP-FPM 7.4 Docker-billede og køre dine tests fra kommandolinjen på få sekunder.

Hvis du foretrækker at køre din PHP 7.4-kode i din browser, skal du også installere et Nginx- eller Apache-billede. Men ingen bekymringer. Bare følg udviklerens anvisninger. Kopier og indsæt kommandoer fra Docker Image-siden til dit kommandolinjeværktøj, og du er klar til at køre.

Resumé

I dette indlæg dækkede vi et stort antal ændringer og tilføjelser, som vi kan forvente med udgivelsen af ​​PHP 7.4. Hvis du leder efter den fulde liste over funktioner sammen med den officielle RFC-dokumentation, skal du tjekke følgende ressourcer:

• PHP 7.4 Anmodninger om kommentarer
• PHP 7.4 Upgrade Notes
• PHP 7.4 Forberedelsesopgaver

Vi holder dig opdateret med alle de nyeste oplysninger om PHP 7.4. Hvis du er en Kinsta-klient, kan du allerede begynde at flytte dine WordPress-websteder til den nyeste version.

Er du klar til at installere og teste de kommende PHP-funktioner? Hvilken er din favorit? Del dine tanker med os i kommentarerne nedenfor.