Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

CssRewrite goes through app_dev.php in Symfony #53

Open
beberlei opened this Issue May 16, 2011 · 73 comments

Comments

Projects
None yet
@beberlei
Copy link

beberlei commented May 16, 2011

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.

@kriswallsmith

This comment has been minimized.

Copy link
Owner

kriswallsmith commented May 16, 2011

Can you provide more details about how you're using Assetic and what you expect it to do?

Also, can you debug to see if the target path in the CssRewriteFilter includes _controller/?

@beberlei

This comment has been minimized.

Copy link
Author

beberlei commented May 17, 2011

I am using the following twig commands:

{% stylesheets 'bundles/hwsplatform/lsl/css/layout_3col_fixed.css'
               'bundles/hwsplatform/lsl/css/stylesheet_168fd464f0.css'
               'bundles/hwsplatform/lsl/css/fix_glossary_definitions.css'
               'bundles/hwsplatform/lsl/css/lsl.css'
               'bundles/hwsplatform/aristo/jquery-ui-1.8.7.custom.css'
               output='css' filter='cssrewrite'
               %}
    <link href="{{ asset_url }}" type="text/css" rel="stylesheet" />
{% endstylesheets %}

In dev mode this becomes (and so on):

<link href="/eberlei/wsnetbeans/lsl-ff-db/trunk/web/app_dev.php/css_layout_3col_fixed_1.css" type="text/css" rel="stylesheet" />

Now this first stylesheet uses @import that now are linked to:

http://devel/eberlei/wsnetbeans/lsl-ff-db/trunk/web/app_dev.php/bundles/hwsplatform/lsl/css/main/base.css

Assetic config is:

assetic:
    debug:          %kernel.debug%
    use_controller: false
    filters:
        cssrewrite: ~

In CssRewriteFilter the following $targetPath is passed for the stylesheet with the @import

css_layout_3col_fixed_1.css

$sourcePath is: bundles/hwsplatform/lsl/css/layout_3col_fixed.css

@beberlei

This comment has been minimized.

Copy link
Author

beberlei commented May 17, 2011

Ok, same happens for image rewrites of course. Which 404s them aswell.

@kriswallsmith

This comment has been minimized.

Copy link
Owner

kriswallsmith commented May 18, 2011

I just noticed you're misusing the output attribute in the Twig tag. Early on, css was expanded to css/*.css but I've since removed that. You should set that to the asset's target path, i.e. css/packed/main.css.

@kriswallsmith

This comment has been minimized.

Copy link
Owner

kriswallsmith commented Jun 30, 2011

Did you see my note about the output attribute? Does fixing that make any difference?

@DTown

This comment has been minimized.

Copy link

DTown commented Jul 11, 2011

