This will also fix#1486

We've got#7446 andsymfony/symfony-docs#3577 for testing/designing the error page templates themselves and maybe that could move closer to "core".

But what's the use case for applying the error page template to "real" exceptions you get in kernel.debug=true?

@mpdude I don't understand your question (about the use case) - can you ask it again?

Well, what I was trying to say:

#7446 is about seeing/testing error pages in kernel.debug mode. It was opened by a colleague of mine (ping@perbernhardt) and I think is resolved by WebfactoryExceptionsBundle. That even made it into the docs (symfony/symfony-docs#3577), but I would not mind seeing it (or parts of it) being moved closer to the Symfony core. Especially a setter for the debug flag on the ExceptionController would be helpful.

The idea of re-submitting the request comes from#1486. I don't really get the OP's idea there, but in#1486 (comment)@stof wrote that it was about pre-viewing the (user-facing) error pages during development as well.

So, when would you want to use this "toggle"-link? To preview the error page?

@mpdude The use-case for this is exactly what you were going for originally: to get "easy error template customization" into core. Adding your bundle as a recommendation to the docs was done because it was something we could do very easily to help people. But since they still need to install and configure a bundle, core would be ideal :).

I've updated the PR, here are some highlights:

1. I'm sharing the "original" request with ExceptionController
2. I'monly showing the link for GET requests (POST could be added, but imperfectly I think)
3. Iam keeping any original query params (e.g.?foo=bar&_real_template=1)
4. I am showing analert message when clicking the link with a URL to the docs page in case you don't actually see an error template next

The biggest issue is that we simply couldnever guarantee that the same exception will be triggered on the next page. It probably will be in 99.9% of the cases, but not always.

So, do we say:

A) "Yay, this is good enough!".
Or
B) "forget trying to recreate the original exception, let's just make it possible for the use to surf to a new page that renders the 404, 403, etc templates" (likeWebFactoryExceptionsBundle does)

I'd say "B" (sorry).

Your page design/UX team needs to be able to write and see error pages when in development - when Assetic re-compiles assets, twig templates are re-compiled and so forth. This is what WebfactoryExceptionsBundle was written for.

On the other hand, a "real" developer is happy to get the great and helpful exception pages during development. I don't see why she would want to switch over to error pages for arbitrary exceptions. Also most of the time the error pages won't convey any information useful for a developer at all, right?

I'd be happy if WebfactoryExceptionsBundle would move closer to core, especially with asetDebug() method on theExceptionController. But I don't think this PR is worth the hassle, especially if it works unreliably and only in certain cases.

I tend to agree with@mpdude. I would rather say "go these these 3 URLs to customize the 403, 404 and 500 error pages" then try to tell them to go to different URLs that will trigger those errors, then click this link.

If something likeWebfactoryExceptionsBundlewere in core, we could still have this nice link as a convenience (but it would just take you to the special URL that displays the error template for the correct status code, not a refresh like I'm doing now).

This idea has gotten voted down before, but it makes sense to me.

I really like this PR and I'd love to see it merged for 2.6.@weaverryan do we know what's preventing us from finishing or merging this PR?

As a side note, instead ofRender True Error Page, we could use a more friendly label, such as:View this error as a visitor,View this error as a user, etc.

@javiereguiluz Thanks for following up! I want to see this idea move quickly, however it's implemented. Here is the only problem:

The query parameter idea will always be imperfect. It won't work for POST requests, and even for GET requests, there's the edge case that whatever exception just happened, won't happen on the next request. We either need to be ok with the edge case of thissometimes not actually showing you the error page, or find a different solutions.

So, we could either be (A) ok with this idea (it's working nicely), or (B) implement something (i.e. an internal route) that allows a user to surf to some URL to see 400, 403, 404, 500, etc error templates.

More than anything, I'd like to see one of these done. (B) was somewhat popular in an earlier issue, but at least back then,@stof didn't prefer it (#7446 (comment)).

Well, actually, I like the idea of resending the request a second time (hoping it triggers the same exception again) even less.

the complex part for the dedicated endpoint is that you might need to be able to render the error page not only for specific status codes of the HttpException, but also for other exceptions which might get a special treatment by a different listener on kernel.exception

(A) seems like a good enough option. Can we hide the link when we know for sure that it's not going to work? I'd prefer not to confuse developers.

@javiereguiluz We can (and I'm doing this now) hide the link for POST requests, which would be the most common (by far) where it probably wouldn't work. For all the other cases, we don't know if it'll work or not.

@stof Even though I opened this PR, I also like (B) better than (A). The biggest reason is that it's difficult to explain to a designer how to find a page with a 403 or 500 error. But saying "go to /_errors/404" and "go to /_errors/500" is quite easy.

If you have more a more complex scenario where you have some custom event handling, then there's obviously no way that we can help you. But fortunately, those users are probably already more advanced, and have a better understanding of how to develop their error templates. I don't want the fact that we can't help out these more advanced use-cases mean that wecan't offer this feature to the vast majority of developers who aren't doing something more advanced.

And if we did (B), we could still have a nice link on the error page. In fact, if you're doing some custom exception handling, you wouldn't see this page/link anyways, which is kind of nice: advanced use-cases wouldn't see a link inviting them to see the error template.

Thanks!

The biggest reason is that it's difficult to explain to a designer how to find a page with a 403 or 500 error. But saying "go to /_errors/404" and "go to /_errors/500" is quite easy.

Exactly that was the intention we had with webfactory/exceptions-bundle: Provide front-end designers with a simple, well-known entry point for designing the error pages.

Plus, some default building blocks for those pages that lead to more helpful (end-user friendly) error messages than thedefault page.

If you guys like what our bundle is doing, we'd be super-proud to craft a PR to get it merged into core.

/cc@MalteWunsch and@sebastiankugler please subscribe to this issue

the next question is whether we integrate WebfactoryExceptionsBundle in core, or whether we recommend this bundle in the doc, letting the guys from webfactory maintain the bundle

@stof We're already recommending it in the docs, so that's good at least. My vote would be to not make people need to install a bundle to have this functionality. That's subjective of course :).

I agree with@weaverryan: forcing to install a bundle for this is too much.

@stof and@weaverryan: if I understood@mpdude correctly, the creators ofWebfactoryExceptionsBundle kindly offer themselves to prepare a PR to integrate its code in the Symfony core and stop developing the bundle.

Given that the amount of code of the bundle is really small, that they are willing to do the integration part and that this is a feature loved by lots of people, what's your opinion?

My 2 cents here: I think (B) is far a better option. IIUC, (A) would not work when GET requests have some kind of side effects (which should not happen anyway.)

After looking at the code of the bundle and knowing that@mpdude has already contributed a lot to Symfony core, I'm in favor of moving the code into core (but not in a new bundle.) If that happens, I don't really see the value of this PR anymore (but I'm also fine if others thinks it adds value.)

@fabpot would you also support the improved error pages that are part of the bundle?

@mpdude I don't know if it's possible, but if you have time, this is the last week before the 2.6 feature freeze. If you're able to make a PR quickly, itmight still be merged for 2.6, which I would personally love :). About the improved error page you listed, I wouldnot do it, just to include less changes and thus improve the chances of merging quickly. We can certainly bring up that topic separately.

Thanks!

I am on vacation till sunday and cannot work on this until then. I could try to brief my fellow@MalteWunsch and maybe he could help out, but you seem not so sure about whether this would be merged so quickly at all?

@mpdude We are able to merge PRs like this one until the end of next week and I will merge PRs that are ready and reviewed as fast as possible to meet the deadline.

See#12096.

Closing in favor of#12109