Title: Errors when using WP_DEBUG Last modified: August 20, 2016 --- # Errors when using WP_DEBUG * Resolved [Mike Schinkel](https://wordpress.org/support/users/mikeschinkel/) * (@mikeschinkel) * [13 years, 6 months ago](https://wordpress.org/support/topic/errors-when-using-wp_debug/) * When using `WP_DEBUG` the following errors are displayed in the admin plugins page: * ``` Notice: Undefined index: PO_group_view in /Users/mikeschinkel/Sites/example/public_html/wp-content/plugins/plugin-organizer/lib/PluginOrganizer.class.php on line 481 Notice: Undefined index: PO_group_view in /Users/mikeschinkel/Sites/example/public_html/wp-content/plugins/plugin-organizer/lib/PluginOrganizer.class.php on line 497 Notice: Undefined index: PO_group_view in /Users/mikeschinkel/Sites/example/public_html/wp-content/plugins/plugin-organizer/lib/PluginOrganizer.class.php on line 566 Notice: Undefined index: plugin_status in /Users/mikeschinkel/Sites/example/public_html/wp-content/plugins/plugin-organizer/lib/PluginOrganizer.class.php on line 398 Notice: Undefined offset: 0 in /Users/mikeschinkel/Sites/example/public_html/wp-content/plugins/plugin-organizer/lib/PluginOrganizer.class.php on line 381 ``` * Using `WP_DEBUG` during plugin development is a best practice as you can see here: * [http://nacin.com/2010/04/23/5-ways-to-debug-wordpress/](http://nacin.com/2010/04/23/5-ways-to-debug-wordpress/) * Would love to see you add the following like to your development system’s `/wp- config.php` file and then test your plugin with it: * `define( 'WP_DEBUG', true );` Viewing 15 replies - 1 through 15 (of 16 total) 1 [2](https://wordpress.org/support/topic/errors-when-using-wp_debug/page/2/?output_format=md) [→](https://wordpress.org/support/topic/errors-when-using-wp_debug/page/2/?output_format=md) * Plugin Author [Jeff Sterup](https://wordpress.org/support/users/foomagoo/) * (@foomagoo) * [13 years, 6 months ago](https://wordpress.org/support/topic/errors-when-using-wp_debug/#post-3183574) * Undefined indexes are not errors. They are a notice. You should never have those turned on in production and I’m well aware that they are there. The undefined index may pose a problem however. I will look into that. * Thread Starter [Mike Schinkel](https://wordpress.org/support/users/mikeschinkel/) * (@mikeschinkel) * [13 years, 6 months ago](https://wordpress.org/support/topic/errors-when-using-wp_debug/#post-3183576) * Hi Jeff, * Technically speaking you are correct. Some (all?) of those warning probably do not result in a but. The concern however is that you are not using `WP_DEBUG` so you might be missing warnings that actually matter. * Here’s other issues: people who develop sites with `WP_DEBUG` cannot use your plugin without it throwing errors, so besides being annoying while development when demoing to clients they ask _“Why is it broken?”_. And some of the more advanced people in the WordPress community actually prefer to run their sites with `WP_DEBUG` being `true`. * Here’s what Andrew Nacin the development lead for WordPress 3.5 has to say about` WP_DEBUG`[1]: * > _If you’re a plugin or theme developer and you don’t know what the `WP\_DEBUG` > is, you’re missing out. (If you do know what it is and you don’t use it during > development, you’re crazy.) > … In a nutshell, there’s an entire API devoted > to informing you of the best practices and the latest APIs. * So, it’s pretty easy to fix these, just always use `WP_DEBUG` when you are developing and then you’ll be able to see and fix these issues. * Hope this helps. * [1] [http://nacin.com/2010/03/22/deprecated-functions-and-wp_debug/](http://nacin.com/2010/03/22/deprecated-functions-and-wp_debug/) * Plugin Author [Jeff Sterup](https://wordpress.org/support/users/foomagoo/) * (@foomagoo) * [13 years, 6 months ago](https://wordpress.org/support/topic/errors-when-using-wp_debug/#post-3183582) * If you run your site with wp_debug set to true you are opening yourself up to hackers. That level of error reporting should never be turned on in a production site. It should only be turned on for testing. I do turn my error reporting up during development but undefined indexes are not problems. They are sometimes intended. As is the case with the notices you reference. I could put an array_key_exists in the if statements to get rid of them but since they are not necessary and can become very redundant I generally don’t use them. * Thread Starter [Mike Schinkel](https://wordpress.org/support/users/mikeschinkel/) * (@mikeschinkel) * [13 years, 6 months ago](https://wordpress.org/support/topic/errors-when-using-wp_debug/#post-3183585) * I’m curious how using `WP_DEBUG` opens someone up to hackers. Can you give a specific example? * Anyway, I’ve gone ahead and made the fixes for you. It required three trivial fixes in `/lib/PluginOrganizer.class.php` and one in `/tpl/globalPlugins.php`: * [https://gist.github.com/4061683](https://gist.github.com/4061683) * Hopefully you’ll be willing to apply? BTW, I used `isset()` instead of `array_key_exists()` because it is more compact in the code and slightly faster. * As an aside, some thoughts on why it’s a good idea to always develop with warnings on: * [http://stackoverflow.com/a/1960588/102699](http://stackoverflow.com/a/1960588/102699) * Plugin Author [Jeff Sterup](https://wordpress.org/support/users/foomagoo/) * (@foomagoo) * [13 years, 6 months ago](https://wordpress.org/support/topic/errors-when-using-wp_debug/#post-3183586) * [http://php.net/manual/en/errorfunc.configuration.php](http://php.net/manual/en/errorfunc.configuration.php) * When you turn on WP_DEBUG you are essentially turning on error_reporting and setting E_ALL. This can have the effect of server path disclosure to a hacker. You have also done the same thing above by pasting your server path for everyone to see. This is not a good idea. * Thread Starter [Mike Schinkel](https://wordpress.org/support/users/mikeschinkel/) * (@mikeschinkel) * [13 years, 6 months ago](https://wordpress.org/support/topic/errors-when-using-wp_debug/#post-3183587) * [@jeff](https://wordpress.org/support/users/jeff/) Fair point about hackers. Of course if your site doesn’t throw errors then you don’t have this problem. But I demur. * As for my pasting my server path for everyone to see, I doubt pasting the local paths to my localhost development machine is really going to open me up to hackers. If it does, so be it. * Regardless if is it a good idea to not have WP_DEBUG on for production, as Nacin says _“if you don’t use WP\_DEBUG during development, you’re crazy.”_ * Anyway, my goal of posting this was to help, not to cause you to get defensive. If you would like to apply my patch that would be nice. If not that’s fine too. * [Dougal Campbell](https://wordpress.org/support/users/dougal/) * (@dougal) * [13 years, 6 months ago](https://wordpress.org/support/topic/errors-when-using-wp_debug/#post-3183588) * Path disclosure doesn’t make a site vulnerable. Yes, it’s information that could make it a little easier for a determined hacker to find things to poke. But only if you server has a vulnerability in the first place. Security through obscurity is not security, as the saying goes. Also, the path Mike posted above is obviously on his own local dev setup, and most-likely not on a public-facing IP. * That said, eliminating all warnings and info messages is still a Best Practice. Yes, it’s annoying to error-check every instance of an array index, define(), etc. But it’s still a Best Practice. Clean code is happy code! * Oh, and nobody is advocating running with WP_DEBUG in production. But even so— many sites turn on logging for warnings or even info messages. If you leave in code that generates these unneeded messages, all those servers running your plugin will waste CPU cycles and disk space for them. I, for one, get annoyed when my logs are polluted like that. * Plugin Author [Jeff Sterup](https://wordpress.org/support/users/foomagoo/) * (@foomagoo) * [13 years, 6 months ago](https://wordpress.org/support/topic/errors-when-using-wp_debug/#post-3183590) * Here’s a write up on OWASP of the problems that arise from full path disclosure. I’m not advocating security through obscurity but there are many different steps one needs to go through to achieve a secure platform. Hiding this vulnerability is one of them. WordPress is known for its security holes and there is no reason for leaving this one open. He was advocating for running with WP_DEBUG set to true in production. * [https://www.owasp.org/index.php/Full_Path_Disclosure](https://www.owasp.org/index.php/Full_Path_Disclosure) * Im not trying to be defensive. I’m just trying to point out that notices are not errors and that they should be ignored. There are many more areas of this plugin that throw notices and I have yet to find a plugin that doesn’t give some kind of notice. The suggestion has been made before and I am well aware of the notices. The plugin is working as intended. * Thread Starter [Mike Schinkel](https://wordpress.org/support/users/mikeschinkel/) * (@mikeschinkel) * [13 years, 6 months ago](https://wordpress.org/support/topic/errors-when-using-wp_debug/#post-3183592) * [@jeff](https://wordpress.org/support/users/jeff/), * > _He was advocating for running with WP\_DEBUG set to true in production._ * Not sure how you got that impression. My initial post said _(bold added):_ * > _Using WP\_DEBUG **during plugin development** is a best practice_ * My only mention of using during production was this _aside_ only because you should never have those turned on in production, which wasn’t the point: * > _And some of the more advanced people in the WordPress community actually prefer > to run their sites with WP\_DEBUG being true._ * Again, I wasn’t trying to make you defensive. If you think it’s acceptable to leave notices in your plugin then given current requirements of the plugin repository it’s your prerogative. I’m now sorry that I ever brought this up. * [Andrew Nacin](https://wordpress.org/support/users/nacin/) * (@nacin) * [13 years, 6 months ago](https://wordpress.org/support/topic/errors-when-using-wp_debug/#post-3183593) * WP_DEBUG is indeed often run in production (including on wordpress.org itself). But it is best to not conflate the two things it does. Primarily, it sets error reporting to include notices — that’s the important part. While it also forces errors to be displayed, that _isn’t_ something you’d do in production — that’s why this part is overridable (via WP_DEBUG_DISPLAY). * The important thing isn’t displaying errors, it’s recognizing that notices are errors. They often indicate (as you mentioned) a problem, or an assumption that could result in a problem later. * [Franz Josef Kaiser](https://wordpress.org/support/users/f-j-kaiser/) * (@f-j-kaiser) * [13 years, 6 months ago](https://wordpress.org/support/topic/errors-when-using-wp_debug/#post-3183594) * **[@jeff](https://wordpress.org/support/users/jeff/) Sterup ** * To double _[@nacin](https://wordpress.org/support/users/nacin/)_ and add some further explanation: Without `WP_DEBUG`, you’re not able to use `WP_DEBUG_LOG`. And you’ll really want to use this in production _too_, as you might not know what happened to your site, when your server starts crashing. Log files can be _accessed_ even _after_ your site is long gone. * As an addition, here’s a short sneak peek from my local config setup. _“Error level: Paranoia”_. * ``` // DS is a short defined as alias of DIRECTORY_SEPARATOR # ================================== # PHP errors & log error_reporting( E_ALL | E_STRICT | E_CORE_ERROR | E_CORE_WARNING | E_COMPILE_ERROR | E_ERROR | E_WARNING | E_PARSE | E_USER_ERROR | E_USER_WARNING | E_RECOVERABLE_ERROR ); @ini_set( 'display_errors', 1 ); @ini_set( 'log_errors', 1 ); # ================================== # DEBUG define( 'WP_DEBUG', true ); // file: ~/WP_CONTENT_DIR/debug.log define( 'WP_DEBUG_LOG', true ); define( 'WP_DEBUG_DISPLAY', true ); define( 'SAVEQUERIES', true ); # DEBUG: MU define( 'DIEONDBERROR', true ); define( 'ERRORLOGFILE', WP_CONTENT_DIR.DS.'logs'.DS.'mu_error.log' ); # PHP Error log location @ini_set( 'error_log', WP_CONTENT_DIR.DS.'logs'.DS.'php_error.log' ); ``` * In case you’re wondering why I’m doing this, here’s the explanation. If you ignore Notices, Warnings or errors, then you’re making the life of everyone who is coding after you pretty hard. If you deliver code that other people build upon, extend, etc. then you’re responsible to throw no errors/warnings/notices at all, because else _no one would be able to distinguish between their own errors and yours_. * **Don’t behave like a ThemeForest developer.** * [Andrew Nacin](https://wordpress.org/support/users/nacin/) * (@nacin) * [13 years, 6 months ago](https://wordpress.org/support/topic/errors-when-using-wp_debug/#post-3183595) * I wouldn’t use WP_DEBUG_LOG in production, unless you’ve specifically blocked wp-content/debug.log from external access. (I wished we didn’t introduce that to begin with, and I don’t know how long it has for this world.) Rather, you’ll want to use standard PHP error logging. * also, SAVEQUERIES is slow and should not be used in production. * [Franz Josef Kaiser](https://wordpress.org/support/users/f-j-kaiser/) * (@f-j-kaiser) * [13 years, 6 months ago](https://wordpress.org/support/topic/errors-when-using-wp_debug/#post-3183596) * [@nacin](https://wordpress.org/support/users/nacin/) Haven’t talked about _this_ logs in production, but that clarification seems to be necessary. * > (…) here’s a short sneak peek from my local config setup * Also it’s not necessary to add all those `E_*`, as `E_ALL` covers lots of them, but it’s easier for me to delete only what I don’t need in some specific case. As I said: Just my local config. * Anyway, maybe it’s time for another “Make” article on debug and development. The last line from my comment above may fit as title. * [Japh](https://wordpress.org/support/users/japh/) * (@japh) * [13 years, 6 months ago](https://wordpress.org/support/topic/errors-when-using-wp_debug/#post-3183599) * Using WP_DEBUG during development is a crucial part of the development process. As [@nacin](https://wordpress.org/support/users/nacin/) says, Notices _are_ errors. * If your plugin is throwing any sort of error level output, you have more work to do. * ———- * Also, I just wanted to add a brief reply to “**Don’t behave like a ThemeForest developer.**“: * While your point is understood, and I myself am also often frustrated by this on some older ThemeForest themes, it’s completely unfair to generalise like that. * Plugin Author [Jeff Sterup](https://wordpress.org/support/users/foomagoo/) * (@foomagoo) * [13 years, 6 months ago](https://wordpress.org/support/topic/errors-when-using-wp_debug/#post-3183607) * Fine. I will go through the plugin and remove notices. But please take my advice. It is not a good idea to run with that level of error reporting on in a production site. Unless you don’t get much traffic. If the notices are printed to the screen it can give a hacker clues as to how your system is set up. Plus it has to write every one of those notices to a file and can bring down your server. Believe me I’ve seen it happen. Best practice is to only log critical errors to your log unless it is a dev server. You can try your best but I can still create notices in your error logs to fill it up by playing around with ajax requests and other URL’s. Viewing 15 replies - 1 through 15 (of 16 total) 1 [2](https://wordpress.org/support/topic/errors-when-using-wp_debug/page/2/?output_format=md) [→](https://wordpress.org/support/topic/errors-when-using-wp_debug/page/2/?output_format=md) The topic ‘Errors when using WP_DEBUG’ is closed to new replies. * ![](https://ps.w.org/plugin-organizer/assets/icon-256x256.png?rev=1786554) * [Plugin Organizer](https://wordpress.org/plugins/plugin-organizer/) * [Frequently Asked Questions](https://wordpress.org/plugins/plugin-organizer/#faq) * [Support Threads](https://wordpress.org/support/plugin/plugin-organizer/) * [Active Topics](https://wordpress.org/support/plugin/plugin-organizer/active/) * [Unresolved Topics](https://wordpress.org/support/plugin/plugin-organizer/unresolved/) * [Reviews](https://wordpress.org/support/plugin/plugin-organizer/reviews/) ## Tags * [errors](https://wordpress.org/support/topic-tag/errors/) * [wp_debug](https://wordpress.org/support/topic-tag/wp_debug/) * 16 replies * 6 participants * Last reply from: [Jeff Sterup](https://wordpress.org/support/users/foomagoo/) * Last activity: [13 years, 6 months ago](https://wordpress.org/support/topic/errors-when-using-wp_debug/page/2/#post-3183619) * Status: resolved