Header ошибка cannot modify header information headers already sent by

No output before sending headers!

Functions that send/modify HTTP headers must be invoked before any output is made.
summary ⇊
Otherwise the call fails:

Warning: Cannot modify header information — headers already sent (output started at script:line)

Some functions modifying the HTTP header are:

header / header_remove
session_start / session_regenerate_id
setcookie / setrawcookie

Output can be:

Unintentional:
- Whitespace before <?php or after ?>
- The UTF-8 Byte Order Mark specifically
- Previous error messages or notices

Intentional:
- print, echo and other functions producing output
- Raw <html> sections prior <?php code.

Why does it happen?

To understand why headers must be sent before output it’s necessary
to look at a typical HTTP
response. PHP scripts mainly generate HTML content, but also pass a
set of HTTP/CGI headers to the webserver:

HTTP/1.1 200 OK
Powered-By: PHP/5.3.7
Vary: Accept-Encoding
Content-Type: text/html; charset=utf-8

<html><head><title>PHP page output page</title></head>
<body><h1>Content</h1> <p>Some more output follows...</p>
and <a href="/"> <img src=internal-icon-delayed> </a>

The page/output always follows the headers. PHP has to pass the
headers to the webserver first. It can only do that once.
After the double linebreak it can nevermore amend them.

When PHP receives the first output (print, echo, <html>) it will
flush all collected headers. Afterward it can send all the output
it wants. But sending further HTTP headers is impossible then.

How can you find out where the premature output occurred?

The header() warning contains all relevant information to
locate the problem cause:

Warning: Cannot modify header information — headers already sent by
(output started at /www/usr2345/htdocs/auth.php:52) in
/www/usr2345/htdocs/index.php on line 100

Here «line 100» refers to the script where the header() invocation failed.

The «output started at» note within the parenthesis is more significant.
It denominates the source of previous output. In this example, it’s auth.php
and line 52. That’s where you had to look for premature output.

Typical causes:

Print, echo

Intentional output from print and echo statements will terminate the opportunity to send HTTP headers. The application flow must be restructured to avoid that. Use functions
and templating schemes. Ensure header() calls occur before messages
are written out.

Functions that produce output include
- print, echo, printf, vprintf
- trigger_error, ob_flush, ob_end_flush, var_dump, print_r
- readfile, passthru, flush, imagepng, imagejpeg
among others and user-defined functions.
Raw HTML areas

Unparsed HTML sections in a .php file are direct output as well.
Script conditions that will trigger a header() call must be noted
before any raw <html> blocks.
```
<!DOCTYPE html>
<?php
    // Too late for headers already.
```
Use a templating scheme to separate processing from output logic.
- Place form processing code atop scripts.
- Use temporary string variables to defer messages.
- The actual output logic and intermixed HTML output should follow last.
Whitespace before <?php for «script.php line 1» warnings

If the warning refers to output inline 1, then it’s mostly
leading whitespace, text or HTML before the opening <?php token.
```
 <?php
# There's a SINGLE space/newline before <? - Which already seals it.
```
Similarly it can occur for appended scripts or script sections:
```
?>

<?php
```
PHP actually eats up a single linebreak after close tags. But it won’t
compensate multiple newlines or tabs or spaces shifted into such gaps.
UTF-8 BOM

Linebreaks and spaces alone can be a problem. But there are also «invisible»
character sequences that can cause this. Most famously the
UTF-8 BOM (Byte-Order-Mark)
which isn’t displayed by most text editors. It’s the byte sequence EF BB BF, which is optional and redundant for UTF-8 encoded documents. PHP however has to treat it as raw output. It may show up as the characters ï»¿ in the output (if the client interprets the document as Latin-1) or similar «garbage».

In particular graphical editors and Java-based IDEs are oblivious to its
presence. They don’t visualize it (obliged by the Unicode standard).
Most programmer and console editors however do:

There it’s easy to recognize the problem early on. Other editors may identify
its presence in a file/settings menu (Notepad++ on Windows can identify and
remedy the problem),
Another option to inspect the BOMs presence is resorting to an hexeditor.
On *nix systems hexdump is usually available,
if not a graphical variant which simplifies auditing these and other issues:

