zf2-assetic-module
zf2-assetic-module copied to clipboard
widmogrod
Serve static files with combine=false and debug=true.
When using ...
'debug' => true,
'combine' => false
... assetic module was including individual files from a collection, for example:
<script type="text/javascript" src="/js/main_bootstrap.min_1.js"></script>
<script type="text/javascript" src="/js/main_json2_2.js"></script>
<script type="text/javascript" src="/js/main_modernizr_3.js"></script>
<script type="text/javascript" src="/js/main_main_4.js"></script>
... however, it was unable to serve them which resulted in error 404. This PR fixes this and allows for serving static files based on $asset->getTargetPath().
Please review and send in feedback. If you like the direction I'll add tests and fix docs.
Could you provide me example of module with assets and configuration?
What do you mean that you "were unable to serve them"?
- whether the assets have been copied to the public directory?
- do you have "buildOnRequest" set to
trueorfalse
whether the assets have been copied to the public directory?
no
http://localhost/js/main_main_4.js ---> A 404 error occurred
Actually, I don't want to have them copied to public directory. I want individual files from collections to be accessible via PHP. When deploying to production, debug becomes false and I can build the final, monolithic compiles versions of collections. In devel (with debug => true) it's better not to pollute public dir.
do you have "buildOnRequest" set to true or false
didn't help, regardless of value.
Actually, I don't want to have them copied to public directory.
But that how is AsseticBundle is working.
If you have:
debug: true
combine:false
buildOnRequest:true
Then your assets from module going to be moved to public/asset - on every change request.
On production you should have:
debug: false
combine:true
buildOnRequest:false
And run from command line:
php public/index.php assetic setup
php public/index.php assetic build
Hmm... well, it's not doing that :-) And I'm quite happy about it, actually.
Even if it did, it'd make those silly names like /js/main_bootstrap.min_1.js (the original file is just bootstrap.min.js).
Hello all,
I must admit that I do agree with Thinkscape : Keeping the same names would be much better in dev. I haven't reviewed your code yet Thinkscape, but I think that we need to improve this excellent module, and this kind of improvement is on the right track.
Don't you think so Gabriel ?
Furthermore, I'll propose a PR to remove the "head_..." stuff which is not clean and replace it (as we already spoke about) with a variable.
This module is a must have, and I think that we can help to make it even better.
