I've been struggling with this problem for a long time now, but I cannot really find the solution. The problem is that < !DOCTYPE html etc... does not start at the first line, but leaves four blank lines before it starts.
All my files (header.php, index.php etc) have no line breaks before they start.
Anyone with any similar problems/experiences out there? It would have been of huge help!
See here for reference: view-source:http://2famous.tv/
Thank you
This is most often not caused by leading but by trailing whitespace. Lots of old PHP code still closes down code at the end, which then all too often has a stray newline:
<?php
// Lot of source code
?> <----- and a newline here which is the culprit!
To avoid this issue, never close files with ?> - PHP doesn't need it and will just stop parsing at EOF, thus implicitly avoid this 'garbage' in the output.
As for finding the files causing it - good luck, I'd start with combing any custom extensions for this and just removing all ?> markers that you can find.
As an alternative, you can probably 'fix' it by adding a single ob_start() call to your index.php, and then in the template containing the doctype executing ob_end_clean() - this puts all intermediate output in the output buffers, and then trashes it.
Related
Not using a closing tag in files that are included seem to work fine for me. Yet, in the PHP.net manual for the include statement it says:
When a file is included, parsing drops out of PHP mode and into HTML
mode at the beginning of the target file, and resumes again at the
end. For this reason, any code inside the target file which should be
executed as PHP code must be enclosed within valid PHP start and end
tags.
This seems to indicate that I should be using closing tags on such files.
Yet, the following information in the PHP.net manual for instruction separation seems to contradict this:
The closing tag of a PHP block at the end of a file is optional, and
in some cases omitting it is helpful when using include or require, so
unwanted whitespace will not occur at the end of files, and you will
still be able to add headers to the response later. It is also handy
if you use output buffering, and would not like to see added unwanted
whitespace at the end of the parts generated by the included files.
Is there a contradiction here or am I misunderstanding something? If I am misunderstanding something, what am I misunderstanding?
what PHP is telling you is that when you have and html archive you have to use enclosing php tags to use php, and the second paragraph, tells you that when using a php file, it is optional to close the php tags, because there may be more files running and the last of them may have the closing tag, because if you close the php tag when you are in a php file, you can break the following files because php execution may end unexpectedly
I'm having an issue, which seems like a bug, whereby if I download a CSV that I've created it seems to leave 12 empty spaces on the top of the file before filling in the content I want in there.
Is this just a general bug?
I'm using Codeigniter 2.1.3
Thanks Guys
I just had this same issue. When I looked through my code I was calling in a model that had a closing ?> tag, and for some weird reason, that created the extra space. Look to see if you have any closing php tags.
i had the issue too. But i solve it not related to closing ?>, but space in the beginning of php file. use tools such as winHex to open related php files, look if the file start with a space(in Hex it's 20), remove it, and the problem had solved.
sorry for my poor english.
<!DOCTYPE html>
This is the code.
How can I fix that?
I tested the HTML/CSS/JavaScript before integrating the code with Laravel.
Make sure your PHP files don't have the closing tags (?>). They might add whitespace to your HTML.
For more info, see the PHP docs:
If a file is pure PHP code, it is preferable to omit the PHP closing tag at the end of the file. This prevents accidental whitespace or new lines being added after the PHP closing tag, which may cause unwanted effects because PHP will start output buffering when there is no intention from the programmer to send any output at that point in the script.
You might also want to take a look at this post: Why would one omit the close tag?
I know this is few years late but for other people.
change the page encoding to UTF-8 without BOM and it will be solved.
I have a php website that on certain pages is adding a dot or space before the first html tag. I can't figure out where it is coming from - is there a way to debug the code so i can see where it is coming from?
Thanks,
Josh
To help prevents this happening it is considered a good practice to don't end your PHP file with a ?>.
You possibly have some file that are this way (notice the extra space after the ?>):
<?php
// Some code //
?>
If you would remove the ?> at the end, the extra space at the end of the file won't be interpreted as something to output.
For files that contain only PHP code,
the closing tag ("?>") is never
permitted. It is not required by PHP,
and omitting it´ prevents the
accidental injection of trailing white
space into the response.
Source: http://framework.zend.com/manual/en/coding-standard.php-file-formatting.html
Maybe it is a BOM character?
Maybe you should check your templates if you are using them... the problem could be there and not in your main code.
and yes is a GOOD PRACTICE in PHP not to close the ending tag.
There really is no good way to go about debugging this. You need to go through every file the page is hitting and figure out where the output is coming from. If you really wanted to be lazy about it you could do some output buffering, but this isn't the right way to do things.
Problems like this can be difficult to track down. If you're in some kind of framework or system that includes a lot of files, you might try a var_dump(get_included_files()) on the line before your error occurs, and that will give you a place to start. If that isn't sufficient, xdebug might get you further. Things to look out for are space before and after the PHP tags, and functions that might send output.
I got some strange problem where i have 2 copies of same website in 2 different folders. In one of those 2 copies has whitespace before doctype declaration so i have problems to work with facebook as document is formated incorrectly.
Before html there is some php calculations, but there is no echo statements or something.
What could be cause for 2 identique websites under same server in different folders, one having this issue?
I'm almost positively certain that you have some trailing whitespace at the end of a PHP include. Check there first.
Example:
<?php
// header file
include 'other_file.php';
?><!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN"
"http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
<html xmlns="http://www.w3.org/1999/xhtml"><!-- etc. -->
Then
<?php
// other_file.php
// connects to database, or something,
// but notice the whitespace after the closing tag
?>
... pretend this text isn't here
I added the note at the end to get stackoverflow's markdown editor to show the additional lines after the closing ?> tag. PHP automatically truncates one newline character after the tag in includes, but if you have more than one they will be interpreted as blank space before your doctype declaration.
Easiest fix? Remove the closing tag ?> from all of your includes. This is a valid technique, and could be the fastest way for you to get up and running.
You don't say which browser you're having problems with. IE used to check the first few letters of the page for a doctype and, if it isn't one (such as whitespace), it would go into quirks mode.
This is especially common if you are using includes. Check over all your includes or other php files carefully that come before your output or headers.
<?
echo "php here";
?>
This will cause a problem if it's in an includes
that comes before your headers or doctypes.
Remove any non php here, file should end with "?>"
not whitespace, linefeeds or characters.
As for why? Unknown, on one production server this issue raises it's head constantly for me (CentOs 5) but on my dev machine (latest Fedora) it doesn't happen and I have no issues.
Honestly there's probably something I could track down to find out why, but since proper usage says "no extra spaces or lines" I just do that and don't worry too much about the "why is it handled differently on my servers" all that much. (Kind of a cop-out I know)
I ran into this where a line break was above the Doctype. I tried a few things and then ended up just placing the doctype in the php.
<?php
echo '<!DOCTYPE html>';
... other php code/includes/etc ...
?>
<html>
... other html elements ...
Not sure if that's the right way to go about it, but it worked for me. If you're using a more extensive doctype, you'll need to escape special characters.
I just spent a day solving this problem where my libraries worked fine on static pages but under a dynamic system with a master script at the start (apache mod_write rewriting all to master script) the browser flipped into backward compat mode (js: alert(document.compatMode()) ) and distorted my styling. All my include files were ended properly and no echos, etc.. The problem? A blank line above the opening <?php of the master script.......
You may not believe but I have a MAGIC way to solve this problem:
Upload your documents (which are included before <!DOCTYPE) on your host using File Manager of CPanel, then choose the document and Click "Edit" to see the source code of the document. Then press Ctrl+Home then press Delete!
You see that nothing will be deleted but that hidden white space!!
Save your document and you will notice that everything is OK now.
I do this for all of my projects
In my case this works fine:
$ brew update
$ brew install coreutils
$ cd directoryWithSymfony2Project
$ for file in $(find ./ -name '*.twig' -or -name '*.php'); do sed `echo -e 's/[\xC2\xA0]//g'` $file > temp; echo 'Processing ' $file;rm $file; mv temp $file; done
I had the same issue, and the culprit was a whitespace at the top of one of my included PHP files, before <?php:
<?php //Line above this line was the problem
function gggl_vertical_cards(){
ob_start();
?>
//...
do you use session_start() or header() anywhere? then (without outbutbuffering) no whitespace or other character is allowed to send to the client before this functions.