[WebProfilerBundle] `/_wdt/styles.css` is not found #59045

alexislefebvre · 2024-11-29T16:19:00Z

Symfony version(s) affected

7.2.0

Description

When I browse my local website, the debug toolbar is displayed without any style:

Loading http://localhost:8000/_wdt/styles.css in the browser shows:

The requested resource /_wdt/styles.css was not found on this server.

For some reason, it is passed to the PHP built-in server:

How to reproduce

The PHP server runs in Docker through php -S 0.0.0.0:8000 -t public/.

It looks like it's not the source of the problem since http://localhost:8000/_wdt/50aa18?XDEBUG_IGNORE=1 works without any issue.

Possible Solution

See this workaround to change the path of the path in your project: #59045 (comment)

Additional Context

The debug toolbar has no issues:

Router

config/routes/web_profiler.yaml

when@dev:
    web_profiler_wdt:
        resource: '@WebProfilerBundle/Resources/config/routing/wdt.xml'
        prefix: /_wdt

    web_profiler_profiler:
        resource: '@WebProfilerBundle/Resources/config/routing/profiler.xml'
        prefix: /_profiler

debug:router:

$ bin/console debug:router _wdt_stylesheet
+--------------+--------------------------------------------------------------------------+
| Property     | Value                                                                    |
+--------------+--------------------------------------------------------------------------+
| Route Name   | _wdt_stylesheet                                                          |
| Path         | /_wdt/styles.css                                                         |
| Path Regex   | {^/_wdt/styles\.css$}sDu                                                 |
| Host         | ANY                                                                      |
| Host Regex   |                                                                          |
| Scheme       | ANY                                                                      |
| Method       | ANY                                                                      |
| Requirements | NO CUSTOM                                                                |
| Class        | Symfony\Component\Routing\Route                                          |
| Defaults     | _controller: web_profiler.controller.profiler::toolbarStylesheetAction() |
| Options      | compiler_class: Symfony\Component\Routing\RouteCompiler                  |
|              | utf8: true                                                               |
+--------------+--------------------------------------------------------------------------+

$ bin/console debug:router _wdt
+--------------+----------------------------------------------------------------+
| Property     | Value                                                          |
+--------------+----------------------------------------------------------------+
| Route Name   | _wdt                                                           |
| Path         | /_wdt/{token}                                                  |
| Path Regex   | {^/_wdt/(?P<token>[^/]++)$}sDu                                 |
| Host         | ANY                                                            |
| Host Regex   |                                                                |
| Scheme       | ANY                                                            |
| Method       | ANY                                                            |
| Requirements | NO CUSTOM                                                      |
| Class        | Symfony\Component\Routing\Route                                |
| Defaults     | _controller: web_profiler.controller.profiler::toolbarAction() |
| Options      | compiler_class: Symfony\Component\Routing\RouteCompiler        |
|              | utf8: true                                                     |
+--------------+----------------------------------------------------------------+

[WebProfilerBundle] Render the toolbar stylesheet #58287

The text was updated successfully, but these errors were encountered:

alexislefebvre · 2024-11-29T16:24:34Z

On this line:

symfony/src/Symfony/Bundle/WebProfilerBundle/Resources/config/routing/wdt.xml

Line 7 in 4ed9d03

Replacing /styles.css with /styles fixes the issue: the CSS is rendered when calling /_wdt/styles.

So it looks like it's a limitation of the built-in server of PHP. My hypothesis: it tries to find the file /_wdt/styles.css when this path is provided, but call Symfony when the path is changed to /_wdt/styles.

alexislefebvre · 2024-11-29T16:33:00Z

Possible (ugly) workaround: add this in your template:

        {% if 'dev' == app.request.server.get('APP_ENV') %}
            <style>
                {{ include('@WebProfiler/Profiler/toolbar.css.twig') }}
            </style>
        {% endif %}

alexislefebvre · 2024-11-29T16:33:38Z

It looks like it's an edge case, let's see if someone else has the same issue.

lugosium · 2024-12-01T17:44:38Z

Got this issue too

alexislefebvre · 2024-12-01T18:08:47Z

Got this issue too

Here is a workaround by using the old version to override the new version:

