Headers already sent after a PHP upgrade

Before you start

Save the complete error message and its timestamp in a private note. Record which page or action triggers it and what changed immediately beforehand. A screenshot of a blank page gives a developer less to work with than the first relevant log entry.

Do not post passwords, customer information or complete server paths in a public support thread.

Back up both files and the database before changing anything. Check how you would restore that backupA backup is a separate copy of your website's files and database, so you can bring the site back after a mistake, a hack or a failed update. too. Prefer a restricted test copy using the same PHP versionA PHP version is a numbered edition of PHP, like 8.3. Each edition is looked after for a limited time, then gets security fixes only, then nothing..

Disable real payments and outgoing customer emails on that copy. Change one thing per attempt and keep a note of it, so you can reverse an unsuccessful change without guessing what the previous setting was.

What happens in plain language

A web response contains control information and content. Headers provide that control information, including instructions for cookies or redirects. Once headers have been sent, PHP cannot change them afterwards.

The warning therefore often identifies two places: where output began and where code later tried to set a header.

This is not a new rule introduced by PHP 8. An upgrade can expose an earlier warning, producing unintended output. Text outside PHP code or an unwanted character at the start of a file can also be clues.

Investigate the first output rather than treating the final warning as the whole problem.

Five steps to a repair

1. Save both file references from the message. Record the action, such as submitting a form or signing out. Check private logs for entries immediately before the header warning. An earlier message may identify a separate problem that needs to be repaired first.
2. On the test copy, check whether errors are being printed into the page. Have the administrator review the production display setting and keep diagnostics in private logs. Preserve the earlier error for the developer, so the investigation does not end merely because visitors no longer see its text.
3. Have the file named by output started at compared with a known working version. Look for inserted text, unintended whitespace or an encoding change. Do not remove all whitespace from files indiscriminately. Change only the confirmed source of unwanted output.
4. Review the order of the application logic. Cookies and redirects need to be set before output commits the headers. For a pluginA WordPress plugin is an add-on you install in WordPress to give your site extra features, such as contact forms, SEO tools or a webshop., test an available supplier update first. Output buffering can change the behaviour, but it is not a substitute for identifying incorrectly placed output.
5. Retest the affected journey in a fresh browser session. Check that the redirect reaches the right page and that the login persists after a refresh. Compare new log entries with the original timestamp and record which component was actually repaired.

Why the last line can mislead

Imagine an older plugin printing a deprecationA deprecation is an early warning that a feature still works today but will be removed in a future PHP version, so code using it must be changed in time. warning before a login redirect runs. The redirect might appear last in the log while the earlier output started the problem. This is a scenario to investigate, not a diagnosis without evidence.

Check the sequence before asking someone to rewrite the login feature.

When to get help

Use the help form below when sessions, payments or several plugins are affected. Get assistance too if you are unsure how to edit files without an unintended encoding change. Share both locations from the warning privately, together with the first preceding error.

That gives a developer a focused starting point for following the chain of output.

Check the result

Repeat the exact action that failed first. Then check login, a form submission and the main journey through your website. For a store, use a test order without a real charge.

Read the log for fresh messages with a recent timestamp. A working homepage alone does not establish that every affected function works again.

Keep the version numbers, the change and the outcome with your maintenance notes. Agree who will check the next update. Stop if the same error returns after the suspected cause has already been addressed.

Revisit the diagnosis instead of changing an increasing number of settings together. The aim is a repeatable repair that someone else can understand and verify.