Was ist PHP?

PHP (Abkürzung für Hypertext Preprocessor) ist eine Open-Source Skriptsprache, welche hauptsächlich in der Web-Entwicklung zur Generierung von HTML-Code verwendet wird.

Beispiel:

<?php
   $variable = "Testvariable";
   echo "Folgende Variable wurde definiert: " . $variable;
?>

Generiert folgendes Ergebnis:

Folgende Variable wurde definiert: Testvariable

In diesem Beispiel wird eine Variable definiert und über den Befehl „echo“ an den Text „Folgende Variable wurde definiert:“ hinten hinzugefügt und ausgegeben.

Da PHP eine Skriptsprache ist wird bei jedem Aufruf der PHP Datei der Inhalt neu interpretiert. Im Gegensatz dazu wird am Beispiel von Java oder C erst der Source-Code durch einen „Compiler“ in Maschinen-Code umgewandelt bevor er ausgeführt werden kann.

Standardmäßig bietet PHP schon einige unterschiedlichste Funktionalitäten zur Verfügung – wie z.B.:

  • Datenbank-Zugriff (MySQL, PostgreSQL, SQLite etc.)
  • Dateisystem-Zugriff (Ordner und Dateien erstellen/bearbeiten/löschen etc.)
  • String-Abänderungen (Texte erstellen/bearbeiten/formatieren etc.)
  • XML-Verarbeitung (Datenstrukturen erstellen/bearbeiten/durchsuchen etc.)
  • u.v.m.

Dies sind nur ein paar Beispiele an Funktionalitäten die in der „Standard-PHP“ Installation integriert sind. Jedoch gibt es „PHP-Module“ um die Funktionalität von PHP noch zu erweitern.

Bekannte bzw. häufig verwendete Beispiel hierfür wären:

  • XDebug (Erweiterte Debug Funktionalität um Probleme im PHP-Code schneller zu finden)
  • OPCache (Speichert vorkompilierte Bytecodes aus PHP-Code im Arbeitsspeicher anstatt diesen bei jedem Aufruf neu zu generieren => Performance-Boost)
  • MBString (Ermöglicht das richtige Handhaben von „MultiByte Strings“ in PHP – z.B. von Emoji Icons)
  • GD (Bildbearbeitung – Bilder drehen/umwandeln etc.)
  • SOAP (Eine spezielle Variante von XML Datenstrukturen)
  • u.v.m.

Wie PHP implementiert bzw. aufgerufen wird kann in dem Beitrag „CLI vs WebServer Integration“ nachgelesen werden.

Da sich mit jeder PHP Version aktuelle Funktionen ändern, entfernt werden und neue hinzugefügt werden wurden die wichtigsten Änderungen von PHP 7.1, 7.2 und 7.3 HIER zusammengefasst.

Sources:
PHP: Was ist PHP – https://www.php.net/manual/de/intro-whatis.php

PHP-Versionen

Wie überall in der Software-Entwicklung gibt es auch hier Versionen, die mit der Zeit die „alten“ Funktionalitäten verbessern bzw. neue Funktionalität hinzufügen. Die folgende Liste zeigt einen kurzen Überblick über die wichtigsten Änderungen von PHP 7.1 bis 7.3.

PHP 5.6 und 7.0 wurden hier nicht mehr eingebunden, da diese laut php.net nicht mehr mit Security-Patches versorgt werden und damit auch nicht mehr aktiv verwendet werden sollten. (Stand April 2019)

PHP 7.1

„Nullable types“

function test1(?array $a) {
 
}
 
function test2($a): ?array {
 
}

Die erste Funktion (test1) besagt, dass ein Parameter vom Typ „Array“ der Funktion übergeben werden kann, dieser jedoch auch „null“ sein kann (? vor dem array)

Die zweite Funktion (test2) besagt, dass der Rückgabewert der Funktion vom Typ „Array“ sein kann, jedoch aber auch „null“ erlaubt ist.

