| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
|
|
|
| |
this makes scope rollback much easier
|
|
|
|
| |
we can `super` in to the previous implementation.
|
|
|
|
|
| |
we already know what helpers are path helpers, so just iterate through
that list and define the helpers with warnings
|
| |
|
|
|
|
|
| |
this lets us avoid hard coding a regexp for separating path and url
helpers in the clear! method.
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
Email does not support relative links since there is no implicit host. Therefore all links inside of emails must be fully qualified URLs. All path helpers are now deprecated. When removed, the error will give early indication to developers to use `*_url` methods instead.
Currently if a developer uses a `*_path` helper, their tests and `mail_view` will not catch the mistake. The only way to see the error is by sending emails in production. Preventing sending out emails with non-working path's is the desired end goal of this PR.
Currently path helpers are mixed-in to controllers (the ActionMailer::Base acts as a controller). All `*_url` and `*_path` helpers are made available through the same module. This PR separates this behavior into two modules so we can extend the `*_path` methods to add a Deprecation to them. Once deprecated we can use this same area to raise a NoMethodError and add an informative message directing the developer to use `*_url` instead.
The module with warnings is only mixed in when a controller returns false from the newly added `supports_relative_path?`.
Paired @sgrif & @schneems
|
|
|
|
|
|
|
| |
This reverts commit f632f79b8dcd144408c66a544984b2ba9cf52f87, reversing
changes made to 98c7fe87690ca4de6c46e8f69806e82e3f8af42d.
Closes #16343
|
|
|
|
| |
use helpers.include? so we don't get any false positives
|
|
|
|
|
| |
we should not be accessing internals to figure out if a method is
defined.
|
|
|
|
|
| |
since helpers is a set, we can be confident about when to remove methods
from the module.
|
|
|
|
| |
after this, we can disconnect @module from the instance
|
|
|
|
| |
we can cache the module on the stack, then reuse it
|
| |
|
|
|
|
|
| |
we know the routes should not be "optimized" when mounting an
application
|
|
|
|
|
| |
this caching doesn't increase performance, but does increase complexity.
remove it for now and find better ways to speed up this code.
|
|\
| |
| |
| | |
remove empty unused method
|
| | |
|
|/ |
|
|
|
|
| |
[ci skip]
|
| |
|
|
|
|
| |
See https://github.com/rails/rails/pull/16234#commitcomment-7115670.
|
| |
|
| |
|
|
|
|
| |
Fixes https://github.com/rails/rails/issues/16119.
|
|\
| |
| |
| |
| | |
Conflicts:
actionpack/test/abstract_unit.rb
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
We are planning to remove mocha from our test suite because of
performance problems. To make this possible we should stop require mocha
on ActionSupport::TestCase.
This should not affect applications since users still need to add mocha
to Gemfile and this already load mocha.
Added FIXME notes to place that still need mocha removal
|
|\ \
| | |
| | | |
Fixes to request method test.
|
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
Since we're stubbing the request, the test is actually just asserting
that `@method = env['REQUEST_METHOD']`. In order to the test against
the methodoverride middleware, we should test it against an actual
request. However, Rack is already covering this scenario so we can
remove this test.
|
| | |
| | |
| | |
| | |
| | | |
There is already another test covering Request#request_method. This
test should cover Request#method.
|
| | | |
|
| |/
| |
| |
| |
| | |
The current test is asserting against an outdated version of
Request#method where HEAD requests are treated as GET requests.
|
| |
| |
| |
| |
| |
| |
| | |
Also cleanup test a bit
[related #14886]
[related #14743]
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
The entire 127.0.0.0/8 range is assigned to the loopback address, not
only 127.0.0.0/24. This patch allows ActionDispatch::Request::LOCALHOST
to match any IPv4 127.0.0.0/8 loopback address.
The only place that the #local? method was previously under test was
in the show_expectations_test.rb file. I don't particularly like that
that's implicitly where this code is under test, and I feel like I
should move some of that testing code into the
test/dispatch/request_test.rb file, but I wanted some feedback first.
Credit goes to @sriedel for discovering the issue and adding the
patch.
|
| |
| |
| |
| |
| |
| |
| |
| | |
The Logger by default includes a guard which checks for the
logging level. By removing the custom logging guards, we can decouple
the logging guard from the logging action to be done.
This also follows the good practice listed on http://guides.rubyonrails.org/debugging_rails_applications.html#impact-of-logs-on-performance.
|
| |
| |
| |
| | |
(I think)
|
| |
| |
| |
| |
| |
| | |
this prevents the array from being dumped as a DRbObject so we can
reduce communication with the server. the reporter should always exist
on the server side, so we don't have to worry about GC
|
| | |
|
| | |
|
| | |
|
| |
| |
| |
| |
| | |
only on forking systems though. Feel free to revert this if it causes
problems.
|
| |
| |
| |
| |
| |
| |
| |
| | |
"recall" is a terrible name. This variable contains the parameters that
we got from the path (e.g. for "/posts/1" it has :controller => "posts",
:id => "1"). Since it contains the parameters we got from the path,
"path_parameters" is a better name. We always pass path_parameters to
`generate`, so lets make it required.
|
| |
| |
| |
| |
| | |
this allows us to avoid 2 hash allocations per named helper definition,
also we can avoid a `merge` and `delete`.
|
| |
| |
| |
| |
| |
| | |
since we know that the route should be a path or fully qualified, we can
pass a strategy object that handles generation. This allows us to
eliminate an "if only_path" branch when generating urls.
|
| |
| |
| |
| |
| | |
also if you want a path from a named helper, you should call
helper_path, not helper_url(:only_path => true).
|
| | |
|
| | |
|
| | |
|
| | |
|