10 replies to this topic

[Peter_Ingersoll]

I've run into a problem where my WordPress site migrated from another host provider doesn't work on ASO. The problem appears to be the required Unix LF at the end of lines and the problems caused by Windows CRLF at the end of lines. I've not encountered this on any other hosts I've used.

It seems that any text file I upload could potentially break my sites. Is this something specific to ASO, or am I missing something?

- Peter

[IBBoard]

Bash scripts are picky about which line endings they user, but PHP scripts shouldn't care. I only use Linux (and so only ever end up with LF at the end of lines), but my wife uses Windows and I've never had anything break just because she edited the file.

What errors are you actually getting, and in which files are they occurring?

[NyteOwl]

Uncommon problem. I often edit files for my site in Linux, Windows, Solaris, etc and have no problems. PHP applications such as Wordpress commonly use the "newline" (\n) character to terminate a line which is basically the equivalent of a CR/LF pair; Though if this is in an article it should be parsed as written.

[Peter_Ingersoll]

Thanks for reading and responding.

This all started after I uploaded WordPress files that are successfully used on another host that I'm moving my site from. I was getting the following error on WordPress pages "Cannot modify header information - headers already sent by (output started at [file] ) in [my account]/public_html/wp-includes/pluggable.php on line 866" where [file] is various plugins and [my account] is my server directory. I discovered that this error occurs in some cases when there is extra white space at the beginning or end of PHP files and when output buffering is off (as it usually is).

I submitted a ticket to ASO and was told that my files all have CRLF but should just have LF. The support person ran a script against all my files to change them. These files were all originally uploaded by me from my PC.

I also ran into a problem where themes were getting fouled up in the WP admin pages. In trying to trouble shoot that problem, I was trying to determine if this CRLF thing could be part of the problem.

I've asked ASO for clarification if LF is required in the uploaded file rather than CRLF. I also asked if there was a specific FileZilla setting I should have in place to make this happen automatically between my PC and the ASO Unix server. I have received no response (actually, it was escalated on Friday night to a system manager who, I unhappily found out on Saturday morning, don't come in until Monday).

I've worked with a number of hosting companies previously and I've never run into this problem using all the same software (FileZilla and Notepad++), the same settings, and even the same files.

So my question remains: is the LF/CRLF problem I'm running into typical with ASO, and is there an easy way to remedy? My big concern going forward is that if I forget some conversion (that I've never previously had to do), am I at risk of breaking my site?

Thanks for any insights.

- Peter

[IBBoard]

The error you had is self explanatory (although occasionally hard to spot). Anything outside "<?php" and "?>" in a .php file is printed as-is. That includes white space. If you print something before you send a header (e.g. a cookie) then you'll get the error you got. If you looked at line 866 of ~/public_html/wp-includes/pluggable.php then you'd probably find that it had a blank line. Most likely it was right at the very end of the file. It happens, and if it happens in an include/library file then it'll mess up your whole script like that.

No matter what host you're with, rogue new lines can be a problem (I've seen it on the forums of all of the major web scripts that people edit and modify - phpBB, Wordpress, ZenCart, OpenCart, and the rest). It is possible that the fact it was a CRLF (which is another way of saying \r\n ) rather than just an LF caused a problem in this one instance, but if it is then it is new to me and my ~12 years of PHP experience. The only thing I can think of is that you had a CRLF in just the wrong place, but that it was happy with them everywhere else.

[Peter_Ingersoll]

Thanks much, IBBoard,

I was definitely aware of the whitespace / rogue new line issue, but I couldn't see it. ASO support told me that all the CRs had to be stripped and ran a script to do so. It seemed to help one problem, but then my themes management issue cropped up. That's really the current issue, but I need to have a definitive answer regarding the LF issue so I can eliminate it as a variable.

I'm resigned to reinstall WP and everything else. My fear is that, even with SFTP transfer set to "binary" as suggested, my Windows PC will change a file to a CRLF and I'll be back with the same problem.

As you state, I've never encountered this before either - so all I'm left to do is start over and hope I never see this issue again.

Yay, and fingers crossed.

- Peter

[billzo]

Peter_Ingersoll, on 04 March 2012 - 03:33 PM, said:

I'm resigned to reinstall WP and everything else. My fear is that, even with SFTP transfer set to "binary" as suggested, my Windows PC will change a file to a CRLF and I'll be back with the same problem.

Upload a zip archive and unzip it on the server.

I've written PHP code exclusively on a Windows machine with a development Apache/PHP server installed and have never had a problem like that with Wordpress or anything else.   I also use Filezilla to upload files.  No problems there either.

A quick search of Yahoo reveals a lot of people getting that "headers already sent" error around line 865 or 866 of pluggable.php.  You didn't put any additional white space in config.php when you were editing it for the new server?  No white space in your theme's functions.php file?  There seem to be a lot of places where additional white space can trigger an error with the output indicating that particular line number in pluggable.php due to its use in overriding Wordpress functions.  

It could be with a plugin you are using, too.

[Peter_Ingersoll]

The bottom line is this: it shouldn't matter and this should be a non-issue. The problem that I originally ran into set me and tech services on what probably has been a bit of a wild goose chase due to a WP/PHP error that is often associated with white space at the beginning or end of PHP files. While my files did not have this white space, it did call attention to the CRLF / LF topic and off we went. Unfortunately, it became too much of a point of focus. There's really nothing different about ASO servers versus any other server I've used. Default upload/download of PHP files should work without a hitch. I've reloaded everything just to start clean and will proceed as usual. I don't anticipate additional problems.

Quite frankly, if this was a real problem the ASO wouldn't have nearly the number of happy customers they seem to have.

- Peter

[billzo]

I've never had any trouble with any Wordpress code or themes I've written with ASO.  I don't know why you had your troubles but I'm glad you got them resolved by installing fresh.

Good luck going forward.

[Chris Black]

I've not had any issues uploading files edited on a Windows machine to a WordPress install here either.

If you have shell access you could always log in and run dos2unix on the file if the issue is the Windows encoding.

[ASOAyron]

Chris Black, on 12 March 2012 - 05:15 PM, said:

If you have shell access you could always log in and run dos2unix on the file if the issue is the Windows encoding.

Also, since dos2unix doesn't have an option to work recursively, you can do this instead to process all files in a folder recursively:

find /path/to/folder -type f | xargs dos2unix

Replace /path/to/folder with, you know, the path to the folder.