I have deploy my Symfony 3.1 application and uploaded it online, following the symfony 3.1 cookbook steps (basic file transfer and common post-deployment tasks); I have checked all the requirements, install vendors, clear cache, and install all assets, but no images, css configurations nor js files are loading. I can only see the raw content.
any idea of what I can do?
thanks.
I can't write a comment, cause have no reputation so I hope my advices will be like answer.
First solution very simple. Check the permissions of your web directory.
chmod -R 0777 ./web
Check the config file (or post it's code here).
check if your paths are relative, something like:
href="/images/myimage.jpg"
Where images - folder which contains in web directory
And from my opinion try to clear cache once more in both dev and prod.
I'm using Symfony2 and Assetic. Lately I've been doing a lot of CSS work so at a certain point I needed the command
$ php app/console assetic:dump --env=prod --no-debug
Ever since I've used it I need to run that command everytime I change CSS to see the difference. Now I've did some research and found out that I can put Assetic in to watch mode so I don't have to run the command above after every change using the following command:
$ php app/console assetic:dump --watch --env=prod
However, I just want it back to before I put it into this manual mode. The Symfony2 documentation explains how to do an assetic dump, but not how to put it back in dynamic mode (http://symfony.com/doc/current/cookbook/assetic/asset_management.html#dumping-asset-files)
Does anyone know how to put it back in dynamic mode?
There are two likely possibilities for Symfony not dynamically serving assets from the internal controller:
1. assetic.use_controller is not really true
Confirm 100% you are telling Symfony assetic.use_controller is true. One straightforward method of debugging would be adding this to the top of your controller action and reloading the page:
var_dump($this->container->getParameter('assetic.use_controller'));die();
Not getting true as a return value could mean you are overriding use_controller in either config_dev.php or config_prod.php depending on what environment you are pointing at.
2. Your web server is checking for static assets before passing to Symfony
Most webservers can be configured to check if a URL points to a physical file asset and deliver that file. So if you have dumped assets in Symfony, the webserver might be serving that file and not passing the request onto Symfony.
For nginx see: http://nginx.org/en/docs/http/ngx_http_core_module.html#try_files
For apache see: Apache rewrite rule similar to Nginx try_files
The solution would be to remove the dumped asset files from the file system. Their location depends on where you configured them to go, but check in web/js, web/bundles, etc.
I have a web site built on Symfony2 which uses twig templates, LESS, and assetic.
In order to cache bust assets, I'm simply using this in my config.yml:
framework:
templating:
engines: ['twig']
assets_version: 'asset-version-here'
And then I use the asset() function to load the asset and the cache busting is handled for me.
However, the concern I have is when I load my LESS (css) file, there are references to other files, and I would like to know how these files can be cache busted as well.
Example:
.someSelector { background:url('../images/filename.png'); }
How can I make sure that the referenced file, filename.png is cache busted upon deployment?
The asset files referenced in Twig using asset() are cache busted automatically upon deployment (I use a deployment script hook that updates the assets_version in the framework's config), but those referenced in a stylesheet are not.
How can I do this?
I didn't manage to find a natural solution to this issue. In the end because I needed to move forward, I just added a certain tag in the query string, e.g. {ASSETS_VERSION}, and then I search/replace this with the revision number of the project at deployment time as part of my deployment script.
I'm not proud of this solution but it did solve my problem in the short term until I can find a more elegant solution.
This problem is driving me crazy... I think I've tried every conceivable combination of Sass file, ERB file, asset helper, image helper, etc. etc. Someone please give me new ideas!
Context:
Rails apps require use of asset helpers so that when the assets are precompiled, the source will be a fingerprinted asset file. I.e., if you just called img src="X.jpg", the site in production would look for X.jpg, but the file in public/assets has actually been fingerprinted as X-as;diofua;wemfiwaejfoiawefo.jpg. The only way to get to that fingerprinted file is to use an asset helper, e.g., image_url ('X.jpg').
Right now in my live site, I'm using an asset helper, but for whatever reason, it's not pointing at the fingerprinted asset. Note that the assets are found in development (but again, that's because there's no fingerprint added in development).
Code
Image titled "classic-map.png", located in app/assets/images/galleria
Image is called from a css.erb file required in the application.css file. In the css.erb file, I have the following code:
background-image: url(<%= asset_path 'galleria/classic-map.png' %>);
For reference, http://guides.rubyonrails.org/asset_pipeline.html
Note that I'm choosing to write this as a css.erb file, hence the use of asset_path vs. asset-path. Also, I initially thought that the issue might have been in interpolation, but in the page source, the url is definitely working, it's just that it's pointing at url(galleria/classic-map.png) instead of url(galleria/classic-map-apsoidufalskjf;kasj.png)
A million kudos to whoever can help!
For what it's worth, this happened to be AGAIN, and this time I could not use the hack because I desperately needed the fingerprint. So somehow, magically, I ran a rake assets:clobber and heroku run rake assets:clobber to clean all assets, and then a straight up git push to force Heroku to do the precompilation for me. That did it, and everything works.
Now, when this happens, I clobber assets locally & in production and push, forcing Heroku to precompile remotely. Similar to #user2880239's answer. I have stopped precompiling locally and checking into git.
I sat with a Sr Rails developer who still couldn't help me fix this. But the workaround we ended up using was that we just manually removed the asset fingerprint in the public folder (since the fingerpoint is what the asset helper is meant to point to).
I.e., the file galleria/classic-map-587854758918434124.png we just manually changed back to galleria/classic-map.png and it works fine.
Note that if you do this 'hack', the next time you precompile assets, Rails will create another fingerprinted asset, so you'll have duplication unless you want to keep deleting the additional fingerprinted asset each time. For me, I don't care about the duplication, I care about not thinking about this anymore.
Did you check RAILS_ENV ?
bundle exec rake assets:precompile RAILS_ENV=production
I had the same problem you did. This blog post helped me.
What I did was change a few things in my config/environments/production.rb file, namely...
config.serve_static_assets = true
config.action_dispatch.x_sendfile_header = ‘X-Accel-Redirect’
config.assets.compile = true
Note that you might not need to 'add' any of those properties since they may be pre-set to false or merely commented out.
Then I did the heroku dance:
rake assets:precompile
git add .
git commit -m "Fix static assets"
git push
git push heroku
I'm having the same issue. I even tried the helper from the rails console from heroku, and the helper works fine there!!
$ heroku run rails console
Running `rails console` attached to terminal... up, run.8071
Loading production environment (Rails 4.1.7)
irb(main):001:0> puts helper.image_path("bg.jpg")
/assets/bg-00acfb7dbe138102509d82ac2313c24d.jpg
My final "solution" was to update config.assets.compile = true in config/environments/production.rb to fallback to the non fingerprinted image.
Hope this solution could help to someone. And if you had any real solution, please make me know!
The answer to this for Heroku is in their Pipeline docs here.
By doing clobber you are basically cache-busting all your assets and forcing all clients to reload all static assets (even if they have not changed) every time you deploy your code. That is not advisable as it means every time you deploy ALL clients will experience slow loading times until all assets get cached again.
Your css file has a dependency to your image file, so you need to tell the assets pipeline about this by putting this at the top of your css:
//= depend_on_asset "galleria/classic-map.png"
This tells sprockets that if class-map.png gets a new fingerprint then the css must also get a new fingerprint. So it will only recompile the files (and dependencies that changed).
Also for others landing here, be aware that if you are using asset_path from ANYWHERE other than a view (eg in a model) you need to prepend the full context:
ActionController::Base.helpers.asset_path('your-image.png')
More info here.
I designing an programming a website using Symfony2. I completed some parts and checked the client side in both dev and prod environment. In the first time everything was fine and I saw same result in both environments, But after sum changes in views (I'm using Twig with Three-level Inheritance) such as adding sum other stylesheets in "stylesheets" block, dev environment works fine but in prod environment no stylesheets added and its using old data. I cleared cache and log manually from both path "app/cache/dev" and "app/cache/prod" ... but nothing changed. I removed all stylesheets in block and cleared chache again old data is still there!
Any suggestion?
Apart from clearing the cache, make sure you publish your assets:
app/console assets:install --symlink web
app/console assetic:dump
The problem was about removing cache files. I had been removing cache files via cPanel filemanager. It gave "all files removed successfully" but they didn't. So I found another way to clear cache. I used shell_exec:
shell_exec('rm -r app/cache/prod');