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

TARC-360 SIFO ignores some Smarty errors in debug mode #84

Open
wants to merge 1 commit into
base: master
Choose a base branch
from
Open

TARC-360 SIFO ignores some Smarty errors in debug mode #84

wants to merge 1 commit into from

Conversation

xserrat
Copy link
Contributor

@xserrat xserrat commented Aug 16, 2019

Now when debug mode is enabled, all Smarty errors will be shown in the Debug analyzer and as a PHP warning.

@obokaman-com
Copy link
Member

In what situations would we want to override the given error_reporting level behavior?

@xserrat
Copy link
Contributor Author

xserrat commented Aug 16, 2019

There're some places where we have smarty errors but they are ignored due to the conditional that checks the error_reporting level. I'm not sure if this is the best way to solve the problem but I think it makes sense to show errors when we're under debug mode (or maybe we can change it to dev mode).

What do you think?

@obokaman-com
Copy link
Member

obokaman-com commented Aug 16, 2019

Do you have any example or any way to reproduce the unwanted behavior? The idea is respect the original reporting level, so only silented errors should be ignored.

@xserrat
Copy link
Contributor Author

xserrat commented Aug 16, 2019

For example:

  • In the import process there were some errors in the template when it was executed with -sur and -sar.
  • In /store there are smarty errors in the buy buttons of suggested products.
  • The email of confirm_order.tpl had an undefined 'commission_amount' (it was fixed).

I think that when the fetch method returns a null value and no error is shown is because those errors are being silented. However, what is really rare is that we sometimes see smarty errors but sometimes not. It seems that the error_reporting level is not the same in some cases...

@obokaman-com
Copy link
Member

obokaman-com commented Aug 16, 2019

In theory, if we are receiving a zero error_reporting level, we either have disabled error reporting in the config, or are executing something with forcedly silented errors (@function for instance), so in the end what we're doing with the initial condition is respect the original reporting level.

I think that if we have detected inconsistent behaviors regarding error reporting on templates on some points, maybe it's better to find the origin than forcing their logging.

If I try to execute some of the examples now, I should be able to see that inconsistences? Any specific thing to do to reproduce them?

@xserrat
Copy link
Contributor Author

xserrat commented Sep 28, 2019

Sorry @obokaman-com , I didn't see your last response. The thing I do to reproduce the inconsistencies was commenting the function that silent the error or add a var_dump to see the errors that come to the handler. We can check together next week!

@kpicaza kpicaza requested review from p0lemic and kpicaza July 15, 2022 07:35
@kpicaza kpicaza self-assigned this Jul 15, 2022
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