PHP 8.5 in Shopware: Migration aus Agentursicht 2026

Mit dem Release von PHP 8.5 am 20.11.2025 (php.net) ist die letzte 8.x-Version vor PHP 9.0 erschienen - und für Shopware-Agenturen wird die saubere Migration zur Pflichtaufgabe. Shopware unterstützt PHP 8.5 ab Version 6.7.7 (Shopware Release-Notes / FriendsOfShopware static-data), die im Februar 2026 veröffentlicht wurde. Die Performance-Versprechen sind real: Tideways misst rund +9 % bei CPU-intensiven Workloads gegenüber 8.3, Kinsta dokumentiert +33 % Requests/Sekunde unter WooCommerce im Vergleich zu PHP 8.4. Diese Zahlen entstehen aber nur dann, wenn die Migration sauber orchestriert wird: Plugin-Kompatibilität geprüft, Deprecations adressiert, OPcache richtig dimensioniert und der Rollout über Staging in Production geführt. Dieser Beitrag fokussiert bewusst die Agentur- und Hosting-Perspektive: konkrete Audit-Workflows, automatisierte Test-Patterns, ein Rollout-Plan für Multi-Shop-Hosting und Monitoring-Vorgaben nach dem Go-Live. Eine generische Performance-Übersicht liefert ergänzend der Beitrag zu Shopware 6 auf PHP 8.5 migrieren - hier geht es um die operative Umsetzung.

PHP 8.5 im Überblick: Was ist neu?

PHP 8.5 ist als letzte 8.x-Version vor PHP 9.0 (php.net) ein wichtiger Meilenstein. Sprachlich bringt das Release den lange diskutierten Pipe-Operator|> (Stitcher / Laravel News), zwei neue Array-Funktionen (array_first() und array_last()), eine Clone-with-Syntax, das #[\Override]-Attribut, eine neue URI-Extension sowie verbesserte Fehlerbilder mit Backtraces auch bei Fatal Errors (Phoronix / Zend). PHP dominiert weiterhin den Web-Stack mit 73,3 % aller Websites mit bekannter Server-Sprache (W3Techs Mai 2026); laut der JetBrains State of PHP 2025 (n=1720) ist PHP 8.x die klar dominante Major-Version. Wer Shopware-Stores betreibt, kommt an PHP 8.5 mittelfristig nicht vorbei - insbesondere weil PHP 7.4 bereits seit 28.11.2022 End-of-Life ist (Zend / TuxCare) und alle in 8.5 ausgesprochenen Deprecations in PHP 9.0 zu Fatal Errors werden (Zend).

Performance-Benchmarks: 8.3 vs 8.4 vs 8.5

Die Benchmark-Lage zeigt ein differenziertes Bild. Tideways misst PHP 8.5 in CPU-intensiven Workloads rund 9 % schneller als PHP 8.3. Kinsta veröffentlicht für WooCommerce unter PHP 8.5 etwa 33 % mehr Requests/Sekunde als unter PHP 8.4 - der größte Sprung seit Jahren. Sevalla hingegen findet bei Laravel-Workloads mit hoher DB-Last nur marginale Unterschiede zwischen 8.2 und 8.5 (430 bis 445 req/s) - der Bottleneck liegt dort schlicht in der Datenbank, nicht im PHP-Interpreter. Ähnlich zeigt Kinsta für WordPress unter 8.3, 8.4 und 8.5 nahezu identische Werte (5,42 bis 5,43 req/s). Historisch lieferte schon PHP 8.1 laut Zend etwa +18,4 % Requests/Sekunde gegenüber 7.4, und die JIT-Einführung in 8.0 brachte laut Mobidev 20 bis 30 % Beschleunigung in synthetischen Benchmarks. Für die Praxis heißt das: Wer noch auf 7.4 oder 8.1 steht, sieht durch das Update den größten Effekt. Wer von 8.3 oder 8.4 kommt, holt vor allem bei CPU-lastigen Operationen (Template-Rendering, Image-Processing, Suche-Indizierung) sichtbare Gewinne.

