Shopware 6.7 represents a significant evolution in the platform's architecture. Built on modern Symfony components, stricter type systems, and an optimized service container, it demands a PHP environment that matches its performance expectations. Misconfigured PHP settings remain the most common cause of silent failures, timeout errors, and memory exhaustion during deployment or high-traffic events. This guide walks you through exactly how to align your PHP configuration with Shopware 6.7's requirements, focusing on practical reasoning rather than copy-paste checklists.

PHP Version & Essential Extensions

Shopware 6.7 requires PHP 8.2 or higher, with PHP 8.3 strongly recommended for production workloads. The framework leverages union types, match expressions, named arguments, and optimized standard library functions that simply do not exist in older versions. Beyond the version, you must ensure a specific set of extensions is compiled and loaded. Shopware's installer validates these during bin/prepare, but proactive configuration prevents deployment friction later.

The most critical group includes intl and mbstring. Shopware 6.7 uses intl for currency formatting, tax localization, and multi-store routing logic. Without it, pricing calculations will fall back to broken fallbacks or crash during checkout. mbstring ensures proper UTF-8 handling across customer addresses, product descriptions, and plugin configurations. You also need pdo_mysql (or pdo_pgsql), curl, dom, filter, json, openssl, zip, zlib, sodium, bcmath, tokenizer, ctype, fileinfo, session, simplexml, iconv, xmlreader, and xmlwriter. Missing bcmath breaks decimal precision in cart calculations, while a disabled sodium extension disrupts secure token generation for admin sessions and API endpoints.

Core php.ini Directives Explained

The foundation of Shopware 6.7 stability lies in your php.ini file. Rather than adjusting random values, understand what each directive controls in the context of modern e-commerce workloads.

  • memory_limit: Set to 512M for CLI and 256M–512M for FPM. Shopware 6.7's dependency injection container, cache warmers, and plugin bootstrapping load hundreds of service definitions into memory. During bin/console system:install or major version upgrades, memory spikes are normal but will crash silently if the limit is too low.
  • max_execution_time: Configure to 300+ for CLI and 60–120 for FPM. Long-running operations like catalog synchronization, media migration, or background indexing rely on console commands that bypass web server timeouts but still respect PHP's execution boundary.
  • max_input_vars: Increase to 3000+. Shopware's admin UI and checkout process serialize hundreds of hidden fields for cart rules, shipping methods, and payment gateways. The default 1000 truncates the request payload, leading to empty tax or address data on submission.
  • upload_max_filesize & post_max_size: Keep them equal (e.g., 128M). Shopware 6.7's media management and plugin uploader treat these as a paired boundary. If post_max_size < upload_max_filesize, the server returns a 500 error without logging it, which confuses troubleshooting.
  • realpath_cache_size & realpath_cache_ttl: Set to 4096K and 7200. Shopware's autoloader resolves plugin paths, service definitions, and config files on nearly every request. Without a large realpath cache, PHP repeatedly queries the filesystem, creating I/O bottlenecks that manifest as slow admin responses or stuck background jobs.

The CLI vs FPM Context Trap

One of the most frequent configuration mistakes is treating CLI and web-FPM as identical contexts. Shopware 6.7 heavily relies on bin/console for installation, maintenance, queue workers, and cron-based indexing. These commands run under a completely different PHP interpreter than your Nginx/Apache + FPM stack. On Debian/Ubuntu, these are typically /etc/php/8.3/cli/php.ini and /etc/php/8.3/fpm/php.ini. Applying web limits to CLI will break database migrations; applying CLI limits to FPM will crash the storefront during peak traffic. Always verify active settings using php -i | grep memory_limit for CLI and php-fpm8.3 --status or <?php phpinfo(); ?> for web contexts.

OPCache & JIT Optimization for Shopware 6.7

OPCache is not optional for Shopware 6.7; it's structural. The framework loads dozens of PHP files per request, and Symfony's service container caches compiled class graphs that perform best when opcache handles file validation. Disable opcache.validate_timestamps in production, but pair it with manual cache clearing or deployment hooks to avoid stale code execution.

opcache.enable=1
opcache.memory_consumption=256
opcache.max_accelerated_files=20000
opcache.validate_timestamps=0
opcache.revalidate_freq=0
opcache.jit=1235
opcache.jit_buffer_size=128M

Shopware 6.7's routing, tax calculations, and plugin service resolution benefit significantly from PHP 8.2+'s JIT compiler. The jit=1235 profile enables function-level compilation for frequently executed paths while keeping memory overhead manageable. Increase opcache.memory_consumption only after monitoring actual opcode cache usage via opcache_get_status().

Security, Error Handling & Session Alignment

Shopware 6.7's security layer assumes Symfony's secure defaults. Production environments must disable debug output and enforce strict session behavior:

display_errors = Off
log_errors = On
error_reporting = E_ALL & ~E_DEPRECATED & ~E_STRICT
expose_php = Off
session.cookie_httponly = 1
session.use_strict_mode = 1
session.cookie_secure = 1 ; Requires HTTPS

Mismatched settings cause CSRF validation failures, session fixation risks, or exposed stack traces when plugin hooks throw exceptions. Shopware routes all unhandled errors through var/log/dev.log and var/log/prod.log. Ensure log_errors = On and that the var/ directory is writable by the PHP-FPM user.

Validation & Troubleshooting Workflow

After applying changes, restart FPM (systemctl restart php8.3-fpm) and clear Shopware's cache with bin/console cache:clear. Verify your configuration by checking the status endpoint at /admin, monitoring Symfony profiler metrics for memory usage, and testing critical paths like checkout, media upload, and plugin installation. If you encounter silent failures, enable temporary debugging via SHOPWARE_DEBUG=1, inspect log levels, and verify extension load order using php -m. Always test PHP configuration changes in staging first; Shopware 6.7's strict dependency graph means a single misaligned directive can cascade into deployment blocks or runtime exceptions.

Conclusion

Proper PHP configuration is the bedrock of Shopware 6.7's reliability, speed, and security posture. By aligning your environment with the framework's architectural demands—correct extensions, context-aware limits, optimized opcode caching, and hardened security defaults—you eliminate entire classes of production friction. Verify, measure, and iterate. When configured correctly, Shopware 6.7 delivers predictable performance under load, scales efficiently across multi-store setups, and provides the modern e-commerce foundation your business requires.