Severity: Major · Fix time: 5–15 min · Skill level: Intermediate

The Cannot Modify Header Information (pluggable.php) error is a PHP warning that appears when WordPress tries to send HTTP headers to the browser but output has already been generated — usually by a stray whitespace character before an opening tag or after a closing ?> tag in a theme file, plugin file, or wp-config.php. The error message attributes the problem to pluggable.php because that file handles authentication and session management, but pluggable.php itself is almost never the actual source.

Unlike the RSS Feed Error — which shares the same root cause of whitespace before but breaks your site's XML feed — this error breaks WordPress's ability to set cookies and manage login sessions. You'll see it when trying to log in to wp-admin or when WordPress attempts a redirect.

Need a quick map of every WordPress error? See our 70+ WordPress Errors Guide → for a categorized reference of every common WordPress issue.

[Image: Browser screen showing the PHP warning "Cannot modify header information - headers already sent by (output started at /wp-content/themes/yourtheme/functions.php:1)"]

How the pluggable.php Error Works

HTTP in WordPress works in two phases: first, PHP sends response headers (including Set-Cookie, Location, and Content-Type), then it sends the response body (HTML). Headers must be sent first — PHP enforces this rule strictly. If any output reaches the browser before WordPress calls its header-sending functions, PHP throws the "headers already sent" warning and blocks all subsequent header operations.

The error message names pluggable.php because that file includes functions like wp_set_auth_cookie() and wp_redirect() — the header-sending operations that fail. The actual cause is identified in the parenthetical: (output started at /wp-content/themes/yourtheme/functions.php:1).

Common sources of premature output:

  • Whitespace before — Even a single space, blank line, or invisible byte-order mark (BOM) before the opening tag in any loaded PHP file counts as output.
  • Closing ?> tags with trailing whitespace — PHP files don't need a closing ?> tag. When present, any whitespace or newline after it becomes output.
  • UTF-8 BOM encoding — Files saved with a BOM include three invisible bytes at the start that output before begins.

The key distinction between this error and the RSS Feed Error is context: this error breaks PHP header operations (redirects, login cookies, WordPress sessions), while the feed error specifically breaks XML parsing at your /feed/ URL. Both trace back to whitespace before , but they affect different parts of your site and require you to look in different places.

Check This First — 2-Minute Diagnostic

  1. Read the full error message — It tells you the exact file and line number where premature output starts. Look for output started at /wp-content/themes/yourtheme/functions.php:1.
  2. Enable WP_DEBUG — Add define('WP_DEBUG', true); and define('WP_DEBUG_DISPLAY', true); to wp-config.php temporarily to surface the full error if it's not displaying.
  3. Check functions.php first — This is the most commonly edited theme file and the most frequent source of accidental whitespace. Verify the very first character is < from .
  4. Check recently installed or edited plugins — The error often appears immediately after adding or editing a plugin.
  5. Look for BOM encoding — Open the suspect file in Notepad++ and check the encoding. "UTF-8 BOM" means re-saving as "UTF-8 without BOM" is required.

Purpose & Benefits

1. Understanding This Error Protects Your Login System

The "headers already sent" error can completely break WordPress's login flow — redirects fail, cookies don't set, and login loops result. For a business that relies on wp-admin to publish content or run WooCommerce, a broken login is a full site outage. Resolving it quickly keeps your admin access reliable.

2. The Root Cause Affects Multiple Systems Simultaneously

Whitespace before in a heavily-loaded file like functions.php also breaks RSS feeds, interferes with plugin redirects, and can produce white screen of death symptoms. Fixing the single source file repairs all of these simultaneously.

3. Proper File Encoding Is a Development Standard

Every developer working on your WordPress site should save PHP files as UTF-8 without BOM and without a closing ?> tag. This documented PHP best practice prevents the "headers already sent" error class entirely, across all plugins and themes your team touches.

Examples

1. Whitespace Before

A site owner adds a code snippet to functions.php using their hosting control panel's file editor. The editor adds a blank line before the existing tag on save, or the snippet is pasted in with a leading newline.

<?php
// CORRECT: The opening <?php tag is the very first content in this file.
// No blank lines, no spaces, no BOM characters appear before this line.
// This is the only correct way to start a WordPress PHP file.

function my_theme_setup() {
    // Theme setup code here
}
add_action('after_setup_theme', 'my_theme_setup');

// No closing ?> tag at the end — omitting it is best practice.

Connect via SFTP, open functions.php in a proper code editor, and delete any content before . Save as UTF-8 without BOM.

