I'm running an app (on Dreamhost) that works fine in the development environment, but does not work properly in production. I've tried eliminating every difference I could: using the same mysql instance, for example.
The only thing I can see is that my query params seem to be encoded strangely.
Here's how they look in the development instance:
This search:
GET "/individuals?utf8=%E2%9C%93&search%5Bfirstname_like%5D=&search%5Blastname_like%5D=jones&commit=Search"
Produces these params:
Parameters: {"utf8"=>"✓", "search"=>{"firstname_like"=>"", "lastname_like"=>"jones"}, "commit"=>"Search"}
In the production instance:
GET "/individuals/?utf8=%25E2%259C%2593&search%255Bfirstname_like%255D=&search%255Blastname_like%255D=jones&commit=Search"
Produces these params:
Parameters: {"commit"=>"Search", "search%5Bfirstname_like%5D"=>"", "utf8"=>"%E2%9C%93", "search%5Blastname_like%5D"=>"jones"}
The query string seems to have an extra "25" in there.
Any idea what gives?
Turns out this was an Apache "mod_rewrite" issue. I had a .htaccess file from html5boilerplate that was causing the problem.
Related
I use the following code in one of my models
def jasper_amount
ActionController::Base.helpers.number_to_currency(amount)
end
I know that it breaks MVC. However, in this case it is the best solution. I have to pass data to Jasper via the Ruby Java Bridge and formatting in Jasper would be much more complicated.
Calling object.jasper_amount from the rails console works fine and prints the expected results. This works fine in development and production.
Now, to pass the data to Jasper I first have to create an xml version of the object's attributes using object.to_xml(methods: [:jasper_amount]).to_s This works in development but not in production. In production the value for jasper_amount that is passed to Jasper is "0.00 €". However, if I remove number_to_currency from def jasper_amount (just returning unformatted amount) it works. What's even more confusing is the fact that calling jasper_amount from the rails console in productions works. I guess the culprit must be to_xml, but I have no idea why it works in development and not in production.
The problem was with Ruby Java Bridge (rjb) and BigDecimal. If you use BigDecimal with rjb, you have to include the "BigDecimal" gem in your Gemfile. Otherwise all your BigDecimals will be 0 (and that all over your app!)
* Listening on tcp://0.0.0.0:3000
Started GET "postinstall/" for 127.0.0.1 at 2013-10-27 07:26:15 +0000
ActiveRecord::SchemaMigration Load (1.8ms) SELECT "schema_migrations".* FROM "schema_migrations"
This is basically it, all my buttons linked to helpers like:
new_user_registration GET /users/sign_up(.:format) registrations#new
edit_user_registration GET /users/edit(.:format) registrations#edit
Only all the links are like this:
http://localhost:3000/postinstall/users/sign_in
I've been through my log and at one point requests just start being effectively poisoned by this "postinstall" business.
I've grepped for 'postinstall' because surely this word can't be coming from nowhere. I decided to sleep on it because I thought it must be a stupid mistake, but now I need help and unlike 99.9% of my previous questions - it doesn't seem this one has been answered whatsoever.
Searching for even the query "postinstall" on Google yields terrible results.
I THINK my problem lies in a path helper, everywhere the 'postinstall' is getting prepended to requests/urls - the path is referred to like so:
Test
<%= link_to "Sign In", new_user_session_path, :class => "btn btn-success" %>
Where the first link would work route OK, but then the buttons to Submit the login form are trying the POST to /postinstall/users/sign_in etc... The second button would be a link to /postinstall/users etc.
I have absolutely no idea how this started, I've been over my git log and even going back 3 or 4 days (this issue started last night) the error still persists.
Is it seemingly specific to my Mac too, deployed to a dev site (Ubuntu) with no issues. I have restarted my mac etc. Any help is very obviously appreciated...
I had the same problem.
I'm using puma as webserver, and puma uses a ENV called 'SCRIPT_NAME' which was setted with 'postinstall' value after i installed a software, doing puma inject 'postinstall' on url.
if you still having this issue, unset SCRIPT_NAME var from your ENV, using the command on shell unset SCRIPT_NAME.
If you are using TotalTerminal, the recent update leaves the SCRIPT_NAME environment variable set after the update. Rebooting the computer solves the issue.
I started a new topic on Binary Age's support site to try to get this fixed: http://discuss.binaryage.com/t/totalterminal-update-overrides-script-name-breaks-webservers/897
I am using Ruby on Rails 3.1 and I would like to understand why a constant's value stated in an initializer file sometimes is not retrieved as expected.
That is, in my ROOT_RAILS/config/initializers/initializer_name.rb file I have "simply" the following code:
CONSTANT_NAME = [
'value_one',
'value_two',
'value_three'
]
In a my view_file_name.js.erb file I have "simply" the following code:
<% logger.debug "#{CONSTANT_NAME.inspect}" %>
When I perform a HTTP request so to "trigger"/"run" the view_file_name.js.erb source code and then I go to check the log file, sometimes the CONSTANT_NAME is outputted, sometimes it isn't (in the latter case it outputs a [] value). I tried to restart the server many times but, after a while, the constant outputted to the log became [].
What is the problem? How can I solve that?
P.S.: I noted that the issue occurs mostly when I reload the page. This is a strange behavior and maybe there is something really subtle in my poor code that I can not fix. I think that the issue is related to the "process" to retrieve the CONSTANT_NAME value from the initializer file...
i work on an old Rails 2.3.4 App.
When i invoke an action of an "baz" controller with an GET param like
www.foo.com/baz/search?search_string=Hello
i get the expected result but i looks like rails is caching the result.
Invoking the action with an new param like
www.foo.com/baz/search?search_string=World
returns the old result.
I did some debugging an realized that this behaviour only occurs in "production env" when
"config.cache_classes" is "true"
Any ideas?
THX!
config.cache_classes = true in production.rb wouldn't cache any results. It basically means that it wouldn't reload Rails classes in the Production Environment and have them cached,( this is why the production environment is faster than development )
are you doing some page caching or any other kind of caching in that controller, It would be great if you could post your controller code here.
there is a scaffold created Story... and in the create action, there is
#story = Story.new(params[:story])
i was curious as to what is in params... so i want to dump out params... but there is no view associated with the create action... is there a way to dump out its content? is there a way to dump out the POST variables in of my code too? (to see what's going on in the lower level)
The easiest thing to do is just dump params out to the log:
Rails.logger.info("PARAMS: #{params.inspect}")
If you're in development mode, just look in your development.log and that line will be there.
The params scope is a combination of URL/FORM (GET/POST) fields, and it will be printed out in the log as part of the normal output processing, so you might not need your own dumping of it - any development or production log contains the params dump at the top of the log line, e.g.
Processing Clients::ClientsController#show (for x.x.x. at 2009-05-24 00:34:26) [GET]
Parameters: {"id"=>"303", "user_id"=>"2"}
Now I know Rails more, you can also simply use a
p params
in your code and look at the console's output (the log shown on the console)
If you're on a Mac, Spike is a great little app the analyses log files and will let you inspect params for requests, amongst other things.
Using Fiddler on Windows, it is shown
the HTTP line #1 is:
POST /stories HTTP/1.1
this is the POST content:
authenticity_token=62iw%2BrsxlCFsbnxsS7FXKRn6CcvJfjottrsBPlM5lZo%3D&story%5Bname%5D=Google+Main+Site&story%5Blink%5D=www.google.com&commit=Create
listed in a table:
authenticity_token 62iw+rsxlCFsbnxsS7FXKRn6CcvJfjottrsBPlM5lZo=
story[name] Google Main Site
story[link] www.google.com
commit Create
and the server log is:
Parameters: {"commit"=>"Create", "story"=>{"name"=>"Google Main Site", "link"=>"www.google.com"}, "authenticity_token"=>"62iw+rsxlCFsbnxsS7FXKRn6CcvJfjottrsBPlM5lZo="}
You don't need to anything except look in your logs (they live in /log). Unless you're fiddling with something, the logging of parameters is turned on by default in all logs.
Processing PostsController#create (for 127.0.0.1 at 2009-05-24 13:03:24) [POST]
Parameters: {"commit"=>"Create", "authenticity_token"=>"2G6BKOs8xNAaXiToVf4r1ko8QZzP9QAomi2PHVQC5Oc=", "story"=>{"something"=>"asdfafd"}}
Parameters lists all parameters, and the hash following "story" is the equivalent of params[:story] (everything comes to the server as strings, and Rails turns it into a HashWithIndifferentAccess so that you can access it with a symbol).
If you're on a *NIX system (including OS X) open a new terminal window/tab and type the following command:
tail -f log/development.log
You'll get a constant stream of requests coming in -- including params -- and the resulting DB actions. Invaluable for development/debugging, IMO.