| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| | |
|
| |
|
|
|
|
|
|
|
| |
When someone gets a routing exception, the routes are rendered (starting in Rails 4.0). This PR brings parity between the html routes in the `rails/info/routes` path and when rendered from an exception. This is the continuation of #8521 which brought html formatted routes.
In addition to bringing parity to the two views, we're keeping our views DRY by rendering off of the same partials. In this case Railties depends on partials provided by ActionDispatch. I'm open to alternative implementations. Ideally both views will use the same code so any improvements or updates to it will be reproduced on both.
<hr />
|
| | |
|
| |
|
|
| |
If someone receives a routing error, they likely need to view the routes. Rather than making them visit '/rails/info/routes' or run `rake routes` we can give them that information on the page.
|
| |
|
|
|
|
| |
If a user gets a routing error due to a view helper such as using user_path without an :id they must go to their logs to see the backtrace. By adding in the trace template, a user can see which line the error occurred on without leaving the browser.
When a routing error occurs outside of the view the application trace will be blank and will not confuse developers.
|
| |
|
|
|
|
| |
When a newcomer hits the routing error page they
are often confused about how to trouble shoot the
next step. Adding a simple help text can gently
remind coders where to get more help.
|
|
|
middleware.
This commit breaks all exception catching plugins like ExceptionNotifier. These plugins should be rewritten as middleware instead overriding Controller#rescue_action_in_public.
|
