I took over a Laravel 5.5 project, and there is something going on that I have never encountered - the content on the error reporting screen is all replaced by stars.
I don't know what the previous devs did to accomplish this, but obviously I want to be able to see this info. The .env content seems fairly obvious:
APP_ENV=local
APP_HOST=http://localhost
APP_DEBUG=true
APP_TESTMODE=false
APP_CACHE_ENABLED=true
Other than that, there are API keys for Stripe, AWS etc, but nothing that would presume to block me from viewing the info on the error screen.
Why is this problem occurring and how can I fix it?
You probably have the debug_blacklist set, as seen in the documentation
Simply remove the debug_blacklist array from your config/app.php configuration file and the values will reveal.
Related
This route was working for months but suddenly it went blank and I got no errors and logs for it. I tried cleaning the cache using "php artisan optimize:clear" and cleared all the possible caches, but it doesn't work!
I haven't had any changes related to this route and view. It seems like a bug. My Laravel version is 7.30.4.
And I'm sure it's a route-related issue because changes in view don't affect it.
Yo should put some debug or code on the Handler.php, just to be sure if there's an Exception. Also change your .env enviorment to not production, don't forget to run a "php artisan optimize". Hope this info helps you.
I have a form that allows upload three files at the same time but just one is required. That works fine, my only problem is the following: if I upload three files I haven't any problem but if I upload one or two files (leaving two or one files empties) I obtain the following notice:
Notice: No file uploaded in Unknown on line 0
As much as empty files. The files are uploaded properly without any other problem, but I want remove that notice... or unless hide it, although I prefer remove it. I tried to hide it using
error_reporting(0);
and
ini_set('display_errors',0);
but neither of two worked...
It is the first time that I have problem, if someone could lead me I'd be very grateful due to that I am stuck with it.
If you are having the same problem as me, check with phpinfo() if you are using a debug version of PHP. If you see that Debug Build has a value of yes, your problem will be fixed if you install a live version of PHP instead of a debug version
The Error itself is caused by running a Debug version of PHP 7, see the bug report. As noted by HPierce because it was a Debug build it overrides the usual PHP settings for error_reporting. However as the Original question is actually about how to hide certain [expected] error messages (Notices), my answer is to this detail specifically.
Kevin, the attempted ways to hide errors you've listed in your question would normally work on non-debug PHP builds. However, it is unwise to ignore the errors, rather than solving them at source. It's also (more) unwise to hide all errors simply due to having expected errors appearing.
As it's only a Notice, you can work around it by setting your error_reporting() value as below:
//report all errors except notices.
error_reporting(E_ALL & ~E_NOTICE);
I would suggest this is far wiser than turning off error reporting entirely which is not recommended. If you want to stop errors being output to browser (as referenced by Tina) you can use display_errors.
Perhaps you may also need to set
ini_set('error_reporting', 0);
depending on your php ini configuration?
Also make sure you set it before carrying out any of the code.
I have a CodeIgniter PHP app running on a Heroku Cedar instance.
We are running a PHP app and we need to log errors, but NOT print them to the screen. No matter what I do, the errors are printing to the screen, which is not safe for production.
Here is the PHP code which works on my local environment and everywhere else (besides Heroku):
error_reporting(E_ALL); #we care about all errors
ini_set('display_errors',0); #but DONT print to screen
I have seen this document which suggested I try adding a custom CodeIgniter logging class, which did not work.
I also added a phpinfo() to the app to check if somehow my settings were being overridden downstream, but it shows that display_errors is set to "Off".
So why am I STILL seeing errors printed on the screen?
It turns out that CodeIgniter 2.x has some completely asinine error handling in which they use a custom error handler to ignore the developers configurations. Apparently this is fixed in v3.
I was able to fix it by just commenting out the custom error handling, which for me was located in in CodeIgniter.php, line 72...
//set_error_handler('_exception_handler');
Or the best solution of all: don't use CodeIgniter in the first place.
Bit of a strange one here. I'm looking through my PHP Error log and on a number of occasions I'm seeing the following line
File does not exist: /var/www/vhosts/mywebsite.org.uk/httpdocs/users/assignmnets
The reason the file doesn't exist is that the folder is spelt wrong - it should read assignments, not assignmnets.
The thing is, I've gone through all of the code on the site and this spelling mistake doesn't appear anywhere at all, so why am I getting this error? Furthermore, there are no links to the above folder - any links point directly to the php file contained within the folder - assignments/assignments.php
I can't make head nor tail of it. Is this a common issue with PHP or is there something I am getting wrong?
Thanks!
What kind of PHP error log is it? some custom logger function? Try using Tracy https://github.com/nette/tracy - enabling this debugger in your project with
Debugger::enable(Debugger::DETECT, __DIR__ . '/mylog');
will result in that all PHP errors will be logged as an HTML file with very verbose description of the error, including full stack trace (in production environment; on localhost, when development environment is detected, you will see the stack trace immediatelly in browser). From this you will be able to determine which part of code caused this problem next time it happens.
Don't forget to disable your custom error handler if any is in use, as it may be colliding with Tracy.
My local windows webserver (IIS) doesn't log php errors to log file.The php53_errors.log file is always empty. http://prntscr.com/2aels How to fix it? I think something goes wrong with permission settings. But it shows errors on browser window. And, one more question:Notices like "Undefined index".. Are they really important?
In the IIS server manager tool, there is option call error page. Please disable to use the IE error page to show you the error.
Besides please go to the C:\inetpub\wwwroot\web.config this file controls how to display and log the error as well. It should have one line like this.
<httpErrors errorMode="Detailed" />
Do you have php.ini in right setup according to this?
http://php.net/manual/en/install.windows.manual.php
specially keys log_errors and error_log
Read the last part of your question:
Notices like "Undefined index".. Are they really important?
It depends on your definition of 'important'.
The easy answer is no, they're not important. That's the reason they're classified as notices rather than warnings. It's okay to ignore them.
However you should still pay attention to them, and try to fix them where possible.
For example, the notice you quoted "Undefined index". This is caused (as I'm sure you're aware) by referencing an array element that hasn't yet been defined.
It is best practice to prevent this notice from being raised by using isset(), because if you do that, then when you do still get the notice, you'll know it is important - maybe you made a typo in your variable name or array index? The code will still run, but it won't work properly, and getting the notice might be the first clue you have of that. If that notice is suppressed or drowned out by legitimate ones, you'll never spot it.
Most 'notices' raised by PHP are on a similar level to that -- they indicate that something might be wrong, but PHP doesn't know for sure. If you write your code defensively to prevent notices from being raised when you're happy with the code, then you can afford to pay more attention to the ones that do still crop up.
Hope that helps.