Fra den 6. december 2018 er den seneste og største version, PHP 7.3, her! Med det kommer nye nyttige funktioner, funktionaliteter, deprecations, et stort antal fejlrettelser og et boost i ydeevne. PHP 7.3 er også nu tilgængelig for alle Kinsta-klienter i MyKinsta dashboard. 🤘

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

I dette indlæg giver vi et overblik over de funktioner og ændringer, som vi personligt anser som mest relevante. Men du kan altid kontrollere den fulde liste over funktioner, ændringer og fejlrettelser i PHP 7.3 Opgrader noter og PHP 7.3 Anmodninger om kommentarer.

Opdatering: PHP 7.4 (officiel udgivelse) er nu tilgængelig for alle Kinsta-klienter.

Hvad er Nyt i PHP med PHP 7.3?

I dette indlæg dækker vi følgende PHP 7,3 ændringer:

Fleksible Heredoc og Nowdoc Syntakser

Dette er nok en af de mest relevante forbedringer, der kommer med PHP 7.3, og vi synes det fortjener lidt mere opmærksomhed. Så før vi dyker ind i PHP 7.3 heredoc/nudoc ændringer, giver vi et hurtigt overblik over denne nyttige kernefunktion. Hvis du allerede er sikker på nudoc og heredoc, er du velkommen til at hoppe til PHP 7.3-ændringerne.

Et overblik over heredok og nudoc syntakser

Heredok-syntaxen giver mulighed for at tilføje en stor mængde tekst uden at skulle undslippe ting som dobbelt citater. En heredok starter med <<< efterfulgt af en markør, og slutter med samme markør efterfulgt af en semikolon. Her er et eksempel:

udskriv <<<EOT
Heredoc-teksten opfører sig som en dobbeltciteret streng uden de dobbelte citater.
EOT;

En nudoc opfører sig meget som en heredoc, med nogle undtagelser

  • Identifikatoren er indeholdt i enkelte citater
    (<<<'EOT')
  • Ingen passering sker inden for en nowdoc

Her er et eksempel på nowdoc

print <<<'EOT'
Nowdocs are to single-quoted strings what heredocs are to double-quoted strings.
EOT;

Heredocs og nowdocs deler de samme regler som regulerer brugen af lukkemærket:

  1. Lukmarkøren skal begynde i linjens første kolonne
  2. Markøren skal følge de samme navngivningsregler som enhver anden etiket i PHP: den må kun indeholde alfanumeriske tegn og understregninger og skal starte med et ikke-ciffert tegn eller understregning.

PHP Manual advarer:

Det er meget vigtigt at bemærke, at linjen med den afsluttende identifikator ikke må indeholde andre tegn, undtagen et semikolon(;). Det betyder især, at identifikatorenmåske ikke er indrykket, der må ikke være nogen mellemrum eller faner før eller efter semikolonet. Det er også vigtigt at indse, at det første tegn før den afsluttende identifikator skal være en ny linje som defineret af det lokale operativsystem. Dette er \n på UNIX-systemer, herunder macOS. Den afsluttende delimiter skal også efterfølges af en ny linje.

PHP 7.2 ugyldig syntaks:

class foo {
    public $bar = <<<EOT
    bar
    EOT;
}
// Identifier must not be indented

PHP 7.2 gyldig syntaks:

class foo {
    public $bar = <<<EOT
bar
EOT;
}

For at holde det kort, i PHP 7.2:

  • Den afsluttende markør må ikke være indrykket
  • Linjen med lukkemarkøren må ikke indeholde tegn som mellemrum eller faner
  • Det første tegn før lukkemærket skal være en ny linje
  • Afslutningsmarkøren skal efterfølges af en ny linje

Det er klart nok, at heredok og nudoc-syntaks er ret restriktive, men PHP 7.3 kan ændre dette lidt med følgende forbedringer.

1. Tillad, at den afsluttende markør er indrykket, og at den ledende hvide plads skal fjernes

Med PHP 7,3 har vi lov til at indrykke lukkemarkøren, og vi kan trygt skrive følgende kode:

class foo {
    public $bar = <<<EOT
        bar
    EOT;
}

Indtastningen af den lukkende markør angiver mængden af hvide rum (eller faner), som vil blive fjernet fra hver linje af kroppen. Men pas på: Den afsluttende markør skal aldrig være indrykket længere end nogen anden linje i kroppen.

Se koden nedenfor:

class foo {
    public $bar = <<<EOT
    bar
        EOT;
}

Koden ovenfor ville udstede følgende parse fejl:

Parse-fejl: Ugyldigt organindrykningsniveau (forventer en indrykning i det mindste ...) i%s på linje%d

Stripping faner og whitespaces tillader os at inddrage heredoc / nudocs kropp til det samme niveau af koden rundt, og uden unødvendig hvide plads før hver linje af kroppen.

Vi kan bruge både faner og mellemrum til indrykning, men vi må ikke bruge dem sammenblandet. Det betyder, atvi skal bruge de samme indrykningskarakterer til lukkemarkøren og alle linjer i kroppen. I tilfælde af forskellige indrykningskarakterer forventer vi en anden type parsefejl (ugyldig indrykning).

2. Fjern det efterfølgende nye linjeskrav fra lukkemarkøren

I øjeblikket skal en ny linje følge markøren for at opsige heredok / nudoc. PHP 7.3 ville ændre dette og tillade os at opsige heredoc / nudoc på samme linje. Her er et eksempel fra RFC

PHP 7.2 gyldig syntaks:

$values = [<<<END
a
b
c
END
, 'd e f'];

PHP 7.3 gyldig syntaks:

$values = [<<<END
a
b
c
END, 'd e f'];

Du skal alligevel være forsigtig, når du vælger navnet på din markør, fordi “lejlighedsvis” kan du forvente en fejl, hvis den passer til et ord, du brugte i heredoc / nudoc’s legeme (læs mere her på RFC og GitHub).

Begge forslag bestod med mere end 2/3 stemmer

PHP 7.3 RFC

Yderligere ressourcer

Tillad et Kommende Komma i Funktionsopkald

Kommende kommaer (eller “endelige kommaer”) er kommaer til en liste over elementer, parametre eller egenskaber, og de er nyttige i sammenhænge, ​​hvor nye værdier tilføjes ofte, fordi de forhindrer fejl på grund af et manglende komma. I PHP er kommende kommaer tilladt i arrayer, og fra PHP 7.2 er de tilladt i grupperede navneområder.

Fra PHP 7.3 vil efterfølgende komma være tilladt i funktionserklæringer. Variadiske funktioner giver et eksempel på kontekst, hvor efterfølgende komma er yderst nyttige:

foo(
    $bar,
    $baz,
);

Vi kan bruge et kommende komma, når vi opretter en matrix med compact(), for at returnere en formateret streng med sprintf(), eller når vi fusionerer en matrix:

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

Også kommende kommaer ville være nyttige til debugging:

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

Og de er stærke med unset() og isset():

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

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

Trailing kommaer vil også blive tilladt i metodeopkald og indkapslinger.

Bemærk: Denne ændring vil kun påvirke funktionsopkald. Syntaks for funktionsdeklaration ændres ikke. Desuden vil frie komma, flere kommende kommaer og ledende kommaer ikke blive tilladt.

Yderligere eksempler findes på RFC-siden. Denne RFC bestod med en 30 til 10 stemme.
PHP 7.3 RFC

PHP 7.3 RFC

JSON_THROW_ON_ERROR

En af de mest værdsatte funktioner, der kommer med PHP 7.3, giver en ny måde at håndtere JSON fejl på. Dette er ikke en kernefunktion, men en tilføjelse til JSON-udvidelsen, der ville ændre fejladfærden af json_decode() og json_encode().

I øjeblikket returnerer json_decode() null ved fejl, men null kan også være et gyldigt resultat. Dette kunne være forvirrende, fordi

Det er kun muligt at vide, om der opstod en fejl ved at kalde json_last_error() eller json_last_error_msg(), som returnerer den globale fejltilstand i henholdsvis maskinlæsbare og humanlæsbare formularer. – PHP RFC

json_encode() returnerer FALSE ved fejl. Dette er tydeligere, fordi der er en specifik fejlværdi. I begge tilfælde stopper begge funktioner hverken programkørsel på fejl eller kaster nogen advarsel.

Med det sagt er her forslaget til PHP 7.3:

Denne RFC foreslår i stedet at tilføje en ny valgflagsværdi for json_decode() og json_encode(), JSON_THROW_ON_ERROR. JsonException. Når dette flag er passeret, ændres fejladfærden af disse funktioner. Den globale fejltilstand forbliver uberørt, og hvis der opstår en fejl, der ellers ville sætte den, vil disse i stedet kaste en JsonException med meddelelsen og kodeindstillingen til hvad json_last_error() og json_last_error_msg() ellers ville være.

Her er et eksempel, der viser en simpel måde at smide en JSON-fejl på:

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

At kaste en undtagelse ved fejl ville give flere fordele, som du vil finde opført på RFC.