Ohne diese vorangestellten ? würde bei einem Aufruf der Funktion test1 mit dem Paramter „null“ bzw. bei der Funktion test2 mit dem Rückgabe-Wert „null“ ein „Fatal Error“ produziert werden.

Array und list haben gleiche Funktionalität

Alter Code:

$array = array(0 => 'a', 1 => 'b');
 
list($a, $b) = $array;
 
// $a ist = 'a'
// $b ist = 'b'

Neuer Code:

$array = array(0 => 'a', 1 => 'b', 2 => 'c');
 
[$a, $b] = $array;
 
// $a ist = 'a'
// $b ist = 'b'
 

list(1 => $b, 2 => $c) = $array;
// ist das gleiche wie
[1 => $b, 2 => $c] = $array;

Sichtbarkeiten von Konstanten in Klassen

Wie es schon bei Klassen-Variablen und Funktionen bekannt ist können nun „Sichtbarkeiten“ (bekannt aus der Objektorientierten Programmierung) auch auf Konstanten angewandt werden.

  • public Zugriff auf Variablen ist von überall möglich, d.h. auch von anderen Klassen bzw. Objekten
  • protected Zugriff auf Variablen ist nur in der eigenen Klasse UND von allen Klassen, die von der eigenen Klasse abgeleitet (=extended) wurden, möglich.
  • private Zugriff auf Variablen ist nur in der eigenen Klasse vorhanden.
class test {
    const PUBLIC1 = 'TEST';
 
    public const PUBLIC2 = 'TEST';
    protected const PROTECTED = 'TEST';
    private const PRIVATE = 'TEST';
}

try-catch mit mehreren Exception Angaben möglich

Es ist nun möglich in einem try-catch Block mehrere Exception-Typen mit einem | anzugeben.

try {
     throw new Exception('Fehler');
} catch (Exception | AndererExceptionTyp $catchedException) {
     var_dump($catchedException);
}

mcrypt Erweiterung veraltet => OpenSSL verwenden

Die Funktionen der „mcrypt“ Erweiterung (Funktionsnamen die mit „mcrypt_“ starten) werden nun als „deprecated“ markiert bzw. bei Verwendung in der error.log als „deprecated“ angezeigt.

Ersetzt wird die mcrypt Funktionlität mit den Funktionen aus der OpenSSL Erweiterung.

PHP 7.2

Native Untersützung für das Bild-Format (BMP)

Bis jetzt musste man bei der Bild-Bearbeitung von BMP-Bildern über PHP externe Bibliotheken verwenden. Jedoch bietet seit PHP 7.2 die GD-Bibliothek die Unterstützung für dieses Bildformat mit an.

Typ „object“ bei Parameter- und Rückgabewerten einstellbar

Bis jetzt war es nicht bei Funktionen als Paramter- oder Rückgabewerte eine Variable vom Typ „object“ anzugeben. Seit PHP 7.2 ist dies nun aber möglich.

function test (object $a): object {

}

exif_read_data() erkennt mehr Daten aus Bildern

EXIF (Exchangeable Image File Format) ist ein Standard für das Abspeichern von Metadaten bei Bild-Dateien.

Bis jetzt waren diese automatisch ausgelesenen Daten aus PHP sehr beschränkt. Jedoch wurden mit PHP 7.2 diverse EXIF-Formate von bekannten Kamera-Herstellern hinzugefügt. Siehe HIER

Verschlüsselte ZIP-Archive nun möglich

Ab PHP 7.2 ist es nun möglich ZIP-Archive mit Passwörtern zu erstellen.

PHP 7.3

Nachgestelltes Komma in Funktions-Parametern erlaubt

Ab PHP 7.3. ist es nun erlaubt beim letzten Parameter eines Funktionsaufrufs ein Komma hinten anzustellen.

my_function(
    $param1,
    $param2,
);

JSON_THROW_ON_ERROR

Aktuell gibt json_decode() null bei einem Fehler zurück.
null kann aber auch ein gültiges Ergebnis sein was zu Verwirrungen führen kann.

