FeedWordPress 2011.1018. It’s like two upgrades in one!

I’m happy to announce that ** version 2011.1018 is now available for download(http://downloads.wordpress.org/plugin/feedwordpress.2011.1018.zip).**

This announcement is actually going to sum up the changes for a couple of different releases of FeedWordPress. The previous public release, **2011.0721**, was released some time ago, and has been available at through the WordPress plugin repository, but I was unable to post the announcement on the project due to an unfortunate combination of two factors: a technical breakdown at the old project website, and a cross-country move that effectively prevented me from taking the time to fix the breakdown. Happily, the move is over and, rather than fixing the breakdown, I have simply decided to migrate the project website over to a brand new home. (Same URL as before, but running the latest release of WordPress.) So, without further ado, here are the changes made in today’s release, along with the changes that 2011.0721 had already introduced:

### Version 2011.1018 ###

* **HTTP BASIC AND DIGEST AUTHENTICATION SUPPORT:** FeedWordPress now offers
improved support for syndicating feeds that make use of HTTP Basic or HTTP
Digest authentication methods. In order to set up authentication on one of
your feeds, just go to its Settings > Feed page, and click on the “Uses
Username/Password” link underneath the Feed URL. Enter the username and
password for accessing the feed, then select the authentication method. (If
you’re not sure which method your feed provider uses, try Basic first.)
Save Changes, and syndicate away.

**NOTE:** HTTP Digest support requires the curl module for PHP. If you are not
sure whether this module has been installed, contact your web hosting
provider to check.

* **WP 3.3 (BETA) COMPATIBILITY:** This version fixes an init-sequence bug that
could cause intrusive warning messages or fatal errors in WP 3.3 beta
versions.

* **BUGFIX: FIXES LONG DELAYS IN UPDATES SCHEDULES IN LARGE INSTALLATIONS.** A
performance feature introduced in version 2011.0721 had some flaws in its
implementation, which tended to create serious delays (on the order of
several hours) in FeedWordPress’s attempts to schedule updates for feeds,
when users had a very large number of feeds (several dozen or more) in their
FeedWordPress installation. This feature has been reconfigured to adjust
dynamically to the number of feeds in Syndicated Sources and the frequency
with which they are updated. If you’ve seen a lot of ready-to-update feeds
piling up, several hours after they were supposed to get updated, then this
upgrade should better ensure that your feeds get updated in a timely fashion.

* **BUGFIX: syndicated_item_guid FILTERS FIXED.** Previous versions of
FeedWordPress theoretically allowed for filters on the syndicated_item_guid
hook, which was intended to filter the globally-unique identifier element
(rss:guid or atom:id) — useful if you need to convince FeedWordPress to use
different guids, or to recognize two or more incoming posts as versions of
the same post rather than as distinct items. However, while the hook
affected the guid stored in the WordPress database, it did not affect the
guid used to check whether an incoming feed item had already been syndicated
or was a new item — which greatly limited the practical usefulness of the
filter. This bug has been fixed: syndicated_item_guid filters should now
properly control not only the final database record, but also the initial
uniqueness test applied to posts.

### Version 2011.0721 ###

* **BUGFIX: SERIOUS BUG CAUSING RARE UNEXPECTED DELETION OF PAGES AND OTHER
CONTENT.** A bug in the guid-checking code for some rare kinds of guids could
cause content in the wp_posts table to seemingly disappear at random after
FeedWordPress updates.This most frequently but not exclusively affected
static pages. What actually happened is that in these rare cases the
existing static page was mistaken for an older version of the new incoming
syndicated post, which was then stored as a new revision of the original
page. The bug that caused these mistaken identities has been fixed.

* **BUGFIX: UNWANTED AUTOMATIC PAGE-LOAD-BASED UPDATES NO LONGER A NUISANCE.**
Some users encountered a bug in which FeedWordPress would adopt an automatic
page-load-based update method, even if they had requested that it not do
so, and that it use a manual or cron job update method instead. The bug
causing this has been fixed, and page-load-based updates should no longer
trigger unless explicitly turned on.

* **WP 3.2 USER INTERFACE COMPATIBILITY: POST TAGS BOX NOW WORKS AGAIN.** The
release of WordPress 3.2 caused a breakage in the tags box which prevented
you from adding or removing tags under Syndication –> Categories & Tags.
(The breakage was the result of an incompatibility introduced by the new
release of jQuery.) This breakage has now been fixed, and the tags box
should work correctly again.

* **FEED UPDATE SCHEDULING IMPROVEMENTS: UI.** The Syndicated Sources table now
provides considerably more data to understand update scheduling, when
specific scheduling decisions are made because of, e.g., requests from the
feed producer.

* **FEED UPDATE SCHEDULING IMPROVEMENTS: ENFORCEABLE “MINIMUM INTERVAL” SETTING
TO SPACE OUT UPDATES.** Some feeds request specific update schedules, using
standard elements such as sy:updateFrequency and rss:ttl. Normally,
FeedWordPress respects any scheduling requests that a feed makes — if it
requests a longer gap between polls than what FWP would normally adopt, then
FWP slows down to meet the request. If it indicates a shorter gap than what
FWP would normally adopt, FWP speeds up and checks that feed for updates
more often than it normally would. Now, there should not be any way for user
settings to override an explicit slow-down request from the feed producer —
if producers indicate a particular update schedule, then polling the feed
more frequently than they request is considered abusive behavior. But
there’s no reason why users should not be able — if they so desire — to
override speed-up requests, and poll a feed *less* frequently than the
indicated update schedule, if the FWP user wants to space update checkins
over a longer interval of time. Before, they could not do this: FWP always
sped up to meet the indicated update schedule. Now, they can do this, by
using the new “Minimum Interval” setting in Syndication –> Feeds &
Updates..

As always, if you notice any problems, have any questions, need any help, or just want to say “Hi,” don’t hesitate to me a line(/contact) via e-mail or through the comment form. Keep in mind that while I do my best to answer any e-mails I receive about FeedWordPress, I’m currently working through a significant backlog of e-mails (somewhere in the high dozens or low hundreds) that accumulated while I was making my move. So for the time being, you can assume I’ll be getting back to you, but it may be a few days before that happens.

Now and enjoy(http://downloads.wordpress.org/plugin/feedwordpress.2011.1018.zip)!

Thanks for the heads-up about this.

I think I know where the problem is, but I need confirmation from someone whose system has the configuration that’s causing this error. (It most likely has to do with not having the libcurl module for PHP available on your system.) Anyway, if you’d be willing to do a quick experiment for me, I may be able to put a fix out first thing tomorrow morning.

Here’s the experiment: after the upgrade, there should be a new file in your wp-content/plugins/feedwordpress directory, called feedwordpresshttpauthenticator.class.php. If you can bring up that file in an editor and find the following method (should be at line #41):

function digest_dont ($use, $args) {
    if ($this->need_curl($args)) :
        $use = false;
    endif;
    return false;
} /* FeedWordPerssHTTPAuthenticator::digest_dont () */

Then try changing the final line from this:

    return false;

To this:

    return $use;

Save the file, re-upload to your wp-content/plugins/feedwordpress directory, and try fetching RSS feeds again. If it fixes your problem, I’ll incorporate the fix into an incremental release for tomorrow morning.

-C

9 thoughts on “FeedWordPress 2011.1018. It’s like two upgrades in one!”

bork on October 18, 2011 at 5:47 pm said:

The latest update borks WP. I’m getting the following error when trying to update feeds to install other plugin updates: “WP HTTP Error: There are no HTTP transports available which can complete the requested request.”

When I deactivate FWP, the errors go away and everything works fine again. I’m running WP 3.2.1.
- radgeek on October 18, 2011 at 7:52 pm said:
  Thanks for the heads-up about this.
  
  I think I know where the problem is, but I need confirmation from someone whose system has the configuration that’s causing this error. (It most likely has to do with not having the libcurl module for PHP available on your system.) Anyway, if you’d be willing to do a quick experiment for me, I may be able to put a fix out first thing tomorrow morning.
  
  Here’s the experiment: after the upgrade, there should be a new file in your wp-content/plugins/feedwordpress directory, called feedwordpresshttpauthenticator.class.php. If you can bring up that file in an editor and find the following method (should be at line #41):
```
function digest_dont ($use, $args) {
    if ($this->need_curl($args)) :
        $use = false;
    endif;
    return false;
} /* FeedWordPerssHTTPAuthenticator::digest_dont () */
```
  Then try changing the final line from this:
```
    return false;
```
  To this:
```
    return $use;
```
  Save the file, re-upload to your wp-content/plugins/feedwordpress directory, and try fetching RSS feeds again. If it fixes your problem, I’ll incorporate the fix into an incremental release for tomorrow morning.
  
  -C
- bork on October 18, 2011 at 8:49 pm said:
  
  Yep, that fixed it. Thanks!
- radgeek on October 19, 2011 at 5:15 pm said:
  
  Cool. Here, as promised, is the official release, which contains this fix, and some other UI tweaks as well.
  
  http://feedwordpress.radgeek.com/2011/10/19/feedwordpress-2011-1019/
Scott Tribe on October 18, 2011 at 9:46 pm said:

I was about to report the same error. I installed the plugin and did a manual feed read and each and every feed gave that error.
- Paul on October 19, 2011 at 4:51 am said:
  
  Exactly the same issue accross multiple blogs – the suggested ‘fix’ seems to have resolved the issue.
- radgeek on October 19, 2011 at 5:15 pm said:
  
  OK. Thanks for the heads-up. Here, as promised above, is the official release, which contains this fix, and some other UI tweaks as well.
  
  http://feedwordpress.radgeek.com/2011/10/19/feedwordpress-2011-1019/
Barbara Christensen on October 23, 2011 at 1:10 pm said:

Just did the update, and I’m getting this error:

Fatal error: Undefined class name ‘self’ in /home/content/s/i/l/silverlux/html/wordpress/wp-content/plugins/feedwordpress/feedwordpresshttpauthenticator.class.php on line 6
- radgeek on October 24, 2011 at 10:01 am said:
  
  Barbara,
  
  Sorry to hear you’re hitting this error. It sounds like the result of attempting to run WordPress on a web host that provides only PHP 4, rather than PHP 5 — could you let me know what version of PHP you are using?
  
  If it is PHP 4 that you’re running, then you might need to take a look at this for help: WordPress Codex: Switching to PHP 5. Up-to-date versions of WordPress (from 3.2 onward) require PHP 5.2 or higher. If there’s no good way right now for you to switch over to PHP 5, let me know — I have a work-around that you can use for the time being, so that you might be able to at least get FWP back up and running. But I should warn you that going forward, you may run into more problems with both the WordPress core and FWP until you are able to upgrade to PHP 5.

Comments are closed.