I'm trying to upgrade a Rails 2 app to Rails 3, and I'm really having problems with a route. Here's what I have in the routes.rb file
get 'profile/:login' => 'account#profile', :as => :profile
When I go to http://localhost:3000/profile/MyUsername, it does not correctly add :login to the params hash. See here:
Started GET "/profile/MyUsername?foo=bar" for 127.0.0.1 at Tue Mar 20 21:39:03 -0400 2012
Processing by AccountController#profile as HTML
Parameters: {"foo"=>"bar"}
For some reason, :login is not part of the regular params. On a hunch, I inspected the request.env and found this:
action_dispatch.request.path_parameters"=>{:action=>"profile", :controller=>"account", :login=>"MyUsername"}
I'm totally stumped at this point. Am I missing something? Where should I look next to figure out what is going on here?
Update
I started playing with removing gems and this magically worked. I just commented out gems from the Gemfile until I got the absolute minimal set needed to load the homepage. At that point, the params were exactly as expected. Then I added gems back a few at a time in order to find the cause. I added everything back and...it works now. Crazy, but whatever it takes, I guess.
Looks like you mixed the syntax for 'match' with 'get'. Please try:
match 'profile/:login' => 'account#profile', :as => :profile, :via => :get
Or
get 'profile/:login', :to => 'account#profile', :as => :profile
in your config/routes.rb
When I want to use URL params I always use resource(s) when defining the route. That is convention with Rails 3.x so you can try it.
resources :accounts , :exclude => :all do
member do
get :profile
end
end
This should help or any other way of defining resource URL.
Something like this should work
match 'profile(/:login)' => "account#profile", :as => :profile
If it does not, there may be something else in your routes file that conflicts. Make sure any match ':controller(/:action(/:id(.:format)))' (or similar "match everything" routes) are at the very bottom of your routes file.
Related
Okay, so I've upgraded to Rails 4 (kind of unplanned with my 10.9 server update) and have been able to get everything running on my photo gallery app except for the routes. For some reason I've always had trouble understanding routes since rails 3. Here was my previous working code under Rails 3
root :to => "gallery#index", :as => "gallery"
get 'gallery' => 'gallery#index'
resources :galleries
match 'gallery_:id' => 'gallery#show', :as => 'gallery'
I understand that match has been depreciated, but if I try to use GET, I'm getting the following error:
Invalid route name, already in use: 'gallery' You may have defined two routes with the same name using the :as option, or you may be overriding a route already defined by a resource with the same naming.
Basically, I want the root (index) to load as "/photos/gallery" as it does, and my show action to load, for example, record id 435 as: "/photos/gallery_435" which is how I previously had it working. Sorry for what is probably a simple question, I just cannot seem to grasp the rails routing.
Try this
match 'gallery_:id' => 'gallery#show', :via => [:get], :as => 'gallery_show'
You can then refer to this path as gallery_show_path in your helpers and views.
Changing the 'as' removes the conflict.
I have my routes arranged so that when visiting the site the :id is displayed before the slug like so
match "/causes/:id/:slug" => "causes#show", :as => :cause, :via => 'get'
But I also have a nested attribute called "post" that belongs to causes like so
match "/causes/:id/:slug/posts" => "causes#posts", :via => 'get', :as => :posts
When I use this, everything works great for the causes, but not for the posts.
If I use
#post = Post.find(params[:id])
in causes or posts controller it always looks for the ID of the causes, and not the :id of the posts. So if the post :id is 9, and the cause :id is 1, and I use
#post = Post.find(params[:id])
it will always look for post[1] and not 9 or whatever the post id really is.
What am I doing wrong? Is there a way to make this work in the routes, or maybe a different way to find the id of a nested object in the controller?
I need the route to be the way I have it set up, :id/:slug...
rake routes information:
cause GET /causes/:id/:slug(.:format) causes#show
edit_cause GET /causes/:id/:slug/edit(.:format) causes#edit
PUT /causes/:id/:slug(.:format) causes#update
posts GET /causes/:id/:slug/posts(.:format) causes#posts
POST /causes/:id/:slug/posts(.:format)
PUT /causes/:id/:slug/posts(.:format) causes#update_post
DELETE /causes/:id/:slug/posts(.:format) causes#destroy_post
causes GET /causes(.:format) causes#index
POST /causes(.:format) causes#create
Any help would be great.
To solve your immediate problem, you'll want to add something like this to routes.rb
# config/routes.rb
match "/causes/:cause_id/:slug/post/:id" => "causes#update_post", :via => 'put', :as => :update_post
And then you can generate the URL in your views like this...
link_to 'Update this post', update_post_path(#cause, #post)
...and access the parameters in your controller as params[:id] (for the post) and params[:cause_id] (for the cause).
More generally, though, the way you are specifying your routes is pretty cumbersome, and I suspect you're making your life harder than it needs to be. If this were me, I would do something like
# config/routes.rb
resources :causes do
resources :posts
end
This would accomplish something pretty close to what you have now, the main difference being that it wouldn't contain slugs. I'm not sure why you need to have both slugs and IDs, maybe you could just identify your causes by their slugs? Stringex is a good gem for generating slugs, and you can set it so that slugs are guaranteed to be unique.
Here is the section of the Rails guide on nested resources
http://guides.rubyonrails.org/routing.html#nested-resources
And here is a Railscast about using slugs with nested resources
http://railscasts.com/episodes/314-pretty-urls-with-friendlyid?view=comments
Hope this helps.
This is because you're using the id of the cause, and if you're doing /causes/:id/posts shouldn't you be doing #posts = #cause.postsanyway?
I would look into the new router syntax for rails 3 if I were you, as there is a nicer way to nest resources http://guides.rubyonrails.org/routing.html
edit:
use the friendly_id gem and nest your resources, to avoid confusion follow REST best practises that resource in question is at the end so
/causes/:slug/posts/:slug
I am new to rails and was wondering how I can make this work. I want a URL to look like this:
http://localhost:3000/businesses/coldfire-gundam
using this route:
match "/businesses/:permalink", :to => "businesses#show", :as => :business_permalink
however when I place this route before this:
resources :businesses
any call to /businesses/1 (1 as param[:id]) does not work anymore, obviously because it is caught by the permalink declaration
how can I make it work then?
You need a way to differentiate /businesses/:id and /businesses/:permalink. The :id should always be numeric (unless of course you're using MongoDB) so if you can force your :permalink to always contain something non-numeric then a simple :constraints should do the trick:
match '/businesses/:permalink', :to => 'businesses#show`, :constraints => { :permalink => /.*\D/ }, :as => :business_permalink
The /.*\D/ forces the route to only match if :permalink contains at least one non-numeric character. You need the .* because route regexes are implicitly anchored at the beginning.
If you happen to be using MongoDB then your :id will probably be a hex BSON ID so you'd want to use /.*\H/ as your constraint and you'd want some way to ensure that your :permalink always contains at least one non-hex character.
Once all that's in place you can put your match "/businesses/:permalink" before your resources :businesses in routes.rb and everything should work fine. And routes are checked in the same order that they appear in routes.rb so you will want your match before your resources.
I would suggest using the friendly_id gem for creating permalink routes. This will handle most of the 'magic' for you in an easily reusable way.
Resources for the gem and railscast:
https://github.com/norman/friendly_id
http://railscasts.com/episodes/314-pretty-urls-with-friendlyid
I have a threads model, that has Thread (id, uuid, title...)
Here is the path:
When the controller redirects: http://localhost:3000/threads/828b9a2ffc
In the logs I then see:
Started GET "/threads/828b9a2ffc" for 127.0.0.1 at Sat Jul 09 17:24:02 -0700 2011
Processing by ThreadsController#show as HTML
Parameters: {"id"=>"828b9a2ffc"}
The issue here is I don't want 828b9a2ffc to be the ID, I want it to interpruted as uuid in the parameters, so I should see:
Parameters: {"uuid"=>"828b9a2ffc"}
How can that be made possible in the routes file?
Thanks
Maybe I'm missing something obvious but what's wrong with using a route like:
match '/threads/:uuid' => 'threads#show', :via => :get
in your routes.rb?
The simplest way would probably be:
match 'threads/:uuid' => 'threads#show', :as => :thread
That will make the last part of the url available as params[:uuid]. If you already have
resources :threads
defined then just put it above that in your routes file and it will override the threads#show path already defined.
In routes.rb you need something like this:
get 'threads/:uuid', :action => "show", :as => "by_uuid"
This will create a thread_by_uuid_path(thread_object) helper method but if you also have:
resources :threads
... there will still be the standard show route which uses :id and will conflict with the new one you define above. You could define each of the routes manually and deleted the resources :threads line, but I would tend to leave the route alone and change the controller method like this:
def show
#thread = Thread.find_by_uuid(params[:id]) || Thread.find(params[:id])
...
end
... this way the ID can still be used even though you expect the UUID to be passed.
I am new to ruby and while creating a sample application found out an issue that whenever I go to http://127.0.0.1:3000/people/index by default show action is executed and index is taken as a parameter. This is server log:
Started GET "/people/index" for
127.0.0.1 at 2010-12-23 18:43:01 +0500 Processing by PeopleController#show as
HTML Parameters: {"id"=>"index"}
I have this in my route file:
root :to => "people#index"
resources :people
match ':controller(/:action(/:id(.:format)))'
What is going on here and how can I fix the issue?
The route
resources :people
creates "sub"-routes
get '/people' => 'people#index'
get '/people/new' => 'people#new'
post '/people' => 'people#create'
get '/people/:id' => 'people#show'
get '/people/:id/edit' => 'people#edit'
put '/people/:id' => 'people#update'
delete '/people/:id' => 'people#destroy'
Actually, all of these sub-routes include (.:format) at the end of the recognized path.
The path /people/index would be recognized by the route /people/:id, mapping to the action #show.
The path /people would be recognized by the route /people, mapping to the action #index.
Use the URL helpers people_path and people_url for the /people route.
To get Rails to travel backward in time to before it espoused REST and to understand /people/index, do this:
resources :people do
get :index => 'people#index'
end
You might want to watch this Railscast episode.
A couple things to keep in mind when working with your routes:
rake routes dumps the map of URLs to your controllers
When providing backwards compatibility, redirect the user to the correct path
I personally have yet to upgrade my app to Rails 3, and I'll be dragging my feet until I really need to do it (just got it out the door not too long ago). In Rails 2.x you had resource routes, but if you kept the default controller/action/id route it would fall through and resolve. It appears that is no longer the case in Rails 3. Essentially your resource routes handle all URLs in that resource namespace (/people in your case).
To provide backwards compatibility, I would add a redirect route to resolve that incompatibility.
match "/people/index", :to => redirect("/people")
The main reason for that is to prevent users from saving an incorrect URL for their personal links--while allowing legacy users to still be able to get where they meant to go.
Edit: New answer, removed pointing out the typo in the question.