Magento Debug HEADERS ALREADY SENT error

Question

I am receiving the following error in my system.log file:

 2011-01-12T14:16:52+00:00 DEBUG (7): HEADERS ALREADY SENT: 
 [0] C:\xampp\htdocs\www.mysite.com\app\code\core\Mage\Core\Controller\Response\Http.php:44
 [1] C:\xampp\htdocs\www.mysite.com\lib\Zend\Controller\Response\Abstract.php:727
 [2] C:\xampp\htdocs\www.mysite.com\app\code\core\Mage\Core\Controller\Response\Http.php:75
 [3] C:\xampp\htdocs\www.mysite.com\app\code\core\Mage\Core\Controller\Varien\Front.php:188
 [4] C:\xampp\htdocs\www.mysite.com\app\code\core\Mage\Core\Model\App.php:304
 [5] C:\xampp\htdocs\www.mysite.com\app\Mage.php:596
 [6] C:\xampp\htdocs\www.mysite.com\index.php:81

I know what "headers already sent" means but I have no idea what file is causing this and the trace doesn't really give me any information.

Is there a way of finding out the offending file?

Thanks!

score 17 · Accepted Answer · edited Mar 26 '15 at 10:40

17

Here's the hard way.

Find the location in the file that's doing the logging

C:\xampp\htdocs\www.mysite.com\app\code\core\Mage\Core\Controller\Response\Http.php 
Mage::log('HEADERS ALREADY SENT: '.mageDebugBacktrace(true, true, true));

Add logging to get a copy of every file included/required so far

Mage::log(print_r(get_included_files(),true));

You can add this logging directly to the core file if you remember to restore the file to it's pre messed with condition, or you can add a temporary copy at

app/code/local/Mage/Core/Controller/Response/Http.php

as long as you remember to remove it when you're done (or just use git).

Check this list of files for the usual white-space suspects, and then check them for any functions that might produce output (echo, print, readfile, there's probably more)

edited Mar 26 '15 at 10:40

Community

1
1

answered Jan 12 '11 at 19:54

Alana Storm

164,128
91
395
599

2

This is what I was looking for thanks. I'm going to work my way through the list and will try to report back here in a few years when I'm done. Thanks! – sulman Jan 13 '11 at 09:50
To Alan Storm, could you give me an example for replicate this warning? – Josua Marcel C Sep 14 '12 at 08:27
I tried using closing php tag with empty spaces on it `?> ` but no luck – Josua Marcel C Sep 17 '12 at 03:37
1

the below method is much better, that should be the accepted answer – WonderLand May 11 '16 at 08:50

score 17 · Answer 2 · edited Mar 07 '18 at 02:53

17

Here's an easier way.

Look at the canSendHeaders method in file

lib/Zend/Controller/Response/Abstract.php

Add some logging to

public function canSendHeaders($throw = false)
{
    $ok = headers_sent($file, $line);
    // to get PHP's report on which file is sending a header.
    if ($ok !== false){
        Mage::log('File: ' . $file, null, 'exception.log', true);
        Mage::log('Line: ' . $line, null, 'exception.log', true);
    }

    if ($ok && $throw && $this->headersSentThrowsException) {
        #require_once 'Zend/Controller/Response/Exception.php';
        throw new Zend_Controller_Response_Exception('Cannot send headers; headers already sent in ' . $file . ', line ' . $line);
    }

    return !$ok;
}

edited Mar 07 '18 at 02:53

Ricardo Martins

5,702
3
40
59

answered Jan 12 '11 at 20:18

Alana Storm

164,128
91
395
599

This just logs 3 empty lines: 2011-01-13T09:59:41+00:00 EMERG (0): – sulman Jan 13 '11 at 10:00
This is not the correct syntax for `Mage::log`. I'll chalk that up to Alan being tired, that's certainly not typical of him. If you use more than 1 parameter for `Mage::log`, the second is the error level and you need the third to indicate the log file. What you really want here is `Mage::log("file: $file, line: $line")` – Mageician Apr 20 '15 at 20:47
@BrianVPS Thanks for the heads up -- I had indeed "DERP'd" the the syntax of `Mage::log` and `var_dump` in my head. Post is corrected. – Alana Storm Apr 20 '15 at 21:11

score 11 · Answer 3 · edited Jun 14 '18 at 11:19

That error is thrown from Mage_Core_Controller_Response_Http -> sendHeaders(). This function calls the super class function that actually does the check to see whether or not headers have already been sent, Zend_Controller_Response_Abstract -> canSendHeaders().

The Zend_Controller_Response_Abstract class handles, among other things, sending response headers and tracking the last time the headers were sent (and from what file and line). Here is what that function looks like, and where we'll make a change around line 316 to lib\Zend\Controller\Response\Abstract.php:

public function canSendHeaders($throw = false) {
    $ok = headers_sent($file, $line);
    if ($ok && $throw && $this->headersSentThrowsException) {
        #require_once 'Zend/Controller/Response/Exception.php';
        throw new Zend_Controller_Response_Exception('Cannot send headers; headers already sent in ' . $file . ', line ' . $line);
    }
    return !$ok;
}

To:

public function canSendHeaders($throw = false)
{
    $ok = headers_sent($file, $line);

    if ($ok) {
        Mage::log('Cannot send headers; headers already sent in ' . $file . ', line ' . $line, null, 'headers.log');
    }

    return !$ok;

    #if ($ok && $throw && $this->headersSentThrowsException) {
    #    #require_once 'Zend/Controller/Response/Exception.php';
    #    throw new Zend_Controller_Response_Exception('Cannot send headers; headers already sent in ' . $file . ', line ' . $line);
    #}
    #return !$ok;
}

This will log the error in /var/log/header.log.

This is a great answer with exactly the detail I needed to track down my problem. Using this to find the file and @xyphoid's answer to understand why, I was able to fix it. I had no idea echoing the response from an Ajax call was bad. Learn something new every day :) — Mageician, Apr 20 '15 at 20:50

score 10 · Answer 4 · answered Jul 16 '13 at 03:07

10

The most common place you run into this in Magento is when you output content directly from the controller.

Instead of doing

echo $string;

within a controller, do this:

$this->getResponse()->setBody($string);

answered Jul 16 '13 at 03:07

xyphoid

1,380
10
12

In our case the culprit is `Mage_Adminhtml_Cms_WysiwygController::directiveAction` which is outputting an image (almost) straight without using `setBody`. – jlilja Dec 08 '15 at 11:46
+1 Nice! I got this when I was echoing output instead of `$this->getResponse()->setBody($string);`. I hope, I remember next time ;) – Damodar Bashyal Nov 21 '16 at 02:26

