Take the 2-minute tour ×
WordPress Development Stack Exchange is a question and answer site for WordPress developers and administrators. It's 100% free, no registration required.

I'm getting this message each time I activate my plugin:

The plugin generated 80 characters of unexpected output during activation. If you notice “headers already sent” messages, problems with syndication feeds or other issues, try deactivating or removing this plugin.

The only way I can suppress the message is to wrap my activation function code in a conditional (**see below).

How should I rewrite this to prevent the alert?

function myPlugin($post)
{
    echo "Whatever is here throws an unexpected output alert when the plugin isa activated";
//I can place code here without issue, but anything that is output via echo throws the alert.
}
register_activation_hook(__FILE__, 'myPlugin');

Wrapping the function code in the conditional suppresses the alerts:

function myPlugin($post)
{
    global $pagenow;
    if ( is_admin() && $pagenow !== 'plugins.php' ) {
        echo "No more alerts when its wrapped this way";
        }
}
 ?>
share|improve this question
    
Isn't the problem that you are outputting data in your activation hook? I don't think you're supposed to do that, since that hook will only fire once in the background, so no output will ever be seen by the user (and indeed, any output is an indication to WordPress that your plugin contains an error). –  Jan Fabry Nov 4 '10 at 13:21

4 Answers 4

up vote 1 down vote accepted

Hi @Scott B:

When you get this kind of message is usually means your plugin had a syntax error and was generating that kind of error messages because of how the loading on activation is handled, i.e. HTTP headers are sent after the error message is display. Your plugin's error message is loaded in an <iframe>; have you done a "View Source" on the <iframe> to see if there's an obvious error message?

Also, you should consider getting an HTTP debugger which can help with this kind of things:

  • Windows has the excellent and free Fiddler.

  • For Mac OS X there's HTTPScoop (not great, but inexpensive at US$15.)

  • There's also Charles for Windows/Mac/Linux (US$50 - I may break down and buy it one day. Wish I could get Fiddler on Mac, but since Fiddler comes from Microsoft I don't hold my breath.)

UPDATE

Based on the comments below, here's a screen of me using "Inspect Element" in Safari (but you can do the same with Chrome and FireFox, or similar with IE and the Web Developer Toolbar):

Screenshot of Element Inspector on Safari with the WordPress plugin error IFRAME

You can grab that <iframe>d URL and load it directly in your browser to make the process of debugging easier. Something in your plugin is sending q header() after an error message is thrown, that's what that error message means.

Loading WordPress Plugin Activation URL directly from the browser

BTW, I just added a stray character and hence syntax error in my plugin to get it to throw an error which is why you see the error as you do.

share|improve this answer
    
Thanks Mike, I'm missing the iframe element. In firefox, when I right click on the error message, there is not "View Frame Source" available. I only see "View Source". –  Scott B Nov 1 '10 at 22:18
    
The error is only occuring on activation, but no iframe is present that I can tell. –  Scott B Nov 1 '10 at 22:20
1  
@MikeSchinkel The problem only occurs inside functions that are hooked to de-/activation/uninstall hooks. You're simply not allowed to echo something there. This will close to always result in exactly the reported error. –  kaiser Dec 14 '11 at 7:55
1  
Exactly @kaiser - Thanks for your answer :) –  Zack Feb 17 '12 at 1:49
1  
@kaiser I already upvoted yours :) –  Zack Feb 17 '12 at 16:05

I've just been exploring this problem and what I've found is that the problem can be caused by errors in the php (like calling a deprecated function) which Wordpress suprresses, FTP garbling or by having code outside of the 'php' tags.

I don't think that Mike is correct above. The unexpected output issue is handled differently than a fatal error, firstly, wordpress suppresses the issue, it gives the 'unexpected output' message and more importantly it does actually activate the plugin and redirects back to the plugin page whereas with an error it just dies. I don't think that there will be anything useful in the frame and I don't think that the headers will let you the output that wordpress didn't expect which is what will provide the clues for solving the underlying issue.

There are a number of solutions to getting at the unexpected output text which require either hacking the plugins.php file or setting an event handler for the 'activate_plugin' action.

FWIW, you can find my solutions here (work in progress!) with some links to other people's solutions from which I borrowed shamelessly!

share|improve this answer
    
Completely agree. WP will suppress errors and not activate the plugin. This "error" received by the OP (and myself just now) lets the plugin activate. –  Zack Feb 17 '12 at 1:46

Sry, for the late answer, but I just stumbled upon and the answer is really simple:

Never echo anything inside functions that are used on de-/activation/uninstall hooks. This will always result in the above mentioned error message.

share|improve this answer

I had this problem too. It occured thad the plugin php file had bad encoding. I simply copied whole content to a new notepad file and saved it with ansi encoding. Error message dissapeard. Of ccourse now there are language issues but it's some other case. Regards

share|improve this answer

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.