Nun gibt es folgende Funktionen:

  • json_last_error()
    • Gibt (sofern vorhanden) den letzten Fehler zurück, der beim letzten Kodieren/Dekodieren von JSON aufgetreten ist.
  • json_last_error_msg()
    • Gibt bei Erfolg die Fehlermeldung zurück, „No error“, wenn kein Fehler aufgetreten ist. Im Fehlerfall wird FALSE zurückgegeben.

Ein anonymer User hat bei der php.net Definition der json_last_error_msg() Funktion eine nette Helper-Funktion geschrieben, welche die Fehler-Ausgabe bei json_decode() vereinfacht:

<?php
    if (!function_exists('json_last_error_msg')) {
        function json_last_error_msg() {
            static $ERRORS = array(
                JSON_ERROR_NONE => 'No error',
                JSON_ERROR_DEPTH => 'Maximum stack depth exceeded',
                JSON_ERROR_STATE_MISMATCH => 'State mismatch (invalid or malformed JSON)',
                JSON_ERROR_CTRL_CHAR => 'Control character error, possibly incorrectly encoded',
                JSON_ERROR_SYNTAX => 'Syntax error',
                JSON_ERROR_UTF8 => 'Malformed UTF-8 characters, possibly incorrectly encoded'
            );

            $error = json_last_error();
            return isset($ERRORS[$error]) ? $ERRORS[$error] : 'Unknown error';
        }
    }
?>

Alternativ kann dies auch über einen try-catch Block gelöst werden:

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

is_countable Funktion

Aktuell ist es für z.b. foreach-Schleifen üblich die Variablen wie folgt zu überprüfen:

$array = [1,2,3,4,5,6,7,8];

if(is_array($array) && sizeof($array) > 0){
  foreach($array as $value){
    
  }
}

Dies kann nun wie folgt verkürzt werden:

$array = [1,2,3,4,5,6,7,8];

if(is_countable($array)){
  foreach($array as $value){
    
  }
}

array_key_first(), array_key_last()

Bis jetzt war es nicht „einfach“ möglich den ersten bzw. letzten „key“ eines Arrays zu erhalten. Mit den Funktionenarray_key_first()und array_key_last() ist dies nun einfach möglich.

Sources

mod_php vs (Fast)CGI vs FPM

mod_php

„mod_php“ ist ein Module für den Web-Server „apache“.

Mit diesem Modul ist PHP sozusagen „integriertim Web-Server. Das bewirkt, dass es keinen extra PHP-Prozess zur Abwicklung des PHP-Codes gibt sondern alles vom Apache-Prozess verarbeitet wird.

Der große Vorteil bei der Verwendung von „mod_php“ ist Performance. Im Vergleich zu CGI bewirkt der Umstieg auf „mod_php“ einen durchschnittlichen Performance-Gewinn von 300-500%.

Grund dafür ist die Möglichkeit des Cachings von diversen PHP-Modulen bzw. Konfigurationen die sonst (bei CGI und FastCGI) bei jedem Aufruf einer Seite immer neu ausgelesen und abgearbeitet werden müssen.

CGI

Die „Common Gateway Interface“ (kurz CGI) Implementation bedeutet, dass der Web-Server pro Anfrage eine neue PHP-Interpreter-Prozess startet. Dadurch müssen bei jeder Anfrage alle PHP-Module, die php.ini und die diversen anderen Konfigurationen neu geladen und durchgeführt werden, was sehr ineffizient ist.

Hauptvorteil von der CGI Implementation ist die komplette Isolierung zwischen ausgeführten Web-Server Code und PHP-Code.

FastCGI

FastCGI ist eine PHP-Implementation, die die Security-Vorteile von CGI implementiert aber trotzdem effizient in der Abarbeitung ist wie mod_php.

Hier wird nicht pro Request eine neue PHP-Interpreter-Instanz gestartet (was das primäre Problem war bei CGI), sondern es gibt schon „fertige“ PHP-Interpreter-Instanzen, denen nur die angefragte PHP-Datei übergeben wird.