score 5 · Answer 5 · answered Jan 12 '11 at 15:35

5

I see this too. I think it has something to do with images in WYSIWYG. Try watching the logs whilst going through the admin (especially CMS pages) and you might see it happen. It's harmless.

answered Jan 12 '11 at 15:35

clockworkgeek

37,650
9
89
127

Thanks for the reply. This is actually occurring on all front end page views though. I'm on a mission to get a clean system.log file! – sulman Jan 12 '11 at 16:12
1

then you should start looking for whites-paces before output – Anton S Jan 12 '11 at 19:46
@clockworkgeek, i did the same error but i want to replicate this, i've done by echo directly on block, controller, closing tags and whitespace but not replicated yet. how to replicate this warning? do you know how to to that? – Josua Marcel C Sep 18 '12 at 06:32
Removing the white-spaces between the html elements (as @Anton suggested) in the WYSIWIG editor for the CMS pages got rid of the warning in the OP's question. Note: opening the WYSIWYG editor for CMS pages seems to insert white spaces. Everytime I opened the WYSIWYG editor in CMS (even if just to review the html), I had to make sure to remove whitespaces... another annoying feature of Magento. – Vee Jul 30 '15 at 15:09

score 3 · Answer 6 · answered Apr 06 '13 at 13:52

Maybe it will be helpful for someone: I get similar message when I turn on Magento's WYSIWYG when editing pages in CMS -> Pages (I've got WYSIWYG disabled by default so I have to click "Show/Hide Editor" in order to enable it). If page contains CMS tags such as for example:

{{store url='my-other-page'}}

this message apears in the system.log after I click "Show/Hide Editor":

2013-04-06T11:10:38+00:00 DEBUG (7): HEADERS ALREADY SENT: <pre>[0] ...\app\code\core\Mage\Core\Controller\Response\Http.php:52
[1] ...\lib\Zend\Controller\Response\Abstract.php:766
[2] ...\app\code\core\Mage\Core\Controller\Response\Http.php:83
[3] ...\app\code\core\Mage\Core\Controller\Varien\Front.php:188
[4] ...\app\code\core\Mage\Core\Model\App.php:354
[5] ...\app\Mage.php:683
[6] ...\index.php:87
</pre>

score 0 · Answer 7 · edited Apr 29 '12 at 20:31

0

I think this might be OnePageCheckout extension problem. I have the same error in Magento, and seems that this error is not so popular. Also I have OnePageCheckout installed. But, of course, this might be just coincidence.

edited Apr 29 '12 at 20:31

Charles Menguy

40,830
17
95
117

answered Apr 29 '12 at 17:51

zzza

1

score 0 · Answer 8 · answered Feb 22 '14 at 13:39

0

Same Issue while making Ajax Call

I was getting the Log when i was making Ajax call and calling the template directly from controller.

When i changed the code and created block in layout xml file. the log error got fixed.

answered Feb 22 '14 at 13:39

Deepak Mallah

3,926
4
21
26

score 0 · Answer 9 · answered Jun 21 '16 at 15:39

0

I have the same problem while installing Magento.

In my case enabling output_buffering in PHP solved the issue.

In xampp with PHP 5.6 output_buffering is enabled by default.

In xampp with PHP 5.3 output_buffering is disabled by default.

answered Jun 21 '16 at 15:39

Frank Rochlitzer

1

score 0 · Answer 10 · edited May 23 '17 at 11:47

0

I received this error when I built my Ajax request in a "hacky" way, echoing the contents directly instead of sending them out through the layout. Once I sent them out through the layout, the errors disappeared. See my own question here:

Best way to output ajax data from a Magento Admin Extension

props to @alan for his answer to my question.

edited May 23 '17 at 11:47

Community

1
1

answered Jan 12 '11 at 21:26

Chris

1,731
3
24
38

score 0 · Answer 11 · answered Feb 16 '18 at 16:31

In our case this was a bug in Magento CE 1.9.2.4, which was fixed in Magento CE 1.9.3, happened when using WYSIWYG with images. We just made a little extension which overwrites the function directiveAction() in \app\code\core\Mage\Adminhtml\controllers\Cms\WysiwygController.php. For more Details see (in German) here.

Magento Debug HEADERS ALREADY SENT error

11 Answers11

Linked