An easy fix is to set the text editor to save files as «UTF-8 (no BOM)»
or similar to such nomenclature. Often newcomers otherwise resort to creating new files and just copy&pasting the previous code back in.

Correction utilities

There are also automated tools to examine and rewrite text files
(sed/awk or recode).
For PHP specifically there’s the phptags tag tidier.
It rewrites close and open tags into long and short forms, but also easily
fixes leading and trailing whitespace, Unicode and UTF-x BOM issues:
```
phptags  --whitespace  *.php
```
It’s safe to use on a whole include or project directory.
Whitespace after ?>

If the error source is mentioned as behind the
closing ?>
then this is where some whitespace or the raw text got written out.
The PHP end marker does not terminate script execution at this point. Any text/space characters after it will be written out as page content
still.

It’s commonly advised, in particular to newcomers, that trailing ?> PHP
close tags should be omitted. This eschews a small portion of these cases.
(Quite commonly include()d scripts are the culprit.)
Error source mentioned as «Unknown on line 0»

It’s typically a PHP extension or php.ini setting if no error source
is concretized.
- It’s occasionally the gzip stream encoding setting
  or the ob_gzhandler.
- But it could also be any doubly loaded extension= module
  generating an implicit PHP startup/warning message.
Preceding error messages

If another PHP statement or expression causes a warning message or
notice being printed out, that also counts as premature output.

In this case you need to eschew the error,
delay the statement execution, or suppress the message with e.g.
isset() or @() —
when either doesn’t obstruct debugging later on.

No error message

If you have error_reporting or display_errors disabled per php.ini,
then no warning will show up. But ignoring errors won’t make the problem go
away. Headers still can’t be sent after premature output.

So when header("Location: ...") redirects silently fail it’s very
advisable to probe for warnings. Reenable them with two simple commands
atop the invocation script:

error_reporting(E_ALL);
ini_set("display_errors", 1);

Or set_error_handler("var_dump"); if all else fails.

Speaking of redirect headers, you should often use an idiom like
this for final code paths:

exit(header("Location: /finished.html"));

Preferably even a utility function, which prints a user message
in case of header() failures.

Output buffering as a workaround

PHPs output buffering
is a workaround to alleviate this issue. It often works reliably, but shouldn’t
substitute for proper application structuring and separating output from control
logic. Its actual purpose is minimizing chunked transfers to the webserver.

The output_buffering=
setting nevertheless can help.
Configure it in the php.ini
or via .htaccess
or even .user.ini on
modern FPM/FastCGI setups.
Enabling it will allow PHP to buffer output instead of passing it to the webserver instantly. PHP thus can aggregate HTTP headers.
It can likewise be engaged with a call to ob_start();
atop the invocation script. Which however is less reliable for multiple reasons:
- Even if <?php ob_start(); ?> starts the first script, whitespace or a
  BOM might get shuffled before, rendering it ineffective.
- It can conceal whitespace for HTML output. But as soon as the application logic attempts to send binary content (a generated image for example),
  the buffered extraneous output becomes a problem. (Necessitating ob_clean()
  as a further workaround.)
- The buffer is limited in size, and can easily overrun when left to defaults.
  And that’s not a rare occurrence either, difficult to track down
  when it happens.

Both approaches therefore may become unreliable — in particular when switching between
development setups and/or production servers. This is why output buffering is
widely considered just a crutch / strictly a workaround.

See also the basic usage example
in the manual, and for more pros and cons:

What is output buffering?
Why use output buffering in PHP?
Is using output buffering considered a bad practice?
Use case for output buffering as the correct solution to «headers already sent»

But it worked on the other server!?

If you didn’t get the headers warning before, then the output buffering
php.ini setting
has changed. It’s likely unconfigured on the current/new server.

Checking with `headers_sent()`

You can always use headers_sent() to probe if
it’s still possible to… send headers. Which is useful to conditionally print
info or apply other fallback logic.

if (headers_sent()) {
    die("Redirect failed. Please click on this link: <a href=...>");
}
else{
    exit(header("Location: /user.php"));
}

Useful fallback workarounds are:

HTML <meta> tag