Bemærk: En ugyldig dybdeparameter, der sendes til json_decode() udsender en advarsel og returnerer NULL. Denne opførsel påvirkes ikke af JSON_THROW_ON_ERROR. På samme måde påvirkes ikke parametreringsfejl af JSON_THROW_ON_ERROR og fortsætter med at producere advarsler.

Dette forslag bestod med 23 til 0 stemmer.

PHP 7.3 RFC

Yderligere ressourcer

list() Reference Assignment

Hvad betyder referenceopgave?

Overvej følgende linje:

$b = &$a;

Her får $b værdien af $a, men den værdi er ikke kopieret fra $a til $b. I PHP kan vi tildele en værdi ved reference, hvilket betyder at to variable kan pege på de samme data, og hver ændring til en variabel påvirker de oprindelige data. Her er an et eksempel fra PHP manualen:

<?php
$a = 3;
$b = &$a; // $b is a reference to $a

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

Lad os nu ændre værdien på $a:

$a = 4; // skift $a

print "$a\n"; // udskriver 4
udskrive "$b\n"; // udskriver også 4, da $b er en henvisning til $a, som er blevet ændret

Hvad er listen() Construct og hvordan det ændrer sig med PHP 7.3

list() sprogkonstruktion kan bruges til at “tildele variabler som om de var i en matrix”, men med list() kan vi for øjeblikket ikke tildele variable værdier ved reference.

PHP 7.3 skal ændre dette, så vi kan tildele variabler ved henvisning også med list() konstruktionen, som vist i følgende eksempel:

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

Hvilket er det samme som:

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

Fordelen med dette forslag er, at vi nu kunne tildele flere variabler som reference, hvilket ikke var tilladt for øjeblikket. Flere eksempler er tilgængelige på RFC. Forslaget bestod med 17 til 7 stemmer.

PHP 7.3 RFC

Yderligere ressourcer

is_countable Funktion

En anden nyttig funktion, der kommer med PHP 7.3, er funktionen is_countable() Op til PHP 7.2, får vi en fejl, når vi forsøger at count() noget, der ikke kan tælles. Af denne grund er vi nødt til at tilføje følgende kode for at undgå en advarsel:

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

Denne RFC foreslår funktionen is_countable(), som returnerer true hvis den givne variabel er en matrix, eller det er en talbar variabel, false ellers. Så kan koden ovenfor ændres som følger:

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

Dette forslag bestod med 25 til 0 stemmer.
PHP 7.3 RFC

PHP 7.3 RFC

Yderligere ressourcer

array_key_first(), array_key_last()

I øjeblikket kan vi hente den første og den sidste nøgle i en matrix ved hjælp af reset(), end() og key() funktioner. Desværre, med disse funktioner, er der ingen måde at samle det første eller det sidste indeks i et array uden at ændre sin interne tilstand. Andre muligheder reducerer normalt læsbarhed og ydeevne.

Dette forslag vil ændre dette scenario ved at tilføje to nye funktioner til PHP kernen:

  • array_key_first()
  • array_key_last()

Fra PHP 7.3, array_key_first() og array_key_last() mulighed for at hente den første og den sidste tast i et givet array uden at påvirke den interne arraypeger. Disse nye funktioner vil give os mulighed for at skrive mindre kompleks kode og i nogle tilfælde undgå fejl. Se RFC for yderligere information og flere eksempler.

array_key_first() og array_key_last() er blevet godkendt med 18 til 14 stemmer.

Bemærk: Den oprindelige RFC foreslog to funktioner, array_value_first() og array_value_last(), som blev stemt i en anden afstemning, men ikke blevet godkendt og vil ikke blive en del af PHP-kernen.

PHP 7.3 RFC

Yderligere ressourcer

Argon2 Password Hash Enhancements

Argon2 er en hashingalgoritme implementeret i som et alternativ til Bcrypt-algoritmen. PHP 7.2 introduceredePASSWORD_ARGON2I constant, konstanten, der kan bruges tilpassword_* funktioner:

password_hash('password', PASSWORD_ARGON2I);

Siden den første implementering er der tilføjet en ny variant af Argon2, så på tidspunktet for denne skrivning kommer Argon2 i tre varianter:

  • Argon2d maksimerer modstand mod GPU krakningsangreb. Det er hurtigere og bruger dataafhængig hukommelsesadgang.
  • Argon2i bruger data-uafhængig hukommelse adgang, som er foretrukket for password hashing. Det er langsommere, da det gør mere passerer over hukommelsen for at beskytte mod offoff-angreb.
  • Argon2id er en hybrid version, der kombinerer Argon2i tilgangen til den første overgangshukommelse og Argon2d tilgangen til efterfølgende pass.

