Module: FriendlyId::Base

Configure FriendlyId's behavior in a model.

class Post < ActiveRecord::Base
  extend FriendlyId
  friendly_id :title, :use => :slugged
end

When given the optional block, this method will yield the class's instance of Configuration to the block before evaluating other arguments, so configuration values set in the block may be overwritten by the arguments. This order was chosen to allow passing the same proc to multiple models, while being able to override the values it sets. Here is a contrived example:

$friendly_id_config_proc = Proc.new do |config|
  config.base = :name
  config.use :slugged
end

class Foo < ActiveRecord::Base
  extend FriendlyId
  friendly_id &$friendly_id_config_proc
end

class Bar < ActiveRecord::Base
  extend FriendlyId
  friendly_id :title, &$friendly_id_config_proc
end

However, it's usually better to use FriendlyId.defaults for this:

FriendlyId.defaults do |config|
  config.base = :name
  config.use :slugged
end

class Foo < ActiveRecord::Base
  extend FriendlyId
end

class Bar < ActiveRecord::Base
  extend FriendlyId
  friendly_id :title
end

In general you should use the block syntax either because of your personal aesthetic preference, or because you need to share some functionality between multiple models that can't be well encapsulated by FriendlyId.defaults.

Order Method Calls in a Block vs Ordering Options

When calling this method without a block, you may set the hash options in any order.

However, when using block-style invocation, be sure to call FriendlyId::Configuration's use method prior to the associated configuration options, because it will include modules into your class, and these modules in turn may add required configuration options to the @friendly_id_configuraton's class:

class Person < ActiveRecord::Base
  friendly_id do |config|
    # This will work
    config.use :slugged
    config.sequence_separator = ":"
  end
end

class Person < ActiveRecord::Base
  friendly_id do |config|
    # This will fail
    config.sequence_separator = ":"
    config.use :slugged
  end
end

Including Your Own Modules

Because :use can accept a name or a Module, defaults can be a convenient place to set up behavior common to all classes using FriendlyId. You can include any module, or more conveniently, define one on-the-fly. For example, let's say you want to make Babosa the default slugging library in place of Active Support, and transliterate all slugs from Russian Cyrillic to ASCII:

require "babosa"

FriendlyId.defaults do |config|
  config.base = :name
  config.use :slugged
  config.use Module.new {
    def normalize_friendly_id(text)
      text.to_slug.normalize(:transliterations => [:russian, :latin])
    end
  }
end