parse error in ruby routes - ruby-on-rails

I am launching my first ruby server i have launched the server to view the welcome aboard page and have generated a controller for the page however when i change the route file and uncomment the following statement
root 'welcome#index'
I get the following error
JSON::ParserError in Welcome#index
Showing C:/Sites/examplesite/app/views/layouts/application.html.erb
where line #5 raised:
757: unexpected token at 'Script execution time was exceeded on script
"AppData\Local\Temp\execjs20160617-1504-n6adzfjs".
Script execution was terminated.
'
Rails.root: C:/Sites/examplesite
what part of the code is causing the error and how can it be fixed
these are the code which is run
index.html.erb
<h1>Hello, Rails!</h1>
routes.rb
Rails.application.routes.draw do
get 'welcome/index'
# The priority is based upon order of creation: first created -> highest priority.
# See how all your routes lay out with "rake routes".
# You can have the root of your site routed with "root"
root 'welcome#index'
#root 'welcome#index'
application.html.erb (where the error is reported on line 5)
<!DOCTYPE html>
<html>
<head>
<title>Examplesite</title>
<%= stylesheet_link_tag 'application', media: 'all', 'data-turbolinks-track' => true %>
<%= javascript_include_tag 'application', 'data-turbolinks-track' => true %>
<%= csrf_meta_tags %>
</head>
<body>
<%= yield %>
</body>
</html>

Is this producing on other machines too?
This message is issued if the systems cscript timeout period is exceeded before a script completes execution.
Any program that uses the cscript command in Windows has the ability to add a /s switch in addition to the /t timeout command.
When the /s switch is used, all of the switches from the command (which includes the /t timeout) are saved to the registry.
Vivado does not use the /s switch.
However, the cscript commands that are issued from Vivado are subject to the settings saved by another program.
To fix this, go to the following location in the registry (regedit), and delete the "Timeout" key, or set it to 0:
HKEY_CURRENT_USER\Software\Microsoft\Windows Script Host\Settings

Related

Capybara RSpec with CSS and JS?

