headers_sent() issue with plugins and instant website

Hi Glenn

Thanks for looking into this! Spaces in plugins can defintiely be a problem when headers are being sent. This is something I've run into myself a few times so I am quite familiar with how frustrating that can be.

If you are still having trouble with sporadic error messages, could you shoot us over a full support ticket? I'd like to take a closer look myself :).

Thanks!

Hi Ross

No, I'm not having sporadic messages, I've already diagnosed and solved the problem.

The purpose behind my post was/is two fold:
1. To let you fellows at IAT and IW users know of a potential problem.
2. To identify to new and I suppose veteran plugin developers that there is a potential issue/problem when creating/saving a plugin.

The second issue is a result of IAT not having any documentation available for new users or newbie plugin developers.

You guys nailed it when you created and released CMSB and the plugin's set it apart from any other software I've worked with.

Unfortunately IAT's lack of documentation sucks which is why I created my own tutorial on Plugins. I have been writing and updating it for my own benefit and I don't mind sharing it with your community.

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

If I were to make a suggestion it would be that in a future release of Instant Website, you either remove the headers_sent() or set it to provide the site owner/developer a more meaningful message. The error message is meaningless to the site visitor and it doesn't even give the visitor a link to report the error to anyone.

As it stand the site owner is completely unaware that their site is not available to some visitors. A CMSB user could be using a third party plugin thus generating the error and not know about it.

Considering the page displays just fine with the headers_sent() commented out clearly suggest this should be handled in a different manner.

Since the issue is part and parcel with how to create plugins I included it in this post.

Now, if you could tell me/us why some site visitors trigger the error while others do not, I would be most interested in knowing.

In my tests, one site visitor triggers the error every time. The only thing that I know is that they have a satellite internet connection. I'm guessing that it's the satellite's request and server's response during the connection protocol that is triggering the error. However, I tested it with a buddy who has a satellite connection and there was no error so I'm really baffled. Got any ideas as to why this is the case?

Thanks for taking time to read and respond.

Hi Glen,

I've updated the error message to show the source of the whitespace as so:

if (headers_sent($file, $line)) {
die("You must load " .basename(__FILE__). " at top of file! Make sure there are no extra spaces before
it (or at the end of any plugins)! Output started in $file line $line.\n");
}

>Now, if you could tell me/us why some site visitors
>trigger the error while others do not, I would be most
>interested in knowing.

I'm curious about that too, because I would imagine if there was extra whitespace sent it would affect all users. What was the file and line that was reported when you received errors by mail?

Thanks!

Hi Dave.

The problem with using "die(...)" is that the its the site visitor that is seeing error message. The site owner or developer will never know about. Unless the site visitor knows the site owner they are just going to move on to the next site.

I only became aware of the problem because the site visitor called me.

What's weird is that the page will still display even if the headers_sent() was triggered which reinforces the point that there is no need to stop execution of the script.

The initial error was a result of a plugin I had written. I have a tendency to add white space to the bottom so that I'm look at the code in the middle of the screen.

During my testing I added various amounts of new lines to different plugins at different times and my email error message always identified the last line of the file I was testing. Only active plugins generated the error. So basically the error can be caused by any plugin that has "more than one line" after the closing php tag.

I tried generating the errors by accessing the site from my neighbors cable connection, my buddies satellite connection and via W3C's validation scripts which was another form on external access. I could not generate the error.

However, during the testing stage I did receive access errors from other IP addresses other than the person who was assisting me from Toronto. This tells us that it isn't an isolated situation.

I'm still of the belief that it has to do with establishing the communication protocols during the request/response/ack stage via their ISP's satellite or possibly some weird ISP's DHCP configuration between them and their clients.
After all Telus thinks they know it all and yes they are down east as well.

I think you should consider not using die(). Even echo or print would at least allow the page to display.
As for me, I'm going to leave the email notification in place since I do have that tendency to add white space while developing.

ps. To help determine whether or not this is a real issue maybe other users of IW could use the email notification and deliberately add a few extra lines to one of their active plugins.

pps. I have created and activated a plugin with extra line feeds. Click to see if your connection displays the error.
http://www.canadiandomainregistry.ca/cmsDemo/index.php
The page will either display normally or die() and send me an email.

Hi Glen,

If you send headers after you've sent content you'll get a warning from PHP regardless, so the idea with the die call is it shows just that one error and nothing else so it's more noticable instead of PHPs default warning somewhere in the page content, which looks like this: "Warning: Cannot modify header information - headers already sent by ...".

The problem with removing that line (or sending content before headers such as with whitespace in plugins) is that if header have already been sent (which means page content or whitespace has been sent) no more HTTP headers can be sent (and you can't set cookies or, session values either). So, for example, this would produce a "headers already sent" error:

print " ";
ob_flush();
header("HTTP/1.0 404 Not Found");
print "<h1>404 Not Found</h1>";
print "done";

I'm thinking it may be a server-side caching issue. That IIS sometimes hasn't yet sent the content to PHP so PHP doesn't know headers have been sent. Can you try adding this line and let me know if you get the error all the time?

ob_flush();
if (headers_sent($file, $line)) {
die("You must load " .basename(__FILE__). " at top of file! Make sure there are no extra spaces before
it (or at the end of any plugins)! Output started in $file line $line.\n");
}

Anyways, with Instant Website I don't think it's matters much and it's pretty safe to remove that line. All it does is prevent you from getting a different error when the 404 code is called. So if it's not proving helpful removing it is probably the way to go.

Also, it gives me an idea that maybe we could auto-detect the whitespace at the end of plugins in CMSB init and warn developers about it.

Let me know if ob_flush() gives you different results (and if you have any extensions that automatically gzencode/compress output or anything like that.

Thanks!

Hi Dave

I added a link to the previous post to have people test to see if they get the error.

I did as you requested and added ob_flush().
The page failed with the error message. I refreshed a half dozen times and the error message displayed every time.

I've now commented out ob_flush() and reactivated the faulty plugin to see if users from the forums will see the page or the error.
http://www.canadiandomainregistry.ca/cmsDemo/index.php

I see the page...

Hmm, I did some more testing and headers_sent() seems pretty inconsistent and problematic.

I've removed it from website_init.php. Thanks for the tip! :)