Pipe-Operator und neue Array-Funktionen

Der Pipe-Operator ist die sichtbarste Neuerung. Im Shopware-Kontext eignet er sich besonders für Daten-Transformations-Pipelines in eigenen Services - etwa bei der Aufbereitung von Produktdaten für externe Schnittstellen, Feed-Generierung oder Import-Routinen. Das nachfolgende Beispiel zeigt typische Vorher-/Nachher-Patterns aus echten Programmier-Projekten.

<?php
// Vorher (PHP 8.3): verschachtelte Funktionen
$slug = strtolower(trim(preg_replace('/[^a-z0-9]+/i', '-', $name)));

// Nachher (PHP 8.5): Pipe-Operator
$slug = $name
    |> trim(...)
    |> fn(string $s) => preg_replace('/[^a-z0-9]+/i', '-', $s)
    |> strtolower(...);

// array_first() / array_last() statt reset()/end()
// Vorher: modifiziert internen Array-Pointer
$first = reset($products);
$last = end($products);

// Nachher: ohne Seiteneffekt
$first = array_first($products);
$last = array_last($products);

// #[\Override] in Shopware-Subscribern
use Shopware\Core\Framework\Event\NestedEventCollection;

class ProductSubscriber implements EventSubscriberInterface
{
    #[\Override]
    public static function getSubscribedEvents(): array
    {
        return ['product.loaded' => 'onProductLoaded'];
    }
}

Breaking Changes und Deprecations

PHP 8.5 ist im Wesentlichen abwärtskompatibel, deprecated aber eine Reihe von Konstrukten, die in PHP 9.0 zu Fatal Errors werden (Zend). Für Agenturen heißt das: Jetzt bereinigen, nicht erst beim Sprung auf 9.0. Die folgende Liste zeigt die für Shopware-Codebasen relevantesten Punkte.

• MHASH_*-Konstanten deprecated (Zend). Selten genutzt, aber in Legacy-Plugins für Hash-Operationen vereinzelt zu finden.
• Non-canonical Casts deprecated (RFC wiki.php.net): (integer) und (double) sollen durch (int) und (float) ersetzt werden.
• Inkrement von nicht-numerischen Strings deprecated (Zend). Empfohlen: str_increment() für alphabetische Inkremente.
• Alternative Case-Syntax mit Semikolon entfernt (PHP RFC 8.5): case Foo; ist jetzt ungültig, nur noch case Foo: funktioniert.
• filter_*()$filter-Parameter zwingend (Zend): Die bisherige Default-Variante wird entfernt.
• Implicit nullable Parameter deprecated (PHP 8.4 fortgesetzt): function foo(string $s = null) muss als ?string $s = null deklariert werden.
• get_class() und get_parent_class() ohne Parameter deprecated: Statt impliziter Selbst-Referenz static::class oder parent::class verwenden.
• Verschiedene *_unserialize()-Varianten deprecated: Sicherheitsbedingt - explizit den allowed_classes-Parameter setzen.
• getInternalMetadata() (Date/Time) deprecated: Interne API, in einigen Date-Plugins verwendet.
• Diverse Typ-Coercion-Warnungen verschärft: null an string-Parameter ohne ?string-Deklaration wird strenger geprüft.

Shopware-Kompatibilität: 6.7.7 als Mindestversion

