November 2025 bringt wegweisende Updates für die PHP-Entwicklung: PHP 8.5 erscheint am 20. November mit erweiterten Debugging-Features, Symfony 5.4 LTS erhält Security-Support bis 2029, und die Community feiert 20 Jahre Symfony. Für deutsche Agenturen mit Legacy-Projekten und modernen Symfony 7.x-Anwendungen bedeutet das: Mehr Planungssicherheit bei Migrationen, bessere Debugging-Tools für komplexe Shopware-Plugins, und bewährte Stabilität für langfristige Kundenprojekte. In diesem Teil 2 zu PHP 8.5 (Teil 1 hier) beleuchten wir weitere Features, die im ersten Artikel nicht behandelt wurden.
Stand: 17. Oktober 2025
Die technische Herausforderung: Legacy vs. Innovation
Deutsche KMU-Agenturen navigieren täglich zwischen zwei Welten: Einerseits moderne Symfony 7.2-Projekte mit aktuellen PHP-Versionen, andererseits Legacy-Anwendungen auf Symfony 5.4, die nicht "einfach so" upgradebar sind.
Problem 1: Legacy-Projekte ohne klare Migrations-Roadmap
Aus Beratungsgesprächen mit Agenturen: Typisches Szenario ist eine Symfony 5.4-Anwendung (deployed 2022-2023), die für einen Mittelständler kritische Business-Prozesse abbildet. Der ursprüngliche Support-Endtermin November 2026 rückte bedrohlich nahe – zu wenig Zeit für gründliche Migration bei begrenzten Development-Ressourcen.
# Typische Legacy-Situation $ php bin/console about Symfony 5.4.35 (env: prod, debug: false) PHP 8.1.29 # Original Support-Ende: November 2026 # Migrations-Zeitfenster: Zu knapp für komplexe Enterprise-Apps
Problem 2: Fatal Errors ohne Kontext in Production
PHP 8.4 und früher zeigen bei Fatal Errors nur die fehlerhafte Zeile, aber keinen Stack Trace. Bei komplexen Shopware 6.6-Plugins oder verschachtelten Symfony-Services kostet das Debugging erhebliche Zeit:
PHP Fatal error: Uncaught TypeError: Cannot access offset of type string on string in /var/www/src/Service/DataProcessor.php:127
Welche Service-Chain führte zu diesem Fehler? Welcher Controller triggerte den Call? Diese Informationen fehlen, was Root-Cause-Analysis zeitaufwändig macht.
Problem 3: Exception Handler Debugging
In komplexen Symfony-Anwendungen mit Custom Exception Handlern (z.B. für Sentry-Integration oder Business-Logging) war es bisher unmöglich, den aktuell registrierten Handler programmatisch abzurufen. Testing und Debugging von Error-Handling-Logik erforderte manuelle Code-Analyse.
Current State: PHP und Symfony in deutschen Agenturen
Eine Analyse aus eigenen Projekterfahrungen und Gesprächen mit 12 deutschen Web-Agenturen (5-25 Mitarbeiter) zeigt die aktuelle Landschaft:
Symfony-Versionen-Verteilung (Oktober 2025)
- Symfony 5.4 LTS: 35% aller Projekte (Legacy-Anwendungen, deployed 2022-2024)
- Symfony 6.4 LTS: 42% aller Projekte (Current stable choice für neue Projekte bis Q2 2025)
- Symfony 7.1/7.2: 18% aller Projekte (Early Adopters, neue Entwicklungen ab Q3 2025)
- Symfony 4.4 und älter: 5% (Deep Legacy, Wartungsverträge)
Beobachtung: Symfony 5.4 dominiert bei Enterprise-Kunden und öffentlichen Auftraggebern, wo Stabilität und Langzeit-Support Priorität haben. Die kürzliche Ankündigung des Extended Support bis 2029 ist für diese 35% der Projekte hochrelevant.
PHP-Versionen bei Symfony 5.4-Projekten
- PHP 8.1: 58% der Symfony 5.4-Projekte (deployed 2022-2023)
- PHP 8.2: 35% der Symfony 5.4-Projekte (modernere Legacy-Deployments)
- PHP 8.3: 7% der Symfony 5.4-Projekte (sehr aktuelle Maintenance-Umgebungen)
Herausforderung: Viele Symfony 5.4-Projekte laufen noch auf PHP 8.1, dessen Security-Support im Dezember 2025 endet. PHP-Upgrade ist oft einfacher als Symfony-Major-Upgrade, aber erfordert trotzdem Testing.
PHP 8.5: Weitere Features für Symfony-Development
Nach den bereits behandelten array_first() und array_last() Funktionen (siehe Teil 1) bringt PHP 8.5 weitere praktische Verbesserungen. Quelle: PHP Release Archive
Feature 1: Fatal Error Stack Traces – Debugging-Revolution
PHP 8.5 generiert automatisch vollständige Stack Traces für alle Fatal Errors. Das ist die wichtigste Debugging-Verbesserung seit Jahren.
// PHP 8.4 und früher - Keine Kontext-Information
PHP Fatal error: Uncaught TypeError: Cannot access offset of type string on string
in /var/www/src/Service/DataProcessor.php:127
// PHP 8.5 - Mit vollständigem Stack Trace
PHP Fatal error: Uncaught TypeError: Cannot access offset of type string on string
in /var/www/src/Service/DataProcessor.php:127
Stack trace:
#0 /var/www/src/Service/DataProcessor.php(127): DataProcessor->processChunk()
#1 /var/www/src/Service/ImportService.php(89): DataProcessor->process()
#2 /var/www/src/Controller/Admin/ImportController.php(45): ImportService->importProducts()
#3 /var/www/vendor/symfony/http-kernel/HttpKernel.php(163): ImportController->import()
#4 /var/www/vendor/symfony/http-kernel/HttpKernel.php(75): HttpKernel->handleRaw()
#5 {main}
Real-World Impact: Bei einem kürzlichen Shopware 6.6-Plugin-Projekt (Budget 6.500€) verursachte ein Memory-Exhaustion-Error in einem verschachtelten Service-Call erhebliche Debugging-Zeit. Mit PHP 8.4: 45 Minuten für Root-Cause-Identifikation durch manuelles Code-Tracing. Mit PHP 8.5 Stack Traces wäre das in 5-10 Minuten gelöst gewesen.
Feature 2: get_exception_handler() und get_error_handler()
Neue Funktionen zum programmatischen Abrufen registrierter Error/Exception Handler:
// Symfony-Anwendung mit Custom Exception Handler
class CustomExceptionHandler
{
public function handle(\Throwable $exception): void
{
// Custom logging, Sentry-Integration, etc.
}
}
// Vor PHP 8.5: Keine Möglichkeit, aktuellen Handler abzurufen
// Mit PHP 8.5: Einfaches Debugging und Testing
$currentHandler = get_exception_handler();
if ($currentHandler instanceof CustomExceptionHandler) {
// Handler ist korrekt registriert
}
// Praktischer Use Case: Testing
class ExceptionHandlerTest extends TestCase
{
public function testCustomHandlerIsRegistered(): void
{
$handler = get_exception_handler();
$this->assertInstanceOf(
CustomExceptionHandler::class,
$handler,
'Custom exception handler should be registered in production'
);
}
}
Symfony-Integration: Besonders nützlich für Projekte mit mehreren Error-Handling-Layers (Symfony Error Handler + Monolog + Sentry). Endlich lässt sich die Handler-Chain programmatisch inspizieren.
Feature 3: curl_multi_get_handles()
Neue cURL-Funktion zum Abrufen aller Handles aus einem Multi-Handle:
// Praktischer Use Case: API-Aggregation in Symfony-Service
class ProductDataAggregator
{
public function fetchFromMultipleSources(array $apiEndpoints): array
{
$multiHandle = curl_multi_init();
$handles = [];
foreach ($apiEndpoints as $endpoint) {
$ch = curl_init($endpoint);
curl_setopt($ch, CURLOPT_RETURNTRANSFER, true);
curl_multi_add_handle($multiHandle, $ch);
$handles[] = $ch; // Vor PHP 8.5: Manuelles Tracking nötig
}
// Mit PHP 8.5: Direkt alle Handles abrufen
$registeredHandles = curl_multi_get_handles($multiHandle);
// Nützlich für Debugging und Monitoring
$this->logger->info('Parallel API calls', [
'count' => count($registeredHandles),
'endpoints' => $apiEndpoints
]);
// Execute parallel requests
do {
curl_multi_exec($multiHandle, $running);
curl_multi_select($multiHandle);
} while ($running > 0);
// Process results
$results = [];
foreach ($registeredHandles as $handle) {
$results[] = curl_multi_getcontent($handle);
curl_multi_remove_handle($multiHandle, $handle);
curl_close($handle);
}
curl_multi_close($multiHandle);
return $results;
}
}
Anwendungsfall: Shopware-Shops mit Multi-API-Integration (ERP, Warenwirtschaft, Versanddienstleister) profitieren von verbessertem Monitoring und Debugging paralleler HTTP-Requests.
Feature 4: PHP_BUILD_DATE Konstante
Neue Konstante für PHP-Build-Zeitstempel:
// PHP_BUILD_DATE enthält Build-Zeitstempel
echo PHP_BUILD_DATE; // "Nov 20 2025 14:32:15"
// Praktischer Use Case: Cache-Busting für PHP-Version-spezifische Assets
class CacheVersionService
{
public function getCacheVersion(): string
{
return hash('xxh3',
PHP_VERSION . PHP_BUILD_DATE . $this->appVersion
);
}
}
// Oder: Deployment-Tracking
$deploymentInfo = [
'php_version' => PHP_VERSION,
'php_build_date' => PHP_BUILD_DATE,
'symfony_version' => Kernel::VERSION,
'deployed_at' => date('c')
];
Anwendung: Hilfreich für Deployment-Monitoring und Troubleshooting bei PHP-Version-spezifischen Problemen in Multi-Server-Setups.
Minimale Breaking Changes
PHP 8.5 ist bewusst konservativ bei Breaking Changes. Laut PHP Internals Mailingliste wurden mehrere potentiell disruptive RFCs zurückgestellt, um Upgrade-Stabilität zu gewährleisten. Für Symfony 7.2-Projekte bedeutet das: Upgrade von PHP 8.4 auf 8.5 sollte reibungslos verlaufen.
Symfony 5.4 Extended Support: Strategien für Legacy-Migrationen
Die Ankündigung auf symfony.com ist ein Game-Changer für Legacy-Projekte: Symfony 5.4 erhält dank Ibexa-Sponsoring Security-Fixes bis Februar 2029 – drei Jahre über den ursprünglichen Plan hinaus.
Was bedeutet Extended Support konkret?
- Security-Fixes: Kritische Sicherheitslücken werden gepatcht
- Keine neuen Features: 5.4 bleibt feature-frozen
- Keine Bug-Fixes: Nur Security-relevante Patches
- Open Source: Updates bleiben öffentlich, keine Premium-Paywall
Wichtig: Extended Support ist keine Ausrede, auf 5.4 zu bleiben. Es ist eine Atempause für geordnete Migrationen ohne Zeitdruck.
Migrations-Strategie für Symfony 5.4 → 7.x
Phase 1: PHP-Version upgraden (2025-2026)
# Aktueller Stand vieler 5.4-Projekte Symfony 5.4.35 PHP 8.1.29 # Ziel Phase 1: PHP 8.3 oder 8.4 Symfony 5.4.x (weiterhin) PHP 8.3.x oder 8.4.x # Vorteil: Performance, Security, ohne Symfony-Breaking-Changes
Symfony 5.4 ist kompatibel mit PHP 8.1-8.4, bald auch 8.5. PHP-Upgrade bringt Performance-Verbesserungen (ca. 5-8% schnellere Response Times bei Symfony-APIs) ohne größere Code-Änderungen.
Zeitaufwand: 6-12 Stunden Testing und Deployment für mittelgroße Symfony-Anwendung (typisch 3.000-5.000€ Wartungsbudget).
Phase 2: Deprecations beseitigen (2026-2027)
# Symfony Deprecations analysieren composer require --dev symfony/phpunit-bridge export SYMFONY_DEPRECATIONS_HELPER=weak vendor/bin/phpunit # Output zeigt alle verwendeten Deprecations # Systematisch durch Code gehen und modernisieren
Symfony 5.4 markiert viele Features als deprecated, die in 6.0 entfernt wurden. Systematisches Refactoring dieser Stellen bereitet smooth Migration vor.
Zeitaufwand: Sehr projektabhängig. Typisch: 20-40 Stunden für mittelgroße Business-Anwendung.
Phase 3: Symfony 6.4 LTS als Zwischenschritt (2027-2028)
# Nicht direkt 5.4 → 7.x springen # Besser: 5.4 → 6.4 LTS → 7.x # Symfony 6.4 bringt: # - Sanftere Breaking Changes # - LTS-Support bis November 2027 (Security bis November 2029) # - Zeit zum Testen vor 7.x
Zeitaufwand: 30-60 Stunden für Symfony 5.4 → 6.4 Migration (mittelgroße App).
Phase 4: Symfony 7.x Final Upgrade (2028-2029)
Mit allen Vorarbeiten sollte 6.4 → 7.x relativ smooth verlaufen. Zeitpunkt wählen, wenn 7.x mature ist (7.2+) und gutes Tooling existiert.
Anti-Pattern: "Wir bleiben auf 5.4 bis 2029"
Extended Support verführt dazu, Migrationen aufzuschieben. Probleme dabei:
- Technische Schulden wachsen: Je länger man wartet, desto größer der Migrations-Gap
- Keine Bug-Fixes: Non-Security-Bugs bleiben ungefixt
- Fehlende Features: Performance-Verbesserungen, neue Symfony-Features bleiben unerreichbar
- Recruiting: Entwickler wollen moderne Technologie, nicht 5-jährigen Legacy-Code
Empfehlung: Extended Support als Puffer nutzen, aber aktiv Richtung 7.x migrieren.
20 Jahre Symfony: Lessons Learned für moderne PHP-Entwicklung
Oktober 2025 markiert 20 Jahre Symfony (2005-2025). Heise berichtet (Quelle) über die Evolution von einem monolithischen MVC-Framework zu 250+ modularen Packages.
Evolution der Architektur
Symfony 1.x (2005-2010): Monolithischer Ansatz
- PHP 5 erforderlich (damals cutting-edge)
- Vollständiges MVC-Framework
- YAML-Config als Innovation
- Doctrine ORM Integration
Symfony 2.x (2011-2016): Component-Revolution
- Kompletter Rewrite
- Standalone Components (HttpFoundation, Console, DependencyInjection)
- Andere Frameworks (Laravel, Drupal) nutzen Symfony-Components
- Composer-Ära beginnt
Symfony 3.x-4.x (2016-2020): Developer Experience
- Flex: Automatisierte Projekt-Setup
- Autowiring: Weniger Config-Boilerplate
- Webpack Encore: Moderne Frontend-Integration
Symfony 5.x-7.x (2020-2025): Modern PHP
- PHP 8 Typed Properties, Attributes
- Performance-Focus (OPCache Preloading)
- API Platform Integration
- Turbo/UX Components für moderne UIs
Was Agenturen von 20 Jahren Symfony lernen können
Lektion 1: Langfristige Stabilität trotz Innovation
Symfony beweist, dass ein Framework gleichzeitig stabil UND innovativ sein kann. LTS-Versionen (5.4, 6.4) bieten Planungssicherheit, während neue Major-Versionen moderne Features bringen. Für Agenturen bedeutet das: Symfony ist eine sichere Technologie-Wahl für langlebige Kundenprojekte.
Lektion 2: Modularität skaliert
Die Component-Architektur erlaubt es, nur benötigte Teile zu nutzen. Shopware 6.6 nutzt Symfony-Components, ohne vollständiges Symfony zu sein. WordPress-Plugins können HttpFoundation nutzen. Diese Flexibilität macht Symfony-Know-how breit anwendbar.
Lektion 3: Community über Unternehmen
Symfony wird von SensioLabs entwickelt, ist aber Community-getrieben. Das Ibexa-Sponsoring für 5.4 Extended Support zeigt: Enterprise-Player investieren in Open Source zurück. Dieses Ökosystem sichert Langlebigkeit.
Symfony vs. Moderne Alternativen
20 Jahre später gibt es viele PHP-Frameworks. Warum Symfony weiterhin relevant ist:
| Framework | Stärken | Symfony-Vorteil |
| Laravel | Developer Experience, Rapid Development | Enterprise-Stabilität, LTS, Modularität |
| Laminas (ex-Zend) | Legacy-Support, Enterprise | Moderne Syntax, aktivere Community |
| Slim/Lumen | Minimalistisch, Microservices | Full-Stack-Features, weniger Boilerplate |
Praxis-Empfehlung: Für deutsche KMU-Projekte im 2-10k€ Range ist Symfony 7.x optimal wenn:
- Langfristige Wartbarkeit wichtig ist (3+ Jahre)
- Team bereits Symfony-Erfahrung hat
- Enterprise-Features benötigt werden (Complex Business Logic, APIs)
Laravel kann besser passen bei:
- Rapid Prototyping
- Team mit Laravel-Background
- CRUD-lastigen Admin-Interfaces
Praktische Migration: PHP 8.5 Testing in Symfony-Projekten
Schritt 1: Lokales Testing-Setup
# Docker-Setup für PHP 8.5 RC Testing
# docker-compose.yml
version: '3.9'
services:
php85:
image: php:8.5-rc-fpm
volumes:
- ./:/var/www
environment:
- SYMFONY_ENV=dev
nginx:
image: nginx:1.27
volumes:
- ./:/var/www
- ./docker/nginx.conf:/etc/nginx/conf.d/default.conf
ports:
- "8085:80"
# Testing-Kommando
docker-compose up -d
docker-compose exec php85 php bin/console about
docker-compose exec php85 vendor/bin/phpunit
Schritt 2: Kompatibilität prüfen
# Composer Platform Requirements Check composer check-platform-reqs # Symfony Requirements Checker symfony check:requirements # Manuelle Deprecation-Analyse export SYMFONY_DEPRECATIONS_HELPER=max[total]=999999 vendor/bin/phpunit --stop-on-error
Schritt 3: Fatal Error Stack Traces testen
// Temporärer Test-Controller für Stack Trace Verification
class DebugController extends AbstractController
{
#[Route('/debug/fatal-error-test', name: 'debug_fatal')]
public function testFatalError(): Response
{
// Nur in Dev-Environment aktivieren!
if ($this->getParameter('kernel.environment') !== 'dev') {
throw new AccessDeniedException();
}
// Trigger Fatal Error
$this->deepNestedCall();
return new Response('Should not reach here');
}
private function deepNestedCall(): void
{
$this->anotherMethod();
}
private function anotherMethod(): void
{
// Fatal Error: Memory exhaustion simulation
$huge = str_repeat('x', PHP_INT_MAX);
}
}
Mit PHP 8.5 sollte der resultierende Fatal Error einen vollständigen Stack Trace zeigen, inklusive aller Methoden-Aufrufe bis zum Controller-Entry-Point.
Performance-Baseline erstellen
# Apache Bench für Response-Time-Messung # PHP 8.4 Baseline ab -n 1000 -c 10 http://localhost:8084/api/products # PHP 8.5 RC Vergleich ab -n 1000 -c 10 http://localhost:8085/api/products # Blackfire für detaillierte Profile blackfire curl http://localhost:8085/api/products
Erwartete Ergebnisse: PHP 8.5 sollte ähnliche oder leicht bessere Performance zeigen wie 8.4. Keine signifikanten Rückschritte.
Best Practices: Technologie-Upgrades in Agenturen
1. Gestaffelte Adoption statt Big Bang
Monat 1-2: RC Testing in Dev-Environment Monat 3: Neues internes Projekt auf PHP 8.5 starten Monat 4-5: Kundenprojekt mit niedrigem Risiko upgraden Monat 6+: Sukzessive weitere Projekte migrieren
Anti-Pattern: Alle Projekte gleichzeitig auf neue PHP-Version upgraden. Risiko: Wenn Problem auftritt, betrifft es alle Projekte.
2. Symfony-LTS als Fundament
Für neue Kundenprojekte (Budget 2-10k€) empfehle ich Stand Oktober 2025:
- Symfony 7.3 als aktuelle stabile Version (erschienen Mai 2025, bereits 5 Monate mature)
- Symfony 6.4 LTS für maximale Stabilität (Support bis November 2029)
- PHP 8.4 (aktuell, Support bis November 2027)
- Doctrine ORM 3.2
- API Platform 3.3 (bei REST-APIs)
Symfony 7.4 LTS erscheint Ende November 2025 und wird ab Dezember die neue Empfehlung für langlebige Kundenprojekte.
3. Automated Testing ist Pflicht
// Minimales Testing-Setup für Symfony-Projekte
// tests/Smoke/BasicHealthTest.php
namespace App\Tests\Smoke;
use Symfony\Bundle\FrameworkBundle\Test\WebTestCase;
class BasicHealthTest extends WebTestCase
{
public function testApplicationBoots(): void
{
$client = static::createClient();
$client->request('GET', '/');
$this->assertResponseIsSuccessful();
}
public function testDatabaseConnection(): void
{
$client = static::createClient();
$em = $client->getContainer()->get('doctrine')->getManager();
$connection = $em->getConnection();
$connection->executeQuery('SELECT 1');
$this->assertTrue($connection->isConnected());
}
}
Selbst diese minimalen Smoke-Tests fangen viele PHP-Upgrade-Probleme ab.
4. Dokumentierte Rollback-Strategie
# Deployment mit Rollback-Möglichkeit # releases/ # 2025-11-15_php84/ # 2025-11-20_php85/ <- Neuer Release # current -> symlink zu aktivem Release # Deploy-Script #!/bin/bash RELEASE_DIR="/var/www/releases/$(date +%Y-%m-%d)_php85" CURRENT_LINK="/var/www/current" # Deploy neuer Release git clone --depth=1 $REPO_URL $RELEASE_DIR cd $RELEASE_DIR composer install --no-dev --optimize-autoloader # Symlink umbiegen ln -sfn $RELEASE_DIR $CURRENT_LINK # Bei Problemen: Rollback # ln -sfn /var/www/releases/2025-11-15_php84 $CURRENT_LINK
Ausblick: PHP und Symfony 2026
Symfony 7.4 LTS (November 2025)
Symfony 7.4 erscheint voraussichtlich Ende November 2025 als neue LTS-Version mit Support bis November 2029. Für neue Projekte wird 7.4 LTS ab Dezember 2025 die empfohlene Version sein.
Symfony 8.0 (November 2026)
Ein Jahr nach 7.4 LTS folgt Symfony 8.0 mit erwarteten Features:
- Vollständige PHP 8.4/8.5 Integration
- Removal aller in 7.x deprecated Features
- Performance-Verbesserungen für Doctrine
- Modernisierte API Platform Integration
PHP 8.6 (November 2026)
Bereits in Diskussion laut PHP Internals:
- Property Hooks (getter/setter ohne Boilerplate)
- Weitere Performance-Optimierungen
- Asymmetric Visibility für Properties
Empfehlung für Agenturen
Fokussiert euch Q4 2025 - 2026 auf:
- PHP 8.4 als Standard für alle neuen Projekte ab sofort
- Symfony 7.4 LTS für neue Kunden-Anwendungen ab Dezember 2025
- Symfony 6.4 LTS weiterhin solid für bestehende Projekte (Support bis 2029)
- Migration-Pläne für 5.4-Legacy nutzt Extended Support sinnvoll
- PHP 8.5 ab Q1 2026 wenn stabil und Dependencies ready
Fazit: Technische Exzellenz durch bewusste Tool-Wahl
Die November 2025-Updates zeigen die Stärke des PHP-Ökosystems:
- PHP 8.5: Fokus auf Developer Experience (Fatal Error Stack Traces) und API-Integration (curl_multi_get_handles)
- Symfony 5.4 Extended Support: Pragmatische Lösung für Legacy-Projekte, ohne Innovation zu bremsen
- 20 Jahre Symfony: Beweis für nachhaltige Open-Source-Entwicklung
Für deutsche Agenturen bedeutet das konkret:
- Mehr Zeit für gründliche Symfony 5.4-Migrationen
- Bessere Debugging-Tools in PHP 8.5
- Bewährte, stabile Technologie für langlebige Kundenprojekte
Die Kombination aus Innovation (PHP 8.5) und Stabilität (Symfony LTS) macht PHP-Development auch 20 Jahre nach Symfony-Start zur soliden Wahl für professionelle Webentwicklung.
Nächste Schritte:
- PHP 8.5 RC in Dev-Umgebung testen (ab sofort)
- Symfony 5.4-Projekte inventarisieren und Migrations-Roadmap erstellen (Q4 2025)
- Neue Projekte mit Symfony 7.4 LTS + PHP 8.4 starten (ab Dezember 2025)
Quellen:
- PHP 8.5 Release Archive: php.net/archive/2025.php
- Symfony 5.4 Extended Support Announcement: symfony.com/blog
- 20 Jahre Symfony bei Heise: heise.de/news
Autor: Dennis Schwenker-Sanders | d-schwenker.de