[DX] Easier template customizing with a query parameter #11327

weaverryan · 2014-07-05T19:41:06Z

Hi guys!

Q	A
Bug fix?	no
New feature?	yes
BC breaks?	no
Deprecations?	no
Tests pass?	yes
Fixed tickets	#7446, #1486
License	MIT
Doc PR	TODO

This follows #7446. Here's a screenshot:

When you click the link, voila! You see your real error template. It works by adding a _real_template=1 query parameter, which the ExceptionController looks for.

The styling is a little rough on the link, as is the text, so I'm open to suggestions.

TODOS

Open up a docs PR once we're settled on approach

Thanks!

…o see the error template

GromNaN · 2014-07-05T21:04:23Z

src/Symfony/Bundle/TwigBundle/Controller/ExceptionController.php

@@ -51,8 +51,14 @@ public function showAction(Request $request, FlattenException $exception, DebugL

        $code = $exception->getStatusCode();

+        // allow the developer to see the real template with ?_real_template=1
+        $debug = $this->debug;


This would be easier to read in 1 line:

$debug = $this->debug && !$request->query->get('_real_template');

this would break the code at line 61

nvm I miseunderstood what you wrote

jakzal · 2014-07-12T08:54:21Z

This will also fix #1486

mpdude · 2014-07-23T19:49:02Z

We've got #7446 and symfony/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?

weaverryan · 2014-07-25T21:20:49Z

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

mpdude · 2014-07-28T20:54:19Z

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?

This *only* shows the "Render True Error Page" if the request is GET. Additionally, it keeps the original query parameters in tact

weaverryan · 2014-08-23T15:55:16Z

@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 :).

weaverryan · 2014-08-23T16:01:40Z

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

I'm sharing the "original" request with ExceptionController
I'm only showing the link for GET requests (POST could be added, but imperfectly I think)
I am keeping any original query params (e.g. ?foo=bar&_real_template=1)
I am showing an alert 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 could never 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" (like WebFactoryExceptionsBundle does)

mpdude · 2014-08-23T18:59:37Z

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 a setDebug() method on the ExceptionController. But I don't think this PR is worth the hassle, especially if it works unreliably and only in certain cases.

weaverryan · 2014-08-23T19:04:29Z

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 like WebfactoryExceptionsBundle were 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.

javiereguiluz · 2014-09-06T10:35:38Z

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 of Render 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.

weaverryan · 2014-09-12T12:59:20Z

@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 this sometimes 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)).

stof · 2014-09-12T13:02:49Z

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

javiereguiluz · 2014-09-12T13:20:15Z

(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.

weaverryan · 2014-09-12T13:59:33Z

@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 we can'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!

mpdude · 2014-09-12T15:11:26Z

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 the default 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

stof · 2014-09-12T15:33:26Z

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

weaverryan · 2014-09-12T15:36:38Z

@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 :).

javiereguiluz · 2014-09-12T15:50:57Z

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

@stof and @weaverryan: if I understood @mpdude correctly, the creators of WebfactoryExceptionsBundle 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?

fabpot · 2014-09-16T05:41:13Z

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.)

mpdude · 2014-09-16T10:23:37Z

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

weaverryan · 2014-09-22T16:08:45Z

@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, it might still be merged for 2.6, which I would personally love :). About the improved error page you listed, I would not do it, just to include less changes and thus improve the chances of merging quickly. We can certainly bring up that topic separately.

Thanks!

mpdude · 2014-09-23T15:39:56Z

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?

fabpot · 2014-09-24T05:47:03Z

@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.

mpdude · 2014-10-02T11:51:01Z

See #12096.

fabpot · 2014-10-03T11:34:42Z

Closing in favor of #12109