PHP 8.5 wird offiziell ab Shopware 6.7.7 unterstützt (Shopware Release-Notes / FriendsOfShopware static-data). Die 6.6.x-Linie bleibt auf PHP 8.2 bis 8.3 limitiert, ältere 6.4.x-Stände sogar auf PHP 7.4 / 8.0. Für Stores, die noch auf 6.5 oder 6.6 stehen, sind also zwei Sprünge nötig: zuerst Major-Update auf 6.7, dann der PHP-Wechsel. Shopware selbst kommuniziert für 6.7 deutliche Storefront-Verbesserungen - laut Shopware doppelt so viele Bestellungen pro Sekunde gegenüber 6.6 und rund 25 % kleinere JS/CSS-Bundles. Eine Shopware-Migrations-Beratung ist hier oft sinnvoller als der reine Versions-Sprung. Wichtig zu wissen: Plugin-Kompatibilität hinkt traditionell 2 bis 3 Monate hinter Major-Releases hinterher; Branchen-Erfahrung zeigt, dass rund 75 bis 80 % der gängigen Plugins binnen 3 Monaten nach einem PHP-Major-Wechsel kompatibel sind. Für die übrigen 20 bis 25 % gilt es, früh zu prüfen, ob ein Update geplant ist, ein Fork betreut werden muss oder eine Eigenentwicklung sinnvoller ist.

Plugin-Audit vor der Migration

Der Plugin-Audit ist die zentrale Hebel-Station jeder PHP-Migration. Aus Agentursicht hat sich ein vierstufiges Vorgehen bewährt: erst inventarisieren, dann statisch analysieren, dann dynamisch testen, dann Update- bzw. Refactor-Plan ableiten. Ohne diese Reihenfolge läuft jede Migration ins Risiko, dass auf Staging Fehler nicht reproduziert werden, weil bestimmte Plugins unter Last andere Code-Pfade nehmen als unter Test-Last.

1. Inventarisierung: Alle aktiven Plugins listen (Composer-Lockfile + Shopware Admin Plugin-Manager). Trennung in First-Party (eigene Entwicklung), Third-Party kommerziell (Hersteller-Support) und Third-Party Community (oft ohne aktiven Maintainer).
2. Statische Analyse mit PHPStan / Psalm: Mindestens Level 5, idealerweise Level 7. Custom-Rules für PHP-8.5-Deprecations einbinden, Fehler pro Plugin segmentieren.
3. Composer-Constraint-Check: composer why-not php 8.5 listet alle Pakete, die PHP 8.5 explizit ausschließen. Diese Liste ist die Kurz-Roadmap für Hersteller-Updates.
4. Manuelle Code-Review für Hot-Paths: Checkout-Plugins, Payment-Provider, ERP-Connector, Search-Plugins. Das sind die kritischen Punkte mit hohem Schadenspotenzial bei Fehlern.
5. Dynamischer Test mit echten Daten-Schnitten: Anonymisierter Production-Dump in Staging einspielen, Plugin-Funktionalität entlang typischer Customer-Journeys durchtesten.
6. Risiko-Matrix erstellen: Pro Plugin Score aus (Kritikalität × Update-Status × Refactor-Aufwand). Steuert die Priorisierung in Sprint-Plänen.
7. Lizenz- und Vertragslage prüfen: Bei kommerziellen Plugins, ob ein Update-Vertrag besteht und ein PHP-8.5-fähiges Release angekündigt ist.
8. Fallback-Plan: Für Plugins ohne PHP-8.5-Update klären, ob Fork, Eigenentwicklung oder Funktions-Verzicht der richtige Weg ist.

Test-Strategie für die Migration

Eine PHP-Migration ohne automatisierte Tests ist russisches Roulette. Die folgenden vier Test-Ebenen haben sich für Shopware-Stores bewährt: Unit-Tests auf Service- und Helper-Ebene, Integration-Tests gegen Shopware-Kernel und Datenbank, End-to-End-Tests mit Playwright oder Cypress für Storefront-Flows, sowie Smoke-Tests für die wichtigsten Cron- und Queue-Jobs. Für die Migration speziell empfehlen wir, einen dedizierten PHP-8.5-Matrix-Lauf in der CI/CD aufzusetzen, der den gesamten Test-Stack parallel zu PHP 8.3 und 8.4 ausführt. Das deckt Regressionen früh auf - lange bevor Code in den Master-Branch gelangt. Komplett-Setups dieser Art unterstützen wir typischerweise in der Programmierung - inklusive GitHub-Actions- oder GitLab-CI-Konfiguration.

