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 <[email protected]> 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 <[email protected]>
> *Nosūtīts:* otrdiena, 2022. gada 8. februāris 06:34
> *Kam:* Jānis Elmeris <[email protected]>
> *Kopija:* AllenJB <[email protected]>; [email protected] <
> [email protected]>
> *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 <[email protected]> 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 <[email protected]>
> *Nosūtīts:* ceturtdiena, 2022. gada 6. janvāris 21:28
> *Kam:* [email protected] <[email protected]>
> *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.
>
>