Comments RSS feed not working since version 1.6.1

[shadowm]

A while ago, I noticed that comments in my blog stopped appearing in my feeds aggregator program, although email notifications continued to work properly. It turns out that the comments RSS feed misses all <item> nodes and their children every time. Based on the date of the last comment that landed on my feeds aggregator, this happened around the time I upgraded to 1.6.1 (shortly after its release).

So, I decided to download the full 1.6 and 1.6.1 versions and try them along with 1.6.2 on my test server, installing each version from scratch in separate directories and posting one blog post with two comments in all three instances. I could thus confirm that the comments feed worked fine on 1.6.0, and first broke on 1.6.1. Of course, it continues to be broken on 1.6.2.

Both the test server and the live server run s9y using PDO::SQLite, on Apache 2.2. The live server runs FreeBSD 8.3, with PHP 5.3.15 and SQLite 3.7.11; the test server is actually a laptop running Debian wheezy, with PHP 5.4.4 and SQLite 3.7.13

[garvinhicking]

Hi!

Sadly yes, the RSS feed of the s9y 1.6.2 release has a bug that prevents comments from showing up.

You could either try the 1.7 release that should hopefully soon be out, or download an updated rss.php file from our GITHub repository which would contain that fix...

Sorry for that!

HTH,
Garvin

[Lux]

Sadly yes, the RSS feed of the s9y 1.6.2 release has a bug that prevents comments from showing up.

You could either try the 1.7 release that should hopefully soon be out, or download an updated rss.php file from our GITHub repository which would contain that fix...

Good to know.

Thanks

Dirk

[Lux]

Hi,

this feed, does not work either:

http://deimhart.net/rss.php?version=2.0 ... format=mp3

Sorry.

All feeds are broken ...

http://deimhart.net/index.php?/feeds/index.rss2

Dirk

[shadowm]

You could either try the 1.7 release that should hopefully soon be out, or download an updated rss.php file from our GITHub repository which would contain that fix...

Well, I’m naturally wary of running larger pre-release software on a live server, so I tried with just the updated rss.php from the 1.6 branch (the other branches have incompatible changes, that got me stuck at first) and the comments feed is back without any apparent regressions. Thanks!

[garvinhicking]

Hi Lux!

Your feed shows up for me in Firefox.

Regards,
Garvin

[Lux]

Hi Lux!
Your feed shows up for me in Firefox.

I copied the rss.php from 1.6.1, which has exactly the same md5sum as the one from 1.6.2 and after that it worked.

Caching?

Cheers

Dirk

[garvinhicking]

Hi!

The rss.php of s9y 1.6.3 would be the one that's fixed... rss.php of 1.6.2 and 1.6.1 should not be different I think.

Regards,
Garvin

[Lux]

The rss.php of s9y 1.6.3 would be the one that's fixed... rss.php of 1.6.2 and 1.6.1 should not be different I think.

Does a rss.php with a different date influence Serendipities internal caching?

Cheers

Dirk

[garvinhicking]

Hi!

The RSS feeds are cached by your browser; you can delete your browsers cache to ensure that you get recent content (or publish a new blog article). So uploading a "fixed" rss.php file would not necessarily be reflected in your browser, unless you remove its cache. s9y doesn't maintain the cache by itself.

Regards,
Garvin

[Lux]

The RSS feeds are cached by your browser; you can delete your browsers cache to ensure that you get recent content (or publish a new blog article). So uploading a "fixed" rss.php file would not necessarily be reflected in your browser, unless you remove its cache. s9y doesn't maintain the cache by itself.

Hmpf, I am pretty clueless, what the reason is, that it does not work.

It is not only me having problems. Today I got the message from one user, using a podcast client against DeimHart-Feeds. After copying rss.php it worked for him.

Cheers

Dirk

[garvinhicking]

Hi!

Did you write a new blogentry and check the feed then? What do you use? Try using wget, that shouldn't cache.

Regards,
Garvin

[Lux]

Did you write a new blogentry and check the feed then? What do you use? Try using wget, that shouldn't cache.

It is already resolved, the question is why.

I got reports with errors from users running Android podcast clients and I had errors myself.

Solution was to copy the same (!) rss.php and overwrite the one in the directory.

Which mechanics are behind that? Since the error was solved with this procedure for all the clients, it can only be the (apache) server, php(.ini) or the software.

Can you agree with that?

Cheers

Dirk

[garvinhicking]

Hi!

That can't be...you must have copied some other file, or the rss.php file was actually different.

The only thing that could be involved is APC or some other bytecode cache implemented into PHP, but even then - the error must be rss.php, and if you didn't copy a file that changes the rss.php content, this cannot have been the fix...

Regards,
Garvin

[Lux]

That can't be...you must have copied some other file, or the rss.php file was actually different.

Agreed. I mostly update to the recent version immediately after release. Could it be that the oldest archives (tar.bze2) of 1.6.2 contained a different version?

The only thing that could be involved is APC or some other bytecode cache implemented into PHP, but even then - the error must be rss.php, and if you didn't copy a file that changes the rss.php content, this cannot have been the fix...

Even with a similar file I can imagine two things that could invalidate a php or apache cache (none configured).

1. The timestamp of the file changed.
2. The inode of the file changed.

Cheers

Dirk