Argon2id anbefales på internettet, undtagen når der er gode grunde til specifikt at foretrække en anden variant.

Den nye RFC foreslår implementeringen af Argon2id inden for password_* -funktionerne med den nyePASSWORD_ARGON2ID-konstant:

password_hash('password', PASSWORD_ARGON2ID);

Implementeringen er identisk med Argon2i implementeringen og vil acceptere de samme omkostningsfaktorer:

  • En hukommelsesomkostning der definerer antallet af KiB, der skal indtages under hashing (standardværdier er 1 << 10 eller 1024 KiB eller 1 MiB)
  • En tidsomkostning der definerer antallet af iterationer af hashingalgoritmen (standard til 2)
  • En parallelismefaktor, som angiver antallet af parallelle tråde, der vil blive brugt under hashing (standard til 2)

Se følgende kode:

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

Flere oplysninger og eksempler på RFC.

PHP 7.3 RFC

Yderligere ressourcer

Deprecations

Følgende funktioner/funktionaliteter fjernes med PHP 7.3 og fjernes senest PHP 8.0.

Udskrive og fjerne image2wbmp()

Funktionen image2wbmp() udsender eller gemmer en WBMP -version af et givet billede. Denne funktion tager tre argumenter: en billedressource, et filnavn (stien til den gemte fil) og en forgrundsfarve.

Fra PHP 5.0 er det identisk med imagewbmp(), så denne RFC foreslår at deprecere og fjerne det.
Siden PHP 7.3, ville hvert opkald til image2wbmp() udstede en deprecation advarsel. Efter fjernelsen vil hvert opkald kaste en fatal fejl.

PHP 7.3 RFC

Udskrive og fjerne sag-ufølsomme konstanter

PHP understøtter i øjeblikket både case-sensitive og case-insensitive konstanter. Alligevel understøttes tilfælde af, ufølsomme konstanter men anses for at være uoverensstemmende i funktionaliteter og at være komplekse at bruge.
Dette forslag begynder med følgende lokaler:

  • Klassekonstanter er
  • globale konstanter erklæret med const er altid sagerfølsomme
  • Konstanter defineret meddefine() er som standard store bogstaver

Derudover hedder PHP Sprogreferencen udtrykkeligt:

En konstant er som standard store bogstaver. Ved konventionen er konstante identifikatorer altid store bogstaver.

Når det er sagt, foreslår denne RFC følgende ændringer:

  • Deprecate calling define() med tredje parameter sæt til true – PHP 7.3
  • Deprecate adgang til tilfælde-ufølsomme konstanter med et hus forskelligt fra erklæringen (med undtagelse af true, false og null) – PHP 7.3
  • Fjern muligheden for at erklære sag-ufølsomme konstanter – PHP 8.0
  • Konverter true, false og null fra special-cased konstanter til reserverede søgeord – PHP 8.0

PHP 7.3 RFC

Udskrive og fjern Case-Insensitive.

Yderligere afskrivninger for PHP 7.3

Her er en hurtig liste over funktionaliteter afskrevet i PHP 7.3. Det er ikke udtømmende, de er bare de deprecationsforslag, som jeg personligt anser mere relevante. For en komplet liste over foreslåede afskrivninger, se Afskrivninger for PHP 7.3.

Ikke-dokumenterede mbstring-funktionaliaser: Der er en række ubibliotekerede mbstring-funktionaliaser der er duplikater af tilsvarende funktioner ved hjælp af mb_-præfiks. For eksempel er mbereg et alias af mb_ereg.
Alle disse funktioner vil blive markeret som forældet, og en afskrivningsmeddelelse vil blive kastet, når de opstår under kompilering

Stringsøgningsfunktioner med heltalsnål: Disse funktioner fungerer normalt på strengnåle. Hvis en ikke-strengnål gives, konverteres den til et helt tal og anvendes som ordinær værdi af et tegn (læs mere på PHP nanualen). Her er et eksempel fra RFC:

$str = "There are 10 apples";
var_dump(strpos($str, "10")); // int(10)
var_dump(strpos($str, 10));   // bool(false)

Dette anses for at være forvirrende og forårsage uforudsigelige problemer, fordi typen kan ændre sig med brugerdatakilden. Af denne grund foreslår RFC spørgsmålet om en deprecationsadvarsel, hvis en nål med nålestrøm passerer til en af ​​følgende funktioner:

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