create the templates/bundles/WebProfilerBundle/Profiler/ directory
copy-paste the old version of the Twig file in the toolbar_js.html.twig file in this new directory

Through CLI:

mkdir --parents templates/bundles/WebProfilerBundle/Profiler/
curl https://raw.githubusercontent.com/symfony/symfony/31b6a568850ad260b9d20122667a84ce0665ba7a/src/Symfony/Bundle/WebProfilerBundle/Resources/views/Profiler/toolbar_js.html.twig \
--output templates/bundles/WebProfilerBundle/Profiler/toolbar_js.html.twig

This will revert this change and inline the CSS instead of loading it through an URL.

alexislefebvre · 2024-12-01T18:11:17Z

It would be nice to be able to use the "old" way with a parameter of WebProfilerBundle.

alexislefebvre · 2024-12-02T13:44:18Z

Got this issue too

What server do you use? The built-in PHP server too?

alexislefebvre · 2024-12-02T14:04:04Z

Another workaround: use Symfony CLI to run the server: https://symfony.com/download

In the context of PHP in a Docker container, based on an Alpine image:

Install it:

+ RUN apk add --no-cache bash
+ RUN wget https://get.symfony.com/cli/installer -O - | bash
+ RUN mv -v /root/.symfony5/bin/symfony /usr/local/bin/symfony

Start the server by replacing the entrypoint of Docker:

- entrypoint: php -S 0.0.0.0:8000 -t public/
+ entrypoint: symfony local:server:start --port=8000 --allow-all-ip --no-tls

Build and restart the Docker container
It works!

lugosium · 2024-12-02T14:10:15Z

Got this issue too

What server do you use? The built-in PHP server too?

I'm behind docker/nginx.

Thanks for your help 👍

lugosium · 2024-12-02T14:29:46Z

Issue is (for me) in the nginx vhost:

    location ~* \.(jpg|jpeg|png|webp|gif|ico|css|js|woff|woff2|ttf)$ {
       expires 1d;
    }

If I remove css in the regex it's ok.
But i don't really want to remove that...

alexislefebvre · 2024-12-02T14:31:23Z

Actual solution with PHP's built-in server:

- php -S 0.0.0.0:8000 -t public/
+ php -S 0.0.0.0:8000 public/index.php

~~The last parameter is the router, it will serve the file through Symfony.~~

-t public/ (the docroot) has to be removed, public/index.php will be used as a router, and the CSS file for WebProfilerBundle will be served by Symfony.

rpkamp · 2024-12-02T14:48:40Z

Same issue here, behind NGiNX + PHP-FPM. I get a 404 on /_wdt/styles.css.

Probably caused by

location ~* \.(?:css|js|jpg|jpeg|gif|png|ico|svg|ttf|otf|woff|woff2|eot)$ {
    expires 1y;
    add_header Cache-Control "public, immutable";
}

telling NGiNX all css files should be served by it, and it will not try PHP to serve it.

alexislefebvre · 2024-12-02T14:49:15Z

It works as expected now.

@lugosium I didn’t get if you use PHP’s built-in server or something else (like php-fpm or apache).

If you use the built-in server, please try the solution on the comment above.

Otherwise, please open another issue since it may be related to nginx.

rpkamp · 2024-12-02T14:53:24Z

Adding this to my NGiNX config seems to solve it, though I don't really like having to configure something explicitly for a dev tool.

location ^~ /_wdt {
    try_files $uri /index.php?$query_string;
}

rpkamp · 2024-12-02T15:03:21Z

Chaning /styles.css to /styles would also fix the issue, as suggested here

lugosium · 2024-12-02T15:17:25Z

Chaning /styles.css to /styles would also fix the issue, as suggested here

+1 here, suffix .css not needed as we can rely on the 'Content-Type' => 'text/css' header and it's not a file anymore.

alexislefebvre · 2024-12-02T17:55:00Z

I reopen this issue so that Symfony's maintainers can study this case.

andrewbrereton · 2024-12-04T00:36:23Z

Adding this to my NGiNX config seems to solve it, though I don't really like having to configure something explicitly for a dev tool.
location ^~ /_wdt {
    try_files $uri /index.php?$query_string;
}

