ebrigham1 / cakephp-error-email Goto Github PK

I am getting the following error:

Fatal error: Uncaught InvalidArgumentException: Unknown email configuration "default". in /var/www/x/cakephp/vendor/cakephp/cakephp/src/Mailer/Email.php:2243 Stack trace: #0 /var/www/x/cakephp/vendor/cakephp/cakephp/src/Mailer/Email.php(2083): Cake\Mailer\Email->_applyConfig(NULL) #1 /var/www/x/cakephp/vendor/cakephp/cakephp/src/Mailer/Email.php(362): Cake\Mailer\Email->setProfile('default') #2 /var/www/x/cakephp/vendor/ebrigham1/cakephp-error-email/src/Traits/EmailThrowableTrait.php(51): Cake\Mailer\Email->__construct('default') #3 /var/www/x/cakephp/vendor/ebrigham1/cakephp-error-email/src/Traits/EmailThrowableTrait.php(37): ErrorEmail\Error\ErrorHandler->_getMailer() #4 /var/www/x/cakephp/vendor/ebrigham1/cakephp-error-email/src/Error/ErrorHandler.php(80): ErrorEmail\Error\ErrorHandler->emailThrowable(Object(Error)) #5 /var/www/x/cakephp/vendor/cakephp/cakephp/src/Error/BaseErrorHandler.php(176): ErrorEmail\Error\ErrorHandler->handleException( in /var/www/x/cakephp/vendor/cakephp/cakephp/src/Mailer/Email.php on line 2243

Fatal error: Uncaught InvalidArgumentException: Unknown email configuration "default". in /var/www/x/cakephp/vendor/cakephp/cakephp/src/Mailer/Email.php:2243 Stack trace: #0 /var/www/x/cakephp/vendor/cakephp/cakephp/src/Mailer/Email.php(2083): Cake\Mailer\Email->_applyConfig(NULL) #1 /var/www/x/cakephp/vendor/cakephp/cakephp/src/Mailer/Email.php(362): Cake\Mailer\Email->setProfile('default') #2 /var/www/x/cakephp/vendor/ebrigham1/cakephp-error-email/src/Traits/EmailThrowableTrait.php(51): Cake\Mailer\Email->__construct('default') #3 /var/www/x/cakephp/vendor/ebrigham1/cakephp-error-email/src/Traits/EmailThrowableTrait.php(37): ErrorEmail\Error\ErrorHandler->_getMailer() #4 /var/www/x/cakephp/vendor/ebrigham1/cakephp-error-email/src/Error/ErrorHandler.php(80): ErrorEmail\Error\ErrorHandler->emailThrowable(Object(Cake\Error\FatalErrorException)) #5 /var/www/x/cakephp/vendor/cakephp/cakephp/src/Error/BaseErrorHandler.php(230): ErrorEmail\Error\Error in /var/www/x/cakephp/vendor/cakephp/cakephp/src/Mailer/Email.php on line 2243

Tip:

"cakephp/cakephp": ">=3.3.2 <4.0.0"

can be simplified using carot: ^3.2.2

Hi!
I try your fantastic plugin. The plugin notify to me errors in code but I can't configure notification of type errors like cURL Error (7) Failed to connect to gooooooogle.es port 443: No route to host
Cake\Http\Exception\HttpException

When such an error appears, enter by Cake\Error\Middleware; instead of ErrorEmail\Middleware\ErrorHandlerMiddleware;

How can I configure it to be able to report these errors? Thank you very much

My Cakephp version is 3.7.7

I've cloned your plugin inside my plugins dir then I've made configurations like you say in the readme page, but my project don't work it gives me the message:

Fatal error: Uncaught Error: Class 'ErrorEmail\Error\ErrorHandler' not found in /var/www/html/app/config/bootstrap.php:122 Stack trace: #0 /var/www/html/app/vendor/cakephp/cakephp/src/Http/BaseApplication.php(61): require_once() #1 /var/www/html/app/vendor/cakephp/cakephp/src/Http/Server.php(70): Cake\Http\BaseApplication->bootstrap() #2 /var/www/html/app/webroot/index.php(37): Cake\Http\Server->run() #3 {main} thrown in /var/www/html/app/config/bootstrap.php on line 122

I'm loading the plugin in my bootstrap.php
and I've replaced default cakephp error handler by yours
and in my applicationphp error handermidleware I've done the same
in my app.php I've added configuration for default configuration

What may I have done wrong?

[Mon Mar 16 19:12:06.814841 2020] [php7:warn] [pid 23677] [client 1.2.3.4:47120] PHP Warning:  SplFileInfo::openFile(/var/www/html/tmp/cache/error_emails/error_email_error_email_exception_deprecated_exception_request_handler_componentbefore_redirectisdeprecated_thisfunctionalitywillberemovedin400_settheenable_before_redirectoptiontofalsetodisablethiswarningvarwwwhtmlvendorcakephpcakephpsrc_event_event_managerphpline352_youcandisabledeprecationwarningsbysetting_errorerror_levelto_e_a_l_l_e_u_s_e_r_d_e_p_r_e_c_a_t_e_dinyourconfigappphp16384): failed to open stream: File name too long in /var/www/html/vendor/cakephp/cakephp/src/Cache/Engine/FileEngine.php on line 406, referer: https://censored.domain.com/request/path

