Make WordPress Core

Opened 9 years ago

Closed 7 years ago

#1020 closed defect (bug) (fixed)

Presentation area shows raw CSS instead of Theme/Author names

Reported by: JPigford Owned by:
Milestone: 2.1 Priority: high
Severity: normal Version: 1.5.2
Component: Template Keywords: css line-endings stylesheet has-patch needs-testing
Focuses: Cc:


When in /wp-admin/themes.php for a theme I've recently been working on, instead of showing the Name, Author, and Description, it just shows all of the CSS coding. I've tried replacing all the comment tags in 3 other editors instead of Dreamweaver but it still shows it. It does it on 2 different installations of wordpress.

Attachments (2)

CSSIssue.pdf (75.8 KB) - added by JPigford 9 years ago.
1020.diff (555 bytes) - added by Nazgul 8 years ago.

Download all attachments as: .zip

Change History (37)

comment:1 JPigford9 years ago

  • Patch set to No

comment:2 matt9 years ago

I bet this is because he has mac CR line endings. We need to normalize when we read files in. Maybe wp_get_file_contents

comment:3 JPigford9 years ago

Would it help to show the HTML I'm getting for the theme.php or no?

comment:4 matt9 years ago

No it wouldn't, but it would help if you could link to the CSS file.

comment:6 JPigford9 years ago

Eh, any update on this?

comment:7 JPigford9 years ago

Something...anything! For 4 days now this has left the blog unuseable because I can't fix the theme. Right now I'm seriously considering dropping WordPress on all my sites (and my clients) if this issue can't be fixed as it seriously hinders it's use.

comment:8 ColdForged9 years ago

Have you tried enabling the auto_detect_line_endings setting in your php.ini? If this is a Macintosh related line-ending issue this may help. WordPress is using the PHP "file()" function to read in the stylesheet, so PHP is the one having difficulty with the line-ending.

edited on: 03-07-05 22:44

comment:9 JPigford9 years ago

Will enabling auto_detect_line_endings possibly mess up any of the other sites on my server? I have 30+ sites and would hate to screw them all because of this WordPress problem. Basically, does it "hurt" to have it enabled?

comment:10 ColdForged9 years ago

I cannot see how it would adversely affect other sites. The simple fact is that your PHP installation is not being allowed to handle Macintosh-style line ending appropriately. It isn't a WordPress problem, it's a configuration problem. WordPress is using a built-in PHP function to read a file and that built-in function is not able to parse the file correctly because it can't auto-detect line-endings. So this will currently be a problem on any file on any site on that server that happens to have Mac line-endings and that uses a built-in PHP function to read that file in.

comment:11 JPigford9 years ago

2 things:

1) It's a problem on 2 different servers. 1 of whom's php.ini I can't edit because it's a clients and they're on a shared server.

2) This is the only time I've ever edit this issue with a CSS file in WP and I've been using my Mac with WP for 6+ months.

I don't know that's its just "a configuration" problem and if it is and it just "happened" to be the same wrong configuration on 2 totally seperate servers then it seems like it's an issue WordPress might should address instead of telling people they have to edit their php.ini file to use their software.

comment:12 ColdForged9 years ago

Fair enough.

1) I can't see what's going on on your server, I'm merely digging through code and coming up with possibilities.
2) I don't speak for WP I'm merely a hobbyist who's trying to help you determine what the problem is.

You hadn't heard anything, I was giving you something to try. Sorry you're not happy with my suggestion.

comment:13 JPigford9 years ago

I'm not mad. I'm just stating the facts. And I wsn't saying you were affiliated with WordPress by suggesting I edit the php.ini file...I was just saying that if that's what was required to make WP work on people's servers then WP should try to fix the issue, not people who want to use their stuff. Thanks for your help so far, I'm just a bit frustrated that I'll have to ditch WP.

comment:14 ColdForged9 years ago

What version of PHP is this, by the way?

<a href="http://www.zend.com/manual/function.file.php">Here</a> is a link showing the function used and mentioning the use of the line ending auto detect configuration. That said, as Matt also said, it could always be worked around by not using the file() function to read in that file and normalize to a certain line-ending format, obviating the need for the file() function and the subsequent configuration option.

comment:15 JPigford9 years ago

Both servers with the issue are running 4.3.10

So everything could more or less function the same without using the file()? If so, what's the real point of it?

comment:16 ColdForged9 years ago

file() is a convenience function. It just happens to have problems deciphering Macintosh line endings without that particular option turned on. Therefore, to make it so that WordPress isn't reliant on a server-side configuration option it means constructing a replacement function -- that would operate precisely the same as file() _with_ the configuration option turned on -- or, essentially, reinventing the wheel to get around a PHP installation weakness.

