Install Software For Free


Developer C. Johnson
Update Time Feb. 23, 2022, 5:15 a.m.
Donation URL: donation
PHP Version: 4.5 +
WordPress Version: 5.9
Copyright URL: Copyright Information


feed rss atom syndication aggregation


2022.0208 2022.0222 0.992 0.96 0.97 0.98 0.981 0.99 0.991 2011.0531 2011.0602 2011.0721 2011.1018 2011.1019 2012.1212 2012.1218 2013.0503 2013.0504 2014.0805 2015.0426 0.8 0.95 0.9 0.91 0.993 2008.1030 2008.1101 2008.1105 2008.1214 2009.0612 2009.0707 2009.1111 2009.1112 2010.0127 2010.0528 2010.0531 2010.0602 2010.0623 2010.0903 2010.0905 2011.0211 2011.0211.2 2011.0512 2011.0706 2015.0514 2016.0420 2016.1211 2016.1213 2017.0913 2017.1004 2017.1020 2020.0118 2020.0818 2021.0713 2022.0123 2022.0203 2009.0613 2009.0618 2022.0204


FeedWordPress is an Atom/RSS aggregator for WordPress. It syndicates content from feeds that you choose into your WordPress weblog, and then the content it syndicates appears as a series of special posts in your WordPress posts database. If you syndicate several feeds then you can use WordPress's posts database and templating engine as the back-end of an aggregation ("planet") website. It was developed, originally, as a utility/hobby project, because I needed a more flexible replacement for Planet for aggregator sites that I administered. FeedWordPress is designed with flexibility, ease of use, and ease of configuration in mind. You'll need a working installation of WordPress (version 4.5 or later), and it helps to have SFTP or FTP access to your web host. The ability to create cron jobs on your web host is helpful but not required.


To use FeedWordPress, you will need: New Installations
  1. Download the FeedWordPress installation package and extract the files on your computer.
  2. Create a new directory named feedwordpress in the wp-content/plugins directory of your WordPress installation. Use an FTP or SFTP client to upload the contents of your FeedWordPress archive to the new directory that you just created on your web host.
  3. Log in to the WordPress Dashboard and activate the FeedWordPress plugin.
  4. Once the plugin is activated, a new Syndication section should appear in your WordPress admin menu. Click here to add new syndicated feeds, set up configuration options, and determine how FeedWordPress will check for updates. For help, see the FeedWordPress Quick Start page.
Upgrades To upgrade an existing installation of FeedWordPress to the most recent release:
  1. Download the FeedWordPress installation package and extract the files on your computer.
  2. Upload the new PHP files to wp-content/plugins/feedwordpress, overwriting any existing FeedWordPress files that are there.
  3. Log in to your WordPress administrative interface immediately in order to see whether there are any further tasks that you need to perform to complete the upgrade.
  4. Enjoy your newer and hotter installation of FeedWordPress


