I have recently bought a new MacBook Pro. Before I had my MacBook Pro I was working on a website on my desktop computer. And now I want to transfer this code to my new MacBook Pro.
The problem is that when I transfered the code (I put it on Dropbox and simply downloaded it on my MacBook Pro) I started to see lots of error messages in my PHP code.
The error message I”m receiving is:
Warning: Cannot modify header information - headers already sent by (output started at /some/file.php:1) in /some/file.php on line 23
I have done some research on this and it seems that this error is most frequently caused by a new line, simple whitespace or any output before the <?php sign. I have looked through all the places where I have cookies that are being sent in the HTTP request and also where I'm using the header() function. I haven’t detected any output or whitespace that possibly could interfere and cause this problem.
Noteworthy is that the error always says that the output is started at line 1. Which got me thinking if there is some kind of coding differences in the way that the Mac OS X and Windows operating systems handle new lines or white spaces? Or could the Dropbox transfer messed something up?
The code on one of the sites(login.php) which produces the error:
<?php
include "mysql_database.php";
login();
$id = $_SESSION['Loggedin'];
setcookie("login", $id, (time()+60*60*24*30));
header('Location: ' . $_SERVER['HTTP_REFERER']);
?>
login function:
function login() {
$connection = connecttodatabase();
$pass = "";
$user = "";
$query = "";
if (isset($_POST['user']) && $_POST['user'] != null) {
$user = $_POST['user'];
if (isset($_POST['pass']) && $_POST['pass'] != null) {
$pass = md5($_POST['pass']);
$query = "SELECT ID FROM Anvandare WHERE Nickname='$user' AND Password ='$pass'";
}
}
if ($query != "") {
$id = $connection->query($query);
$id = mysqli_fetch_assoc($id);
$id = $id['ID'];
$_SESSION['Loggedin'] = $id;
}
closeconnection($connection);
}
Complete error:
Warning: Cannot modify header information - headers already sent by (output started at /Users/name/GitHub/website/login.php:1) in /Users/namn/GitHub/website/login.php on line 9
Check if there are spaces in front of your php opening tag. Also try resaving the file from notepad++ using the windows (crlr) line endings. (Edit > EOL Conversion > Windows format)
Noteworthy is that the error always says that the output is started at
line 1. Which got me thinking if there is some kind of coding
differences in the way that the Mac OS X and Windows operating systems
handle new lines or white spaces? Or could the Dropbox transfer messed
something up?
Don’t redo your code or worry about the header() calls or even the cookie stuff. That is not the issue.
The issue is that Windows line endings are different from Mac line endings. More details here.
Different operating systems use different characters to mark the end
of line:
Unix / Linux / OS X uses LF (line feed, '\n', 0x0A)
Macs prior to OS X use CR (carriage return, '\r', 0x0D)
Windows / DOS uses CR+LF (carriage return followed by line feed, '\r\n', 0x0D0A)
And what happens in cases like this is the formatting of the page causes the PHP parser in Apache to choke on the files. Possibly sending content to the browser before you intend to when making header() calls or setting cookies. Meaning technically the screwed up line endings force a “header” to be sent because the file itself is outputting data to the browser inadvertently.
The solution might be to avoid using Dropbox & just copy the files onto a flash drive & transfer it that way. That’s an idea but I am not convinced that Dropbox was the culprit in this. Meaning the issue might still exist even if you copy the files to a flash drive.
Or if that does not work, do as the linked to article suggests & download a good text editing tool like TextWrangler. Just load the files into TextWrangler & then manually change the line endings so they are Mac (CR) and resave the files.
Another long-term solution to this issue might be to use a version control system like git coupled with an account on GitHub to manage your code. The benefit is by pushing code to GitHub & pulling code from GitHub, the process itself will deal with cross-platform line ending headaches. And you don’t need to worry about inadvertent oddities caused by a straight copy of files to a service like DropBox.
But again, pretty convinced this has nothing to do with Dropbox. It’s all about Windows line endings being different from Mac OS X line endings.
EDIT: There are some interesting ideas on how to handle the bulk conversion of Windows line endings to Mac OS X line endings on Mac OS X Hints. The most intrguing one is the use of zip and unzip to facilitate the process. I have not tried this, so caveat emptor! But it does sound like something worth testing since the last line states, BTW, it's the "-a" flag to unzip, that is causing the ascii files to have their lines endings converted.:
I've always used the following (in a file named fixascii):
#!/bin/sh
zip -qr foo.zip "$#" && unzip -aqo foo.zip && rm foo.zip
And then execute it as:
fixascii [files or directories to convert]
Which has the benefit over most of these other commands in that you
can point it with impunity at an entire directory tree and it will
process all the files in it and not corrupt any binaries that may
happen to have a string of bits in them that look like a line-ending.
I've seen too many times where someone corrupted a ton of images and
other binaries, when trying to fix line-endings on text files using
dos2unix or tr in combination with find but failed to ensure that only
text files were processed. Unzip figure out which files are ascii,
converts them, and leaves the binaries alone.
BTW, it's the "-a" flag to unzip, that is causing the ascii files to
have their lines endings converted.
And then looking in the official man page for unzip under the -a (convert text files) option; emphasis is mine:
Ordinarily all files are extracted exactly as
they are stored (as ''binary'' files). The -a option causes files
identified by zip as text files (those with the 't' label in zipinfo
listings, rather than 'b') to be automatically extracted as
such, converting line endings, end-of-file characters and the
character set itself as necessary. (For example, Unix files use
line feeds (LFs) for end-of-line (EOL) and have no end-of-file (EOF)
marker; Macintoshes use carriage returns (CRs) for EOLs; and most
PC operating systems use CR+LF for EOLs and control-Z for EOF. In
addition, IBM mainframes and the Michigan Terminal System use
EBCDIC rather than the more common ASCII character set, and NT
supports Unicode.) Note that zip's identification of text files
is by no means perfect; some ''text'' files may actually be binary
and vice versa. unzip therefore prints ''[text]'' or
''[binary]'' as a visual check for each file it extracts when using
the -a option. The -aa option forces all files to be extracted
as text, regardless of the supposed file type.
EDIT: Also, if you have access to a Linux machine, you might want to checkout dos2unix. More details here as well. And found another Stack Overflow question here.
Finally found an easy way to fix this! I was looking through the php.ini file when i came across an option which is named: auto_detect_line_endings, and has its default value set to: Off.
The description to this option is:
; If your scripts have to deal with files from Macintosh systems,
; or you are running on a Mac and need to deal with files from
; unix or win32 systems, setting this flag will cause PHP to
; automatically detect the EOL character in those files so that
; fgets() and file() will work regardless of the source of the file.
; http://php.net/auto-detect-line-endings
Which is exactly what i was looking for!
I simply used the ini_set() function at the beginning of my database file(which i load on every php page) and it seems to have solved the problem for me! The ini_set() function also returns the option changed in the php.ini file to normal when script is completed.
Full line of the ini_set() function that i used:
ini_set("auto_detect_line_endings", true);
Thanks for all your help guys!
More info on ini_set() function here: ini_set() function
More info on the auto_detect_line_endings option here: Auto detect line endings option
Related
I had to recover my dev server and cloned the git repo I was working on, however now all files have their text on 1 line only.
This means that all PHP files is useless as many of them have // for my personal info. It's a mess and I am not quite sure what to do.
I understand that Git automatically converts line endings. I am working in a Windows environment and might have had it converted to UNIX/or something else from when I set it up.
Anyway that's done, but is there any way I can fix this?
It depends on your installation of git for Windows. Make sure to set it to clone Windows-Style-line-endings (\r\n, a.k.a. CRLF) and to push Unix-Style-line-endings (\n, a.k.a. LF). This to prevent your current problem from happening again.
To solve your problem now, open the file in a Notepad / IDE and
replace "\n" by "\r\n". Actually, modern editors should not have a problem
in displaying your text.
I have strange problem in every PHP page, at end of every response there is some special character, that is not related to PHP script, I test it with just <?php phpinfo();?> page that is there.
They are like this
�
But that is not in 404 static page response, I think that is related to php config over version or, not Apache config, but I can’t find what cause this.
Bad situation is that it cause every AJAX/Json response fails, because change structure of response data by adding special character at end of every response
What cause this problem and how can solve it?
According to this answer on Server Fault, the issue is problems with mod_gzip:
The problem is being caused by mod_gzip and the fact that you do not
have a final newline in your files. The newline problem is caused by
serving Windows-encoded files on a Unix system.
This might be connected to line ending differences between Windows & Unix machines. I actually answered a similar question earlier today. Specifically:
Different operating systems use different characters to mark the end
of line:
Unix / Linux / OS X uses LF (line feed, '\n', 0x0A)
Macs prior to OS X use CR (carriage return, '\r', 0x0D)
Windows / DOS uses CR+LF (carriage return followed by line feed, '\r\n', 0x0D0A)
If you are on a Linux server you can install the dos2unix tool to convert the PHP files in question to properly formatted Linux text files.
If you are on Ubuntu—for example—just run this command to install it:
sudo apt-get install dos2unix
Then you can run it like this on a file:
dos2unix some_kind_of_file.php
Which would take some_kind_of_file.php and convert it in place from Windows line endings to Unix line endings. More details here.
I work on a Windows 7 machine and Notepad++ for a number of tasks. I have noticed that when I work with someone on a Mac who tries to edit a file, and then I access it later, there are always extra lines, sometimes missing lines, white space is all crazy. Usually extra lines.
Sometimes, there fewer lines or code is just collapsed as if all white space were removed.
I'm certain there isn't a prank involved, as it has happened a number of times over the years. I'm just finally curious enough to ask if anyone knows what causes this?
That happens when you download a file that it's in Linux to a Windows throught FTP ASCII, you can download the files with FileZilla selecting:
Transfer -> Transfer Type -> Binary
That way the EOLs transfers just fine.
This is probably caused by the EOL or end-of-line character that you have selected in your editor. I also code on a Windows 7 machine, but have to push my files to UNIX where if I view the files, I will see ^M's or other strange characters in VI. If I recall correctly, go to Edit -> EOL Conversion and convert to UNIX/MAC. Just be sure to always set your EOL to UNIX and you shouldn't see the issue anymore.
Here's a link to a similar topic on SO:
https://stackoverflow.com/questions/2889163/eol-in-notepad-and-notepad
What may be happening is that the Mac user is encoding the file in a slightly different way. Notepad++ is readying the file, but is not expecting to have to handle a Mac encoded file -- thus it renders oddly.
For example, the software may be converting tabs to spaces. Another example is the special characters used between systems, such as:
\n = CR (Carriage Return) - used as a new line character in Unix
\r = LF (Line Feed) - used as a new line character in Mac OS
\n\r = CR + LF - used as a new line character in Windows
That's my thought.
I have a weird issue where my PHP files have lost their line breaks and appear to have weird box/rectangle shaped characters in them. I have no clue how to fix them and they are interfering with my website.
What editor are you using? That is a symptom of trying to edit Unix format files in MS notepad (amongst other combinations).
Your files have most likely been converted by an FTP transaction of uploading them to the remote server (because the client correctly used TYPE A) and not converted back when you retrieved them (because it incorrectly used TYPE I).
Either get a better editor (like Notepad++ or EditPadPro) or force your FTP client into ASCII mode (TYPE A).
FYI, on *nix a line ending character is LF only (\n), on Windoze it is CRLF (\r\n) and on Mac it is CR only (\r).
By the way, this can still occasionally happen in Notepad++ if you use Notepad++'s FTP plugin and do not set the FTP plugin (nppftp) settings to ASCII. That is why I found this post.
You are likely seeing the difference between Windows and Unix line breaks.
Windows uses CR+LF whereas Unix-based systems simply use LF.
See also: http://en.wikipedia.org/wiki/Line_break_(computing)#Representations
PHP will parse both, so I doubt that is the reason your code isn't running. Of course, with no file posted, this is only a best guess (and a common issue).
Yes, as Brad said, you probably have the wrong line breaks. Assuming that you're on a *nix system, run dos2unix <filename>, and that will replace the Windows endline \r\n with the *nix endline character of \n.
You just enabled "Show Linebreaks" or "Show special characters" in your editors menu options. So now, rather than an invisible "\n" or "\r\n" you are seeing a representation of them.
We have a web app using Andrew Valums ajax file uploader, if we kick off 5 - 10 image uploads at once, more often then not at least 2 or 3 will result in the same gd error "Corrupt JPEG data"
Warning: imagecreatefromjpeg() [function.imagecreatefromjpeg]:
gd-jpeg, libjpeg: recoverable error: Corrupt JPEG data:
47 extraneous bytes before marker 0xd9 in ....
However this did not happen on our old test server, or local development box's, only on our new production server.
The file size on the server is the same as the original on my local machine, so it completes the upload but I think the data is being corrupted by the server.
I can "fix" the broken files by deleting them and uploading again, or manually uploading via FTP
We had a shared host on Godaddy and just have started to have this issue on a new box (that I set up, so probably explains a lot :) CentOS 5.5+, Apache 2.2.3, PHP 5.2.10
You can see some example good and bad picture here. http://174.127.115.220/temp/pics.zip
When I BinDiffed them I see a consistent pattern the corruption is always 64 byte blocks, and while the distance between corrupted blocks is not constant the number 4356 comes up a lot.
I really think we can rule out the Internet as error checking and retransmission with TCP is pretty reliable, further there seems to be no difference between browser versions, or if I turn anti-virus and firewalls off.
So I'm picking configuration of Apache / PHP?
Some cameras will append some data inside the file that will get interpreted incorrectly (most likely do to character encoding with in the headers).
A solution I found was to read the file in binary mode like so
$fh = fopen('test.jpg', 'rb');
$str = '';
while($fh !== false && !feof($fh)){
$str .= fread($fh, 1024);
}
$test = #imagecreatefromstring($str);
imagepng($test,'save.png');
Well, i think the problem is jpeg-header data, and as far as i know there is nothing to do with it by PHP, i think the problem is your fileuploader, maybe there are some configuration for it that you are missing.
Hmm - a 64 byte corruption?...or did you mean 64 bit?
I'm going to suggest that the issue is in fact as a result of the PHP script. the problem that regularly comes up here is that the script inserts CRLFs into the data stream being uploaded, and is caused by differences between the Window/*nix standards.
Solution is to force the php script to upload in binary mode (use the +b switch for ALL fopen() commands in the php upload). It is safe to upload a text file in binary mode as at least you can still see the data.
Read here for more information on this issue:
http://us2.php.net/manual/en/function.fopen.php
This can be solved with:
ini_set ('gd.jpeg_ignore_warning', 1);
I had this problem with GoDaddy hosting.
I had created the database on GoDaddy using their cPanel interface. It was created as "latin collation" (or something like that). The database on the development server was UTF8. I've tried all solutions on this page, to no avail. Then I converted the database to UTF8, and it worked.
Database encoding shouldn't affect BLOB data (or so I would think). BLOB stands for BINARY Large Object (something...), to my knowledge!
Also, strangely, the data was copied from the dev to production server while the database was still "latin", and it was not corrupted at all. It's only when inserting new images that the problem appeared. So I guess the image data was being fed to MySQL as text data, and I think there is a way (when using SQL) of inserting binary data, and I did not follow it.
Edit: just took a look at the MySQL export script, here it is:
INSERT INTO ... VALUES (..., _binary 0xFFD8FF ...
Anyway, hope this will help someone. The OP did not indicate what solved his problem...