}
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@xxxxxxxxx>
Nosūtīts: otrdiena, 2022. gada 8. februāris 21:01
Kam: Jānis Elmeris <janis.elmeris@xxxxx>
Kopija: php-general@xxxxxxxxxxxxx <php-general@xxxxxxxxxxxxx>
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 detailsdefine('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@xxxxx> 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@xxxxxxxxx>
Nosūtīts: otrdiena, 2022. gada 8. februāris 06:34
Kam: Jānis Elmeris <janis.elmeris@xxxxx>
Kopija: AllenJB <php.lists@xxxxxxxxxxxxx>; php-general@xxxxxxxxxxxxx <php-general@xxxxxxxxxxxxx>
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@xxxxx> 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@xxxxxxxxxxxxx>
Nosūtīts: ceturtdiena, 2022. gada 6. janvāris 21:28
Kam: php-general@xxxxxxxxxxxxx <php-general@xxxxxxxxxxxxx>
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.