ActiveScaffold apparently creates public/blank.html every time the server starts, even if that file already exists (so adding it to version control doesn't help). This is causing my application to fail to boot on Heroku, since they have a read-only file system.
Can someone please tell me how to prevent this behavior or work around it so I can deploy my app with ActiveScaffold on Heroku?!
In my rush to get this working I didn't even think to analyze the init.rb file within the ActiveScaffold plugin directory. Therein contains the require statement to a file containing the logic to copy files from the plugin's "public" directory on-server-load. Commenting out that functionality fixed my problem (after ensuring that I already had those files in their intended destinations).
Related
In another question (Why does the Rails command force a help message for the new command?), I found that Rails needs the rails script to be in the script folder, in the root of my project, in order for it to be properly detected as an existing Rails projects, and allow me to use the various rails commands other then new.
I did this because I felt that the more popular moniker for including executable content in a repository to highlight available use cases is by using the name scripts. At least the pluralism in English should be appreciated!
Is there anyway to change which folder the main Rails executable looks for the project-included one?
I actually think it's a bit silly to include this rails executable in the project, and can be redundant. Maybe it's for customization, but I feel that could better be done in the configuration, environment, other .rb files. So also, could this just be removed somehow, and still have a functioning project through varied use of the main rails command.
I'm running a test Ruby-on-Rails app using Webrick in a test environment. The automated end-to-end test accesses an admin page which causes a JavaScript file to be updated which is used by another admin page. The problem is that the second admin page does not see the update, but instead gets the old copy of the JavaScript file. I can see the changed file on the file system, but even if use curl from the command line, I still get the old version of the file. The test used to work (at least with Rails 4.0, if not 4.1). It is just now that I am trying to update to Rails 4.2 that this problem has arisen.
Is there something I can do to to tell Rails/Sprockets to forget its old cached copy of the JavaScript that was updated? I know when I am updating it, and wouldn't mind even resetting Sprocket's entire cache if I couldn't do it selectively. What I can't do is restart the server each time a JavaScript file gets updated.
I tried many approaches to making Sprockets "forget" its cached copy, but it seemed very determined to remember, and I began to have the sense that I was fighting against a firmly entrenched design decision. In the end I decided that, just for my generated-on-the-fly JavaScript files, I would avoid sprockets altogether, which meant handling the compiling and fingerprinting of the files myself, and writing my own version of javascript_include_tag just for those generated files.
For reference, the compiling and fingerprinting is actually fairly easy:
require "uglifier"
require "digest"
minified_content = Uglifier.compile(File.read(my_generated_js_file))
fingerprint = Digest::MD5.hexdigest(minified_content)
fingerprinted_file = File.basename(basename, '.js') + '-' + fingerprint + '.js'
(and then just write out the fingerprinted file to public/assets).
I am trying to modify javascript files in a Ruby on Rails application in HEROKU. Every time I modified something, it did not have any effect on the application. Thanks to a member in this web site, I realized that my application is using asset packager. This asset packager creates a file called base_packaged.js that has all the javascript file compressed.
Because I am new with Heroku and using Windows I modify everything with a text editor, in this case I use notepad++. So when I change the file for example quote.js, nothing happens. I suppose The file quote.js is changed but the compressed base_packaged.js is not been updated. So when I push the file using GIT GUI to Heroku, only the file quote.js is updated but heroku does not recognized that change and does not modify the base_package.js.
How can I modify edit or update the base_package.js. Obviously file is very important I don't want to make a mess with my application.
Thank you.
Ok, so this is surely a suboptimal solution but I have had the same exact problem and this is what I have done. Go into any file such as your rake file in your public directory and just add something to a comment or add another comment.
Git will see this change and your other changes will get added along. I completely understand that this is a hack but It is super easy you works!
Its redmine, a Ruby on Rails application. Currently, every issue can have one or more files. But if a user decide to update/change them, the old files are replaced. My task is to develop something to allow versioned files for every issue: so, if a user update the content of an existing issue, the previous state of the issue is preserved and it can be displayed in some form.
I'm new to RoR and Redmine development.
I guess the best thing in this case is to modify Redmine so that instead of uploading files to the issue, you put the files into a subversion repository and then add a link in the issue.
Alternatively, allow multiple files to be added, and modify to code to rename them everytime one is uploaded - appending a suffix (_1, _2 etc) to each filename.
I am generating some large files in my Rails application. Fortunately, they only need to be generated once. I would like to save these files to disk so that I don't have to generate them again.
Which directory in my Rails application is the most appropriate place to put application generated files?
Thanks!
If security of the files is not an issue you can put them in a subdirectory of public (for example, public/assets) which in your deploy script is symlinked to a directory in shared/public so that when you redeploy the files are retained.
If security is an issue, the solution is similar, though you would not want the directory to be web accessible. Instead you would use a controller to control access and serve up the files with send_file.