I have a Laravel application that has to integrate with a legacy external code base. I spent weeks making sure that everything worked. Unfortunately I'm not the only developer, and as the other code base doesn't exit on strict errors, they don't get fixed, or caught, until it breaks my code. And I only find out afterwards.
I need to disable exit() on strict errors. Fatal errors should still fail. A cursory google search only returns "Don't" which is obviously the best option, but unfortunately not possible in my circumstances.
Add error_reporting line right after application initialization to bootstrap/app.php as follow:
$app = new Illuminate\Foundation\Application(
// Laravel\Lumen\Application in case of Lumen
realpath(__DIR__.'/../')
);
error_reporting(E_ALL & ~E_STRICT);
This will prevent ErrorException to be thrown on E_STRICT. Same applies for Lumen:
$app = new Laravel\Lumen\Application(
realpath(__DIR__.'/../')
);
error_reporting(E_ALL & ~E_STRICT);
Related
A PHP Error was encountered
Severity: 8192
Message: Creation of dynamic property CI_URI::$config is deprecated
Filename: core/URI.php
Line Number: 102
Backtrace:
File: C:\xampp\htdocs\inv_perpus\index.php
Line: 288
Function: require_once
This is an issue with CodeIgniter.
in /system/core/URI.php you can add this to the top of the class to fix it:
/**
* CI Config
*
* #var CI_Config
*/
public $config;
Or, you can disable deprecation warnings in one of two ways:
php.ini
error_reporting = E_ALL & ~E_DEPRECATED
in code:
ini_set('error_reporting', E_ALL & ~E_DEPRECATED);
of course it is bad practice to disable these errors, as these errors should be heard loudly and fixed quickly.
I opened an issue with CodeIgniter and opened a pull-request to resolve this for you in their next release. They should be onto it relatively quickly and release a patch soon thereafter so just let the course of it play out and silence the error for now
This issue is resolved in CodeIgniter 4 however
Also not a best practice, but instead of set the error reporting, in my case it was better solution to simply added an # charachter to the beginning of each reported lines.
My server is running PHP 5.3 and my WordPress install is spitting these errors out on me, causing my session_start() to break.
Deprecated: Assigning the return value of new by reference is deprecated in /home//public_html/hub/wp-settings.php on line 647
Deprecated: Assigning the return value of new by reference is deprecated in /home//public_html/hub/wp-settings.php on line 662
Deprecated: Assigning the return value of new by reference is deprecated in /home//public_html/hub/wp-settings.php on line 669
Deprecated: Assigning the return value of new by reference is deprecated in /home//public_html/hub/wp-settings.php on line 676
Deprecated: Assigning the return value of new by reference is deprecated in /home//public_html/hub/wp-settings.php on line 712
This is annoying, but I do not want to turn off on screen error reporting. How do I disable these bothersome deprecated warnings?
I am running WordPress 2.9.2.
You can do it in code by calling the following functions.
error_reporting(E_ERROR | E_WARNING | E_PARSE | E_NOTICE);
or
error_reporting(E_ALL ^ E_DEPRECATED);
To only get those errors that cause the application to stop working, use:
error_reporting(E_ALL ^ (E_NOTICE | E_WARNING | E_DEPRECATED));
This will stop showing notices, warnings, and deprecated errors.
I needed to adapt this to
error_reporting = E_ALL & ~E_DEPRECATED
You have to edit the PHP configuration file. Find the line
error_reporting = E_ALL
and replace it with:
error_reporting = E_ALL ^ E_DEPRECATED
If you don't have access to the configuration file you can add this line to the PHP WordPress file (maybe headers.php):
error_reporting(E_ALL ^ E_DEPRECATED);
I just faced a similar problem where a SEO plugin issued a big number of warnings making my blog disk use exceed the plan limit.
I found out that you must include the error_reporting command after the wp-settings.php require in the wp-config.php file:
require_once( ABSPATH .'wp-settings.php' );
error_reporting( E_ALL ^ ( E_NOTICE | E_WARNING | E_DEPRECATED ) );
by doing this no more warnings, notices nor deprecated lines are appended to your error log file!
Tested on WordPress 3.8 but I guess it works for every installation.
All the previous answers are correct. Since no one have hinted out how to turn off all errors in PHP, I would like to mention it here:
error_reporting(0); // Turn off warning, deprecated,
// notice everything except error
Somebody might find it useful...
In file wp-config.php you can find constant WP_DEBUG. Make sure it is set to false.
define('WP_DEBUG', false);
This is for WordPress 3.x.
I tend to use this method
$errorlevel=error_reporting();
$errorlevel=error_reporting($errorlevel & ~E_DEPRECATED);
In this way I do not turn off accidentally something I need
If PHP warnings are breaking things in WordPress, but you still want to know what the warnings are, you can disable displaying PHP errors/warnings and only send them to the log file:
define( 'WP_DEBUG', true );
define( 'WP_DEBUG_DISPLAY', false );
define( 'WP_DEBUG_LOG', true );
this error occur when you change your php version: it's very simple to suppress this error message
To suppress the DEPRECATED Error message, just add below code into your index.php file:
init_set('display_errors',False);
I am using the WordPress REST API and in my main plugin file I set:
ini_set('display_errors', 1);
ini_set('display_startup_errors', 1);
error_reporting(E_ALL);
I'm getting some weird behavior. For instance in a function/endpoint I have something like:
function test($request){
$request['id'] <- this works fine here
but if I add another function like this I get a silent error
$validID = check_id($request['id']);
}
So when I do this my return from the endpoint is blank and I get this error:
has been blocked by CORS policy: No 'Access-Control-Allow-Origin' header is present on the requested resource.
Now if I set error_reporting to:
error_reporting(E_ERROR | E_WARNING | E_PARSE);
My endpoint works just fine. Not sure what is happening here. I don't get any php error logs and this makes it extremely difficult to troubleshoot. So should I just NOT use E_ALL?
I also tested the endpoint by leaving out a semi colon. I get the same result except now I get an empty response for both error_reporting(E_ALL) and error_reporting(E_ERROR | E_WARNING | E_PARSE). I'd love to get some kind of log/return to tell me whats wrong.
Unfortunately a lot of WordPress code out there is written without WP_DEBUG enabled, which means without E_ALL level. As result it tends to be full of notices and deprecation issues developers don't see and don't bother to correct.
So raising error reporting can often trigger issues entirely unrelated to your own code.
Since your immediate problem is lack of obvious error message/log, you should experiment with WP_DEBUG_DISPLAY and WP_DEBUG_LOG configuration to see if that helps.
Generally it's preferable to use constants to control WP's error handling centrally. When extensions start to mess with this it's... well, a mess. :)
Another thing you could try is a dedicated error handler. I made and use a wps plugin that wraps whoops handler for WP context. For API errors it tries to override the output and return a meaningful trace for what happened.
I created an APP and removed this error in development. In the app/Http/Controllers/Controller.php class, before the declaration of the class I included the following line:
ini_set('error_reporting', E_ALL & ~E_STRICT);
WHen I send to production and enable the errors display, it gives me two errors:
2/2:
The Class myApp/.../ClassNameController does not exist
1/2:
Declaration of ... should be compatible with ...
So I believe the first error is creating the second. The production environment is ignoring the line I added to allow multiple signatures for the same method name.
How can I disable it in production mode?
All over the web[1][2][3], it says that since PHP 5.0.0 "assigning the return value of new by reference" gives a E_DEPRECATED or E_STRICT depending on your php version (E_DEPRECATED didn't exist until 5.3, so it was E_STRICT before that).
As such it is my understanding that this code should give such a warning:
error_reporting(E_ALL | E_STRICT);
class A
{
}
$a =& new A();
However, I have tried this on two completely different servers (one running PHP 5.3 and one running PHP 5.2) and neither is actually giving any message! What's going on? Is my understanding incorrect or is something strange going on on those two servers?
(I do also think it is strange that this is deprecated, seeing that $a = null; $b =& $a; $b = new A(); does not do the same as $a = null; $b =& $a; $b =& new A();, but that's only a part of the question if I misunderstood what is deprecated...)
In response to the OP, this comment pointed him in the right direction:
It wouldn't at all surprise me if the problem here lies elsewhere: try setting E_ALL | E_STRICT in your php.ini directly, don't forget to change the php-cli.ini, too, if you're running this code on the command line.Also double check if the errors aren't hidden by doing an ini_set('display_errors',1);1. If you're running this on a windows box, there have been some bugs with this in the past.
Since the OP also pointed out that the warnings were generated before any code got executed, I had a hunch, that the expected warnings are being raised at compile-time, rather then runtime, so I had another look at the docs. There, I found this big red-box note, which confirmed my suspicions:
Most of E_STRICT errors are evaluated at the compile time thus such errors are not reported in the file where error_reporting is enhanced to include E_STRICT errors (and vice versa).
Since version 5 PHP is effectively a "compiled" language (similar to Java, the code is compiled to Zend Bytecode). When the Zend-engine compiles code with errors that are issued at compiled time, an in-script error_reporting call has no effect on weather or not these errors are reported: the error_reporting call applies only to the runtime errors/warnings.Perhaps this: error_reporting(E_ALL | E_STRICT | E_COMPILE_ERROR); is worth a look, too
Bottom line: Set the error reporting in the php.ini files whenever you can.