I'm playing with Padrino, experimenting with a very minimal site at the moment with no DB and just a few HAML and SASS files under the app/ directory.
What I've noticed is that each time I render a page which links to a stylesheet that's defined in a .sass file, it compiles the stylesheet to .css and stores it under public/.
This is all very well, but I also have some static assets stored in public/, including images and some other hand-written .css files.
What this means is that my public/ directory becomes a mix of things I placed there and things compiled by Padrino. So, looking in there will show a bunch of .css files, some of which are compiled .sass files, and some of which are my actual primary static assets. This is confusing.
Is there a way I can stop Padrino (or Sinatra, or Rack, or whatever is doing it) from saving these compiled files during development, and keep my public/ clean?
Alternatively, can someone explain why what I'm asking for is a bad idea / by design / I should learn to love it instead? :-)
Thanks.
I don't know how to set the SASS settings for Padrino, I had a look and couldn't find anything helpful either. I would feel a bit nervous about running it this way too, it could easily get confusing and unhelpful, and what if the asset names clash?
What you could do is not add SASS in via Padrino, and then run it yourself either via the --watch switch or via something like Guard. That way you can also specify different subfolders within the public directory (images/css/js etc), which is what I do (although it does mean you need to remember to add the subfolder as part of the path when describing links). The app doesn't even need to know you're using SASS, and precompilation, when it's this simple, is surely better than the kind of compilation on demand that you've got at the moment (IMO).
You might try the Padrino mailing list for help with the settings.
Using the padrino-sprockets gems I also wanted to change the default /public/stylesheets directory to /assets/stylesheets where sprockets pick them up. I found that my padrino project genereated with the -c sass option had a /lib/sass_plugin.rb file with the following:
# Enables support for SASS template reloading for rack.
# Store SASS files by default within 'app/stylesheets/sass'
# See http://nex-3.com/posts/88-sass-supports-rack for more details.
module SassInitializer
def self.registered(app)
require 'sass/plugin/rack'
Sass::Plugin.options[:template_location] = File.join(Padrino.root, "app/stylesheets")
Sass::Plugin.options[:css_location] = File.join(Padrino.root, "public/stylesheets")
app.use Sass::Plugin::Rack
end
end
Editing the :css_location path and restarting Padrino did the trick!
Related
Shahzaib here, coming to you for a bit of help !
I'm still new in the Shopify and liquid stuff but i'm getting there.
I'm cutrently trying to minify a scss.liquid file on Shopify, usually when I try to do that with a css file, I use an online minifier, exept that, apprently the scss.liquid format is not properly handled. Every time I try to minify it, my site crash ?
Do you guys have something to recommand regarding minifying a scss.liquid file ?
thanks in advance,
regards, Shahzaib.
I recommend setting up a gulp task to do this. This will help simplify your SCSS files into individual files for whatever they style. Also, you won't be edited your theme's default theme.scss.liquid file, so it is easier to overwrite default styles, and you know exactly which styling is yours vs the theme's.
To setup a gulp task, you will need to install node.js and gulp. I recommend using npm for this. Here is a good introduction tutorial to this which you'll need to adapt a bit to work with your Shopify file structure. For example, I recommend adding a src directory for your custom .scss files, and compiling them into one single file in the assets directory, instead of working directly in the theme.scss.liquid file.
https://css-tricks.com/gulp-for-beginners/
Once you have completed those instructions, make sure to add node_modules to your .gitignore file before committing.
Next, setup your project to use themekit. https://shopify.github.io/themekit/ , and have your gulp task run on save of the file. This will compiling your src files into a single file in the assets directory which will then be uploaded to your store by themekit.
Hope this helps!
I'd second than10's answer, and add that if minification of static assets is going to be part of your theme development workflow, use gulp.js running locally with something like gulp-shopify-upload watching your changes and pushing them up to your store:
https://www.npmjs.com/package/gulp-shopify-upload
See basic usage in particular.
I have started trying out Sass for my css work. In the directory where my Css file resides I see a '.sass-cache' folder too. Can any one tell me why is this folder created and is it safe if I delete it.
thanks,
By default, Sass caches compiled templates and partials. This dramatically speeds up re-compilation of large collections of Sass files, and works best if the Sass templates are split up into separate files that are all #imported into one large file.
Without a framework, Sass puts the cached templates in the .sass-cache directory. In Rails and Merb, they go in tmp/sass-cache. The directory can be customized with the :cache_location option.
If you don’t want Sass to use caching at all, set the :cache option to false.
You can configure the Sass cache location by setting a Sass option in your compass configuration file like so:
sass_options = {:cache_location => "path\to\tmp\sass-cache"}
Source: Sass reference
If your main problem is "inhibiting pushes to development environments when multiple developers use/change it", you can add it to your .gitignore file. As stated in the other answer, Sass cache files speed up compilation based on whether a Sass file has changed since last compile.
In my experience it's standard practice to consider them temporary files, and omit them from version control.
The aim:
I would like a Tumblr blog to pull CSS from a Rails app's asset directory.
This means I can use SASS, Compass and other sitewide CSS to generate the styling.
This also means if anything is updated in low-level CSS, tumblr.css will be regenerated along with the regular cap deploy, and Tumblr's appearance will change automatically.
The problem:
The Rails 3 asset pipeline adds a hash to the filename, e.g.:
tumblr-c6ec969ce054623163b9404f6c8330e9.css
Therefore the Tumblr template can't include it unless I update the URL manually every time it changes.
Is there a way to either selectively disable asset.digest for one file, or to explicitly generate a single CSS file from SASS, without going through the whole asset pipeline? Or maybe to generate an automatic alias or something?
You will not have to disable the digests at all.
When Rails precompiles the assets, it adds digests to all the files. However it also creates identical files without digests. So both the following files will load the same css:
tumblr-c6ec969ce054623163b9404f6c8330e9.css
tumblr.css
If you check the public/assets directory after precompilation you should see both files.
Hope this makes helps.
In Rails 4 it seems that the asset precompile no longer does both the digest and non-digest filenames, only the filenames with the digest get compiled. The best option now to precompile assets without a digest hash is to use the Non Stupid Digest Assets gem:
https://github.com/alexspeller/non-stupid-digest-assets
Hopefully they add this to the Rails project as a standard feature in Rails 5.
I have that sneaking feeling I'm missing something obvious:
I ran
RAILS_ENV=production bundle exec rake assets:precompile
to precompile my assets before pushing to Heroku. Looking in /public/assets shows that application.js and application.css manifests successfully compiled, but none of my standalone files precompiled:
admin.js.coffee
blog.js.coffee.erb
[ ... several more similarly named ... ]
twitter.js.coffee.erb
and
admin.css.less
home.css.less
public.css.less
are all missing from /public/assets.
I thought that Rails would precompile the application.js/.css files, plus anything else that doesn't end in js/css:
The default matcher for compiling files includes application.js,
application.css and all files that do not end in js or css:
[ /\w+\.(?!js|css).+/, /application.(css|js)$/ ]
from: http://guides.rubyonrails.org/asset_pipeline.html#precompiling-assets
I don't want to have to manually update config.assets.precompile every time an asset file name changes. Am I missing something that will make Rails precompile these assets?
Update
Based on #Richard Hulse's answer below, I tested it out by created a separate manifest file for a standalone asset (i.e. I renamed twitter.js.coffee.erb to twitter-include.js.coffee.erb and added twitter.js with a single //= require pulling in the renamed original). This seems to work.
There must be a cleaner way than this, and it seems to contradict the Rails guide quoted above. The guide says the only files that won't be compiled are .js or .css files not named application. What I'm see is only .js or .css being directly compiled (i.e. not via a manifest) - nothing else.
Two things:
If these files are included in your application manifests, then they are included in the site's application files.
There should be a line in both application manifests: require_tree, that will pick up all the assets automatically for your. Is that in these files?
Edit in reply to edit:
The way I would structure this is have two sets of manifests. The standard ones (application.css/.js) are for public. The admin set are for admin pages. Include all the stuff you want in admin.js/.css manifests and add those files to the precompile array:
config.assets.precompile += ['admin.js', 'admin.css']
This would allow you to share code between the two groups. For example you can include jquery in both, but jquery_ujs in admin only. In your admin section layout just include the admin manifests instead of the application manifests.
In practice you will then add new files to the application or admin manifests as you develop the site, and you won't have to change the precompile configuration.
Once you get to the point of adding lots of assets, an admin section and so on, it is expected that things will get more complex and that you have to be explicit about what is included in manifests and the order (as opposed to require_tree).
Got a trouble when including some external javascript code (example can be jquery.treeview plugin with css and images included) - in vendor/assets (where this should go) it seems it doesnt work with images. Any experience or example of doing this?
I suspect it's because you need to correct /images/foo.jpg to the new scheme of /assets/foo.jpg
If not, please include logs and examples.
Along the lines of what Zach said, the solution I've used is to modify the js/css files to be erb templates, and used asset_path('treeview/foo.jpg') to replace '/treeview/foo.jpg', and move all plugin images to the app/assets/images/treeview folder.
This will make everything work swimmingly, but it is less than ideal in requiring hacking up plugins before they work with the new system.
Of course, you can also keep your CSS and JS files in /public/javascripts and just javascript_include_tag them as usual, but you'll lose the precompile/bundle/compress functionality the asset pipeline provides.