Ab dem 6. Dezember 2018 ist die neueste und beste Version, PHP 7.3, verfügbar! Mit ihr kommen neue nützliche Funktionen, Funktionalitäten, Verwerfungen, eine ganze Reihe von Bugfixes und eine Steigerung der Performance. PHP 7.3 ist nun auch für alle Kinsta-Kunden im MyKinsta Dashboard verfügbar. 🤘

Update: PHP 8.1 (offizielles Release) ist jetzt für alle Kinsta Kunden verfügbar. PHP 7.3 wird von Kinsta nicht mehr unterstützt. Bitte beachte, dass wir die PHP-Versionen 8.1, 8.2 und 8.3 unterstützen.

In diesem Beitrag geben wir einen Überblick über die Features und Änderungen, die wir persönlich für am relevantesten halten. Sie können jedoch jederzeit die vollständige Liste der Funktionen, Änderungen und Bugfixes in den PHP 7.3 Upgrade-Notes und in den PHP 7.3 „Requests For Comments“ überprüfen.

Was gibt es Neues in PHP 7.3?

In diesem Beitrag behandeln wir folgende Themen:

Flexible Heredoc und Nowdoc Syntaxes

Dies ist wahrscheinlich eine der wichtigsten Verbesserungen von PHP 7.3, und wir denken, dass es etwas mehr Aufmerksamkeit verdient. Bevor wir also in die PHP 7.3 Heredoc/Northdoc-Änderungen einsteigen, geben wir Ihnen einen kurzen Überblick über diese nützliche Kernfunktion. Wenn Sie bereits mit nowdoc und heredoc vertraut sind, können Sie gerne direkt zu den Änderungen an PHP 7.3 gehen.

Ein Überblick über die Heredoc- und Nowdoc-Syntaxen

Die heredoc-Syntax bietet die Möglichkeit, eine große Textmenge hinzuzufügen, ohne dass man Dinge wie doppelte Anführungszeichen vermeiden muss. Ein Heredoc beginnt mit <<<, gefolgt von einem Marker, und endet mit dem gleichen Marker, gefolgt von einem Semikolon. Hier ist ein Beispiel:

print <<<EOT
Heredoc text behaves just like a double-quoted string, without the double quotes.
EOT;

Ein Nowdoc verhält sich ähnlich wie ein Heredoc, mit einigen Ausnahmen:

  • Der Bezeichner wird in einfache Anführungszeichen gesetzt (<<<'EOT')
  • In einem nowdoc wird kein Parsing durchgeführt.

Hier ist ein Beispiel für nowdoc:

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

Heredocs und Nowdocs haben die gleichen Regeln, die die Verwendung der Schließmarkierung regeln:

  1. Die Schließmarkierung muss in der ersten Spalte der Zeile beginnen.
  2. Der Marker muss den gleichen Namensregeln folgen wie jedes andere Label in PHP: Er darf nur alphanumerische Zeichen und Unterstriche enthalten und muss mit einem Unterstrich oder einem anderen Zeichen welches keine Zahl ist beginnen.

Die PHP Anleitung warns:

„Es ist sehr wichtig zu beachten, dass die Zeile mit der Abschlusskennung keine weiteren Zeichen enthalten darf, außer einem Semikolon (;). Das bedeutet insbesondere dass der Bezeichner nicht eingerückt sein darf, und vor oder nach dem Semikolon keine Leerzeichen oder Tabulatoren vorhanden sein dürfen. Es ist auch wichtig zu wissen, dass das erste Zeichen vor dem Abschlusskennzeichen eine Zeilenumbruch sein muss, wie vom lokalen Betriebssystem definiert. Dies ist \n auf UNIX-Systemen, einschließlich macOS, der Fall. Nach dem abschließenden Trennzeichen muss ebenfalls eine Zeilenumbruch erfolgen.“

PHP 7.2 ungültiger Syntax:

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

PHP 7.2 gültiger Syntax:

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

Um es kurz zu halten, in PHP 7.2:

  • Darf die Schließmarkierung nicht eingerückt werden.
  • Darf die Zeile mit der Schließmarkierung keine Zeichen wie Leerzeichen oder Tabulatoren enthalten.
  • Muss das erste Zeichen vor der Schließmarkierung ein Zeilenumbruch sein.
  • Muss Nach der Schließmarkierung eine neue Zeile folgen.

