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

I’m happy to announce that FeedWordPress version 2011.1018 is now available for download.

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: syndicateditemguid FILTERS FIXED. Previous versions of
    FeedWordPress theoretically allowed for filters on the syndicateditemguid
    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: syndicateditemguid 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 drop me a line 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 download and enjoy!

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

  1. 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.

    • 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

  2. 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

    • 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.

Leave a Reply

Your email address will not be published. Required fields are marked *