I PHP 8.0 skal afskrivningsadvarslen fjernes, og nålene skal automatisk konverteres til strenge.

fgetss()-funktionen og string.strip_tags stream filter: fgetss() og string.strip_tags strimmelmærker fra en stream, da de læser den. Både funktionen og filteret afslører strip_tags()-funktionen, hvilket gør implementeringen af strip_tags() mere kompleks, da der kræves en streaming state-maskine. Derudover påpeger RFC en anden ulempe ved disse funktioner:

På den anden side synes disse funktioner at være af meget lidt nytteværdi. strip_tags() selv på grund af sine begrænsninger og kendte fejl har allerede meget få legitime applikationer. Der er ikke behov for at levere indbygget support til streaming applikation oven på det.

Så RFC foreslår at markere fgetss(), gzgetss() og SplFileObject::fgetss() som udskrevet.

Hvad Betyder PHP 7.3 for WordPress-Brugere?

Ifølge den officielle WordPress Stats-side, som skrevet af dette, har kun 32,9% af WordPress-brugere opgraderet til PHP 7 eller højere. Kun 4% bruger PHP 7.2. Du kan se, at et stort flertal af brugere, over 38%, stadig kører på PHP 5.6. Hvad der endda er skræmmende er, at over 28,5% af brugerne bruger ikke-understøttede PHP-versioner. I december 2016 ramte WordPress.org faktisk deres officielle anbefaling til brugere fra PHP 5.6 til PHP 7 eller højere.

WordPress PHP versioner
WordPress PHP versioner

PHP 7 Performance

Tallene ovenfor er især afskræmmende 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 tillader, at systemet udfører dobbelt så mange anmodninger pr. Sekund i sammenligning med PHP 5.6 ved næsten halvdelen af latensen.
  • Christian Vigh offentliggjorde også en a PHP præstations sammenligning hvor han fandt ud af, at PHP 5.2 var 400% langsommere end PHP 7.

Vi kørte vores egne PHP performance benchmarks. Og på samme måde som benchmarks ovenfor så vi, 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.

WordPress 5.0 PHP benchmarks
WordPress 5.0 PHP benchmarks
  • 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🏆

Det er også interessant at bemærke, at WordPress 4.9.8 på PHP 7.3 var lidt hurtigere end WordPress 5.0.

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

Mange er langsomme om at opdatere på grund af den tid, der er involveret i testning af alle deres nye 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.

Check version af PHP
Check version af PHP

Dette afhænger af, at værten ikke ændrer værdien X-Powered-By header. Hvis de gør det, kan du muligvis ikke se din PHP-version. I så fald kan du også installere et gratis plugin som Version Info hvilket vil vise dig nogle grundlæggende serveroplysninger i foden af dit WordPress admin dashboard.

Tjek PHP version i WordPress
Tjek PHP version i WordPress

Alternativt kan du også uploade en fil via FTP for at se din PHP-version eller nå ud til din vært og spørge.

Opdatering til PHP 7.3

Den endelige version af PHP 7.3 er her, og du kan begynde at teste det med det samme. Du kan teste dit WordPress-websted lokalt eller kontrollere dine scripts i et miljø som Docker, som giver dig mulighed for at teste forskellige versioner af PHP fra kommandolinjen.

Eller du kan udnytte et scenemiljø, da det ligner et live produktionssted. Opret et a scenemiljø med et par enkle klik i MyKinsta dashboard.

WordPress staging scenemiljø
WordPress staging scenemiljø

Vi anbefaler altid at teste grundigt, inden du bruger det på et produktionssted. For at gøre det, skal du simpelthen ændre PHP-motoren til installationsstedet under “Værktøjer”, og du kan begynde at teste, for at sikre kompatibiliteten af dine tredjeparts plugins og temaer.

Skift til PHP 7.3
Skift til PHP 7.3

Når du har bekræftet, at alt fungerer, kan du enten ændre dit produktionssted over til PHP 7.3 eller hvis du har foretaget ændringer, skal du også sætte din scene-side til live.

Resumé

Den nyeste og bedste version af PHP er her. Det bringer os gaver som fleksible heredocs og nudocs, kommende kommaer i funktionsopkald, list () referenceopgaver og mere. I dette indlæg har vi givet et overblik over vores foretrukne forbedringer og ændringer, men vi vil også gerne vide, hvilke er dine foretrukne, og på hvilke måder vil du udnytte dem. Lad os vide det i kommentarerne nedenfor.

Du kan finde den fulde liste over PHP 7.3-forslag på siden Forespørgsler til kommentarer og GitHubs PHP 7.3 Upgrade Notes.

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.