PHP 7.4, la più recente minor release di PHP 7, è stato rilasciato alla General Availability il 28 novembre 2019. Quindi è il momento per noi di analizzare alcune delle novità e delle funzionalità più interessanti che rendono PHP più veloce e affidabile.
Aggiornamento: PHP 8.1 (versione ufficiale) è ora disponibile per tutti i clienti Kinsta. Kinsta non supporta più PHP 7.4. Supportiamo invece le versioni di PHP 8.0, 8.1, 8.2 e 8.3.
Anche se PHP 7.4 migliora significativamente le prestazioni e la leggibilità del codice, PHP 8 sarà la vera pietra miliare per le prestazioni di PHP, poiché la proposta di inclusione di JIT è già stata approvata.
Ad ogni modo, oggi analizzeremo insieme alcune delle funzionalità e delle modifiche più interessanti che ci attendiamo da PHP 7.4. Giusto per registrazione, queste sono state le date importanti che hanno portato al rilascio di PHP 7.4::
- 6 giugno: PHP 7.4 Alpha 1
- 18 luglio: PHP 7.4 Beta 1 – Congelamento delle funzionalità
- 28 novembre: rilascio di PHP 7.4 per la GA
Potete trovare l’elenco completo delle funzionalità e delle novità nella pagina ufficiale della RFC.
Cosa c’è di nuovo in PHP con PHP 7.4?
In questo post analizziamo diverse novità e funzionalità aggiunte al linguaggio con il rilascio definitivo di PHP 7.4:
Dimenticatevi di array_merge: PHP 7.4 Porta lo Spread Operator nell’Espressione degli Array
Disponibile a partire da PHP 5.6, lo spacchettamento degli argomenti è una sintassi che permette di decomprimere array e Traversables in elenchi di argomenti. Per decomprimere un array o un Traversable, è necessario anteporvi … (3 punti), come mostrato nell’esempio che segue:
function test(...$args) { var_dump($args); }
test(1, 2, 3);Ora, questa RFC di PHP 7.4 propone di estendere questa funzionalità alle definizioni degli array:
$arr = [...$args];Il primo vantaggio dichiarato dello Spread Operator nell’espressione dell’array riguarda le prestazioni. Infatti, il documento dell’RFC afferma:
Lo Spread Operator dovrebbe avere prestazioni migliori rispetto a
array_merge. Questo non solo perché lo Spread Operator è una struttura del linguaggio mentrearray_mergeè una chiamata di funzione, ma anche perché l’ottimizzazione del tempo di compilazione può essere performante per gli array di costanti.
Un vantaggio significativo dello Spread Operator è che supporta qualsiasi oggetto traversable, mentre la funzione array_merge supporta solo gli array.
Ecco un esempio di spacchettamento degli argomenti nell’espressione di array:
$parts = ['apple', 'pear'];
$fruits = ['banana', 'orange', ...$parts, 'watermelon'];
var_dump($fruits);Se si dovesse eseguire questo codice con PHP 7.3 o versioni precedenti, PHP genererebbe un Parse error:
Parse error: syntax error, unexpected '...' (T_ELLIPSIS), expecting ']' in /app/spread-operator.php on line 3Invece PHP 7.4 restituisce un array:
array(5) {
[0]=>
string(6) "banana"
[1]=>
string(6) "orange"
[2]=>
string(5) "apple"
[3]=>
string(4) "pear"
[4]=>
string(10) "watermelon"
}L’RFC afferma che possiamo espandere lo stesso array più volte. Inoltre, possiamo utilizzare la sintassi dello Spread Operator ovunque nell’array, dato che è possibile aggiungere elementi normali prima o dopo lo Spread Operator. Per questo, il codice che segue funzionerà nel modo in cui potremmo aspettarci:
$arr1 = [1, 2, 3];
$arr2 = [4, 5, 6];
$arr3 = [...$arr1, ...$arr2];
$arr4 = [...$arr1, ...$arr3, 7, 8, 9];È anche possibile decomprimere gli array restituiti da una funzione direttamente in un nuovo array:
function buildArray(){
return ['red', 'green', 'blue'];
}
$arr1 = [...buildArray(), 'pink', 'violet', 'yellow'];PHP 7.4 produce il seguente 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"
}Possiamo anche utilizzare la generator syntax:
function generator() {
for ($i = 3; $i <= 5; $i++) {
yield $i;
}
}
$arr1 = [0, 1, 2, ...generator()];Tuttavia non possiamo decomprimere gli array passati per riferimento (by reference). Considerate il seguente esempio:
$arr1 = ['red', 'green', 'blue'];
$arr2 = [...&$arr1];Se provassimo a decomprimere un array per riferimento, PHP genererebbe il seguente Parse error:
Parse error: syntax error, unexpected '&' in /app/spread-operator.php on line 3Ad ogni modo, se gli elementi del primo array sono memorizzati per riferimento, saranno memorizzati per riferimento anche nel secondo array. Ecco un esempio:
$arr0 = 'red';
$arr1 = [&$arr0, 'green', 'blue'];
$arr2 = ['white', ...$arr1, 'black'];Ed ecco cosa otteniamo con 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"
}La proposta dello Spread Operator è stata approvata con 43 voti favorevoli contro 1.
Arrow Functions 2.0 (Short Closures)
In PHP, le funzioni anonime sono considerate piuttosto prolisse e difficili da implementare e mantenere. Questa RFC propone l’introduzione di una sintassi più sintetica e più chiara per le arrow functions (o short closures), che dovrebbe permetterci di ripulire in modo significativo il nostro codice PHP.
Considerate il seguente esempio:
function cube($n){
return ($n * $n * $n);
}
$a = [1, 2, 3, 4, 5];
$b = array_map('cube', $a);
print_r($b);PHP 7.4 permette di utilizzare una sintassi più concisa, e la funzione qui sopra potrebbe essere riscritta come segue:
$a = [1, 2, 3, 4, 5];
$b = array_map(fn($n) => $n * $n * $n, $a);
print_r($b);Attualmente, le funzioni anonime (closure) possono ereditare variabili definite nello scopo superiore (parent scope) grazie al costrutto di linguaggio use, come mostrato di seguito:
$factor = 10;
$calc = function($num) use($factor){
return $num * $factor;
};Ma con PHP 7.4, le variabili definite nel parent scope sono catturate implicitamente per valore (implicit by-value scope binding). Possiamo, quindi, scrivere l’intera funzione vista sopra su una singola riga:
$factor = 10;
$calc = fn($num) => $num * $factor;La variabile definita nel parent scope può essere utilizzata nella arrow function esattamente come se stessimo utilizzando use($var), e non è possibile modificare una variabile dal parent scope.
La nuova sintassi rappresenta un notevole miglioramento del linguaggio in quanto ci consente di creare codice più leggibile e gestibile. Possiamo anche utilizzare parametri e tipi di ritorno, valori predefiniti, liste di argomenti a lunghezza variabile (funzioni variadiche), possiamo passare e restituire per riferimento, ecc. Infine, le short closure possono essere utilizzate anche in metodi di classe e possono fare uso della variabile $this esattamente come le normali closure.
Questa RFC è stata approvata con 51 voti favorevoli contro 8.
Operatore di Assegnazione di Coalescenza Nulled
Aggiunto con PHP 7, l’operatore di coalescenza (??) è utile quando abbiamo bisogno di un operatore ternario insieme a isset(). Questo restituisce il primo operando, se questo esiste e non è NULL. In caso contrario, restituisce il secondo operando. Ecco un esempio:
$username = $_GET['user'] ?? 'nobody';Questo codice fa una cosa piuttosto semplice: recupera il parametro della richiesta e imposta un valore predefinito nel caso in cui questo non esista. Il significato di questa riga di codice è chiaro, ma cosa accadrebbe se avessimo nomi di variabili molto più lunghi, come in questo esempio della RFC?
$this->request->data['comments']['user_id'] = $this->request->data['comments']['user_id'] ?? 'value';Nel lungo termine, questo codice potrebbe essere un po’ difficile da mantenere. Quindi, con l’obiettivo di aiutare gli sviluppatori a scrivere codice più intuitivo, questa RFC propone l’introduzione dell’operatore di assegnazione null coalesce (??=). Quindi, invece di scrivere il codice precedente, potremmo scrivere quanto segue:
$this->request->data['comments']['user_id'] ??= 'value';Se il valore del parametro di sinistra è null, viene utilizzato il valore del parametro di destra.
Si noti che, mentre l’operatore di coalescenza è un operatore di confronto, ??= è un operatore di assegnazione.
Questa proposta è stata approvata con 37 voti favorevoli e 4 contrari.
Typed Properties 2.0
Le dichiarazioni del tipo dell’argomento, o type hint, consentono di specificare il tipo di una variabile che si prevede venga passata a una funzione o a un metodo di classe. I type hint sono disponibili sin da PHP 5 e, a partire da PHP 7.2, li possiamo utilizzare con il tipo di dati object. Ora PHP 7.4 spinge il type hinting un passo avanti, aggiungendo il supporto per le dichiarazioni del tipo di proprietà di prima classe. Ecco un esempio molto semplice:
class User {
public int $id;
public string $name;
}Sono supportati tutti i tipi, ad eccezione di void e callable:
public int $scalarType;
protected ClassName $classType;
private ?ClassName $nullableClassType;La RFC spiega il motivo per cui void e callable non sono supportati:
Il tipo void non è supportato perché non è utile e ha una semantica poco chiara.
Il tipo callable non è supportato perché il suo comportamento dipende dal contesto.
Quindi possiamo tranquillamente usare bool, int, float, string, array, object, iterable, self, parent, qualsiasi nome di classe o di interfaccia e i nullable types (?type).
I tipi possono essere utilizzati su proprietà statiche:
public static iterable $staticProp;Sono inoltre ammessi con la notazione var:
var bool $flag;È possibile impostare valori di proprietà predefiniti, che ovviamente devono corrispondere al tipo di proprietà dichiarato, ma solo le proprietà nullable possono avere null come valore predefinito:
public string $str = "foo";
public ?string $nullableStr = null;Lo stesso tipo si applica a tutte le proprietà di una singola dichiarazione:
public float $x, $y;Cosa succede se commettiamo un errore sul tipo di proprietà? Consideriamo il seguente codice:
class User {
public int $id;
public string $name;
}
$user = new User;
$user->id = 10;
$user->name = [];Nel codice qui sopra, abbiamo dichiarato un tipo di proprietà string, ma abbiamo impostato un array come valore della proprietà. In tale situazione, otteniamo il seguente Fatal error:
Fatal error: Uncaught TypeError: Typed property User::$name must be string, array used in /app/types.php:9Questa RFC è stata approvata con 70 voti contro 1.
Weak References
Con questa RFC, PHP 7.4 introduce la classe WeakReference, che consente ai programmatori di mantenere un riferimento a un oggetto che non impedisce che l’oggetto stesso venga distrutto.
Attualmente PHP supporta le Weak References con il ricorso ad un’estensione come pecl-weakref. Ad ogni modo, la nuova API è diversa dalla classe WeakRef documentata.
Ecco un esempio dell’autore di questa proposta, Nikita Popov:
$object = new stdClass;
$weakRef = WeakReference::create($object);
var_dump($weakRef->get());
unset($object);
var_dump($weakRef->get());Il primo var_dump stampa object(stdClass)#1 (0) {}, mentre il secondo var_dump stampa NULL, dato che l’oggetto di riferimento è stato distrutto.
Slides for my PHP 7.4 talk at #PHPRussia2019. Was a great conference!https://t.co/zLr9Bj2aKl
— Nikita Popov (@nikita_ppv) May 19, 2019
Questa RFC è stata approvata con 28 voti a 5.
Tipi di Ritorno Covarianti e Parametri Controvarianti
La varianza è una proprietà delle gerarchie di classe che descrive il modo in cui i tipi di un costruttore di tipi influenzano i sottotipi. In generale, un costruttore di tipi può essere:
- Invariante: se il tipo del super-tipo vincola il tipo del sottotipo.
- Covariante: se l’ordine dei tipi viene mantenuto (i tipi vengono ordinati dai più specifici ai più generici).
- Controvariante: se l’ordine dei tipi viene invertito (i tipi vengono ordinati dai più generici ai più specifici).
Attualmente, PHP ha per lo più parametri e tipi di ritorno invarianti, con poche eccezioni. Questa RFC propone di consentire covarianza e controvarianza su tipi di parametri e tipi di ritorno, e fornisce anche diversi esempi di codice.
Ecco un esempio di tipo di ritorno covariante:
interface Factory {
function make(): object;
}
class UserFactory implements Factory {
function make(): User;
}Ed ecco un esempio di tipo di parametro controvariante:
interface Concatable {
function concat(Iterator $input);
}
class Collection implements Concatable {
// accepts all iterables, not just Iterator
function concat(iterable $input) {/* . . . */}
}Si veda la RFC per uno sguardo più da vicino alla covarianza e alla controvarianza in PHP 7.4.
Questa RFC è passato con 39 voti a 1.
Preloading
Questa proposta di Dmitry Stogov è una delle nostre preferite perché dovrebbe portare un significativo miglioramento delle prestazioni. Il Preloading è il processo di caricamento di librerie e framework nell’OPCache nella fase di inizializzazione del modulo (maggiori informazioni sul ciclo di vita di PHP).
Ecco come funziona il Preloading nelle parole di Dmitry:
All’avvio del server – prima che venga eseguito qualsiasi codice dell’applicazione – possiamo caricare in memoria un certo set di file PHP e rendere i loro contenuti “permanentemente disponibili” a tutte le richieste successive che saranno servite da quel server. Tutte le funzioni e le classi definite in questi file saranno disponibili per le richieste nativamente, esattamente come le entità interne.
Questi file vengono caricati all’avvio del server, vengono eseguiti prima di qualsiasi applicazione e rimangono disponibili per eventuali richieste future. È fantastico in termini di prestazioni.
Il Preloading è controllato da una specifica direttiva php.ini: opcache.preload. Questa direttiva specifica uno script PHP da compilare ed eseguire all’avvio del server. Questo file può essere utilizzato per precaricare file aggiuntivi, includendoli oppure tramite la funzione opcache_compile_file() (si legga di più al riguardo nella documentazione di PHP).
Ma c’è un rovescio della medaglia. Infatti la RFC afferma esplicitamente:
i file precaricati rimangono memorizzati nella memoria opcache per sempre. La modifica dei corrispondenti file sorgente non avrà alcun effetto senza un altro riavvio del server.
Tuttavia, tutte le funzioni definite nei file precaricati verranno caricate permanentemente nelle tabelle delle funzioni e delle classi PHP e resteranno disponibili per ogni richiesta futura. Ciò porterà a buoni miglioramenti delle prestazioni, anche se questi miglioramenti potrebbero essere considerevolmente variabili.
Potete leggere di più sulle limitazioni e le eccezioni del Preloading nella pagina ufficiale della RFC.
Nuovo Meccanismo di Serializzazione Personalizzata degli Oggetti
Questa è un’altra proposta di Nikita Popov approvata con un’ampia maggioranza di voti.
Al momento, abbiamo due diversi meccanismi per la serializzazione personalizzata degli oggetti in PHP:
- I magic methods
__sleep()e__wakeup() - L’interfaccia
Serializable
Secondo Nikita, entrambe queste soluzioni presentano problemi che portano ad un codice complesso e inaffidabile. Potete approfondire questo argomento nella RFC. Qui mi limito a dire che il nuovo meccanismo di serializzazione dovrebbe prevenire questi problemi fornendo due nuovi magic methods, __serialize() e __unserialize(), che combinano i due meccanismi esistenti.
Questa proposta è stata approvata con 20 voti favorevoli e 7 contrari.
Deprecazioni
Le seguenti funzioni/funzionalità saranno deprecate con PHP 7.4. Per un elenco più completo delle deprecazioni, consultate le PHP 7.4 Upgrade Notes.
Cambia la Precedenza dell’Operatore di Concatenazione
Attualmente, in PHP gli operatori aritmetici “+” e “-” e l’operatore di stringa “.” sono “left associative” e hanno la stessa precedenza (maggiori informazioni in Operator Precedence).
Ad esempio, considerate la seguente riga:
echo "sum: " . $a + $b;In PHP 7.3 questo codice produce il seguente avviso:
Warning: A non-numeric value encountered in /app/types.php on line 4Questo perché la concatenazione viene valutata da sinistra a destra. È come scrivere il seguente codice:
echo ("sum: " . $a) + $b;Questa RFC propone di cambiare la precedenza degli operatori, dando al “.” una precedenza inferiore rispetto agli operatori “+” e “-“, così che le somme e le sottrazioni vengano sempre eseguite prima della concatenazione delle stringhe. Quella riga di codice sarebbe equivalente alla seguente:
echo "sum: " . ($a + $b);Si tratta di una proposta in due fasi:
- A partire dalla versione 7.4, PHP dovrebbe emettere un avviso di deprecazione quando incontra un’espressione senza parentesi con “+”, “-” e “.”.
- La modifica effettiva della precedenza di questi operatori dovrebbe arrivare con PHP 8.
Entrambe le proposte sono state approvate con un’ampia maggioranza di voti.
Deprecato l’Operatore Ternario con Associazione a Sinistra
In PHP l’operatore ternario, a differenza di molti altri linguaggi, è associato a sinistra. Secondo Nikita Popof, questo può generare confusione per i programmatori che passano da un linguaggio all’altro.
Attualmente, in PHP il seguente codice è corretto:
$b = $a == 1 ? 'one' : $a == 2 ? 'two' : $a == 3 ? 'three' : 'other';È interpretato come:
$b = (($a == 1 ? 'one' : $a == 2) ? 'two' : $a == 3) ? 'three' : 'other';Questo potrebbe portare ad errori perché potrebbe non essere ciò che intendiamo fare. Quindi questo RFC propone di deprecare e rimuovere l’uso dell’associatività a sinistra per gli operatori ternari e di costringere gli sviluppatori a utilizzare le parentesi.
È un’altra proposta in due fasi:
- A partire da PHP 7.4, gli operatori ternari nidificati senza l’uso esplicito delle parentesi generano un avviso di deprecazione.
- A partire da PHP 8.0, ci sarà un errore di runtime.
Questa proposta è stata approvata con 35 voti favorevoli contro 10 sfavorevoli.
Cosa significa PHP 7.4 per gli utenti di WordPress?
PHP è il linguaggio di programmazione lato server più utilizzato sul web. Secondo W3Techs, al 2 dicembre 2019, l’uso di PHP è utilizzato dal 78,9% di tutti i siti web di cui è possibile rilevare il linguaggio di programmazione lato server.
Sfortunatamente, PHP 5 è ancora utilizzato dal 52,4% di tutti i siti web con un linguaggio di programmazione lato server noto. Se si aggiunge il numero di utenti che utilizzano ancora PHP 7.0, risulta che una grande maggioranza di siti web ha ancora in esecuzione versioni non supportate di PHP.
Secondo la pagina ufficiale di WordPress Stats, al momento in cui scriviamo, un enorme 67% di tutti i siti web WordPress gira su versioni non supportate di PHP. Solo poco più del 3% utilizza l’ultima versione: PHP 7.3. È chiaro che una grande maggioranza di utenti, oltre il 31%, ha ancora in esecuzione PHP 5.6.
Vi consigliamo vivamente di chiedere al vostro host una versione di PHP supportata, preferibilmente aderente ai requisiti ufficiali di WordPress. Al momento in cui scriviamo, maggio 2019, WordPress richiede:
- PHP versione 7.3 o superiore.
- MySQL versione 5.6 o superiore, O MariaDB versione 10.1 o superiore.
- Supporto HTTPS
PHP 7 Performance
I numeri sopra riportati sono particolarmente scoraggianti dal punto di vista delle prestazioni, perché PHP 7 ha dimostrato di essere significativamente più veloce. Ecco alcune statistiche:
- I benchmark ufficiali di PHP hanno dimostrato che PHP 7 consente al sistema di eseguire il doppio delle richieste al secondo rispetto a PHP 5.6, a quasi metà della latenza.
- Anche Christian Vigh ha pubblicato un confronto delle prestazioni di PHP in cui ha scoperto che PHP 5.2 era il 400% più lento di PHP 7.
- Andrei Avram ha registrato tempi di esecuzione più rapidi e minore utilizzo di memoria in PHP 7.4 rispetto a PHP 7.3
- Phoronix ha eseguito alcuni test di benchmark preventivi con PHP 7.4 Alpha e ha visto che era leggermente più veloce di PHP 7.3.
Upgraded my @kinsta site to PHP 7.4 and it is like 10x faster. Woot!
— Ronald Huereca (@RonaldHuereca) December 2, 2019
Noi abbiamo eseguito i nostri benchmark delle prestazioni PHP con PHP 7.3. Abbiamo visto che WordPress 5.0 su PHP 7.3 poteva eseguire quasi tre volte il numero di transazioni (richieste) al secondo rispetto a PHP 5.6. A breve pubblicheremo i benchmark di PHP 7.4!
- Benchmark di WordPress 5.0 PHP 5.6: 91,64 ric/sec
- Risultati benchmark di WordPress 5.0 PHP 7.0: 206,71 ric/sec
- Risultati benchmark di WordPress 5.0 PHP 7.1: 210,98 ric/sec
- Risultati benchmark di WordPress 5.0 PHP 7.2: 229,18 ric/sec
- Risultati benchmark di WordPress 5.0 PHP 7.3: 253,20 ric/sec 🏆
Molti sono lenti ad aggiornare semplicemente per via del tempo necessario a testare tutti i plugin e i temi di terze parti per assicurarsi che funzionino correttamente. Ma molte volte si tratta semplicemente di non averlo ancora fatto.
Verificare la Vostra Versione di PHP
Non siete sicuri di quale versione di PHP state utilizzando? Uno dei modi più semplici per verificarlo è utilizzare uno strumento come Pingdom o Google Chrome Devtools. Il primo header di richiesta HTTP mostrerà in genere la versione.
Tuttavia, questo dipende dall’host che potrebbe non modificare il valore dell’intestazione X-Powered-By. Molti lo fanno per motivi di sicurezza (incluso Kinsta). In questo caso, potreste non vedere la vostra versione di PHP. In tal caso, se utilizzate WordPress 5.2 o versioni successive, potete utilizzare lo strumento Salute del Sito. Andate su “Strumenti” → “Salute del sito” → “Informazioni” e, nella sezione “Server”, troverete la versione PHP del vostro server.
In alternativa, potete installare un plugin gratuito come Version Info, che vi mostrerà alcune informazioni di base sul server nella parte inferiore della dashboard di amministrazione di WordPress. Un altro metodo per vedere la vostra versione di PHP è il caricamento di un file tramite FTP. In alternativa, potete semplicemente contattare il vostro host e chiedere a loro.
Aggiornare a PHP 7.4
La versione finale di PHP 7.4 è già disponibile su Kinsta. Se non siete su Kinsta, potete testare localmente il vostro sito WordPress o verificare i vostri script in un ambiente come Docker, che consente di testare diverse versioni di PHP dalla riga di comando.
Il modo più semplice per iniziare i test è creare un ambiente di staging, dato che questo assomiglierà molto al vostro sito di produzione. Nella dashboard di MyKinsta, fate clic sul vostro sito e passate l’ambiente in modalità di staging.
Quindi, alla voce “Strumenti”, cambiate il motore PHP del sito di staging. Potrete così iniziare i test per garantirvi la compatibilità dei vostri temi e plugin di terze parti.
Come per le versioni precedenti di PHP, la nostra funzione di self-healing PHP supporta pienamente PHP 7.4. Se PHP si blocca per qualsiasi motivo, lo riavvieremo automaticamente. Se il riavvio non risolve il problema, il nostro sistema di monitoraggio avviserà il nostro team di sysadmin per indagare sulla causa del problema.
Si vedano tutti i dettagli sulla release di PHP 7.4 su Kinsta.
Installare ed Eseguire PHP 7.4 su Docker
Volete testare su Docker? Per fortuna, non è necessario compilare e configurare PHP 7.4 manualmente. Se avete già installato Docker sul vostro sistema, dovete solo installare l’immagine Docker non ufficiale PHP-FPM 7.4 ed eseguire i vostri test dalla riga di comando in pochi secondi.
Se preferite eseguire il vostro codice PHP 7.4 nel browser, dovete anche installare un’immagine di Nginx o Apache. Ma non preoccupatevi. Seguite le indicazioni dello sviluppatore. Copiate e incollate i comandi dalla pagina dell’Immagine di Docker nel vostro terminale dei comandi e siete subito pronti a partire.
Riepilogo
In questo post, abbiamo descritto un buon numero delle novità introdotte con il rilascio di PHP 7.4. Se state cercando l’elenco completo delle funzionalità, con la documentazione ufficiale delle RFC, consultate le seguenti risorse:
Vi terremo aggiornati su tutte le novità riguardanti PHP 7.4 e le sue release. Se siete clienti di Kinsta, potete già iniziare a spostare i vostri siti WordPress sull’ultima versione.
Pronti a installare e testare le prossime funzionalità di PHP? Qual è quella che preferite? Condividete i le vostre considerazioni con noi nei commenti.
Carlo è cultore appassionato di webdesign e front-end development. Gioca con WordPress da oltre 20 anni, anche in collaborazione con università ed enti educativi italiani ed europei. Su WordPress ha scritto centinaia di articoli e guide, pubblicati sia in siti web italiani e internazionali, che su riviste a stampa. Lo trovate su LinkedIn.
Lascia un commento