Es ist offensichtlich, dass die Syntaxen von Heredoc und Nowdoc sehr restriktiv sind, aber PHP 7.3 kann dies mit den folgenden Verbesserungen ein wenig ändern.

1. Ermöglicht das Einrücken der Schließmarkierung und das Entfernen des führenden Leerzeichens.

Mit PHP 7.3 ist es uns erlaubt, die Schließmarkierung einzurücken, und wir können folgenden Code sicher schreiben:

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

Die Einrückung der Schließmarkierung legt die Menge an Leerzeichen (oder Tabs) fest, die von jeder Zeile des Körpers entfernt werden. Aber Vorsicht: Der Schließmarker sollte niemals weiter eingerückt sein als jede andere Linie des Körpers.

Siehe untenstehender Code:

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

Der obige Code würde den folgenden Parse-Fehler auslösen:

Parse error: Invalid body indentation level (expecting an indentation at least ...) in %s on line %d

Das Entfernen von Tabulatoren und Leerzeichen erlaubt es uns, den Körper des Heredocs/nowdoc auf die gleiche Ebene des Codes um ihn herum einzurücken, und zwar ohne unnötigen Leerraum vor jeder Zeile des Körpers.

Wir können sowohl Tabulatoren als auch Leerzeichen für die Einrückung verwenden, aber wir dürfen sie nicht vermischt verwenden. Das bedeutet, dass wir die gleichen Einrückungszeichen für den Schließmarker und alle Linien des Körpers verwenden müssen. Im Falle von unterschiedlichen Einrückungszeichen würden wir eine andere Art von Parse-Fehler (ungültige Einrückung) erwarten.

2. Entfernen Sie die nachlaufende neue Leitungsanforderung vom Schließmarker.

Derzeit muss dem Marker eine neue Zeile folgen, um das Heredoc/Northdoc zu beenden. PHP 7.3 würde dies ändern und es uns ermöglichen, das heredoc/nowdoc in der gleichen Zeile zu beenden. Hier ist ein Beispiel aus dem RFC:

PHP 7.2 gültiger Syntax:

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

PHP 7.3 gültiger Syntax:

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

Seien Sie jedenfalls vorsichtig bei der Wahl des Namens Ihres Markers, denn „gelegentlich“ können Sie mit einem Fehler rechnen, wenn er mit einem Wort übereinstimmt, das Sie im Body des heredoc/nowdoc verwendet haben (lesen Sie mehr dazu auf dem RFC und GitHub).

Both proposals passed with more than 2/3 votes.

PHP 7.3 RFC

Zusätzliche Infos:

Erlaubt ein nachgestelltes Komma in Funktionsaufrufen

Nachfolgende Kommas (oder „Endkommas“) werden an eine Liste von Elementen, Parametern oder Eigenschaften angehängt und sind nützlich in Kontexten, in denen neue Werte häufig angehängt werden, weil sie Fehler aufgrund eines fehlenden Komma verhindern. In PHP sind nachgestellte Kommas in Arrays erlaubt, und ab PHP 7.2 sind sie in gruppierten Namensräumen erlaubt.

Ab PHP 7.3 sind nachgestellte Kommas in Funktionsdeklarationen erlaubt. Variadische Funktionen bieten ein Beispiel für einen Kontext, in dem nachgestellte Kommas äußerst nützlich sind:

foo(
    $bar,
    $baz,
);

Wir können ein abschließendes Komma verwenden, wenn wir ein Array mit compact(), erstellen, um eine formatierte Zeichenkette mit sprintf() zurückzugeben, oder wenn wir ein Array zusammenführen:

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

Auch das Nachfolgen von Kommas wäre für das Debuggen nützlich:

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

Und sie sind nützlich mit unset() und isset():

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

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

Nachfolgende Kommas sind auch in Methodenaufrufen und Anlagen erlaubt.

Hinweis: Diese Änderung betrifft nur Funktionsaufrufe. Die Syntax der Funktionsdeklaration ändert sich nicht. Außerdem sind freistehende Kommas, mehrere Nachkommas und führende Kommas nicht erlaubt.

