I am using simple_form gem and have a ordinary rails scaffold which is working perfectly - I am able to update/create/destroy records.
When I add the views in application <%= yield %> a issue occurred - the simple_form gem is rendering a form with action "/" for the new action and I was not able to create new records.
In my controller, the path for create action is
#POST /webinars
So, I edit the action of the form from "/" to "/webinars" (using the browser console) and then successfully create a record.
I suppose that I should override the action of the from somehow, but was not able to find how.
Is this the real problem?
<%= simple_form_for #user, url: '/webinars' do %>
...
<% end %>
I'm migrating my app to Rails 3.2.8 from 2.3.5. One form uses reCAPTCHA (in an erb file). Right now, all the HTML tags that the recaptcha_tags puts out are in escaped HTML. (i.e. <...> instead of <...>). So I see the tags themselves in the HTML page, instead of the reCAPTCHA box.
Here's what my erb looks like. I've verified that it doesn't matter where in the erb I put the recaptcha tags (inside the form_for or outside):
register.html.erb
...
<%= recaptcha_tags :public_key => RECAPTCHA_PUBLIC_KEY %>
...
Other things, like form_for don't have this problem. They output straight HTML.
Gemfile
gem "recaptcha", :require => 'recaptcha/rails'
Thanks in advance!
Turns out I needed to prefix the recaptcha_tags call with "raw":
register.html.erb
...
<%= raw recaptcha_tags :public_key => RECAPTCHA_PUBLIC_KEY %>
...
One of the major changes between Rails 2.3.5 and 3.X was some changes having to do with cross site scripting. You may want to start your upgrade by upgrading to 2.3.14 and adding the rails_xss gem. The rails_xss gem (https://github.com/rails/rails_xss) will switch the HTML safety default to escape, so it will cause the issue you're seeing with recaptcha_tags. This will allow you to see what strings in your app need to be marked as html_safe.
Or, if recaptcha_tags is the only issue, you may be able to fix it by telling rails not to escape the recaptcha_tags.
Something like:
<%= raw recaptcha_tags :public_key => "_________" %>
Thanks for doing the research. :)
I have a brand new Rails 3.1rc4 project. After generating a scaffold, migrating and creating a new entry I noticed that I could not destroy the entry I had just created.
It turns out that "/assets/defaults.js" can't be found so the destroy confirmation dialog isn't popped up.
I figure this might have something to do with the new asset pipeline, but searching for solutions has not helped me out much.
Any idea why defaults.js can't be found?
Thanks for any help.
It's most likely because the reference to
javascript_include_tag :defaults
is still in the application layout. That reference should be changed to
javascript_include_tag "application"
I found the issue - somehow (through a gem, probably) my app/views/layouts/application.html.erb file was changed from
<%= javascript_include_tag "application" %>
to
<%= javascript_include_tag :defaults %>
Changing it back to the original fixed my issue.
I would like to get some ref to use Jquery in Rails app.
At the moment, I am stuck to find the things to enable google suggest in text box and autocomplete in Rails app. Any help/suggestions/ref would be of great help.
I did a short search on auto-complete with Rails earlier today and these are the best links I found:
http://github.com/crowdint/rails3-jquery-autocomplete and http://github.com/crowdint/rails3-jquery-autocomplete-app
http://blog.jackhq.com/posts/3-how-to-add-jquery-autocomplete-to-your-rails-forms-in-a-restful-way
http://code.google.com/p/jquery-autocomplete/
Edit: I just implemented the first link in my app, works flawless so far. I had minor problems with the documentation though, this works for me (on typing AutoComplete starts after the second character):
Model named Category, has an attribute name:
controller:
class UsersController < ApplicationController
autocomplete :category, :name
...
routes:
get 'users/autocomplete_category_name'
view:
<%= form_tag 'users/index' do %>
<%= autocomplete_field_tag 'address', '', users_autocomplete_category_name_path, :size => 75 %>
<% end %>
I am going through the rails 3 tutorial at railstutorial.org. I have just created an extremely simple scaffold Users.
The scaffold-generated destroy link does not work in Internet Explorer. It redirects to the show action instead of deleting the user.
This problem only happens in IE9 and IE8 (the only IE versions I've tested so far) The problem DOES NOT happen in Firefox. Can anyone tell me why this is happening?
The view:
<%= link_to 'Destroy', user, :confirm => 'Are you sure?', :method => :delete %>
Generated HTML:
Destroy
The controller:
def destroy
#user = User.find(params[:id])
#user.destroy
respond_to do |format|
format.html { redirect_to(users_url) }
format.xml { head :ok }
end
end
In Rails 3.1 with the asset pipeline, all the javascript is in application.js. So, rather than :defaults, you need "application".
<%= javascript_include_tag "application" %>
Make sure you have <%= javascript_include_tag :defaults %>
JS is now unobtrusive in rails 3, so the include is required to make it work.
Replace public/javascripts/rails.js of your application with this one:
https://github.com/rails/prototype-ujs/raw/master/src/rails.js
This is updated recently (2010/11/13).
The rails.js bundled with Rails 3.0.0/3.0.1 does not work well on Internet Explorer.
You need to upgrade your prototype distribution to 1.7 instead of 1.7rc2 (which doesn't have full support for IE 9). The latest Rails gem (at time of writing( in the gem repo is bundling 1.7rc2. Go to the prototype homepage, download the new 1.7 release and replace this with the bundled prototype.js.
I couldn't get it to work with IE9 with the default javascript libraries, so I installed jquery-rails and it works just fine. Not perhaps the ideal solution, but if it works...
By default, new rails projects are created with Prototype javascript libraries, with some prototype-specific helper functions in "public/javascript/rails.js". The scaffolding relies on some of these helpers to handle some things, like destroying a record, since there isn't a good javascript-free way of making a DELETE request, etc.
Make sure that your pages are loading both the javascript libraries and the "rails.js" file, which are needed to make the scaffolding work (see theschmitzer's answer, or check in Firebug).
Second, if you are using jQuery, install the 'jquery-rails' gem and then run "rails g jquery:install". This will remove the Prototype libraries, install the jQuery libraries, and update the helpers to use jQuery.
Try replacing your javascript default include with:
<%= javascript_include_tag "jquery" %>
<%= javascript_include_tag "jquery.min" %>
<%= javascript_include_tag "rails" %>
after following the steps above to get the latest jquery.js, jquery.min.js, and rails.js. That worked for me, anyway.
Or, replace the meaning of :defaults in application.rb:
config.action_view.javascript_expansions[:defaults] = %w(jquery jquery.min rails)
And then your application layout can still look have
<%= javascript_include_tag :defaults %>
This is probably because the loading of your script (rails.js and/or application.js) happens in head. At script execution time, there are no elements in your DOM with the attributes data-confirm and data-method.
So, the solution is to move the javascript tag to the end of <body>. At this time, the DOM has most likely been loaded and the javascript will find your elements.
I experience the same problem, regardless of web browser.
theschmitzer's answer didn't help me.
I found that as long as I am using the jquery javascript library the destroy method in the controller is never called.
In my case I had a conflict between the javascript libraries (jQuery and Prototype) which was hard to figure out for such a newbie. I changed completely to jQuery - as in the end of this railcast: http://railscasts.com/episodes/205-unobtrusive-javascript
I had the same problem. I was using the <%= javascript_include_tag :defaults %> as well as the jQuery library. When I removed the jQuery library, things worked. Also, you could use noConflict().
I notice that in rails 4, link_to puts the :method as a html attribute "data-method" but :confirm goes to an attribute "confirm" where the javascript needs it to be "data-confirm".
Not sure if this is a bug in rails, but you can work around it by doing this:
<%= link_to 'Destroy', user, :data => {:confirm => 'Are you sure?'}, :method => :delete %>