| @@ -1,643 +1,7 @@ | ||
| 1 | 1 | FeedWordPress Change Log |
| 2 | 2 | ======================== |
| 3 | -Changes from 2009.0707 to Trunk | |
| 4 | 3 | |
| 5 | -### Compatibility ### | |
| 6 | - | |
| 7 | -* SIMPLEPIE IS NOW USED TO PARSE FEEDS; NO MORE MAGPIERSS UPGRADES NEEDED: | |
| 8 | - One of the biggest changes in this release is that FeedWordPress no | |
| 9 | - longer depends on MagpieRSS to parse feeds, and has switched to the much | |
| 10 | - more up-to-date and flexible SimplePie feed parser, which is included as | |
| 11 | - a standard part of WordPress versions 2.8 and later. Using SimplePie will | |
| 12 | - hopefully allow for better handling of feeds going further, and will | |
| 13 | - allow me greater flexibility in determining how exactly the feed parser | |
| 14 | - will operate. It also means that FeedWordPress no longer requires | |
| 15 | - special upgrades to the WordPress core MagpieRSS files, and should | |
| 16 | - eliminate quite a bit of complexity. | |
| 17 | - | |
| 18 | -* MAGPIERSS COMPATIBILITY LAYER FOR EXISTING FILTERS AND ADD-ONS: However, | |
| 19 | - I have also implemented a compatibility layer to ensure that existing | |
| 20 | - filters and add-ons for FeedWordPress which depended on the MagpieRSS | |
| 21 | - data format *should not be broken* by the switch to SimplePie. Going | |
| 22 | - forward, I recommend that new filters and add-ons be written to take | |
| 23 | - advantage of the SimplePie object representations of items, feeds, etc., | |
| 24 | - rather than the MagpieRSS arrays, but the MagpieRSS arrays will still | |
| 25 | - be available and older filters should continue to work as they have in | |
| 26 | - the past. | |
| 27 | - | |
| 28 | -* COMPATIBILITY WITH WORDPRESS 2.9.x and 3.0: This release has been tested | |
| 29 | - for the existing WordPress 2.9.x branch and with the upcoming release of | |
| 30 | - WordPress 3.0. Changes in the user interface JavaScript between WordPress | |
| 31 | - 2.8.x and WordPress 2.9 caused the tag box interface element to break in | |
| 32 | - the Syndication --> Categories & Tags settings page; changes in the API | |
| 33 | - functions for adding new authors caused fatal errors under certain | |
| 34 | - conditions in WordPress 3.0. These breakages have been fixed. | |
| 35 | - | |
| 36 | -* DROPPED LEGACY SUPPORT FOR WORDPRESS PRIOR TO 2.8: Because SimplePie is | |
| 37 | - not included with versions of WordPress prior to 2.8, I have chosen to | |
| 38 | - drop legacy support for WordPress versions 1.5 through 2.7. If you are | |
| 39 | - using FeedWordPress with a version of WordPress before 2.8, you will | |
| 40 | - have to upgrade your installation of WordPress in order to take | |
| 41 | - advantage of this release. | |
| 42 | - | |
| 43 | -* PHP 5.3 COMPATIBILITY: A couple of compatibility issues, which were | |
| 44 | - causing fatal errors amd ugly warnings for users of PHP 5.3, | |
| 45 | - have been eliminated. | |
| 46 | - | |
| 47 | -### Features and Processing ### | |
| 48 | - | |
| 49 | -* INTERFACE REORGANIZATION: The interface restructuring, began with | |
| 50 | - Version 2009.0612, has been completed. Catch-all settings pages have | |
| 51 | - been eliminated entirely for pages that cover each aspect of handling | |
| 52 | - a feed: Feeds & Updates, Posts & Links, Authors, Categories & Tags, | |
| 53 | - and Back End handling of the database and diagnostic information. | |
| 54 | - Extensive new interface hooks allow add-on modules to significantly | |
| 55 | - change or extend the FeedWordPress admin interface and workflow. | |
| 56 | - | |
| 57 | -* STORING INFORMATION FROM THE FEED IN CUSTOM FIELDS: Many users | |
| 58 | - have written to request the ability to store information from elements | |
| 59 | - in the feed in a custom field on each post. (So that, for example, if | |
| 60 | - post includes a `itunes:duration` element, you could store the contents | |
| 61 | - in a Custom Field called `duration` on the post (for a Theme to access | |
| 62 | - later). The Custom Post Settings under Syndication --> Posts & Links now | |
| 63 | - allow you to access any item or feed tag, using a syntax similar to | |
| 64 | - a much-simplified version of XPath. See Posts & Links settings for | |
| 65 | - details. | |
| 66 | - | |
| 67 | -* UPDATE-FREEZING ON MANUALLY EDITED POSTS: FeedWordPress now allows you | |
| 68 | - to mark posts that have been manually edited, so that the changes you | |
| 69 | - make will not be overwritten by later updates from the feed. If you make | |
| 70 | - manual edits to a particular post, just check the "Manual editing" | |
| 71 | - checkbox in order to protect your changes from being overwritten. If you | |
| 72 | - want to block *all* posts from being updated after they are imported | |
| 73 | - for the first time, a new "Updated Posts" setting in Posts & Links | |
| 74 | - allows you to freeze all posts from a particular feed, or all syndicated | |
| 75 | - posts. | |
| 76 | - | |
| 77 | -* SETTING: FEED-BY-FEED SETTINGS FOR WHERE PERMALINKS POINT TO: You've | |
| 78 | - always been able to tell FeedWordPress whether permalinks for posts | |
| 79 | - should point to the original source of the story or the local copy. Now | |
| 80 | - you can choose different policies for different feeds, instead of one | |
| 81 | - global policy for all feeds. (Of course, you can still use a global | |
| 82 | - default if you prefer.) | |
| 83 | - | |
| 84 | -* SETTING: USER CONTROL OVER TIMING BASIS. You can now determine the | |
| 85 | - schedule on which feeds are considered ready to poll for updates -- | |
| 86 | - by default feeds become ready for polling after about 1 hour. You can | |
| 87 | - now increase or decrease the time window under Syndication --> Feeds & | |
| 88 | - Updates. (However, please pay *CAREFUL ATTENTION* to the recommendations | |
| 89 | - and DO NOT set the scheduling lower than 60 minutes unless you are | |
| 90 | - ABSOLUTELY SURE that you have specific permission from webmaster who | |
| 91 | - provides that specific feed to poll more frequently than that. If you | |
| 92 | - set this too low (and about 60 minutes is the polite minimum if you | |
| 93 | - haven't been given a different figure), most webmasters will consider | |
| 94 | - the frequent hits on their server as rude, or even downright abusive. | |
| 95 | - | |
| 96 | -* OTHER SETTINGS: New settings also include the ability to stop FWP from | |
| 97 | - resolving relative URLs within syndicated content, and the ability to | |
| 98 | - choose whether FeedWordPress should indicate the comment feed from the | |
| 99 | - original source, or the local comment feed, when providing the comment | |
| 100 | - feed URL for a syndicated post. | |
| 101 | - | |
| 102 | -### PARSING ### | |
| 103 | - | |
| 104 | -* BETTER DATE HANDLING -- FEWER FLASHBACKS TO 1969 and 1970: FeedWordPress | |
| 105 | - has made some bugfixes and some improvements in the logic for parsing | |
| 106 | - dates. This should allow FeedWordPress to correctly parse more dates in | |
| 107 | - more feeds; and, in the last resort, when FeedWordPress fails to | |
| 108 | - correctly parse a date, to fall back to a more intelligent default. This | |
| 109 | - should hopefully avoid most or all error conditions that have resulted | |
| 110 | - in articles being erroneously dated to the dawn of the Unix epoch | |
| 111 | - (31 December 1969 or 1 January 1970). | |
| 112 | - | |
| 113 | -* FULL-TEXT "EXCERPTS" NOW PROPERLY SHORTENED. Based on a straightforward | |
| 114 | - reading of the existing RSS specs, it's reasonable for the | |
| 115 | - rss:description element to be read as a plaintext summary or excerpt for | |
| 116 | - the item containing the description -- with the full text of the item, | |
| 117 | - if available, in another, better-suited element, such as the de facto | |
| 118 | - standard content:encoded extension element. The problem is that uses of | |
| 119 | - RSS rarely have much to do with anything like a straightforward reading | |
| 120 | - of the specs. As a result, many actual RSS producers in the wild put the | |
| 121 | - full text of the article in a description element. But since | |
| 122 | - FeedWordPress has treated this text as a summary, this produces | |
| 123 | - aggregated posts with lengthy "excerpts" containing the full text of the | |
| 124 | - article. This release of FeedWordPress fixes the problem by doing a | |
| 125 | - little digging before treating rss:description as a summary: if the | |
| 126 | - description element is used properly as a plain text summary, then | |
| 127 | - FeedWordPress will take the summary provided by the feed, rather than | |
| 128 | - recreating its own excerpt from the full text; but if an RSS item has no | |
| 129 | - full-text element other than description, FeedWordPress will treat the | |
| 130 | - description element as the full text of the article, and generate a | |
| 131 | - shortened excerpt automatically from that text. | |
| 132 | - | |
| 133 | -### API ### | |
| 134 | - | |
| 135 | -* TEMPLATE API: new template tags `get_local_permalink()` and | |
| 136 | - `the_local_permalink()` allow you to access the permalink for a post on | |
| 137 | - your aggregator site, even when FeedWordPress is rewriting permalinks to | |
| 138 | - point to the original source site. | |
| 139 | - | |
| 140 | -* NEW HOOKS FOR ADD-ONS AND FILTERS: I have added a number of new hooks | |
| 141 | - which allow add-on modules to filter more precisely, gather information | |
| 142 | - at more points, and to enhance the FeedWordPress admin interface. For | |
| 143 | - a list of new hooks and documentation, see the FeedWordPress | |
| 144 | - documentation wiki at | |
| 145 | - <http://feedwordpress.radgeek.com/wiki/add-ons-and-filters> | |
| 146 | - | |
| 147 | -* FILTER API: A number of new utility methods have been added to the | |
| 148 | - SyndicatedPost class to make it easier for filters and add-ons to | |
| 149 | - | |
| 150 | -* FILTER API: Globals $fwp_channel and $fwp_feedmeta DEPRECATED. These | |
| 151 | - global variables, originally introduced to allow filters access to | |
| 152 | - information about the source feed in `syndicated_item` filters (which | |
| 153 | - were passed in through global variables rather than as parameters | |
| 154 | - because of a bug in WP 1.5 which was then fixed in 1.5.1) have been | |
| 155 | - DEPRECATED. If you have any filters or add-ons which still depend on | |
| 156 | - these global variables, you should see about fixing them to access data | |
| 157 | - about the source feed using the SyndicatedPost::link element instead. | |
| 158 | - For documentation, see the FeedWordPress documentation wiki at | |
| 159 | - <http://feedwordpress.radgeek.com/wiki/syndicatedpost> and | |
| 160 | - <http://feedwordpress.radgeek.com/wiki/syndicatedlink>. | |
| 161 | - | |
| 162 | -* DIAGNOSTICS: I've included a number of new diagnostic options and | |
| 163 | - messages, which should allow an experienced user to better investigate | |
| 164 | - any problems that may crop up. | |
| 165 | - | |
| 166 | -### Bug Fixes ### | |
| 167 | - | |
| 168 | -* BUGFIX: & IN PERMALINKS NO LONGER CAUSING ATOM OR HTML VALIDATION | |
| 169 | - EFFORTS: Many users reported an issue in which syndicating a feed with | |
| 170 | - special XML characters in the URLs (& was the most common, since it is | |
| 171 | - used to separate HTTP GET parameters) would cause the aggregator's | |
| 172 | - feeds to produce invalid (malformed) XML. This update addresses the | |
| 173 | - issue in Atom feeds. Unfortunately, it has not been technically possible | |
| 174 | - to address the problem in RSS 2.0 feeds, due to limitations on | |
| 175 | - WordPress's internal templates for RSS feeds. | |
| 176 | - | |
| 177 | -* BUGFIX: BROKEN URLS IN "POPULAR POSTS" AND SIMILAR PLUGINS SHOULD NO | |
| 178 | - LONGER BE BROKEN. A number of users noticed an issue where plugins and | |
| 179 | - templates that listed posts in locations outside of the post loop | |
| 180 | - (for example, "Popular Posts"-style plugins that listed posts in the | |
| 181 | - sidebar), often produced the wrong URL for post links. (Typically, all | |
| 182 | - the posts listed would get the same wrong URL.) This should now be | |
| 183 | - fixed. Thanks to Björn for sending in a quick fix! | |
| 184 | - | |
| 185 | -* MINOR BUGFIXES: This release includes a number of fixes to minor bugs | |
| 186 | - and compatibility issues, including: silent failures of the "Syndicate" | |
| 187 | - button, "Illegal Offset Type" error messages from MagpieRSS, | |
| 188 | - | |
| 189 | - | |
| 190 | -Changes from 2009.0618 to 2009.0707 | |
| 191 | -* BUGFIX: WORDPRESS 2.8 AJAX COMPATIBILITY ISSUES RESOLVED (blank or | |
| 192 | - truncated "Syndicated Sites" administration page): Due to changes in the | |
| 193 | - AJAX interface elements between WordPress 2.7 and WordPress 2.8, several | |
| 194 | - FeedWordPress users encountered an issue where the front "Syndication" | |
| 195 | - page in the FeedWordPress administrative interface would come up blank, | |
| 196 | - without the normal "Syndicated Sites" list and "Update" control, or | |
| 197 | - sometimes wth the boxes visible but one or both of them truncated, with | |
| 198 | - only the title bar. This issue should now be resolved: with the new | |
| 199 | - version of FeedWordPress, the compatibility issue that caused the | |
| 200 | - disappearance should be eliminated, and if boxes are shown with only | |
| 201 | - their handle visible, you should once again be able to drop down the | |
| 202 | - rest of the box by clicking once on its title bar. | |
| 203 | - | |
| 204 | -* BUGFIX: TAG SETTING WIDGET FIXED. Due to changes in interface elements | |
| 205 | - between WordPress 2.7 and WordPress 2.8, people using FeedWordPress with | |
| 206 | - WordPress 2.8 found that the widget for setting tags to be applied to | |
| 207 | - all syndicated posts, or all syndicated posts from a particular feed, | |
| 208 | - no longer displayed "Add" and "Remove" buttons for individual tags. This | |
| 209 | - issue has now been fixed, and the tagging widget should once again work | |
| 210 | - more or less exactly like the tagging widget for individual posts in the | |
| 211 | - normal WordPress admin interface. | |
| 212 | - | |
| 213 | -Changes from 2009.0613 to 2009.0618 | |
| 214 | -* BUGFIX: MYSTERY ERRORS WITH WITH WP_Http_Fsockopen HTTP TRANSPORT | |
| 215 | - ELIMINATED: Thanks to a combination of a subtle bug in FeedWordPress, | |
| 216 | - and changes to the HTTP transport code in WordPress, a number of users | |
| 217 | - encountered an error in which any time they attempted to add a new feed | |
| 218 | - through the FeedFinder interface, FeedWordPress would fail and display | |
| 219 | - an HTTP request failure diagnostic message. The subtle bug has been | |
| 220 | - fixed, and with it, most of these errors should now be eliminated. | |
| 221 | - | |
| 222 | - Be sure to upgrade your MagpieRSS to the most recent MagpieRSS version | |
| 223 | - after you have insalled FeedWordPress 2009.0618, or this bug fix will | |
| 224 | - not take effect. | |
| 225 | - | |
| 226 | - | |
| 227 | -Changes from 2009.0612 to 2009.0613 | |
| 228 | -* INTERFACE/BUGFIX: WORDPRESS 2.8 CATEGORY BOX FIX. Thanks to a subtle | |
| 229 | - change in class names between the WordPress 2.7 and 2.8 stylesheets, | |
| 230 | - category boxes in the FeedWordPress settings interface tended to overflow | |
| 231 | - and have a lot of messy-looking overlapping text under WordPress 2.8. | |
| 232 | - This has now been fixed. | |
| 233 | - | |
| 234 | -* FeedFinder FAILURE DIAGNOSTICS: When FWP's FeedFinder fails to find any | |
| 235 | - feeds at a given URL (for example, when you are trying to add a | |
| 236 | - subscription through the administrative interface and you run into an | |
| 237 | - error message), FeedWordPress now provides more diagnostic information | |
| 238 | - for the reasons behind the failure. If that helps you, great; if not, | |
| 239 | - it should help me respond more intelligently to your support request.. | |
| 240 | - | |
| 241 | -Changes from 2008.1214 to 2009.0612 | |
| 242 | -* WORDPRESS 2.8 COMPATIBILITY: FeedWordPress 2009.0612 has been tested for | |
| 243 | - compatibility with the recent version 2.8 release of WordPress. | |
| 244 | - | |
| 245 | -* INTERFACE RESTRUCTURING: In order to avoid settings posts from becoming | |
| 246 | - too crowded, and to modularize and better organize the user interface, | |
| 247 | - new "Posts" and "Categories & Tags" subpages have been created under the | |
| 248 | - "Syndication" menu. "Posts" controls settings for individal syndicated | |
| 249 | - posts (such as publication status, comment and ping status, whether or | |
| 250 | - not to use the original location of the post as the permalink, whether | |
| 251 | - or not to expose posts to formatting filters, and so on). "Categories & | |
| 252 | - Tags" controls settings for assigning new syndicated posts to categories | |
| 253 | - and tags, such as categories or tags to apply to all syndicated posts, | |
| 254 | - and how to handle categories that do not yet exist in the WordPress | |
| 255 | - database. These subpages, like the Authors subpage, handle settings for | |
| 256 | - the global default level and for individual syndicated feeds. | |
| 257 | - | |
| 258 | - Corresponding to these new subpages, the old Syndication Settings and | |
| 259 | - Feed Settings subpages have been cleaned up and simplified, and now only | |
| 260 | - link to the appropriate subpages for options that can be set in the | |
| 261 | - Posts, Authors, or Categories & Tags subpages. | |
| 262 | - | |
| 263 | -* FEATURE: ADD CUSTOM SETTINGS TO EACH SYNDICATED POST: FeedWordPress has | |
| 264 | - long had an interface for creating custom settings for each syndicated | |
| 265 | - *feed* which could be retrieved in templates using the `get_feed_meta()` | |
| 266 | - template function. But it had no feature for adding custom fields to | |
| 267 | - each individual syndicated *post*. In response to requests from users, I | |
| 268 | - have added the ability to apply custom fields to each individual | |
| 269 | - syndicated post, using the new Syndication --> Posts subpage. You can | |
| 270 | - set up custom fields to be applied to every syndicated post, or custom | |
| 271 | - fields to be applied to syndicated posts from a particular feed. | |
| 272 | - | |
| 273 | -* FEATURE: MAGPIERSS VERSION CHECK AND UPGRADE: FeedWordPress will attempt | |
| 274 | - to determine whether or not you are using the upgraded version of | |
| 275 | - MagpieRSS that comes packaged with FeedWordPress. If not, it will throw | |
| 276 | - an error on admin pages, and, if you are a site administrator, it will | |
| 277 | - give you the option to ignore the error message, or to attempt an | |
| 278 | - automatic upgrade (using a native file copy). If the file copy fails, | |
| 279 | - FeedWordPress will offer some guidance on how to perform the upgrade | |
| 280 | - manually. | |
| 281 | - | |
| 282 | -* BLANK POSTS PROBLEM NO LONGER OCCURS WITH OLD & BUSTED MAGPIERSS: Due | |
| 283 | - to the fact that I relied on a content normalization that occurs in my | |
| 284 | - upgraded version of MagpieRSS, but not in the old & busted version of | |
| 285 | - MagpieRSS that ships with WordPress, until this version, if you tried to | |
| 286 | - syndicate an Atom feed without having performed the (*strongly | |
| 287 | - recommended*) MagpieRSS upgrade, all of the posts would come up with | |
| 288 | - completely blank contents. That's not because MagpieRSS couldn't read | |
| 289 | - the data, but rather because the new Magpie version puts that data in a | |
| 290 | - location where the old version doesn't, and I was only looking in that | |
| 291 | - newer location. Now it checks for both, meaning that posts will continue | |
| 292 | - to display their contents even if you don't upgrade MagpieRSS. (But you | |
| 293 | - **really should** upgrade it, anyway.) | |
| 294 | - | |
| 295 | -* BUGFIX: RELATIVE URI RESOLUTION FOR POST CONTENT RESTORED. Some time | |
| 296 | - back, I added support for resolving relative URIs against xml:base on | |
| 297 | - feeds that support it to the MagpieRSS upgrade in FeedWordPress. Then I | |
| 298 | - took out code that did the same thing from the main FeedWordPress code. | |
| 299 | - Of course, the problem is that some people, even though it is clearly | |
| 300 | - stupid or evil to do so, still include relative URIs for images or links | |
| 301 | - in posts on feed formats that do *not* adequately support xml:base | |
| 302 | - (notably, RSS 2.0 feeds). In response to a user request, I have added | |
| 303 | - this functionality back in, so that MagpieRSS will resolve any relative | |
| 304 | - URIs that it knows how to resolve using xml:base, and then FeedWordPress | |
| 305 | - will attempt to resolve any relative URIs that are left over afterwards. | |
| 306 | - | |
| 307 | -* BUGFIX: INTERFACE OPTION FOR SETTING SYNDICATED POST PUBLICATION STATUS | |
| 308 | - ON A FEED-BY-FEED BASIS HAS BEEN RESTORED: Due to a version-checking | |
| 309 | - bug, users of WordPress 2.7.x lost an option from the "Edit a syndicated | |
| 310 | - feed" interface which allowed them to determine whether newly syndicated | |
| 311 | - posts should be published immediately, held as "Pending Review," saved | |
| 312 | - as drafts, or saved as private posts. (The option to change this | |
| 313 | - setting globally remained in place, but users could no longer set it on | |
| 314 | - a feed-by-feed basis.) The version-checking bug has been fixed, and the | |
| 315 | - option has been restored. | |
| 316 | - | |
| 317 | -* BUGFIX: "ARE YOU SURE?" FATAL ERROR ELIMINATED AND SECURITY IMPROVED: | |
| 318 | - Under certain circumstances (for example, when users have configured | |
| 319 | - their browser or proxy not to send HTTP Referer headers, for privacy or | |
| 320 | - other reasons), many features in the FeedWordPress administrative | |
| 321 | - interface (such as adding new feeds or changing settings) would hit a | |
| 322 | - fatal error, displaying only a cryptic message reading "Are you sure?" | |
| 323 | - and a blank page following it. This problem has been eliminated by | |
| 324 | - taking advantage of WordPress's nonce functions, which allow the | |
| 325 | - security check which ran into this error to work properly even without | |
| 326 | - receiving an HTTP Referer header. (N.B.: WordPress's nonce functions | |
| 327 | - were first introduced in WordPress 2.0.3. If you're using FeedWordPress | |
| 328 | - with an older version of WordPress, there's no fix for this problem: | |
| 329 | - you'll just need to turn Referer headers back on. Sorry.) | |
| 330 | - | |
| 331 | -* BUGFIX: MANUALLY-ALTERED POST STATUS, COMMENT STATUS, AND PING STATUS NO | |
| 332 | - LONGER REVERTED BY POST UPDATES: If you manually altered the post status, | |
| 333 | - comment status, or ping status of a syndicated post from what it was set | |
| 334 | - to when first syndicated -- for example, if you had a feed that was set | |
| 335 | - to bring in new posts as "Pending Review," and you then marked some of | |
| 336 | - the pending posts as "Published" and others as "Unpublished" -- then | |
| 337 | - in previous versions of FeedWordPress, these manual changes to the | |
| 338 | - status would be lost -- so that, for example, your Published or Unpublished | |
| 339 | - articles would revert to Pending Review -- if the source feed made any | |
| 340 | - upates to the item. This could make the Pending Review feature both | |
| 341 | - unreliable and also extremely frustrating to work with. The good news is | |
| 342 | - that this bug has since been fixed: if you manually update the status | |
| 343 | - of a post, it will no longer be reverted if or when the post is updated. | |
| 344 | - | |
| 345 | -* BUGFIX: OCCASIONAL FATAL ERROR ON UPDATE ELIMINATED: Under certain | |
| 346 | - limited conditions (specifically, when both the title and the content of | |
| 347 | - a post to be updated are empty), an attempt to update the post would | |
| 348 | - result in a fatal error. This has been fixed. | |
| 349 | - | |
| 350 | -* INTERFACE: "CONFIGURE SETTINGS" CONVENIENCE LINK ADDED TO CONFIRMATION | |
| 351 | - MESSAGE WHEN A NEW FEED IS ADDED: When you add a new subscription to | |
| 352 | - FeedWordPress, the message box that appears to confirm it now includes a | |
| 353 | - handy link to the feed's settings subpage, so that you can quickly set | |
| 354 | - up any special settings you may want to set up for the new feed, without | |
| 355 | - having to hunt through the list of all your other subscriptions to pick | |
| 356 | - out the new one. | |
| 357 | - | |
| 358 | -* INTERFACE: SIMPLIFYING AND CLARIFYING AUTOMATIC UPDATES SETTINGS. I have | |
| 359 | - removed an interval setting for the cronless automatic updates which has | |
| 360 | - confused many FeedWordPress users. In past versions of FWP, when you | |
| 361 | - turned on automatic updates, you would be presented with a time interval | |
| 362 | - setting which controlled how often FeedWordPress would check for feeds | |
| 363 | - ready to be polled for updates. (That is, it DID NOT control how often | |
| 364 | - feeds *would be polled*; it controlled how often FeedWordPress would | |
| 365 | - *check* for feeds that *had become ready to poll*. The schedule on which | |
| 366 | - feeds became ready for polling was still controlled either by requests | |
| 367 | - encoded in elements within the feed itself, or else according to an | |
| 368 | - internal calculation within FeedWordPress, averaging out to about 1 hour, | |
| 369 | - if the feed did not include any scheduling request elements.) Since many | |
| 370 | - users very often (and understandably) confused the purpose of this | |
| 371 | - setting, and since the setting is for a feature that's actually very | |
| 372 | - unlikely to require any manual control by the user, I have removed the | |
| 373 | - setting; FeedWordPress now simply uses the default value of checking for | |
| 374 | - feeds to poll every 10 minutes. | |
| 375 | - | |
| 376 | -* FEEDFINDER PERFORMANCE IMPROVEMENT: FeedWordPress's FeedFinder class | |
| 377 | - now uses `array_unique()` to make sure that it doesn't waste time | |
| 378 | - repeatedly iterating over and polling the same URI. Props to Camilo | |
| 379 | - (<http://projects.radgeek.com/2008/12/14/feedwordpress-20081214/#comment-20090122160414>). | |
| 380 | - | |
| 381 | -Changes from 2008.1105 to 2008.1214 | |
| 382 | - | |
| 383 | -* WORDPRESS 2.7 COMPATIBILITY: FeedWordPress has been tested for | |
| 384 | - compatibility with the newly released WordPress 2.7. WordPress 2.7 has | |
| 385 | - deprecated the Snoopy library for HTTP requests, which caused a fatal | |
| 386 | - error for users who had not installed the MagpieRSS upgrade (or whose | |
| 387 | - installation of the MagpieRSS upgrade was overwritten by a recent update | |
| 388 | - of WordPress). FeedWordPress now handles things gracefully when Snoopy | |
| 389 | - is not immediately available. | |
| 390 | - | |
| 391 | -* INTERFACE SPIFFED UP: Interface elements have been updated so that | |
| 392 | - FeedWordPress's management interface fits in more naturally with the | |
| 393 | - WordPress 2.7 interface (including a new logo and a number of small | |
| 394 | - interface tweaks). | |
| 395 | - | |
| 396 | -* BUG WITH TAGS FOR SYNDICATED ARTICLES FIXED: Several users encountered a | |
| 397 | - bug with the option to add tags to all syndicated posts under | |
| 398 | - Syndication --> Settings -- if you told FeedWordPress to add more than | |
| 399 | - one tag to all syndicated posts, instead of doing so correctly, it would | |
| 400 | - add a *single* tag instead, whose name was composed of the names of all | |
| 401 | - the tags you asked it to add. This bug was the result of nothing more | |
| 402 | - dignified than a typographical error on my part. It has now been fixed. | |
| 403 | - | |
| 404 | -* MORE INFORMATION AVAILABLE WHEN FEEDWORDPRESS CAN'T FIND A FEED: When | |
| 405 | - you enter a URL for a new syndication source, FeedWordPress uses a | |
| 406 | - simple feed-finding algorithm (originally based on Mark Pilgrim's | |
| 407 | - Universal Feed Finder) to try to determine whether the URL is the URL | |
| 408 | - for a feed, or, if the URL points to an ordinary website rather than to | |
| 409 | - a feed, whether there is a feed for that website. All well and good, but | |
| 410 | - if FeedWordPress failed to find a feed, for whatever reason, it would | |
| 411 | - typically return nothing more than a nasty little note to the effect of | |
| 412 | - "no feed found," without any explanation of what went wrong. | |
| 413 | - FeedWordPress now keeps track of error conditions from the HTTP | |
| 414 | - requests that it uses in the course of looking for the feed, and so may | |
| 415 | - be able to give you a bit more information about the nature of the | |
| 416 | - problem if something goes wrong. | |
| 417 | - | |
| 418 | - | |
| 419 | -Changes from 2008.1101 to 2008.1105 | |
| 420 | - | |
| 421 | -* INTERFACE RESTRUCTURING AND SYNDICATION --> AUTHORS PAGE: As a first | |
| 422 | - step towards modularizing and better organizing the user interface, a | |
| 423 | - new "Authors" subpage has been created under the Syndication menu, which | |
| 424 | - controls settings for syndicated authors, both at the global default | |
| 425 | - level and at level of individual syndicated feeds. | |
| 426 | - | |
| 427 | -* BUG RELATED TO THE ATTRIBUTION OF POSTS TO THE WRONG AUTHOR FIXED: Some | |
| 428 | - users encountered an issue in which posts by different authors on | |
| 429 | - different blogs -- especially blogs generated by Blogger -- were | |
| 430 | - mistakenly attributed to a single author. The problem was caused by the | |
| 431 | - way in which FeedWordPress matches syndicated authors to user accounts | |
| 432 | - in the WordPress database: normally, if two feeds each list an author | |
| 433 | - with the same e-mail address, they are counted as being the same person. | |
| 434 | - Normally this works well, but it creates an issue in cases where | |
| 435 | - blogging software assigns a single anonymous e-mail address to users who | |
| 436 | - do not want their real e-mail address published. This is, for example, | |
| 437 | - what Blogger does (by giving all users a default e-mail address of | |
| 438 | - <noreply@blogger.com> if they don't want their own e-mail address | |
| 439 | - listed). FeedWordPress now allows the user to correct for this problem | |
| 440 | - with a couple of new settings under **Syndication --> Authors**, which | |
| 441 | - allow users to turn off e-mail based author matching for particular | |
| 442 | - addresses, or, if desired, to turn it off entirely. By default, e-mail | |
| 443 | - based author matching is still turned on, but disabled for a list of | |
| 444 | - known generic e-mail addresses. Right now, the "list" consists entirely | |
| 445 | - of <noreply@blogger.com>; if you know other addresses that should be | |
| 446 | - added, please [contact me](http://radgeek.com/contact) to let me know. | |
| 447 | - | |
| 448 | - Please note that if you have already encountered this issue on your | |
| 449 | - blog, upgrading FeedWordPress will prevent it from re-occurring in the | |
| 450 | - future, but you still need to do two other things to fix the existing | |
| 451 | - problem on your blog. | |
| 452 | - | |
| 453 | - First, for each feed where posts have been mis-attributed, you need to | |
| 454 | - change the existing author mapping rules to re-map a a syndicated | |
| 455 | - author's name to the proper target account. Go to **Syndication --> | |
| 456 | - Authors**, select the feed you want to change from the drop-down list, | |
| 457 | - and then change the settings under the "Syndicated Authors" section. | |
| 458 | - (You will probably need to select "will be assigned to a new user..." to | |
| 459 | - create a new user account with the appropriate name.) | |
| 460 | - | |
| 461 | - Second, for each feed where posts have been mis-attributed, you need to | |
| 462 | - re-assign already-syndicated posts that were mis-attributed to the | |
| 463 | - correct author. You can do that from **Syndication --> Authors** by | |
| 464 | - using the author re-assignment feature, described below. | |
| 465 | - | |
| 466 | -* AUTHOR RE-ASSIGNMENT FOR A PARTICULAR FEED: The author settings page | |
| 467 | - for each syndicated feed, under **Syndication --> Authors**, now | |
| 468 | - includes an section titled "Fixing mis-matched authors," which provides | |
| 469 | - an interface for re-assigning or deleting all posts attributed to a | |
| 470 | - particular author on a particular feed. | |
| 471 | - | |
| 472 | -* SUPPORT FOR `<atom:source>` ELEMENT IN SYNDICATED FEEDS: Some feeds | |
| 473 | - (for example, those produced by FeedWordPress) aggregate content from | |
| 474 | - several different sources, and include information about the original | |
| 475 | - source of the post in an `<atom:source>` element. A new setting under | |
| 476 | - **Syndication --> Options** allows you to control what FeedWordPress | |
| 477 | - will report as the source of posts syndicated from aggregator feeds in | |
| 478 | - your templates and feeds: you can have FeedWordPress report that the | |
| 479 | - source of a post is the aggregator feed itself, or you can have it | |
| 480 | - report that the source of a post is the original source that the | |
| 481 | - aggregator originally syndicated the post from. | |
| 482 | - | |
| 483 | - By default, FeedWordPress will report the aggregator, not the original | |
| 484 | - source, as the source of a syndicated item. | |
| 485 | - | |
| 486 | -* LOAD BALANCING AND TIME LIMITING FEATURES FOR UPDATES: Some users have | |
| 487 | - encountered issues due to running up against PHP execution time limits | |
| 488 | - during the process of updating large syndicated feeds, or a very large | |
| 489 | - set of syndicated feeds. FeedWordPress now has a feature that allows you | |
| 490 | - to limit the total amount of time spent updating a feed, through the | |
| 491 | - "Time limit on updates" setting under **Syndication --> Options**. By | |
| 492 | - turning on this setting and adjusting the time limit to a low enough | |
| 493 | - figure to avoid your PHP installation's time-out setting. (PHP execution | |
| 494 | - time limits are usually in the vicinity of 30 seconds, so an update | |
| 495 | - time limit of 25 seconds or so should provide plenty of time for updates | |
| 496 | - while allowing a cushion of time for other, non-update-related functions | |
| 497 | - to do their work.) | |
| 498 | - | |
| 499 | - If feed updates are interrupted by the time limit, FeedWordPress uses | |
| 500 | - some simple load balancing features to make sure that updates to other | |
| 501 | - feeds will not be blocked by the time-hogging feed, and will also make | |
| 502 | - sure that when the interrupted update is resumed, FeedWordPress will | |
| 503 | - skip ahead to resume processing items at the point at which it was | |
| 504 | - interrupted last time, so that posts further down in the feed will | |
| 505 | - eventually get processed, and not get blocked by the amount of time it | |
| 506 | - takes to process the items higher up in the feed. | |
| 507 | - | |
| 508 | -* `guid` INDEX CREATION BUTTON: FeedWordPress frequently issues queries on | |
| 509 | - the `guid` column of the WordPress posts database (since it uses post | |
| 510 | - guid URIs to keep track of which posts it has syndicated). In very large | |
| 511 | - FeedWordPress installations, you can often significantly improve | |
| 512 | - performance by creating a database index on the `guid` column, but | |
| 513 | - normally you would need to poke around with MySQL or a tool like | |
| 514 | - phpMyAdmin to do this. FeedWordPress can now save you the trouble: to | |
| 515 | - create an index on the `guid` column, just go to | |
| 516 | - **Syndication --> Options**, and mash the button at the bottom of the | |
| 517 | - "Back End" section. | |
| 518 | - | |
| 519 | -Changes from 2008.1030 to 2008.1101 | |
| 520 | - | |
| 521 | -* INTERFACE BUG THAT PREVENTED ADDING NEW SITES FIXED: The UI reforms in | |
| 522 | - FWP 2008.1030 unintentionally introduced a bug that prevents clean | |
| 523 | - installations of FeedWordPress from providing an input box for adding | |
| 524 | - new feeds to the list of syndicated feeds. This bug has been fixed. | |
| 525 | - | |
| 526 | -Changes from 0.993 to 2008.1030 | |
| 527 | - | |
| 528 | -* WORDPRESS 2.6 COMPATIBILITY: FeedWordPress should now be compatible with | |
| 529 | - WordPress 2.6, and should work more or less seamlessly with the new post | |
| 530 | - revision system. A bug which caused multiple new revisions to be created | |
| 531 | - for posts on certain feeds, regardless of whether or not the item had | |
| 532 | - been updated, has been fixed. | |
| 533 | - | |
| 534 | -* INTERFACE IMPROVEMENTS: The user interface has been substantially | |
| 535 | - restyled to fit in better with the visual style of WordPress 2.5 and | |
| 536 | - 2.6. | |
| 537 | - | |
| 538 | -* YOUTUBE BUG FIXED: POSTS SYNDICATED THROUGH AN AUTOMATIC UPDATE ARE NO | |
| 539 | - LONGER STRIPPED OF `<OBJECT>` TAGS AND CERTAIN OTHER HTML ELEMENTS: Due | |
| 540 | - to the way that some versions of WordPress process posts that are | |
| 541 | - inserted into the database when no user is logged in, many users | |
| 542 | - experienced an issue where YouTube videos and other content using the | |
| 543 | - HTML `<object>` tag would be stripped out of posts that were syndicated | |
| 544 | - during an automatic update. (Posts that were syndicated through manual | |
| 545 | - updates from within the WordPress Dashboard were not affected, because | |
| 546 | - the issue does not arise when an update is executed under a logged-in | |
| 547 | - administrator's credentials.) This bug has now been fixed; YouTube | |
| 548 | - videos and other content using `<object>` tags should now appear | |
| 549 | - properly in syndicated posts, regardless of the way in which the post | |
| 550 | - was syndicated. | |
| 551 | - | |
| 552 | -* AJAX BUGS FIXED: Bugs which blocked the normal operation of WordPress | |
| 553 | - 2.5's AJAX interface elements when FeedWordPress was activated have been | |
| 554 | - fixed. | |
| 555 | - | |
| 556 | -* TAG SUPPORT: A couple of features have been introduced to take advantage | |
| 557 | - of the tagging features in WordPress 2.3.x, 2.5.x, and 2.6.x. Now, when | |
| 558 | - unfamiliar categories are encountered for posts on a feed, you can | |
| 559 | - choose for FeedWordPress (1) to drop the category; (2) to drop the | |
| 560 | - category and to filter out any post that does not match at least one | |
| 561 | - familiar category; (3) to create a new category with that name, or, | |
| 562 | - now, you can also have FeedWordPress (4) create a new *tag* with that | |
| 563 | - name. This option can be set site-wide under Syndication --> Options, | |
| 564 | - or it can be set on a feed-by-feed basis in a feed's Edit screen. | |
| 565 | - | |
| 566 | - In addition, you can now set particular tags to apply to all incoming | |
| 567 | - syndicated posts, under Syndication --> Options, or you can set tags | |
| 568 | - to apply to all incoming syndicated posts from a particular feed in that | |
| 569 | - feed's Edit screen. | |
| 570 | - | |
| 571 | -* FORMATTING FILTERS: There is a new option available under Syndication -> | |
| 572 | - Options which allows users to choose whether or not to expose syndicated | |
| 573 | - posts to being altered by formatting filters. By default, FeedWordPress | |
| 574 | - has always protected syndicated posts (which are already in display-ready | |
| 575 | - HTML when they are syndicated) from being reformatted by formatting | |
| 576 | - filters. However, this approach means that certain plugins which depend | |
| 577 | - on formatting filters (for example, to add "Share This" bars or relevant | |
| 578 | - links to the end of a post) are blocked from working on any syndicated | |
| 579 | - posts. If you want to use one of these plugins together with | |
| 580 | - FeedWordPress, you can now do so by changing the "Formatting Filters" | |
| 581 | - setting from "Protect" to "Expose." | |
| 582 | - | |
| 583 | -* `<atom:source>` ELEMENTS NOW INCLUDED IN ATOM FEED: Atom 1.0 provides | |
| 584 | - a standard method for aggregators to indicate information about the original source of | |
| 585 | - a syndicated post, using the `<atom:source>` element. FeedWordPress now | |
| 586 | - introduces standard `<atom:source>` elements including the title, homepage, and | |
| 587 | - feed URI of the source from which a syndicated post was syndicated. Cf. | |
| 588 | - <http://www.atomenabled.org/developers/syndication/atom-format-spec.php#element.source> | |
| 589 | - | |
| 590 | -* MODULARIZATION OF CODE: The code for different elements of FeedWordPress | |
| 591 | - has been broken out into several modules for easier inspection, | |
| 592 | - documentation, and maintenance of the code. | |
| 593 | - | |
| 594 | -* VERSIONING SCHEME CHANGED: FeedWordPress's feature set has proven stable | |
| 595 | - enough that it can now be removed from beta status; a good thing, since | |
| 596 | - I was very quickly running out of version numbers to use. New releases | |
| 597 | - of FeedWordPress will have version numbers based on the date of their | |
| 598 | - release. | |
| 599 | - | |
| 600 | -Changes from 0.992 to 0.993 | |
| 601 | - | |
| 602 | -* WORDPRESS 2.5.1 COMPATIBILITY: FeedWordPress should now be compatible | |
| 603 | - with WordPress 2.5.1. | |
| 604 | - | |
| 605 | -* WORDPRESS 2.5 INTERFACE IMPROVEMENTS: FeedWordPress's Dashboard | |
| 606 | - interface has undergone several cosmetic changes that should help it | |
| 607 | - integrate better with the WordPress Dashboard interface in WordPress | |
| 608 | - version 2.5.x. | |
| 609 | - | |
| 610 | -* SYNDICATED POSTS CAN BE MARKED AS "PENDING REVIEW": WordPress 2.3 users | |
| 611 | - can now take advantage of WordPress's new "Pending Review" features for | |
| 612 | - incoming syndicated posts. Posts marked as "Pending Review" are not | |
| 613 | - published immediately, but are marked as ready to be reviewed by an | |
| 614 | - Administrator or Editor, who can then choose to publish the post or | |
| 615 | - hold it back. If you want to review syndicated posts from a particular | |
| 616 | - feed, or from all feeds, before they are posted, then use | |
| 617 | - Syndication --> Syndicated Sites --> Edit or Syndication --> Options to | |
| 618 | - change the settings for handling new posts. | |
| 619 | - | |
| 620 | -* AWARE OF NEW URI FOR del.icio.us FEEDS: Previous releases of | |
| 621 | - FeedWordPress already automatically split del.icio.us tags up | |
| 622 | - appropriately appropriately when generating categories. (del.icio.us | |
| 623 | - feeds smoosh all the tags into a single `<dc:subject>` element, | |
| 624 | - separated by spaces; FeedWordPress un-smooshes them into multiple | |
| 625 | - categories by separating them at whitespace.) Unfortunately, del.icio.us | |
| 626 | - recently broke the existing behavior by changing host names for their | |
| 627 | - feeds from del.icio.us to feeds.delicious.com. Version 0.993 accounts | |
| 628 | - for the new host name and un-breaks the tag splitting. | |
| 629 | - | |
| 630 | 4 | Changes from 0.991 to 0.992 |
| 631 | 5 | --------------------------- |
| 632 | 6 | * AUTHOR RE-MAPPING: FeedWordPress now offers considerable control over |
| 633 | 7 | how author names on a feed are translated into usernames within the |
| @@ -668,9 +32,9 @@ | ||
| 668 | 32 | has, hopefully, been resolved, by correcting for the bug in WordPress. |
| 669 | 33 | |
| 670 | 34 | Changes from 0.99 to 0.991 |
| 671 | 35 | -------------------------- |
| 672 | -* WORDPRESS MU COMPATIBILITY: FeedWordPress should now be compatible with | |
| 36 | +* WORDPRESS MU COMPATABILITY: FeedWordPress should now be compatible with | |
| 673 | 37 | recent releases of WordPress MU. Once FeedWordPress is made available |
| 674 | 38 | as a plugin, each individual blog can choose to activate FeedWordPress |
| 675 | 39 | and syndicate content from its own set of contributors. |
| 676 | 40 | |
| @@ -687,12 +51,12 @@ | ||
| 687 | 51 | authors whose names included international characters. This |
| 688 | 52 | incompatability has now been fixed; hopefully, authors with |
| 689 | 53 | international characters in their names should now be handled properly. |
| 690 | 54 | |
| 691 | -* `<media:content>` BUG IN MAGPIERSS FIXED: A bug in MagpieRSS's handling | |
| 692 | - of namespaced elements has been fixed. Among other things, this bug | |
| 693 | - caused items containing a Yahoo MediaRSS `<media:content>` element (such | |
| 694 | - as many of the feeds produced by wordpress.com) to be represented | |
| 55 | +* media:content BUG IN MAGPIERSS FIXED: A bug in MagpieRSS's handling of | |
| 56 | + namespaced elements has been fixed. Among other things, this bug caused | |
| 57 | + items containing a Yahoo MediaRSS `<media:content>` element (such as | |
| 58 | + many of the feeds produced by wordpress.com) to be represented | |
| 695 | 59 | incorrectly, with only a capital "A" where the content of the post |
| 696 | 60 | should have been. Feeds containing `<media:content>` elements should now |
| 697 | 61 | be syndicated correctly. |
| 698 | 62 | |
| @@ -847,9 +211,9 @@ | ||
| 847 | 211 | * DATE BUG AFFECTING SOME PHP INSTALLATIONS RESOLVED: due to a subtle bug |
| 848 | 212 | in parse_w3cdtf(), some installations of PHP encountered problems with |
| 849 | 213 | FeedWordPress's attempt to date posts, which would cause some new posts |
| 850 | 214 | on Atom feeds to be dated as if they had apppeared in 1969 or 1970 |
| 851 | - (thus, effectively, never appearing on front page at all). This bug in | |
| 215 | + (thus, effectively, never appearing on front apge at all). This bug in | |
| 852 | 216 | the date handling should now be fixed. |
| 853 | 217 | |
| 854 | 218 | * PHP <?=...?> SHORT FORM ELIMINATED: some installations of PHP do not |
| 855 | 219 | allow the <?=...?> short form for printing PHP values, which was used |
| @@ -931,9 +295,9 @@ | ||
| 931 | 295 | regular expressions and careful matching of lowercasing functions |
| 932 | 296 | (comparing results from PHP only to other results from PHP, and results |
| 933 | 297 | from MySQL only to other results from MySQL). |
| 934 | 298 | |
| 935 | -* BUG FIX: Items dated December 31, 1969 should appear less often. The | |
| 299 | +* BUG FIX: Items dated Decembr 31, 1969 should appear less often. The | |
| 936 | 300 | function for parsing W3C date-time format dates that ships with |
| 937 | 301 | MagpieRSS can only correctly parse fully-specified dates with a |
| 938 | 302 | fully-specified time, but valid W3C date-time format dates may omit the |
| 939 | 303 | time, the day of the month, or even the month. Some feeds in the wild |
| @@ -958,9 +322,9 @@ | ||
| 958 | 322 | that all the examples of improper side-effects that I can find now |
| 959 | 323 | require an HTTP POST to take effect. I think I got pretty much |
| 960 | 324 | everything; if there's anything that I missed, let me know. |
| 961 | 325 | |
| 962 | - Further reading: [Sam Ruby 2005-05-06: This Stuff Matters](http://www.intertwingly.net/blog/2005/05/06/This-Stuff-Matters) | |
| 326 | + Further reading: [Sam Ruby 2005-05-06: This Stuff Matters] (http://www.intertwingly.net/blog/2005/05/06/This-Stuff-Matters) | |
| 963 | 327 | |
| 964 | 328 | * BUG FIX: Categories applied by `cats` setting should no longer prevent |
| 965 | 329 | category-based filtering from working. In FeedWordPress, you can (1) |
| 966 | 330 | apply certain categories to all syndicated posts, or all posts from |
| @@ -1068,10 +432,9 @@ | ||
| 1068 | 432 | into the WordPress database so that (among other things) that post |
| 1069 | 433 | will have its enclosure listed in your blog's RSS 2 newsfeed. |
| 1070 | 434 | |
| 1071 | 435 | Note that enclosure support requires using the optional MagpieRSS |
| 1072 | - upgrade (i.e., replacing your `wp-includes/rss-functions.php` with | |
| 1073 | - `OPTIONAL/wp-includes/rss-functions.php` from the FWP archive) | |
| 436 | + upgrade (i.e., replacing your `wp-includes/rss-functions.php` with `OPTIONAL/wp-includes/rss-functions.php` from the FWP archive) | |
| 1074 | 437 | |
| 1075 | 438 | * FEATURE: for completeness's sake, there is now a feed setting, |
| 1076 | 439 | `hardcode url`, that allows you to set the URI for the front page |
| 1077 | 440 | of a contributor's website manually (that is, prevent it from being |
