I am working on a project that needs to alter Refinery's WYMEditor behavior a bit. This is easily done by overriding jquery.refinery.wymeditor.js using rake refinery:override and editing it to my own needs, which works fine in development environment.
However, when it comes to production, overrides are ignored. That is, the compiled asset just contains jquery.refinery.wymeditor.js from bundle, and editing that file directly there may give the desired effect, but that's just not the way it should be done.
Strange thing is, that the problem apparently manifests itself only when trying to override backend-related assets.
It might be useful to know that I am using refinery-edge.
Any help appreciated.
So I have managed to beat it. First thing to mention is that it wouldn't be possible without poking into Refinery source code.
As I have already written in the comment, the problem was that I was trying to override an asset (wymeditor/jquery.refinery.wymeditor.js in my case) that wasn't included in a view directly, but was referenced in another asset, which was taken from the gem. And since sprockets knows nothing about Refinery's overrides, it took the referenced assets by the relative path, i.e. from the gem (and hence, unmodified), too. So, again, in my case the solution was to override the refinery/wymeditor.js, and everything worked as a charm.
Should you need to change any other backend script than WYMEditor, you will most likely have to override the refinery/refinery.js, which includes all other backend scripts, in addition to the very script you need to modify.
There is one big concern, though. With all these overrides, I have made any updates very error-prone, since some files will update, and some will not. It could have been avoided by overriding everything, but that effectively means no updates at all.
Try changing the name of the generated file and including that in your manifest instead of the original name. I suspect that it is preferring the original in the presence of two assets named the same thing.
Related
In Rails, my assets have fingerprints added to them, e.g.
mysite.com/assets/something/base-216123123asdfasd20a.css
Unfortunately, if I want to link to this from another site (like a blog) I can't rely on the fingerprint.
Is there a configuration setting I can set so that I can access files without knowing their fingerprint? (While still keeping the fingerprint for normal Rails usage; this would just be used for special cases)
I don't want to do one-off things like creating a route for a specific asset, because I'll need it for many assets.
The simplest way is to put the files directly into the public folder:
- public
-- your_file.js
This would then have to be called by referencing your URL directly = http://domain.com/your_file.js
This is only really advisable for files which you want to remain static (such as widget JS or similar).
Non Digest Assets
Alternatively, you may wish to try a gem I've never used before called non-stupid-digest-assets - a gem which allows you to determine which files are "fingerprinted" and which are not.
I've never used this gem, so cannot comment on its effectiveness, but it looks like it will give you the ability to save certain assets without their fingerprinted name. This means that you'll still be able to call them using the various asset path helpers which are available in Rails, as well as giving others a direct reference for the file:
#config/initializers/non_digest_assets.rb
NonStupidDigestAssets.whitelist = ["your_file.js"]
You'll then be able to call asset_path("your_file.js")
I have the following files, in my asset path:
javascripts/abc.js
templates/abc.js.mustache # this gets compiled to abc.js
naturally, they both would be requested as assets/abc.js.
Is there a fix? If not, what part of the Sprockets source would need to be modified?
My thinking is along the lines that if the engine can remove the extension, it can well enough add a suffix.
It may be too obvious, but isn't it better just rename files? I understand nature of your question, but it's hard to imagine ultimate requirements, which forces same filenames for those files. Hence this, you have foobar.js and foobar.js.mustache, which compiles to foobar.js. Why they have same names? They do same things? This is design flaw, if you ask me.
I have the same problem, and have not yet found a satisfying solution. My sites have many complex full-stack plugins (aka engines), and they have lots of css, js, and image files. Having to namespace, eg "styles.css" in each plugin kinda sucks. When upgrading to Rails 3, I assumed the file resolver would put engines/plugins in /styles, but no, they all get combined into one virtual path.
My current temporary solution is to build a rake task that I run that checks for duplicate filenames. I run it before committing code and on deployment. Hackity! If that helps, great, if not, perhaps someone out there has a more elegant solution...
I have put all my images for my admin theme in the assets folder within a folder called admin. Then I link to it like normal ie.
# Ruby
image_tag "admin/file.jpg" .....
#CSS
.logo{ background:url('/assets/images/admin/logo.png');
FYI. Just for testing I am not using the asset_path tag just yet as I have not compiled my assets.
Ok all good so far until I decided to update an image. I replaced some colors but on reload the new styled image is not showing. If I view the image directly in the browser its still showing the old image. Going one step further I destroyed the admin images folder. But it has broken nothing all the images are still being displayed. And yes I have cleared my cache and have tried on multiple browsers.
Is there some sort of image caching going on? This is just local development using pow to serve the pages.
Even destroying the whole images folder the images are still being served.
Am I missing something?
In 3.1 you just get rid of the 'images' part of the path. So an image that lives in /assets/images/example.png will actually be accessible in a get request at this url - /assets/example.png
Because the assets/images folder gets generated along with a new 3.1 app, this is the convention that they probably want you to follow. I think that's where image_tag will look for it, but I haven't tested that yet.
Also, during the RailsConf keynote, I remember D2h saying the the public folder should not have much in it anymore, mostly just error pages and a favicon.
You'll want to change the extension of your css file from .css.scss to .css.scss.erb and do:
background-image:url(<%=asset_path "admin/logo.png"%>);
You may need to do a "hard refresh" to see changes. CMD+SHIFT+R on OSX browsers.
In production, make sure
rm -rf public/assets
bundle exec rake assets:precompile RAILS_ENV=production
happens upon deployment.
For what it's worth, when I did this I found that no folder should be include in the path in the css file. For instance if I have app/assets/images/example.png, and I put this in my css file...
div.example { background: url('example.png'); }
... then somehow it magically works. I figured this out by running the rake assets:precompile task, which just sucks everything out of all your load paths and dumps it in a junk drawer folder: public/assets. That's ironic, IMO...
In any case this means you don't need to put any folder paths, everything in your assets folders will all end up living in one huge directory. How this system resolves file name conflicts is unclear, you may need to be careful about that.
Kind of frustrating there aren't better docs out there for this big of a change.
In rails 4 you can now use a css and sass helper image-url:
div.logo {background-image: image-url("logo.png");}
If your background images aren't showing up consider looking at how you're referencing them in your stylesheets.
when referencing images in CSS or in an IMG tag, use image-name.jpg
while the image is really located under ./assets/images/image-name.jpg
http://railscasts.com/episodes/279-understanding-the-asset-pipeline
This railscast (Rails Tutorial video on asset pipeline) helps a lot to explain the paths in assets pipeline as well. I found it pretty useful, and actually watched it a few times.
The solution I chose is #Lee McAlilly's above, but this railscast helped me to understand why it works. Hope it helps!
The asset pipeline in rails offers a method for this exact thing.
You simply add image_path('image filename') to your css or scss file and rails takes care of everything. For example:
.logo{ background:url(image_path('admin/logo.png'));
(note that it works just like in a .erb view, and you don't use "/assets" or "/assets/images" in the path)
Rails also offers other helper methods, and there's another answer here: How do I use reference images in Sass when using Rails 3.1?
I copied the 'config' directory and renamed it to 'config_dev' so that I don't alter the current settings. How do I configure Rails to use the config directory of 'config_dev'?
Well, i'm not sure whether you can rename that and still make it work or not. However, i would highly not recommend that approach. If you must do something like that, better rename the files inside the folder, like environment.rb.bak or the likes.
Generally speaking a config folder is where important settings initiate from and i think that changing that convention can lead to more problems. I could be wrong, but i would just change the files (that's what the rails 2 to rails 3 conversion plugin does as well).
I'm attempting to reopen the String class in rails and add a bunch more methods for my app to use. Writing the code isn't a problem - my question is rather about where this code should go.
It doesn't make sense to me to reopen a class inside a different model file, because it really has nothing to do with any of the models specifically. I thought perhaps somewhere in config or lib would make sense, but I'm not particularly well versed with RoR yet.
To summarize, where would be the most logical place to define class-modifying code, and are there any implications depending on where/when the code is loaded?
The most logical place is probably in a file in the config/initializers directory. Any *.rb file you put in here will be automatically executed when rails boots. If you want, you could put them in a sub folder, so you could do something like config/initializers/extensions/*.rb.
I try keep these monkey-patches to a minimum, only when they are very clearly in the best interest of my code.
Lately I have preferred to keep the files organized in folders such as lib/monkey/string.rb, lib/monkey/hash.rb, etc. I then require all files in the lib/monkey folder in my environment.rb file.
# Load all monkey-patches.
Dir["lib/monkey/*.rb"].each {|monkeyfile| require monkeyfile}
This keeps all of my class modifying code isolated to one location, should a problem arise. I also enjoy the somewhat goofy naming, because it makes it stand out as something to be mindful of. Someone may have a better system, if so ... I'd love to hear about it!