FPM

Der „PHP-FastCGI Process Manager“ (kurz PHP-FPM) ist eine alternative zur FastCGI Implementation von PHP in einem Webserver.

Hier besteht immer parallel zum Web-Server Prozess (zu mindest) ein PHP-FPM Prozess, an den PHP-Anfragen vom Web-Server weitergeleitet werden.

Für weitere Details siehe HIER

Source: https://blog.layershift.com/which-php-mode-apache-vs-cgi-vs-fastcgi/

PHP-FPM

Der „PHP-FastCGI Process Manager“ (kurz PHP-FPM) ist eine alternative zur FastCGI Implementation von PHP in einem Webserver.

Hier besteht immer parallel zum Web-Server Prozess (zu mindest) ein PHP-FPM Prozess, an den PHP-Anfragen vom Web-Server weitergeleitet werden.

FPM-Prozesse unterteilen sich in unterschiedliche „Pools“. In diesen Pools werden typischerweise mehrere Prozesse für eine gewissen Seite gestartet werden damit diese bei Anfragen über den Web-Server gleich zur Verfügung stehen.

Die Anzahl dieser Prozesse und diverse anderen Einstellungen für den Pool können in der FPM Konfiguration (wie weiter unten zu sehen) eingestellt werden.

Installation (Debian basierte Distros)

sudo apt install php7.2 php7.2-common php7.2-cli php7.2-fpm

FPM Konfiguration

Diese befinden sich unter „/etc/php/7.2/fpm/pool.d/“.
Hier wird pro Socket eine Datei erstellt.

[<pool-name>]
user = <username>
group = <groupname>
listen = /run/php/<socket-name>.sock
listen.owner = www-data
listen.group = www-data
pm = dynamic
pm.max_children = 5
pm.start_servers = 2
pm.min_spare_servers = 1
pm.max_spare_servers = 3
env[HOSTNAME] = $HOSTNAME
env[PATH] = /usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin
chroot = <docroot-path>
php_admin_value[openssl.capath] = /etc/ssl/certs

Beim eingetragenen Pfad bei „listen“ wird nach neustarten des PHP-FPM-Prozesses ein Socket erstellt.

Über diesen kann dann der jeweilige Web-Server die Anfragen weiterleiten (siehe unten)

Web-Server Konfiguration (NGINX)

Der Web-Server muss dafür so konfiguriert werden, dass PHP-Files an den jeweiligen PHP-Prozess (typischerweise über einen Socket) weitergeleitet werden.

Am Beispiel vom NGINX-Web-Server: /etc/nginx/sites-available/<domain-name>.conf

server {
    listen 443 ssl http2; # managed by Certbot
    listen [::]:443 ssl http2;

    ssl_certificate /etc/letsencrypt/live/<domain-name>/fullchain.pem; # managed by Certbot
    ssl_certificate_key /etc/letsencrypt/live/<domain-name>/privkey.pem; # managed by Certbot
    include /etc/letsencrypt/options-ssl-nginx.conf; # managed by Certbot
    ssl_dhparam /etc/letsencrypt/ssl-dhparams.pem; # managed by Certbot

    root <path-to-docroot>;
    server_name <domain-name>;

    index index.html index.htm index.php;

    location / {
        try_files $uri $uri/ /index.php?$args;
    }	

    location ~ \.php$ {
        include snippets/fastcgi-php.conf;
	fastcgi_pass unix:/run/php/<fpm-socket-name>.sock;
    }
	
    error_log <path-to-logs>/error.log warn;
    access_log <path-to-logs>/access.log apm;
}

server {
    if ($host = <domain-name>) {
        return 301 https://$host$request_uri;
    } # managed by Certbot
	
    listen 80;
    listen [::]:80;

    server_name <domain-name>;
    return 404; # managed by Certbot
}

Die folgende Zeile ist für die „Weiterleitung“ an den FPM-Prozess verantwortlich

fastcgi_pass unix:/run/php/<fpm-socket-name>.sock;