Weitere Beispiele finden Sie auf der RFC-Seite. Dieser RFC wurde mit 30 zu 10 Stimmen verabschiedet.

PHP 7.3 RFC

JSON_THROW_ON_ERROR

Eine der beliebtesten Funktionalitäten von PHP 7.3 bietet eine neue Möglichkeit, JSON-Fehler zu behandeln. Dies ist kein Kernfeature, sondern eine Erweiterung der JSON-Erweiterung, die das Fehlerverhalten von json_decode() und json_encode() ändern würde.

Derzeit gibt json_decode() null bee einem Fehler zürück null aber null kann auch ein gültiges Ergebnis sein. Das kann verwirrend sein, denn:

Es ist nur möglich zu wissen, ob ein Fehler aufgetreten ist, indem json_last_error() oder json_last_error_msg() aufgerufen wird, die den globalen Fehlerzustand in maschinenlesbaren bzw. menschenlesbaren Formen zurückgeben. – PHP RFC

json_encode() gibt FALSE being einem Fehler zürück. Dies ist klarer, da es einen bestimmten Fehlerwert gibt. Beide Funktionen stoppen die Programmausführung jedenfalls nicht im Fehlerfall und warnen nicht.

Abgesehen davon, hier ist der Vorschlag für PHP 7.3:

Dieser RFC schlägt stattdessen vor, einen neuen Optionsflag-Wert für json_decode() und json_encode(), JSON_THROW_ON_ERRORinzuzufügen. Wenn dieses Flag überschritten wird, wird das Fehlerverhalten dieser Funktionen geändert. Der globale Fehlerzustand bleibt unberührt, und wenn ein Fehler auftritt, der ihn ansonsten setzen würde, werfen diese Funktionen stattdessen eine JsonException mit der Nachricht und dem Code, der auf json_last_error() und json_last_error_msg() gesetzt ist.

Hier ist ein einfaches Beispiel, das eine Möglichkeit aufzeigt, einen JSON-Fehler zu verursachen:

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

Das Auslösen einer Ausnahme bei einem Fehler würde mehrere Vorteile mit sich bringen, die Sie auf dem RFC finden.

Hinweis: Ein ungültiger Tiefenparameter, der an json_decode() übergeben wird, gibt eine Warnung aus und gibt NULL zurück. Dieses Verhalten wird von JSON_THROW_ON_ERROR. Similarly, nicht beeinflusst. Ebenso werden Parameter-Parsing-Fehler von JSON_THROW_ON_ERROR nicht beeinflusst und erzeugen weiterhin Warnungen.

Dieser Vorschlag wurde mit 23 zu 0 Stimmen angenommen.

PHP 7.3 RFC

Zusätzliches Material

list() Reference Assignment

Was bedeutet „Reference Assignment“?

Beachten Sie die folgende Zeile:

$b = &$a;

Hier erhält $b den Wert von $a, aber dieter Wert wild nicht von $a nach $bkopiert. In PHP können wir einen Wert per Referenz zuweisen, was bedeutet, dass zwei Variablen auf dieselben Daten verweisen können, und jede Änderung an einer Variablen wirkt sich auf die Originaldaten aus. Hier ist ein Beispiel aus dem PHP Handbuch:

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

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

Lassen Sie uns nun den Wert von $a ändern:

$a = 4; // change $a

print "$a\n"; // prints 4
print "$b\n"; // prints 4 as well, since $b is a reference to $a, which has been changed

Was ist der list() Construct und wie wird er sich mit PHP 7.3 verändern?

Das Sprachkonstrukt list() kann verwendet werden, um „Variablen so zuzuweisen, als wären sie in einem Array“, aber mit list() ist es uns derzeit nicht erlaubt, Variablenwerte per Referenz zuzuweisen.

PHP 7.3 sollte dies ändern, so dass wir Variablen per Referenz auch mit dem list() Konstrukt zuweisen können, wie im folgenden Beispiel gezeigt:

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

Dies ist das gleiche wie:

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