<?php
declare(strict_types=1);

namespace App\Tests\Migration;

use PHPUnit\Framework\TestCase;
use PHPUnit\Framework\Attributes\RequiresPhp;
use Shopware\Core\Framework\Test\TestCaseBase\IntegrationTestBehaviour;

#[RequiresPhp('>=8.5')]
final class Php85CompatibilityTest extends TestCase
{
    use IntegrationTestBehaviour;

    public function testPipeOperatorInProductSlugBuilder(): void
    {
        $name = ' Bio-Apfel "Boskoop" ';
        $slug = $name
            |> trim(...)
            |> fn(string $s) => preg_replace('/[^a-z0-9]+/i', '-', $s)
            |> strtolower(...);

        self::assertSame('bio-apfel-boskoop-', $slug);
    }

    public function testArrayFirstReturnsFirstElementWithoutPointerSideEffect(): void
    {
        $products = ['SKU-1', 'SKU-2', 'SKU-3'];
        // Pointer bleibt unverändert - Vorteil gegenüber reset()
        self::assertSame('SKU-1', array_first($products));
        self::assertSame('SKU-1', array_first($products));
    }

    public function testNoDeprecatedCastsRemain(): void
    {
        $output = shell_exec('php -d error_reporting=E_ALL -l src/');
        self::assertStringNotContainsString('Deprecated', (string) $output);
    }
}

OPcache-Tuning für maximale Performance

OPcache ist der wichtigste Performance-Hebel in jedem Shopware-Setup - und unter PHP 8.5 lohnt sich ein Review der Konfiguration. maxcluster empfiehlt für Shopware und Magento 512 MB OPcache sowie opcache.max_accelerated_files=65407 als realistische Mittelwerte. OPcache-Preload bringt zusätzlich rund 2 bis 5 % Performance (maxcluster), erfordert aber, dass Preload-Skripte zur Shopware-Version passen - sonst entstehen Ladefehler beim Worker-Start. Für komplexere Setups gehen wir typischerweise iterativ vor: Baseline messen, OPcache-Stats per opcache_get_status() analysieren, gezielt erhöhen oder reduzieren. Im Zusammenspiel mit Managed Hosting für Online-Shops sind solche Tuning-Schleifen Routine.

; OPcache Konfiguration für Shopware 6.7.7+ unter PHP 8.5
opcache.enable=1
opcache.enable_cli=0
opcache.memory_consumption=512
opcache.interned_strings_buffer=64
opcache.max_accelerated_files=65407
opcache.validate_timestamps=0
opcache.revalidate_freq=0
opcache.save_comments=1
opcache.fast_shutdown=1
opcache.huge_code_pages=1
opcache.jit=tracing
opcache.jit_buffer_size=128M

; Preload (nur wenn Shopware-Version stabil)
opcache.preload=/var/www/shopware/var/cache/opcache-preload.php
opcache.preload_user=www-data

; Realpath-Cache (häufig unterschätzt, hoher Effekt)
realpath_cache_size=4096K
realpath_cache_ttl=600

Rollout-Plan: Staging zu Production

Der Rollout selbst ist der Punkt, an dem Migrationen kippen können. Die folgenden sechs Phasen haben sich für Shopware-Migrationen aus der Agenturpraxis bewährt - und sind sowohl für Single-Shop- als auch für Multi-Shop-Hostings anwendbar.