…de (mpdude) This PR was squashed before being merged into the 2.6-dev branch (closes #12096). Discussion ---------- Add an action to show *error* pages in kernel.debug mode | Q | A | ------------- | --- | Bug fix? | no | New feature? | yes | BC breaks? | no | Deprecations? | no | Tests pass? | yes | Fixed tickets | #7446, #1486, #11327 | License | MIT | Doc PR | symfony/symfony-docs#4293 See #7446 for the initial reasoning. In short, add to your `routing_development.yml` file the following ```yaml _errors: resource: "@TwigBundle/Resources/config/routing/errors.xml" prefix: /_error ``` Then you can use `http://localhost/app_dev.php/_error/xxx` to preview the HTML *error* page that the default `ExceptionController` (from `TwigBundle`) would pick for the XXX status code. You can also use `http://localhost/app_dev.php/_error/xxx.{some_format}` to show error pages for other formats than HTML, most notably `txt`. Note that the status code will be 500 for all exceptions [that do not implement `HttpExceptionInterface`](https://github.com/symfony/symfony/blob/master/src/Symfony/Component/Debug/Exception/FlattenException.php#L47). ##### Want to test with a custom exception? ~~Folks might want to display (part of) the exception even on error pages and thus need to work with generic (own) exceptions.~~ ~~They could write an arbitrary controller and throw their exception there. By default, the `ExceptionController` would be used to handle this, only that it would not show *error* pages in `kernel.debug` mode.~~ ~~Thus, a simple public setter to change the `debug` flag after construction could help. Do we want to add that as well?~~ If you want to test error pages with your own exceptions, * create a subclass of `ExceptionController` * set the protected `debug` flag to false * register it as twig.exception_controller in the config * throw your custom exception from any controller. That should give you the error page also in `kernel.debug` mode. ##### To-Do - [x] Update docs - [x] Add route in symfony/symfony-default Commits ------- 66ed177 Add an action to show *error* pages in kernel.debug mode

Adding the capability to add ?_real_template=1 to an exception page t…

56809cd

…o see the error template

GromNaN reviewed Jul 5, 2014
View reviewed changes

romainneutron added the TwigBundle label Jul 12, 2014

wouterj mentioned this pull request Jul 23, 2014

[2.2] Allow toggling between production and development error pages... #1486

Closed

Padding "original_request" to the exception controller and using it

afa16cb

This *only* shows the "Render True Error Page" if the request is GET. Additionally, it keeps the original query parameters in tact

weaverryan changed the title ~~Easier template customizing with a query parameter~~ [DX] Easier template customizing with a query parameter Sep 12, 2014

mpdude mentioned this pull request Oct 2, 2014

Add an action to show *error* pages in kernel.debug mode #12096

Closed

2 tasks

fabpot closed this Oct 3, 2014

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

[DX] Easier template customizing with a query parameter #11327

[DX] Easier template customizing with a query parameter #11327

weaverryan commented Jul 5, 2014

GromNaN Jul 5, 2014

romainneutron Jul 15, 2014

romainneutron Jul 15, 2014

jakzal commented Jul 12, 2014

mpdude commented Jul 23, 2014

weaverryan commented Jul 25, 2014

mpdude commented Jul 28, 2014

weaverryan commented Aug 23, 2014

weaverryan commented Aug 23, 2014

mpdude commented Aug 23, 2014

weaverryan commented Aug 23, 2014

javiereguiluz commented Sep 6, 2014

weaverryan commented Sep 12, 2014

stof commented Sep 12, 2014

javiereguiluz commented Sep 12, 2014

weaverryan commented Sep 12, 2014

mpdude commented Sep 12, 2014

stof commented Sep 12, 2014

weaverryan commented Sep 12, 2014

javiereguiluz commented Sep 12, 2014

fabpot commented Sep 16, 2014

mpdude commented Sep 16, 2014

weaverryan commented Sep 22, 2014

mpdude commented Sep 23, 2014

fabpot commented Sep 24, 2014

mpdude commented Oct 2, 2014

fabpot commented Oct 3, 2014

[DX] Easier template customizing with a query parameter #11327

[DX] Easier template customizing with a query parameter #11327

Conversation

weaverryan commented Jul 5, 2014

GromNaN Jul 5, 2014

Choose a reason for hiding this comment

romainneutron Jul 15, 2014

Choose a reason for hiding this comment

romainneutron Jul 15, 2014

Choose a reason for hiding this comment

jakzal commented Jul 12, 2014

mpdude commented Jul 23, 2014

weaverryan commented Jul 25, 2014

mpdude commented Jul 28, 2014

weaverryan commented Aug 23, 2014

weaverryan commented Aug 23, 2014

mpdude commented Aug 23, 2014

weaverryan commented Aug 23, 2014

javiereguiluz commented Sep 6, 2014

weaverryan commented Sep 12, 2014

stof commented Sep 12, 2014

javiereguiluz commented Sep 12, 2014

weaverryan commented Sep 12, 2014

mpdude commented Sep 12, 2014

stof commented Sep 12, 2014

weaverryan commented Sep 12, 2014

javiereguiluz commented Sep 12, 2014

fabpot commented Sep 16, 2014

mpdude commented Sep 16, 2014

weaverryan commented Sep 22, 2014

mpdude commented Sep 23, 2014

fabpot commented Sep 24, 2014

mpdude commented Oct 2, 2014

fabpot commented Oct 3, 2014