Der Vorteil dieses Vorschlags ist, dass wir nun mehrere Variablen per Referenz zuweisen können, was derzeit nicht erlaubt war. Weitere Beispiele sind auf dem RFC verfügbar. Dieser Vorschlag wurde mit 17 zu 7 Stimmen angenommen.

PHP 7.3 RFC

Zusätzliches Material:

is_countable Funktion

Ein weiteres nützliches Feature von PHP 7.3 ist die Funktion is_countable(). Bis zu PHP 7.2, erhalten wir einen Fehler beim Versuch, etwas zu count() das nicht zählbar ist. Aus diesem Grund sind wir gezwungen, den folgenden Code hinzuzufügen, um eine Warnung zu vermeiden:

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

Dieser RFC schlägt die Funktion is_countable() vor die true zurückgibt, wenn die angegebene Variable ein Array oder eine zählbare Variable ist, ansonsten false. So könnte der obige Code wie folgt geändert werden:

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

Dieser Vorschlag wurde mit 25 zu 0 Stimmen angenommen.

PHP 7.3 RFC

Zusätzliches Material/h4>

array_key_first(), array_key_last()

Derzeit können wir den ersten und den letzten Schlüssel eines Arrays mit den Funktionen reset(), end() und key() abrufen. Leider gibt es mit diesen Funktionen keine Möglichkeit, den ersten oder letzten Index eines Arrays zu sammeln, ohne seinen internen Zustand zu ändern. Andere Optionen reduzieren in der Regel die Lesbarkeit und Leistung des Codes.
Dieser Vorschlag würde dieses Szenario ändern, indem er zwei neue Funktionen zum PHP-Kern hinzufügt:

  • array_key_first()
  • array_key_last()

Seit PHP 7.3, ermöglichen array_key_first() und array_key_last() das Abrufen des ersten und letzten Schlüssels eines bestimmten Arrays, ohne den internen Array-Pointer zu beeinflussen. Diese neuen Funktionen würden es uns ermöglichen, weniger komplexen Code zu schreiben und in einigen Fällen Fehler zu vermeiden. Weitere Informationen und einige Beispiele finden Sie im RFC.

array_key_first() und array_key_last() wurden mit 18 bis 14 Stimmen genehmigt.

Hinweis: Der ursprüngliche RFC schlug zwei weitere Funktionen vor, array_value_first() und array_value_last(), die in einer anderen Umfrage abgestimmt wurden, aber nicht genehmigt wurden und nicht Teil des PHP-Kerns werden.

PHP 7.3 RFC

Zusätzliches Material

Argon2 Passwort Hash Erweiterungen

Argon2 ist ein Hash-Algorithmus, der in PHP 7.2 als Alternative zum Bcrypt-Algorithmus implementiert wurde. PHP 7.2 führte die Konstante PASSWORD_ARGON2I ein, die für die Verwendung in PASSWORD_ARGON2I ein, die für die Verwendung in password_*Funktionen verfügbar ist:

password_hash('password', PASSWORD_ARGON2I);

Seit seiner ersten Implementierung wurde eine neue Variante von Argon2 hinzugefügt, so dass zum Zeitpunkt dieses Schreibens Argon2 in drei Varianten erhältlich ist:

  • Argon2d maximiert die Widerstandsfähigkeit gegen GPU-Cracking-Angriffe. Es ist schneller und verwendet datenabhängigen Speicherzugriff.
  • Argon2i verwendet datenunabhängigen Speicherzugriff, der für die Passwort-Hashing bevorzugt wird. Es ist langsamer, da es mehr Übergaben über den Speicher macht, um vor „tradeoff“ Attacken zu schützen.
  • Argon2id ist eine Hybridversion, die den Argon2i-Ansatz für den ersten Durchlauf über den Speicher und den Argon2d-Ansatz für nachfolgende Durchläufe kombiniert.

Argon2id wird im Internet empfohlen, außer wenn es gute Gründe gibt, eine andere Variante zu bevorzugen.

Der neue RFC schlägt die Implementierung von Argon2id innerhalb der password_* Funktionen mit der neuen Konstante PASSWORD_ARGON2ID vor:

password_hash('password', PASSWORD_ARGON2ID);