This worked for me.

Running nginx php-fpm inside Docker.

Jean-Gian · 2024-12-04T11:21:37Z

I got this issue too, with apache

PhilETaylor · 2024-12-05T20:35:20Z

Are you all "behind" a proxy and not set trusted_proxies? I think I had this issue yesterday

lugosium · 2024-12-05T20:44:11Z

No proxy for me.

mustanggb · 2024-12-06T12:17:55Z

I encountered this upgrading from 7.1.9 to 7.2.0, the fix from rpkamp worked nicely.

alexislefebvre · 2024-12-06T17:46:00Z

Another workaround:

On this line:

symfony/src/Symfony/Bundle/WebProfilerBundle/Resources/config/routing/wdt.xml

Line 7 in 4ed9d03

<route id="_wdt_stylesheet" path="/styles.css">

Replacing /styles.css with /styles fixes the issue: the CSS is rendered when calling /_wdt/styles.

I was able to do this in a project, by changing the config instead of the file in vendor/:

config/routes/web_profiler.yaml

    when@dev:
        web_profiler_wdt:
            resource: '@WebProfilerBundle/Resources/config/routing/wdt.xml'
            prefix: /_wdt
    
        web_profiler_profiler:
            resource: '@WebProfilerBundle/Resources/config/routing/profiler.xml'
            prefix: /_profiler
    
+       _wdt_stylesheet:
+           path: /custom_wdt/styles
+           controller: web_profiler.controller.profiler::toolbarStylesheetAction

It may require to delete the cache.

THenkeDE · 2024-12-10T17:49:27Z

same problem with local WAMP Environment on Win11 with standard Apache (no nGinx).

Test-Updated from working 7.1.* to 7.3.*, nothing else changed.

Power2All · 2024-12-11T09:55:00Z

I had the same issue when updating 7.1 to 7.2
#59045 (comment) fixed the issue after clearing the cache, development running purely in PHP 8.3 (using built-in web server), and with Apache as well. Should also work fine in NGINX.

Jean-Gian · 2024-12-11T10:01:57Z

Solution by @alexislefebvre works perfectly for me

Another workaround:

On this line:

symfony/src/Symfony/Bundle/WebProfilerBundle/Resources/config/routing/wdt.xml

Line 7 in 4ed9d03

<route id="_wdt_stylesheet" path="/styles.css">

Replacing /styles.css with /styles fixes the issue: the CSS is rendered when calling /_wdt/styles.

I was able to do this in a project:

config/routes/web_profiler.yaml
    when@dev:
        web_profiler_wdt:
            resource: '@WebProfilerBundle/Resources/config/routing/wdt.xml'
            prefix: /_wdt
    
        web_profiler_profiler:
            resource: '@WebProfilerBundle/Resources/config/routing/profiler.xml'
            prefix: /_profiler
    
+       _wdt_stylesheet:
+           path: /custom_wdt/styles
+           controller: web_profiler.controller.profiler::toolbarStylesheetAction
It may require to delete the cache.

Power2All · 2024-12-11T10:06:18Z

Solution by @alexislefebvre works perfectly for me
Another workaround:

On this line:

symfony/src/Symfony/Bundle/WebProfilerBundle/Resources/config/routing/wdt.xml

Line 7 in 4ed9d03

<route id="_wdt_stylesheet" path="/styles.css">

Replacing /styles.css with /styles fixes the issue: the CSS is rendered when calling /_wdt/styles.

I was able to do this in a project:
config/routes/web_profiler.yaml
    when@dev:
        web_profiler_wdt:
            resource: '@WebProfilerBundle/Resources/config/routing/wdt.xml'
            prefix: /_wdt
    
        web_profiler_profiler:
            resource: '@WebProfilerBundle/Resources/config/routing/profiler.xml'
            prefix: /_profiler
    
+       _wdt_stylesheet:
+           path: /custom_wdt/styles
+           controller: web_profiler.controller.profiler::toolbarStylesheetAction
It may require to delete the cache.

I didn't need to do any of that, only the wdt.xml file was enough, and clearing cache.
Can you try it without that part ?

