How do I debug a fatal error activating a plugin?

gohanman
(@gohanman)

8 years, 5 months ago
I have a simple, one file plugin. On trying to activate the plugin I get a message “Plugin could not be activated because it triggered a fatal error.”.

I’ve verified that it is not a syntax error by checking the file on the command line with php -l.

Nothing is written to the server’s PHP error log. I have verified that the server’s error log works correctly – for example, if I drop a test.php file in wordpress’s root directory containing:
```
<?php
$foo = new NonExistantClass();
```
and browse it the fatal error gets logged correctly as expected.

I tried enabling WP_DEBUG in wordpress’ config. Doing that changed nothing in what was displayed in the browser error or what was logged. I also tried setting WP_DEBUG_LOG. This also did not log anything when trying to activate the plugin.

How do I get useful information about what’s going wrong? How can I get a log somewhere, anywhere, that details what the fatal error is?

Viewing 5 replies - 1 through 5 (of 5 total)

Clayton James
(@claytonjames)

8 years, 5 months ago

I’m sure you’ve probably been through all of this, but I’ll mention the reference anyhow just in case – Debugging in WordPress

There are also some plugins that might be able to expose the nature of the error right from the dashboard. They might be worth taking a look at. Debugging Plugins

https://wordpress.org/plugins/search.php?q=debug
Thread Starter gohanman
(@gohanman)

8 years, 5 months ago
Yeah. The problem actually stemmed from the security advice here: https://codex.wordpress.org/Writing_a_Plugin#Plugin_Files

I wrote
```
defined( 'ABS_PATH' ) or die( 'No script kiddies please!' );
```
instead of
```
defined( 'ABSPATH' ) or die( 'No script kiddies please!' );
```
but die() isn’t really a fatal error. It just prints to STDOUT (which presumably gets eaten by output buffering somewhere) and exits.

Something like this would probably be a better solution.
```
if (!defined('ABSPATH')) {
    trigger_error('Invalid call state', E_USER_ERROR);
}
```
Moderator bcworkz
(@bcworkz)

8 years, 5 months ago

The WP activation failure message is perhaps misleading. Any activation failure is called a “fatal” error by WP. With either code I’m seeing STDOUT content after the WP message on my installation. I’m not sure why you didn’t. Different server configuration perhaps. While your suggestion is more “honest”, both versions achieve the intended purpose and there’s little reason to be more honest with some hacker inappropriately trying to access a page. There’s some validity to using whatever code requires the least resource to process. Dying is better than error handling in this respect. IMO only, I’m not speaking for wp.org in this regard.

Anyway, I’m glad you found the problem, doing so without any clue is maddening!

Thread Starter gohanman
(@gohanman)

8 years, 5 months ago

The suggestion has less to do with honesty and more to do with failing in a logged manner.

If the environment is configured with display_errors off using trigger_error would provide even less information with a blank white screen instead of “Go away script kiddies”. But even if display_errors is on the point of the suggestion is to put it at the top of the script to prevent access. There’s nothing on the call stack to leak into display.
adamjsutt
(@adamjsutt)

8 years, 5 months ago
I had a similar problem and at the end ended up getting pro help to fix it.
- This reply was modified 8 years, 5 months ago by adamjsutt.