Die Implementierung ist identisch mit der Argon2i-Implementierung und akzeptiert die gleichen Kostenfaktoren:

  • Speicherkosten, die die Anzahl der KiBs definieren, die beim Hashing verbraucht werden sollen (Standardwerte sind 1<<<10, oder 1024 KiB, oder 1 MiB).
  • Ein Zeitaufwand, der die Anzahl der Iterationen des Hashing-Algorithmus definiert (Standard ist 2).
  • Ein Parallelitätsfaktor, der die Anzahl der parallelen Threads festlegt, die beim Hashing verwendet werden (Standard ist 2).

Siehe folgender Code:

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

Mehr Informationen und Beispiele finden Sie hier: RFC.

PHP 7.3 RFC

Zusätzliches Material

Verwerfungen

Die folgenden Funktionen/Funktionalitäten werden mit PHP 7.3 veraltet und spätestens mit PHP 8.0 entfernt.

Verwerfen und Entfernen von image2wbmp()

Die Funktion image2wbmp() gibt eine WBMP-Version eines bestimmten Bildes aus oder speichert sie. Diese Funktion benötigt drei Argumente: eine Bildressource, einen Dateinamen (der Pfad zur gespeicherten Datei) und eine Vordergrundfarbe.
Ab PHP 5.0 ist es identisch mit imagewbmp(), daher schlägt dieser RFC vor, es zu verwerfen und zu entfernen.
Seit PHP 7.3 würde jeder Aufruf von image2wbmp() ine Verfallswarnung ausgeben. Nach der Entfernung würde jeder Aufruf einen fatalen Fehler verursachen.

PHP 7.3 RFC

Veraltete und entfernte Konstanten, die nicht auf Groß-/Kleinschreibung achten.

PHP unterstützt derzeit sowohl case-sensitive als auch case-insensitive Konstanten. Wie auch immer, Groß- und Kleinschreibung wird unterstützt, gilt aber als abhängig von Inkonsistenzen in den Funktionalitäten und als komplex in der Anwendung.

Dieser Vorschlag beginnt mit den folgenden Prämissen:

  • Klassenkonstanten sind immer case-sensitive
  • globale Konstanten, die mit const deklariert sind, sind immer case-sensitive
  • Konstanten, die mit define() definiert sind, sind standardmäßig case-sensitive.

Darüber hinaus heißt es in der PHP-Language Reference ausdrücklich:

„Eine Konstante ist standardmäßig case-sensitive. Konventionell sind Konstantenbezeichner immer in Großbuchstaben geschrieben.“

Allerdings schlägt dieser RFC folgende Änderungen vor:

  • Veraltetes Aufrufen von define() mit drittem Parameter auf true gesetzt – PHP 7.3
  • Verwerfen Sie den Zugriff auf case-insensitive Konstanten mit einem von der Deklaration unterschiedlichem casing (mit Ausnahme von true, false und null) – PHP 7.3
  • Entfernen Sie die Möglichkeit, Konstanten mit Groß-/Kleinschreibung zu deklarieren – PHP 8.0
  • Konvertiert true, false und null von Sonderkonstanten in reservierte Keywords – PHP 8.0

PHP 7.3 RFC

Verwerfen und entfernen Sie Case-Insensitive Konstanten..

Zusätzliche Verwerfungen für PHP 7.3

Hier ist eine kurze Liste von Funktionalitäten, die in PHP 7.3 veraltet sind. Diese ist nicht vollständig, es sind nur die Vorschläge zur Verwerfung, die wir persönlich für wichtig halten. Eine vollständige Liste der vorgeschlagenen Verwerfungen finden Sie unter Deprecations für PHP 7.3.

Undokumentierte mbstring-Funktionsaliase: Es gibt eine Reihe von undokumentierten mbstring -Funktionsaliasen, die Duplikate von äquivalenten Funktionen mit mb_-Präfix sind. Zum Beispiel ist mbereg ein Alias von mb_ereg.
Alle diese Funktionen werden als veraltet markiert und es wird ein Verfallshinweis ausgegeben, wenn sie während der Kompilierung auftreten.
Zeichenketten-Suchfunktionen mit „integer needle“: Diese Funktionen arbeiten in der Regel auf string needles. Wenn eine Non-String-Needle angegeben wird, wird sie in eine ganze Zahl umgewandelt und als Ordnungszahl eines Zeichens angewendet (mehr dazu im PHP Handbuch). Hier ist ein Beispiel aus dem RFC:

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

