Feed importer doesn't update comments' quantity of already imported feed items

Tiny Tiny RSS Support
1

How to reproduce:

  1. Let updater imports some feed item. As a consequence, database remembers number of comments for this item.
  2. Let number of comments is changed in the RSS feed.
  3. Let updater processes the same feed item again.

Updater does not update comments’ quantity in the database. Therefore database stores the value of comments’ number that was firstly imported.

2

looks like you’re right although i’m not sure if its such a bad thing

updating one number vs recalculating everything in the database (i.e. running article plugins), idk if its worth it

3

Just for note: some fields, such as author, are updated for already imported items. And even filters are started again for these items (as a consequence: if user removes some labels and thereafter some filter assigns some removed labels then deleted labels are repaired).

4

yeah i agree that this behavior is inconsistent, since most of the fields are updated i guess comment count should too

5

I had noticed that some time ago and put the comments count update into the date_updated modification branch so that no new hash calculation would be triggered, like so:

--- a/include/rssfuncs.php
+++ b/include/rssfuncs.php
@@ -757,7 +757,7 @@
 
 					$base_entry_id = db_fetch_result($result, 0, "id");
 
-					db_query("UPDATE ttrss_entries SET date_updated = NOW()
+					db_query("UPDATE ttrss_entries SET date_updated = NOW(), num_comments = '$num_comments'
 						WHERE id = '$base_entry_id'");
 
 					continue;

(Yeah, I’m somewhat behind latest trunk. Line should be here now).

While hijacking this conversation I could also mention that the possibility of content replacement for starred articles is not really satisfactory. This can be fixed with

-				if ($entry_current_hash == $entry_stored_hash && !isset($_REQUEST["force_rehash"])) {
+				if ($marked_ || ($entry_current_hash == $entry_stored_hash && !isset($_REQUEST["force_rehash"]))) {

here, where $marked_ indicates if the entry is starred or not and has to be set somewhat above that change. Dunno how anybody else feels about this, but I lost some starred articles because of hash recalculations.

6

that’s just adding to inconsistency, to make this work properly it should trigger article hash recalculation.

what do you mean lost?

7

heads up, comment count should update article hash now. sorry it took me a while, i was busy with some other stuff and completely forgot about it.

8

Is there a chance this could be made optional? I don’t speak PHP, or I’d attempt it myself. I was wondering if there could be a checkbox on the feed preferences, and then if true, the comment count could be checked. If false, it would be excluded from the hashing.

9

care to elaborate why? i’m unironically interested

the answer is no, of course

10

OK.

There are some sites where I like what the authors say, but the comments sections are less than spectacular, where less than spectacular refers to dumpster fires.

I’d like to be able to keep up with what the author says, but don’t need the updates whenever someone comments on the article.

11

are you sure you actually understand what was discussed here?

hint: you are not going to get duplicate articles or whatever, it’s just the comment count will change in the UI, if you read the article already you will never notice this.

12

OK. Should it have triggered an “everything that has comments is now unread once” then?

13

i have no idea wtf you’re talking about

14

For all feeds that include comment counts in the feeds, should the rehashing make those articles appear as unread?

15

Nope, discussed patch merely updates comments count in the database and does not change article status or anything else.