RSS feeds reported as unmodified after publishing an entry

[Cenic]

Hi,

I just discovered an oddness that I believe is a bug. Today I published a new entry in my blog. Looking at the webserver logs I noticed that all accesses to the feeds (like /feeds/atom10.xml) were answered with a HTTP 304 Document Unmodified response. I downloaded the XML and the new entry is included with

Code: Select all

<published>2009-10-04T15:31:00Z</published>
<updated>2009-08-24T18:25:26Z</updated>

A trace of the network packets showed, that everybody is accessing the feed with a Modified-Since header that asks for updates since 2009-08-24 and my webserver happily responds with Document Unmodified. For the just published entry I find the following timestamps in the entries table (converted to readable output):

Code: Select all

     timestamp      |    last_modified    
--------------------+---------------------
2009-10-04 15:31:00 | 2009-08-24 18:25:26

Looking at include/admin/entries.inc.php I believe the following is happening: I created the entry on August 24th. I edited it a couple of times as draft and used the clock button to adjust the time. But that only seems to have an effect on the timestamp and not the last_modified attribute. When I finally published the article today it is still marked as old in the database. In my opinion the last_modified attribute should be adjusted for every save operation as well. I looked into the 1.5 beta code (I'm still on 1.4.1) and it doesn't seem to have changed there. Maybe this could be fixed before 1.5 comes out?

Regards,
Stefan

[garvinhicking]

Hi!

Thanks for mentioning this. Indeed I remember this has came up at some point in 1.5 developemnt, and I think we did some changes there; either inside the rss.php file or inside the include/functions_entries.inc.php.

Since 1.5 is close to final release, maybe you'd like to help inspect this issue and upgrade to the recent snapshot to tell me if its fixed?

Regards,
Garvin

[Cenic]

Hi Garvin,

I have compared the two files you mentioned from the latest snapshot (the last three are empty BTW) to my installed files. That is

Code: Select all

<?php # $Id: functions_entries.inc.php 2395 2008-12-09 10:05:33Z garvinhicking $
<?php # $Id: rss.php 2326 2008-08-27 19:20:23Z garvinhicking $

in my 1.4.1 installation and

Code: Select all

<?php # $Id: functions_entries.inc.php 2583 2009-09-12 11:18:28Z garvinhicking $
<?php # $Id: rss.php 2446 2009-01-30 14:03:31Z garvinhicking $

in the current snapshot. Unfortunately I don't see any change that involves the timestamps. Around line 1296 there is the following code in serendipity_updertEntry which you might have in mind:

Code: Select all

if (!isset($entry['last_modified']) || !is_numeric($entry['last_modified'])) {
    $entry['last_modified'] = $entry['timestamp'];
}

I guess that is never executed again, since the existing entry in draft mode in fact has a last_modified attribute. Shouldn't last_modified be the maximum of timestamp and the current time, that is

Code: Select all

$entry['last_modified'] = max($entry['timestamp'], time());

without any additional condition to make sure it is updated whenever the entry is saved?

Regards,
Stefan

[garvinhicking]

Hi!

I'm sorry, I then must have confused something. No reason came to my mind why last_modified should not be inreased; the current code logic would only set it, if the entry has not been in draft mode before.

I patched it like you suggested, to always update last_modified = time().

Thanks,
Garvin

[Cenic]

Hi Garvin,

thanks for your support!
Looking forward to the 1.5 release.

Regards,
Stefan