[Plugin: FeedWordPress] Repeat posts on every update

I have the same problem!

It seems as if GUID is gone ??

I’ll try to downgrade wordpress…

Downgrading WordPress to 3.1.2 solved it for me. I’m not sure about what is the problem.

If anyone has a suggestion on how to delete all posts (and postmeta) for all duplicates, please tell. A sql-query would be nice.

I think Hotfix will solve it:

https://www.ads-software.com/extend/plugins/hotfix/

There is a bug in 3.1.3.

Hmm, Hotfix doesn’t fix it for me. I was hoping I wouldn’t have to downgrade as I’m not very good with MySQL manipulation. Seems to be the only solution at this point though. Is this a good procedure? https://www.cleverlight.net/blog/easy-wordpress-downgrade.html

Hi

I’m having the same problem with my blog.

Right now I set all syndicated posts to be ‘pending’ till I approve them – I just had to trash over 100 pending posts.

There seems to be no pattern to which posts from which feed it chooses to republish. I really have no idea what is going on. If someone comes up with a way to solve this, I would love to know!

Having the same problem, hotfix does not help.

Forcing all FeedWordpress posts to “pending” first, deleting hundreds of redundant ones:-(

One way to at least limit the damage is using the “FWP+: Limit posts by date” plugin and set it to 1-2 days and 1-2 post items only. This will limit how many posts are replicated, but at least in my case may risk missing valid new posts.

I can’t even downgrade to WP 3.1.2 being on a shared server:-(

Hey y’all,

Sorry about this, and thanks for putting up the heads-up here. I wish I had been able to push out a fix sooner, but WP 3.1.3 was released while I was on a week-long house-hunting trip. Argh.

Anyway. The good news is that this problem should now be fixed (or worked around, depending on your perspective) in the most recent version of FeedWordPress (v. 2011.0531), now available at feedwordpress.radgeek.com.

The rest is some technical details.

For those who are curious, the reason that this issue arose is that the most recent release of WordPress added a URL-check filtering function for post guids. Or, rather, it applies an existing filter — esc_url_raw() — to a field that it hadn’t previously been applied to — the guid. That filter rejects any URI that doesn’t begin with a protocol/scheme that’s on a hardcoded whitelist of allowable schemes — http, ftp, svn, gopher, and a handful of others. Unfortunately, the tag: scheme, used in tag URIs, is not on the list of allowable schemes, and WordPress provides no readily accessible way of extending the list to include it. This is unfortunate since esc_url_raw is now used to filter all incoming guids, and tag: URLs are very commonly used to produce opaque unique identifiers for use in the guid field. So, under the new rules in WP 3.1.3, posts from any source feed that used a tag: URI — which includes all feeds produced by Blogger, all feeds produced by other Google web services, and a number of other common feed sources, as well as any feeds that don’t include explicit guids (since FeedWordPress would generate a guid internally using the tag URI syntax) — would be inserted into the database with a blank guid, rather than with the guid they were assigned by the feed. This breaks FWP’s ability to recognize previously-syndicated posts, and causes the posts to be re-syndicated anew every time FWP checks the feed.

In my view, the failure to include tag: URIs in the list of allowable schemes, and the lack of any way to extend the list to include them, is somewhere in between a flaw and an outright bug in WordPress. Be that as it may, rejected guids are a condition that FWP will have to work around in a reasonable fashion. So the new release of FWP includes a work-around to generate an allowable guid if the guid assigned to the post gets filtered out.

So, again, to fix the issue, hopefully all you should need to do is upgrade to the most recent release of FWP.

-C

Hi Charles,

Thanks for responding so quickly (and I hope you’ve found the house…).

But I’m afraid the fix did not work, I keep on getting the same even after upgrading…

I’ve just realized my testing was flawed (?) since I just forced update all feeds and saw the dupes being created again. But those were posts that already had been published with the blanked out GUID ( I assume), so the proper test is only with NEW posts, or completely deleting one of the “bad” ones and re-updating them.
Will do more checking…

Yes, I think Charles’s fix is working – have not tested a lot, but so far so good – sorry for the false alarm.

Thanks a lot for the fast fix, Charles! ??

Zoli – in your case, did you have to completely remove all the entries that were being republished so that they would publish one final time as the correct version?

Also, should I not be forcing the feeds to update?

Zoli and I had a conversation about his case in e-mail. It turns out that the release put out today fixed the problem for some of his feeds (those which used tag: URLs), but didn’t cover a distinct problem that appeared in some other feeds — in particular, some feeds produced by ZDNet, which included leading or trailing whitespace in their GUID elements. I wrote a quick fix to cover that edge case, which is now part of the Development Version of FeedWordPress, and will be rolled into an official update sometime around tomorrow.

I’ve done more testing, and the new-new fix (the one coming out tomorrow) seems to be working with all my previous “problem feeds”.

sygnin: yes, you do have to completely remove the trouble entries (even from trash), so FWP can create a version with the proper GUID.

Ok, thanks guys!