There is default limit 255 characters on file-name in usual cases, see https://serverfault.com/a/9548/86062

This particular issue can be tested by enabling deprecation warnings, and using 'emailLevels' => ['exception', 'error', 'warning', 'notice', 'strict', 'deprecated'] config

Therefore process generating the throttle cache file should either trim the cache-key to 255 characters (unpractical and problematic), or generate SHA or other hash from cache-key, to stay in file name length limits (sha256 in hex is 64 characters, that should be safe for all situations)

Is it possible to replace deprecated function call in Tempaltes/Email/html/error.ctp and exception.ctp ?

Should be used

$this->request->getAtrribute('here')

instead of currently used

$this->request->here

since this will soon be deprecated.

Thanks.

First of all: Very nice documentation and everything. Awesome look and file on first glance!

Too small things though:
It would be good to not have those emails being actually "sent" synchronously.
This can further delay feedback to the user. Ideally those are put somewhere (like a queue), where another task can then collect those jobs and process the actual email sending part.

Another little thing: For a complete system failure this seems to trigger a lot of mails, like millions for a larger visitor count. I can only see an (optional) throttle for a certain blacklist etc, but not for a specific valid "admin mail" for example.
I would probably but a generic "throttle locking" in, that will based on a simple cache value or alike then completely stop sending those alert mails - as the admin sure already got enough of those?
Just some feedback here on the email sending issue.

Hi,
would it be possilbe to replace deprecated methods

• setTemplate()
• setLayout()

in src/Tratis/EmailThrowableTrait.php with

• $email->viewBuilder()->setTemplate()
• $email->viewBuilder()->setLayout()

?

As Cake4 is approaching (and methods marked as deprecated are supposed to be removed in v3.8 according to roadmap), maybe there are more than just these two remaining.

Thank you.

@ebrigham1

Thanks for the nice plugin. It is really good and solved our issues.

We have seen that this plugin only send email on fatal errors. It is not sending emails on "Database Query Errors" and warning and notice errors.

Is there way that we can able to receive those emails also. We want to make our website error free and that we can only able to do if we will going to receive each and every type of emails.

Hey,

since the CakePHP 4.x is released, and I found forks with 4.x support, do you plan to add the support too, or do you expect us to maintain fork with the support elsewhere?

Mentioned are
https://github.com/chtheis/cakephp-error-email/commits/master
and
https://github.com/pettrbalint/cakephp-error-email/commits/master

Thank you

Hi, thanks for your wonderful plugin, works really well :-)

One thing, I've not found possible to configure (without subclassing), is to ignore side-WarningExceptions about premature headers emission, when the content (ie. error) is output directly from controller, not from view.

Such will result in 2 additional emails being sent, generated by vendor/cakephp/cakephp/src/Http/ResponseEmitter.php

• Unable to emit headers. Headers sent in file=/path/to/class/that/printed/output.php line=line-number
• Cannot modify header information - headers already sent by (output started at /path/to/class/that/printed/output.php:line-number)

These are usually side-effect, not the direct reason, of error occuring.

Would it be possible to filter out these 2 emails, in situation where there are more emails queued about error itself?

Means.

• scenario 1
  • if controller/model/component/... outputs content, this results only in those 2 emails being sent
  • this is currently handled as it should imo
• scenario 2
  • if controller/model/component/... produces error which causes subsequently premature content output and 2 additional emails being sent (total 3 or more emails), do not send the 2 emails about error/warning being produced

Cheers

This is enhancement proposal, solving simple app-specific issue.
If the error is thrown in loop code (ie. generating "Undeffined offset" in loop code), this will generate as many emails, as there are loop iterations.

Currently $cacheKey is determined from throwable class, message and code concatenated and cleaned.

If app is to implement workaround for such situation, it would need to copy relevant code (generating $cacheKey), and for example replace the exception message with filename and line-number, that produced said throwable.

This has 2 possible solutions:

• Add option ErrorEmail.throttleAlgorithm with numerical values, that identify the algorithm that is used to throttle (this can be expanded later, and each algorithm should be implemented as standalone method in EmailThrowableTrait so it can be overriden for app-specific cases)
• Update trait interface to protected function _appSpecificSkipThrottle($throwable, $context = []), which would allow passing extra context data to app-specific handler (again, this proposed update can be applied to all _appSpecific* methods), context could in this case include cacheKey, but better would be to extract cacheKey generation to separate function, so it can be overriden ultimately

Second proposed approach, would also help greatly if ErrorHandlerMiddleware.handleException called the trait method _emailThrowable with $request and $response so these could be passed as context in trait methods, or be ultimately accessible from app-specific trait implementation through other methods

This whole proposal is to prevent users of this lib, to blindly copy-paste / override whole functions (such as _throttle or emailThrowable) from current EmailThrowableTrait, to achieve goals similar to described ones, which could result in fatal breaks in future, as soon as the lib code gets updated.

I'm actually thinking about providing both means (extract cacheKey algorithm generation, extract throttle algorithm no.1, and providing context in trait via methods _getRequest and _getResponse), so if you're cool with that, let me know, I'll push relevant changes for you to review.