Re: How to debug "Unknown: Headers already sent"?

From: Date: Sun, 13 Feb 2022 17:14:01 +0000
Subject: Re: How to debug "Unknown: Headers already sent"?
References: 1  Groups: php.general 
Request: Send a blank email to php-general+get-327912@lists.php.net to get a copy of this message
Poop Sent from my iPhone > On Feb 13, 2022, at 11:52 AM, Negin Nickparsa <nickparsa@gmail.com> wrote: > >  > search for session_start() in your code and replace it with this: > > > (!isset($_SESSION)) { > // server should keep session data for AT LEAST 24 hour > ini_set('session.gc_maxlifetime', 60 * 60 * 24); > // each client should remember their session id for EXACTLY 24 hour > session_set_cookie_params(60 * 60 * 24); > session_start(); > } > > Sincerely > Negin Nickparsa > > >> On Wed, Feb 9, 2022 at 11:52 AM Jānis Elmeris <janis.elmeris@lv.lv> wrote: >> Thank you for the suggestions! >> >> The big problem of debugging by disabling/enabling plugins is that the error cannot be >> reproduced consistently. You may browse the store, doing similar actions for 10 min, and you're >> lucky if you get one "headers already sent" error message. So, if you keep browsing for 10 >> min and no error occurs, it doesn't mean it will not occur in the next 10 min. >> >> 'WP_DEBUG', 'WP_DEBUG_LOG' constants would not really help, because the >> message gets output before those constants are defined or getting checked. As I wrote, the warning >> occurs before any of the WordPress' PHP code gets executed. >> >> And as I told, the error message does not tell me 'headers already sent by >> "plugin name"'. The full error message is as follows: >> "PHP Warning: Unknown: Headers already sent. You cannot change the session >> module's ini settings at this time in Unknown on line 0" >> >> I'm not sure what is trying to change what session settings before any PHP code gets >> executed, and how can the headers already be sent at that point. >> >> Janis >> >> No: Negin Nickparsa <nickparsa@gmail.com> >> Nosūtīts: otrdiena, 2022. gada 8. februāris 21:01 >> Kam: Jānis Elmeris <janis.elmeris@lv.lv> >> Kopija: php-general@lists.php.net <php-general@lists.php.net> >> Tēma: Re: Atb.: How to debug "Unknown: Headers already sent"? >> >> you can post this in wordpress community support, they should be able to help you. >> >> enable your debugs first and show more details >> define('WP_DEBUG', true); >> define('WP_DEBUG_LOG', true); >> define('WP_DEBUG_DISPLAY', false); >> Issue is not nginx, your best bet is plugins, one of them is sending it early, it usually >> should tell you headers already sent by "plugin name" if you have all logs enabled. >> >> After this, when you see a better presentation of errors, if the error was inside a plugin, >> by this far you would know the plugin name inside the error. >> If not , still disable plugins half and half and if an issue happens in that half of >> plugins again disable half until you find the culprit. >> >> somewhere in plugins should be your focus. also switch templates and see if culprit is >> there. >> >> Negin Nickparsa >> >> >> On Tue, Feb 8, 2022 at 2:04 AM Jānis Elmeris <janis.elmeris@lv.lv> wrote: >> Thank you for the reply! >> >> So, in Magento, every time the site sends any kind of response back to the client, you log >> the backtrace of who has called the response controller? >> >> I don't think it would help me (in my case it's Wordpress), because the headers >> warning is output even before the Wordpress code starts to get executed (even before >> "auto_prepend_file" gets executed). >> >> Janis >> >> No: Negin Nickparsa <nickparsa@gmail.com> >> Nosūtīts: otrdiena, 2022. gada 8. februāris 06:34 >> Kam: Jānis Elmeris <janis.elmeris@lv.lv> >> Kopija: AllenJB <php.lists@allenjb.me.uk>; php-general@lists.php.net >> <php-general@lists.php.net> >> Tēma: Re: How to debug "Unknown: Headers already sent"? >> >> for me that I use Magento, it is pretty easy we would use a controller specifically the one >> that is sending the requests to the client, then do a backtrace and log the backtrace and see where >> in the file that echo culprit is, however for your case I do not know with pure PHP but maybe try to >> debug where you are sending the HTTP requests whatever platform you are using. >> >> Negin >> >> >> On Fri, Jan 7, 2022 at 4:13 AM Jānis Elmeris <janis.elmeris@lv.lv> wrote: >> Thank you for the reply! >> >> I added error_logs before all the ini_sets I could find. When I browsed the Woocommerce, I >> got the error three times in about 10 minutes. Looking at the error log, it seemed that one time the >> error occurred right before one specific ini_set call, but the two other cases didn't have >> explicit ini_set calls in the code around the time the "Unknown: Headers already sent." >> error appeared. So, I guess that the first one was just a coincidence. >> >> I'm somehow not too hopeful of finding the problem in the PHP code seeing as PHP >> engine itself does not know which PHP code file causes the problem. So, I suppose, the problem >> should be on some other level, shouldn't it? >> >> I saw someone on the Internet mentioning XDebug as a way to debug something like this but >> gave no details. Would you have any idea on how to use XDebug for such cases? >> >> Janis >> >> No: AllenJB <php.lists@allenjb.me.uk> >> Nosūtīts: ceturtdiena, 2022. gada 6. janvāris 21:28 >> Kam: php-general@lists.php.net <php-general@lists.php.net> >> Tēma: Re: How to debug "Unknown: Headers already sent"? >> >> >>> On 06/01/2022 17:13, Jānis Elmeris wrote: >>> How can I try debugging the "Unknown: Headers already sent. You cannot change the >>> session module's ini settings at this time in Unknown on line 0" warning, when PHP is not >>> giving any more details except that it happened (no info on what's trying to send the headers >>> or where the output had started). >>> >>> This warning happens from time to time only. (In my case, it happens when I browse a >>> Woocommerce store. It has happened in the local dev environment when I click on a product, when I >>> click on adding product to the cart, when I click to checkout. But it happens rarely. Mostly, all >>> the requests are processed all right, no PHP warnings.) >>> >>> Almost everything that I found about "headers already sent" on the Internet, >>> refers to the cases when the PHP code is written in a way that outputs some content before sending >>> the headers, in which case the PHP gives a reference to the PHP code that's in some way related >>> to the error. But the "unknown" cases are different. >>> >>> I found that this error may be caused by repeatedly loading the same PHP extensions, or >>> by some PHP extension working incorrectly. For example, "zlib" extension has had such >>> problem when executing "ob_gzhandler". >>> >>> I looked at the PHP configuration and didn't see an extension being loaded more >>> than once. Regarding "ob_gzhandler", I found only one place in the Wordpress code using >>> it, and added a log there. Then I got a headers already sent warning message, but the >>> "ob_gzhandler" had not been used in that request. >>> >>> So, how could this warning be tracked down? Can I use XDebug somehow to do it? >>> >>> I'm using PHP 7.4 FPM. >>> >>> Regards, >>> Janis >> >> The error message is specifically complaining about ini settings being set. I would check >> the code for any calls to ini_set(), specifically that are modifying ini settings relating to >> sessions (which all start with 'session.' - see >> https://www.php.net/manual/en/session.configuration.php ). If you >> can then trace when / where this code is called, this might help you work out what's going on. >> >> When the issue does occur, try to note down what you were doing when it happened. What were >> the last few actions you did? These may help you to work out how to reproduce the issue. >> >> As you appear to be using WooCommerce, I would try their support forums / chat as they may >> know of issues specific to that application or any popular plugins / extensions: >> https://developer.woocommerce.com/ >> >> You might also want to try forums / chat for WordPress as WooCommerce is built on that. You >> may also want to check all your plugins are up-to-date, look for any which haven't been updated >> by their developers in a long time and disable any which aren't being used.

« previous php.general (#327912) next »