This plugin provides a simple but powerful function for developers and site administrators. It automatically captures critical PHP errors (fatal errors, parse errors, etc.) that would otherwise take your site down silently.<\/p>\n\n
Instead of having to check server logs, you receive an instant notification via a webhook to a service of your choice, like Slack<\/strong> or Discord<\/strong>. This allows for immediate action and faster debugging.<\/p>\n\n The setup is minimal: just add your webhook URL on the settings page, and the plugin takes care of the rest.<\/p>\n\n The plugin has no service of its own. It sends data only to the webhook URL you enter on its settings page \u2014 Slack, Discord, n8n or whatever you choose \u2014 and contacts nothing else. The terms and privacy policy of the service you point it at apply.<\/p>\n\n Nothing is sent until you save a URL. After that:<\/p>\n\n No visitor data is included \u2014 no IP addresses, cookies, form contents or accounts. The crashed request's path does travel along, so a query string holding personal data would be included.<\/p>\n\n\n A webhook URL is a special web address provided by services like Slack, Discord, or Zapier. When your WordPress site sends a message to this URL, the service receives it and can post it, for example, in a specific chat channel. You can get this URL from the settings of your chosen service.<\/p><\/dd>\n It reads its settings once per request and holds back half a megabyte of memory, so it can still report if the request runs out. Beyond that it does nothing until a fatal error happens.<\/p><\/dd>\n The plugin reports Yes, labelled separately. On an out-of-memory crash the file and line PHP reports are wherever the last allocation landed, not the cause \u2014 so the notification also carries peak memory, the configured limit and the crashed request.<\/p><\/dd>\n No. An identical error \u2014 same message, file and line \u2014 is reported at most once every five minutes, so a fault that hits many requests at once still produces one notification.<\/p><\/dd>\n Yes: If another plugin already owns that file, it stays untouched and the settings page says so. Alerts keep working either way. The file is removed when you deactivate or delete the plugin.<\/p><\/dd>\n Yes. The filter External services<\/h3>\n\n
\n
\n
wonderful-webhook-alerts<\/code> folder to the \/wp-content\/plugins\/<\/code> directory.<\/li>\n\n
What is a webhook URL?<\/h3><\/dt>\n
Does this plugin affect my site's performance?<\/h3><\/dt>\n
Which error types are reported?<\/h3><\/dt>\n
E_ERROR<\/code>, E_PARSE<\/code>, E_CORE_ERROR<\/code>, E_COMPILE_ERROR<\/code>, E_USER_ERROR<\/code>, and E_RECOVERABLE_ERROR<\/code> \u2014 the same set WordPress itself treats as fatal.<\/p><\/dd>\nDoes it also report \"Allowed memory size exhausted\"?<\/h3><\/dt>\n
The same error keeps happening. Will I get flooded?<\/h3><\/dt>\n
Does the plugin add a file to wp-content?<\/h3><\/dt>\n
wp-content\/fatal-error-handler.php<\/code>, WordPress' official drop-in. It has to run first \u2014 WordPress registers its own shutdown handler before plugins load, and by then the error can already have been replaced by a later one.<\/p>\n\nCan I intercept the notification?<\/h3><\/dt>\n
wonderful_webhook_alerts_pre_crash_dispatch<\/code> receives ( null, $url, $body )<\/code> and replaces the built-in transport when it returns anything but null.<\/p><\/dd>\n\n<\/dl>\n\n\n1.2.0<\/h4>\n\n
\n
E_USER_ERROR<\/code> and E_RECOVERABLE_ERROR<\/code> are reported too \u2014 the set WordPress itself treats as fatal.<\/li>\nwonderful_webhook_alerts_pre_crash_dispatch<\/code>.<\/li>\n1.1.1<\/h4>\n\n
\n
1.1.0<\/h4>\n\n
\n
1.0.0<\/h4>\n\n
\n