This was only needed due to https://github.com/rails/rails/blob/6591a10b1f6eccc91bc01ab708050884058e9665/railties/lib/rails/console_app.rb#L6 We don't need that on master. Fixes #6907.
When you mount your application at a path, for example /myapp, server should set SCRIPT_NAME to /myapp. With such information, rails application knows that it's mounted at /myapp path and it should generate routes relative to that path. Before this patch, rails handled SCRIPT_NAME correctly only for regular apps, but it failed to do it for mounted engines. The solution was to hardcode default_url_options[:script_name], which is not the best answer - it will work only when application is mounted at a fixed path. This patch fixes the situation by respecting original value of SCRIPT_NAME when generating application's routes from engine and the other way round - when you generate engine's routes from application. This is done by using one of 2 pieces of information in env - current SCRIPT_NAME or SCRIPT_NAME for a corresponding router. This is because we have 2 cases to handle: - generating engine's route from application: in this situation SCRIPT_NAME is basically SCRIPT_NAME set by the server and it indicates the place where application is mounted, so we can just pass it as :original_script_name in url_options. :original_script_name is used because if we use :script_name, router will ignore generating prefix for engine - generating application's route from engine: in this situation we already lost information about the SCRIPT_NAME that server used. For example if application is mounted at /myapp and engine is mounted at /blog, at this point SCRIPT_NAME is equal /myapp/blog. Because of that we need to keep reference to /myapp SCRIPT_NAME by binding it to the current router. Later on we can extract it and use when generating url Please note that starting from now you *should not* use default_url_options[:script_name] explicitly if your server already passes correct SCRIPT_NAME to rack env. (closes #6933)
It's not really a good idea to have this as a global config option. We should allow people to specify the behaviour per association. There will now be two new values: * :dependent => :restrict_with_exception implements the current behaviour of :restrict. :restrict itself is deprecated in favour of :restrict_with_exception. * :dependent => :restrict_with_error implements the new behaviour - it adds an error to the owner if there are dependent records present See #4727 for the original discussion of this.
…tion called out at the top level
…some basic data". I dont consider this something most people is going to want most of the time. If you want to add it in your own app, knock yourself out. But it doesnt belong in Rails imo
…fined by Active Support) Selecting which key extensions to include in active_support/rails made apparent the systematic usage of Object#in? in the code base. After some discussion in 5ea6b0d we decided to remove it and use plain Ruby, which seems enough for this particular idiom. In this commit the refactor has been made case by case. Sometimes include? is the natural alternative, others a simple || is the way you actually spell the condition in your head, others a case statement seems more appropriate. I have chosen the one I liked the most in each case.
The Inflector is currently not very supportive of internationalized websites. If a user wants to singularize and/or pluralize words based on any locale other than English, they must define each case in locale files. Rather than create large locale files with mappings between singular and plural words, why not allow the Inflector to accept a locale? This patch makes ActiveSupport::Inflector locale aware and uses `:en`` unless otherwise specified. Users will still be provided a list of English (:en) inflections, but they may additionally define inflection rules for other locales. Each list is kept separately and permanently. There is no reason to limit users to one list of inflections: ActiveSupport::Inflector.inflections(:es) do |inflect| inflect.plural(/$/, 's') inflect.plural(/([^aeéiou])$/i, '\1es') inflect.plural(/([aeiou]s)$/i, '\1') inflect.plural(/z$/i, 'ces') inflect.plural(/á([sn])$/i, 'a\1es') inflect.plural(/é([sn])$/i, 'e\1es') inflect.plural(/í([sn])$/i, 'i\1es') inflect.plural(/ó([sn])$/i, 'o\1es') inflect.plural(/ú([sn])$/i, 'u\1es') inflect.singular(/s$/, '') inflect.singular(/es$/, '') inflect.irregular('el', 'los') end 'ley'.pluralize(:es) # => "leyes" 'ley'.pluralize(:en) # => "leys" 'avión'.pluralize(:es) # => "aviones" 'avión'.pluralize(:en) # => "avións" A multilingual Inflector should be of use to anybody that is tasked with internationalizing their Rails application. Signed-off-by: David Celis <firstname.lastname@example.org>
Closes #7110 there's more work to do on rack-cache issue 69
This allows us to do: In your configuration: Rails.queue[:image_queue] = SomeQueue.new Rails.queue[:mail_queue] = SomeQueue.new In your app code: Rails.queue[:mail_queue].push MailJob.new Both jobs pushed to the same default queue Rails.queue.push DefaultJob.new Rails.queue[:default].push DefaultJob.new
This applies to the following helpers: `button_to` `button_tag` `image_submit_tag` `link_to` `submit_tag`
Changes introduced in 7404cda. Fix railties build.
Last versions of Turn don't monkey patch MiniTest to setup the natural language option. Here is an [example](https://github.com/TwP/turn/blob/master/try/test_autorun_minitest.rb#L3). This patches the following behaviour: $ rake test:units `<top (required)>': undefined method `use_natural_language_case_names=' for MiniTest::Unit:Class (NoMethodError)
…st_helper.rb to reflect that