Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[6.0] Restore the exception's messages #29775

Closed
wants to merge 1 commit into from

Conversation

Bouhnosaure
Copy link

This PR resolves #29774

By adding the same behavior as the 403.blade.php and the 503.blade.php in the following files :

  • 401.blade.php
  • 404.blade.php
  • 419.blade.php
  • 429.blade.php
  • 500.blade.php

The goal is to have the same behavior for the abort() method

@GrahamCampbell GrahamCampbell changed the title Restore the exception's messages [6.0] Restore the exception's messages Aug 28, 2019
@GrahamCampbell
Copy link
Member

Hmm. Do we always want the user to see the message?

@GrahamCampbell
Copy link
Member

Maybe we should only show the message for exceptions that implement HttpExceptionInterface.

@Bouhnosaure
Copy link
Author

Bouhnosaure commented Aug 28, 2019

Humm, the issue I've run into was to change the message for the 419 with the default blade error pages without publishing them in the project.

It worked only with 403 and 503, that's why I've created this PR, this was only on the blade side

@fkeloks
Copy link
Contributor

fkeloks commented Aug 28, 2019

Hello,

I agree with @GrahamCampbell .
Most of the time, we do not display on the screen the actual message of the thrown exeption.

Maybe an option could be added to choose this new behavior or not, but I do not think it's worth it.

@Bouhnosaure
Copy link
Author

Bouhnosaure commented Aug 28, 2019

Hi !

I see, for what I've seen, for now we can't choose to display or not because the messages, as we talk, are in a translation helper.

In order to not see them, we can :

  • Put empty values in the translations files
  • Set the message to empty
  • Use a Boolean as false in the message parameter in order to treat the case of not wanting to see it and add a logic gate to hide or not on the view side
  • Add an optional parameter in the abort method
  • Use a config file to define the behaviors of the errors and their display by default

But i think, it will be better to open another issue to manage the if the user wants or not to display the errors, this PR was, only, to 'harmonize' the way messages are treated in the views files by default without publishing them, because we can set message for 403 and 503 right now but not for the other errors codes.

But indeed, it can be great to have the choice to hide or not the messages

@GrahamCampbell
Copy link
Member

Well, one could simply say that everyone can roll their own views, and do what they want, and that the ones in the core are simply a sane default. Defaults will not be right for everyone though, but you can just have your own views then.

@Bouhnosaure
Copy link
Author

Okay !

I'll roll my own so, i was trying to make all have the same behavior in term of message.

Thanks anyway, i'll close my issue and reject my PR !

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants