FeedWordPress 2009.0618: bug fix eliminates HTTP request failures when FeedFinder uses WP_Http_Fsockopen

FeedWordPress 2009.0618 is now available for download.

This is a bug fix release. Other than a few mainly cosmetic code clean-ups, there is only one change between this release and the previous release, 2009.0613. But it’s an important one.

After upgrading to WordPress 2.8, many users reported encountering the following error whenever they attempted to add a new feed through FeedWordPress’s feed-finder interface:

HTTP request failure


HTTP Transports available:

  1. WP_Http_Fsockopen

I reported earlier that this error was the result of some changes in the HTTP request functions provided by FeedWordPress (changes to the order in which different HTTP transports are used; changes which I think were rather ill-considered). After managing to replicate the problem and investigating more deeply, I found out that it was actually the result of a combination of two factors — the changes in WordPress 2.8 (which I still think were a mistake) and also a subtle bug in FeedWordPress’s feed-finder code, which the changes in the HTTP transport code ended up exposing. In any case, the subtle bug has now been fixed, and with it, the source of most of these HTTP request errors should be eliminated.

So, if you’ve been encountering this problem, be sure to download the most recent FeedWordPress. Then, after it’s installed, make sure you also upgrade your MagpieRSS to the version included with the most recent FeedWordPress. The fix is included in the MagpieRSS code, and will not be applied unless and until you upgrade your MagpieRSS to version 2009.0618.

Download and enjoy! As always, you have any issues with the release, or if there is anything that you would like to see included in a future release, please use the comments form or drop me a line to let me know about it.

Please remember that your generous gifts to the project tip jar make ongoing development and support for FeedWordPress possible.

Posted in Uncategorized

FeedWordPress 2009.0613: minor UI glitches fixed and improved diagnostics for feed problems

FeedWordPress version 2009.0613 is now available for download.

This is a very minor update, which I guess should not be too much of a surprise, if you take into account the fact that I made a major release just yesterday. However, due to some difficulties that some people have been having, I thought it would be a good idea to push out a release with better diagnostics.

The basic issue is this: until WordPress version 2.7, FeedWordPress used the Snoopy HTTP library (which is included in WordPress) to fetch feeds for updating, and also for the feed finder that helps you subscribe to new feeds in the administrative interface. With WordPress 2.7, however, the WordPress team decided to deprecate Snoopy — so it’s still included with WordPress, but not used internally, and it may be dropped from future releases — and to introduce a new custom API for HTTP requests (the WP_Http class and some wrapper functions that make use of it). So, if you’re using WordPress 2.7.x or 2.8, FeedWordPress uses the new functions rather than the deprecated Snoopy module. One of the advantages of the new code is that it is supposed to be able to make use of any of several different HTTP transport APIs which may be available, depending on your PHP set-up (for example libcurl, fsockopen, URL support in fopen, etc.). But I’ve been noticing problems that many users have had that tie back to problems with the underlying HTTP transports used by WordPress’s new code, and, for reasons that are unclear to me, the WordPress development team decided to make some changes in WordPress 2.8 which make these problems even more likely to occur and even harder to get around. In any case, this is almost certainly the underlying issue if you, like others, are encountering something like this when you try to syndicate a new feed:

Error: I couldn’t find any feeds at <http://example.com/> request error: :. Try another URL

The best solution for you will depend on details about your own hosting situation — in particular, what version of WordPress you are using FeedWordPress with, and whether or not you are able to install new PHP modules on your web host, or, if not, whether or not you have someone who is willing to install new PHP modules for you. Unfortunately it’s not likely to be something that FeedWordPress itself can fix. But I have made some updates so that FeedWordPress will, at least, provide some more useful diagnostic information — which may help you figure out what needs to be done, or which will hep me help you figure it out, if you send the diagnostic information to me along with your support request.

So, anyway, all that said, that’s why I’m pushing out a new release today. (There are also a couple other minor changes included in the release, but I would probably not have bothered with a public release just yet except for the number of support requests I’ve gotten since yesterday’s release, which the diagnostics would help with.) Other than some under-the-hood re-arranging of the code, here are the significant changes between 2009.0613 and the previous releas, 2009.0612:

    change in class names between the WordPress 2.7 and 2.8 stylesheets,
    category boxes in the FeedWordPress settings interface tended to overflow
    and have a lot of messy-looking overlapping text under WordPress 2.8.
    This has now been fixed.

  • FeedFinder FAILURE DIAGNOSTICS: When FWP’s FeedFinder fails to find any
    feeds at a given URL (for example, when you are trying to add a
    subscription through the administrative interface and you run into an
    error message), FeedWordPress now provides more diagnostic information
    for the reasons behind the failure. If that helps you, great; if not,
    it should help me respond more intelligently to your support request..