1. Phase 1 - Baseline (Woche 1): Aktuelle Performance messen (TTFB, LCP, OPcache-Hit-Rate, Queue-Throughput). Plugin-Inventar, Composer-Lockfile, PHP-Konfiguration dokumentieren. Erfolgskriterien definieren.
2. Phase 2 - Staging-Setup (Woche 2): Klon der Production auf identischer Infrastruktur. Anonymisierter Daten-Dump. PHP 8.5 + Shopware 6.7.7 als Doppel-Update parallel zur 8.3-Variante.
3. Phase 3 - Plugin-Audit und Fixes (Woche 3-4): Statische Analyse, Deprecation-Cleanup, Plugin-Updates. Custom-Plugins anpassen. Test-Suite grün bekommen.
4. Phase 4 - Last-Tests (Woche 5): k6, Locust oder JMeter mit produktionsnahen Szenarien. CPU-, Memory- und DB-Profil pro PHP-Version vergleichen. Regression-Schwellen definieren.
5. Phase 5 - Canary-Rollout (Woche 6): Bei Multi-Shop-Hosting zuerst auf einem unkritischen Mandanten umstellen. Bei Single-Shop: Traffic-Split via Reverse-Proxy (z.B. 5 % auf 8.5, 95 % auf 8.3).
6. Phase 6 - Vollumstellung (Woche 7-8): Stufenweise auf 100 %, mit definiertem Rollback-Pfad (PHP-Version per update-alternatives oder Container-Tag). Nach 48 h ohne Auffälligkeiten Rollback-Window schließ.

Monitoring nach dem Go-Live

Nach dem Go-Live entscheidet das Monitoring, ob die Migration als Erfolg gilt. Wir empfehlen drei Beobachtungsebenen, idealerweise auf einem zentralen Dashboard zusammengeführt: Application-Performance-Monitoring (APM) für PHP-Internals (Request-Time, OPcache-Hit-Rate, Memory pro Request), Infrastructure-Monitoring für FPM-Pools, MariaDB/MySQL und Redis sowie Real-User-Monitoring (RUM) für LCP, INP, CLS aus Sicht der Endnutzer. Insbesondere die OPcache-Hit-Rate ist nach einer PHP-Migration ein Frühindikator: Fällt sie unter 95 %, ist meist max_accelerated_files zu klein oder Preload greift nicht. Ergänzend lohnt sich der Blick auf die Shopware 6 Performance-Optimierung und das Edge-Caching für globale Shopware-Performance - beides verstärkt den PHP-8.5-Effekt.

Ein typisches Beobachtungsfenster sind die ersten 14 Tage nach Go-Live. In dieser Phase laufen oft Edge-Cases auf, die im Test-Setup nicht abgebildet waren - etwa selten getriggerte Cron-Jobs, Sondermandate eines B2B-Kunden oder spezielle Currency-Konstellationen. Wir empfehlen, in dieser Phase PHP-Error-Logs auf E_DEPRECATED-Niveau auszuwerten: Selbst harmlos wirkende Warnings können Hinweise auf Code-Stellen geben, die in PHP 9.0 brechen werden. Die Erkenntnisse fließ direkt in den nächsten Sprint - so wird die PHP-8.5-Migration zur Vorarbeit für den 9.0-Sprung, nicht zum isolierten Einzelprojekt.

PHP 8.5 als Vorbereitung auf den 9.0-Sprung

Wer PHP 8.5 jetzt sauber einführt, macht den Sprung auf PHP 9.0 deutlich planbarer: Die in 8.5 deprecated markierten Konstrukte werden in 9.0 zu Fatal Errors (Zend), und alles, was heute schon entfernt ist, muss später nicht im Krisenmodus angefasst werden. Aus Agentursicht ist die 8.5-Migration damit kein technisches Update, sondern ein strategischer Ankerpunkt: Sie ist die letzte Gelegenheit, Codebasen sortiert in das nächste Major-Zeitalter zu führen, ohne unter Zeitdruck zu stehen. Für Shopware-Betreiber ist das doppelt relevant, weil Shopware 6.8/6.9 absehbar PHP 9.0 als Mindestversion verlangen werden - und dann zählt jeder Monat Vorlauf. Der konsequente Einsatz von Static-Analysis-Tools, automatisierten Tests und einer dokumentierten Plugin-Roadmap ist dabei der Unterschied zwischen einer ruhigen Migration und einem Krisenprojekt.

Häufige Fragen zur PHP-8.5-Migration