Support for Drupal 7 is ending on 5 January 2025—it’s time to migrate to Drupal 10! Learn about the many benefits of Drupal 10 and find migration tools in our resource center.
By typehost on
The site was fully functional and suddenly these errors appeared:
Warning: session_start() [function.session-start]: Cannot send session cache limiter - headers already sent (output started at /home/client/public_html/index.php:1) in /home/client/public_html/includes/bootstrap.inc on line 860
Warning: Cannot modify header information - headers already sent by (output started at /home/client/public_html/index.php:1) in /home/client/public_html/includes/bootstrap.inc on line 531
Warning: Cannot modify header information - headers already sent by (output started at /home/client/public_html/index.php:1) in /home/client/public_html/includes/bootstrap.inc on line 532
Warning: Cannot modify header information - headers already sent by (output started at /home/client/public_html/index.php:1) in /home/client/public_html/includes/bootstrap.inc on line 533
Warning: Cannot modify header information - headers already sent by (output started at /home/client/public_html/index.php:1) in /home/client/public_html/includes/bootstrap.inc on line 534
Warning: array_key_exists() [function.array-key-exists]: The second argument should be either an array or an object in /home/client/public_html/includes/module.inc on line 217
Warning: array_key_exists() [function.array-key-exists]: The second argument should be either an array or an object in /home/client/public_html/includes/module.inc on line 217
I have checked through the site, changed some of the files to correct "extra spaces" at the end of files, but it didn't fix anything. Referenced these posts and many others on the topic:
But no closer to diagnosis. In php.ini:
; Initialize session on request startup.
session.auto_start = 0
Caching is disabled in admin - the site is running Drupal 5.5.
The site administrator says the only thing he has done was "run the Send Studio PHP script" in a subfolder on the same domain. I have been through the site and the forums but come no closer to finding the problem. Any help or suggestions welcome.
NOTE:
One other thing I am confused about is why the header is set to expire in 1978 in bootstrap.inc code lines 530 to 535:
function drupal_page_header() {
header("Expires: Sun, 19 Nov 1978 05:00:00 GMT");
header("Last-Modified: " . gmdate("D, d M Y H:i:s") . " GMT");
header("Cache-Control: store, no-cache, must-revalidate");
header("Cache-Control: post-check=0, pre-check=0", FALSE);
}
Is this standard in Drupal and would changing this date fix the problem? I've checked this also in Drupal 5.7 and the date is the same.
Is this an issue better sent to the web hosting provider?
Comments
One quick and easy thing to
One quick and easy thing to try is to clear (not empty) the sessions table in the database. While there you can also clear the cache and cache* tables, then see what happens.
----------------------------------------------------------------------
http://www.bwv810.com/
I am a writer and researcher. In my spare time I build websites with Drupal.
Je peux communiquer en français. / Я могу общаться на русском языке.
hostgator
I found out that the hosting company, Hostgator, upgraded the servers from PHP 4 to PHP 5 without notifying the client. Would that cause something like this?
PHP injection attack
According to the host this was caused by a PHP injection attack:
"Upon further investigation, this appears to be the result of a php injection attack as there was an iframe inserted at the top of your index.php file. I have removed the iframe line so the site is now working and am forwarding this to our security department for further assistance."
The site needs to be upgraded to 5.7.
What do you mean by "clear (not empty)"?
What is the fine distinction you were trying to emphasize here? It looks like I have a similar problem with 6.x after an upgrade of Linux distro. First, I could not get it out of the "maintenance" mode (I think I was still seeing that page just from cache), now it is a blank page with
Warning: session_start() [function.session-start]: Cannot send session cache limiter - headers already sent (output started at /var/www/drupal/index.php:5) in /var/www/drupal/includes/bootstrap.inc on line
Checked php.ini, empty end lines, etc... Want to clear the cache in a db, but this post makes me nervous now -- can I clear it "too much"? ;-)
Thanks,
Pavel.
Need save as UTF8 without BOM
>> Warning: session_start() [function.session-start]: Cannot send session cache limiter - headers already sent (output started at >> /home/client/public_html/index.php:1) in /home/client/public_html/includes/bootstrap.inc on line 860
>> ...
If "index.php" UTF8 ------> save it as encoding UTF8 without BOM
Yeah the hosting company
Yeah the hosting company probably caused it, it sounds like, anyways shared hosting sucks in my opinion, if you can run a cloud server thats better because they can't mess with it then.
Another
Another option that worked for me at http://drupal.org/node/251540#comment-1887994
The problem for me...
The problem for me was that in my settings.php file there were spaces at the start, before <?php
Removing them fixed the problem.
CPANEL BACKUP HAS NOT WORKED FOR YEARS
CPanel, a commonly used web server manager, has a backup system that seems just lovely. You create a full backup of the site and transfer the resultant file to the new web server. Time and time again up to this very day (Sept 11, 2010) the one big surprise database dependent users get(like those who use Drupal) is that their database has nothing in it. Many depending upon CPanel end up in a situation where that is all they have. The only hope is if you have a separate back up of the database to go into phpmyadmin, select the empty database and click the import tab and import the database file.
The reason I mentioned this is because many of our users that have transferred from other hosting companies to ours have ended up with empty databases in their Drupal installation, thanks to Cpanel ignoring the problem for years. In fact we just had one put in a ticket to cpanel complaining that they had lost all of the data for many drupal sites thanks to the database being zero in the Full backup pack. Then when they launch the site in the browser they get results identical to what you posted. Some have thought the entire back up was corrupted and just reinstall a fresh copy of Drupal. It's not the files that is the problem it's the completely empty database. Cpanel, is, to this very day, acting like they don't know about the problem; the problem is they no longer seem to have programmers competent enough to fix these issues. Cpanel has continued to be a nice system mostly because of the original creators work. The work around to the problem for those of us who want to continue using Cpanel is to do a separate database only backup and then import it after you do the full backup, as I say using phpmyadmin. It's really not that difficult. Hope this helps someone who is surprised when they get this output. One last thing-- the full back up claims it includes SSL certs but it commonly fails to do this too.
On the subject of SSL certs, I strongly advise people to use their own self-generated certs at the full 2048 bit level you get excellent encryption and offers, in many cases, superior protection over the costly certificates. You can make a cert in 2 minutes flat using SSH or Cpanel or Plesk or DirectAdmin. The only thing expensive certs do is they claim to verify your identity. Well you can post your company contact information on your site. I strongly disagree with Firefox's attempt to push expensive certificate sales and act like they are protecting people from a bogus threat. No doubt they have paid interests in certificate sales firms. They should spend more time debugging Firefox and less time deceiving people.