alexislefebvre · 2024-12-11T13:08:35Z

I didn't need to do any of that, only the wdt.xml file was enough, and clearing cache.
Can you try it without that part ?

The wdt.xml is in the vendor/ directory so it only works on one install and can't be deployed as is.

Jean-Gian · 2024-12-11T14:25:31Z

The solution that @alexislefebvre suggested is stable and clean, is agnostic to the webserver and doesn't rely on editing vendor files

Power2All · 2024-12-11T15:03:01Z

The solution that @alexislefebvre suggested is stable and clean, is agnostic to the webserver and doesn't rely on editing vendor files

I was under the impression both the xml and the routing file needed to be changed.
Read it wrong, thanks for clarifying.

smnandre · 2024-12-17T00:28:15Z

Question for people having trouble with this page... is the exception panel stylesheet working ? (it uses the same code as far as i know)

/_profiler/123456/exception.css

(with a profiler token instead of 123456)

alexislefebvre · 2024-12-17T01:48:59Z

Question for people having trouble with this page... is the exception panel stylesheet working ? (it uses the same code as far as i know)

/_profiler/123456/exception.css

(with a profiler token instead of 123456)

I'm not sure if that correspond to your question but the profiler and the exception pages are displayed without and with issues:

CSS is inlined on this page, it has no display issues:

CSS is broken on an exception page:

smnandre · 2024-12-17T03:07:32Z

CSS is inlined on this page, it has no display issues:

My PR had a bad impact on you people and i'm sorry. Sincerely.

I'm trying to get all information i can, to find a good solution for everyone (for now: your suggestion to remove ".css" seems the best)

I'm not sure if that correspond to your question but the pro

On your first screenshot, we see the profiler token was 970bae (the 6 digits in the URL)

Can you try accessing to https://localhost:8000/_profiler/970bae/exception.css

Thanks

alexislefebvre · 2024-12-18T01:02:16Z

On your first screenshot, we see the profiler token was 970bae (the 6 digits in the URL)

Can you try accessing to https://localhost:8000/_profiler/970bae/exception.css

Thanks

Here is the result:

What page load this CSS file? I never saw an issue with …/exception.css.

markuskuerten · 2025-01-04T23:20:52Z

I encountered a similar problem after updating from 7.1 to 7.2.

On my site, the Symfony Toolbar initially appears without a stylesheet and only after a short delay does it display correctly with the stylesheet applied.

For me, the only solution that worked was the workaround proposed by alexislefebvre "using the old version to override the new version."

#59045 (comment)

Here are some details about my environment:

Web server: nginx 1.24.0 (Ubuntu)
PHP version: php8.3-fpm
Proxy: None

I’d appreciate any guidance or a permanent fix for this issue.

alexislefebvre · 2025-01-04T23:49:00Z

I’d appreciate any guidance or a permanent fix for this issue.

This one is permanent: #59045 (comment)

