| @@ -1,11 +1,11 @@ | ||
| 1 | 1 | === FeedWordPress === |
| 2 | 2 | Contributors: Charles Johnson |
| 3 | -Donate link: http://projects.radgeek.com/feedwordpress/ | |
| 3 | +Donate link: http://feedwordpress.radgeek.com/ | |
| 4 | 4 | Tags: syndication, aggregation, feed, atom, rss |
| 5 | -Requires at least: 1.5 | |
| 6 | -Tested up to: 2.5.1 | |
| 7 | -Stable tag: 0.993 | |
| 5 | +Requires at least: 3.0 | |
| 6 | +Tested up to: 3.5 | |
| 7 | +Stable tag: 2012.1212 | |
| 8 | 8 | |
| 9 | 9 | FeedWordPress syndicates content from feeds you choose into your WordPress weblog. |
| 10 | 10 | |
| 11 | 11 | == Description == |
| @@ -14,44 +14,43 @@ | ||
| 14 | 14 | * Project URI: <http://projects.radgeek.com/feedwordpress> |
| 15 | 15 | * License: GPL 2. See License below for copyright jots and tittles. |
| 16 | 16 | |
| 17 | 17 | FeedWordPress is an Atom/RSS aggregator for WordPress. It syndicates content |
| 18 | -from feeds that you choose into your WordPress weblog; if you syndicate several | |
| 19 | -feeds then you can use WordPress's posts database and templating engine as the | |
| 20 | -back-end of an aggregation ("planet") website. It was developed, originally, | |
| 21 | -because I needed a more flexible replacement for [Planet](http://www.planetplanet.org/) | |
| 22 | -to use at [Feminist Blogs](http://feministblogs.org/). | |
| 18 | +from feeds that you choose into your WordPress weblog; the content it syndicates | |
| 19 | +appears as a series of special posts in your WordPress posts database. If you | |
| 20 | +syndicate several feeds then you can use WordPress's posts database and | |
| 21 | +templating engine as the back-end of an aggregation ("planet") website. It was | |
| 22 | +developed, originally, because I needed a more flexible replacement for | |
| 23 | +[Planet][] to use at [Feminist Blogs][]. | |
| 23 | 24 | |
| 25 | +[Planet]: http://www.planetplanet.org/ | |
| 26 | +[Feminist Blogs]: http://feministblogs.org/ | |
| 27 | + | |
| 24 | 28 | FeedWordPress is designed with flexibility, ease of use, and ease of |
| 25 | 29 | configuration in mind. You'll need a working installation of WordPress or |
| 26 | -WordPress MU (versions [2.5][], [2.3][], [2.2][], [2.1][], [2.0][] or [1.5][]), | |
| 27 | -and also FTP or SFTP access to your web host. The ability to create cron jobs on | |
| 28 | -your web host is helpful but not absolutely necessary. You *don't* need to tweak | |
| 29 | -any plain-text configuration files and you *don't* need shell access to your web | |
| 30 | -host to make it work. (Although, I should point out, web hosts that *don't* | |
| 31 | -offer shell access are *bad web hosts*.) | |
| 30 | +WordPress MU (version [3.0] or later), and also FTP or SFTP access to your web | |
| 31 | +host. The ability to create cron jobs on your web host is helpful but not | |
| 32 | +required. You *don't* need to tweak any plain-text configuration files and you | |
| 33 | +*don't* need shell access to your web host to make it work. (Although, I should | |
| 34 | +point out, web hosts that *don't* offer shell access are *bad web hosts*.) | |
| 32 | 35 | |
| 33 | - [2.5]: http://codex.wordpress.org/Version_2.5 | |
| 34 | - [2.3]: http://codex.wordpress.org/Version_2.3 | |
| 35 | - [2.2]: http://codex.wordpress.org/Version_2.2 | |
| 36 | - [2.1]: http://codex.wordpress.org/Version_2.1 | |
| 37 | - [2.0]: http://codex.wordpress.org/Version_2.0 | |
| 38 | - [1.5]: http://codex.wordpress.org/Version_1.5 | |
| 36 | + [WordPress]: http://wordpress.org/ | |
| 37 | + [WordPress MU]: http://mu.wordpress.org/ | |
| 38 | + [3.0]: http://codex.wordpress.org/Version_3.0 | |
| 39 | 39 | |
| 40 | 40 | == Installation == |
| 41 | 41 | |
| 42 | -To use version 0.993 of FeedWordPress, you will need: | |
| 42 | +To use FeedWordPress, you will need: | |
| 43 | 43 | |
| 44 | -* an installed and configured copy of WordPress version 2.3.x, 2.2.x, | |
| 45 | - 2.1.x, 2.0.x, or 1.5.x. (FeedWordPress will also work with the | |
| 46 | - equivalent versions of WordPress MU.) | |
| 44 | +* an installed and configured copy of [WordPress][] or [WordPress MU][] | |
| 45 | + (version 3.0 or later). | |
| 47 | 46 | |
| 48 | -* FTP or SFTP access to your web host | |
| 47 | +* FTP, SFTP or shell access to your web host | |
| 49 | 48 | |
| 50 | 49 | = New Installations = |
| 51 | 50 | |
| 52 | -1. Download the FeedWordPress archive in zip or gzipped tar format and | |
| 53 | - extract the files on your computer. | |
| 51 | +1. Download the FeedWordPress installation package and extract the files on | |
| 52 | + your computer. | |
| 54 | 53 | |
| 55 | 54 | 2. Create a new directory named `feedwordpress` in the `wp-content/plugins` |
| 56 | 55 | directory of your WordPress installation. Use an FTP or SFTP client to |
| 57 | 56 | upload the contents of your FeedWordPress archive to the new directory |
| @@ -56,69 +55,35 @@ | ||
| 56 | 55 | directory of your WordPress installation. Use an FTP or SFTP client to |
| 57 | 56 | upload the contents of your FeedWordPress archive to the new directory |
| 58 | 57 | that you just created on your web host. |
| 59 | 58 | |
| 60 | -3. Upgrade the copy of MagpieRSS packaged with WordPress by installing the | |
| 61 | - new copies of `rss.php` and `rss-functions.php` into the `wp-includes` | |
| 62 | - directory of your FeedWordPress installation. These files are stored in | |
| 63 | - the `MagpieRSS-upgrade` directory of your FeedWordPress archive. Strictly | |
| 64 | - speaking, upgrading MagpieRSS is optional; FeedWordPress will run | |
| 65 | - correctly without the upgrade. But if you hope to take advantage of | |
| 66 | - numerous bug fixes, or support for Atom 1.0, multiple post categories, | |
| 67 | - RSS enclosures, or multiple character encodings, then you need to | |
| 68 | - install the upgrade. | |
| 59 | +3. Log in to the WordPress Dashboard and activate the FeedWordPress plugin. | |
| 69 | 60 | |
| 70 | -4. Log in to the WordPress Dashboard and activate the FeedWordPress plugin. | |
| 61 | +4. Once the plugin is activated, a new **Syndication** section should | |
| 62 | + appear in your WordPress admin menu. Click here to add new syndicated | |
| 63 | + feeds, set up configuration options, and determine how FeedWordPress | |
| 64 | + will check for updates. For help, see the [FeedWordPress Quick Start][] | |
| 65 | + page. | |
| 66 | + | |
| 67 | +[FeedWordPress Quick Start]: http://feedwordpress.radgeek.com/wiki/quick-start | |
| 71 | 68 | |
| 72 | -5. Once the plugin is activated, you can go to **Syndication --> Options** | |
| 73 | - and set (1) the link category that FeedWordPress will syndicate links | |
| 74 | - from (by default, "Contributors"), and (2) whether FeedWordPress will | |
| 75 | - use automatic updates or only manual updates. | |
| 76 | - | |
| 77 | -5. Go to the main **Syndication** page to set up the list of sites that | |
| 78 | - you want FeedWordPress to syndicate onto your blog. | |
| 79 | - | |
| 80 | 69 | = Upgrades = |
| 81 | 70 | |
| 82 | -To *upgrade* an existing installation of FeedWordPress to version 0.993: | |
| 71 | +To *upgrade* an existing installation of FeedWordPress to the most recent | |
| 72 | +release: | |
| 83 | 73 | |
| 84 | -1. Download the FeedWordPress archive in zip or gzipped tar format and | |
| 85 | - extract the files on your computer. | |
| 74 | +1. Download the FeedWordPress installation package and extract the files on | |
| 75 | + your computer. | |
| 86 | 76 | |
| 87 | -2. If you are upgrading from version 0.98 or earlier, then you need to | |
| 88 | - create a new directory named `feedwordpress` in the `wp-content/plugins` | |
| 89 | - directory of your WordPress installation, and you also need to *delete* | |
| 90 | - your existing `wp-content/update-feeds.php` and | |
| 91 | - `wp-content/plugins/feedwordpress.php` files. The file structure for | |
| 92 | - FeedWordPress has changed and the files from your old version will not | |
| 93 | - be overwritten, which could cause conflicts if you leave them in place. | |
| 77 | +2. Upload the new PHP files to `wp-content/plugins/feedwordpress`, | |
| 78 | + overwriting any existing FeedWordPress files that are there. | |
| 79 | + | |
| 80 | +3. Log in to your WordPress administrative interface immediately in order | |
| 81 | + to see whether there are any further tasks that you need to perform | |
| 82 | + to complete the upgrade. | |
| 94 | 83 | |
| 95 | -3. Upload the new PHP files to `wp-content/plugins/feedwordpress`, | |
| 96 | - overwriting any existing FeedWordPress files that are there. Also be | |
| 97 | - sure to upgrade the MagpieRSS module by uploading `rss.php` and | |
| 98 | - `rss-functions.php` from the `MagpieRSS-upgrade` directory in your | |
| 99 | - archive to the `wp-includes` directory of your WordPress installation. | |
| 84 | +4. Enjoy your newer and hotter installation of FeedWordPress | |
| 100 | 85 | |
| 101 | -3. If you are upgrading from version 0.96 or earlier, **immediately** log | |
| 102 | - in to the WordPress Dashboard, and go to **Options --> Syndicated**. | |
| 103 | - Follow the directions to launch the database upgrade procedure. The new | |
| 104 | - versions of FeedWordPress incorporate some long-needed improvements, but | |
| 105 | - old meta-data needs to be updated to prevent duplicate posts and other | |
| 106 | - possible maladies. If you're upgrading an existing installation, updates | |
| 107 | - and FeedWordPress template functions *will not work* until you've done | |
| 108 | - the upgrade. Then take a coffee break while the upgrade runs. It should, | |
| 109 | - hopefully, finish within a few minutes even on relatively large | |
| 110 | - databases. | |
| 111 | - | |
| 112 | -4. If you are upgrading from version 0.98 or earlier, note that the old | |
| 113 | - `update-feeds.php` has been eliminated in favor of a (hopefully) more | |
| 114 | - humane method for automatic updating. If you used a cron job for | |
| 115 | - scheduled updates, it will not work anymore, but there is another, | |
| 116 | - simpler method which will. See [Setting Up Feed Updates](http://projects.radgeek.com/feedwordpress/install/#setting-up-feed-updates) | |
| 117 | - to get scheduled updates back on track. | |
| 118 | - | |
| 119 | -5. Enjoy your new installation of FeedWordPress. | |
| 120 | - | |
| 121 | 86 | == Using and Customizing FeedWordPress == |
| 122 | 87 | |
| 123 | 88 | FeedWordPress has many options which can be accessed through the WordPress |
| 124 | 89 | Dashboard, and a lot of functionality accessible programmatically through |
| @@ -124,19 +89,1810 @@ | ||
| 124 | 89 | Dashboard, and a lot of functionality accessible programmatically through |
| 125 | 90 | WordPress templates or plugins. For further documentation of the ins and |
| 126 | 91 | outs, see the documentation at the [FeedWordPress project homepage][]. |
| 127 | 92 | |
| 128 | - [FeedWordPress project homepage]: http://projects.radgeek.com/feedwordpress/ | |
| 93 | + [FeedWordPress project homepage]: http://feedwordpress.radgeek.com/ | |
| 129 | 94 | |
| 95 | +== Changelog == | |
| 96 | + | |
| 97 | += 2012.1212 = | |
| 98 | + | |
| 99 | +* WORDPRESS 3.5 COMPATIBILITY: This release has been tested for compatibility | |
| 100 | + with new releases of WordPress, up to version 3.5, and any documented | |
| 101 | + compatibility issues have been cleared -- in particular, if you were seeing | |
| 102 | + error pages stating that you don't have permission to access the | |
| 103 | + FeedWordPress Syndication page within the WordPress admin interface, then | |
| 104 | + upgrading to this release should fix the problem. | |
| 105 | + | |
| 106 | + As always, if you encounter any compatibility problems after upgrading your | |
| 107 | + version of WordPress and your version of FeedWordPress to the most recent | |
| 108 | + versions, please contact me with as detailed a description as possible of | |
| 109 | + the issue you are encountering, the circumstances you're encountering it | |
| 110 | + under, what you expect to see happening, and what is happening instead. | |
| 111 | + | |
| 112 | +* PHP 5.4 COMPATIBILITY: This release has been audited to fix potential | |
| 113 | + problems with deprecation notices or fatal errors under recent versions | |
| 114 | + of PHP. In particular, all uses of run-time pass-by-reference have been | |
| 115 | + eliminated from the code; if you were seeing a fatal error reading | |
| 116 | + "Call-time pass-by-reference has been removed ..." then upgrading to | |
| 117 | + this release should fix the problem. | |
| 118 | + | |
| 119 | +* CUSTOMIZATION FRAMEWORK: A great deal of work has been done to make the | |
| 120 | + underlying framework more flexible, so that PHP add-ons can be written | |
| 121 | + to adapt FeedWordPress to handle custom XML vocabularies, expiration of | |
| 122 | + posts under specified conditions, and other custom behavior. | |
| 123 | + | |
| 124 | +* BUGFIX: MANUALLY EDITED POST SLUGS NOT OVERWRITTEN. Thanks to a report | |
| 125 | + by Chris Fritz, I've identified some code that causes post slugs for the | |
| 126 | + posts generated by FWP to be rewritten with every update, even if the | |
| 127 | + user has manually updated the slug from within the WordPress editing | |
| 128 | + interface. This has been fixed: FWP will continue to generate new slugs | |
| 129 | + for syndicated posts, but when syndicated posts are updated, they will | |
| 130 | + retain the slug that they had at the time of the update; any manual | |
| 131 | + changes to the post slug should be preserved. | |
| 132 | + | |
| 133 | +* USER-AGENT STRING: FeedWordPress now sends a distinctive User-Agent | |
| 134 | + string identifying itself, and noting that it is a feed aggregator. | |
| 135 | + | |
| 136 | +* MISCELLANEOUS PERFORMANCE IMPROVEMENTS: A number of changes have been | |
| 137 | + made to try to reduce the intensity and expense in terms of both | |
| 138 | + database performance and web server memory consumption. | |
| 139 | + | |
| 140 | +* DIAGNOSTICS IMPROVEMENTS: A number of new and improved diagnostics have | |
| 141 | + been added which should aid in understanding and troubleshooting issues | |
| 142 | + that may arise. | |
| 143 | + | |
| 144 | += 2011.1019 = | |
| 145 | + | |
| 146 | +* BUGFIX: "THERE ARE NO HTTP TRANSPORTS AVAILABLE" ERROR FIXED: The initial | |
| 147 | + support for HTTP Basic and Digest authentication in version 2011.1018 | |
| 148 | + contained a bug that could cause HTTP requests for feeds or for other | |
| 149 | + WordPress resources to break down if you do not have the PHP curl module | |
| 150 | + installed. This bug has been fixed, and these errors should no longer | |
| 151 | + appear. | |
| 152 | + | |
| 153 | +* IMPROVED HTTP AUTHENTICATION SUPPORT: In addition, the HTTP Authentication | |
| 154 | + support in FeedWordPress has been extended, to ensure that Basic | |
| 155 | + authentication is available in many web host configurations, and to allow | |
| 156 | + you to add a username and password for a feed immediately when you | |
| 157 | + subscribe to it. | |
| 158 | + | |
| 159 | += 2011.1018 = | |
| 160 | + | |
| 161 | +* HTTP BASIC AND DIGEST AUTHENTICATION SUPPORT: FeedWordPress now offers | |
| 162 | + improved support for syndicating feeds that make use of HTTP Basic or HTTP | |
| 163 | + Digest authentication methods. In order to set up authentication on one of | |
| 164 | + your feeds, just go to its Settings > Feed page, and click on the "Uses | |
| 165 | + Username/Password" link underneath the Feed URL. Enter the username and | |
| 166 | + password for accessing the feed, then select the authentication method. (If | |
| 167 | + you're not sure which method your feed provider uses, try Basic first.) | |
| 168 | + Save Changes, and syndicate away. | |
| 169 | + | |
| 170 | + NOTE: HTTP Digest support requires the curl module for PHP. If you are not | |
| 171 | + sure whether this module has been installed, contact your web hosting | |
| 172 | + provider to check. | |
| 173 | + | |
| 174 | +* WP 3.3 (BETA) COMPATIBILITY: This version fixes an init-sequence bug that | |
| 175 | + could cause intrusive warning messages or fatal errors in WP 3.3 beta | |
| 176 | + versions. | |
| 177 | + | |
| 178 | +* BUGFIX: FIXES LONG DELAYS IN UPDATES SCHEDULES IN LARGE INSTALLATIONS. A | |
| 179 | + performance feature introduced in version 2011.0721 had some flaws in its | |
| 180 | + implementation, which tended to create serious delays (on the order of | |
| 181 | + several hours) in FeedWordPress's attempts to schedule updates for feeds, | |
| 182 | + when users had a very large number of feeds (several dozen or more) in their | |
| 183 | + FeedWordPress installation. This feature has been reconfigured to adjust | |
| 184 | + dynamically to the number of feeds in Syndicated Sources and the frequency | |
| 185 | + with which they are updated. If you've seen a lot of ready-to-update feeds | |
| 186 | + piling up, several hours after they were supposed to get updated, then this | |
| 187 | + upgrade should better ensure that your feeds get updated in a timely fashion. | |
| 188 | + | |
| 189 | +* BUGFIX: syndicated_item_guid FILTERS FIXED. Previous versions of | |
| 190 | + FeedWordPress theoretically allowed for filters on the syndicated_item_guid | |
| 191 | + hook, which was intended to filter the globally-unique identifier element | |
| 192 | + (rss:guid or atom:id) -- useful if you need to convince FeedWordPress to use | |
| 193 | + different guids, or to recognize two or more incoming posts as versions of | |
| 194 | + the same post rather than as distinct items. However, while the hook | |
| 195 | + affected the guid stored in the WordPress database, it did not affect the | |
| 196 | + guid used to check whether an incoming feed item had already been syndicated | |
| 197 | + or was a new item -- which greatly limited the practical usefulness of the | |
| 198 | + filter. This bug has been fixed: syndicated_item_guid filters should now | |
| 199 | + properly control not only the final database record, but also the initial | |
| 200 | + uniqueness test applied to posts. | |
| 201 | + | |
| 202 | += 2011.0721 = | |
| 203 | + | |
| 204 | +* BUGFIX: SERIOUS BUG CAUSING RARE UNEXPECTED DELETION OF PAGES AND OTHER | |
| 205 | + CONTENT. A bug in the guid-checking code for some rare kinds of guids could | |
| 206 | + cause content in the wp_posts table to seemingly disappear at random after | |
| 207 | + FeedWordPress updates.This most frequently but not exclusively affected | |
| 208 | + static pages. What actually happened is that in these rare cases the | |
| 209 | + existing static page was mistaken for an older version of the new incoming | |
| 210 | + syndicated post, which was then stored as a new revision of the original | |
| 211 | + page. The bug that caused these mistaken identities has been fixed. | |
| 212 | + | |
| 213 | +* BUGFIX: UNWANTED AUTOMATIC PAGE-LOAD-BASED UPDATES NO LONGER A NUISANCE. | |
| 214 | + Some users encountered a bug in which FeedWordPress would adopt an automatic | |
| 215 | + page-load-based update method, even if they had requested that it not do | |
| 216 | + so, and that it use a manual or cron job update method instead. The bug | |
| 217 | + causing this has been fixed, and page-load-based updates should no longer | |
| 218 | + trigger unless explicitly turned on. | |
| 219 | + | |
| 220 | +* WP 3.2 USER INTERFACE COMPATIBILITY: POST TAGS BOX NOW WORKS AGAIN. The | |
| 221 | + release of WordPress 3.2 caused a breakage in the tags box which prevented | |
| 222 | + you from adding or removing tags under Syndication --> Categories & Tags. | |
| 223 | + (The breakage was the result of an incompatibility introduced by the new | |
| 224 | + release of jQuery.) This breakage has now been fixed, and the tags box | |
| 225 | + should work correctly again. | |
| 226 | + | |
| 227 | +* FEED UPDATE SCHEDULING IMPROVEMENTS: UI. The Syndicated Sources table now | |
| 228 | + provides considerably more data to understand update scheduling, when | |
| 229 | + specific scheduling decisions are made because of, e.g., requests from the | |
| 230 | + feed producer. | |
| 231 | + | |
| 232 | +* FEED UPDATE SCHEDULING IMPROVEMENTS: ENFORCEABLE "MINIMUM INTERVAL" SETTING | |
| 233 | + TO SPACE OUT UPDATES. Some feeds request specific update schedules, using | |
| 234 | + standard elements such as sy:updateFrequency and rss:ttl. Normally, | |
| 235 | + FeedWordPress respects any scheduling requests that a feed makes -- if it | |
| 236 | + requests a longer gap between polls than what FWP would normally adopt, then | |
| 237 | + FWP slows down to meet the request. If it indicates a shorter gap than what | |
| 238 | + FWP would normally adopt, FWP speeds up and checks that feed for updates | |
| 239 | + more often than it normally would. Now, there should not be any way for user | |
| 240 | + settings to override an explicit slow-down request from the feed producer -- | |
| 241 | + if producers indicate a particular update schedule, then polling the feed | |
| 242 | + more frequently than they request is considered abusive behavior. But | |
| 243 | + there's no reason why users should not be able -- if they so desire -- to | |
| 244 | + override speed-up requests, and poll a feed *less* frequently than the | |
| 245 | + indicated update schedule, if the FWP user wants to space update checkins | |
| 246 | + over a longer interval of time. Before, they could not do this: FWP always | |
| 247 | + sped up to meet the indicated update schedule. Now, they can do this, by | |
| 248 | + using the new "Minimum Interval" setting in Syndication --> Feeds & | |
| 249 | + Updates.. | |
| 250 | + | |
| 251 | += 2011.0706 = | |
| 252 | + | |
| 253 | +* WP 3.2 COMPATIBILITY: ELIMINATES FATAL ERROR "Call to undefined method | |
| 254 | + WP_SimplePie_File::WP_SimplePie_File() in | |
| 255 | + [...]/wp-content/plugins/feedwordpress/feedwordpress.php on line 1841." The | |
| 256 | + latest release of WordPress, version 3.2, has shifted the minimum | |
| 257 | + requirements up to PHP 5.2, and in line with the shift to PHP5 they have | |
| 258 | + rewritten a number of code segments that made use of now-obsolete PHP4 | |
| 259 | + idioms. Unfortunately, this caused a fatal error whenever FeedWordPress | |
| 260 | + attempted to make use of the cache, since FWP's caching plugin was written | |
| 261 | + to match the older idiom. FeedWordPress has been updated to follow the new, | |
| 262 | + PHP5 idiom when possible, thus eliminating the fatal error. | |
| 263 | + | |
| 264 | +* PERFORMANCE: The handling of queries to determine whether posts had been | |
| 265 | + previously syndicated produced some very slow queries (usually, but not | |
| 266 | + always, involving a scan over the MD5(post_guid) column of the table). The | |
| 267 | + code that prepares MySQL queries for previously-syndicated checks has been | |
| 268 | + revised to eliminate the MD5(post_guid) scan entirely, and to significantly | |
| 269 | + improve performance by eliminating other unnecessary clauses. | |
| 270 | + | |
| 271 | +* BUGFIX: NO LONGER DESTROYS STICKY POSTS. Previous versions could destroy | |
| 272 | + (or, more precisely, replace the content of) sticky posts due to some | |
| 273 | + queries mashed together in unexpected ways by WordPress. Version 2011.0706 | |
| 274 | + accounts for and eliminates the problem; your sticky posts should be safe | |
| 275 | + once again. | |
| 276 | + | |
| 277 | +* BUGFIX: GUIDS CONTAINING MYSQL-ESCAPED CHARACTERS NO LONGER CAUSE DUPLICATE | |
| 278 | + POSTS TO APPEAR. One remaining source of duplicate post issues in 2011.0602 | |
| 279 | + was guids that contained characters that needed to be escaped for MySQL, | |
| 280 | + such as single quotes and double quotes. The work-around for handling | |
| 281 | + filtered URIs has now been corrected to ensure that these do not cause | |
| 282 | + duplicate posts. | |
| 283 | + | |
| 284 | += 2011.0602 = | |
| 285 | + | |
| 286 | +* WP 3.1.3 COMPAT / BUGFIX: WHITESPACE IN GUIDS NO LONGER PRODUCES DUPLICATE | |
| 287 | + POSTS. The work-around for handling filtered URIs in guid elements has now | |
| 288 | + been extended to handle URIs that were filtered because of leading or | |
| 289 | + trailing whitespace, in addition to URIs that were filtered because of | |
| 290 | + unapproved schemes. | |
| 291 | + | |
| 292 | +* WP 3.1.3 COMPAT / BUGFIX: RELATIVE URLS IN GUIDS NO LONGER PRODUCE DUPLICATE | |
| 293 | + POSTS. The work-around for handling filtered URIs in guid elements has now | |
| 294 | + been extended to handle URIs that were altered without being filtered out | |
| 295 | + entirely (most commonly because a scheme was added to a relative URL). | |
| 296 | + | |
| 297 | +* BUGFIX: UPDATES TO POST NO LONGER CAUSE DUPLICATE DRAFT VERSION TO APPEAR. | |
| 298 | + Under certain conditions in 2011.0531, an update to an existing post would | |
| 299 | + not be properly applied to the post itself, but rather would appear as a | |
| 300 | + duplicate post with Draft status. This bug has been eliminated, and updates | |
| 301 | + will now be properly inserted as revisions to the existing post. | |
| 302 | + | |
| 303 | += 2011.0531 = | |
| 304 | + | |
| 305 | +* WORDPRESS 3.1.3 COMPATIBILITY: DUPLICATE POSTS ISSUE FIXED. Due to | |
| 306 | + internal changes in the way that WordPress handles post guids in the | |
| 307 | + most recent release (3.1.3), many users experienced problems with many | |
| 308 | + duplicate posts appearing in rapid succession. (Specifically, this would | |
| 309 | + happen with any posts using tag: URL guids -- such as all the posts | |
| 310 | + coming from Blogger feeds or feeds from other Google services.) This | |
| 311 | + compatibility release of FeedWordPress eliminates the issue by working | |
| 312 | + around the new restrictions on tag: URLs. | |
| 313 | + | |
| 314 | +* NEW AND IMPROVED DIAGNOSTICS: Syndication --> Diagnostics now contains some | |
| 315 | + new diagnostics settings useful for debugging problems with duplicate posts | |
| 316 | + (allowing you to easily view the guid of posts in the WordPress posts | |
| 317 | + database and allowing you to track the SQL used to check for existing | |
| 318 | + versions of a syndicated post). | |
| 319 | + | |
| 320 | += 2011.0512 = | |
| 321 | + | |
| 322 | +* DIAGNOSTICS IMPROVEMENTS; "THERE MAY BE A BUG IN FEEDWORDPRESS" CRITICAL | |
| 323 | + ERROR NOTICES ELIMINATED: This version includes some major improvements | |
| 324 | + to the Syndication --> Diagnostics section, which should aid in | |
| 325 | + troubleshooting difficulties with items failing to be imported, posts | |
| 326 | + failing to be properly inserted into the database, or updates failing to | |
| 327 | + be recorded. If you have been encountering critical error / bug notices | |
| 328 | + with a white screen and the message "THERE MAY BE A BUG IN | |
| 329 | + FEEDWORDPRESS," followed by an extraordinarily long dump of mostly | |
| 330 | + incomprehensible diagnostic information, you'll be happy to know that | |
| 331 | + the condition causing these notices has been eliminated. In the few | |
| 332 | + cases where errors may still crop up with database insertions, | |
| 333 | + FeedWordPress will now produce a significantly more manageable and more | |
| 334 | + useful diagnostic message. | |
| 335 | + | |
| 336 | +* BUGFIX: NEW POSTS FAILING TO APPEAR IN A CLEANLY-INSTALLED FEEDWORDPRESS | |
| 337 | + SYSTEM. If you encountered a recurring problem with FeedWordPress | |
| 338 | + failing to import new posts, after a clean install of FeedWordPress | |
| 339 | + (i.e., not an upgrade from a previous version), this problem may have | |
| 340 | + been the result of a bug with author-handling which has now been fixed | |
| 341 | + in the 2011.0512 release. (If the problem does *not* go away with the | |
| 342 | + upgrade, this version also includes significant improvements to the | |
| 343 | + Diagnostics system, which will help track down what *is* causing it | |
| 344 | + in your particular case.) | |
| 345 | + | |
| 346 | +* PERFORMANCE: New handling of update hashes allows FeedWordPress to avoid | |
| 347 | + a certain kind of infinite loop, caused when two more more different | |
| 348 | + syndicated feeds each carried a version of the same item (for example, | |
| 349 | + because it appeared on two different aggregator feeds that you're | |
| 350 | + syndicating). In previous versions, when this kind of loop cropped up, | |
| 351 | + syndicated posts could pile up an indefinitely large number of revisions | |
| 352 | + -- each revision alternating between the version from each of the two | |
| 353 | + feeds where it appeared -- which would, over time, dramatically inflate | |
| 354 | + the size of the database, and kill the performance of queries on the | |
| 355 | + post table. This issue has been resolved: revisions of the post that | |
| 356 | + have been syndicated once will not be re-syndicated over and over again. | |
| 357 | + | |
| 358 | +* AUTHOR LISTS: Lists of authors presented on the Author settings pages | |
| 359 | + should now be easier to scan through, with author names arranged in | |
| 360 | + alphabetical order. | |
| 361 | + | |
| 362 | +* FEED ITEM DATE PARSING: More tweaks to make date-time handling more | |
| 363 | + resilient when feeds provide broken or weird values for the timestamps | |
| 364 | + on syndicated items. FWP will now attempt to work around unparseable | |
| 365 | + timezone values. | |
| 366 | + | |
| 367 | +* AUTHOR MATCHING: Now attempts to match author names against the WP login | |
| 368 | + name in addition to display_name; when creating user record, also fills | |
| 369 | + in some best-guess values for nickname, firstname and lastname. Also | |
| 370 | + properly picks up Atom 1.0 author/uri data from feed. | |
| 371 | + | |
| 372 | +* COMPATIBILITY: FeedWordPress has been successfully tested for | |
| 373 | + compatibility with recent releases of WordPress, up to version 3.1.2. | |
| 374 | + | |
| 375 | += 2011.0211 = | |
| 376 | + | |
| 377 | +* BUGFIX: DUPLICATE POSTS WHEN GUIDS ARE TOO LONG: When feeds included | |
| 378 | + exceptionally long GUIDs, FeedWordPress could occasionally get into | |
| 379 | + a situation where posts with the long GUIDs would be duplicated over | |
| 380 | + and over again with each update (because FWP failed to store the full | |
| 381 | + GUID, due to length constraints in the relevant database tables). | |
| 382 | + Without the full GUID, FWP would not know that the post had already | |
| 383 | + been syndicated once. This bug has been fixed, and should no longer | |
| 384 | + produce duplicate posts. | |
| 385 | + | |
| 386 | +* HTTP TIMEOUT SETTING: If you are frequently running into timeout | |
| 387 | + problems with one or more of the feeds you syndicate, FWP now allows you | |
| 388 | + to adjust the timeout for HTTP requests using a global or feed-by-feed | |
| 389 | + setting. | |
| 390 | + | |
| 391 | +* HTTP GET PARAMETERS: You can now temporarily or permanently add HTTP | |
| 392 | + GET parameters to a subscription using an interface in Syndication --> | |
| 393 | + Feeds & Updates. This is especially helpful for making quick, short-term | |
| 394 | + changes to a subscription (for example, to pull in all the previous | |
| 395 | + items from a web service, before settling down to pulling in only newly | |
| 396 | + updated items). | |
| 397 | + | |
| 398 | +* DIAGNOSTICS SYSTEM: Added several new diagnostics which are useful in | |
| 399 | + troubleshooting, and established a framework for add-on modules to hook | |
| 400 | + in with their own diagnostic messages. | |
| 401 | + | |
| 402 | +* UI: Adjusted some internal coding, which should allow for settings | |
| 403 | + pages and add-ons to properly display multiple category pickers on a | |
| 404 | + single settings page. | |
| 405 | + | |
| 406 | +* PHP4 COMPATIBILITY TWEAKS: This version makes some tweaks to the handling | |
| 407 | + of object references which should improve compatibility with older | |
| 408 | + versions of PHP. (Although, I should note, web hosts that still force | |
| 409 | + you to run under PHP 4 -- in 2011! -- are *bad web hosts*.) | |
| 410 | + | |
| 411 | +* IMPROVED PERFORMANCE: This version eliminates a *major* performance drag | |
| 412 | + that shows up on sites with large numbers of users (due to some poor | |
| 413 | + decisions about where to place a user query, which caused the user table | |
| 414 | + to be scanned frequently when it did not need to be). If you experienced | |
| 415 | + serious problems with CPU load or slow database performance under | |
| 416 | + 2010.0905, which kicked in immediately when FWP was loaded and tended | |
| 417 | + to disappear immediately if FWP was de-activated, it is likely that | |
| 418 | + upgrading away from 2010.0905 to the most recent version will resolve | |
| 419 | + your problem. | |
| 420 | + | |
| 421 | + | |
| 422 | += 2010.0905 = | |
| 423 | + | |
| 424 | +* BUGFIX: CATEGORIES AND TAGS CORRECTLY ASSIGNED IN AUTOMATIC UPDATES. | |
| 425 | + Version 2010.0903 switched over to a new way of assigning categories and | |
| 426 | + tags as part of its support for handling custom taxonomies. | |
| 427 | + Unfortunately, the method that it uses is subjected to some checks of | |
| 428 | + the current user's capabilities, which creates problems for posts that | |
| 429 | + are being inserted into the WordPress database when there *is* no | |
| 430 | + current user logged in (as, for example, when an update is being carried | |
| 431 | + out from a cron job or automatic update). The result was that posts | |
| 432 | + from cron jobs and automatic updates ended up with no Categories and no | |
| 433 | + Tags being assigned. This bug has now been fixed: in 2010.0905, Tags and | |
| 434 | + Categories should be correctly assigned to all posts, regardless of | |
| 435 | + whether they were added from manual updates, cron jobs, or automatic | |
| 436 | + updates. | |
| 437 | + | |
| 438 | += 2010.0903 = | |
| 439 | + | |
| 440 | +* WORDPRESS 3 REQUIRED: Please note that this release of FeedWordPress | |
| 441 | + *requires* WordPress 3.0 or later. If you are currently using a 2.x | |
| 442 | + branch of WordPress, you will need to upgrade to WordPress 3 before you | |
| 443 | + can successfully upgrade FeedWordPress. | |
| 444 | + | |
| 445 | +* BUGFIX: NO MORE DISAPPEARING "SYNDICATED SOURCES" PANEL; INTERNET | |
| 446 | + EXPLORER UI GLITCH APPARENTLY FIXED: Several users independently | |
| 447 | + reported a problem with FWP 2010.0623 and various versions of IE. A | |
| 448 | + problem with the HTML markup caused IE (but not Firefox or | |
| 449 | + Chrome) to completely hide the Syndicated Sources administration panel | |
| 450 | + (the main list of currently-syndicated sources, and the main location | |
| 451 | + for adding new sources, under the Syndication menu item) when a user | |
| 452 | + added their first syndicated feed. Maddeningly, the glitch seemed to | |
| 453 | + affect some IE users and not others: I was never able to reproduce the | |
| 454 | + problem for myself on my own machines. However, the markup of Syndicated | |
| 455 | + Sources has undergone significant changes and corrections since | |
| 456 | + 2010.0623, and two independent sources who had been having this problem | |
| 457 | + confirm that they no longer encounter it with the updated version. For | |
| 458 | + the time being, I am going to declare this bug squashed. | |
| 459 | + | |
| 460 | +* BUGFIX: MORE PROTECTION AGAINST FATAL ERRORS FROM PLUGGABLE VERSIONS OF | |
| 461 | + SimplePie: FeedWordPress now takes some precautions that should help to | |
| 462 | + better avoid conflicts for users who have installed pluggable versions | |
| 463 | + of SimplePie for another plugin or theme. (You may not know that you have | |
| 464 | + done this; but if you've been encountering fatal errors indicating that | |
| 465 | + you cannot redeclare class SimplePie, or something along those lines, | |
| 466 | + there is now a better chance that those fatal errors will be eliminated. | |
| 467 | + | |
| 468 | +* PERFORMANCE: SIGNIFICANTLY REDUCED MEMORY CONSUMPTION FOR LARGE UPDATES: | |
| 469 | + FeedWordPress is still a memory-hungry little module, especially when | |
| 470 | + you are dealing with very large feeds. However, users should notice a | |
| 471 | + significant reduction in memory overloads, especially if they update a | |
| 472 | + large number of feeds at once. | |
| 473 | + | |
| 474 | +* USER INTERFACE IMPROVEMENTS: Nothing is radically different, but there's | |
| 475 | + been a fair amount of extra spit and polish added, including a convenient | |
| 476 | + new Dashboard widget that may save you a trip to the Syndication menu, | |
| 477 | + a lot of effort to make the relationship between global and feed-by-feed | |
| 478 | + settings more obvious to the user and more easily controllable, to make | |
| 479 | + navigation between settings pages easier, to sand off a few rough edges, | |
| 480 | + and to make other improvements on the margins. I hope you'll like how | |
| 481 | + it looks. | |
| 482 | + | |
| 483 | +* ADDING MULTIPLE FEEDS: FeedWordPress now provides a convenient mode for | |
| 484 | + adding multiple feeds at once, using either a copy-and-pasted list, or | |
| 485 | + else an OPML file. Go to Syndication --> Syndicated Sources and check | |
| 486 | + out the two new buttons underneath the New Source input box. When you | |
| 487 | + have to add a number of feeds at once, this can save you considerable | |
| 488 | + time and trouble. | |
| 489 | + | |
| 490 | +* IMPROVED HANDLING OF AUTHORS WITH DUPLICATE E-MAIL ADDRESS AND AUTHORS | |
| 491 | + WITH NAMES WRITTEN IN FOREIGN SCRIPTS: WordPress 3 is increasingly picky | |
| 492 | + about what it will accept for new author accounts, and some of the | |
| 493 | + conditions it imposes can cause error conditions that prevent posts from | |
| 494 | + being properly syndicated, or properly attributed, if authors happen to | |
| 495 | + have identical e-mail addresses, or if users are given usernames that are | |
| 496 | + written in non-Western scripts. FeedWordPress now handles these much | |
| 497 | + better, and systematically works to avoid clashes between syndicated | |
| 498 | + authors' account names or in their e-mail addresses, which should result | |
| 499 | + in significantly better results in mapping author names to WordPress | |
| 500 | + user accounts. | |
| 501 | + | |
| 502 | +* MAPPING CATEGORIES ON SYNDICATED POSTS TO TAGS NOW BETTER SUPPORTED: | |
| 503 | + In previous versions, the only way for the Categories provided by a | |
| 504 | + syndicated feed to be mapped into Post Tags was to instruct FWP to | |
| 505 | + create new tags, rather than new categories, for unfamiliar categories | |
| 506 | + from the feed. This works fine if you want tags to be the default; but | |
| 507 | + if you want only a *specific* set of tags, there was no way to get them | |
| 508 | + without getting most or all other categories imported as tags. You can | |
| 509 | + now do this by creating a tag (under Posts ==> Post Tags) before | |
| 510 | + importing the post; when the syndicated category matches a pre-existing | |
| 511 | + tag, the incoming post will be tagged with that tag, without creating | |
| 512 | + a local Post Category. | |
| 513 | + | |
| 514 | +* REL-TAG MICROFORMAT SUPPORT FOR INLINE TAGS: Syndicated posts that | |
| 515 | + contain inline tags, marked up using the Rel-Tag microformat | |
| 516 | + <http://microformats.org/wiki/rel-tag>, are now tagged with the tags | |
| 517 | + provided by Rel-Tag format links. | |
| 518 | + | |
| 519 | +* MUCH GREATER CONTROL OVER CATEGORY AND TAG MAPPING: This is partly the | |
| 520 | + result of building in support for a potentially endless set of custom | |
| 521 | + taxonomies (see below), but in general there has been a great deal of | |
| 522 | + effort towards giving you more control over how categories and tags | |
| 523 | + provided by the feed are mapped into terms on the local blog. In | |
| 524 | + particular, you can now force FeedWordPress to create only categories | |
| 525 | + from categories and tags provided by the feed; or to create only tags; | |
| 526 | + or to search both categories and tags for a match; or you can simply | |
| 527 | + force it to drop all of the categories provided by the feed and use | |
| 528 | + only categories or tags that you explicitly provide. In addition, you | |
| 529 | + can now also choose whether to override global categories settings with | |
| 530 | + a local, feed-specific setting; or whether to *add together* *both* the | |
| 531 | + global categories and the local feed-specific categories -- depending | |
| 532 | + on whatever your use-case may demand. | |
| 533 | + | |
| 534 | +* CUSTOM POST TYPES AND TAXONOMY SUPPORTS: This is mainly for the | |
| 535 | + super-geeky, but if you use other plugins or themes that make | |
| 536 | + significant use of WordPress's support for custom post types and custom | |
| 537 | + taxonomies, you may be pleased to find that FeedWordPress now allows you | |
| 538 | + to feed incoming posts into any custom feed type that you wish, and to | |
| 539 | + map categories and tags from the feed to custom taxonomies as well as | |
| 540 | + to the standard Category and Tag taxonomies. | |
| 541 | + | |
| 542 | +* STORING NAMESPACED CUSTOM FEED ELEMENTS IN POST CUSTOM FIELDS: If you | |
| 543 | + would like to use FeedWordPress's support for storing custom meta-data | |
| 544 | + from feed elements in the custom fields for a post (for example, to | |
| 545 | + store geolocation data or iTunes media meta-data), you'll find that it's | |
| 546 | + now much easier for you to access these namespaced elements. You always | |
| 547 | + could access them, but in previous versions you might have to write | |
| 548 | + something ugly like $(/{http://www.w3.org/2003/01/geo/wgs84_pos#}lat) | |
| 549 | + just to get at the value of a `<geo:lat>` tag. Now, as long as you use | |
| 550 | + the same mnemonic codes that the feed producer used, you should always | |
| 551 | + be able to write a nice, simple expression like $(/geo:lat) to get the | |
| 552 | + value of a <geo:lat> tag. | |
| 553 | + | |
| 554 | +* CUSTOM DIRECTORY STRUCTURE SUPPORT: if you poke at it enough, WordPress | |
| 555 | + is relatively flexible about where it should store admin interface code, | |
| 556 | + uploaded content, plugins, and a number of other things that occupy an | |
| 557 | + important place in the WordPress directory structure. Previous versions | |
| 558 | + of FeedWordPress encountered serious errors or broke entirely when used | |
| 559 | + with directory structures other than the default. This should now be | |
| 560 | + fixed: FWP now supports custom directory structures wherever WordPress | |
| 561 | + allows them to be customized, rather than depending on the default | |
| 562 | + locations. Enjoy your freedom! | |
| 563 | + | |
| 564 | +* MANY NEW FILTERS AND API UTILITY FUNCTIONS FOR ADD-ON PROGRAMMERS: There | |
| 565 | + have been too many improvements to list them all in this ChangeLog, but | |
| 566 | + it means that much more power and ease for folks who are customizing | |
| 567 | + FeedWordPress through PHP filters or add-on modules. Fuller | |
| 568 | + documentation will be put up at the Wiki at feedwordpress.radgeek.org | |
| 569 | + soon. | |
| 570 | + | |
| 571 | += 2010.0623 = | |
| 572 | + | |
| 573 | +* WORDPRESS 3.0 COMPATIBILITY / AUTHOR MAPPING INTERFACE ISSUES: I | |
| 574 | + resolved a couple of outstanding issues with the author mapping | |
| 575 | + interface (Syndication --> Authors), which were preventing new users | |
| 576 | + from being created correctly and author mapping rules from being set up | |
| 577 | + correctly. These partly had to do with new restrictions on user account | |
| 578 | + creation introduced in WordPress 3.0; anyway, they should now be fixed. | |
| 579 | + | |
| 580 | +* MORE EFFICIENT SYNDICATED URL LOOKUPS: Several users noticed that the | |
| 581 | + bug fix introduced in 2010.0528 for compatibility with post-listing | |
| 582 | + plugins caused a lot more queries to the database in order to look up | |
| 583 | + numerical post IDs from the URL provided to the filter. This shouldn't | |
| 584 | + cause any major problems, but it is not as efficient as it could be; the | |
| 585 | + code now takes advantage of a more efficient way of doing things, | |
| 586 | + which usually will not require any additional database queries. | |
| 587 | + | |
| 588 | +* SIMPLEPIE FEED UPDATE ISSUES: If you have been having significant | |
| 589 | + problems with getting feeds to update correctly, this may be the result | |
| 590 | + of some bugs in the implementation of SimplePie caching that ships with | |
| 591 | + WordPress (as of version 3.0). (You would most commonly experience this | |
| 592 | + error if you continually saw errors such as "No feed found at <...>" in | |
| 593 | + your updates.) Fortunately, SimplePie allows for a great deal of | |
| 594 | + extensibility and this allows me to work around the problem; these | |
| 595 | + error conditions should now be mostly eliminated when the underlying | |
| 596 | + feed is valid. | |
| 597 | + | |
| 598 | +* UI: SHOW INACTIVE SOURCES: When you use the default unsubscribe option | |
| 599 | + -- which turns off the subscription to a feed while preserving the posts | |
| 600 | + from it and the syndication-related meta-data for the feed -- the | |
| 601 | + unsubscribed feed can now easily be viewed in a special "Inactive" | |
| 602 | + section of the Syndicated Sources page. (As a side benefit, if you've | |
| 603 | + accidentally, or only temporarily, turned off the subscription to a | |
| 604 | + feed, it is now much easier to restore the feed to being active, or to | |
| 605 | + delete it permanently, if you prefer. | |
| 606 | + | |
| 607 | +* UI: FEED FINDER / SWITCH FEED INTERFACE IMPROVEMENTS: changes to styling | |
| 608 | + and options for the feed finder / switch feed, which should now make it | |
| 609 | + easier, in some cases, to find alternative feeds, and make interface | |
| 610 | + options more clearly visible. | |
| 611 | + | |
| 612 | +* FILTERS: `syndicated_item_published` and `syndicated_item_updated` NOW | |
| 613 | + PROPERLY AFFECT THE DATING OF POSTS. These filters used to affect some | |
| 614 | + date-related settings, but not others -- and, most importantly, not the | |
| 615 | + final date that is set for a post's publication or last-modified date | |
| 616 | + in the WordPress database. Now, they do affect that, as they should. | |
| 617 | + (Filters should receive, and return, a long integer, representing a Unix | |
| 618 | + epoch relative timestamp.) | |
| 619 | + | |
| 620 | +* MAGIC URL TO CLEAR THE CACHE: Suppose that you need to clear the feed | |
| 621 | + cache, for whatever reason; suppose, even, that you need to clear it on | |
| 622 | + a regular basis. One way you might do this is by logging into the | |
| 623 | + FeedWordPress administrative interface and going to Syndication --> | |
| 624 | + Performance. Another way you might do it, now, is to simply send an | |
| 625 | + HTTP request to a magic URL provided by FeedWordPress: if your blog is | |
| 626 | + at example.com, the URL would be <http://example.com/?clear_cache=1> | |
| 627 | + | |
| 628 | += 2010.0602 = | |
| 629 | + | |
| 630 | +* CATEGORY BOX INTERFACE ELEMENT FIXED FOR WP 3.0: Stylesheet changes | |
| 631 | + between WordPress 2.9.x and the WordPress 3.0 RC caused the Categories | |
| 632 | + box under **Syndication --> Categories & Tags** to malfunction. This | |
| 633 | + has been fixed. | |
| 634 | + | |
| 635 | +* LINK CATEGORY SELECTION BOX IN SYNDICATION ==> FEEDS FIXED FOR WP 2.8 | |
| 636 | + AND 2.9: A WP 3.0 compatibility change introduced in 2010.0531 | |
| 637 | + inadvertently broke the Syndicated Link Category selector under | |
| 638 | + Syndication --> Feeds & Updates in WP 2.8 and WP 2.9, causing the post | |
| 639 | + categories to be displayed in the selector rather than the link | |
| 640 | + categories. This should now be fixed so that the selector will work | |
| 641 | + correctly under both the current versions of WordPress and the 3.0 RC. | |
| 642 | + | |
| 643 | +* MORE PERMISSIVE HANDLING OF FEEDS WITH BAD CONTENT-TYPE HEADERS: One of | |
| 644 | + the small advantages that MagpieRSS had over SimplePie is that it was | |
| 645 | + more tolerant about parsing well-formed feeds that the remote web server | |
| 646 | + happened to deliver with weird or incorrect HTTP Content-type headers. | |
| 647 | + In feeds affected by this problem, the new SimplePie parser would simply | |
| 648 | + fail to find a feed, due to its being led astray by the contents of the | |
| 649 | + Content-type header. This version includes an extension to SimplePie's | |
| 650 | + content-type sniffer that offers more permissive handling of the HTTP | |
| 651 | + headers. | |
| 652 | + | |
| 653 | +* MORE FULL-TEXT "EXCERPTS" NOW PROPERLY SHORTENED. Version 2010.0528 | |
| 654 | + introduced code to control for cases in which elements intended for | |
| 655 | + item summaries are (ill-advisedly) used to carry the full text of posts; | |
| 656 | + past versions of FeedWordPress would simply include the full text of the | |
| 657 | + post in the excerpt field, but newer versions now attempt to detect | |
| 658 | + this condition when it arises and to head it off, by blanking out the | |
| 659 | + excerpt field and filling it with an automatically generated short, | |
| 660 | + plain text excerpt from the full content. This release broadens the | |
| 661 | + test conditions that indicate when an excerpt field is treated as | |
| 662 | + identical to the full text of the post, and should therefore improve | |
| 663 | + the handling of some feeds (such as Google Reader feeds) where the full | |
| 664 | + text of each post was still appearing in the excerpt field. | |
| 665 | + | |
| 666 | +* FILTERS: `syndicated_item_published` AND `syndicated_item_updated` | |
| 667 | + FILTERS NOW ALLOW FILTER AUTHORS TO CHANGE POST TIMESTAMPS. You can now | |
| 668 | + use the `syndicated_item_published` and `syndicated_item_updated` filter | |
| 669 | + hooks to write filters or add-ons which directly change the post date | |
| 670 | + and most-recently-updated timestamps on incoming syndicated posts. Props | |
| 671 | + to niska for pointing out where the filters needed to be applied in | |
| 672 | + order to change WordPress's internal timestamps for incoming posts. | |
| 673 | + | |
| 674 | += 2010.0531 = | |
| 675 | + | |
| 676 | +* PERMALINK / CUSTOM FIELDS PROBLEM RESOLVED: An issue in 2010.0528 caused | |
| 677 | + some posts to be imported without the proper syndication-related | |
| 678 | + meta-data being attached (thus causing permalinks to point back to the | |
| 679 | + aggregator website rather than to the source website, among other | |
| 680 | + problems). This problem has been resolved (and a fix has been applied | |
| 681 | + which will resolve the problem for any posts affected by this problem, | |
| 682 | + if the original post is recent enough to still be available on the feed). | |
| 683 | + | |
| 684 | +* UI: The "Back End" section has been split into two separate sections -- | |
| 685 | + "Performance" (dealing with caching, database index, and other | |
| 686 | + performance tweaks), and "Diagnostics" (dealing with debug mode, | |
| 687 | + update logging, and a number of new diagnostic tests which I will be | |
| 688 | + rolling out over the next few releases). | |
| 689 | + | |
| 690 | +* Several minor interface bug fixes and PHP warning notices eliminated. | |
| 691 | + | |
| 692 | += 2010.0528 = | |
| 693 | + | |
| 694 | +#### Compatibility #### | |
| 695 | + | |
| 696 | +* SIMPLEPIE IS NOW USED TO PARSE FEEDS; NO MORE MAGPIERSS UPGRADES NEEDED: | |
| 697 | + One of the biggest changes in this release is that FeedWordPress no | |
| 698 | + longer depends on MagpieRSS to parse feeds, and has switched to the much | |
| 699 | + more up-to-date and flexible SimplePie feed parser, which is included as | |
| 700 | + a standard part of WordPress versions 2.8 and later. Using SimplePie will | |
| 701 | + hopefully allow for better handling of feeds going further, and will | |
| 702 | + allow me greater flexibility in determining how exactly the feed parser | |
| 703 | + will operate. It also means that FeedWordPress no longer requires | |
| 704 | + special upgrades to the WordPress core MagpieRSS files, and should | |
| 705 | + eliminate quite a bit of complexity. | |
| 706 | + | |
| 707 | +* MAGPIERSS COMPATIBILITY LAYER FOR EXISTING FILTERS AND ADD-ONS: However, | |
| 708 | + I have also implemented a compatibility layer to ensure that existing | |
| 709 | + filters and add-ons for FeedWordPress which depended on the MagpieRSS | |
| 710 | + data format *should not be broken* by the switch to SimplePie. Going | |
| 711 | + forward, I recommend that new filters and add-ons be written to take | |
| 712 | + advantage of the SimplePie object representations of items, feeds, etc., | |
| 713 | + rather than the MagpieRSS arrays, but the MagpieRSS arrays will still | |
| 714 | + be available and older filters should continue to work as they have in | |
| 715 | + the past. | |
| 716 | + | |
| 717 | +* COMPATIBILITY WITH WORDPRESS 2.9.x and 3.0: This release has been tested | |
| 718 | + for the existing WordPress 2.9.x branch and with the upcoming release of | |
| 719 | + WordPress 3.0. Changes in the user interface JavaScript between WordPress | |
| 720 | + 2.8.x and WordPress 2.9 caused the tag box interface element to break in | |
| 721 | + the Syndication --> Categories & Tags settings page; changes in the API | |
| 722 | + functions for adding new authors caused fatal errors under certain | |
| 723 | + conditions in WordPress 3.0. These breakages have been fixed. | |
| 724 | + | |
| 725 | +* DROPPED LEGACY SUPPORT FOR WORDPRESS PRIOR TO 2.8: Because SimplePie is | |
| 726 | + not included with versions of WordPress prior to 2.8, I have chosen to | |
| 727 | + drop legacy support for WordPress versions 1.5 through 2.7. If you are | |
| 728 | + using FeedWordPress with a version of WordPress before 2.8, you will | |
| 729 | + have to upgrade your installation of WordPress in order to take | |
| 730 | + advantage of this release. | |
| 731 | + | |
| 732 | +* PHP 5.3 COMPATIBILITY: A couple of compatibility issues, which were | |
| 733 | + causing fatal errors amd ugly warnings for users of PHP 5.3, | |
| 734 | + have been eliminated. | |
| 735 | + | |
| 736 | +#### Features and Processing #### | |
| 737 | + | |
| 738 | +* INTERFACE REORGANIZATION: The interface restructuring, began with | |
| 739 | + Version 2009.0612, has been completed. Catch-all settings pages have | |
| 740 | + been eliminated entirely for pages that cover each aspect of handling | |
| 741 | + a feed: Feeds & Updates, Posts & Links, Authors, Categories & Tags, | |
| 742 | + and Back End handling of the database and diagnostic information. | |
| 743 | + Extensive new interface hooks allow add-on modules to significantly | |
| 744 | + change or extend the FeedWordPress admin interface and workflow. | |
| 745 | + | |
| 746 | +* STORING INFORMATION FROM THE FEED IN CUSTOM FIELDS: Many users | |
| 747 | + have written to request the ability to store information from elements | |
| 748 | + in the feed in a custom field on each post. (So that, for example, if | |
| 749 | + post includes a `itunes:duration` element, you could store the contents | |
| 750 | + in a Custom Field called `duration` on the post (for a Theme to access | |
| 751 | + later). The Custom Post Settings under Syndication --> Posts & Links now | |
| 752 | + allow you to access any item or feed tag, using a syntax similar to | |
| 753 | + a much-simplified version of XPath. See Posts & Links settings for | |
| 754 | + details. | |
| 755 | + | |
| 756 | +* UPDATE-FREEZING ON MANUALLY EDITED POSTS: FeedWordPress now allows you | |
| 757 | + to mark posts that have been manually edited, so that the changes you | |
| 758 | + make will not be overwritten by later updates from the feed. If you make | |
| 759 | + manual edits to a particular post, just check the "Manual editing" | |
| 760 | + checkbox in order to protect your changes from being overwritten. If you | |
| 761 | + want to block *all* posts from being updated after they are imported | |
| 762 | + for the first time, a new "Updated Posts" setting in Posts & Links | |
| 763 | + allows you to freeze all posts from a particular feed, or all syndicated | |
| 764 | + posts. | |
| 765 | + | |
| 766 | +* SETTING: FEED-BY-FEED SETTINGS FOR WHERE PERMALINKS POINT TO: You've | |
| 767 | + always been able to tell FeedWordPress whether permalinks for posts | |
| 768 | + should point to the original source of the story or the local copy. Now | |
| 769 | + you can choose different policies for different feeds, instead of one | |
| 770 | + global policy for all feeds. (Of course, you can still use a global | |
| 771 | + default if you prefer.) | |
| 772 | + | |
| 773 | +* SETTING: USER CONTROL OVER TIMING BASIS. You can now determine the | |
| 774 | + schedule on which feeds are considered ready to poll for updates -- | |
| 775 | + by default feeds become ready for polling after about 1 hour. You can | |
| 776 | + now increase or decrease the time window under Syndication --> Feeds & | |
| 777 | + Updates. (However, please pay *CAREFUL ATTENTION* to the recommendations | |
| 778 | + and DO NOT set the scheduling lower than 60 minutes unless you are | |
| 779 | + ABSOLUTELY SURE that you have specific permission from webmaster who | |
| 780 | + provides that specific feed to poll more frequently than that. If you | |
| 781 | + set this too low (and about 60 minutes is the polite minimum if you | |
| 782 | + haven't been given a different figure), most webmasters will consider | |
| 783 | + the frequent hits on their server as rude, or even downright abusive. | |
| 784 | + | |
| 785 | +* OTHER SETTINGS: New settings also include the ability to stop FWP from | |
| 786 | + resolving relative URLs within syndicated content, and the ability to | |
| 787 | + choose whether FeedWordPress should indicate the comment feed from the | |
| 788 | + original source, or the local comment feed, when providing the comment | |
| 789 | + feed URL for a syndicated post. | |
| 790 | + | |
| 791 | +#### Parsing #### | |
| 792 | + | |
| 793 | +* BETTER DATE HANDLING -- FEWER FLASHBACKS TO 1969 and 1970: FeedWordPress | |
| 794 | + has made some bugfixes and some improvements in the logic for parsing | |
| 795 | + dates. This should allow FeedWordPress to correctly parse more dates in | |
| 796 | + more feeds; and, in the last resort, when FeedWordPress fails to | |
| 797 | + correctly parse a date, to fall back to a more intelligent default. This | |
| 798 | + should hopefully avoid most or all error conditions that have resulted | |
| 799 | + in articles being erroneously dated to the dawn of the Unix epoch | |
| 800 | + (31 December 1969 or 1 January 1970). | |
| 801 | + | |
| 802 | +* FULL-TEXT "EXCERPTS" NOW PROPERLY SHORTENED. Based on a straightforward | |
| 803 | + reading of the existing RSS specs, it's reasonable for the | |
| 804 | + rss:description element to be read as a plaintext summary or excerpt for | |
| 805 | + the item containing the description -- with the full text of the item, | |
| 806 | + if available, in another, better-suited element, such as the de facto | |
| 807 | + standard content:encoded extension element. The problem is that uses of | |
| 808 | + RSS rarely have much to do with anything like a straightforward reading | |
| 809 | + of the specs. As a result, many actual RSS producers in the wild put the | |
| 810 | + full text of the article in a description element. But since | |
| 811 | + FeedWordPress has treated this text as a summary, this produces | |
| 812 | + aggregated posts with lengthy "excerpts" containing the full text of the | |
| 813 | + article. This release of FeedWordPress fixes the problem by doing a | |
| 814 | + little digging before treating rss:description as a summary: if the | |
| 815 | + description element is used properly as a plain text summary, then | |
| 816 | + FeedWordPress will take the summary provided by the feed, rather than | |
| 817 | + recreating its own excerpt from the full text; but if an RSS item has no | |
| 818 | + full-text element other than description, FeedWordPress will treat the | |
| 819 | + description element as the full text of the article, and generate a | |
| 820 | + shortened excerpt automatically from that text. | |
| 821 | + | |
| 822 | +#### API #### | |
| 823 | + | |
| 824 | +* TEMPLATE API: new template tags `get_local_permalink()` and | |
| 825 | + `the_local_permalink()` allow you to access the permalink for a post on | |
| 826 | + your aggregator site, even when FeedWordPress is rewriting permalinks to | |
| 827 | + point to the original source site. | |
| 828 | + | |
| 829 | +* NEW HOOKS FOR ADD-ONS AND FILTERS: I have added a number of new hooks | |
| 830 | + which allow add-on modules to filter more precisely, gather information | |
| 831 | + at more points, and to enhance the FeedWordPress admin interface. For | |
| 832 | + a list of new hooks and documentation, see the FeedWordPress | |
| 833 | + documentation wiki at | |
| 834 | + <http://feedwordpress.radgeek.com/wiki/add-ons-and-filters> | |
| 835 | + | |
| 836 | +* FILTER API: A number of new utility methods have been added to the | |
| 837 | + SyndicatedPost class to make it easier for filters and add-ons to | |
| 838 | + | |
| 839 | +* FILTER API: Globals $fwp_channel and $fwp_feedmeta DEPRECATED. These | |
| 840 | + global variables, originally introduced to allow filters access to | |
| 841 | + information about the source feed in `syndicated_item` filters (which | |
| 842 | + were passed in through global variables rather than as parameters | |
| 843 | + because of a bug in WP 1.5 which was then fixed in 1.5.1) have been | |
| 844 | + DEPRECATED. If you have any filters or add-ons which still depend on | |
| 845 | + these global variables, you should see about fixing them to access data | |
| 846 | + about the source feed using the SyndicatedPost::link element instead. | |
| 847 | + For documentation, see the FeedWordPress documentation wiki at | |
| 848 | + <http://feedwordpress.radgeek.com/wiki/syndicatedpost> and | |
| 849 | + <http://feedwordpress.radgeek.com/wiki/syndicatedlink>. | |
| 850 | + | |
| 851 | +* DIAGNOSTICS: I've included a number of new diagnostic options and | |
| 852 | + messages, which should allow an experienced user to better investigate | |
| 853 | + any problems that may crop up. | |
| 854 | + | |
| 855 | +#### Bug Fixes #### | |
| 856 | + | |
| 857 | +* BUGFIX: & IN PERMALINKS NO LONGER CAUSING ATOM OR HTML VALIDATION | |
| 858 | + EFFORTS: Many users reported an issue in which syndicating a feed with | |
| 859 | + special XML characters in the URLs (& was the most common, since it is | |
| 860 | + used to separate HTTP GET parameters) would cause the aggregator's | |
| 861 | + feeds to produce invalid (malformed) XML. This update addresses the | |
| 862 | + issue in Atom feeds. Unfortunately, it has not been technically possible | |
| 863 | + to address the problem in RSS 2.0 feeds, due to limitations on | |
| 864 | + WordPress's internal templates for RSS feeds. | |
| 865 | + | |
| 866 | +* BUGFIX: BROKEN URLS IN "POPULAR POSTS" AND SIMILAR PLUGINS SHOULD NO | |
| 867 | + LONGER BE BROKEN. A number of users noticed an issue where plugins and | |
| 868 | + templates that listed posts in locations outside of the post loop | |
| 869 | + (for example, "Popular Posts"-style plugins that listed posts in the | |
| 870 | + sidebar), often produced the wrong URL for post links. (Typically, all | |
| 871 | + the posts listed would get the same wrong URL.) This should now be | |
| 872 | + fixed. Thanks to Björn for sending in a quick fix! | |
| 873 | + | |
| 874 | +* MINOR BUGFIXES: This release includes a number of fixes to minor bugs | |
| 875 | + and compatibility issues, including: silent failures of the "Syndicate" | |
| 876 | + button, "Illegal Offset Type" error messages from MagpieRSS, and others. | |
| 877 | + | |
| 878 | += 2009.0707 = | |
| 879 | + | |
| 880 | +* BUGFIX: WORDPRESS 2.8 AJAX COMPATIBILITY ISSUES RESOLVED (blank or | |
| 881 | + truncated "Syndicated Sites" administration page): Due to changes in the | |
| 882 | + AJAX interface elements between WordPress 2.7 and WordPress 2.8, several | |
| 883 | + FeedWordPress users encountered an issue where the front "Syndication" | |
| 884 | + page in the FeedWordPress administrative interface would come up blank, | |
| 885 | + without the normal "Syndicated Sites" list and "Update" control, or | |
| 886 | + sometimes wth the boxes visible but one or both of them truncated, with | |
| 887 | + only the title bar. This issue should now be resolved: with the new | |
| 888 | + version of FeedWordPress, the compatibility issue that caused the | |
| 889 | + disappearance should be eliminated, and if boxes are shown with only | |
| 890 | + their handle visible, you should once again be able to drop down the | |
| 891 | + rest of the box by clicking once on its title bar. | |
| 892 | + | |
| 893 | +* BUGFIX: TAG SETTING WIDGET FIXED. Due to changes in interface elements | |
| 894 | + between WordPress 2.7 and WordPress 2.8, people using FeedWordPress with | |
| 895 | + WordPress 2.8 found that the widget for setting tags to be applied to | |
| 896 | + all syndicated posts, or all syndicated posts from a particular feed, | |
| 897 | + no longer displayed "Add" and "Remove" buttons for individual tags. This | |
| 898 | + issue has now been fixed, and the tagging widget should once again work | |
| 899 | + more or less exactly like the tagging widget for individual posts in the | |
| 900 | + normal WordPress admin interface. | |
| 901 | + | |
| 902 | += 2009.0618 = | |
| 903 | + | |
| 904 | +* BUGFIX: MYSTERY ERRORS WITH WITH WP_Http_Fsockopen HTTP TRANSPORT | |
| 905 | + ELIMINATED: Thanks to a combination of a subtle bug in FeedWordPress, | |
| 906 | + and changes to the HTTP transport code in WordPress, a number of users | |
| 907 | + encountered an error in which any time they attempted to add a new feed | |
| 908 | + through the FeedFinder interface, FeedWordPress would fail and display | |
| 909 | + an HTTP request failure diagnostic message. The subtle bug has been | |
| 910 | + fixed, and with it, most of these errors should now be eliminated. | |
| 911 | + | |
| 912 | + Be sure to upgrade your MagpieRSS to the most recent MagpieRSS version | |
| 913 | + after you have insalled FeedWordPress 2009.0618, or this bug fix will | |
| 914 | + not take effect. | |
| 915 | + | |
| 916 | += 2009.0613 = | |
| 917 | + | |
| 918 | +* INTERFACE/BUGFIX: WORDPRESS 2.8 CATEGORY BOX FIX. Thanks to a subtle | |
| 919 | + change in class names between the WordPress 2.7 and 2.8 stylesheets, | |
| 920 | + category boxes in the FeedWordPress settings interface tended to overflow | |
| 921 | + and have a lot of messy-looking overlapping text under WordPress 2.8. | |
| 922 | + This has now been fixed. | |
| 923 | + | |
| 924 | +* FeedFinder FAILURE DIAGNOSTICS: When FWP's FeedFinder fails to find any | |
| 925 | + feeds at a given URL (for example, when you are trying to add a | |
| 926 | + subscription through the administrative interface and you run into an | |
| 927 | + error message), FeedWordPress now provides more diagnostic information | |
| 928 | + for the reasons behind the failure. If that helps you, great; if not, | |
| 929 | + it should help me respond more intelligently to your support request.. | |
| 930 | + | |
| 931 | += 2009.0612 = | |
| 932 | + | |
| 933 | +* WORDPRESS 2.8 COMPATIBILITY: FeedWordPress 2009.0612 has been tested for | |
| 934 | + compatibility with the recent version 2.8 release of WordPress. | |
| 935 | + | |
| 936 | +* INTERFACE RESTRUCTURING: In order to avoid settings posts from becoming | |
| 937 | + too crowded, and to modularize and better organize the user interface, | |
| 938 | + new "Posts" and "Categories & Tags" subpages have been created under the | |
| 939 | + "Syndication" menu. "Posts" controls settings for individal syndicated | |
| 940 | + posts (such as publication status, comment and ping status, whether or | |
| 941 | + not to use the original location of the post as the permalink, whether | |
| 942 | + or not to expose posts to formatting filters, and so on). "Categories & | |
| 943 | + Tags" controls settings for assigning new syndicated posts to categories | |
| 944 | + and tags, such as categories or tags to apply to all syndicated posts, | |
| 945 | + and how to handle categories that do not yet exist in the WordPress | |
| 946 | + database. These subpages, like the Authors subpage, handle settings for | |
| 947 | + the global default level and for individual syndicated feeds. | |
| 948 | + | |
| 949 | + Corresponding to these new subpages, the old Syndication Settings and | |
| 950 | + Feed Settings subpages have been cleaned up and simplified, and now only | |
| 951 | + link to the appropriate subpages for options that can be set in the | |
| 952 | + Posts, Authors, or Categories & Tags subpages. | |
| 953 | + | |
| 954 | +* FEATURE: ADD CUSTOM SETTINGS TO EACH SYNDICATED POST: FeedWordPress has | |
| 955 | + long had an interface for creating custom settings for each syndicated | |
| 956 | + *feed* which could be retrieved in templates using the `get_feed_meta()` | |
| 957 | + template function. But it had no feature for adding custom fields to | |
| 958 | + each individual syndicated *post*. In response to requests from users, I | |
| 959 | + have added the ability to apply custom fields to each individual | |
| 960 | + syndicated post, using the new Syndication --> Posts subpage. You can | |
| 961 | + set up custom fields to be applied to every syndicated post, or custom | |
| 962 | + fields to be applied to syndicated posts from a particular feed. | |
| 963 | + | |
| 964 | +* FEATURE: MAGPIERSS VERSION CHECK AND UPGRADE: FeedWordPress will attempt | |
| 965 | + to determine whether or not you are using the upgraded version of | |
| 966 | + MagpieRSS that comes packaged with FeedWordPress. If not, it will throw | |
| 967 | + an error on admin pages, and, if you are a site administrator, it will | |
| 968 | + give you the option to ignore the error message, or to attempt an | |
| 969 | + automatic upgrade (using a native file copy). If the file copy fails, | |
| 970 | + FeedWordPress will offer some guidance on how to perform the upgrade | |
| 971 | + manually. | |
| 972 | + | |
| 973 | +* BLANK POSTS PROBLEM NO LONGER OCCURS WITH OLD & BUSTED MAGPIERSS: Due | |
| 974 | + to the fact that I relied on a content normalization that occurs in my | |
| 975 | + upgraded version of MagpieRSS, but not in the old & busted version of | |
| 976 | + MagpieRSS that ships with WordPress, until this version, if you tried to | |
| 977 | + syndicate an Atom feed without having performed the (*strongly | |
| 978 | + recommended*) MagpieRSS upgrade, all of the posts would come up with | |
| 979 | + completely blank contents. That's not because MagpieRSS couldn't read | |
| 980 | + the data, but rather because the new Magpie version puts that data in a | |
| 981 | + location where the old version doesn't, and I was only looking in that | |
| 982 | + newer location. Now it checks for both, meaning that posts will continue | |
| 983 | + to display their contents even if you don't upgrade MagpieRSS. (But you | |
| 984 | + **really should** upgrade it, anyway.) | |
| 985 | + | |
| 986 | +* BUGFIX: RELATIVE URI RESOLUTION FOR POST CONTENT RESTORED. Some time | |
| 987 | + back, I added support for resolving relative URIs against xml:base on | |
| 988 | + feeds that support it to the MagpieRSS upgrade in FeedWordPress. Then I | |
| 989 | + took out code that did the same thing from the main FeedWordPress code. | |
| 990 | + Of course, the problem is that some people, even though it is clearly | |
| 991 | + stupid or evil to do so, still include relative URIs for images or links | |
| 992 | + in posts on feed formats that do *not* adequately support xml:base | |
| 993 | + (notably, RSS 2.0 feeds). In response to a user request, I have added | |
| 994 | + this functionality back in, so that MagpieRSS will resolve any relative | |
| 995 | + URIs that it knows how to resolve using xml:base, and then FeedWordPress | |
| 996 | + will attempt to resolve any relative URIs that are left over afterwards. | |
| 997 | + | |
| 998 | +* BUGFIX: INTERFACE OPTION FOR SETTING SYNDICATED POST PUBLICATION STATUS | |
| 999 | + ON A FEED-BY-FEED BASIS HAS BEEN RESTORED: Due to a version-checking | |
| 1000 | + bug, users of WordPress 2.7.x lost an option from the "Edit a syndicated | |
| 1001 | + feed" interface which allowed them to determine whether newly syndicated | |
| 1002 | + posts should be published immediately, held as "Pending Review," saved | |
| 1003 | + as drafts, or saved as private posts. (The option to change this | |
| 1004 | + setting globally remained in place, but users could no longer set it on | |
| 1005 | + a feed-by-feed basis.) The version-checking bug has been fixed, and the | |
| 1006 | + option has been restored. | |
| 1007 | + | |
| 1008 | +* BUGFIX: "ARE YOU SURE?" FATAL ERROR ELIMINATED AND SECURITY IMPROVED: | |
| 1009 | + Under certain circumstances (for example, when users have configured | |
| 1010 | + their browser or proxy not to send HTTP Referer headers, for privacy or | |
| 1011 | + other reasons), many features in the FeedWordPress administrative | |
| 1012 | + interface (such as adding new feeds or changing settings) would hit a | |
| 1013 | + fatal error, displaying only a cryptic message reading "Are you sure?" | |
| 1014 | + and a blank page following it. This problem has been eliminated by | |
| 1015 | + taking advantage of WordPress's nonce functions, which allow the | |
| 1016 | + security check which ran into this error to work properly even without | |
| 1017 | + receiving an HTTP Referer header. (N.B.: WordPress's nonce functions | |
| 1018 | + were first introduced in WordPress 2.0.3. If you're using FeedWordPress | |
| 1019 | + with an older version of WordPress, there's no fix for this problem: | |
| 1020 | + you'll just need to turn Referer headers back on. Sorry.) | |
| 1021 | + | |
| 1022 | +* BUGFIX: MANUALLY-ALTERED POST STATUS, COMMENT STATUS, AND PING STATUS NO | |
| 1023 | + LONGER REVERTED BY POST UPDATES: If you manually altered the post status, | |
| 1024 | + comment status, or ping status of a syndicated post from what it was set | |
| 1025 | + to when first syndicated -- for example, if you had a feed that was set | |
| 1026 | + to bring in new posts as "Pending Review," and you then marked some of | |
| 1027 | + the pending posts as "Published" and others as "Unpublished" -- then | |
| 1028 | + in previous versions of FeedWordPress, these manual changes to the | |
| 1029 | + status would be lost -- so that, for example, your Published or Unpublished | |
| 1030 | + articles would revert to Pending Review -- if the source feed made any | |
| 1031 | + upates to the item. This could make the Pending Review feature both | |
| 1032 | + unreliable and also extremely frustrating to work with. The good news is | |
| 1033 | + that this bug has since been fixed: if you manually update the status | |
| 1034 | + of a post, it will no longer be reverted if or when the post is updated. | |
| 1035 | + | |
| 1036 | +* BUGFIX: OCCASIONAL FATAL ERROR ON UPDATE ELIMINATED: Under certain | |
| 1037 | + limited conditions (specifically, when both the title and the content of | |
| 1038 | + a post to be updated are empty), an attempt to update the post would | |
| 1039 | + result in a fatal error. This has been fixed. | |
| 1040 | + | |
| 1041 | +* INTERFACE: "CONFIGURE SETTINGS" CONVENIENCE LINK ADDED TO CONFIRMATION | |
| 1042 | + MESSAGE WHEN A NEW FEED IS ADDED: When you add a new subscription to | |
| 1043 | + FeedWordPress, the message box that appears to confirm it now includes a | |
| 1044 | + handy link to the feed's settings subpage, so that you can quickly set | |
| 1045 | + up any special settings you may want to set up for the new feed, without | |
| 1046 | + having to hunt through the list of all your other subscriptions to pick | |
| 1047 | + out the new one. | |
| 1048 | + | |
| 1049 | +* INTERFACE: SIMPLIFYING AND CLARIFYING AUTOMATIC UPDATES SETTINGS. I have | |
| 1050 | + removed an interval setting for the cronless automatic updates which has | |
| 1051 | + confused many FeedWordPress users. In past versions of FWP, when you | |
| 1052 | + turned on automatic updates, you would be presented with a time interval | |
| 1053 | + setting which controlled how often FeedWordPress would check for feeds | |
| 1054 | + ready to be polled for updates. (That is, it DID NOT control how often | |
| 1055 | + feeds *would be polled*; it controlled how often FeedWordPress would | |
| 1056 | + *check* for feeds that *had become ready to poll*. The schedule on which | |
| 1057 | + feeds became ready for polling was still controlled either by requests | |
| 1058 | + encoded in elements within the feed itself, or else according to an | |
| 1059 | + internal calculation within FeedWordPress, averaging out to about 1 hour, | |
| 1060 | + if the feed did not include any scheduling request elements.) Since many | |
| 1061 | + users very often (and understandably) confused the purpose of this | |
| 1062 | + setting, and since the setting is for a feature that's actually very | |
| 1063 | + unlikely to require any manual control by the user, I have removed the | |
| 1064 | + setting; FeedWordPress now simply uses the default value of checking for | |
| 1065 | + feeds to poll every 10 minutes. | |
| 1066 | + | |
| 1067 | +* FEEDFINDER PERFORMANCE IMPROVEMENT: FeedWordPress's FeedFinder class | |
| 1068 | + now uses `array_unique()` to make sure that it doesn't waste time | |
| 1069 | + repeatedly iterating over and polling the same URI. Props to Camilo | |
| 1070 | + (<http://projects.radgeek.com/2008/12/14/feedwordpress-20081214/#comment-20090122160414>). | |
| 1071 | + | |
| 1072 | += 2008.1214 = | |
| 1073 | + | |
| 1074 | +* WORDPRESS 2.7 COMPATIBILITY: FeedWordPress has been tested for | |
| 1075 | + compatibility with the newly released WordPress 2.7. WordPress 2.7 has | |
| 1076 | + deprecated the Snoopy library for HTTP requests, which caused a fatal | |
| 1077 | + error for users who had not installed the MagpieRSS upgrade (or whose | |
| 1078 | + installation of the MagpieRSS upgrade was overwritten by a recent update | |
| 1079 | + of WordPress). FeedWordPress now handles things gracefully when Snoopy | |
| 1080 | + is not immediately available. | |
| 1081 | + | |
| 1082 | +* INTERFACE SPIFFED UP: Interface elements have been updated so that | |
| 1083 | + FeedWordPress's management interface fits in more naturally with the | |
| 1084 | + WordPress 2.7 interface (including a new logo and a number of small | |
| 1085 | + interface tweaks). | |
| 1086 | + | |
| 1087 | +* BUG WITH TAGS FOR SYNDICATED ARTICLES FIXED: Several users encountered a | |
| 1088 | + bug with the option to add tags to all syndicated posts under | |
| 1089 | + Syndication --> Settings -- if you told FeedWordPress to add more than | |
| 1090 | + one tag to all syndicated posts, instead of doing so correctly, it would | |
| 1091 | + add a *single* tag instead, whose name was composed of the names of all | |
| 1092 | + the tags you asked it to add. This bug was the result of nothing more | |
| 1093 | + dignified than a typographical error on my part. It has now been fixed. | |
| 1094 | + | |
| 1095 | +* MORE INFORMATION AVAILABLE WHEN FEEDWORDPRESS CAN'T FIND A FEED: When | |
| 1096 | + you enter a URL for a new syndication source, FeedWordPress uses a | |
| 1097 | + simple feed-finding algorithm (originally based on Mark Pilgrim's | |
| 1098 | + Universal Feed Finder) to try to determine whether the URL is the URL | |
| 1099 | + for a feed, or, if the URL points to an ordinary website rather than to | |
| 1100 | + a feed, whether there is a feed for that website. All well and good, but | |
| 1101 | + if FeedWordPress failed to find a feed, for whatever reason, it would | |
| 1102 | + typically return nothing more than a nasty little note to the effect of | |
| 1103 | + "no feed found," without any explanation of what went wrong. | |
| 1104 | + FeedWordPress now keeps track of error conditions from the HTTP | |
| 1105 | + requests that it uses in the course of looking for the feed, and so may | |
| 1106 | + be able to give you a bit more information about the nature of the | |
| 1107 | + problem if something goes wrong. | |
| 1108 | + | |
| 1109 | + | |
| 1110 | += 2008.1105 = | |
| 1111 | + | |
| 1112 | +* INTERFACE RESTRUCTURING AND SYNDICATION --> AUTHORS PAGE: As a first | |
| 1113 | + step towards modularizing and better organizing the user interface, a | |
| 1114 | + new "Authors" subpage has been created under the Syndication menu, which | |
| 1115 | + controls settings for syndicated authors, both at the global default | |
| 1116 | + level and at level of individual syndicated feeds. | |
| 1117 | + | |
| 1118 | +* BUG RELATED TO THE ATTRIBUTION OF POSTS TO THE WRONG AUTHOR FIXED: Some | |
| 1119 | + users encountered an issue in which posts by different authors on | |
| 1120 | + different blogs -- especially blogs generated by Blogger -- were | |
| 1121 | + mistakenly attributed to a single author. The problem was caused by the | |
| 1122 | + way in which FeedWordPress matches syndicated authors to user accounts | |
| 1123 | + in the WordPress database: normally, if two feeds each list an author | |
| 1124 | + with the same e-mail address, they are counted as being the same person. | |
| 1125 | + Normally this works well, but it creates an issue in cases where | |
| 1126 | + blogging software assigns a single anonymous e-mail address to users who | |
| 1127 | + do not want their real e-mail address published. This is, for example, | |
| 1128 | + what Blogger does (by giving all users a default e-mail address of | |
| 1129 | + <noreply@blogger.com> if they don't want their own e-mail address | |
| 1130 | + listed). FeedWordPress now allows the user to correct for this problem | |
| 1131 | + with a couple of new settings under **Syndication --> Authors**, which | |
| 1132 | + allow users to turn off e-mail based author matching for particular | |
| 1133 | + addresses, or, if desired, to turn it off entirely. By default, e-mail | |
| 1134 | + based author matching is still turned on, but disabled for a list of | |
| 1135 | + known generic e-mail addresses. Right now, the "list" consists entirely | |
| 1136 | + of <noreply@blogger.com>; if you know other addresses that should be | |
| 1137 | + added, please [contact me](http://radgeek.com/contact) to let me know. | |
| 1138 | + | |
| 1139 | + Please note that if you have already encountered this issue on your | |
| 1140 | + blog, upgrading FeedWordPress will prevent it from re-occurring in the | |
| 1141 | + future, but you still need to do two other things to fix the existing | |
| 1142 | + problem on your blog. | |
| 1143 | + | |
| 1144 | + First, for each feed where posts have been mis-attributed, you need to | |
| 1145 | + change the existing author mapping rules to re-map a a syndicated | |
| 1146 | + author's name to the proper target account. Go to **Syndication --> | |
| 1147 | + Authors**, select the feed you want to change from the drop-down list, | |
| 1148 | + and then change the settings under the "Syndicated Authors" section. | |
| 1149 | + (You will probably need to select "will be assigned to a new user..." to | |
| 1150 | + create a new user account with the appropriate name.) | |
| 1151 | + | |
| 1152 | + Second, for each feed where posts have been mis-attributed, you need to | |
| 1153 | + re-assign already-syndicated posts that were mis-attributed to the | |
| 1154 | + correct author. You can do that from **Syndication --> Authors** by | |
| 1155 | + using the author re-assignment feature, described below. | |
| 1156 | + | |
| 1157 | +* AUTHOR RE-ASSIGNMENT FOR A PARTICULAR FEED: The author settings page | |
| 1158 | + for each syndicated feed, under **Syndication --> Authors**, now | |
| 1159 | + includes an section titled "Fixing mis-matched authors," which provides | |
| 1160 | + an interface for re-assigning or deleting all posts attributed to a | |
| 1161 | + particular author on a particular feed. | |
| 1162 | + | |
| 1163 | +* SUPPORT FOR `<atom:source>` ELEMENT IN SYNDICATED FEEDS: Some feeds | |
| 1164 | + (for example, those produced by FeedWordPress) aggregate content from | |
| 1165 | + several different sources, and include information about the original | |
| 1166 | + source of the post in an `<atom:source>` element. A new setting under | |
| 1167 | + **Syndication --> Options** allows you to control what FeedWordPress | |
| 1168 | + will report as the source of posts syndicated from aggregator feeds in | |
| 1169 | + your templates and feeds: you can have FeedWordPress report that the | |
| 1170 | + source of a post is the aggregator feed itself, or you can have it | |
| 1171 | + report that the source of a post is the original source that the | |
| 1172 | + aggregator originally syndicated the post from. | |
| 1173 | + | |
| 1174 | + By default, FeedWordPress will report the aggregator, not the original | |
| 1175 | + source, as the source of a syndicated item. | |
| 1176 | + | |
| 1177 | +* LOAD BALANCING AND TIME LIMITING FEATURES FOR UPDATES: Some users have | |
| 1178 | + encountered issues due to running up against PHP execution time limits | |
| 1179 | + during the process of updating large syndicated feeds, or a very large | |
| 1180 | + set of syndicated feeds. FeedWordPress now has a feature that allows you | |
| 1181 | + to limit the total amount of time spent updating a feed, through the | |
| 1182 | + "Time limit on updates" setting under **Syndication --> Options**. By | |
| 1183 | + turning on this setting and adjusting the time limit to a low enough | |
| 1184 | + figure to avoid your PHP installation's time-out setting. (PHP execution | |
| 1185 | + time limits are usually in the vicinity of 30 seconds, so an update | |
| 1186 | + time limit of 25 seconds or so should provide plenty of time for updates | |
| 1187 | + while allowing a cushion of time for other, non-update-related functions | |
| 1188 | + to do their work.) | |
| 1189 | + | |
| 1190 | + If feed updates are interrupted by the time limit, FeedWordPress uses | |
| 1191 | + some simple load balancing features to make sure that updates to other | |
| 1192 | + feeds will not be blocked by the time-hogging feed, and will also make | |
| 1193 | + sure that when the interrupted update is resumed, FeedWordPress will | |
| 1194 | + skip ahead to resume processing items at the point at which it was | |
| 1195 | + interrupted last time, so that posts further down in the feed will | |
| 1196 | + eventually get processed, and not get blocked by the amount of time it | |
| 1197 | + takes to process the items higher up in the feed. | |
| 1198 | + | |
| 1199 | +* `guid` INDEX CREATION BUTTON: FeedWordPress frequently issues queries on | |
| 1200 | + the `guid` column of the WordPress posts database (since it uses post | |
| 1201 | + guid URIs to keep track of which posts it has syndicated). In very large | |
| 1202 | + FeedWordPress installations, you can often significantly improve | |
| 1203 | + performance by creating a database index on the `guid` column, but | |
| 1204 | + normally you would need to poke around with MySQL or a tool like | |
| 1205 | + phpMyAdmin to do this. FeedWordPress can now save you the trouble: to | |
| 1206 | + create an index on the `guid` column, just go to | |
| 1207 | + **Syndication --> Options**, and mash the button at the bottom of the | |
| 1208 | + "Back End" section. | |
| 1209 | + | |
| 1210 | += 2008.1101 = | |
| 1211 | + | |
| 1212 | +* INTERFACE BUG THAT PREVENTED ADDING NEW SITES FIXED: The UI reforms in | |
| 1213 | + FWP 2008.1030 unintentionally introduced a bug that prevents clean | |
| 1214 | + installations of FeedWordPress from providing an input box for adding | |
| 1215 | + new feeds to the list of syndicated feeds. This bug has been fixed. | |
| 1216 | + | |
| 1217 | += 2008.1030 = | |
| 1218 | + | |
| 1219 | +* WORDPRESS 2.6 COMPATIBILITY: FeedWordPress should now be compatible with | |
| 1220 | + WordPress 2.6, and should work more or less seamlessly with the new post | |
| 1221 | + revision system. A bug which caused multiple new revisions to be created | |
| 1222 | + for posts on certain feeds, regardless of whether or not the item had | |
| 1223 | + been updated, has been fixed. | |
| 1224 | + | |
| 1225 | +* INTERFACE IMPROVEMENTS: The user interface has been substantially | |
| 1226 | + restyled to fit in better with the visual style of WordPress 2.5 and | |
| 1227 | + 2.6. | |
| 1228 | + | |
| 1229 | +* YOUTUBE BUG FIXED: POSTS SYNDICATED THROUGH AN AUTOMATIC UPDATE ARE NO | |
| 1230 | + LONGER STRIPPED OF `<OBJECT>` TAGS AND CERTAIN OTHER HTML ELEMENTS: Due | |
| 1231 | + to the way that some versions of WordPress process posts that are | |
| 1232 | + inserted into the database when no user is logged in, many users | |
| 1233 | + experienced an issue where YouTube videos and other content using the | |
| 1234 | + HTML `<object>` tag would be stripped out of posts that were syndicated | |
| 1235 | + during an automatic update. (Posts that were syndicated through manual | |
| 1236 | + updates from within the WordPress Dashboard were not affected, because | |
| 1237 | + the issue does not arise when an update is executed under a logged-in | |
| 1238 | + administrator's credentials.) This bug has now been fixed; YouTube | |
| 1239 | + videos and other content using `<object>` tags should now appear | |
| 1240 | + properly in syndicated posts, regardless of the way in which the post | |
| 1241 | + was syndicated. | |
| 1242 | + | |
| 1243 | +* AJAX BUGS FIXED: Bugs which blocked the normal operation of WordPress | |
| 1244 | + 2.5's AJAX interface elements when FeedWordPress was activated have been | |
| 1245 | + fixed. | |
| 1246 | + | |
| 1247 | +* TAG SUPPORT: A couple of features have been introduced to take advantage | |
| 1248 | + of the tagging features in WordPress 2.3.x, 2.5.x, and 2.6.x. Now, when | |
| 1249 | + unfamiliar categories are encountered for posts on a feed, you can | |
| 1250 | + choose for FeedWordPress (1) to drop the category; (2) to drop the | |
| 1251 | + category and to filter out any post that does not match at least one | |
| 1252 | + familiar category; (3) to create a new category with that name, or, | |
| 1253 | + now, you can also have FeedWordPress (4) create a new *tag* with that | |
| 1254 | + name. This option can be set site-wide under Syndication --> Options, | |
| 1255 | + or it can be set on a feed-by-feed basis in a feed's Edit screen. | |
| 1256 | + | |
| 1257 | + In addition, you can now set particular tags to apply to all incoming | |
| 1258 | + syndicated posts, under Syndication --> Options, or you can set tags | |
| 1259 | + to apply to all incoming syndicated posts from a particular feed in that | |
| 1260 | + feed's Edit screen. | |
| 1261 | + | |
| 1262 | +* FORMATTING FILTERS: There is a new option available under Syndication -> | |
| 1263 | + Options which allows users to choose whether or not to expose syndicated | |
| 1264 | + posts to being altered by formatting filters. By default, FeedWordPress | |
| 1265 | + has always protected syndicated posts (which are already in display-ready | |
| 1266 | + HTML when they are syndicated) from being reformatted by formatting | |
| 1267 | + filters. However, this approach means that certain plugins which depend | |
| 1268 | + on formatting filters (for example, to add "Share This" bars or relevant | |
| 1269 | + links to the end of a post) are blocked from working on any syndicated | |
| 1270 | + posts. If you want to use one of these plugins together with | |
| 1271 | + FeedWordPress, you can now do so by changing the "Formatting Filters" | |
| 1272 | + setting from "Protect" to "Expose." | |
| 1273 | + | |
| 1274 | +* `<atom:source>` ELEMENTS NOW INCLUDED IN ATOM FEED: Atom 1.0 provides | |
| 1275 | + a standard method for aggregators to indicate information about the original source of | |
| 1276 | + a syndicated post, using the `<atom:source>` element. FeedWordPress now | |
| 1277 | + introduces standard `<atom:source>` elements including the title, homepage, and | |
| 1278 | + feed URI of the source from which a syndicated post was syndicated. Cf. | |
| 1279 | + <http://www.atomenabled.org/developers/syndication/atom-format-spec.php#element.source> | |
| 1280 | + | |
| 1281 | +* MODULARIZATION OF CODE: The code for different elements of FeedWordPress | |
| 1282 | + has been broken out into several modules for easier inspection, | |
| 1283 | + documentation, and maintenance of the code. | |
| 1284 | + | |
| 1285 | +* VERSIONING SCHEME CHANGED: FeedWordPress's feature set has proven stable | |
| 1286 | + enough that it can now be removed from beta status; a good thing, since | |
| 1287 | + I was very quickly running out of version numbers to use. New releases | |
| 1288 | + of FeedWordPress will have version numbers based on the date of their | |
| 1289 | + release. | |
| 1290 | + | |
| 1291 | += 0.993 = | |
| 1292 | + | |
| 1293 | +* WORDPRESS 2.5.1 COMPATIBILITY: FeedWordPress should now be compatible | |
| 1294 | + with WordPress 2.5.1. | |
| 1295 | + | |
| 1296 | +* WORDPRESS 2.5 INTERFACE IMPROVEMENTS: FeedWordPress's Dashboard | |
| 1297 | + interface has undergone several cosmetic changes that should help it | |
| 1298 | + integrate better with the WordPress Dashboard interface in WordPress | |
| 1299 | + version 2.5.x. | |
| 1300 | + | |
| 1301 | +* SYNDICATED POSTS CAN BE MARKED AS "PENDING REVIEW": WordPress 2.3 users | |
| 1302 | + can now take advantage of WordPress's new "Pending Review" features for | |
| 1303 | + incoming syndicated posts. Posts marked as "Pending Review" are not | |
| 1304 | + published immediately, but are marked as ready to be reviewed by an | |
| 1305 | + Administrator or Editor, who can then choose to publish the post or | |
| 1306 | + hold it back. If you want to review syndicated posts from a particular | |
| 1307 | + feed, or from all feeds, before they are posted, then use | |
| 1308 | + Syndication --> Syndicated Sites --> Edit or Syndication --> Options to | |
| 1309 | + change the settings for handling new posts. | |
| 1310 | + | |
| 1311 | +* AWARE OF NEW URI FOR del.icio.us FEEDS: Previous releases of | |
| 1312 | + FeedWordPress already automatically split del.icio.us tags up | |
| 1313 | + appropriately appropriately when generating categories. (del.icio.us | |
| 1314 | + feeds smoosh all the tags into a single `<dc:subject>` element, | |
| 1315 | + separated by spaces; FeedWordPress un-smooshes them into multiple | |
| 1316 | + categories by separating them at whitespace.) Unfortunately, del.icio.us | |
| 1317 | + recently broke the existing behavior by changing host names for their | |
| 1318 | + feeds from del.icio.us to feeds.delicious.com. Version 0.993 accounts | |
| 1319 | + for the new host name and un-breaks the tag splitting. | |
| 1320 | + | |
| 1321 | += 0.992 = | |
| 1322 | + | |
| 1323 | +* AUTHOR RE-MAPPING: FeedWordPress now offers considerable control over | |
| 1324 | + how author names on a feed are translated into usernames within the | |
| 1325 | + WordPress database. When a post by an unrecognized author comes in, | |
| 1326 | + Administrators can now specify any username as the default username to | |
| 1327 | + assign the post to by setting the option in Syndication --> Options | |
| 1328 | + (formerly FeedWordPress only allowed you to assign such posts to user | |
| 1329 | + #1, the site administrator). Administrators can also create re-mapping | |
| 1330 | + rules for particular feeds (under Syndication --> Syndicated Sites --> | |
| 1331 | + Edit), so that (for example) any posts attributed to "Administrator" | |
| 1332 | + on the feed <http://praxeology.net/blog/feed/> will be assigned to | |
| 1333 | + a user named "Roderick T. Long," rather than a user named | |
| 1334 | + "Administrator." These settings also allow administrators to filter out | |
| 1335 | + posts by particular users, and to control what will happen when | |
| 1336 | + FeedWordPress encounters a post by an unrecognized user on that | |
| 1337 | + particular feed. | |
| 1338 | + | |
| 1339 | +* BUG RELATED TO URIS CONTAINING AMPERSAND CHARACTERS FIXED: A bug in | |
| 1340 | + WordPress 2.x's handling of URIs in Blogroll links created problems for | |
| 1341 | + updating any feeds whose URIs included an ampersand character, such as | |
| 1342 | + Google News RSS feeds and other feeds that have multiple parameters | |
| 1343 | + passed through HTTP GET. If you experienced this bug, the most likely | |
| 1344 | + effect was that FeedWordPress simply would not import new posts from a | |
| 1345 | + feed when instructred to do so, returning a "0 new posts" response. In | |
| 1346 | + other cases, it might lead to unpredictable results from feed updates, | |
| 1347 | + such as importing posts which were not contained in the feed being | |
| 1348 | + syndicated, but which did appear elsewhere on the same website. This bug | |
| 1349 | + has, hopefully, been resolved, by correcting for the bug in WordPress. | |
| 1350 | + | |
| 1351 | += 0.991 = | |
| 1352 | + | |
| 1353 | +* WORDPRESS MU COMPATIBILITY: FeedWordPress should now be compatible with | |
| 1354 | + recent releases of WordPress MU. Once FeedWordPress is made available | |
| 1355 | + as a plugin, each individual blog can choose to activate FeedWordPress | |
| 1356 | + and syndicate content from its own set of contributors. | |
| 1357 | + | |
| 1358 | +* DISPLAY OF MAGPIE WARNINGS: A number of MagpieRSS warnings or error | |
| 1359 | + messages that were displayed when performing an automatic update are | |
| 1360 | + no longer displayed, unless debugging parameters have been explicitly | |
| 1361 | + enabled. | |
| 1362 | + | |
| 1363 | +* BUG RELATED TO INTERNATIONAL CHARACTERS IN AUTHOR NAMES FIXED: Due to a | |
| 1364 | + subtle incompatability between the way that FeedWordPress generated new | |
| 1365 | + user information, and the way that WordPress 2.0 and later added new | |
| 1366 | + authors to the database, FeedWordPress might end up creating duplicate | |
| 1367 | + authors, or throwing a critical error message, when it encountered | |
| 1368 | + authors whose names included international characters. This | |
| 1369 | + incompatability has now been fixed; hopefully, authors with | |
| 1370 | + international characters in their names should now be handled properly. | |
| 1371 | + | |
| 1372 | +* `<media:content>` BUG IN MAGPIERSS FIXED: A bug in MagpieRSS's handling | |
| 1373 | + of namespaced elements has been fixed. Among other things, this bug | |
| 1374 | + caused items containing a Yahoo MediaRSS `<media:content>` element (such | |
| 1375 | + as many of the feeds produced by wordpress.com) to be represented | |
| 1376 | + incorrectly, with only a capital "A" where the content of the post | |
| 1377 | + should have been. Feeds containing `<media:content>` elements should now | |
| 1378 | + be syndicated correctly. | |
| 1379 | + | |
| 1380 | +* update_feedwordpress PARAMETER: You can now use an HTTP GET parameter | |
| 1381 | + (`update_feedwordpress=1`) to request that FeedWordPress poll its feeds | |
| 1382 | + for updates. When used together with a crontab or other means of | |
| 1383 | + scheduling tasks, this means that you can keep your blog automatically | |
| 1384 | + updated on a regular schedule, even if you do not choose to use the | |
| 1385 | + cron-less automatic updates option. | |
| 1386 | + | |
| 1387 | +* Some minor interface-related bugs were also fixed. | |
| 1388 | + | |
| 1389 | + | |
| 1390 | += 0.99 = | |
| 1391 | + | |
| 1392 | +Version 0.99 adds several significant new features, fixes some bugs, and | |
| 1393 | +provides compatability with WordPress 2.2.x and 2.3.x. | |
| 1394 | + | |
| 1395 | +* WORDPRESS 2.2 AND 2.3 COMPATIBILITY: FeedWordPress should now be | |
| 1396 | + compatible with WordPress version 2.2 and the upcoming WordPress | |
| 1397 | + version 2.3. In particular, it has been tested extensively against | |
| 1398 | + WordPress 2.2.3 and WordPress 2.3 Release Candidate 1. | |
| 1399 | + | |
| 1400 | +* AUTOMATIC UPDATES WITHOUT CRON: FeedWordPress now allows you to | |
| 1401 | + automatically schedule checks for new posts without using external task | |
| 1402 | + scheduling tools such as cron. In order to enable automatic updates, go | |
| 1403 | + to **Syndication --> Options** and set "Check for new posts" to | |
| 1404 | + "automatically." For details, see "Automatic Feed Updates" in | |
| 1405 | + README.text. | |
| 1406 | + | |
| 1407 | + An important side-effect of the changes to the update system is that if | |
| 1408 | + you were previously using the cron job and the `update-feeds.php` script | |
| 1409 | + to schedule updates, you need to change your cron set-up. The old | |
| 1410 | + `update-feeds.php` script no longer exists. Instead, if you wish to use | |
| 1411 | + a cron job to guarantee updates on a particular schedule, you should | |
| 1412 | + have the cron job fetch the front page of your blog (for example, by | |
| 1413 | + using `curl http://www.zyx.com/blog/ > /dev/null`) instead of activating | |
| 1414 | + the `update-feeds.php` script. If automatic updates have been enabled, | |
| 1415 | + fetching the front page will automatically trigger the update process. | |
| 1416 | + | |
| 1417 | +* INTERFACE REORGANIZATION: All FeedWordPress functions are now located | |
| 1418 | + under a top-level "Syndication" menu in the WordPress Dashboard. To | |
| 1419 | + manage the list of syndicated sites, manually check for new posts on | |
| 1420 | + one or more feeds, or syndicate a new site, you should use the main page | |
| 1421 | + under **Syndication**. To change global settings for FeedWordPress, | |
| 1422 | + you should use **Syndication --> Options**. | |
| 1423 | + | |
| 1424 | +* FILE STRUCTURE REORGANIZATION: Due to a combination of changing styles | |
| 1425 | + for FeedWordPress plugins and lingering bugs in the FeedWordPress admin | |
| 1426 | + menu code, the code for FeedWordPress is now contained in two different | |
| 1427 | + PHP files, which should be installed together in a subdirectory of your | |
| 1428 | + plugins directory named `feedwordpress`. (See README.text for | |
| 1429 | + installation and upgrade instructions relating to the change.) | |
| 1430 | + | |
| 1431 | +* MULTIPLE CATEGORIES SETTING: Some feeds use non-standard methods to | |
| 1432 | + indicate multiple categories within a single category element. (The most | |
| 1433 | + popular site to do this is del.icio.us, which separates tags with a | |
| 1434 | + space.) FeedWordPress now allows you to set an optional setting, for any | |
| 1435 | + feed which does this, indicating the character or characters used to | |
| 1436 | + divide multiple categories, using a Perl-compatible regular expression. | |
| 1437 | + (In the case of del.icio.us feeds, FeedWordPress will automatically use | |
| 1438 | + \s for the pattern without your having to do any further configuration.) | |
| 1439 | + To turn this setting on, simply use the "Edit" link for the feed that | |
| 1440 | + you want to turn it on for. | |
| 1441 | + | |
| 1442 | +* REGULAR EXPRESSION BUG FIXED: Eliminated a minor bug in the regular | |
| 1443 | + expressions for e-mail addresses (used in parsing RSS `author` | |
| 1444 | + elements), which could produce unsightly error messages for some users | |
| 1445 | + parsing RSS 2.0 feeds. | |
| 1446 | + | |
| 1447 | +* DATE / UPDATE BUG FIXED: A bug in date handling was eliminated that may | |
| 1448 | + have caused problems if any of (1) WordPress, or (2) PHP, or (3) your | |
| 1449 | + web server, or (4) your MySQL server, has been set to use a different | |
| 1450 | + time zone from the one that any of the others is set to use. If | |
| 1451 | + FeedWordPress has not been properly updating updated posts, or has been | |
| 1452 | + updating posts when there shouldn't be any changes for the update, this | |
| 1453 | + release may solve that problem. | |
| 1454 | + | |
| 1455 | +* GOOGLE READER BUGS FIXED: A couple of bugs that made it difficult for | |
| 1456 | + FeedWordPress to interact with Google Reader public feeds have been | |
| 1457 | + fixed. Firstly, if you encountered an error message reading "There was a | |
| 1458 | + problem adding the newsfeed. [SQL: ]" when you tried to add the feed, | |
| 1459 | + the cause of this error has been fixed. Secondly, if you succeeded in | |
| 1460 | + getting FeedWordPress to check a Google Reader feed, only to find that | |
| 1461 | + the title of posts had junk squashed on to the end of them, that bug | |
| 1462 | + has been fixed too. To fix this bug, you must install the newest version | |
| 1463 | + of the optional MagpieRSS upgrade. | |
| 1464 | + | |
| 1465 | +* FILTER PARAMETERS: Due to an old, old bug in WordPress 1.5.0 (which was | |
| 1466 | + what was available back when I first wrote the filter interface), | |
| 1467 | + FeedWordPress has traditionally only passed one parameter to | |
| 1468 | + syndicated_item and syndicated_post filters functions -- an array | |
| 1469 | + containing either the Magpie representation of a syndicated item from | |
| 1470 | + the feed, or the database representation of a post about to be inserted | |
| 1471 | + into the WordPress database. If you needed information about the feed | |
| 1472 | + that the item came from, this was accessible only through a pair of | |
| 1473 | + global variables, $fwp_channel and $fwp_feedmeta. | |
| 1474 | + | |
| 1475 | + Since it's been a pretty long time since WordPress 1.5.0 was in | |
| 1476 | + widespread usage, I have gone ahead and added an optional second | |
| 1477 | + parameter to the invocation of the syndicated_item and syndicated_post | |
| 1478 | + filters. If you have written a filter for FeedWordPress that uses either | |
| 1479 | + of these hooks, you can now register that filter to accept 2 parameters. | |
| 1480 | + If you do so, the second parameter will be a SyndicatedPost object, | |
| 1481 | + which, among other things, allows you to access information about the | |
| 1482 | + feed from which an item is syndicated using the $post->feed and the | |
| 1483 | + $post->feedmeta elements (where $post is the name of the second | |
| 1484 | + parameter). | |
| 1485 | + | |
| 1486 | + NOTE THAT THE OLD GLOBAL VARIABLES ARE STILL AVAILABLE, for the time | |
| 1487 | + being at least, so existing filters will not break with the upgrade. | |
| 1488 | + They should be considered deprecated, however, and may be eliminated in | |
| 1489 | + the future. | |
| 1490 | + | |
| 1491 | +* FILTER CHANGE / BUGFIX: the array that is passed as the first argument | |
| 1492 | + syndicated_post filters no longer is no longer backslash-escaped for | |
| 1493 | + MySQL when filters are called. This was originally a bug, or an | |
| 1494 | + oversight; the contents of the array should only be escaped for the | |
| 1495 | + database *after* they have gone through all filters. IF YOU HAVE WRITTEN | |
| 1496 | + ANY syndicated_post FILTERS THAT PRESUME THE OLD BEHAVIOR OF PASSING IN | |
| 1497 | + STRINGS THAT ARE ALREADY BACKSLASH-ESCAPED, UPDATE YOUR FILTERS | |
| 1498 | + ACCORDINGLY. | |
| 1499 | + | |
| 1500 | +* OTHER MINOR BUGFIXES AND INTERNAL CHANGES: The internal architecture of | |
| 1501 | + FeedWordPress has been significantly changed to make the code more | |
| 1502 | + modular and clean; hopefully this should help reduce the number of | |
| 1503 | + compatibility updates that are needed, and make them easier and quicker | |
| 1504 | + when they are needed. | |
| 1505 | + | |
| 1506 | += 0.981 = | |
| 1507 | + | |
| 1508 | +Version 0.981 is a narrowly targeted bugfix and compatibility release, whose | |
| 1509 | +main purpose is to resolve a major outstanding problem: the incompatibility | |
| 1510 | +between version 0.98 of WordPress and the recently released WordPress 2.1. | |
| 1511 | + | |
| 1512 | +* WORDPRESS 2.1 COMPATIBILITY: FeedWordPress is now compatible with | |
| 1513 | + WordPress 2.1, as well as retaining its existing support for WordPress | |
| 1514 | + 2.0 and 1.5. Incompatibilities that resulted in database warnings, fatal | |
| 1515 | + errors, and which prevented FeedWordPress from syndicating new posts, | |
| 1516 | + have been eliminated. | |
| 1517 | + | |
| 1518 | +* RSS-FUNCTIONS.PHP RENAMED TO RSS.PHP: if you use the upgraded MagpieRSS | |
| 1519 | + replacement that's included with FeedWordPress, be sure to note that | |
| 1520 | + there are now *two* files to upload from the `OPTIONAL/wp-includes` | |
| 1521 | + subdirectory in order to carry out the upgrade: rss-functions.php and | |
| 1522 | + rss.php. **It is necessary to upload both files**, due to a change in | |
| 1523 | + the file naming scheme in WordPress 2.1, and it is necessary to do so | |
| 1524 | + whether you are using WordPress 2.1 or not. If you only upload the | |
| 1525 | + `rss-functions.php` file as in previous installations you will not have | |
| 1526 | + a working copy of MagpieRSS; the rss.php file contains the actual code. | |
| 1527 | + | |
| 1528 | +* DATE BUG AFFECTING SOME PHP INSTALLATIONS RESOLVED: due to a subtle bug | |
| 1529 | + in parse_w3cdtf(), some installations of PHP encountered problems with | |
| 1530 | + FeedWordPress's attempt to date posts, which would cause some new posts | |
| 1531 | + on Atom feeds to be dated as if they had apppeared in 1969 or 1970 | |
| 1532 | + (thus, effectively, never appearing on front page at all). This bug in | |
| 1533 | + the date handling should now be fixed. | |
| 1534 | + | |
| 1535 | +* PHP <?=...?> SHORT FORM ELIMINATED: some installations of PHP do not | |
| 1536 | + allow the <?=...?> short form for printing PHP values, which was used | |
| 1537 | + extensively in the FeedWordPress interface code. Since this could cause | |
| 1538 | + fatal errors for users with the wrong installation of PHP, the short | |
| 1539 | + form has been replaced with full PHP echo statements, and is no longer | |
| 1540 | + used in FeedWordPress. | |
| 1541 | + | |
| 1542 | +* BETTER USER INTERFACE INTEGRATION WITH WORDPRESS 2.x: Some minor changes | |
| 1543 | + have been made to help the FeedWordPress interface pages blend in better | |
| 1544 | + with the user interface when running under WordPress 2.x. | |
| 1545 | + | |
| 1546 | +* GLOBAL CATEGORIES BUG RESOLVED: a bug that prevented some users from | |
| 1547 | + setting one or more categories to apply to syndicated posts from all | |
| 1548 | + feeds (using the checkbox interface under Options --> Syndication) has | |
| 1549 | + been resolved. | |
| 1550 | + | |
| 1551 | += 0.98 = | |
| 1552 | + | |
| 1553 | +* WORDPRESS 2.0 COMPATIBILITY: This is a narrowly-targeted release to | |
| 1554 | + solve a major outstanding problem. FeedWordPress is now compatible with | |
| 1555 | + both WordPress 1.5 and WordPress 2.0. Incompatibilities that caused | |
| 1556 | + fatal SQL errors, and a more subtle bug with off-kilter counts of posts | |
| 1557 | + under a given category, have been resolved. FeedWordPress tests for | |
| 1558 | + database schema using the global $wp_db_version variable (if null, then | |
| 1559 | + we presume that we're dealing with WordPress 1.5). | |
| 1560 | + | |
| 1561 | + NOTE: I have **not** fully tested FeedWordPress with WordPress 2.0. | |
| 1562 | + Further testing may reveal more bugs. However, you should now be able | |
| 1563 | + to get at least basic FeedWordPress functionality up and running. | |
| 1564 | + | |
| 1565 | +* AUTHOR MATCHING: FeedWordPress tests several fields to see if it can | |
| 1566 | + identify the author of the post as a user already in the WordPress user | |
| 1567 | + database. In previous versions, it tested the user login, the nickname, | |
| 1568 | + and tested for "aliases" listed in the Profile (see documentation). FWP | |
| 1569 | + now also matches authors on the basis of e-mail address (*if* an e-mail | |
| 1570 | + address is present). This is particularly helpful for formats such as | |
| 1571 | + RSS 2.0, in which authors are primarily identified by e-mail addresses. | |
| 1572 | + | |
| 1573 | += 0.97 = | |
| 1574 | + | |
| 1575 | +* INSTALLATION PROCEDURE: Some of the changes between 0.96 and 0.97 | |
| 1576 | + require upgrades to the meta-data stored by FeedWordPress to work | |
| 1577 | + properly. Thus, if you are upgrading from 0.96 or earlier to 0.97, most | |
| 1578 | + FeedWordPress operations (including updates and template functions) | |
| 1579 | + WILL BE DISABLED until you run the upgrade procedure. Fortunately, | |
| 1580 | + running the upgrade procedure is easy: just go to either Options --> | |
| 1581 | + Syndication or Links --> Syndicated in the WordPress Dashboard and press | |
| 1582 | + the button. | |
| 1583 | + | |
| 1584 | +* FEED FORMAT SUPPORT: Support has been added for the Atom 1.0 IETF | |
| 1585 | + standard. Several other elements are also newly supported | |
| 1586 | + (dcterms:created, dcterms:issued, dcterms:modified, dc:identifier, | |
| 1587 | + proper support for the RSS 2.0 guid element, the RSS 2.0 author element, | |
| 1588 | + the use of Atom author or Dublin Core dc:creator constructs at the feed | |
| 1589 | + level to identify the author of individual items, etc.) | |
| 1590 | + | |
| 1591 | + N.B.: full support of several Atom 1.0 features, such as categories | |
| 1592 | + and enclosures, requires you to install the optional rss-functions.php | |
| 1593 | + upgrade in your wp-includes directory. | |
| 1594 | + | |
| 1595 | +* BUG FIX: Running `update-feeds.php` from command line or crontab | |
| 1596 | + returned "I don't syndicate..." errors. It turns out that WordPress | |
| 1597 | + sometimes tramples on the internal PHP superglobals that I depended on | |
| 1598 | + to determine whether or not the script was being invoked from the | |
| 1599 | + command line. This has been fixed (the variables are now checked | |
| 1600 | + *before* WordPress can trample them). Note that `update-feeds.php` has | |
| 1601 | + been thoroughly overhauled anyway; see below for details. | |
| 1602 | + | |
| 1603 | +* BUG FIX: Duplicate categories or author names. Fixed two bugs that could | |
| 1604 | + create duplicate author and/or category names when the name contained | |
| 1605 | + either (a) certain international characters (causing a mismatch between | |
| 1606 | + MySQL and PHP's handling of lowercasing text), or (b) characters that | |
| 1607 | + have a special meaning in regular expressions (causing MySQL errors when | |
| 1608 | + looking for the author or category due to regexp syntax errors). These | |
| 1609 | + should now be fixed thanks to careful escaping of names that go into | |
| 1610 | + regular expressions and careful matching of lowercasing functions | |
| 1611 | + (comparing results from PHP only to other results from PHP, and results | |
| 1612 | + from MySQL only to other results from MySQL). | |
| 1613 | + | |
| 1614 | +* BUG FIX: Items dated December 31, 1969 should appear less often. The | |
| 1615 | + function for parsing W3C date-time format dates that ships with | |
| 1616 | + MagpieRSS can only correctly parse fully-specified dates with a | |
| 1617 | + fully-specified time, but valid W3C date-time format dates may omit the | |
| 1618 | + time, the day of the month, or even the month. Some feeds in the wild | |
| 1619 | + date their items with coarse-grained dates, so the optional | |
| 1620 | + `rss-functions.php` upgrade now includes a more flexible parse_w3cdtf() | |
| 1621 | + function that will work with both coarse-grained and fully-specified | |
| 1622 | + dates. (If parts of the date or the time are omitted, they are filled in | |
| 1623 | + with values based on the current time, so '2005-09-10' will be dated to | |
| 1624 | + the current time on that day; '2004' will be dated to this day and time | |
| 1625 | + one year ago. | |
| 1626 | + | |
| 1627 | + N.B.: This fix is only available in the optional `rss-functions.php` | |
| 1628 | + upgrade. | |
| 1629 | + | |
| 1630 | +* BUG FIX: Evil use of HTTP GET has been undone. The WordPress interface | |
| 1631 | + is riddled with inappropriate (non-idempotent) uses of HTTP GET queries | |
| 1632 | + (ordinary links that make the server do something with significant | |
| 1633 | + side-effects, such as deleting a post or a link from the database). | |
| 1634 | + FeedWordPress did some of this too, especially in places where it aped | |
| 1635 | + the WordPress interface (e.g. the "Delete" links in Links --> | |
| 1636 | + Syndicated). That's bad business, though. I've changed the interface so | |
| 1637 | + that all the examples of improper side-effects that I can find now | |
| 1638 | + require an HTTP POST to take effect. I think I got pretty much | |
| 1639 | + everything; if there's anything that I missed, let me know. | |
| 1640 | + | |
| 1641 | + Further reading: [Sam Ruby 2005-05-06: This Stuff Matters](http://www.intertwingly.net/blog/2005/05/06/This-Stuff-Matters) | |
| 1642 | + | |
| 1643 | +* BUG FIX: Categories applied by `cats` setting should no longer prevent | |
| 1644 | + category-based filtering from working. In FeedWordPress, you can (1) | |
| 1645 | + apply certain categories to all syndicated posts, or all posts from | |
| 1646 | + a particular feed; and (2) filter out all posts that don't match one | |
| 1647 | + of the categories that are already in the WordPress database (allowing | |
| 1648 | + for simple category-based filtering; just load up WordPress with the | |
| 1649 | + categories you want to accept, and then tell FeedWordPress not to create | |
| 1650 | + new ones). However, the way that (1) and (2) were implemented meant that | |
| 1651 | + you couldn't effectively use them together; once you applied a known | |
| 1652 | + category to all syndicated posts from a particular feed, it meant that | |
| 1653 | + they'd have at least one familiar category (the category or categories | |
| 1654 | + you were applying), and that would get all posts past the filter no | |
| 1655 | + matter what categories they were originally from. | |
| 1656 | + | |
| 1657 | + Well, no longer. You can still apply categories to all syndicated posts | |
| 1658 | + (using either Syndication --> Options, or the feed-level settings under | |
| 1659 | + Links --> Syndicated). But these categories are not applied to the post | |
| 1660 | + until *after* it has already passed by the "familiar categories" filter. | |
| 1661 | + So now, if you want, you can do category filtering and *then* apply as | |
| 1662 | + many categories as you please to all and only posts that pass the filter. | |
| 1663 | + | |
| 1664 | +* BUG FIX: Other minor typos and HTML gaffes were fixed along the way. | |
| 1665 | + | |
| 1666 | +* PERFORMANCE: get_feed_meta() no longer hits the database for information | |
| 1667 | + on every call; it now caches link data in memory, so FeedWordPress only | |
| 1668 | + goes to the database once for each syndicated link. This may | |
| 1669 | + substantially improve performance if your database server resources | |
| 1670 | + are tight and your templates make a lot of use of custom settings from | |
| 1671 | + get_feed_meta(). | |
| 1672 | + | |
| 1673 | +* API CHANGE: Link ID numbers, rather than RSS URIs, are now used to | |
| 1674 | + identify the feed from which a post is syndicated when you use template | |
| 1675 | + functions such as get_feed_meta(). The practical upshot of this is you | |
| 1676 | + can switch feeds, or change the feed address for a particular syndicated | |
| 1677 | + site, without breaking your templates for all the posts that were | |
| 1678 | + syndicated from the earlier URI. | |
| 1679 | + | |
| 1680 | +* API CHANGE: if you have plugins or templates that make use of the | |
| 1681 | + get_feed_meta() function or the $fwp_feedmeta global, note that the | |
| 1682 | + data formerly located under the `uri` and `name` fields is now located | |
| 1683 | + under the `link/uri` field and the `link/name` field, respectively. Note | |
| 1684 | + also that you can access the link ID number for any given feed under the | |
| 1685 | + global $fwp_feedmeta['link/id'] (in plugins) or | |
| 1686 | + get_feed_meta('link/id') (in a template in post contexts). | |
| 1687 | + | |
| 1688 | +* FEATURE: the settings for individual feeds can now be edited using a | |
| 1689 | + humane interface (where formerly you had to tweak key-value pairs in the | |
| 1690 | + Link Notes section). To edit settings for a feed, pick the feed that you | |
| 1691 | + want under Links --> Syndicated and click the Edit link. | |
| 1692 | + | |
| 1693 | +* FEATURE: The "Unsubscribe" button (formerly "Delete") in Links --> | |
| 1694 | + Syndicated now offers three options for unsubscribing from a feed: (1) | |
| 1695 | + turning off the subscription without deleting the feed data or affecting | |
| 1696 | + posts that were syndicated from the feed (this works by setting the Link | |
| 1697 | + for the feed as "invisible"); (2) deleting the feed data and all of the | |
| 1698 | + posts that were syndicated from the feed; or (3) deleting the feed data | |
| 1699 | + and *keeping* the posts that were syndicated from the feed | |
| 1700 | + setting the Link to "Invisible" (meaning that it will not be displayed | |
| 1701 | + in lists of the site links on the front page, and it won't be checked | |
| 1702 | + for updates; (2) deleting the Link and all of the posts that were | |
| 1703 | + syndicated from its feed; or (3) deleting the feed data but keeping the | |
| 1704 | + posts that were syndicated (which will henceforward be treated as if | |
| 1705 | + they were local rather than syndicated posts). (Note that (1) is usually | |
| 1706 | + the best option for aggregator sites, unless you want to clean up the | |
| 1707 | + results of an error or a test.) | |
| 1708 | + | |
| 1709 | +* FEATURE / BUG FIX: If you have been receiving mysterious "I don't | |
| 1710 | + syndicate...", or "(local) HTTP status code was not 200", or "(local) | |
| 1711 | + transport error - could not open socket", or "parse error - not well | |
| 1712 | + formed" errors, then this update may solve your problems, and if it does | |
| 1713 | + *not* solve them, it will at least make the reasons for the problems | |
| 1714 | + easier to understand. That's because I've overhauled the way that | |
| 1715 | + FeedWordPress goes about updating feeds. | |
| 1716 | + | |
| 1717 | + If you use the command-line PHP scripting method to run scheduled | |
| 1718 | + updates, then not much should change for you, except for fewer | |
| 1719 | + mysterious errors. If you have done updates by sending periodic HTTP | |
| 1720 | + requests to <http://your-blog.com/path/wp-content/update-feeds.php>, | |
| 1721 | + then the details have changed somewhat; mostly in such a way as to make | |
| 1722 | + things easier on you. See the README file or online documentation on | |
| 1723 | + Staying Current for the details. | |
| 1724 | + | |
| 1725 | +* FEATURE: FeedWordPress now features a more sophisticated system for | |
| 1726 | + timed updates. Instead of polling *every* subscribed feed for updates | |
| 1727 | + *each* time `update-feeds.php` is run, FeedWordPress now keeps track of | |
| 1728 | + the last time it polled each feed, and only polls them again after a | |
| 1729 | + certain period of time has passed. The amount of time is normally set | |
| 1730 | + randomly for each feed, in a period between 30 minutes and 2 hours (so | |
| 1731 | + 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 | |
| 1732 | + directly by the feed, which brings us to ... | |
| 1733 | + | |
| 1734 | +* FEATURE: FeedWordPress now respects the settings in the `ttl` and | |
| 1735 | + Syndication Module RSS elements. Feeds with these elements set will not | |
| 1736 | + be polled any more frequently than they indicate with these feeds unless | |
| 1737 | + the user manually forces FeedWordPress to poll the feed (see Links --> | |
| 1738 | + Syndicated --> Edit settings). | |
| 1739 | + | |
| 1740 | += 0.96 = | |
| 1741 | + | |
| 1742 | +* FEATURE: support has been added for enclosures in RSS 2.0 and Atom | |
| 1743 | + 0.6+ newsfeeds. WordPress already supports adding enclosures to an | |
| 1744 | + item; FeedWordPress merely gets the information on the enclosure | |
| 1745 | + from the feed it is syndicating and plugs that information directly | |
| 1746 | + into the WordPress database so that (among other things) that post | |
| 1747 | + will have its enclosure listed in your blog's RSS 2 newsfeed. | |
| 1748 | + | |
| 1749 | + Note that enclosure support requires using the optional MagpieRSS | |
| 1750 | + upgrade (i.e., replacing your `wp-includes/rss-functions.php` with | |
| 1751 | + `OPTIONAL/wp-includes/rss-functions.php` from the FWP archive) | |
| 1752 | + | |
| 1753 | +* FEATURE: for completeness's sake, there is now a feed setting, | |
| 1754 | + `hardcode url`, that allows you to set the URI for the front page | |
| 1755 | + of a contributor's website manually (that is, prevent it from being | |
| 1756 | + automatically updated from the feed channel link on each update). To | |
| 1757 | + set the URI manually, put a line like this in the Link Notes section | |
| 1758 | + of a feed: | |
| 1759 | + | |
| 1760 | + hardcode url: yes | |
| 1761 | + | |
| 1762 | + You can also instruct FeedWordPress to use hardcoded URIs by default | |
| 1763 | + on all feeds using Options --> Syndication | |
| 1764 | + | |
| 1765 | +* FEATURE: by default, when FeedWordPress finds new syndicated posts, | |
| 1766 | + it (1) publishes them immediately, (2) turns comments off, and (3) | |
| 1767 | + turns trackback / pingback pings off. You can now alter all three | |
| 1768 | + default behaviors (e.g., to allow pings on syndicated posts, or to | |
| 1769 | + send newly-syndicated posts to the draft pile for moderation) using | |
| 1770 | + Options --> Syndication | |
| 1771 | + | |
| 1772 | + | |
| 1773 | += From 0.91 to 0.95 = | |
| 1774 | + | |
| 1775 | +* BUG FIX: Fixed an obscure bug in the handling of categories: | |
| 1776 | + categories with trailing whitespace could cause categories with | |
| 1777 | + duplicate names to be created. This no longer happens. While I was | |
| 1778 | + at it I tightened up the operation of | |
| 1779 | + FeedWordPress::lookup_categories() a bit in general. | |
| 1780 | + | |
| 1781 | +* FEATURE DEPRECATED: the feed setting `hardcode categories` is now | |
| 1782 | + deprecated in favor of `unknown categories` (see below), which | |
| 1783 | + allows you to strip off any syndication categories not already in | |
| 1784 | + your database using `unknown categories: default` or `unknown | |
| 1785 | + categories: filter`. If you have `hardcode categories: yes` set on a | |
| 1786 | + feed, this will be treated as `unknown categories: default` (i.e., | |
| 1787 | + no new categories will be added, but if a post doesn't match any of | |
| 1788 | + the categories it will be added in the default category--usually | |
| 1789 | + "Uncategorized" or "General"). | |
| 1790 | + | |
| 1791 | +* FEATURE: You can now set global defaults as to whether or not | |
| 1792 | + FeedWordPress will update the Link Name and Link Description | |
| 1793 | + settings for feeds automatically from the feed title and feed | |
| 1794 | + tagline. (By default, it does, as it has in past versions.) Whether | |
| 1795 | + this behavior is turned on or off, you can still override the | |
| 1796 | + default behavior using feed settings of `hardcode name: yes`, | |
| 1797 | + `hardcode name: no`, `hardcode description: yes`, or `hardcode | |
| 1798 | + description: no`. | |
| 1799 | + | |
| 1800 | +* FEATURE: Users can now provide one or several "aliases" for an | |
| 1801 | + author, just as they can for a category. For example, to make | |
| 1802 | + FeedWordPress treat posts by "Joseph Cardinal Ratzinger" and "Pope | |
| 1803 | + Benedict XVI" as by the same author, edit the user profile for Pope | |
| 1804 | + Benedict XVI and add a line like this to the "User profile" field: | |
| 1805 | + | |
| 1806 | + a.k.a.: Joseph Cardinal Ratzinger | |
| 1807 | + | |
| 1808 | + You can add several aliases, each on a line by itself. You can also | |
| 1809 | + add any other text you like to the Profile without interfering with | |
| 1810 | + the aliases. | |
| 1811 | + | |
| 1812 | +* FEATURE: Users can now choose how to handle syndicated posts that | |
| 1813 | + are in unfamiliar categories or by unfamiliar authors (i.e., | |
| 1814 | + categories or authors whose names are not yet in the WordPress | |
| 1815 | + database). By default, FeedWordPress will (as before) create a new | |
| 1816 | + category (or new author) and use it for the current post and any | |
| 1817 | + future posts. This behavior can be changed, either for all feeds or | |
| 1818 | + for one or another particular feed. | |
| 1819 | + | |
| 1820 | + There are now three different options for an unfamiliar author: (1) | |
| 1821 | + FeedWordPress can create a new author account and attribute the | |
| 1822 | + syndicated post to the new account; (2) FeedWordPress can attribute | |
| 1823 | + the post to an author if the author's name is familiar, and to a | |
| 1824 | + default author (currently, this means the Site Administrator | |
| 1825 | + account) if it is not; (3) FeedWordPress can drop posts by | |
| 1826 | + unfamiliar authors and syndicate only posts by authors who are | |
| 1827 | + already in the database. | |
| 1828 | + | |
| 1829 | + There are, similarly, two different options for an unfamiliar | |
| 1830 | + category: (1) FeedWordPress can create new categories and place the | |
| 1831 | + syndicated post in them; (2) FeedWordPress can drop the unfamiliar | |
| 1832 | + categories and place syndicated posts only in categories that it is | |
| 1833 | + already familiar with. In addition, FeedWordPress 0.95 lets you | |
| 1834 | + choose whether posts that are in *no* familiar categories should be | |
| 1835 | + syndicated (and placed in the default category for the blog) or | |
| 1836 | + simply dropped. | |
| 1837 | + | |
| 1838 | + You can set the default behavior for both authors and categories | |
| 1839 | + using the settings in Options --> Syndication. You can also set | |
| 1840 | + different behavior for specific feeds by adding the `unfamiliar | |
| 1841 | + author` and / or `unfamiliar categories` settings to the Link Notes | |
| 1842 | + section of a feed: | |
| 1843 | + | |
| 1844 | + unfamiliar author: (create|default|filter) | |
| 1845 | + unfamiliar categories: (create|default|filter) | |
| 1846 | + | |
| 1847 | + A setting of `unfamiliar author: create` will make FeedWordPress | |
| 1848 | + create new authors to match unfamiliar author names *for this feed | |
| 1849 | + alone*. A setting of `unfamiliar author: default` will make it | |
| 1850 | + assign posts from unfamiliar authors to the default user account. A | |
| 1851 | + setting of `unfamiliar author: filter` will cause all posts (from | |
| 1852 | + this feed alone) to be dropped unless they are by an author already | |
| 1853 | + listed in the database. Similiarly, `unfamiliar categories: create` | |
| 1854 | + will make FeedWordPress create new categories to match unfamiliar | |
| 1855 | + category names *for this feed alone*; `unfamiliar categories: | |
| 1856 | + default` will cause it to drop any unfamiliar category names; and | |
| 1857 | + `unfamiliar categories: filter` will cause it to *both* drop any | |
| 1858 | + unfamiliar category names *and* to only syndicate posts that are | |
| 1859 | + placed in one or more familiar categories. | |
| 1860 | + | |
| 1861 | + These two new features allow users to do some coarse-grained | |
| 1862 | + filtering without having to write a PHP filter. Specifically, they | |
| 1863 | + offer an easy way for you to filter feeds by category or by author. | |
| 1864 | + Suppose, for example, that you only wanted to syndicate posts that | |
| 1865 | + your contributors place in the "Llamas" category. You could do so by | |
| 1866 | + setting up your installation of WordPress so that the only category | |
| 1867 | + in the database is "Llamas," and then use Options --> Syndication to | |
| 1868 | + set "Unfamiliar categories" to "don't create new categories and | |
| 1869 | + don't syndicate posts unless they match at least one familiar | |
| 1870 | + category". Now, when you update, only posts in the "Llamas" category | |
| 1871 | + will be syndicated by FeedWordPress. | |
| 1872 | + | |
| 1873 | + Similarly, if you wanted to filter one particular feed so that only | |
| 1874 | + posts by (for example) the author "Earl J. Llama" were syndicated to | |
| 1875 | + your site, you could do so by creating a user account for Earl J. | |
| 1876 | + Llama, then adding the following line to the settings for the feed | |
| 1877 | + in Link Notes: | |
| 1878 | + | |
| 1879 | + unfamiliar author: filter | |
| 1880 | + | |
| 1881 | + This will cause any posts from this feed that are not authored by | |
| 1882 | + Earl J. Llama to be discarded, and only the posts by Earl J. Llama | |
| 1883 | + will be syndicated. (If the setting is used on one specific feed, it | |
| 1884 | + will not affect how posts from other feeds are syndicated.) | |
| 1885 | + | |
| 130 | 1886 | == License == |
| 131 | 1887 | |
| 132 | -The FeedWordPress plugin is copyright © 2005-2007 by Charles Johnson. It uses | |
| 1888 | +The FeedWordPress plugin is copyright © 2005-2010 by Charles Johnson. It uses | |
| 133 | 1889 | code derived or translated from: |
| 134 | 1890 | |
| 135 | 1891 | - [wp-rss-aggregate.php][] by [Kellan Elliot-McCrea](kellan@protest.net) |
| 136 | -- [MagpieRSS][] by [Kellan Elliot-McCrea](kellan@protest.net) | |
| 137 | -- [HTTP Navigator 2][] by [Keyvan Minoukadeh](keyvan@k1m.com) | |
| 1892 | +- [MagpieRSS][] by [Kellan Elliot-McCrea](kellan@protest.net) | |
| 138 | 1893 | - [Ultra-Liberal Feed Finder][] by [Mark Pilgrim](mark@diveintomark.org) |
| 1894 | +- [WordPress Blog Tool and Publishing Platform](http://wordpress.org/) | |
| 139 | 1895 | |
| 140 | 1896 | according to the terms of the [GNU General Public License][]. |
| 141 | 1897 | |
| 142 | 1898 | This program is free software; you can redistribute it and/or modify it under |
| @@ -151,7 +1907,6 @@ | ||
| 151 | 1907 | [wp-rss-aggregate.php]: http://laughingmeme.org/archives/002203.html |
| 152 | 1908 | [MagpieRSS]: http://magpierss.sourceforge.net/ |
| 153 | 1909 | [HTTP Navigator 2]: http://www.keyvan.net/2004/11/16/http-navigator/ |
| 154 | 1910 | [Ultra-Liberal Feed Finder]: http://diveintomark.org/projects/feed_finder/ |
| 155 | - | |
| 156 | 1911 | [GNU General Public License]: http://www.gnu.org/copyleft/gpl.html |
| 157 | 1912 | |