Download and enjoy! As always, you have any issues with the release, or if there is anything that you would like to see included in a future release, please use the comments form or drop me a line to let me know about it.

Please remember that your generous gifts to the project tip jar make ongoing development, quick fixes and timely support for FeedWordPress possible.

Posted in Uncategorized

FeedWordPress 2009.0612: WordPress 2.8 compatibility, interface redesign, bug fixes, and significant convenience features added

FeedWordPress version 2009.0612 is now available for download.

Given the recent release of WordPress 2.8 I thought it would be an opportune time to roll up the development I’ve been doing on FeedWordPress over the past few months and push out a new official release. A list of major changes since the last release follows below.

First things first, though. A new version of WordPress has come out, which has caused a number of e-mails — just like every WordPress release does — from people who upgraded WordPress to the latest version, and, in the process, inadvertently downgraded their MagpieRSS to the old, busted version included with WordPress. If you have noticed strange problems with syndicating feeds (especially Atom feeds) immediately after making the upgrade, like those described in my old post about upgrading to WordPress 2.5, then you need to re-copy the MagpieRSS upgrades from your FeedWordPress installation to the wp-includes/ subdirectory of your WordPress installation. Fortunately, if you upgrade to FeedWordPress 2009.0612, one of the new features included in the package is that it will politely remind you to perform this upgrade if it notices that the old version of MagpieRSS is the one that’s loading up.