rails (5.1.4)
rspec-rails (3.7.2)
capybara (2.16.1)
I'm trying to create a RSpec Rails 3.7 System spec as in https://relishapp.com/rspec/rspec-rails/v/3-7/docs/system-specs/system-spec .
Here my simple spec:
require 'rails_helper'
RSpec.describe "testing system", type: :system do
it "tests the spec" do
visit root_path
click_link 'Home'
save_and_open_page
end
The problem is that Capybara does render neither CSS content nor JS content after save_and_open_page call (in the browser) - just a plain HTML. The header inside this HTML-file contains some links
<link rel="stylesheet" media="all" href="/assets/application-ea5a1efcc44a908543519edabe00e74132151ebedeef3c1601921690d9162b5e.css" data-turbolinks-track="reload" />
<script src="/assets/application-ff63e43aef379fef744a00f21a8aadf96dc2ae8e612f8e7974b231f946569691.js" data-turbolinks-track="reload"></script>
but they reference some empty files.
Is there some way to fix it?
I tried some recipes, but still no luck. I tried to precompile the assets, to move "capybara.html" into the "public" folder, but no effect.
Modifying stylesheet_link_tag is not a good solution, a much better solution is to specify Capybara.asset_host which will add a <base> tag to any saved pages. Generally this would be set to something like
Capybara.asset_host = "http://localhost:3000/"
which would then load the JS/CSS assets from your dev server which would have access to the test mode compiled assets in the public subdirectory. Note: that none of this means the page will actually be functional since JS requests will still fail, DB records won't exist anymore, etc. Also, since it saves element attributes (not properties) a checkbox you just checked will probably not be checked in the saved page. However it will give you a generally styled page you can inspect the structure of. If all you're looking for is a current image of the page you should be using the save_screenshot/save_and_open_screenshot functionality provided by most of Capybaras drivers instead.
It has to do something with your assets.
Clear cache and run rake assets:clobber and rake assets:precompile
Still no luck, then check if Capybara is configured correctly.
Check app/views/layouts/application.html.erb has the correct Rails tags for stylesheets and javascripts. Something like this:
<!DOCTYPE html>
<html>
<head>
<title>My App</title>
<%= stylesheet_link_tag 'application', media: 'all' %>
<%= javascript_include_tag 'application' %>
On the command line, run:
rake assets:clobber
rake assets:precompile
Ensure that public/assets/ include:
.sprockets-manifest-<xyz>.json
application-<abc>.js
application-<def>.css
Open the .sprockets-manifest... file and you should see that there are application js and css files with filenames that match the actual public/assets/ files. This .sprockets-manifest file controls what actually gets included in the HTML head links and scripts when the Rails tags are replaced.
If this is still not working, ensure that the files are accessible by your user running the test (including the manifest). Occasionally lose the .sprockets-manifest file when copying files and in source control as it can appear to be hidden.
Finally, check your file log/test.log to see if there are any obvious errors being thrown during the tests.
I found a solution. Perhaps it's not the best one, but it works with me. If anybody find a better approach - let me know, please.
Run rake assets:precompile. I didn't even set RAILS_ENV=test.
Modify the stylesheet_link_tag method:
def stylesheet_link_tag2(*sources)
options = sources.extract_options!.stringify_keys
path_options = options.extract!('protocol').symbolize_keys
sources.uniq.map { |source|
tag_options = {
"rel" => "stylesheet",
"media" => "screen",
"href" => path_to_stylesheet(source, path_options)[1..-1]
}.merge!(options)
tag(:link, tag_options)
}.join("\n").html_safe
end
The idea is to turn the rendered link from this:
<link rel="stylesheet" media="all" href="/assets/application-ea5a1efcc44a908543519edabe00e74132151ebedeef3c1601921690d9162b5e.css" data-turbolinks-track="reload" />
to this:
<link rel="stylesheet" media="all" href="assets/application-ea5a1efcc44a908543519edabe00e74132151ebedeef3c1601921690d9162b5e.css" data-turbolinks-track="reload" />
eliminating the leading slash in the href attribute value (since we don't have a server running but just a saved HTML-page).
Replace the code inside the header in \app\views\layouts\application.html.erb to:
<% if Rails.env.test? %>
<%= stylesheet_link_tag2 'application', media: 'all', 'data-turbolinks-track': 'reload' %>
<% else %>
<%= stylesheet_link_tag 'application', media: 'all', 'data-turbolinks-track': 'reload' %>
<% end %>
Write a spec like this:
require 'rails_helper'
RSpec.describe "testing system", type: :system do
it "tests..." do
visit root_path
click_link 'Home'
save_and_open_page Rails.root.join( 'public', 'capybara.html' )
end
end
Add to .gitignore:
/public/capybara.html
Do the same thing with the JS-content.
UPDATE:
If you don't like modifying \app\views\layouts\application.html.erb you can do some monkey patching:
include ActionView::Helpers::AssetTagHelper
alias_method :old_stylesheet_link_tag, :stylesheet_link_tag
def stylesheet_link_tag2(*sources)
options = sources.extract_options!.stringify_keys
path_options = options.extract!('protocol').symbolize_keys
sources.uniq.map { |source|
tag_options = {
"rel" => "stylesheet",
"media" => "screen",
"href" => path_to_stylesheet(source, path_options)[1..-1]
}.merge!(options)
tag(:link, tag_options)
}.join("\n").html_safe
end
def stylesheet_link_tag(*sources)
if Rails.env.test?
stylesheet_link_tag2(*sources)
else
old_stylesheet_link_tag(*sources)
end
end
I usually put such code into app\helpers\application_helper.rb and add include ApplicationHelper into app\controllers\application_controller.rb
UPDATE 2
Setting Capybara.asset_host = "http://localhost:3000/" as #Thomas Walpole advised doesn't work. That's right - how can it work if http://localhost:3000/ is unavailable (AFTER the spec ran)? Of course - when I call save_and_open_page the HTML-file opens with a file://.... address - with no HTTP-server serving it. The attempts to set
Capybara.asset_host = "file://#{Rails.root}/public"
failed - looks like the base HTML-tag supports only http-adresses - not file://... ones. I checked it in Chrome and Firefox.
So my next code proposal is such:
include ActionView::Helpers::AssetTagHelper
alias_method :old_stylesheet_link_tag, :stylesheet_link_tag
def stylesheet_link_tag2(*sources)
options = sources.extract_options!.stringify_keys
path_options = options.extract!('protocol').symbolize_keys
sources.uniq.map { |source|
tag_options = {
"rel" => "stylesheet",
"media" => "screen",
"href" => "file://#{Rails.root}/public" + path_to_stylesheet(source, path_options)
}.merge!(options)
tag(:link, tag_options)
}.join("\n").html_safe
end
def stylesheet_link_tag(*sources)
if Rails.env.test?
stylesheet_link_tag2(*sources)
else
old_stylesheet_link_tag(*sources)
end
end
This eliminates the need to call
save_and_open_page Rails.root.join( 'public', 'capybara.html' )
instead you can simply call
save_and_open_page

Rails 4 is adding controller name to the asset url which causes 404 error

I am wondering why Rails 4 is adding the controller name to the asset request when I click on a controller specific page. For example, instead of this url (which is accurate): /assets/jqBootstrapValidation.js
It's generating this url (causing a 404 error): /controllername/assets/jqBootstrapValidation.js
It's happening for all js and css files I have manually added to the app/assets directories. Seems like the asset request is getting confused and adding the current directory name to the request but I don't know how to fix it (the assets are in the correct directory).
How do I remove the controller name from the asset request? Any advice would be appreciated.
<%= stylesheet_link_tag 'application', media: 'all', 'data-turbolinks-track' => true %>
<%= javascript_include_tag 'application', 'data-turbolinks-track' => true %>

Cached app issue - deployed with capistrano

I have deployed my app for first time. Cap deploy was successful. However I was getting an error on a specific code segment. So I decided to delete this code segment and get the website up and running first before fixing this error.
I run cap deploy again but I am still getting the same error on the code segment that I removed from the source file (I see the error by tailing production.log). It was not suppose to be there. I searched around on the net and found that the problem is that there is a cached version of the app. I found out that a solution would be to delete the cache-copy folder in /shared folder.
I restarted my services (nginx, unicorn) and open the site again and I still get the same error on the code segment I removed.
I checked my new current folder, cached-copy folder and last release folder and all don't have the code segment that produces the error.
It's really odd to me. Any clue whats going on?
Thanks!
Code segment that produces the error:
ActionView::Template::Error (undefined method `stripe' for #<Rails::Application::Configuration:0x00000002a85578>):
20: <meta name="viewport" content="width=device-width">
21: <%= javascript_include_tag 'application' %>
22: <%= javascript_include_tag "https://js.stripe.com/v1/", type: 'text/javascript' %>
23: <%= javascript_tag "Stripe.publishableKey = '#{Rails.configuration.stripe[:publishable_key]}';", type: 'text/javascript' %>
24: <%= csrf_meta_tag %>
25: <%= stylesheet_link_tag "application", :media => "all" %>
26: <script type="text/javascript" src="//use.typekit.net/xoh2pss.js"></script>
app/views/layouts/application.html.erb:23:in `_app_views_layouts_application_html_erb__486989174473553269_34754060'
The line 23 was removed but its still shown as generating the error.
# config/initializers/stripe.rb
Stripe::API_KEY = 'asd8df9sadf766'
# application.html.erb
<%= javascript_tag do -%>
Stripe.publishableKey = <%= Stripe::API_KEY %>;
<% end -%>
Are your assets precompiled and the old all.js (or similar) being redeployed without this change present? If the routine invoked by the javascript portion isn't present that could produce an error -- that might be the stripe method you're trying to invoke. If they were manually precompiled and you made the change but didn't re-compile it, the redeploy would simply put the old one back out there.

Following The Rails getting Started Guide and getting a ActionController::InvalidAuthenticityToken

I'm following the rails getting started guide here:
http://guides.rubyonrails.org/getting_started.html
I'm on the step 'Creating posts', where I setup my new view to submit a post to my controller.
When I click the submit button in the view I get the error ActionController::InvalidAuthenticityToken
I was able to get past the error by commenting out this line in the ApplicationController
protect_from_forgery with: :exception
However I'm not sure if I should be doing that. Is that fine or should I dig deeper into the problem? What does that line do?
Content of:
/views/layouts/application.html.erb
<!DOCTYPE html>
<html>
<head>
<title>Budget</title>
<%= stylesheet_link_tag "application", media: "all", "data-turbolinks-track" => true %>
<%= javascript_include_tag "application", "data-turbolinks-track" => true %>
<%= csrf_meta_tags %>
</head>
<body>
<%= yield %>
</body>
</html>
No, you shouldn't be commenting that line in your ApplicationController. It is meant for the security of your application at production level.
From the docs: Turn on request forgery protection. Bear in mind that only non-GET, HTML/JavaScript requests are checked.
protect_from_forgery is a feature in Rails that protects against Cross-site Request Forgery (CSRF) attacks. This feature makes all generated forms have a hidden id field. This id field must match the stored id or the form submission is not accepted. This prevents malicious forms on other sites or forms inserted with XSS from submitting to the Rails application. Shamelessly copied from here.
And, in last but not the least. Here is the link explaining why Cross-Site Request Forgery (CSRF) should be taken seriously, and why it is important.

My route returns a blank view (no html when I do view source)

I am brand new to Ruby on Rails and I have been trying to get a simple default route set up and working. When I try to run my application I get a blank result (if I do a view source, there is nothing there).
Here are the relevant files (not sure if I am missing something that would be useful).
app/config/routes.rb
Blog::Application.routes.draw do
root :to => "home#index"
end
app/views/home/index.html.erb
<h1>Home#index</h1>
<p>Find me in app/views/home/index.html.erb</p>
app/controllers/home_controller.rb
class HomeController < ApplicationController
def index
end
end
app/views/layouts/application.html.erb
<!DOCTYPE html>
<html>
<head>
<title>Benji</title>
<%= stylesheet_link_tag :all %>
<%= javascript_include_tag :defaults %>
<%= csrf_meta_tag %>
</head>
<body>
<%= yield %>
</body>
</html>
When I try to run my application, I go to http://localhost:3000 and nothing shows up. If I do a view source, it is empty.
If do rake routes this is the result:
JESSE-GAVINs-MacBook-Pro-17:benji jesse$ rake routes
(in /Users/jesse/Dev/benji)
root /(.:format) {:action=>"index", :controller=>"home"}
JESSE-GAVINs-MacBook-Pro-17:benji jesse$
In my development.log file I see this:
Started GET "/" for 127.0.0.1 at Tue Sep 07 10:44:10 -0500 2010
Processing by HomeController#index as HTML
Rendered home/index.html.erb within layouts/application (2.8ms)
Completed 200 OK in 15ms (Views: 14.7ms | ActiveRecord: 0.0ms)
What could be the issue? How do I go about solving this?
Solved (sort of...)
It works just fine when I started the rails server on a different port.
It was my understanding that I didn't need to restart the server in order for it to detect changes in the code.
Sorry about the waste of time, I just didn't know which tree I needed to bark up. I learned some things along the way.
As you're playing with Routes, you absolutely need to restart the server. I don't know if this is part of the problem, but most (all?) things under config/ need the server to be restarted to take effect, particularly routes and environment

Resources