Presentation area shows raw CSS instead of Theme/Author names

[JPigford]

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.

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

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

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

​http://www.machtpc.com/wp-content/themes/machtpctemplate/style.css

There she is.

Eh, any update on this?

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.

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

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?

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.

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.

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.

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.

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.

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?

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.

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?

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.

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.

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

Where can I see what line endings they have?

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

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...

<a href="​http://www.google.com/search?hl=en&lr=&c2coff=1&q=+site:kb.indiana.edu+convert+line+endings+between+mac+unix+and+windows">Look here</a>.

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.

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?

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.

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);

...

NIce one, that fix works a dream.

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).

Tg

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.

Muskie

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);
}

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.

Thanks.

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.

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