2022.0222 2022.0204 2022.0123 Vulnerability CVE-2021-25055 allowed for an XSS (Cross-Site Scripting) attack using a specially crafted URL for a page within the FeedWordPress admin interface. (To be exploited, an existing user with login credentials that allow them to access the FeedWordPress dashboard would have to follow the malicious URL and log in.) This vulnerability has been corrected in the current version; to protect your site's security PLEASE BE SURE TO UPGRADE AS SOON AS POSSIBLE to version 2022.0123 or later, via the WordPress Plugin Repository or via Github. * BUG FIXES: Fixes a number of small possible bugs when creating new syndicated posts under unusual conditions -- a sanity check is built in to avoid infinite loops in case of certain unexpected error outcomes when creating new users; some more possible sources of PHP 8 "Countable" warnings are eliminated, etc. 2021.0713 2020.0818 2020.0118 2017.1020 Back when FeedWordPress was first created, the assumption was that a well-behaved aggregator would include boilerplate text to indicate the source of syndicated posts, but that the best way to do this was to provide a set of syndication-specific template tags so that the administrator setting up the site could edit their Theme template files with constructs like: This post by originally appeared at . By . You can still do this, of course, and for maximum expressive power and flexibility, it is certainly the best way to do it. Template Tags are documented here: However, (1) it requires writing PHP code, which not everyone is comfortable doing; and (2) it requires altering template files within your Theme, which is not always possible, especially given the increasing role that prepackaged commercial themes have come to play in the WordPress ecosystem. So, now, you can get some basic features for adding boilerplate text and attribution credits even without touching your template files, and without having to add custom add-ons for FeedWordPress. Enjoy! * MINOR CODE MODERNIZATION, PHP 7.1 COMPATIBILITY AND BUG FIXES. This project is now 12+ years old (good lord), and there are still some places where code was written at a time when PHP was a very different language from what it is now. Props to @david-robinson-practiceweb for pointing out and sending a pull request to fix some instances where obsolete PHP reference notation (&$q on parameters and so on) created a compatibility problem for PHP 7.1. Props to an email correspondent for pointing out a place in SyndicatedPost where excerpts should be generated from post content using encoding-aware mb_substr(), instead of naively running them through substr(). I've begun making some efforts throughout to begin auditing some of the creakiest old code in the project, to update what needs updating and improve documentation throughout. 2017.0913 ... where is the server that your own copy of FeedWordPress is installed. This release of FeedWordPress normalizes post guid prefixes so as to avoid or limit the scope of this problem. * PHP 7 Compatibility: eliminate remaining sources of PHP 7 compatibility-check failures -- remove the use of depreciated mysql_error() function, and make sure all classes make use of __construct() convention for constructors. * AVOID "PHP Warning: shell_exec() has been disabled for security reasons in [...]/feedwordpress/feeds-page.php on line 197": FeedWordPress uses the PHP shell_exec() function in a very narrowly limited way for information gathering, trying to find the real path to curl or wget on your system, so that it can give as realistic as possible a recommendation for the sample crontab line displayed in Syndication > Feeds & Updates. Some web hosting environments disable shell_exec for security reasons (since it could in theory be used to do a lot more stuff than the very limited information gathering FWP uses it for); in which case, this part of the code in FeedWordPress could spit out a nasty-looking and potentially worrisome-looking error message. So, now this code is fenced with checks to make sure that shell_exec is available, before FWP attempts to make use of it. 2016.1213 In theory, up to this point, FeedWordPress supported any version of WordPress from version 3.0 onward. In practice, version 3.0 was released over 6 years ago, and I can realistically commit only to testing out new releases of FeedWordPress with a few prior versions of WordPress; so I've updated the "Requires at least" field to version 4.5, the first major release issued in 2016. If you've really got to use FeedWordPress with older versions of WordPress, it will probably still work with any moderately modern release of WordPress, but I won't promise to keep it working with releases of WordPress that are more than about a year old. 2016.1211 2016.0420 2015.0514 The first is a common problem across several plugins due to an ambiguity in the WordPress documentation and a change in the behavior of WordPress's built-in add_query_arg() and remove_query_arg() functions which could, under certain low-probability conditions, allow for potential XSS attack vectors. This fixes issue # 39 reported at Thanks to The second fixes a security vulnerability that was reported to me privately (thanks to Adrián M. F.) which, under other low-probability conditions, could allow for SQL insertion attacks by a malicious user with access to login credentials, which would compromise data security. It is IMPORTANT and worth your while to upgrade FeedWordPress as soon as possible in order to eliminate these vulnerabilities. If you have any questions or if there is something blocking you from making the upgrade which you need my help with, don't hesitate to get in touch. * ADMIN UI BUGFIX: "Update Now" button in feeds setting pages should now work once again instead of causing a PHP fatal error. See * SEVERAL OTHER SMALL BUG FIXES. See etc. 2014.0805 2013.0504 2012.0504 2012.0503 2012.1218 2012.1212 As always, if you encounter any compatibility problems after upgrading your version of WordPress and your version of FeedWordPress to the most recent versions, please contact me with as detailed a description as possible of the issue you are encountering, the circumstances you're encountering it under, what you expect to see happening, and what is happening instead. * PHP 5.4 COMPATIBILITY: This release has been audited to fix potential problems with deprecation notices or fatal errors under recent versions of PHP. In particular, all uses of run-time pass-by-reference have been eliminated from the code; if you were seeing a fatal error reading "Call-time pass-by-reference has been removed ..." then upgrading to this release should fix the problem. * CUSTOMIZATION FRAMEWORK: A great deal of work has been done to make the underlying framework more flexible, so that PHP add-ons can be written to adapt FeedWordPress to handle custom XML vocabularies, expiration of posts under specified conditions, and other custom behavior. * BUGFIX: MANUALLY EDITED POST SLUGS NOT OVERWRITTEN. Thanks to a report by Chris Fritz, I've identified some code that causes post slugs for the posts generated by FWP to be rewritten with every update, even if the user has manually updated the slug from within the WordPress editing interface. This has been fixed: FWP will continue to generate new slugs for syndicated posts, but when syndicated posts are updated, they will retain the slug that they had at the time of the update; any manual changes to the post slug should be preserved. * USER-AGENT STRING: FeedWordPress now sends a distinctive User-Agent string identifying itself, and noting that it is a feed aggregator. * MISCELLANEOUS PERFORMANCE IMPROVEMENTS: A number of changes have been made to try to reduce the intensity and expense in terms of both database performance and web server memory consumption. * DIAGNOSTICS IMPROVEMENTS: A number of new and improved diagnostics have been added which should aid in understanding and troubleshooting issues that may arise. 2011.1019 2011.1018 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. 2011.0721 2011.0706 2011.0602 2011.0531 2011.0512 2011.0211 2010.0905 2010.0903 2010.0623 2010.0602 2010.0531 2010.0528 Compatibility Features and Processing Parsing API Bug Fixes 2009.0707 2009.0618 Be sure to upgrade your MagpieRSS to the most recent MagpieRSS version after you have insalled FeedWordPress 2009.0618, or this bug fix will not take effect. 2009.0613 2009.0612 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. * FEATURE: ADD CUSTOM SETTINGS TO EACH SYNDICATED POST: FeedWordPress has 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. * FEATURE: MAGPIERSS VERSION CHECK AND UPGRADE: FeedWordPress will attempt 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 manually. * BLANK POSTS PROBLEM NO LONGER OCCURS WITH OLD & BUSTED MAGPIERSS: Due 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 recommended) 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.) * BUGFIX: RELATIVE URI RESOLUTION FOR POST CONTENT RESTORED. Some time 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. * BUGFIX: INTERFACE OPTION FOR SETTING SYNDICATED POST PUBLICATION STATUS ON A FEED-BY-FEED BASIS HAS BEEN RESTORED: 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. * BUGFIX: "ARE YOU SURE?" FATAL ERROR ELIMINATED AND SECURITY IMPROVED: 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.) * BUGFIX: MANUALLY-ALTERED POST STATUS, COMMENT STATUS, AND PING STATUS NO LONGER REVERTED BY POST UPDATES: 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. * BUGFIX: OCCASIONAL FATAL ERROR ON UPDATE ELIMINATED: Under certain 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. * INTERFACE: "CONFIGURE SETTINGS" CONVENIENCE LINK ADDED TO CONFIRMATION MESSAGE WHEN A NEW FEED IS ADDED: 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. * INTERFACE: SIMPLIFYING AND CLARIFYING AUTOMATIC UPDATES SETTINGS. I have 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. * FEEDFINDER PERFORMANCE IMPROVEMENT: FeedWordPress's FeedFinder class now uses array_unique() to make sure that it doesn't waste time repeatedly iterating over and polling the same URI. Props to Camilo ( 2008.1214 2008.1105 Please note that if you have already encountered this issue on your blog, upgrading FeedWordPress will prevent it from re-occurring in the future, but you still need to do two other things to fix the existing problem on your blog. First, for each feed where posts have been mis-attributed, you need to change the existing author mapping rules to re-map a a syndicated author's name to the proper target account. Go to Syndication --> Authors, select the feed you want to change from the drop-down list, and then change the settings under the "Syndicated Authors" section. (You will probably need to select "will be assigned to a new user..." to create a new user account with the appropriate name.) Second, for each feed where posts have been mis-attributed, you need to re-assign already-syndicated posts that were mis-attributed to the correct author. You can do that from Syndication --> Authors by using the author re-assignment feature, described below. * AUTHOR RE-ASSIGNMENT FOR A PARTICULAR FEED: The author settings page for each syndicated feed, under Syndication --> Authors, now includes an section titled "Fixing mis-matched authors," which provides an interface for re-assigning or deleting all posts attributed to a particular author on a particular feed. * SUPPORT FOR <atom:source> ELEMENT IN SYNDICATED FEEDS: Some feeds (for example, those produced by FeedWordPress) aggregate content from several different sources, and include information about the original source of the post in an <atom:source> element. A new setting under Syndication --> Options allows you to control what FeedWordPress will report as the source of posts syndicated from aggregator feeds in your templates and feeds: you can have FeedWordPress report that the source of a post is the aggregator feed itself, or you can have it report that the source of a post is the original source that the aggregator originally syndicated the post from. By default, FeedWordPress will report the aggregator, not the original source, as the source of a syndicated item. * LOAD BALANCING AND TIME LIMITING FEATURES FOR UPDATES: Some users have encountered issues due to running up against PHP execution time limits during the process of updating large syndicated feeds, or a very large set of syndicated feeds. FeedWordPress now has a feature that allows you to limit the total amount of time spent updating a feed, through the "Time limit on updates" setting under Syndication --> Options. By turning on this setting and adjusting the time limit to a low enough figure to avoid your PHP installation's time-out setting. (PHP execution time limits are usually in the vicinity of 30 seconds, so an update time limit of 25 seconds or so should provide plenty of time for updates while allowing a cushion of time for other, non-update-related functions to do their work.) If feed updates are interrupted by the time limit, FeedWordPress uses some simple load balancing features to make sure that updates to other feeds will not be blocked by the time-hogging feed, and will also make sure that when the interrupted update is resumed, FeedWordPress will skip ahead to resume processing items at the point at which it was interrupted last time, so that posts further down in the feed will eventually get processed, and not get blocked by the amount of time it takes to process the items higher up in the feed. * guid INDEX CREATION BUTTON: FeedWordPress frequently issues queries on the guid column of the WordPress posts database (since it uses post guid URIs to keep track of which posts it has syndicated). In very large FeedWordPress installations, you can often significantly improve performance by creating a database index on the guid column, but normally you would need to poke around with MySQL or a tool like phpMyAdmin to do this. FeedWordPress can now save you the trouble: to create an index on the guid column, just go to Syndication --> Options, and mash the button at the bottom of the "Back End" section. 2008.1101 2008.1030 In addition, you can now set particular tags to apply to all incoming syndicated posts, under Syndication --> Options, or you can set tags to apply to all incoming syndicated posts from a particular feed in that feed's Edit screen. * FORMATTING FILTERS: There is a new option available under Syndication -> Options which allows users to choose whether or not to expose syndicated posts to being altered by formatting filters. By default, FeedWordPress has always protected syndicated posts (which are already in display-ready HTML when they are syndicated) from being reformatted by formatting filters. However, this approach means that certain plugins which depend on formatting filters (for example, to add "Share This" bars or relevant links to the end of a post) are blocked from working on any syndicated posts. If you want to use one of these plugins together with FeedWordPress, you can now do so by changing the "Formatting Filters" setting from "Protect" to "Expose." * <atom:source> ELEMENTS NOW INCLUDED IN ATOM FEED: Atom 1.0 provides a standard method for aggregators to indicate information about the original source of a syndicated post, using the <atom:source> element. FeedWordPress now introduces standard <atom:source> elements including the title, homepage, and feed URI of the source from which a syndicated post was syndicated. Cf. * MODULARIZATION OF CODE: The code for different elements of FeedWordPress has been broken out into several modules for easier inspection, documentation, and maintenance of the code. * VERSIONING SCHEME CHANGED: FeedWordPress's feature set has proven stable enough that it can now be removed from beta status; a good thing, since I was very quickly running out of version numbers to use. New releases of FeedWordPress will have version numbers based on the date of their release. 0.993 0.992 1, the site administrator). Administrators can also create re-mapping rules for particular feeds (under Syndication --> Syndicated Sites --> Edit), so that (for example) any posts attributed to "Administrator" on the feed will be assigned to a user named "Roderick T. Long," rather than a user named "Administrator." These settings also allow administrators to filter out posts by particular users, and to control what will happen when FeedWordPress encounters a post by an unrecognized user on that particular feed. * BUG RELATED TO URIS CONTAINING AMPERSAND CHARACTERS FIXED: A bug in WordPress 2.x's handling of URIs in Blogroll links created problems for updating any feeds whose URIs included an ampersand character, such as Google News RSS feeds and other feeds that have multiple parameters passed through HTTP GET. If you experienced this bug, the most likely effect was that FeedWordPress simply would not import new posts from a feed when instructred to do so, returning a "0 new posts" response. In other cases, it might lead to unpredictable results from feed updates, such as importing posts which were not contained in the feed being syndicated, but which did appear elsewhere on the same website. This bug has, hopefully, been resolved, by correcting for the bug in WordPress. 0.991 0.99 Version 0.99 adds several significant new features, fixes some bugs, and provides compatability with WordPress 2.2.x and 2.3.x. An important side-effect of the changes to the update system is that if you were previously using the cron job and the update-feeds.php script to schedule updates, you need to change your cron set-up. The old update-feeds.php script no longer exists. Instead, if you wish to use a cron job to guarantee updates on a particular schedule, you should have the cron job fetch the front page of your blog (for example, by using curl > /dev/null) instead of activating the update-feeds.php script. If automatic updates have been enabled, fetching the front page will automatically trigger the update process. * INTERFACE REORGANIZATION: All FeedWordPress functions are now located under a top-level "Syndication" menu in the WordPress Dashboard. To manage the list of syndicated sites, manually check for new posts on one or more feeds, or syndicate a new site, you should use the main page under Syndication. To change global settings for FeedWordPress, you should use Syndication --> Options. * FILE STRUCTURE REORGANIZATION: Due to a combination of changing styles for FeedWordPress plugins and lingering bugs in the FeedWordPress admin menu code, the code for FeedWordPress is now contained in two different PHP files, which should be installed together in a subdirectory of your plugins directory named feedwordpress. (See README.text for installation and upgrade instructions relating to the change.) * MULTIPLE CATEGORIES SETTING: Some feeds use non-standard methods to indicate multiple categories within a single category element. (The most popular site to do this is, which separates tags with a space.) FeedWordPress now allows you to set an optional setting, for any feed which does this, indicating the character or characters used to divide multiple categories, using a Perl-compatible regular expression. (In the case of feeds, FeedWordPress will automatically use \s for the pattern without your having to do any further configuration.) To turn this setting on, simply use the "Edit" link for the feed that you want to turn it on for. * REGULAR EXPRESSION BUG FIXED: Eliminated a minor bug in the regular expressions for e-mail addresses (used in parsing RSS author elements), which could produce unsightly error messages for some users parsing RSS 2.0 feeds. * DATE / UPDATE BUG FIXED: A bug in date handling was eliminated that may have caused problems if any of (1) WordPress, or (2) PHP, or (3) your web server, or (4) your MySQL server, has been set to use a different time zone from the one that any of the others is set to use. If FeedWordPress has not been properly updating updated posts, or has been updating posts when there shouldn't be any changes for the update, this release may solve that problem. * GOOGLE READER BUGS FIXED: A couple of bugs that made it difficult for FeedWordPress to interact with Google Reader public feeds have been fixed. Firstly, if you encountered an error message reading "There was a problem adding the newsfeed. [SQL: ]" when you tried to add the feed, the cause of this error has been fixed. Secondly, if you succeeded in getting FeedWordPress to check a Google Reader feed, only to find that the title of posts had junk squashed on to the end of them, that bug has been fixed too. To fix this bug, you must install the newest version of the optional MagpieRSS upgrade. * FILTER PARAMETERS: Due to an old, old bug in WordPress 1.5.0 (which was what was available back when I first wrote the filter interface), FeedWordPress has traditionally only passed one parameter to syndicated_item and syndicated_post filters functions -- an array containing either the Magpie representation of a syndicated item from the feed, or the database representation of a post about to be inserted into the WordPress database. If you needed information about the feed that the item came from, this was accessible only through a pair of global variables, $fwp_channel and $fwp_feedmeta. Since it's been a pretty long time since WordPress 1.5.0 was in widespread usage, I have gone ahead and added an optional second parameter to the invocation of the syndicated_item and syndicated_post filters. If you have written a filter for FeedWordPress that uses either of these hooks, you can now register that filter to accept 2 parameters. If you do so, the second parameter will be a SyndicatedPost object, which, among other things, allows you to access information about the feed from which an item is syndicated using the $post->feed and the $post->feedmeta elements (where $post is the name of the second parameter). NOTE THAT THE OLD GLOBAL VARIABLES ARE STILL AVAILABLE, for the time being at least, so existing filters will not break with the upgrade. They should be considered deprecated, however, and may be eliminated in the future. * FILTER CHANGE / BUGFIX: the array that is passed as the first argument syndicated_post filters no longer is no longer backslash-escaped for MySQL when filters are called. This was originally a bug, or an oversight; the contents of the array should only be escaped for the database after they have gone through all filters. IF YOU HAVE WRITTEN ANY syndicated_post FILTERS THAT PRESUME THE OLD BEHAVIOR OF PASSING IN STRINGS THAT ARE ALREADY BACKSLASH-ESCAPED, UPDATE YOUR FILTERS ACCORDINGLY. * OTHER MINOR BUGFIXES AND INTERNAL CHANGES: The internal architecture of FeedWordPress has been significantly changed to make the code more modular and clean; hopefully this should help reduce the number of compatibility updates that are needed, and make them easier and quicker when they are needed. 0.981 Version 0.981 is a narrowly targeted bugfix and compatibility release, whose main purpose is to resolve a major outstanding problem: the incompatibility between version 0.98 of WordPress and the recently released WordPress 2.1. 0.98 NOTE: I have not fully tested FeedWordPress with WordPress 2.0. Further testing may reveal more bugs. However, you should now be able to get at least basic FeedWordPress functionality up and running. * AUTHOR MATCHING: FeedWordPress tests several fields to see if it can identify the author of the post as a user already in the WordPress user database. In previous versions, it tested the user login, the nickname, and tested for "aliases" listed in the Profile (see documentation). FWP now also matches authors on the basis of e-mail address (if an e-mail address is present). This is particularly helpful for formats such as RSS 2.0, in which authors are primarily identified by e-mail addresses. 0.97 N.B.: full support of several Atom 1.0 features, such as categories and enclosures, requires you to install the optional rss-functions.php upgrade in your wp-includes directory. * BUG FIX: Running update-feeds.php from command line or crontab returned "I don't syndicate..." errors. It turns out that WordPress sometimes tramples on the internal PHP superglobals that I depended on to determine whether or not the script was being invoked from the command line. This has been fixed (the variables are now checked before WordPress can trample them). Note that update-feeds.php has been thoroughly overhauled anyway; see below for details. * BUG FIX: Duplicate categories or author names. Fixed two bugs that could create duplicate author and/or category names when the name contained either (a) certain international characters (causing a mismatch between MySQL and PHP's handling of lowercasing text), or (b) characters that have a special meaning in regular expressions (causing MySQL errors when looking for the author or category due to regexp syntax errors). These should now be fixed thanks to careful escaping of names that go into regular expressions and careful matching of lowercasing functions (comparing results from PHP only to other results from PHP, and results from MySQL only to other results from MySQL). * BUG FIX: Items dated December 31, 1969 should appear less often. The function for parsing W3C date-time format dates that ships with MagpieRSS can only correctly parse fully-specified dates with a fully-specified time, but valid W3C date-time format dates may omit the time, the day of the month, or even the month. Some feeds in the wild date their items with coarse-grained dates, so the optional rss-functions.php upgrade now includes a more flexible parse_w3cdtf() function that will work with both coarse-grained and fully-specified dates. (If parts of the date or the time are omitted, they are filled in with values based on the current time, so '2005-09-10' will be dated to the current time on that day; '2004' will be dated to this day and time one year ago. N.B.: This fix is only available in the optional rss-functions.php upgrade. * BUG FIX: Evil use of HTTP GET has been undone. The WordPress interface is riddled with inappropriate (non-idempotent) uses of HTTP GET queries (ordinary links that make the server do something with significant side-effects, such as deleting a post or a link from the database). FeedWordPress did some of this too, especially in places where it aped the WordPress interface (e.g. the "Delete" links in Links --> Syndicated). That's bad business, though. I've changed the interface so that all the examples of improper side-effects that I can find now require an HTTP POST to take effect. I think I got pretty much everything; if there's anything that I missed, let me know. Further reading: Sam Ruby 2005-05-06: This Stuff Matters * BUG FIX: Categories applied by cats setting should no longer prevent category-based filtering from working. In FeedWordPress, you can (1) apply certain categories to all syndicated posts, or all posts from a particular feed; and (2) filter out all posts that don't match one of the categories that are already in the WordPress database (allowing for simple category-based filtering; just load up WordPress with the categories you want to accept, and then tell FeedWordPress not to create new ones). However, the way that (1) and (2) were implemented meant that you couldn't effectively use them together; once you applied a known category to all syndicated posts from a particular feed, it meant that they'd have at least one familiar category (the category or categories you were applying), and that would get all posts past the filter no matter what categories they were originally from. Well, no longer. You can still apply categories to all syndicated posts (using either Syndication --> Options, or the feed-level settings under Links --> Syndicated). But these categories are not applied to the post until after it has already passed by the "familiar categories" filter. So now, if you want, you can do category filtering and then apply as many categories as you please to all and only posts that pass the filter. * BUG FIX: Other minor typos and HTML gaffes were fixed along the way. * PERFORMANCE: get_feed_meta() no longer hits the database for information on every call; it now caches link data in memory, so FeedWordPress only goes to the database once for each syndicated link. This may substantially improve performance if your database server resources are tight and your templates make a lot of use of custom settings from get_feed_meta(). * API CHANGE: Link ID numbers, rather than RSS URIs, are now used to identify the feed from which a post is syndicated when you use template functions such as get_feed_meta(). The practical upshot of this is you can switch feeds, or change the feed address for a particular syndicated site, without breaking your templates for all the posts that were syndicated from the earlier URI. * API CHANGE: if you have plugins or templates that make use of the get_feed_meta() function or the $fwp_feedmeta global, note that the data formerly located under the uri and name fields is now located under the link/uri field and the link/name field, respectively. Note also that you can access the link ID number for any given feed under the global $fwp_feedmeta['link/id'] (in plugins) or get_feed_meta('link/id') (in a template in post contexts). * FEATURE: the settings for individual feeds can now be edited using a humane interface (where formerly you had to tweak key-value pairs in the Link Notes section). To edit settings for a feed, pick the feed that you want under Links --> Syndicated and click the Edit link. * FEATURE: The "Unsubscribe" button (formerly "Delete") in Links --> Syndicated now offers three options for unsubscribing from a feed: (1) turning off the subscription without deleting the feed data or affecting posts that were syndicated from the feed (this works by setting the Link for the feed as "invisible"); (2) deleting the feed data and all of the posts that were syndicated from the feed; or (3) deleting the feed data and keeping the posts that were syndicated from the feed setting the Link to "Invisible" (meaning that it will not be displayed in lists of the site links on the front page, and it won't be checked for updates; (2) deleting the Link and all of the posts that were syndicated from its feed; or (3) deleting the feed data but keeping the posts that were syndicated (which will henceforward be treated as if they were local rather than syndicated posts). (Note that (1) is usually the best option for aggregator sites, unless you want to clean up the results of an error or a test.) * FEATURE / BUG FIX: If you have been receiving mysterious "I don't syndicate...", or "(local) HTTP status code was not 200", or "(local) transport error - could not open socket", or "parse error - not well formed" errors, then this update may solve your problems, and if it does not solve them, it will at least make the reasons for the problems easier to understand. That's because I've overhauled the way that FeedWordPress goes about updating feeds. If you use the command-line PHP scripting method to run scheduled updates, then not much should change for you, except for fewer mysterious errors. If you have done updates by sending periodic HTTP requests to, then the details have changed somewhat; mostly in such a way as to make things easier on you. See the README file or online documentation on Staying Current for the details. * FEATURE: FeedWordPress now features a more sophisticated system for timed updates. Instead of polling every subscribed feed for updates each time update-feeds.php is run, FeedWordPress now keeps track of the last time it polled each feed, and only polls them again after a certain period of time has passed. The amount of time is normally set randomly for each feed, in a period between 30 minutes and 2 hours (so as to stagger updates over time rather than polling all of the feeds at once. However, the length of time between updates can also be set directly by the feed, which brings us to ... * FEATURE: FeedWordPress now respects the settings in the ttl and Syndication Module RSS elements. Feeds with these elements set will not be polled any more frequently than they indicate with these feeds unless the user manually forces FeedWordPress to poll the feed (see Links --> Syndicated --> Edit settings). 0.96 Note that enclosure support requires using the optional MagpieRSS upgrade (i.e., replacing your wp-includes/rss-functions.php with OPTIONAL/wp-includes/rss-functions.php from the FWP archive) * FEATURE: for completeness's sake, there is now a feed setting, hardcode url, that allows you to set the URI for the front page of a contributor's website manually (that is, prevent it from being automatically updated from the feed channel link on each update). To set the URI manually, put a line like this in the Link Notes section of a feed: hardcode url: yes You can also instruct FeedWordPress to use hardcoded URIs by default on all feeds using Options --> Syndication * FEATURE: by default, when FeedWordPress finds new syndicated posts, it (1) publishes them immediately, (2) turns comments off, and (3) turns trackback / pingback pings off. You can now alter all three default behaviors (e.g., to allow pings on syndicated posts, or to send newly-syndicated posts to the draft pile for moderation) using Options --> Syndication From 0.91 to 0.95 a.k.a.: Joseph Cardinal Ratzinger You can add several aliases, each on a line by itself. You can also add any other text you like to the Profile without interfering with the aliases. * FEATURE: Users can now choose how to handle syndicated posts that are in unfamiliar categories or by unfamiliar authors (i.e., categories or authors whose names are not yet in the WordPress database). By default, FeedWordPress will (as before) create a new category (or new author) and use it for the current post and any future posts. This behavior can be changed, either for all feeds or for one or another particular feed. There are now three different options for an unfamiliar author: (1) FeedWordPress can create a new author account and attribute the syndicated post to the new account; (2) FeedWordPress can attribute the post to an author if the author's name is familiar, and to a default author (currently, this means the Site Administrator account) if it is not; (3) FeedWordPress can drop posts by unfamiliar authors and syndicate only posts by authors who are already in the database. There are, similarly, two different options for an unfamiliar category: (1) FeedWordPress can create new categories and place the syndicated post in them; (2) FeedWordPress can drop the unfamiliar categories and place syndicated posts only in categories that it is already familiar with. In addition, FeedWordPress 0.95 lets you choose whether posts that are in no familiar categories should be syndicated (and placed in the default category for the blog) or simply dropped. You can set the default behavior for both authors and categories using the settings in Options --> Syndication. You can also set different behavior for specific feeds by adding the unfamiliar author and / or unfamiliar categories settings to the Link Notes section of a feed: unfamiliar author: (create|default|filter) unfamiliar categories: (create|default|filter) A setting of unfamiliar author: create will make FeedWordPress create new authors to match unfamiliar author names for this feed alone. A setting of unfamiliar author: default will make it assign posts from unfamiliar authors to the default user account. A setting of unfamiliar author: filter will cause all posts (from this feed alone) to be dropped unless they are by an author already listed in the database. Similiarly, unfamiliar categories: create will make FeedWordPress create new categories to match unfamiliar category names for this feed alone; unfamiliar categories: default will cause it to drop any unfamiliar category names; and unfamiliar categories: filter will cause it to both drop any unfamiliar category names and to only syndicate posts that are placed in one or more familiar categories. These two new features allow users to do some coarse-grained filtering without having to write a PHP filter. Specifically, they offer an easy way for you to filter feeds by category or by author. Suppose, for example, that you only wanted to syndicate posts that your contributors place in the "Llamas" category. You could do so by setting up your installation of WordPress so that the only category in the database is "Llamas," and then use Options --> Syndication to set "Unfamiliar categories" to "don't create new categories and don't syndicate posts unless they match at least one familiar category". Now, when you update, only posts in the "Llamas" category will be syndicated by FeedWordPress. Similarly, if you wanted to filter one particular feed so that only posts by (for example) the author "Earl J. Llama" were syndicated to your site, you could do so by creating a user account for Earl J. Llama, then adding the following line to the settings for the feed in Link Notes: unfamiliar author: filter This will cause any posts from this feed that are not authored by Earl J. Llama to be discarded, and only the posts by Earl J. Llama will be syndicated. (If the setting is used on one specific feed, it will not affect how posts from other feeds are syndicated.)