Dies gilt als verwirrend und verursacht unvorhersehbare Probleme, da sich der Typ mit der Benutzerdatenquelle ändern kann. Aus diesem Grund schlägt der RFC die Ausgabe einer Warnung vor, wenn eine Non-String-Needle an eine der folgenden Funktionen übergeben wird:

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

In PHP 8.0 sollte die Verfallswarnung entfernt und die „Needles“ automatisch in Zeichenketten umgewandelt werden.

fgetss() Funktion und string.strip_tags Streamfilter: fgetss() und string.strip_tags strippen Tags aus einem Stream, während sie ihn lesen. Sowohl die Funktion als auch der Filter zeigen die strip_tags()-Funktionalität an, was die Implementierung von strip_tags() komplexer macht, da eine Streaming-State-Machine erforderlich ist. Darüber hinaus weist der RFC auf einen weiteren Nachteil dieser Funktionen hin:

„Auf der anderen Seite scheinen diese Funktionen von sehr geringem Nutzen zu sein. strip_tags() selbst hat aufgrund seiner Einschränkungen und bekannten Fehler bereits sehr wenige legitime Anwendungen. Es ist nicht erforderlich, darüber hinaus native Unterstützung für Streaming-Anwendungen zu bieten.“

Daher schlägt der RFC vor, fgetss(), gzgetss() und SplFileObject::fgetss() als veraltet zu markieren.

Was bedeutet PHP 7.3 für WordPress-Benutzer?

Laut der offiziellen WordPress Stats-Seite haben zum Zeitpunkt des Schreibens nur 32,9% der WordPress-Benutzer auf PHP 7 oder höher umgestellt. Nur 4% verwenden PHP 7.2. Sie sehen, dass eine große Mehrheit der Benutzer, über 38%, noch immer mit PHP 5.6 arbeiten. Noch beängstigender ist, dass über 28,5% der Benutzer nicht unterstützte PHP-Versionen verwenden. Seit Dezember 2016 hat WordPress.org seine offizielle Empfehlung für Benutzer von PHP 5.6 auf PHP 7 oder höher erhöht.

WordPress PHP Versionen
WordPress PHP Versionen

PHP 7 Performance

Die obigen Zahlen sind besonders entmutigend aus Performance-Sicht, da sich PHP 7 als wesentlich schneller erwiesen hat. Hier sind ein paar Statistiken:

  • Offizielle PHP-Benchmarks zeigen, dass PHP 7 es dem System ermöglicht, doppelt so viele Anfragen pro Sekunde im Vergleich zu PHP 5.6 bei fast der Hälfte der Latenzzeit auszuführen.
  • Christian Vigh veröffentlichte auch einen PHP-Leistungsvergleich, in dem er feststellte, dass PHP 5.2 400% langsamer war als PHP 7.
  • Erste Benchmarks von Phoronix haben gezeigt, dass PHP 7.3 etwa 5% schneller ist als PHP 7.2.

Wir haben unsere eigenen PHP-Performance-Benchmarks durchgeführt. Und ähnlich wie bei den obigen Benchmarks haben wir gesehen, dass WordPress 5.0 auf PHP 7.3 fast dreimal so viele Transaktionen (Anfragen) pro Sekunde ausführen kann wie PHP 5.6.

WordPress 5.0 PHP benchmarks
WordPress 5.0 PHP benchmarks
  • WordPress 5.0 PHP 5.6 Vergleich: 91.64 req/sek
  • WordPress 5.0 PHP 7.0 Vergleichsergebnisse: 206.71 req/sek
  • WordPress 5.0 PHP 7.1 Vergleichsergebnisse: 210.98 req/sek
  • WordPress 5.0 PHP 7.2 Vergleichsergebnisse: 229.18 req/sek 
  • WordPress 5.0 PHP 7.3 Vergleichsergebnisse: 253.20 req/sek 🏆

Es ist auch interessant festzustellen, dass WordPress 4.9.8 auf PHP 7.3 etwas schneller war als WordPress 5.0.

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

