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.
Related
Using
PHP 8.1
Symfony 5.4
Problem
Every symfony command console output is followed by deprecation notice
2022-11-23T22:22:33+01:00 [info] Deprecated: ucfirst(): Passing null to parameter #1 ($string) of type string is deprecated
The problem is I am not using ucfirst anywhere in my project, so it probably is some composer package deprecation. However the deprecation notice does not contain neither the path to a file nor any other clue how it can be found.
How can one track the file / code which triggers this deprecation?
You may want to set error_reporting=E_ALL (not mandatory as you have depreciation notice emitted already) and then log_errors = On and perhaps log_error = syslog and then inspect the log entries in syslog and you should have file and line number which potentially could help you back track the culprit.
Aside from this, it's a depreciation notice and not an error. And since it's not in your code, there's not much you can do beside upgrade your dependencies (incl. Symfony) or disabling E_DEPRECATED notices from being emitted. Again, this is a notice, not an error.
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?
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);
I managed to run MongoDB on Codeigniter using Alex Bilbie` library. The operations go well (connection, queries etc. ) but sometimes I get these PHP notices:
Message: Mongo::__construct() [mongo.--construct]: localhost:27017: pool get (0x4bfab20)
Filename: libraries/Mongo_db.php
Line Number: 1274
A PHP Error was encountered
Severity: Notice
Message: Mongo::__construct() [mongo.--construct]: localhost:27017: found in pool (0x4bfab20)
Filename: libraries/Mongo_db.php
Is there a way to get rid of these? or maybe hide them..as they don't seem to mess up my pages in another way than splashing into the user's screen.
EDIT
On a few pages though, I use the JQgrid and when the errors show up they mess up my HTTP response and render some messy data.
The specific notice messages here have been removed in the MongoDB PHP driver 1.2.11 or later (see PHP-431). Upgrading your MongoDB driver to the latest should remove the excessive notice logging.
General notes on proper settings for Code Igniter logging in production still apply...
The E_NOTICE level of error reporting is intended to warn you about possible bugs or typos. It is typically only used as a development setting rather than for production messages.
The default error_reporting setting in PHP4 and PHP5 is actually set to ignore these:
E_ALL & ~E_NOTICE
The Code Igniter index.php has an application environment setting which normally shows all errors for development and suppresses error reporting for testing and production. You should set this appropriately:
define('ENVIRONMENT', 'production');
If you actually want to capture these messages for a production environment you should update the production settings in your index.php so that instead of error_reporting(0) you have:
error_reporting() set to appropriate level of detail
display_errors off
log_errors on
error_log path set
For example, in index.php you could have:
case 'production':
error_reporting(E_ALL);
ini_set('display_errors','Off');
ini_set('log_errors','On');
ini_set('error_log','/var/log/php5.log');
break;
That way the messages/notices will still be saved to the error_log if you want to review them, but they will not be shown to the end user.
Off the top of my head, there are a few things you could do. This is not an answer regarding a fix to the MongoDB error you are receveing, but rather regarding some methods in which you could hide the errors.
a) Use the '#' operator to ignore any error outputs from the method being called in which outputs the errors you are receiving. This would result in you renaming the method call to the following #method_outputting_mongodb_error($foo,$bar);.
b) Turn off error reporting in CodeIgniter. This is not the best method as all other errors will not be outputted.
There is a good link here re: how you can turn off error reporting: http://phpdog.blogspot.fr/2012/02/codeigniter-error-reporting-handling.html
As #Stennie mentions this has been fixed in later versions of the driver: https://jira.mongodb.org/browse/PHP-431
Try and upgrade.
Also this only existed on the Windows driver and only start happening after v1.2.1. I know that because the guy who made that JIRA also tried 1.2.1 on my advice and he didn't get those E_NOTICEs. I remember having the conversation that actually triggered that JIRA now :).
Unlike others I don't think you should "hide" these errors with E_ALL & ~E_NOTICE. No one is quite decided on hiding E_NOTICE however the general concensus is that it is not the best thing. Of course you would not want your logs to be filled with all this debug info about the MongoDB extension, instead the MongoDB extension should be silent (as you think it should).
Another reason I would not hide E_NOTICE is because of the php.ini of later versions of PHP:
; error_reporting
; Default Value: E_ALL & ~E_NOTICE
; Development Value: E_ALL | E_STRICT
; Production Value: E_ALL & ~E_DEPRECATED
By default PHP will actually install for Production Value (as it does for me) as such the default for PHP error reporting is:
E_ALL & ~E_DEPRECATED
This is the value I have for error_reporting on both my AWS and my local Ubuntu server 12.04 and I have not changed the values since installing as such the default value I gain from installing PHP from both repo and source is:
error_reporting = E_ALL & ~E_DEPRECATED
So the recommended default setup for production for later PHP versions (and probably future ones) actually shows E_NOTICE, which is useful but not if the logs are being filled with stuff from the Mongo extension.
Edit: Downvoter care to explain? I have basically given the same answer as #Stennie, why the downvote?
I have edited my answer to actually take the conversation in the comments on this answer and #Stennie's answer into consideration so the answer makes more sense now.
I've seemingly tried about every different suggestion provided through a couple hours of Google and stackoverflow searching to no avail, and I cannot seem to suppress a large sum of "Deprecated: Assigning the return value of new by reference is deprecated in " errors presented at the top of my application, as well as Many "Warning: the magic method __get() (and __set()) must have public visibility and cannot be static in . Thus far, I have added the following line and many different variations of it to my php.ini file:
error_reporting = E_ALL & ~E_DEPRECATED
error_reporting = E_ALL ^ E_DEPRECATED
I've also attempted a straight suppression of every single error:
error_reporting = ~E_ALL
To no avail either. I've confirmed that it is correctly reading the php.ini file by adjusting other settings successfully.
I've also applied the error_reporting() function (with all different variations of what's provided above) within my scripts with no more luck. Does the location of the reporting have anything to do with the suppression? I've tried posting it at the top of the first file being loaded, also at the top of a required file that is getting called immediately upon executing the main script, no where does it seem to take it.
Try it with a number: http://www.php.net/manual/en/errorfunc.constants.php
Everything but the two deprecateds would be 8191.
PS. It's possible the app/framework/website you're watching/editing/creating sets the error reporting level to E_ALL. If so, it doesn't matter what you set in php.ini, because it's overridden later.