You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
feature #58769 [ErrorHandler] Add a command to dump static error pages (pyrech)
This PR was squashed before being merged into the 7.3 branch.
Discussion
----------
[ErrorHandler] Add a command to dump static error pages
| Q | A
| ------------- | ---
| Branch? | 7.3
| Bug fix? | no
| New feature? | yes
| Deprecations? | no
| Issues | -
| License | MIT
<!--
Replace this notice by a description of your feature/bugfix.
This will help reviewers and should be a good start for the documentation.
Additionally (see https://symfony.com/releases):
- Always add tests and ensure they pass.
- Bug fixes must be submitted against the lowest maintained branch where they apply
(lowest branches are regularly merged to upper ones so they get the fixes too).
- Features and deprecations must be submitted against the latest branch.
- For new features, provide some code snippets to help understand usage.
- Changelog entry should follow https://symfony.com/doc/current/contributing/code/conventions.html#writing-a-changelog-entry
- Never break backward compatibility (see https://symfony.com/bc).
-->
When a web server cannot handle a request or trigger an error without calling the PHP application, it will return instead its default error pages, ignoring completly the error templates defined by the application (Symfony's default "Oops" error page or overriden one in user's app).
Take for example the case of the simple `/%` url : it will trigger an error on almost all web servers (nginx, apache, cloudflare, etc):
- [https://symfony.com/%](https://symfony.com/%)
- [https://api-platform.com/%](https://api-platform.com/%)
- [https://www.cloudflare.com/%](https://www.cloudflare.com/%)
- [https://www.clever-cloud.com/%](https://www.clever-cloud.com/%)
In all these cases, web servers returned their default error page.
To avoid that, in some of our projects, we created a Symfony command to dump the application error pages in static HTML files that the web server can render when it encounters an internal error. The idea is to dump these pages at deploy time so there is nothing else to do at runtime.
Here is a sample on how we configured our nginx to use our beautiful error pages:
```
error_page 400 /error_pages/400.html;
error_page 401 /error_pages/401.html;
# ...
error_page 510 /error_pages/510.html;
error_page 511 /error_pages/511.html;
location ^~ /error_pages/ {
root /path/to/your/symfony/var/cache/error_pages;
internal; # allows this location block to not be triggered when a user manually call these /error_pages/.* urls
}
```
(Kudos to `@xavierlacot` for all the hard work and researches on this topic 💛)
We propose to add this command directly to Symfony so everybody can make use of it.
### Usage
```bash
bin/console error:dump var/cache/prod/error_page [--force] [400 401 ... 511]
```
Commits
-------
37fe14b0244 [ErrorHandler] Add a command to dump static error pages
0 commit comments