2. Closing ?> Tag with Trailing Content

A custom plugin file ends with ?> followed by a blank line. Every time PHP processes this file, it outputs the blank line before WordPress can send headers. The fix: remove the ?> and everything after it. PHP files don't require closing tags — omitting them is best practice throughout WordPress core.

3. BOM Encoding Introduced by an FTP Client

A developer uses an older FTP client to download, edit, and re-upload functions.php. The FTP client silently re-encodes the file as UTF-8 BOM. The three-byte BOM sequence is invisible in most editors but is treated as output by PHP.

Fix: open the file in Notepad++ → Format → Convert to UTF-8 (not UTF-8-BOM) → Save → Re-upload. In VS Code, click the encoding indicator in the status bar and select "Save with Encoding → UTF-8."

Common Mistakes to Avoid

  • Editing pluggable.php directly — The error message names pluggable.php as the file that failed, not the file with the bug. Editing pluggable.php accomplishes nothing and damages a core WordPress file. The source is always listed in the parenthetical.
  • Adding ob_start() as a universal fix — Output buffering hides the symptom, not the cause. Find and remove the rogue whitespace instead.
  • Using a plain text editor like Notepad — Windows Notepad can save files with BOM encoding. Use a proper code editor (VS Code, Notepad++, Sublime Text) set to save as UTF-8 without BOM.
  • Not checking after adding a theme snippet — Tutorial code snippets frequently include leading whitespace. Review pasted code before saving.
  • Forgetting to disable WP_DEBUG after fixing — Leaving debug mode enabled in production exposes PHP notices to site visitors. Set WP_DEBUG back to false once the fix is confirmed.

Best Practices

1. Open the File Named in the Error Message

The error names the exact file and line number where premature output begins. Open that file — not pluggable.php — and check the first line for whitespace before and the last line for whitespace after ?>. This two-point check resolves 90% of cases.

2. Omit the Closing PHP Tag in All Plugin and Theme Files

PHP files don't require a closing ?> tag, and including it creates risk with no benefit. WordPress's own code omits closing PHP tags throughout the codebase. Follow the same convention.

<?php
/**
 * Theme functions and definitions.
 * Note: No closing ?> tag at the end of this file. This is intentional.
 */

function my_theme_custom_function() {
    // Function code
}
add_action('init', 'my_theme_custom_function');

// File ends here — no closing tag

3. Validate PHP Files Before Uploading

Before uploading any edited PHP file, run a basic syntax check. If you're using the command line:

# Check a PHP file for syntax errors before uploading
php -l /path/to/functions.php
# Output if clean: No syntax errors detected in functions.php

This catches missing semicolons, bracket mismatches, and BOM encoding issues before they reach your live site.

4. Use a Staging Site for PHP Edits

Any edit to functions.php or a plugin file carries risk. Use a staging site to test changes before applying them to production. If the edit introduces a "headers already sent" error, you can diagnose and fix it without affecting visitors or breaking your live login access.

Frequently Asked Questions

What causes the pluggable.php error most often?

Whitespace before in a theme or plugin file — specifically functions.php, which loads on every page. The second most common cause is a UTF-8 BOM character introduced by a text editor or FTP client. Both are invisible in most editors.

How do I fix this when locked out of wp-admin?

Connect via SFTP and edit the file named in the error message directly. If you can't read the full error, rename your theme folder to force WordPress to load a default theme — that often restores login access.

Can this error hurt my SEO?

Yes. If the error causes pages to return a 500 Internal Server Error to crawlers, Google may de-index affected pages. The RSS Feed Error — same whitespace root cause — also breaks content syndication. Fix this immediately.

How is this different from the RSS feed error?

Both are caused by whitespace before . This error breaks PHP header operations — redirects, cookies, login — visible on wp-admin pages. The RSS Feed Error breaks XML parsing at /feed/. Fix the whitespace and both problems resolve together.

Is pluggable.php safe to edit directly?

No. It's a WordPress core file — edits get overwritten on every update. The error points to pluggable.php because that's where the header operation failed, not where the problem lives. Never modify core WordPress files to fix this error.

Related Glossary Terms

How CyberOptik Can Help

Still broken? Our team fixes WordPress errors like this in under 30 minutes for maintenance clients. The "headers already sent" error class reads as intimidating but resolves quickly once you know which file to edit. If you're locked out of wp-admin or can't identify the source file from the error message, we can diagnose and resolve it directly. Our WordPress maintenance plans include code review support so changes to your theme and plugins don't introduce new errors. Contact us to get your site back to normal.