This CR
means Carriage Return and LF
means line feed, the LF
is used to generate "new lines" (line break), the CR
up to the Mac 9 was used as line breaking, but from the 10 (Mac OS X) started using LF
, I believe that today all systems internally use only LF
, only the Windows editor Notepad.exe still saved and reads line breaks like this "CR
+LF
" (formed by both), may be by backcompatibility, in fact this does not affect anything since LF
be present shortly after the CR
.
What I suppose is that your script when editing and saving is disappearing with the LF
because it is using some configuration in the Notepad++, another possibility is that you are uploading the files via FTP with some configuration that is failing, it may also be because if the upload is in ASCII sometimes there may be loss of characters (if there is in the middle of the file some unsupported character).
Note that I am not stating that the CR
be the fault on the Linux server, but I believe it can be directly or indirectly, so much so that in my Debian (a type of Linux) worked normally using only CR
, that is it may be that the CR
together with another character is that causes failure as can be another character that has been lost without any relation to the CR
Notepad++
Abra in the Notepad++ Settings > Preferences > New Document > Format (Line ending), thus:
See if this selected CR LF
or LF
or CR
, probably CR
, if you’re trading for LF
or CR LF
, of course this may not solve the problem of files that have already been edited, so to fix this, do the following on Notepad++:
- Make a backup of all documents
- Open all files that you want to edit, that are not from the backup so that they stay in tabs like this:
Then press Ctrl+H and something like:
- Select the option
Extended (\n, \r, \t, \0, \x)
Now we’ll trade them all CR
and CR+LF
for LF
only
In this case I only used the LF
that is already enough for the case, but can do so (chance want CR LF
):
Select the option in Notepad++ File > Save All (or Ctrl+Shift+S), ready now things should be fixed, even if it fails is because it is probably using FTP, in this case follow the next step:
FTP
If you’re using FTP Filezilla or similar maybe the upload via ASCII is making some character conflict and something gets lost, it can also be some configuration of the FTP itself, if it is Filezilla go to Edit > Settings... > Transfer > File Types:
In Default transfer type change from Auto or ASCII for Binary and tighten OK, then try uploading again and see if it’s working.
Extra
Personally to work with PHP, despite being something totally optional, I prefer Sublimetext, since well configured, if you have any interest here I left some tips:
Any line regarding error_log?
– Jefferson Costa
Looks like a coding error. I’m not sure bad try to create a new file to test because it might be the encoding used when creating with an editor this conflicting with a new editor (or different encoding in the same editor). If a new (test only) file created in an editor
UTF-8
run this there the problem otherwise may be thePHP
or in the system.– Lauro Moraes
You are going up the files via FTP?
– Guilherme Nascimento