Close
Glad You're Ready. Let's Get Started!

Let us know how we can contact you.

Thank you!

We'll respond shortly.

PIVOTAL LABS
Standups 5/18/2010 and 5/19/2010: SEO routes

Ask for Help

“Our site requires crafting URLs in a very particular SEO-friendly way. Rails doesn’t seem to give us a good solution for our URLs. Any suggestions?”

One of our clients needs to make their app accept and generate compound URLs that look something like the following:

http://my.site/jkrowling-series-harrypotter-book-1

where author, series, and book are all different domain concepts. Rails RESTful resources don’t really support this format. There wasn’t an immediate solution, but among the peanut gallery of ideas:

  • Hyphens are better than slashes in URL crafting, but Rails doesn’t separate on slashes at all

  • to_param solutions – Overriding to_param to something that starts with an integer ID generates URLs that look very slug-like, but can use standard Rails Domain.find mechanisms. For example, a book.to_param might be overridden to be “1-bookname”, which works for all purposes. The problem with this solution is that it doesn’t quite fit the requirements here, and doesn’t cover the compound needs.

  • Custom routes are always a possibility. You can hook up a special (non-resource) controller that understands flexible browse-y routes like the one above, parses them, and delegates to the more standard resource controllers. The problem here is that you have to figure out a decent delegate pattern and route generation pattern.

  • In general, URL crafting is a separate art from domain model crafting, and Rails doesn’t really cater to this. You will have to design URL-centric code to suit your URL crafting.

“Any ideas on ways to performance test IE7?”

No immediate ideas, but potentially more later.

“When users enter very large search parameters for numbers we get the following exception out of RSolr:”

RSolr::RequestError: Solr Response: For_input_string_11111111111111111111__javalangNumberFormatException

Is there an elegant solution to this aside from validating that all input parameters aren’t larger than max int?

Interesting Things

  • When using named scope methods that refer to other named scope methods, you may discover that your SQL has some redundant condition clauses. This is a bug in Rails 2, and has been true for several versions. However, it’s a harmless bug – MySQL will understand the extraneous condition clauses just fine, without performance implications.

  • Mocking Paperclip for tests is a careful art. See our other blog post: Stubbing out Paperclip ImageMagick in Tests

Comments
  1. Stephan says:

    I’m seeing dashes work in routes like this:

    map.route ‘/dashing/:dashed’, :controller => ‘your_controller’, :action => ‘your_action’, :requirements => { :dashed => /[^-]+-[^-]+-[^-]+/ }

    Looks like one would need to parse `params[:dashed]` again in the controller.

    Stephan

  2. Lenary says:

    using Rack::Rewrite could be useful here:

    http://github.com/jtrupiano/rack-rewrite

    you can also pass a proc as the second argument to rewrite or r301 or r302 so that you can contain logic in there that is helpful

    after that you’d probably have to write your own url helpers though

  3. Josh Susser says:

    @Lenary: Rack::Rewrite is one option, but we prefer Pivotal Labs’ own piece of Rack middleware, [Refraction](http://github.com/pivotal/refraction). It’s a much more complete solution, and logic that is ugly in Rack::Rewrite works naturally as regular old Ruby code.

  4. Nathan Wilmes says:

    Our client elected to try this plugin out: http://github.com/norman/friendly_id. They’re happy with it so far.

  5. Chris Bailey says:

    We’ve done a ton with SEO specific URL’s at DealBase. For example, here’s the URL to the Bellagio hotel in Vegas on our site:

    http://www.dealbase.com/Las-Vegas-Strip/Bellagio-hotel-deals-324

    As you’ve discussed above, it’s a real pain in a Rails app. What further complicates this is if you get into pagination. From our understanding, you don’t want to use “?p=3″ or what not like the standard will_paginate uses, because as a query parameter it doesn’t represent properly for SEO. Instead we use /p3. But of course this meant having to change will_paginate, as well as do some tweaks for our AJAX updating of pages (much of the time, we’re just replacing actual listings on a page via AJAX when going to another page of results, instead of refreshing the whole page), but we still have the full URL’s with /p# available too, so that when we build our sitemap files and so on, they are properly indexed, as well as being properly SEO’ed as secondary pages of results and so on.

    Anyway, it’s definitely a painful aspect if you are highly SEO optimized and it kills a lot of the RESTful resource stuff (but that is a small price to pay if your business is improved by having better SEO rankings :)

Post a Comment

Your Information (Name required. Email address will not be displayed with comment.)

* Copy This Password *

* Type Or Paste Password Here *