Viele aktualisieren die PHP Version nicht, einfach wegen der Zeit, die mit dem Testen all ihrer Plugins und Designs von Drittanbietern verbunden ist, um sicherzustellen, dass sie ordnungsgemäß funktionieren. Aber oft ist der Grund einfach nur der das man es noch nicht getan hat.

Die PHP Version prüfen

Sie sind sich nicht sicher, welche Version von PHP Sie verwenden? Eine der einfachsten Möglichkeiten, dies zu überprüfen, ist die Verwendung eines Tools wie Pingdom oder Google Chrome Devtools. Der erste HTTP-Request-Header zeigt Ihnen typischerweise die Version an.

PHP Version überprüfen
PHP Version überprüfen

Dies setzt voraus, dass der Host den X-Powered-By Header-Wert nicht ändert. Wenn dies der Fall ist, sehen Sie möglicherweise Ihre PHP-Version nicht, in diesem Fall müssen Sie  eine Datei per FTP hochladen. Oder Sie können sich jederzeit an Ihren Hoster wenden und fragen.

Die PHP version in WordPress prüfen
Die PHP version in WordPress prüfen

Alternativ kannst du auch eine Datei per FTP hochladen, um deine PHP-Version zu sehen, oder deinen Host kontaktieren und fragen.

Auf PHP 7.3 Updaten

Die endgültige Version von PHP 7.3 ist noch nicht ganz fertig, aber sobald sie fertig ist, können Sie mit dem Testen der Pre-Release Version beginnen. Sie können Ihre WordPress-Seite lokal testen oder Ihre Skripte in einer Umgebung wie Docker überprüfen, die es Ihnen ermöglicht, verschiedene Versionen von PHP von der Kommandozeile aus zu testen.

Oder Sie können eine Stagingumgebung nutzen, da diese eher einer Live-Produktionsstätte ähnelt. Erstellen Sie mit wenigen Klicks im MyKinsta Dashboard eine Stagingumgebung.

WordPress Staging Umgebung
WordPress Staging Umgebung

Wir empfehlen immer eine gründliche Prüfung, bevor du es in einer Produktionsstätte anwendest. Hierzu ändere einfach die PHP-Engine für die Staging-Site unter „Tools“ und du kannst mit dem Testen beginnen, um die Kompatibilität deiner Plugins und Designs von Drittanbietern sicherzustellen.

Wechseln zu PHP 7.3 RC 4
Wechseln zu PHP 7.3 RC 4

Sobald du bestätigt hast, dass alles funktioniert, kannst du entweder deine Produktionsseite auf PHP 7.3 umstellen oder, wenn du irgendwelche Änderungen vorgenommen hast, auch deine Staging-Seite auf Live stellen.

Zusammenfassung

Zum jetzigen Zeitpunkt befindet sich PHP 7.3 in der RC 4 Phase, und gemäß dem Zeitplan für die Vorbereitungsaufgaben wird es Mitte Dezember offiziell freigegeben. Es wird uns Geschenke wie flexible Heredocs und Nowdocs, Kommas in Funktionsaufrufen, list() Referenzzuweisungen und mehr bringen. In diesem Beitrag haben wir einen Überblick über unsere Lieblingsverbesserungen und -änderungen gegeben, aber wir möchten auch wissen, welche Ihre Favoriten sind und auf welche Weise Sie diese nutzen werden. Lassen Sie es uns in den Kommentaren wissen. Und vergiss nicht, dass PHP nicht tot ist!

Die vollständige Liste der PHP 7.3 Vorschläge finden Sie auf der Seite Requests For Comments und den PHP 7.3 Upgrade Notes von Github.

Carlo Daniele Kinsta

Carlo ist ein leidenschaftlicher Liebhaber von Webdesign und Frontend-Entwicklung. Er beschäftigt sich seit über 10 Jahren mit WordPress, auch in Zusammenarbeit mit italienischen und europäischen Universitäten und Bildungseinrichtungen. Er hat Dutzende von Artikeln und Leitfäden über WordPress geschrieben, die sowohl auf italienischen und internationalen Websites als auch in gedruckten Magazinen veröffentlicht wurden. Du kannst Carlo auf X und LinkedIn finden.