Delete the cache with rm -rf var/cache/* if it doesn't work.

markuskuerten · 2025-01-05T11:18:57Z

This one is permanent: #59045 (comment)

Delete the cache with rm -rf var/cache/* if it doesn't work.

Thank you for your response and the suggestion! Unfortunately, clearing the cache with rm -rf var/cache/* doesn't resolve the issue in my case. I’ve already tried this approach several times, but the problem persists.

For now, the only solution that reliably works for me is the workaround I mentioned earlier (overriding the new version with the old one).

smnandre · 2025-01-06T00:15:24Z

There is a PR opened that fixes this problem. Just have to wait for it to be merged.

#59229

…xislefebvre) This PR was merged into the 7.2 branch. Discussion ---------- [WebProfilerBundle] fix loading of toolbar stylesheet | Q | A | ------------- | --- | Branch? | 7.2 | Bug fix? | yes | New feature? | no | Deprecations? | no | Issues | Fix #59045 | License | MIT It looks like this PR - #58287 Caused issues with some configurations: - #59045 According to the thumb-up emoji on [this comment](#59045 (comment)) (I don’t have a better measurement of the impact), it affected at least 10 users, with various web servers. Proposals: 1. do not use the `.css` file extension so that servers do not try to serve an actual file 2. if we consider that the disappearance of the style of the profiler’s toolbar is a breaking change, the `.css` file extension could be added back with Symfony 8.0, with a note to help people upgrade (see the workarounds in the issue) Commits ------- 7fef930 fix: loading of WebProfilerBundle’s toolbar stylesheet

alexislefebvre added the Bug label Nov 29, 2024

carsonbot added Status: Needs Review WebProfilerBundle labels Nov 29, 2024

alexislefebvre closed this as completed Nov 29, 2024

alexislefebvre reopened this Dec 1, 2024

alexislefebvre mentioned this issue Dec 2, 2024

[WebProfilerBundle] Render the toolbar stylesheet #58287

Merged

alexislefebvre closed this as completed Dec 2, 2024

alexislefebvre reopened this Dec 2, 2024

mmarchois mentioned this issue Dec 12, 2024

🚀 Symfony 7.2 MTES-MCT/dialog#1091

Merged

alexislefebvre mentioned this issue Dec 16, 2024

[WebProfilerBundle] fix loading of toolbar stylesheet #59229

Merged

fabpot closed this as completed Jan 6, 2025

[WebProfilerBundle] /_wdt/styles.css is not found #59045

[WebProfilerBundle] /_wdt/styles.css is not found #59045

Comments

alexislefebvre commented Nov 29, 2024 • edited Loading

Symfony version(s) affected

Description

How to reproduce

Possible Solution

Additional Context

Router

alexislefebvre commented Nov 29, 2024 • edited Loading

alexislefebvre commented Nov 29, 2024

alexislefebvre commented Nov 29, 2024

lugosium commented Dec 1, 2024

alexislefebvre commented Dec 1, 2024 • edited Loading

alexislefebvre commented Dec 1, 2024 • edited Loading

alexislefebvre commented Dec 2, 2024

alexislefebvre commented Dec 2, 2024

lugosium commented Dec 2, 2024

lugosium commented Dec 2, 2024

alexislefebvre commented Dec 2, 2024 • edited Loading

Actual solution with PHP's built-in server:

rpkamp commented Dec 2, 2024

alexislefebvre commented Dec 2, 2024

rpkamp commented Dec 2, 2024

rpkamp commented Dec 2, 2024

lugosium commented Dec 2, 2024

alexislefebvre commented Dec 2, 2024

andrewbrereton commented Dec 4, 2024

Jean-Gian commented Dec 4, 2024

PhilETaylor commented Dec 5, 2024

lugosium commented Dec 5, 2024

mustanggb commented Dec 6, 2024

alexislefebvre commented Dec 6, 2024 • edited Loading

THenkeDE commented Dec 10, 2024

Power2All commented Dec 11, 2024 • edited Loading

Jean-Gian commented Dec 11, 2024

Power2All commented Dec 11, 2024

alexislefebvre commented Dec 11, 2024

Jean-Gian commented Dec 11, 2024

Power2All commented Dec 11, 2024

smnandre commented Dec 17, 2024

alexislefebvre commented Dec 17, 2024 • edited Loading

smnandre commented Dec 17, 2024

alexislefebvre commented Dec 18, 2024 • edited Loading

markuskuerten commented Jan 4, 2025 • edited Loading

alexislefebvre commented Jan 4, 2025

markuskuerten commented Jan 5, 2025

smnandre commented Jan 6, 2025

[WebProfilerBundle] `/_wdt/styles.css` is not found #59045

[WebProfilerBundle] `/_wdt/styles.css` is not found #59045

alexislefebvre commented Nov 29, 2024 •

edited

Loading

alexislefebvre commented Nov 29, 2024 •

edited

Loading

alexislefebvre commented Dec 1, 2024 •

edited

Loading

alexislefebvre commented Dec 1, 2024 •

edited

Loading

alexislefebvre commented Dec 2, 2024 •

edited

Loading

alexislefebvre commented Dec 6, 2024 •

edited

Loading

Power2All commented Dec 11, 2024 •

edited

Loading

alexislefebvre commented Dec 17, 2024 •

edited

Loading

alexislefebvre commented Dec 18, 2024 •

edited

Loading

markuskuerten commented Jan 4, 2025 •

edited

Loading