If your application is structurally hard to fix, then an easy (but
somewhat unprofessional) way to allow redirects is injecting a HTML
<meta> tag. A redirect can be achieved with:
```
 <meta http-equiv="Location" content="http://example.com/">
```
Or with a short delay:
```
 <meta http-equiv="Refresh" content="2; url=../target.html">
```
This leads to non-valid HTML when utilized past the <head> section.
Most browsers still accept it.
JavaScript redirect

As alternative a JavaScript redirect
can be used for page redirects:
```
 <script> location.replace("target.html"); </script>
```
While this is often more HTML compliant than the <meta> workaround,
it incurs a reliance on JavaScript-capable clients.

Both approaches however make acceptable fallbacks when genuine HTTP header()
calls fail. Ideally you’d always combine this with a user-friendly message and
clickable link as last resort. (Which for instance is what the http_redirect()
PECL extension does.)

Why `setcookie()` and `session_start()` are also affected

Both setcookie() and session_start() need to send a Set-Cookie: HTTP header.
The same conditions therefore apply, and similar error messages will be generated
for premature output situations.

(Of course, they’re furthermore affected by disabled cookies in the browser
or even proxy issues. The session functionality obviously also depends on free
disk space and other php.ini settings, etc.)

Further links

Google provides a lengthy list of similar discussions.
And of course many specific cases have been covered on Stack Overflow as well.
The WordPress FAQ explains How do I solve the Headers already sent warning problem? in a generic manner.
Adobe Community: PHP development: why redirects don’t work (headers already sent)
Nucleus FAQ: What does «page headers already sent» mean?
One of the more thorough explanations is HTTP Headers and the PHP header() Function — A tutorial by NicholasSolutions (Internet Archive link).
It covers HTTP in detail and gives a few guidelines for rewriting scripts.

Источник

Ошибка «Невозможно изменить информацию заголовка» означает, что вы правили файлы (скорее всего, wp-config.php) вручную. И правили некорректно. Необходимо сохранять файлы в кодировке UTF-8 без метки BOM (byte order mark).

Имя файла, приводящего к ошибке, и номер строки указаны в «output started at». Например:

Warning: Cannot modify header information — headers already sent by (output started at /home/user/site.ru/public_html/wp-config.php:1) in /home/user/site.ru/public_html/wp-includes/pluggable.php on line 934

означает, что проблему вызывает 1-я строка файла wp-config.php.

Убедитесь, что перед первой строкой <?php и после последней ?> нет пустых строк.
Избегайте править файлы в Блокноте. Используйте «программистские» редакторы вроде PSpad, Notepad++ и им подобные, в которых метка BOM отключается. В Notepad++ для этого нужно выбрать в меню «Кодировки» пункт «Преобразовать в UTF-8 без BOM».

Также к предупреждению Cannot modify header information приводит вывод любых других сообщений об ошибках, предупреждений и нотаций php, предшествующих выводу заголовков.

« Вернуться к ЧАВО

Источник

Часто при переносе сайта с локального компьютера можно встретиться с ошибкой вида:

