The Issue:
I am experiencing a total failure of the Symfony WebProfiler after a fresh installation of Symfony 7.4. The issue appears to be a major regression in Twig 3.24.0 that breaks template compilation and variable interpolation within the Profiler Bundle.
Symptoms:
Broken Toolbar: Instead of formatted data, the toolbar displays raw format strings such as
%0fms,%1f MiB, and%00fms.Broken Profiler Dashboard (
/_profiler): Accessing the profiler (e.g.,/_profiler/empty/search/results) is completely KO. It returns incomplete layouts or renders nothing where data should be.Data Loss: Essential collectors like Doctrine (SQL), Security, and Request/Response are no longer accessible.
Template Errors: Logs indicate that Twig fails to resolve dynamic sub-templates. Specifically, the filter
|formatseems to fail, leaving strings like_%s_summary.html.twigunpopulated.
Environment:
Symfony: 7.4.x
Twig: 3.24.0 (latest)
PHP: 8.3 (Dockerized environment)
Server: Apache
What I've already tested (without success):
Permissions: Full
chown -R www-data:www-dataandchmod -R 775onvar/andpublic/.Cache: Multiple manual purges (
rm -rf var/cache/*) andbin/console cache:clear.Assets: Re-installing assets via
assets:install.Attempted Downgrade: Tried forcing
twig/twig:3.23.1, but it creates a dependency conflict with Symfony 7.4 components which are locked to^3.21and default to the latest buggy version.
Visual Evidence:
- Toolbar

- Profiler detail page

Technical Analysis:
It seems that Twig 3.24.0 introduced a change in how the |format filter or macros are handled.
Since the WebProfiler relies heavily on dynamic template naming (e.g., '@WebProfiler/Profiler/_%s_summary.html.twig'|format(profile_type)), the engine now fails to locate these files, causing a domino effect that breaks the entire debugging suite.
Questions:
Is there a recommended way to alias the Twig version to bypass this 3.24.0 regression without breaking Symfony 7.4 dependencies?
Is this a known issue being tracked for a 3.24.1 patch?
Are there temporary configuration workarounds (other than disabling
APP_DEBUG) to restore SQL logging visibility?
Regards