Feed Problem – configuration?

This is what I’ve tried so far. Although I knew that the files indicated in the error page linked to above were fine, I went through every single php (and css) file in the entire WordPress package last night, excluding themes. 116 of 174 files had whitespace outside of the php tags. I did check my theme files also, but since I’d been working with them didn’t find this problem there. This has solved a few minor things, such as the wp-cache issue, but the feeds are still dead.

Here’s a link to a feedvalidator.org error report.

I tried changing the text/xml to application/xml in the wp-rss2.php file. This made no difference. I’ve also read a variety of references online to different versions of all the various feed files, but they all seem to be for troubleshooting 3.0 (or moving) and I’m not sure what else is different in the 3.0 call relationships.

My sequence (I think) is going from htaccess to index.php to the header file, at which point it can’t find the config file and performs ‘die’. I discovered this on my ftp site.
My config file is exactly the same, in terms of content and location, as it has been since I installed WordPress, and I wouldn’t have this weblog up at all if it wasn’t configured properly. Is that correct?

The only other thing that I can think to mention at the moment is that my WordPress is installed in a subdirectory, so I have duplicate htaccess and index.php files …one of each at the root and main subfolder levels.

Can anyone please suggest which code or files might be causing this inoperable feed problem?

Feel free to email me directly if you have an thought but don’t feel like posting.
Thank you,
Vera

Does the problem exist with all the plugins disabled and the default theme?

Yes. All plugins are currently disabled (even Hello Dolly), and all the behaviour is identical with the default theme.

That is very perplex.

I’m not very knowledgable in this area.

I would start by trying WordPress 2.3 and praying that solved it by magic.

Next I would see if you can duplicate the issue in another environment, and then if you can’t figure out what is different between the two environments (php.info)

It is a very safe bet the problem is caused by a blank line some where. Maybe different line endings even?

$ lynx -head -dump https://verabass.com/feed/
HTTP/1.1 200 OK
Date: Tue, 02 Oct 2007 19:49:50 GMT
Server: Apache
Connection: close
Content-Type: text/html

Thank you for taking the time to get and post that link. I appreciate it.

I’ve come across a couple of files that have unicode symbols. (hadn’t opened every single one in Notepad before)
It was the message about foo and bar that made me go look. Why they’re like that is also a mystery …I downloaded the package here recently.

I’m re-doing those, and hoping.

Uprading to 3.0 is coming but not today (unless I have to reinstall, perhaps). Stubborn me insists on finishing if humanly possible. ??

Vera

Check out my fixed feed. ??

For anyone else who might have the same problem, it was the encoding mess.

WordPress 2 and up uses UTF-8 but most text editors, including Wordpad, which save in UTF-8 add BOM (which results in some invisible characters) in front, so you can end having the files interpreted as UTF-16, or ansii, or Latin-1, etc.

The clues in my case were:

This ??? snippet of characters that appeared on some pages before loading. That was created by the BOM (in a UTF-8 encoded file).

the feedvalidator.org report said that my feed was being encoded as UTF-8 but being sent from my server as US-ANSII.

The same report indicated a problem finding the wp-includes/feed-rss2.php file, so I also added UTF-8 after CHARSET= in that file.

I’m still a total newbie here, so if any real coders would like to correct my terminology for the benefit of others, please do!

Vera

I guess the moral of the story isn’t to use Wordpad, or other editors that aren’t true “plain” text editors.

good advice

I’d been using WebTide originally, but it was opening a file accidentally with Notepad that showed me the unicode characters and made me look harder at that.

In WebTide was where I was able to see the hard break squares *before* the document text. They showed at the top of the code schema window, not in the document.

WebTide doesn’t have a save without BOM option, though.

An addional note is that I found the same problem with a few files that were acting up which I downloaded from my old host. These were files that I’d cleaned before originally uploading them. So there’s also server encoding involved in here somehow. My previous hosting was on Apache 1.3 and Linux but with ISO encoding specified first and a default of Latin-1. Guess that’s why they offer WordPress install of an early version, even though most of their help people have no idea of any of this.