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.

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.

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.

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.

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.

Ohne Rate Limiting genügt ein einziger fehlerhafter Client-Loop oder ein gezielter Angriff, um eine PHP-API in die Knie zu zwingen. Ein eigenes Rate Limiting lässt sich mit Redis und wenigen Zeilen PHP umsetzen, ganz ohne Drittanbieter-Gateway, und die Wahl zwischen Fixed Window, Sliding Window und Token Bucket entscheidet darüber, wie fair und wie burst-tolerant der Schutz tatsächlich ausfällt.

Die meisten Erklärungen zu SOLID-Prinzipien arbeiten mit Formen, Enten oder Tieren und lassen offen, wie das in echtem Anwendungscode aussieht. Dieser Artikel nimmt stattdessen eine durchgehende Order-Processing-Pipeline in PHP 8.4, an der jedes der fünf Prinzipien ein konkretes, nachvollziehbares Wartbarkeitsproblem löst: eine Order-Klasse, die zu viel macht, Rabattregeln, die zu einer if/else-Kaskade wuchern, ein Payment-Gateway, das seinen eigenen Vertrag bricht, ein zu fettes Repository-Interface und ein Notification-Service, der zu eng an einen konkreten Mailer gekoppelt ist.

Wer bei großen Datenmengen wahllos zwischen array_map, foreach und Generatoren wechselt, riskiert unnötigen Speicherverbrauch und schwer nachvollziehbare Laufzeiten. Dieser Artikel vergleicht die wichtigsten Array-Funktionen in PHP 8.4 mit echten Benchmarks, zeigt, wann Generatoren mit yield den entscheidenden Unterschied machen, und liefert klare Entscheidungsregeln für den Projektalltag.

Doctrine oder Eloquent zu benutzen ist einfach, zu verstehen, warum sie so funktionieren, wie sie funktionieren, ist es nicht. Wer einmal ein eigenes minimales ORM gebaut hat, versteht Hydration, Unit of Work und Identity Map nicht mehr abstrakt, sondern als konkrete Entscheidungen mit klaren Kompromissen.