Bit of an odd one, but my development activity has been crippled by the loss of error messages in my DevTools. It was working yesterday, and from what I can see nothing on my system has changed.
The issue isn't browser related as it's impacting Chrome, FireFox and Edge; none of them display errors any more:
I saw in another SO question that someone had xDebug installed which was apparently caused this same issue for many folks. I also had it installed and believe I have removed it completely (perhaps there are remnants of its config somewhere?). Unfortunately I'm no better off from removing it.
Now that I can safely say the issue isn't browser related, I guess it can only be either my PHP config or Apache(WAMP) config?
The following PHP functions are compiled on my development environment, but I also wrote them at the top of my broken script for good measure and it made no difference.
error_reporting(E_ALL);
error_reporting(-1);
ini_set('error_reporting', E_ALL);
PHPInfo() confirmed that I'm showing and logging PHP errors also:
I got a little fed up so I uninstalled WAMP64 and installed the latest version (I know, taking a sledgehammer to crack a nut...) and it hasn't helped.
Any ideas?
Related
Since about a week I've got a very strange caching problem. I did not make any changes I know of which could possibly lead to this problem.
It happens using:
PHP 8.1.9
Apache 2.4.48 or the built-in symfony web server
PHPStorm or notepad++
symfony or just plain PHP
Firefox or Edge
My output gets cached somehow. I can completely destroy the PHP code or rename/delete files -> still displayed correctly. Some time later it finally refreshes and displays the errors. The errors themselves don't get cached. Fixing them immediately returns the script to the expected behaviour. I've already disabled caching inside Firefox (in the settings and setting disk.cache.enabled to false), but it happens with Edge, too.
The only common thing my experiments share is the PHP version/installation, it probably does not have to do anything with Apache, symfony or the browser.
Any ideas?
I've found the answer.
Somehow opcache.revalidate_freq inside the php.ini was set to 200 and zend_extension=opcache enabled. I've never changed this manually. Would be interesting to find out what caused the change.
My php code is in the hostgator server and since I have to write a few scripts I don't have to install the wamp/lamp server.
I did a bit digging and found extensions namely PHP console. I added it and tested once, it showed me the line number of the errror.
But after a few hours when I tested the extension it is not working anymore for the same script and the same error.
I also tried another popular extension called Xdebug helper. But that also seems to be not working.
To test I have removed a semicolon in my working script and the link is : http://arqamahmad.com/music_app/getmusic.php
PS : I am using a shared hostgator server and I have done my research on the .htaccess and php.ini files. Nothing is helpful. The PHP console extension was the best but there seems to be some problem to that.
Answer : I had to add a php.ini file inside public_http making allowing the php debug mode on then only it the extensions work.
For Firefox, there is FirePHP (http://www.firephp.org/) in combination with Firebug. There is a similar extension for Chrome, but I haven’t tested that (https://github.com/itsgoingd/clockwork-chrome).
The general thing is that you need to somehow transfer your error messages from PHP back to the client. If you don’t want to use a browser extension for that, you can also use an approach chosen by many frameworks (e.g. Symfony): add an admin module in your page, where the error messages are displayed (you need to intercept errors on the servers for that, by registering a custom error handler).
Edit: This of course requires PHP to output error messages at all, which depends on (among others) the php.ini settings like error_reporting, which need to be set to a level that the errors you desire for reporting will trigger the error handler functions.
Concerning your remark about Xdebug: to use Xdebug helper, Xdebug (a PHP extension for debugging) needs to be available on the server, which it usually is not on production systems.
Since php is executed on the server side, no browser add-on will help you. You need to add a few lines of code to the php file to show the errors.
Here's a link for you: https://stackoverflow.com/a/21429652/6735510
I have a few small scripts installed on my server and was trying to debug yesterday. To show errors on page I set Display_errors= on in the phpsettings of my cloudlinux cpanel. this didn't show errors on page and after trying out different php versions I gave up for a few hours. When I came back to give it another try I noticed that php errors were showing on my pages.
This was the first thing I couldn't understand.
After much time spent on slowly debugging I am down to only a few minor notices and errors and I would like to turn off php errors again untill I can get back to the rest in a few days or possibly weeks.
I went back to set display_errors= off in my cloudlinux cpanel but all errors are still showing.
mysite.com/phpinfo.php shows diplay_errors is set to off. I have tried searching for any rogue php.ini files, but there are none. I cant find anything in my htaccess files either. The index.php files of my scripts are also not showing any error settings.
I have rebooted the server completely, cleared pc caches, tried multiple different devices, restarted apache. all to no avail.
Even with ini_set('display_errors', 'Off'); at the top of my index.php file The errors are still showing
Link to page with errors: http://urlgone.com/162e2a/
Can anyone recommend how I can track down what is causing errors to display. Been stuck on this for hours and I feel like i'm just going in circles now.
For some reason, I get a HTTP 330 error whenever a PHP error is printed. This didn't use to happen, but since we had to restore our PHP application from a backup due to a server failure, it does. During that restoration, we switched over from using Apache to nginx + fastcgi. However, I'm also running the application locally, and I'm noticing the same issue on Apache, but only when using php 5.3.X. The application used to run on 5.2.11.
Has anyone encountered anything like this before? The only thing that googling has brought up is that maybe the PHP errors are sent using one encoding, and the rest of the content is sent gzipped, but I have no idea how to fix that - if it even is the problem.
Please ask if you need any more information. I'm not quite sure what information I could provide you with that would be helpful.
Enabling zlib compression in php.ini (zlib.output_compression = On) and then removing any ob_start("ob_gzhandler"); from the scripts seems to have solved the problem.
I've been experiencing a safari problem while building a web application. The screen goes completely blank (white) and refreshing won't help. Going to another page on the site gives the same problem. Then magically, after a little while, everything goes back to normal and pages are rendered correctly!
This started happening around the same time that I SUSPECT my hosting automatically upgraded from PHP 5.2.x to 5.3 (all of a sudden, we got 'deprecated function' errors and the error settings and handling were unchanged)
I also have to mention that this doesn't happen in our dev environment (PHP 5.2.9, Apache 2)
Settings
Safari 4.0.2 and the latest one (don't know the version)
Server side: PHP 5.3, MySQL 5.0.90, Apache is cPanel Easy Apache v3.2.0
Does anyone know why this is happening at all or know how to fix it?
If it happens with other browsers as well as safari it is probably an error message generated but not displayed. Depending on your code these can be time dependent.
If you have an error log file on your server check it's content.
You should also set up a PHP 5.3 development environment as quickly as possible. There are things that can go wrong when upgrading from 5.2. to 5.3 (see this page and yes, you can get angry at your provider, the PHP site does not advice an upgrade without a code check).