Now, then. Here are the major changes since the release of FeedWordPress 2008.1214.

  • WORDPRESS 2.8 COMPATIBILITY: FeedWordPress 2009.0612 has been tested for
    compatibility with the recent version 2.8 release of WordPress.

  • INTERFACE RESTRUCTURING: In order to avoid settings posts from becoming
    too crowded, and to modularize and better organize the user interface,
    new “Posts” and “Categories & Tags” subpages have been created under the
    “Syndication” menu. “Posts” controls settings for individal syndicated
    posts (such as publication status, comment and ping status, whether or
    not to use the original location of the post as the permalink, whether
    or not to expose posts to formatting filters, and so on). “Categories &
    Tags” controls settings for assigning new syndicated posts to categories
    and tags, such as categories or tags to apply to all syndicated posts,
    and how to handle categories that do not yet exist in the WordPress
    database. These subpages, like the Authors subpage, handle settings for
    the global default level and for individual syndicated feeds.

    Corresponding to these new subpages, the old Syndication Settings and
    Feed Settings subpages have been cleaned up and simplified, and now only
    link to the appropriate subpages for options that can be set in the
    Posts, Authors, or Categories & Tags subpages.

    long had an interface for creating custom settings for each syndicated
    feed which could be retrieved in templates using the get_feed_meta()
    template function. But it had no feature for adding custom fields to
    each individual syndicated post. In response to requests from users, I
    have added the ability to apply custom fields to each individual
    syndicated post, using the new Syndication –> Posts subpage. You can
    set up custom fields to be applied to every syndicated post, or custom
    fields to be applied to syndicated posts from a particular feed.

    to determine whether or not you are using the upgraded version of
    MagpieRSS that comes packaged with FeedWordPress. If not, it will throw
    an error on admin pages, and, if you are a site administrator, it will
    give you the option to ignore the error message, or to attempt an
    automatic upgrade (using a native file copy). If the file copy fails,
    FeedWordPress will offer some guidance on how to perform the upgrade

    to the fact that I relied on a content normalization that occurs in my
    upgraded version of MagpieRSS, but not in the old & busted version of
    MagpieRSS that ships with WordPress, until this version, if you tried to
    syndicate an Atom feed without having performed the (strongly
    ) MagpieRSS upgrade, all of the posts would come up with
    completely blank contents. That’s not because MagpieRSS couldn’t read
    the data, but rather because the new Magpie version puts that data in a
    location where the old version doesn’t, and I was only looking in that
    newer location. Now it checks for both, meaning that posts will continue
    to display their contents even if you don’t upgrade MagpieRSS. (But you
    really should upgrade it, anyway.)

    back, I added support for resolving relative URIs against xml:base on
    feeds that support it to the MagpieRSS upgrade in FeedWordPress. Then I
    took out code that did the same thing from the main FeedWordPress code.
    Of course, the problem is that some people, even though it is clearly
    stupid or evil to do so, still include relative URIs for images or links
    in posts on feed formats that do not adequately support xml:base
    (notably, RSS 2.0 feeds). In response to a user request, I have added
    this functionality back in, so that MagpieRSS will resolve any relative
    URIs that it knows how to resolve using xml:base, and then FeedWordPress
    will attempt to resolve any relative URIs that are left over afterwards.

    Due to a version-checking
    bug, users of WordPress 2.7.x lost an option from the “Edit a syndicated
    feed” interface which allowed them to determine whether newly syndicated
    posts should be published immediately, held as “Pending Review,” saved
    as drafts, or saved as private posts. (The option to change this
    setting globally remained in place, but users could no longer set it on
    a feed-by-feed basis.) The version-checking bug has been fixed, and the
    option has been restored.

    Under certain circumstances (for example, when users have configured
    their browser or proxy not to send HTTP Referer headers, for privacy or
    other reasons), many features in the FeedWordPress administrative
    interface (such as adding new feeds or changing settings) would hit a
    fatal error, displaying only a cryptic message reading “Are you sure?”
    and a blank page following it. This problem has been eliminated by
    taking advantage of WordPress’s nonce functions, which allow the
    security check which ran into this error to work properly even without
    receiving an HTTP Referer header. (N.B.: WordPress’s nonce functions
    were first introduced in WordPress 2.0.3. If you’re using FeedWordPress
    with an older version of WordPress, there’s no fix for this problem:
    you’ll just need to turn Referer headers back on. Sorry.)

    If you manually altered the post status,
    comment status, or ping status of a syndicated post from what it was set
    to when first syndicated — for example, if you had a feed that was set
    to bring in new posts as “Pending Review,” and you then marked some of
    the pending posts as “Published” and others as “Unpublished” — then
    in previous versions of FeedWordPress, these manual changes to the
    status would be lost — so that, for example, your Published or Unpublished
    articles would revert to Pending Review — if the source feed made any
    upates to the item. This could make the Pending Review feature both
    unreliable and also extremely frustrating to work with. The good news is
    that this bug has since been fixed: if you manually update the status
    of a post, it will no longer be reverted if or when the post is updated.

    limited conditions (specifically, when both the title and the content of
    a post to be updated are empty), an attempt to update the post would
    result in a fatal error. This has been fixed.

    When you add a new subscription to
    FeedWordPress, the message box that appears to confirm it now includes a
    handy link to the feed’s settings subpage, so that you can quickly set
    up any special settings you may want to set up for the new feed, without
    having to hunt through the list of all your other subscriptions to pick
    out the new one.

    removed an interval setting for the cronless automatic updates which has
    confused many FeedWordPress users. In past versions of FWP, when you
    turned on automatic updates, you would be presented with a time interval
    setting which controlled how often FeedWordPress would check for feeds
    ready to be polled for updates. (That is, it DID NOT control how often
    feeds would be polled; it controlled how often FeedWordPress would
    check for feeds that had become ready to poll. The schedule on which
    feeds became ready for polling was still controlled either by requests
    encoded in elements within the feed itself, or else according to an
    internal calculation within FeedWordPress, averaging out to about 1 hour,
    if the feed did not include any scheduling request elements.) Since many
    users very often (and understandably) confused the purpose of this
    setting, and since the setting is for a feature that’s actually very
    unlikely to require any manual control by the user, I have removed the
    setting; FeedWordPress now simply uses the default value of checking for
    feeds to poll every 10 minutes.

    now uses array_unique() to make sure that it doesn’t waste time
    repeatedly iterating over and polling the same URI. Props to Camilo

Enjoy! As always, you have any issues with the release, or if there is anything that you would like to see included in a future release, please use the comments form or drop me a line to let me know about it.

Please remember that your generous gifts to the project tip jar make ongoing development and support for FeedWordPress possible.

Posted in Uncategorized