PHP

PHP-Serialisierung entscheidet über mehr als nur das Datenformat: serialize() ist schnell und erhält jede Objekteigenschaft, wird bei fremden Daten aber schnell zum Einfallstor für Object Injection. JSON ist sicher und sprachunabhängig, kostet dafür Objektfidelity und etwas Geschwindigkeit. Dieser Beitrag zeigt, wie beide Formate intern funktionieren, wo unserialize() gefährlich wird und wie eine saubere Migration in bestehenden Systemen gelingt.

Jeder require, jedes include und jede Autoloader-Auflösung durchläuft in PHP eine Pfadauflösung, die ohne ausreichend dimensionierten Realpath-Cache bei jedem einzelnen Request erneut Dateisystemzugriffe erzeugt. Gerade bei Projekten mit tausenden Klassen und tiefen Verzeichnisbäumen summiert sich das zu einem Overhead, der sich mit wenigen Zeilen Konfiguration fast vollständig eliminieren lässt.

Bis PHP 8.0 funktionierte der Spread-Operator in Array-Literalen nur mit numerischen Schlüsseln, assoziative Arrays mussten weiterhin über array_merge zusammengeführt werden. Seit PHP 8.1 unterstützt die Spread-Syntax auch String-Keys direkt. Wir zeigen den Unterschied zum klassischen Spread, das Kollisionsverhalten und wann sich der Umstieg von array_merge lohnt.

PHP-Security ist mehr als eine einzelne Funktion oder ein Framework-Feature, sie umfasst Input-Validierung, Output-Encoding, Session-Härtung, Secrets-Management, CSRF-Schutz, Security-Header, saubere Fehlerbehandlung und Dependency-Sicherheit als zusammenhängendes System. Dieser Beitrag gibt den vollständigen Überblick über die Security Best Practices, die jede produktive PHP-Anwendung unabhängig vom eingesetzten Framework braucht.

Ein PHP-Array kann als Stack, Queue und fast alles andere dienen, das ist seine große Stärke und gleichzeitig seine größte Schwäche. Die SPL bringt mit SplStack, SplQueue und SplPriorityQueue spezialisierte Strukturen mit, die nicht nur klarere Absicht im Code ausdrücken, sondern bei bestimmten Operationen auch messbar schneller arbeiten. Wir zeigen, wann sich der Umstieg lohnt.

Eine Pure Function liefert bei gleichen Argumenten immer dasselbe Ergebnis und verändert nichts außerhalb ihres eigenen Rückgabewerts. Dieses Prinzip der referenziellen Transparenz macht PHP-Code vorhersagbar, leicht testbar und parallelisierbar, ganz ohne zusätzliches Framework oder neue Sprachsyntax.

Ein Symfony-Major-Upgrade scheitert selten an Symfony selbst, sondern an Composer-Abhaengigkeiten, die noch nicht kompatibel sind. Mit composer why-not, gezielt gelockerten Constraints und einer sauberen CI-Pipeline lassen sich diese Konflikte systematisch aufloesen, statt sie mit riskanten --ignore-platform-reqs-Flags zu uebertuenchen.

Jahrelang griffen Entwickler zu privaten Properties mit öffentlichem Getter, nur um Lesbarkeit von außen zu erlauben, ohne Schreibzugriff zu öffnen. Asymmetric Visibility beendet diesen Umweg: Eine Property kann öffentlich lesbar und gleichzeitig privat oder protected beschreibbar sein, direkt in der Deklaration, ohne eine einzige Zeile Getter-Code.

Direkte Aufrufe von new DateTime() oder time() sind der klassische Grund, warum zeitabhängige Logik schwer zu testen ist. Eine eigene Clock-Abstraktion löst das Problem an der Wurzel und erlaubt es, feste Zeitpunkte in PHPUnit-Tests zu setzen.

OPcache Preloading lädt ausgewählte Klassen und Funktionen einmalig beim Start eines PHP-FPM-Workers in einen dauerhaften Speicherbereich, sodass sie für jeden folgenden Request sofort verfügbar sind. Richtig konfiguriert spart das spürbar Zeit für Autoloading, Vererbungsauflösung und Interface-Checks, falsch konfiguriert bringt es nichts oder erzeugt schwer nachvollziehbare Fehler nach jedem Deploy.