Cannot modify header information, output started at .module:1 error SOLVED

This problem caused white screens after form submission (not exactly white screens of death, as the form submitted successfully and you could keep browsing by reloading, but a tad annoying and disconcerting all the same) and also made our Captcha image disappear.

And of course the mean red Drupal warning that told us exactly where the problem lay.

Here's bits and pieces of the error message:

warning: Cannot modify header information - headers already sent by (output started at
.module:1)
common.inc on line 141.

This problem is causing this error only occasionally, but a white screen after submitting any form every time I think. The warning is quite specific – this module, line one is what the part ending in .module:1 means – but it still took a little debugging.

I couldn't see anything wrong with the first line of the accused file in any editor on my Mac, and I couldn't see it in vi, but finally with less I could see it.

0 stedile:/var/www/wsf2008/sites/wsf2008.net/modules/wsf_action# less wsf_action.module

The first line of my file was not the clean PHP opening it appeared to be, but a horrid UTF-8 indicator:

<U+FEFF><?php

Less cannot edit a file. Pressing v to edit resulted in nano, which did not see the beginning of the file.

Agaric is beginning to think this cannot be edited out, but the file type must be changed with an off-server text file editor.

Funny thing though, we were assuming that our problem was some Korean we included in a PHP file, which forced us to save it as UTF-8– but that was the page.tpl.php file, not the wsf_action.module file.

Weirdness. (It's the Agaric way.)

Let's try this, in TextWrangler save the file (using Options) as UTF-8, no BOM.

BOM is a so-called byte-order mark, the Unicode character at code point U+FEFF ("zero-width no-break space"), and it really has no business being in UTF-8, as it is utterly unnecessary:

While UTF-8 does not have byte order issues, a BOM encoded in UTF-8 may be used to mark text as UTF-8. It only identifies a file as UTF-8 and does not state anything about byte order. Quite a lot of Windows software (including Windows Notepad) adds one to UTF-8 files. However in Unix-like systems (which make heavy use of text files for configuration) this practice is not recommended, as it will interfere with correct processing of important codes such as the hash-bang at the start of an interpreted script. It may also interfere with source for programming languages that don't recognise it. For example, gcc reports stray characters at the beginning of a source file, and in PHP, if output buffering is disabled, it has the subtle effect of causing the page to start being sent to the browser, preventing custom headers from being specified by the PHP script. The UTF-8 representation of the BOM is the byte sequence EF BB BF, which appears as the ISO-8859-1 characters "" in most text editors and web browsers not prepared to handle UTF-8.

So, on with the fix:

Ebony:~/workspace/repos/agaric/agaric-sites/5/wsf ben$ svn commit -m "saved as UTF no BOM"
Sending wsf/trunk/wsf2008.net/modules/wsf_action/wsf_action.module
Transmitting file data .
Committed revision 2874.

Do an svn update on the other end...

The file looks good in less!

Starts straight with:
<php

We shall see if that solves our problems. It does! Forms submit without a detour into blank screen land, and the image captcha is back!

Reference:
http://drupal.org/node/145358
http://drupal.org/node/67122

Resolution

So the conclusion, again, is to save the file without BOM.