We're moving from php4 to php5, and we get this warning on one of our developers machines, but not in our php5 test setup:
Deprecated: Call-time pass-by-reference has been deprecated in C:\Workspace\Prelive\www\includes\filename etc..
The code seems to be the same in both environments, and the php.ini on the test environment has this setup for errors:
error_reporting = E_STRICT | E_ALL
We could ofcourse just fix the code so the warning will go away, but my main concern is why the test environment is not complaining about it.
There is a php.ini directive called allow_call_time_pass_reference, which may be off in the environment which does not complain about it.
You've probably checked this already, but is
display_errors = On
set in both ini files?
Related
Im on a development server using a version of php that doesn't support mysql_connect() our production server does. I have tried: error_reporting = E_ALL ^ E_DEPRECATED but it doesn't work. After restarting Apache I still the deprecated error message.
I have access to the ini file I should not need php functions to change the error reporting. this is also for wordpress.
error_reporting() is a function. Try: error_reporting(E_ALL ^ E_DEPRECATED ^ E_USER_DEPRECATED);. Or ini_set("error_reporting", E_ALL & ~E_DEPRECATED);. Then test the settings with echo ini_get("error_reporting");. Minimal PHP version must be 5.3.0 for that.
Try replacing your mysql_connect() with mysqli_connect()
Are you sure that you've modified the correct php.ini? Often there are several included with an install. Is this happening on your local development machine, or on a live server? The best way to make sure you've modified the right php.ini is to run a phpinfo file.
Create a new file, name it phpinfo.php and write:
<?php echo phpinfo(); ?>
Run this script in your browser and go down to the line that says "Loaded Configuration File"
This used to cause me headaches when using a WAMP install.
WordPress sets the error_reporting to E_ALL in its config files, thus overriding whatever you've set in php.ini. I beleieve setting error_reporting(E_ALL ^ E_DEPRECATED) in wp-config.php clears it up. See Turn off deprecated errors php 5.3 for various and sundry variations on that setting.
setting: define('WP_DEBUG', false); to false fixed the issue.
Every time I have an error within my code and try to run it, the page becomes inaccessible. This is clearly very frustrating as it's hard debugging code with no feedback.
Relevant information from cPanel:
Apache version 2.2.22
PHP version 5.3.14
MySQL version 5.1.68-cll
Architecture x86_64
Operating system linux
If more information is required then please ask, I'm sorry I cannot provide any more information but frankly I am stumped.
Thanks.
Enable error reporting to see what error PHP had, if it had one.
There are several places you can look, firstly try checking your Apache error log. In many cases this is located in /var/log/apache2/error.log . Another way to debug a page like this is to enable error logging.
The simplest way of doing this being adding these lines to your php file:
ini_set('display_errors',1);
error_reporting(E_ALL);
In addition to this, you can also clean up the errors formatting by adding:
ini_set('html_errors', 'On');
In addition to this method of enabling error reporting, you may also enable them from you configuration file by adding the following line:
error_reporting = E_ALL
You need to update your php.ini to display errors. There are a couple settings.
Search your php.ini for display_errors and error_reporting. The file is usually commented very well on the options for error reporting, but error_reporting = E_ALL is a typical setting. Sometimes people want to suppress notices and set error_reporting to E_ALL & ~E_NOTICE.
display_errors = On is the config to print the errors to the screen.
After changing your php.ini, Apache usually needs to be restarted. I'm not sure how much control you have over your server, so if you can't restart Apache but you have a php.ini available, your host probably has it configured so you don't need to restart.
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.
My development server runs my PHP web application smoothly on PHP 5.3.8.
However, when upgrading my PHP production server from PHP 5.2.6 to 5.3.8 I got several problems with this application (complaints about deprecated function ereg_replace and missing date.timezone settings) which forced me to order a rollback to 5.2.6.
How can the same PHP code work fine on one 5.3.8 server and not on another? What are common causes for this behavior? Any suggestions?
Your error level settings are not the same on your machines.
FYI:
ereg_replace is deprecated and using it is highly discouraged
every call to a date/time function will generate a E_NOTICE if the
timezone isn't valid, and/or a E_WARNING message if using the system
settings or the TZ environment variable
Please access php.ini (PHP configuration file) on both server.
Find the line "; display_errors"
Please compare the following lines after that.
These are the options available for the three settings variable:
; display_errors
; Default Value: On
; Development Value: On
; Production Value: Off
; display_startup_errors
; Default Value: Off
; Development Value: On
; Production Value: Off
; error_reporting
; Default Value: E_ALL & ~E_NOTICE
; Development Value: E_ALL | E_STRICT
; Production Value: E_ALL & ~E_DEPRECATED
are you totally positive that your development server runs PHP 5.3.8?
All ereg_* functions are deprecated in PHP 5.3.X, so your code should not run on PHP 5.3 without any warning. if so, that is weird because your development server should generate more warnings (e.g. E_ALL) than your production server. Check your error reporting settings in php.ini. (display_errors, error_reporting)
to make it fly, you should really search for any occurance of ereg_* and replace these expressions with a preg_* equivalent.
date.timezone can be set in your php.ini. After that, i see less reason why your PHP 5.2.6 code should not run on 5.3.6.
PHP is an evolving language, same for Java or c#, so it means you have to check the documentation if some functions are not deprecated and update your code accordingly.
Also you have to make sure your PHP settings are the same on both servers.
If you check the ereg_replace documentation there is this blurb:
Warning This function has been DEPRECATED as of PHP 5.3.0. Relying on
this feature is highly discouraged.
I want to keep errors out of my PHP output stream. I only want output of things I explicitly echo.
Looking at my php.ini, is "display_errors" the only configuration I need to change?
Instead of modifying php.ini, you can call this at a very early part of your code:
error_reporting(0);
Note that this means fatal errors will die silently as well, so it makes it a little difficult to debug at first.
I only recommend that if we're talking about a production machine. display_errors will hide them from the user, but make sure you have log_errors and error_log set in the php.ini so you'll see them on your regular log analysis (you do, right?).
For a development machine, I recommend keeping display_errors on and error_reporting(E_ALL | E_STRICT) so you'll see if anything is fishy.
You can modify that INI directive and change the flag to 0 (False) or disable error_reporting on a page by page basis
error_reporting(0)
Typically Production environments should be on display_errors = 0 Though not all of us have both Development and Production environments
You can also change the "verbosity" of the error messages by passing different values to error_reporting function (Or by changing the INI value for it in php.ini) More information on that can be found here: PHP: Runetime Configuration - error_reporting