Hi Kris,
I have the problem that the cssrewrite doesn't seem to work out well if I use the @..Bundle notation like
{% stylesheets '@BattlFrontendBundle/Resources/public/css/basic.css' ...
then he produces something like this
"../../Resources/bundles/battlfrontend/images/layout/nav_line.png"
in the original css file its this "url(../images/layout/search.png)"
I'm not using the output attribute here.

If I use this notation
{% stylesheets 'bundles/battlfrontend/css/basic.css' ...
it's working for the dev mode, but not for the normal mode.
../../bundles/battlfrontend/images/layout/nav_line.png
This path is generated for both.

Config settings for assetics are the same for dev&normal:

assetic:
debug: %kernel.debug%
use_controller: false
filters:
yui_css:
jar: "%kernel.root_dir%/Resources/java/yuicompressor-2.4.6.jar"
yui_js:
jar: "%kernel.root_dir%/Resources/java/yuicompressor-2.4.6.jar"
cssrewrite: ~

@kriswallsmith

This comment has been minimized.

Copy link
Owner

kriswallsmith commented Jul 11, 2011

This is a known limitation of the Symfony integration that will be addressed in Assetic 1.1 when we add support for asset dependencies. The easiest solution is to keep everything in one load path, i.e. all CSS files in web/. You can also keep these assets in your bundle’s Resources/public/ directory and install them to web/ using the assets:install command. Either way, avoid using the @MyBundle notation to include stylesheets that reference images when defining your Assetic assets.

On Monday, July 11, 2011 at 10:11 AM, DTown wrote:

Hi Kris,
I have the problem that the cssrewrite doesn't seem to work out well if I use the @..Bundle notation like
{% stylesheets '@BattlFrontendBundle/Resources/public/css/basic.css' ...
then he produces something like this
"../../Resources/bundles/battlfrontend/images/layout/nav_line.png"
in the original css file its this "url(../images/layout/search.png)"
I'm not using the output attribute here.

If I use this notation
{% stylesheets 'bundles/battlfrontend/css/basic.css' ...
it's working for the dev mode, but not for the normal mode.
../../bundles/battlfrontend/images/layout/nav_line.png
This path is generated for both.

Config settings for assetics are the same for dev&normal:

assetic:
debug: %kernel.debug%
use_controller: false
filters:
yui_css:
jar: "%kernel.root_dir%/Resources/java/yuicompressor-2.4.6.jar"
yui_js:
jar: "%kernel.root_dir%/Resources/java/yuicompressor-2.4.6.jar"
cssrewrite: ~

Reply to this email directly or view it on GitHub:
#53 (comment)

@lmammino

This comment has been minimized.

Copy link

lmammino commented Aug 17, 2011

@kriswallsmith can you provide a simple example that shows ho to handle the assest in one load path?

@pierre-b

This comment has been minimized.

Copy link

pierre-b commented Oct 25, 2011

@Imammino:

Here is the example of the Kriswallsmith comment:

My bundle is nammed LbpCoreBundle. My assets are in Lbp\CoreBundle\Resources\public

Everytime I change something I do a "assets:install web" command.

This is in the twig layout:
{% stylesheets 'bundles/lbpcore/css/*' filter='cssrewrite' %}{% endstylesheets %}

And in my css looks like :
background:url(../images/corner.png) etc...

It works for me.

@lmammino

This comment has been minimized.

Copy link

lmammino commented Oct 26, 2011

Yes, i ended up with the same solution after a while!
Anyway, Thanks a lot @pierre-b

@ardianys

This comment has been minimized.

Copy link

ardianys commented Oct 27, 2011

You can using this command to avoid hard copy,
so you don't have to run assets:install web command everytime you make some changes in your asset

php app/console assets:install --symlink web
@lmammino

This comment has been minimized.

Copy link

lmammino commented Oct 27, 2011

@ardianys beware that every time you update your bundles with php bin/vendors update it will remove all your symlinks and replaces them with a raw copy of your bundles web folder. So you have to tear down the raw copies and run php app/console assets:install --symlink web again...

@ardianys

This comment has been minimized.

Copy link

ardianys commented Oct 28, 2011

Thanks for your info. I didn't know detailed behaviour of this command.

Regards.

@lmammino

This comment has been minimized.

Copy link

lmammino commented Oct 29, 2011

@ardianys, never mind ;)
Have a nice weekend!

@diegosainz

This comment has been minimized.

Copy link

diegosainz commented Nov 19, 2011

Hi all,

We have the same problem and solve it the same way as suggested here (reference the files on web/bundles, installing the assets and then compiling). But it is very uncomfortable when you are working on resources (or you have the option to work directly on the published web/bundles resources with the --watch assetic option, but then if you forget to copy your changes to Bundle/Resources you may overwrite them) so I put together a command that automatically listens for any changes on every Bundle/Resources, updates the asset in web/bundles and dumps the assetic file:

https://gist.github.com/1378305

To use it install the command in any bundle you want and run

console tracpoint:assets --watch

Regards,

Diego
sperantus.com

@stof

This comment has been minimized.

Copy link
Collaborator

stof commented Nov 19, 2011

@diegosainz The assets:install command has a --symlink option doing a symlink instead of a copy for the assets

@diegosainz

This comment has been minimized.

Copy link

diegosainz commented Nov 20, 2011

@stof:Yes, that's a better solution, unfortunately for us we are developing on windows and symlink option is not supported :(

@mvrhov

This comment has been minimized.

Copy link

mvrhov commented Nov 20, 2011

AFAIK windows Vista + supports hardlinks... and afair PHP too.

@stof

This comment has been minimized.

Copy link
Collaborator

stof commented Nov 20, 2011

@diegosainz On windows, you need to run the script as administrator or to disable some of the checks (on 7 only as Vista does not allow disabling them) to be able to use the --symlink option.

@diegosainz

This comment has been minimized.

Copy link

diegosainz commented Nov 21, 2011

@stof I wasnt aware of that, Thank you!

@alexismo

This comment has been minimized.

Copy link

alexismo commented Dec 1, 2011

So when I use the relative path for CSS images (../images/[...]), the CSS gets rewritten, as it should.
(../../Resources/public/images/[...])
But the images don't show up.

When I use the full path (/bundles/planbgofone/images/[...]), the CSS does not get rewritten but the images show.

Does this have something to do with the "dev" environment versus prod?

@stof

This comment has been minimized.

Copy link
Collaborator

stof commented Dec 1, 2011

the CssRewrite filter does not work when using the @MyBundle syntax in AsseticBundle to reference the assets. This is a known limitation.

@mrtorrent

This comment has been minimized.

Copy link

mrtorrent commented Dec 5, 2011

@stof is there a bug report for this in AsseticBundle? I can't seem to find it

@tcz

This comment has been minimized.

Copy link

tcz commented Dec 19, 2011

Woah, this looks a little bit too complex. Is there any proposal for fixing this?

@talpan

This comment has been minimized.

Copy link

talpan commented Jan 19, 2012

what's the progress on this, is there any eta?
I would really like a real solution, this stuff is just annoying :/.

Of course, very thankful for your support.

@Abhoryo

This comment has been minimized.

Copy link

Abhoryo commented Jan 21, 2012

I always use this without cssrewrite and the --symlink option.:

background-image: url("/bundles/mybundle/images/bg.png");
@ahundiak

This comment has been minimized.

Copy link

ahundiak commented Feb 1, 2012

This fix for cssrewrite is to not use cssrewrite. Nor should you add bundle paths to your css. Instead, use output as follows:

   {% stylesheets 
        output="bundles/zaysoarbiter/css/forms2.css"
        '@ZaysoArbiterBundle/Resources/scss/forms2.scss'
    %}
        <link rel="stylesheet" href="{{ asset_url }}" media="all" />
    {% endstylesheets %}

This works in development mode because the whole 'bundles/...' is still just a virtual name. For production mode, use the asset:install and the assetic:dump to copy everything to your web directory. Relative paths in css will now work fine without any rewriting.

@stof

This comment has been minimized.

Copy link
Collaborator

stof commented Feb 1, 2012

the other way to fix it is to use the cssembed filter to embed the images in the CSS file directly.

@pumppi

This comment has been minimized.

Copy link

pumppi commented Feb 2, 2012

Is there any example for the ccsembed filter?

@apfelbox

This comment has been minimized.

Copy link

apfelbox commented Mar 5, 2012

I have a similiar problem: all request, going through app_dev.php/bundles produce a NotFoundHttpException. Without app_dev.php everything is working without errors. Is this related?

@gremo

This comment has been minimized.

Copy link

gremo commented Dec 17, 2012

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

@alex88

This comment has been minimized.

Copy link

alex88 commented Jan 28, 2013

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

@jrobeson

This comment has been minimized.

Copy link

jrobeson commented Jun 14, 2013

@kriswallsmith : is this gonna be scheduled for 1.2?

@kriswallsmith

This comment has been minimized.

Copy link
Owner

kriswallsmith commented Jun 14, 2013

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 (#53 (comment)).

@alex88

This comment has been minimized.

Copy link

alex88 commented Jun 25, 2013

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 comment has been minimized.

Copy link

kitingChris commented Aug 4, 2014

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.

@JHGitty

This comment has been minimized.

Copy link

JHGitty commented Sep 28, 2014

+1 ; any updates?

@cassianotartari

This comment has been minimized.

Copy link

cassianotartari commented Oct 2, 2014

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

@ghost

This comment has been minimized.

Copy link

ghost commented Oct 7, 2014

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

@smilesrg

This comment has been minimized.

Copy link

smilesrg commented Nov 5, 2014

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

@JHGitty

This comment has been minimized.

Copy link

JHGitty commented Nov 27, 2014

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

@rimouesleti

This comment has been minimized.

Copy link

rimouesleti commented Dec 12, 2014

Same problem here with Symfony 2.6

@n1c01a5

This comment has been minimized.

Copy link

n1c01a5 commented Apr 7, 2015

Same problem.

@clubdesarrolladores

This comment has been minimized.

Copy link

clubdesarrolladores commented May 19, 2015

+1 same problem, please fix this soon

@JHGitty

This comment has been minimized.

Copy link

JHGitty commented May 20, 2015

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

This comment has been minimized.

Copy link

drAlberT commented Jun 5, 2015

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

@JHGitty

This comment has been minimized.

Copy link

JHGitty commented Jun 5, 2015

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

This comment has been minimized.

Copy link

drAlberT commented Jun 8, 2015

@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

This comment has been minimized.

Copy link

stphane commented Mar 21, 2016

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 😠 !
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 comment has been minimized.

Copy link

ReneMuetti commented Mar 30, 2016

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

This comment has been minimized.

Copy link

stphane commented Mar 30, 2016

@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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.