When I edit theme css in theme editor in WP admin
WordPress reformats my CSS and adds a blank life between entrys in css.
it adds a cr and line break ....
In other words if you have a 100 line css
download with FTP look at in text editor
it is now 200 lines
as WP added blank lines to css
it should not be adding things to the CSS?

It may only do this when it wraps window but I think not it appears to add blank lines.

Imagine the damage to a 1000 line CSS it spaces every entry by 1 line!!!!!!!!!!!!!! It stiil works but it messes it up.

THAT IS COFIRMED ONE EDIT DOUBLE SPACE ENTIRE CSS... VERY BAD

Here is part of the problem but not the double space in total.
When you down load the file in FTP and it is in windows encoding
the line endings.
So you ftp back and all is fine.
Now you are at the coffee shop and what a quick change, so you login to WP admin and theme editor edit CSS.
Now you get home and download in ftp to continue your work on CSS.
The file is now mac formatted (or thinks it is) so when you edit the line endings do not contain the right line breaks for windows OR WP theme editor as it ignores them. This explains the wierd spacing though not the double spacing .... why is it converting to mac and yet ignores mac?!
weird.. it adds a CR tag
must be bug
again though its still double spacing on edit IN windows line ending though if you down load cSS its tagged mac format...

Use notepad 2 or Note pad plus to see the error.
When ever you edit with WordPress editor it adds cr and says css is now mac formatted.

FTP download the file and now see all the extra CR's it adds.

So it likes CR only so I convert to CR only and it beaks CSS it wants CR LF to work but if that is the case why does the online editor add CR only?????????????????????????

Change History (29)

WordPress 2.7.1 doesn't have CSS editor, it has file editing capabilities using a textarea where everything is controlled by your browser. If you're having problems try another browser or file a bug with the browser's creators.

If you were testing WordPress 2.8 which includes CodePress, the proper place for bug reports would be CodePress' bug tracker.

The reported problem still exists´(and isnt limited to editing css files). I´ve been struggling for years with this bug and havent found a solution yet. When saving theme or plugin files via Wordpress backend editor, blank lines are added after each line - which on the other hand are only seen, if I open the file via Dreamweaver or ftp/download. I then have to do a reg-ex-search and replace to get them removed (find: [\r\n]{2,} replace with: \n )

9716.patch​ may not undo the "double line" problem you're seeing, harmr. The file is read off the file system (using file_get_contents), presented in the browser (very dependent upon your browser + OS), then posted back to the server, and written back using fopen/fwrite.

Somewhere in that process, the line endings are being translated incorrectly. WordPress is using common practices for working with text files in the web, but this patch should give you a choice as to how the line endings are translated when they written back to the server. The fopen mode in the patch has been changed, too, to prevent any unexpected EOL translation.

Seems line breaks have to be normalized when saving edited files. Also if line breaks are \r, the theme or plugin "header" becomes inaccessible. This is browser and OS dependent but seems all modern browsers work with \n line breaks in a textarea. So the patch can be as simple as:

When we do that, we can cause problems if someone then opens up the file on their local OS.

If someone were to open a \n-normalized file in Notepad, when it was originally \r\n, it's a bad experience. I dealt with this in GSoC two years ago but didn't come up with a great solution. We need to make sure the file displays fine but saves with the existing endings.

And all is well.
I hope this gets included in the next update.
Since I am unsure as of yet as to why the extra CR gets added or when; the ability for the end-user to turn this on/off may be a good addition.

@Everyone - Curious if this will be the one fix we need. Both solutions have worked for me without causing any funkiness when opening the file after a WP edit in any program; Dreamweaver, Sublime Text 2, Windows Notepad and WordPad included. If this patch works across all platforms *nix/Windows then we won't need the toggle option.

I like kurtpayne's patch, 9716.diff, but rather than an option, we should just detect the line endings of the current file, normalize them on display, and then save them based on the original detection.

@nacin I hear you and I have to say that even when I explicitly set the fopen to preserve the EOL in the original file it still ends up with extra EOL's in the document. This occurs with each and every update too; at least in my experience so far. This is why I am backing the patch that "normalizes" the string before writing it to the file. I know this is isn't the most elegant solution, yet....

And what are the original line endings anyways? Most core files have \n EOLs, seems many plugins have \r\n EOL and themes generally have \n EOL (depending on the OS preferences of the authors).

Thinking we should standardize on either one or the other. A good criteria would probably be to determine on which platform non-native EOLs would cause more problems. i.e. Notepad on Windows vs. TextEdit on MacOS. As far as I can see TextEdit "understands" \r\n EOLs and Notepad doesn't understand \n, so \r\n seems as the proper default.

Standardizing on \r\n is really lame for anyone not on Windows. We should try *very* hard to avoid modifying line endings. People might use the theme editor for a quick change and this could have some bad effects to workflows.

If the file has a mix of line endings, then sure, we just choose a default. But we can be smart about it.

HallMarc, please upload here a file you are struggling with. I can't reproduce.

Seems to work fine on MacOS and probably most text editors on Linux (i.e. EOL style doesn't matter, text is displayed properly). Also works for all types of IDE enabled editors on any platform. Actually the only commonly used text editor that has a problem with EOLs is Notepad. However agree that more tests/feedback is needed.

Leaving mixed line endings when different people edit the same file offline is a lot worse imho.

Admittedly that's applied to content & not files. Though files & content are rendered by the browser, and the above works globally there. Meanwhile all modern editors do newline detection & replacement (and have settings for it), and I'm really against adding newline options to WP.

I too have noticed this behaviour. Sometimes, after a website has gone live, our team may make quick small changes to the CSS using the inbuilt theme editor, rather than downloading the file and editing it.

/wp-admin/theme-editor.php?file=style.css

When I next download the CSS file, and open it in Notepad or Sublime2, every line has an extra \n after it which makes the file larger and harder to read. I have tested the editing in Windows Firefox 37.0.1 and Windows IE 11 and both of these cause the issue.