CssRewrite goes through app_dev.php in Symfony

[beberlei]

Using symfony2 and a cssrewrite to fix all @import they now go through app_dev.php/path/to/import/file.css which leads to 404 errors from the symfony kernel.

[alex88]

It depends when the 1.1 version comes out, but I don't think that early :)

[MPLLC]

It's frustrating that there's no fix for this, especially since using the bundle name is what's used all throughout the official Symfony documentation! Ridiculous.

[gremo]

@KevinM1 totally agree. We need a fix... soon.

[alex88]

So 1.1 is nearly out, but no fix for this yet? C'mon guys!

[ghost]

@kriswallsmith : is this gonna be scheduled for 1.2?

[kriswallsmith]

I'm AFK. Do we have a failing test case yet?

On Thursday, June 13, 2013 at 10:26 PM, Johnny Robeson wrote:

@kriswallsmith (https://github.com/kriswallsmith) : is this gonna be scheduled for 1.2?

— Reply to this email directly or view it on GitHub (https://github.com/kriswallsmith/assetic/issues/53#issuecomment-19439897).

[alex88]

I think that there should be a filter that creates new assets on each url() it finds inside css and so, so it gets managed by assetic and dumped/referenced together with the others

[kitingChris]

This issue is now open for 3 years.... How about finally fixing this? For my project due to serving static files not on the same server I need a fix for this problem... I need to use the @bundles notation projectwide.

[ghost]

+1 ; any updates?

[cassianotartari]

Looking for a solution too. I'm trying to work with AWS - EC2 and S3 for assets without success

[ghost]

+1 Please fix this soon! This is extremely hindering any sort of streamlined development!

[smilesrg]

+1 for this fix. But everyone can use FkrCssURLRewriteBundle for fixing this issue

[ghost]

We need an official solution which we could put into the official symfony2 documentation!

[rimouesleti]

Same problem here with Symfony 2.6

[n1c01a5]

Same problem.

[clubdesarrolladores]

+1 same problem, please fix this soon

[ghost]

I think there will be never a fix for this. The Best Practice currently is to use css files in the web directory (I prefer web/css or web/bundles/app/css).

See this warning in the Symfony2 Book: http://symfony.com/doc/current/cookbook/assetic/asset_management.html#including-css-stylesheets

You should do:

    {% stylesheets 'bundles/app/css/*' filter='cssrewrite' %}

You should NOT do:

    {% stylesheets '@AppBundle/Resources/public/css/*' filter='cssrewrite' %}

[drAlberT]

I can't see any "best practice" sentence on the doc .. simply it makes us aware of the issue

+1 for taking this issue on a solution

[ghost]

Here is the Best Practice to store the css files in the web directory: http://symfony.com/doc/current/best_practices/web-assets.html

[drAlberT]

@JHGitty yep I see, but this is a bp for application .. if I have a bundle to redistribute or reuse I need to have my assets bundled together with the code who uses them

So I agree to avoid misuse of bundled-assets, but they are a tool that has its own field of application and can't be ignored or labeled as "poor practice" always IMHO

However, I think assets should be treated all the same way ... so there should be no difference in the use of css, js or images .. I agree to use {% stylesheets 'bundles/app/css/*' filter='cssrewrite' %}, but we should do the same with JS and images then :)

[stphane]

app_dev is driving me crazy with a web/fonts/... issue ! Giving this stylesheet snippet:

            {% stylesheets
                filter="node_scss,uglifycss"
                output="dist/main.css"
                '../app/Resources/public/scss/main.scss'
            %}
                <link rel="stylesheet" href="{{ asset_url }}">
            {% endstylesheets %}

The resulting css "/app_dev.php/dist/main_main_1.css" file points to some bootstrap glyphicons fonts referenced with "/fonts/bootstrap/glyphi..." okey so I copied this fonts directory to /web.

I then expected the browser to search for those files inside "/app_dev.php/fonts/bootstrap/glyph…", this is what is done but a 404 is served instead by the dev controller :angry: ! If I hit the url directly from vhost root "/fonts/bootstrap/glyph…", the file is correctly served by NGINX.

Is there a way to make app_dev resolve the /fonts path nicely (I mean in a clean way) ? Could someone please help me handling this ? Thank you !

[ReneMuetti]

This is a design bug. Since you do not work through a config switch, but with different scripts that is an unavoidable consequence.

I had the same problem. The support was unfortunately no help. Also sont there are no viable solutions. I therefore once assembled a "solution": the page-template (base.html.twig)

<!DOCTYPE html>
<!--[if lt IE 7 ]><html class="ie ie6" lang="de"> <![endif]-->
<!--[if IE 7 ]><html class="ie ie7" lang="de"> <![endif]-->
<!--[if IE 8 ]><html class="ie ie8" lang="de"> <![endif]-->
<!--[if (gte IE 9)|!(IE)]><!--><html lang="de"> <!--<![endif]-->
    <head>
        <meta charset="UTF-8" />
        <meta name="viewport" content="width=device-width, initial-scale=1, maximum-scale=1">
        {{ include('AppBundle:default:scss.html.twig') }}
....

then the CSS file (scss.html.twig)

{% if app.environment == 'dev' %}
    {% stylesheets filter="scssphp" output="css/app_dev.css" debug=true
        "assets/scss/global-dev.scss"
        "assets/css/*.css"
    %}
    <link rel="stylesheet" type="text/css" href="{{ asset_url }}" media="screen">
    {% endstylesheets %}
{% else %}
    {% stylesheets filter="scssphp" output="css/app_prod.css" debug=true
        "assets/scss/global-prod.scss"
        "assets/css/*.css"
    %}
    <link rel="stylesheet" type="text/css" href="{{ asset_url }}" media="screen">
    {% endstylesheets %}
{% endif %}

then generate 2 different scss: one contains the paths for productive operation ( '../fonts/' ) and the other, the paths for the DEV mode ( '../../fonts/' ).

Another solution I have not found. The Simple tile cause must be resolved by the development team. Both app*.php together are placed and the DEV mode must be regulated through a config option.

[stphane]

@ReneMuetti Thank you very much for sharing ! In the meantime, I ended up turning use_controller switch to false inside the configuration file and I now use assetic's watcher in dev environment. I didn't think of wrapping Assetic tags between conditions since Assetic does not interpret twig files but only parses them in order to process stylesteets and javascripts tags. Actually it does make sense ! I will definitely concider your «solution» for futur projects.