Der PHP-FPM Prozess muss bei jeder neu erstellten oder geändert Konfiguration neu gestartet werden um den Socket zu erstellen, zu dem sich dann der Webserver verbindet. In dem gleichen Zug kann der Webserver auch gleich neugestartet werden.

sudo systemctl restart php7.2-fpm.service nginx

CLI vs WebServer Integration

Wie in der PHP-FPM Beschreibung schon beschrieben können unterschiedliche Konfigurationen für unterschiedliche vHosts erstellt werden.

Das hat natürlich den Vorteil, dass unterschiedliche vHosts mit unterschiedlichen PHP Versionen ausgeführt werden können, was bei Legacy-Software öfters der Fall ist, da diese die neuesten PHP Standards nicht implementiert haben und zu mindest Warnings auftauchen.

Diese Konfiguration ändert aber nichts an der systemweiten installierten PHP Version.

Das bedeutet, dass die PHP Version aus einer PHP-Info Datei nicht unbedingt die gleiche sein muss wie die PHP Version, die aus dem folgenden Befehl über das Terminal erscheint.

php -v
PHP 7.2.19-1+ubuntu18.04.1+deb.sury.org+1 (cli) (built: May 31 2019 11:17:15) ( NTS )
Copyright (c) 1997-2018 The PHP Group
Zend Engine v3.2.0, Copyright (c) 1998-2018 Zend Technologies
    with Zend OPcache v7.2.19-1+ubuntu18.04.1+deb.sury.org+1, Copyright (c) 1999-2018, by Zend Technologies
    with Xdebug v2.7.1, Copyright (c) 2002-2019, by Derick Rethans

Wie ändert man die Standard PHP Version in der CLI?

HINWEIS: Dies ist nur möglich, wenn root bzw. sudo Rechte am Server vorhanden sind!

Über folgenden Befehl findet man heraus, was der Pfad zu einem Befehl ist

which php

Dieser gibt bei meinem Server aktuell folgendes aus:

/usr/bin/php

Wenn man nun diese „Datei“ genauer betrachtet sieht man folgendes:

ls -al /usr/bin/php        
lrwxrwxrwx 1 root root 21 Jan  3  2018 /usr/bin/php -> /etc/alternatives/php

Das bedeutet, dass /usr/bin/php eigentlich nur auf /etc/alternatives/php zeigt, also eine Art Verknüpfung. Hier sieht man aber schon am Pfad, dass es etwas mit den „alternatives“ zu tun hat.

Wenn diese Datei genauer betrachtet wird sieht man folgendes:

ls -al /etc/alternatives/php        
lrwxrwxrwx 1 root root 15 May 31  2018 /etc/alternatives/php -> /usr/bin/php7.2

Dieser Link zeigt nun zum „wirklichen“ Binary, welches dann PHP in der Version ausführt.

ls -al /usr/bin/php7.2      
-rwxr-xr-x 1 root root 4899864 May 31 13:17 /usr/bin/php7.2

D.h. der Befehl „php“ liegt in „/usr/bin/php“, welcher dann weiter zu „/etc/alternatives/php“ und final zu „/usr/bin/php7.2“ linkt.

Um diese „Verlinkung“ nun anzupassen (um eine andere PHP Version in der CLI zu erhalten) kann folgender Befehl eingegeben werden:

sudo update-alternatives --set php /usr/bin/php7.3

Damit haben wir die Standard PHP Version in der CLI von 7.2 auf 7.3 geändert.

php -v
PHP 7.3.6-1+ubuntu18.04.1+deb.sury.org+1 (cli) (built: May 31 2019 11:06:48) ( NTS )
Copyright (c) 1997-2018 The PHP Group
Zend Engine v3.3.6, Copyright (c) 1998-2018 Zend Technologies
    with Zend OPcache v7.3.6-1+ubuntu18.04.1+deb.sury.org+1, Copyright (c) 1999-2018, by Zend Technologies
    with Xdebug v2.7.1, Copyright (c) 2002-2019, by Derick Rethans