Re: How to debug "Unknown: Headers already sent"?
| From: | Michael Bredthauer | 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.