I've been trying to cleanly handle the switch from categories to tags by doing some fancy url rewriting using mod_rewrite, and I'm pulling out my hair.

After giving up in frustration at not being able to match what seems like a simple match, I decided to give up and just manually put in a rewrite ...

Oh, sorry. Late night hacking

I stuck it at line 131, and got it from the entries include file.

In case you run into the same difficulty I did, the plugin files inexplicably are named 'showentries' rather than 'sidebarentries.'

I've been working on some extreme template customization, and I'm using the Sidebar Entries plugin. I've been tearing my hair out trying to figure out why $entry.is_entry_owner isn't working as expected, and just figured out that the plugin isn't setting up that variable the same way that ...

OHHHH. You want Authorpic.. Do you have THAT plugin installed? The gravatar/favatar plugin is only for COMMENTS. The file that's named like your username and in your templates folder is called by the Authorpic plugin, not that gravatar/favatar plugin.

Try installing authorpic and see if that does ...

Maybe your style template doesn't support user images?

take a look at cookingwithkooks.org, that site is using the avatar plugin (but is using gravatars rather than local images)

Could you check if the 'entryproperties' table holds all the ep_aggregator_articleurl etc. items for your feed items? My guess is that those are missing, too?

Well, I can't vouch for whether they were there when the entries were saving as new, but they're all correct now..

I did a quick ...

arg!

I guess that didn't fix it after all. Every time I think I've got it, I learn I'm wrong. I've currently got 2 entries that it is detecting as new repeatedly, which both HAVE entries in the md5 table, they just show the wrong hash. So whatever is deleting the entries sometimes isn't always ...

Well, it did work the first time a feed was added. It's just somehow being removed when a feed is updated... I've gone 'round and 'round through there trying to figure out how, but nothing is jumping out at me.

I'll take a peek at the other table this evening, or in the next couple days. I have a ...

sorry 'bout the delay.

# Always update the MD5 hash, to catch updates of an entry properly. Patch by jerwarren!
$t = time();
$sql = "INSERT INTO {$serendipity['dbPrefix']}aggregator_md5
(entryid, md5, timestamp)
VALUES ('$entryid', '$md5hash', '$t')";

serendipity_db_query($sql);

It was ...

i was just playing around with it, and it seems your 'UPDATE' call is malformed or something. If I replace it with an INSERT (which I copied directly from a few lines up) it works like expected.

if I leave the entry in aggregator_md5, your UPDATE call removes it. In any case, this seems to solve my ...

that's the first thing I did in my own debugging process, and the value is valid at save time. It's got to be cleared out somewhere else along the way.

Perhaps when the aggregator runs and goes to do the check it is being deleted before the check?

hmm. my reply seems to have disappeared...

anyway, yeh, I have that code you added. I couldn't find anywhere where it was deleting either, but it's doing it. And only when aggregating a post that has changed since the initial aggregation. Also, it does it for any of the serendipity feeds I've got ...

You seem to know exactly what I'm trying to do, so any help/suggestions/advice is greatly appreciated! Thanks!!

OK, I just whipped up something that will do what you want. It doesn't currently take actual gravatar images into account however, so if you use my system and a user does actually have ...

After some more debugging, I've found that when it detects an updated post, it's actually deleting the MD5 hash from the serendipity_aggregator_md5 table. From that point onward, since there is no entry in the table, it is assumed to need updating.

I posted a new post, ran the aggregator, checked ...

Maybe that missing MD5 entry comes from the old versions of the plugin, and it should work for new entries?

Well, that was my first thought as well. But then when I thought about it more, it seems like if it was now working properly, it would be saving the 'new' updated post's MD5 to the table ...