comment:17 JPigford9 years ago

But what confuses me is that I've edit *countless* CSS files, PHP files, etc etc for use with WP over the past 6 months and never had this issue. It's only happening with this particular CSS file. If I edit other CSS files for other themes, they are fine. Not sure if it's something *in* the CSS file or a way it was saved possibly?

comment:18 ColdForged9 years ago

That CSS file has Macintosh line endings, being a single '\r' at the end of each line. It was saved by a Mac text editor in Mac format and uploaded or copied in verbatum. Perhaps the other ones weren't, but the one you linked to is.

comment:19 JPigford9 years ago

What about this one: http://www.theappleblog.com/wp-content/themes/tab/style.css

It was edited in the exact same program as the other one.

comment:20 ColdForged9 years ago

No, that one has Unix line endings (single '\n').

comment:21 JPigford9 years ago

Where can I see what line endings they have?

comment:22 ColdForged9 years ago

I use Visual Slickedit which has a view that shows the file in hex. If you have shell access you can use the od -x command to dump the file in hex and look. 0x0d is a Mac ending, 0x0a is a Unix ending, 0x0d0a is a Windows ending.

edited on: 03-08-05 19:34

comment:23 JPigford9 years ago

Is there a program that will convert line endings to a certain format no matter what OS you are using? I am thorougly confused at why only this file is doing the Mac line endings...

comment:25 JPigford9 years ago

Well, looks like your google answer paved the path to fixing the issue. Converting the line endings did the trick. Thanks for your help ColdForged.

comment:26 2fargon9 years ago

  • Status changed from new to assigned

Can you please provide clear steps to reproduce the problem?

The theme you were working on might be causing the problem. Does this occuer with the default themes/files that are a part of the downloaded package?

comment:27 JPigford9 years ago

Sorry, I can't provide clear steps because I don't have a clue really. All I know is that the problem was the line endings were Mac. The second I converted them to Unix line endings the problem was fixed. The best I could do is give you the file that has the mac line endings and let you see on your server that it screws things up. The same file caused problems on 2 seperate servers.

This didn't happen with the default themes because they don't have mac line endings.

Overall, the sole cause of the issue is the mac line endings.

comment:28 anonymousbugger9 years ago

I added a quick fix to the function.php. It looks like it work's like a charm. Becuase mac's use "\r" sometimes rather then "\n", this converts them. I added:

function get_theme_data($theme_file) {

$theme_data = implode(, file($theme_file));

fixing the theme page so it's easier.to deal with mac & pc
$theme_data = preg_replace("/\r/","\n",$theme_data);


comment:29 anonymousbugger9 years ago

NIce one, that fix works a dream.

comment:30 TechGnome9 years ago

I had a similar problem with the Taft theme. I found that if I opened it up in PSPad and changed the text mode from Mac to DOS (wor Win) and re-saved it, it was OK. I suspect it has to do with the way the different OSs/editors handle CR/LF character(s).


JPigford9 years ago

comment:31 muskie9 years ago

I too encountered this problem. I eventually fixed it. I could easily reproduce it if you like. I cut and pasted some text into a new text file I created with BBEdit. At the time I had line endings to be Mac. I've switched to Unix line endings. I did't even need any CSS just putting
in the Theme information in the comment will demonstrate this problem.


comment:32 meganano8 years ago

  • Cc ColdForged added
  • Component changed from Administration to Template
  • Keywords css line-endings stylesheet added
  • Priority changed from normal to high
  • Severity changed from major to normal
  • Version changed from 1.5.1 to 1.5.2

I've been looking for a solution to this problem for several weeks. I found a file called functions.php in the wp-includes folder and added the code as noted above exactly as it was posted and then again with the comments removed and the closing brace added.

function get_theme_data($theme_file) {

$theme_data = implode(, file($theme_file));
$theme_data = preg_replace(/\r/","\n",$theme_data);

comment:33 meganano8 years ago

Ack... cut myself off. Basically it broke the page no matter what, even when I fixed a number of percieved typos.

Can you please post the correct code... there are some problems with it that are breaking the page and unfortunately I'm not enough of a php guru to know what's wrong with it.


comment:34 Nazgul8 years ago

  • Keywords has-patch needs-testing added
  • Milestone set to 2.1

Don't know if this issue is still valid, because there has been no activity in this ticket for almost a year.

But I've created a patch based on the comments in this ticket. Only I'm unable to do some real testing, because I don't have a Mac.

Nazgul8 years ago

comment:35 matt7 years ago

  • Resolution set to fixed
  • Status changed from assigned to closed

(In [4546]) Normalization of newlines fixes #1020, also did some minor reformatting.

Note: See TracTickets for help on using tickets.