Incorrect Timestamp in rss.php?

[madaed]

I suppose Serendipity uses an incorrect timestamp in the caching logic of rss.php when the timestamp of an entry was manually set to the future. Serendipity uses the "last_modified" field which is older than the "timestamp" field in this case. So the client will not update the feed until you publish a newer article or change the "last_modified" field.

I suggest the following fix (not 100% sure if its really working):

rss.php line 67 (latest full release 1.2, 2007-08-26):

Replace:

Code: Select all

$last_modified = gmdate('D, d M Y H:i:s \G\M\T', serendipity_serverOffsetHour($latest_entry[0]['last_modified'], false));

with:

Code: Select all

if ($latest_entry[0]['last_modified'] > $latest_entry[0]['timestamp'] || $latest_entry[0]['timestamp'] > time())
    $last_modified = $latest_entry[0]['last_modified'];
else
    $last_modified = $latest_entry[0]['timestamp'];

$last_modified = gmdate('D, d M Y H:i:s \G\M\T', serendipity_serverOffsetHour($last_modified, false));

So serendipity uses always the newest timestamp available that is not in the future.

[garvinhicking]

Hi!

But when you save an article, last_modified is always set to the current timestamp - so even if you publish an entry to the future, the last_modified will still be set to the current timestamp and should update rss feeds accordingly, because that timestamp is always newer than the last one...?

Regards,
Garvin

[madaed]

But when you save an article, last_modified is always set to the current timestamp

I'm not sure, but I think Serendipity overwrites the "last_modified" timestamp when the user updates the entry.

functions_entries.php, line 1244 in serendipity_updertEntry():

Code: Select all

if (!serendipity_db_bool($entry['isdraft']) 
    && !serendipity_db_bool($_entry['isdraft'])) {
  $entry['last_modified'] = time();
}

So if the user saves a new entry with a timestamp set to the future and updates the entry later, the "last_modified" timestamp is set to the time when the entry was updated - not to the time the entry is supposed to be published. In this case the "last_modified" field has not the same value as the "timestamp" field, has it?

[garvinhicking]

Hi!

Which problem exactly are you experiencing? Let's look at that first, maybe it's a different issue.

And yes, s9y updates last_modified everytime an entry is saved, to ensure that changes are also reflected in the RSS feed.

Regards,
Garvin

[madaed]

Hi,

first: thank you for your great support!

We recognized that some feed aggregators need a very long time to index our feeds, especially entries that were timed to the future. One of our team-members claims, that this works much faster if you update these entries once after they appeared at the blog. So you have to set the timer, save the entry, wait until it is shown in the blog and click on the "Save" button again. Now the aggregators find the new entries.

That's what my fellow claims. I am not sure if he is right. But I suppose that the cache logic uses the wrong timestamp - one that's older than the timestamp of the article.

And yes, s9y updates last_modified everytime an entry is saved, to ensure that changes are also reflected in the RSS feed.

So let's say I write an entry. It is 10 am. I set the timer to 5pm and save the entry. In this case "last_modified" and "timestamp" are both 5pm.

When someone makes changes to the entry and updates it at 3pm, "timestamp" is still 5pm while "last_modified" is 3pm.

A crawler checks our feeds every two hours. At 4pm he downloads the new feed, because Serendipity sais, that the blog was last modified at 3pm. But the new feed does not already appear in the feeds. At 6pm the crawler looks after our feeds again. Serendipity still sais that the last changes were made at 3pm, but now the article is shown in the feeds.

The crawler will not recognize the new article until
a) I update the entry again,
b) Write a new article.

That's how I understood what Serendipity does. What do you think?

[garvinhicking]

Hi!

Ah, I believe you are then experiencing the general RFC2646 (or so) behaviour. You can check for that in the s9y configuration and disable the caching.Planets and RSS aggregators don't really understand our "If-Modified-Since" behaviour. No matter if you en/disable it, there's always a drawback

Regards,
Garvin

[madaed]

Ah, I believe you are then experiencing the general RFC2646 (or so) behaviour.

I do what? RFC2646? That's the RFC for text/plain format

Anyway, I will disable the caching and hope that this will solve the problem.
Thank you for your help.