| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
|
|
|
|
| |
This will make easier to applications that rely on having const_missing
hooks in production upgrade to Rails 5.
This option is going to be remove in the future and the default behavior
will be to disable the dependency loading.
|
| |
|
|
|
|
|
|
| |
The /rails/info routes were inaccessible in apps with a catch-all
globbing route, as they were being appended after the globbing route and
would never be matched.
See also ccc3ddb7762bae0df7e2f8d643b19b6a4769d5be.
|
| |
|
|
| |
http://edgeguides.rubyonrails.org/api_documentation_guidelines.html#english
|
| |
|
|
| |
Also, make sure to call the +complete+ hooks if +run+ fails.
|
| |
|
|
|
|
| |
These should allow external code to run blocks of user code to do
"work", at a similar unit size to a web request, without needing to get
intimate with ActionDipatch.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
This is meant to provide a way for Action Cable, Sprockets, and possibly
other Rack applications to mark themselves as internal, and to exclude
themselves from the routing inspector, and thus `rails routes` / `rake
routes`.
I think this is the only way to have mounted Rack apps be marked as
internal, within AD/Journey. Another option would be to create an array
of regexes for internal apps, and then to iterate over that everytime a
request comes through. Also, I only had the first `add_route` method set
`internal`'s default to false, to avoid littering it all over the
codebase.
|
| |
|
|
|
|
| |
We mostly care about `reload_classes_only_on_change=true`, because
that's the default... and there, we definitely need to wait for the lock
when necessary.
|
| |
|
|
|
|
|
|
|
|
|
|
| |
Specifically, the "loose upgrades" behaviour that allows us to obtain an
exclusive right to load things while other requests are in progress (but
waiting on the exclusive lock for themselves) prevents us from treating
load & unload interchangeably: new things appearing is fine, but they do
*not* expect previously-present constants to vanish.
We can still use loose upgrades for unloading -- once someone has
decided to unload, they don't really care if someone else gets there
first -- it just needs to be tracked separately.
|
| | |
|
| |
|
|
| |
This reverts commit a8bf12979e5fa15282b39c8cfa315e663f613539.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Adds `config.action_mailer.preview_enabled`
This allows mail previewing to be enabled easily in non-development
environments such as staging. The default is set to true for development
so no changes should be required to existing Rails applications.
The mail preview path can still be configured using the existing
`config.action_mailer.preview_path` configuration option.
Adding this avoids devs from having to do stuff like:
https://gist.github.com/lengarvey/fa2c9bd6cdbeba96526a
Update actionmailer/CHANGELOG with new configuration.
Update configuring guide with new configuratation.
Add `config.action_mailer.preview_path` to configuring guide.
|
| | |
|
| |
|
|
|
|
|
|
| |
Showing welcome page in production can expose information, which should
not be visible on production if people don't override the default root
route.
This reverts commit b0caea29c2da9f4c8bb958019813482da297067d.
|
| |
|
|
|
|
|
| |
With Rails 4 the default index page was moved from a static file `index.html` inside the `public/` folder to an internal controller/view inside of the railties gem. This was to allow use of erb in the default index page and to remove the requirement that new apps must delete a static file to make their index pages work. While this was a good change, the functionality was unexpected to developers who wish to get their apps running in production ASAP. They will create a new app `rails new my app`, start a server to verify it works, then immediately deploy the app to verify that it can start working in production. Unfortunately locally they see a page when they visit `localhost:3000` when they visit their production app they get an error page.
We initially anticipated this problem in the original pull request, but did not properly anticipate the severity or quantity of people who would like this functionality. Having a default index page serves as an excellent litmus test for a passed deploy on default apps, and it is very unexpected to have a page work locally, but not on production.
This change makes the default index page available in production if the developer has not over-written it by defining their own `root` path inside of routes.
|
| |
|
|
|
| |
Conflicts:
railties/test/application/loading_test.rb
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Whilst autoloading is known to be not threadsafe, leaving it in place
is a softer solution than failing hard when an application is deployed.
Many older applications will have paths added to `autoload_paths` and
ideally these should be eagerly loaded to be threadsafe. However one
of these paths is quite often lib which could lead to unintended
consequences due to the 'junk drawer' nature of this directory.
Developers should refrain from adding paths to `autoload_paths` or
`eager_load_paths` and use custom folders inside app for code that
needs to be eagerly loaded and use `require` or `require_dependency`
to explicitly load code from other locations.
|
| |
|
|
| |
with Rails 4.0.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This is an alternative implementation to #7771 thanks to the advice of @spastorino
Rails is a dynamic framework that serves a static index.html by default. One of my first questions ever on IRC was solved by simply deleting my public/index.html file. This file is a source of confusion when starting as it over-rides any set "root" in the routes yet it itself is not listed in the routes. By making the page dynamic by default we can eliminate this confusion.
This PR moves the static index page to an internal controller/route/view similar to `rails/info`. When someone starts a rails server, if no root is defined, this route will take over and the "dynamic" index page from rails/welcome_controller will be rendered. These routes are only added in development. If a developer defines a root in their routes, it automatically takes precedence over this route and will be rendered, with no deleting of files required.
In addition to removing this source of confusion for new devs, we can now use Rails view helpers to build and render this page. While not the primary intent, the added value of "dogfooding" should not be under-estimated.
The prior PR #7771 had push-back since it introduced developer facing files. This PR solves all of the same problems, but does not have any new developer facing files (it actually removes one).
cc/ @wsouto, @dickeyxxx, @tyre, @ryanb, @josevalim, @maxim, @subdigital, @steveklabnik
ATP Railties and Actionpack.
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
|
| |
The reason the test was failing was because when the test
invokes `app.config`, the app is loaded and, as `eager_load`
is set to true, it disables the dependency loading mechanism,
so controllers that are later defined are not loaded.
|
| |
|
|
|
|
|
| |
The new option allows any Ruby namespace to be registered and set
up for eager load. We are effectively exposing the structure existing
in Rails since v3.0 for all developers in order to make their applications
thread-safe and CoW friendly.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Previously, the eager load behavior was mostly coupled to
config.cache_classes, however this was suboptimal since in
some environments a developer may want to cache classes but
not necessarily load them all on boot (for example, test env).
This pull request also promotes the use of config.eager_load
set to true by default in production. In the majority of the
cases, this is the behavior you want since it will copy most
of your app into memory on boot (which was also the previous
behavior).
Finally, this fix a long standing Rails bug where it was
impossible to access a model in a rake task when Rails was
set as thread safe.
|
| |
|
|
| |
Will show similar contents to the output of `$ rake routes` in the browser in development. This speeds the time required to generate routes, since the application is already initialized.
|
| |
|
|
|
|
| |
Also make sure to not use default queue consumer with custom queue
implementation. It is up to the new queue implementation to
start / shutdown the consumer.
|
| |
|
|
| |
consumers around stdlib's Queue
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
In the current router DSL, using the +match+ DSL
method will match all verbs for the path to the
specified endpoint.
In the vast majority of cases, people are
currently using +match+ when they actually mean
+get+. This introduces security implications.
This commit disallows calling +match+ without
an HTTP verb constraint by default. To explicitly
match all verbs, this commit also adds a
:via => :all option to +match+.
Closes #5964
|
| |
|
|
|
| |
of $rails_rake_task if it is already set.
Fixes #4591.
|
| |
|
|
| |
reload_classes_only_on_change schema.
|
| | |
|
| | |
|
| |
|
|
| |
replaced).
|
| |
|
|
|
|
|
|
|
|
| |
This reverts commit c2e3ce8d1e1174e66536d59d8d97eb2cc8ce6f25.
Conflicts:
railties/lib/rails/application/configuration.rb
railties/lib/rails/application/finisher.rb
railties/lib/rails/engine.rb
|
| |
|
|
|
|
|
|
| |
This can be turned off by setting `config.reload_classes_only_on_change` to false.
Extensions like Active Record should add their respective files like db/schema.rb and db/structure.sql to `config.watchable_files` if they want their changes to affect classes reloading.
Thanks to https://github.com/paneq/active_reload and Pastorino for the inspiration. <3
|
| | |
|
| | |
|
| |
|
|
| |
app_reloader_hooks.
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