Warning: Cannot modify header information - headers already sent by (output started at …

Причины такой проблемы различные. Одни из самых распространенных это:

лишние символы, пробелы в файле;
из-за BOM в UTF.

C первой причиной все понятно — достаточно просто удалить лишние символы и проблема исчезнет.
А вот со второй проблемой намного интереснее.

Немного теории

BOM (англ. Byte Order Mark, BOM) — это метка порядка байтов Юникода, также её часто называют сигнатурой (соответственно, UTF-8 и UTF-8 with Signature).

По наличию сигнатуры программы могут автоматически определить, является ли файл закодированным в UTF-8, однако файлы с такой сигнатурой могут некорректно обрабатываться старыми программами, в частности xml-анализаторами. Многие программы Windows (включая Блокнот) добавляют байты 0xEF, 0xBB, 0xBF в начале любого документа, сохраняемого как UTF-8 — это и есть BOM.

А теперь займемся удалением BOM

Для того, чтобы удалить BOM из файлов, необходимо будет воспользоваться консолью (подключившись по SSH). Для подключения по SSH из Windows воспользуйтесь данной статьёй. Для поиска BOM‘а в файлах сайта, можно использовать команду:

$ find -type f|while read file;do [ "`head -c3 -- "$file"`" == $'xefxbbxbf' ] && echo "found BOM in: $file";done

Команда выведет список файлов, в которых были найдены BOM-символы.
Также можно воспользоваться данной командой:

$ grep -rl $'xEFxBBxBF' .

А с помощью нижеприведенной команды можно найти метки порядка байтов и сразу же удалить их:

$ find . -type f -exec sed 's/^xEFxBBxBF//' -i.bak {} ; -exec rm {}.bak ;

Удачной работы! Если возникнут вопросы — напишите нам, пожалуйста, тикет из Панели управления аккаунта, раздел «Помощь и поддержка».

Источник

Introduction

Interpreting error messages in WordPress can be a time-consuming process. Finding an adequate solution to the problem is equally as difficult.

To keep your website running like clockwork, you need to prevent long periods of downtime.

Find out how to fix the “Cannot Modify Header Information” error in WordPress and get your site up and running quickly.

Introductory image to WordPress Cannot Modify Header Information error.

What Does “Cannot Modify Header Information – Headers Already Sent By” Mean?

The “Cannot Modify Header Information – Headers Already Sent By” error indicates that a .php file cannot execute because an output is being sent before calling an HTTP header. Headers always need to precede the output.

The most common causes of the «Cannot Modify Header Information» error are:

Whitespaces before the opening <?php token.
Whitespaces after the closing ?> tag (if one is present).
An HTML block is in front of the header within the .php file.
Statements that produce output, such as print or echo, are being called before the header.
Issues with an installed plugin.

The warning message tells you which file or files you need to review to fix the issue.

Example of "Cannot Modify Header Information" error in WordPress.

In this example, the warning message indicates that the plugable.php file cannot execute due to an issue within the wp-config.php file.

Warning: Cannot modify header information - headers already sent by (output started at /home/public_html/example.com/wp-config.php:33) in /home/public_html/example.com/wp-includes/plugable.php on line 1063

You need to access and check the code within the wp-config.php file.

The message also provides the path to the file /home/public_html/example.com/wp-config.php. The number 33 points out the exact line within the code causing the error.

The file path and the code line number are an excellent starting point when troubleshooting.

Corrupted PHP File

Use cPanel or an FTP client to access the server the website is located on. It is recommended to back up files before editing them.

The examples in this guide are presented using cPanel.

Edit the File

1. Locate the file by using the path from the warning message. You can also use the search bar at the top of the cPanel dashboard.

2. Select the file and click Edit.

How to edit WordPress files using cPanel.

3. Find the code line number specified in the warning message. Use the Go To Line option to locate lines in lengthy files quickly.

4. Remove any whitespaces preceding the opening <?php token.

Locate the code line causing the error and remove all whitespaces.

5. If the file contains a ?> closing tag, ensure that there are no whitespaces after the tag.

6. Click the Save Changes tab once you remove all redundant whitespaces.

Save changes to the PHP file in cPanel.

Once you reload your webpage, the error message should disappear.

Move the Header Statement

Raw HTML elements in a .php file are rendered as a direct output. If an HTML element is placed before a header call, it can cause the “Cannot Modify Header Information – Headers Already Sent By” error.

To fix the error, place the HTML block after the header statement.

An HTML element preventing a header statement call.

Functions that produce output such as vprintf, printf, echo, flush, and print statements must follow HTTP header calls.

Review the .php file specified in the error message and correct the code. Always position header calls before the output producing elements and functions.

Replace the File

If you cannot locate the corrupt file or you are hesitant to edit the code, you can replace the entire file instead.

1. Download the latest WordPress version.

2. Use an FTP client or cPanel to upload the new version of the file to your server.

3. Overwrite the existing corrupt file with the new version.

Overwrite a corrupt PHP file in WordPress.

4. Reload the previously unavailable webpage.

You can upload and replace entire WordPress folders if the warning displays issues in multiple files.

Find the Plugin that Causes the Error

A faulty plugin can cause the “Cannot Modify Header Information” error.

1. Access your WordPress dashboard.

2. Deactivate and then Activate each plugin, in turn, to determine if one of them is causing the issue.

3. Refresh the affected webpage after every change you make.

Where to deactivate plugins in WordPress.

Focus on the recently installed or updated plugins. The error will reappear once you turn on the failing plugin.

Gather as much data as you can during this process and inform the plugin developers of the issues you encountered.

Conclusion

By following the instructions in this guide, you have successfully identified and resolved the “Cannot Modify Header Information” error.

Warning messages that flag similar issues are not uncommon in WordPress. The presented solutions are applicable in most cases with related underlying causes.

Источник

Image credits : wikipedia commons

This PHP header error results from extra empty spaces that are not suppose to be within your files. You could have unknowingly created them when you are modifying WordPress or your Theme files. You will see something similar to the following error message.

Warning: Cannot modify header information — Header already sent by (Output started at /blog/wp-config.php:34)

Locating the error

We can troubleshoot this issue by looking at the file which the error message is pointing to. Looking at the above sample error, we can see that it points to wp-config.php.

This error usually happens in wp-config.php or functions.php, because both files are most frequently edited by users. If you happen to be editing a theme file other than functions.php, then it’s highly possible that the error is from the file that you have just edited.

Therefore, it’s always good practice to keep a list of files that you have worked on. In programming, we call this file a changelog.

Troubleshooting

You will need to use your FTP program to edit the file on your server.

Use your FTP program to login to your web server.
Navigate to your file, in the example, it’s the wp-config.php.
Open up wp-config.php file.
Look for <?php at the very beginning of the file. Remove any empty space before <?php
The <?php which is the PHP opening tag should be at the very first line of the file within wp-config.php
Look for any ?> sign at the end of the file, it there is any, you will need to remove any empty space after it.
If you cannot find any ?> sign at the end of the file, you will not need to do anything. Just to play safe, you can remove empty lines.
If your error points to functions.php, you can carry out the same procedure.

Error caused by plugin

If you are unable to locate the error, and unable to fix it. There is a high chance that it’s coming from a plugin. You can disable all plugins to see if it fixes your issue. If indeed it’s cause by a plugin, you can start finding it by enabling one plugin at a time, and re-loading your website.

After you have found the plugin that’s causing this issue, you will need to disable it and report this issue to the plugin developer.

External Resources

How to fix «Headers already sent» error in PHP (stackoverflow)
Cannot modify header information — headers already sent (wordpress.org)

Did this answer your question?

Thanks for the feedback

There was a problem submitting your feedback. Please try again later.

Last updated on October 18, 2020

Источник

No output before sending headers!

Why does it happen?

How can you find out where the premature output occurred?

Print, echo

Raw HTML areas

Whitespace before `<?php` for «script.php line 1» warnings

UTF-8 BOM

Correction utilities

Whitespace after `?>`

Error source mentioned as «Unknown on line 0»

Preceding error messages

No error message

Output buffering as a workaround

But it worked on the other server!?

Checking with `headers_sent()`

HTML `<meta>` tag

JavaScript redirect

Why `setcookie()` and `session_start()` are also affected

Further links

Немного теории

А теперь займемся удалением BOM

What Does “Cannot Modify Header Information – Headers Already Sent By” Mean?

Corrupted PHP File

Edit the File

Move the Header Statement

Replace the File

Find the Plugin that Causes the Error

Locating the error

Troubleshooting

Error caused by plugin

External Resources

Возможно, вам также будет интересно:

No output before sending headers!

Why does it happen?

How can you find out where the premature output occurred?

Print, echo

Raw HTML areas

Whitespace before <?php for «script.php line 1» warnings

UTF-8 BOM

Correction utilities

Whitespace after ?>

Error source mentioned as «Unknown on line 0»

Preceding error messages

No error message

Output buffering as a workaround

But it worked on the other server!?

Checking with headers_sent()

HTML <meta> tag

JavaScript redirect

Why setcookie() and session_start() are also affected

Further links

Немного теории

А теперь займемся удалением BOM

What Does “Cannot Modify Header Information – Headers Already Sent By” Mean?

Corrupted PHP File

Edit the File

Move the Header Statement

Replace the File

Find the Plugin that Causes the Error

Locating the error

Troubleshooting

Error caused by plugin

External Resources

Возможно, вам также будет интересно:

Whitespace before `<?php` for «script.php line 1» warnings

Whitespace after `?>`

Checking with `headers_sent()`

HTML `<meta>` tag

Why `setcookie()` and `session_start()` are also affected