| @@ -1,7 +1,389 @@ | ||
| 1 | 1 | FeedWordPress Change Log |
| 2 | 2 | ======================== |
| 3 | +Changes from 2009.0707 to Trunk | |
| 4 | +------------------------------- | |
| 3 | 5 | |
| 6 | +### Compatibility ### | |
| 7 | + | |
| 8 | +* SIMPLEPIE IS NOW USED TO PARSE FEEDS; NO MORE MAGPIERSS UPGRADES NEEDED: | |
| 9 | + One of the biggest changes in this release is that FeedWordPress no | |
| 10 | + longer depends on MagpieRSS to parse feeds, and has switched to the much | |
| 11 | + more up-to-date and flexible SimplePie feed parser, which is included as | |
| 12 | + a standard part of WordPress versions 2.8 and later. Using SimplePie will | |
| 13 | + hopefully allow for better handling of feeds going further, and will | |
| 14 | + allow me greater flexibility in determining how exactly the feed parser | |
| 15 | + will operate. It also means that FeedWordPress no longer requires | |
| 16 | + special upgrades to the WordPress core MagpieRSS files, and should | |
| 17 | + eliminate quite a bit of complexity. | |
| 18 | + | |
| 19 | +* MAGPIERSS COMPATIBILITY LAYER FOR EXISTING FILTERS AND ADD-ONS: However, | |
| 20 | + I have also implemented a compatibility layer to ensure that existing | |
| 21 | + filters and add-ons for FeedWordPress which depended on the MagpieRSS | |
| 22 | + data format *should not be broken* by the switch to SimplePie. Going | |
| 23 | + forward, I recommend that new filters and add-ons be written to take | |
| 24 | + advantage of the SimplePie object representations of items, feeds, etc., | |
| 25 | + rather than the MagpieRSS arrays, but the MagpieRSS arrays will still | |
| 26 | + be available and older filters should continue to work as they have in | |
| 27 | + the past. | |
| 28 | + | |
| 29 | +* COMPATIBILITY WITH WORDPRESS 2.9.x and 3.0: This release has been tested | |
| 30 | + for the existing WordPress 2.9.x branch and with the upcoming release of | |
| 31 | + WordPress 3.0. Changes in the user interface JavaScript between WordPress | |
| 32 | + 2.8.x and WordPress 2.9 caused the tag box interface element to break in | |
| 33 | + the Syndication --> Categories & Tags settings page; changes in the API | |
| 34 | + functions for adding new authors caused fatal errors under certain | |
| 35 | + conditions in WordPress 3.0. These breakages have been fixed. | |
| 36 | + | |
| 37 | +* DROPPED LEGACY SUPPORT FOR WORDPRESS PRIOR TO 2.8: Because SimplePie is | |
| 38 | + not included with versions of WordPress prior to 2.8, I have chosen to | |
| 39 | + drop legacy support for WordPress versions 1.5 through 2.7. If you are | |
| 40 | + using FeedWordPress with a version of WordPress before 2.8, you will | |
| 41 | + have to upgrade your installation of WordPress in order to take | |
| 42 | + advantage of this release. | |
| 43 | + | |
| 44 | +* PHP 5.3 COMPATIBILITY: A couple of compatibility issues, which were | |
| 45 | + causing fatal errors amd ugly warnings for users of PHP 5.3, | |
| 46 | + have been eliminated. | |
| 47 | + | |
| 48 | +### Features and Processing ### | |
| 49 | + | |
| 50 | +* INTERFACE REORGANIZATION: The interface restructuring, began with | |
| 51 | + Version 2009.0612, has been completed. Catch-all settings pages have | |
| 52 | + been eliminated entirely for pages that cover each aspect of handling | |
| 53 | + a feed: Feeds & Updates, Posts & Links, Authors, Categories & Tags, | |
| 54 | + and Back End handling of the database and diagnostic information. | |
| 55 | + Extensive new interface hooks allow add-on modules to significantly | |
| 56 | + change or extend the FeedWordPress admin interface and workflow. | |
| 57 | + | |
| 58 | +* STORING INFORMATION FROM THE FEED IN CUSTOM FIELDS: Many users | |
| 59 | + have written to request the ability to store information from elements | |
| 60 | + in the feed in a custom field on each post. (So that, for example, if | |
| 61 | + post includes a `itunes:duration` element, you could store the contents | |
| 62 | + in a Custom Field called `duration` on the post (for a Theme to access | |
| 63 | + later). The Custom Post Settings under Syndication --> Posts & Links now | |
| 64 | + allow you to access any item or feed tag, using a syntax similar to | |
| 65 | + a much-simplified version of XPath. See Posts & Links settings for | |
| 66 | + details. | |
| 67 | + | |
| 68 | +* UPDATE-FREEZING ON MANUALLY EDITED POSTS: FeedWordPress now allows you | |
| 69 | + to mark posts that have been manually edited, so that the changes you | |
| 70 | + make will not be overwritten by later updates from the feed. If you make | |
| 71 | + manual edits to a particular post, just check the "Manual editing" | |
| 72 | + checkbox in order to protect your changes from being overwritten. If you | |
| 73 | + want to block *all* posts from being updated after they are imported | |
| 74 | + for the first time, a new "Updated Posts" setting in Posts & Links | |
| 75 | + allows you to freeze all posts from a particular feed, or all syndicated | |
| 76 | + posts. | |
| 77 | + | |
| 78 | +* SETTING: FEED-BY-FEED SETTINGS FOR WHERE PERMALINKS POINT TO: You've | |
| 79 | + always been able to tell FeedWordPress whether permalinks for posts | |
| 80 | + should point to the original source of the story or the local copy. Now | |
| 81 | + you can choose different policies for different feeds, instead of one | |
| 82 | + global policy for all feeds. (Of course, you can still use a global | |
| 83 | + default if you prefer.) | |
| 84 | + | |
| 85 | +* SETTING: USER CONTROL OVER TIMING BASIS. You can now determine the | |
| 86 | + schedule on which feeds are considered ready to poll for updates -- | |
| 87 | + by default feeds become ready for polling after about 1 hour. You can | |
| 88 | + now increase or decrease the time window under Syndication --> Feeds & | |
| 89 | + Updates. (However, please pay *CAREFUL ATTENTION* to the recommendations | |
| 90 | + and DO NOT set the scheduling lower than 60 minutes unless you are | |
| 91 | + ABSOLUTELY SURE that you have specific permission from webmaster who | |
| 92 | + provides that specific feed to poll more frequently than that. If you | |
| 93 | + set this too low (and about 60 minutes is the polite minimum if you | |
| 94 | + haven't been given a different figure), most webmasters will consider | |
| 95 | + the frequent hits on their server as rude, or even downright abusive. | |
| 96 | + | |
| 97 | +* OTHER SETTINGS: New settings also include the ability to stop FWP from | |
| 98 | + resolving relative URLs within syndicated content, and the ability to | |
| 99 | + choose whether FeedWordPress should indicate the comment feed from the | |
| 100 | + original source, or the local comment feed, when providing the comment | |
| 101 | + feed URL for a syndicated post. | |
| 102 | + | |
| 103 | +### PARSING ### | |
| 104 | + | |
| 105 | +* BETTER DATE HANDLING -- FEWER FLASHBACKS TO 1969 and 1970: FeedWordPress | |
| 106 | + has made some bugfixes and some improvements in the logic for parsing | |
| 107 | + dates. This should allow FeedWordPress to correctly parse more dates in | |
| 108 | + more feeds; and, in the last resort, when FeedWordPress fails to | |
| 109 | + correctly parse a date, to fall back to a more intelligent default. This | |
| 110 | + should hopefully avoid most or all error conditions that have resulted | |
| 111 | + in articles being erroneously dated to the dawn of the Unix epoch | |
| 112 | + (31 December 1969 or 1 January 1970). | |
| 113 | + | |
| 114 | +* FULL-TEXT "EXCERPTS" NOW PROPERLY SHORTENED. Based on a straightforward | |
| 115 | + reading of the existing RSS specs, it's reasonable for the | |
| 116 | + rss:description element to be read as a plaintext summary or excerpt for | |
| 117 | + the item containing the description -- with the full text of the item, | |
| 118 | + if available, in another, better-suited element, such as the de facto | |
| 119 | + standard content:encoded extension element. The problem is that uses of | |
| 120 | + RSS rarely have much to do with anything like a straightforward reading | |
| 121 | + of the specs. As a result, many actual RSS producers in the wild put the | |
| 122 | + full text of the article in a description element. But since | |
| 123 | + FeedWordPress has treated this text as a summary, this produces | |
| 124 | + aggregated posts with lengthy "excerpts" containing the full text of the | |
| 125 | + article. This release of FeedWordPress fixes the problem by doing a | |
| 126 | + little digging before treating rss:description as a summary: if the | |
| 127 | + description element is used properly as a plain text summary, then | |
| 128 | + FeedWordPress will take the summary provided by the feed, rather than | |
| 129 | + recreating its own excerpt from the full text; but if an RSS item has no | |
| 130 | + full-text element other than description, FeedWordPress will treat the | |
| 131 | + description element as the full text of the article, and generate a | |
| 132 | + shortened excerpt automatically from that text. | |
| 133 | + | |
| 134 | +### API ### | |
| 135 | + | |
| 136 | +* TEMPLATE API: new template tags `get_local_permalink()` and | |
| 137 | + `the_local_permalink()` allow you to access the permalink for a post on | |
| 138 | + your aggregator site, even when FeedWordPress is rewriting permalinks to | |
| 139 | + point to the original source site. | |
| 140 | + | |
| 141 | +* NEW HOOKS FOR ADD-ONS AND FILTERS: I have added a number of new hooks | |
| 142 | + which allow add-on modules to filter more precisely, gather information | |
| 143 | + at more points, and to enhance the FeedWordPress admin interface. For | |
| 144 | + a list of new hooks and documentation, see the FeedWordPress | |
| 145 | + documentation wiki at | |
| 146 | + <http://feedwordpress.radgeek.com/wiki/add-ons-and-filters> | |
| 147 | + | |
| 148 | +* FILTER API: A number of new utility methods have been added to the | |
| 149 | + SyndicatedPost class to make it easier for filters and add-ons to | |
| 150 | + | |
| 151 | +* FILTER API: Globals $fwp_channel and $fwp_feedmeta DEPRECATED. These | |
| 152 | + global variables, originally introduced to allow filters access to | |
| 153 | + information about the source feed in `syndicated_item` filters (which | |
| 154 | + were passed in through global variables rather than as parameters | |
| 155 | + because of a bug in WP 1.5 which was then fixed in 1.5.1) have been | |
| 156 | + DEPRECATED. If you have any filters or add-ons which still depend on | |
| 157 | + these global variables, you should see about fixing them to access data | |
| 158 | + about the source feed using the SyndicatedPost::link element instead. | |
| 159 | + For documentation, see the FeedWordPress documentation wiki at | |
| 160 | + <http://feedwordpress.radgeek.com/wiki/syndicatedpost> and | |
| 161 | + <http://feedwordpress.radgeek.com/wiki/syndicatedlink>. | |
| 162 | + | |
| 163 | +* DIAGNOSTICS: I've included a number of new diagnostic options and | |
| 164 | + messages, which should allow an experienced user to better investigate | |
| 165 | + any problems that may crop up. | |
| 166 | + | |
| 167 | +### Bug Fixes ### | |
| 168 | + | |
| 169 | +* BUGFIX: & IN PERMALINKS NO LONGER CAUSING ATOM OR HTML VALIDATION | |
| 170 | + EFFORTS: Many users reported an issue in which syndicating a feed with | |
| 171 | + special XML characters in the URLs (& was the most common, since it is | |
| 172 | + used to separate HTTP GET parameters) would cause the aggregator's | |
| 173 | + feeds to produce invalid (malformed) XML. This update addresses the | |
| 174 | + issue in Atom feeds. Unfortunately, it has not been technically possible | |
| 175 | + to address the problem in RSS 2.0 feeds, due to limitations on | |
| 176 | + WordPress's internal templates for RSS feeds. | |
| 177 | + | |
| 178 | +* BUGFIX: BROKEN URLS IN "POPULAR POSTS" AND SIMILAR PLUGINS SHOULD NO | |
| 179 | + LONGER BE BROKEN. A number of users noticed an issue where plugins and | |
| 180 | + templates that listed posts in locations outside of the post loop | |
| 181 | + (for example, "Popular Posts"-style plugins that listed posts in the | |
| 182 | + sidebar), often produced the wrong URL for post links. (Typically, all | |
| 183 | + the posts listed would get the same wrong URL.) This should now be | |
| 184 | + fixed. Thanks to Björn for sending in a quick fix! | |
| 185 | + | |
| 186 | +* MINOR BUGFIXES: This release includes a number of fixes to minor bugs | |
| 187 | + and compatibility issues, including: silent failures of the "Syndicate" | |
| 188 | + button, "Illegal Offset Type" error messages from MagpieRSS, | |
| 189 | + | |
| 190 | + | |
| 191 | +Changes from 2009.0618 to 2009.0707 | |
| 192 | +----------------------------------- | |
| 193 | +* BUGFIX: WORDPRESS 2.8 AJAX COMPATIBILITY ISSUES RESOLVED (blank or | |
| 194 | + truncated "Syndicated Sites" administration page): Due to changes in the | |
| 195 | + AJAX interface elements between WordPress 2.7 and WordPress 2.8, several | |
| 196 | + FeedWordPress users encountered an issue where the front "Syndication" | |
| 197 | + page in the FeedWordPress administrative interface would come up blank, | |
| 198 | + without the normal "Syndicated Sites" list and "Update" control, or | |
| 199 | + sometimes wth the boxes visible but one or both of them truncated, with | |
| 200 | + only the title bar. This issue should now be resolved: with the new | |
| 201 | + version of FeedWordPress, the compatibility issue that caused the | |
| 202 | + disappearance should be eliminated, and if boxes are shown with only | |
| 203 | + their handle visible, you should once again be able to drop down the | |
| 204 | + rest of the box by clicking once on its title bar. | |
| 205 | + | |
| 206 | +* BUGFIX: TAG SETTING WIDGET FIXED. Due to changes in interface elements | |
| 207 | + between WordPress 2.7 and WordPress 2.8, people using FeedWordPress with | |
| 208 | + WordPress 2.8 found that the widget for setting tags to be applied to | |
| 209 | + all syndicated posts, or all syndicated posts from a particular feed, | |
| 210 | + no longer displayed "Add" and "Remove" buttons for individual tags. This | |
| 211 | + issue has now been fixed, and the tagging widget should once again work | |
| 212 | + more or less exactly like the tagging widget for individual posts in the | |
| 213 | + normal WordPress admin interface. | |
| 214 | + | |
| 215 | +Changes from 2009.0613 to 2009.0618 | |
| 216 | +----------------------------------- | |
| 217 | +* BUGFIX: MYSTERY ERRORS WITH WITH WP_Http_Fsockopen HTTP TRANSPORT | |
| 218 | + ELIMINATED: Thanks to a combination of a subtle bug in FeedWordPress, | |
| 219 | + and changes to the HTTP transport code in WordPress, a number of users | |
| 220 | + encountered an error in which any time they attempted to add a new feed | |
| 221 | + through the FeedFinder interface, FeedWordPress would fail and display | |
| 222 | + an HTTP request failure diagnostic message. The subtle bug has been | |
| 223 | + fixed, and with it, most of these errors should now be eliminated. | |
| 224 | + | |
| 225 | + Be sure to upgrade your MagpieRSS to the most recent MagpieRSS version | |
| 226 | + after you have insalled FeedWordPress 2009.0618, or this bug fix will | |
| 227 | + not take effect. | |
| 228 | + | |
| 229 | + | |
| 230 | +Changes from 2009.0612 to 2009.0613 | |
| 231 | +----------------------------------- | |
| 232 | +* INTERFACE/BUGFIX: WORDPRESS 2.8 CATEGORY BOX FIX. Thanks to a subtle | |
| 233 | + change in class names between the WordPress 2.7 and 2.8 stylesheets, | |
| 234 | + category boxes in the FeedWordPress settings interface tended to overflow | |
| 235 | + and have a lot of messy-looking overlapping text under WordPress 2.8. | |
| 236 | + This has now been fixed. | |
| 237 | + | |
| 238 | +* FeedFinder FAILURE DIAGNOSTICS: When FWP's FeedFinder fails to find any | |
| 239 | + feeds at a given URL (for example, when you are trying to add a | |
| 240 | + subscription through the administrative interface and you run into an | |
| 241 | + error message), FeedWordPress now provides more diagnostic information | |
| 242 | + for the reasons behind the failure. If that helps you, great; if not, | |
| 243 | + it should help me respond more intelligently to your support request.. | |
| 244 | + | |
| 245 | +Changes from 2008.1214 to 2009.0612 | |
| 246 | +----------------------------------- | |
| 247 | +* WORDPRESS 2.8 COMPATIBILITY: FeedWordPress 2009.0612 has been tested for | |
| 248 | + compatibility with the recent version 2.8 release of WordPress. | |
| 249 | + | |
| 250 | +* INTERFACE RESTRUCTURING: In order to avoid settings posts from becoming | |
| 251 | + too crowded, and to modularize and better organize the user interface, | |
| 252 | + new "Posts" and "Categories & Tags" subpages have been created under the | |
| 253 | + "Syndication" menu. "Posts" controls settings for individal syndicated | |
| 254 | + posts (such as publication status, comment and ping status, whether or | |
| 255 | + not to use the original location of the post as the permalink, whether | |
| 256 | + or not to expose posts to formatting filters, and so on). "Categories & | |
| 257 | + Tags" controls settings for assigning new syndicated posts to categories | |
| 258 | + and tags, such as categories or tags to apply to all syndicated posts, | |
| 259 | + and how to handle categories that do not yet exist in the WordPress | |
| 260 | + database. These subpages, like the Authors subpage, handle settings for | |
| 261 | + the global default level and for individual syndicated feeds. | |
| 262 | + | |
| 263 | + Corresponding to these new subpages, the old Syndication Settings and | |
| 264 | + Feed Settings subpages have been cleaned up and simplified, and now only | |
| 265 | + link to the appropriate subpages for options that can be set in the | |
| 266 | + Posts, Authors, or Categories & Tags subpages. | |
| 267 | + | |
| 268 | +* FEATURE: ADD CUSTOM SETTINGS TO EACH SYNDICATED POST: FeedWordPress has | |
| 269 | + long had an interface for creating custom settings for each syndicated | |
| 270 | + *feed* which could be retrieved in templates using the `get_feed_meta()` | |
| 271 | + template function. But it had no feature for adding custom fields to | |
| 272 | + each individual syndicated *post*. In response to requests from users, I | |
| 273 | + have added the ability to apply custom fields to each individual | |
| 274 | + syndicated post, using the new Syndication --> Posts subpage. You can | |
| 275 | + set up custom fields to be applied to every syndicated post, or custom | |
| 276 | + fields to be applied to syndicated posts from a particular feed. | |
| 277 | + | |
| 278 | +* FEATURE: MAGPIERSS VERSION CHECK AND UPGRADE: FeedWordPress will attempt | |
| 279 | + to determine whether or not you are using the upgraded version of | |
| 280 | + MagpieRSS that comes packaged with FeedWordPress. If not, it will throw | |
| 281 | + an error on admin pages, and, if you are a site administrator, it will | |
| 282 | + give you the option to ignore the error message, or to attempt an | |
| 283 | + automatic upgrade (using a native file copy). If the file copy fails, | |
| 284 | + FeedWordPress will offer some guidance on how to perform the upgrade | |
| 285 | + manually. | |
| 286 | + | |
| 287 | +* BLANK POSTS PROBLEM NO LONGER OCCURS WITH OLD & BUSTED MAGPIERSS: Due | |
| 288 | + to the fact that I relied on a content normalization that occurs in my | |
| 289 | + upgraded version of MagpieRSS, but not in the old & busted version of | |
| 290 | + MagpieRSS that ships with WordPress, until this version, if you tried to | |
| 291 | + syndicate an Atom feed without having performed the (*strongly | |
| 292 | + recommended*) MagpieRSS upgrade, all of the posts would come up with | |
| 293 | + completely blank contents. That's not because MagpieRSS couldn't read | |
| 294 | + the data, but rather because the new Magpie version puts that data in a | |
| 295 | + location where the old version doesn't, and I was only looking in that | |
| 296 | + newer location. Now it checks for both, meaning that posts will continue | |
| 297 | + to display their contents even if you don't upgrade MagpieRSS. (But you | |
| 298 | + **really should** upgrade it, anyway.) | |
| 299 | + | |
| 300 | +* BUGFIX: RELATIVE URI RESOLUTION FOR POST CONTENT RESTORED. Some time | |
| 301 | + back, I added support for resolving relative URIs against xml:base on | |
| 302 | + feeds that support it to the MagpieRSS upgrade in FeedWordPress. Then I | |
| 303 | + took out code that did the same thing from the main FeedWordPress code. | |
| 304 | + Of course, the problem is that some people, even though it is clearly | |
| 305 | + stupid or evil to do so, still include relative URIs for images or links | |
| 306 | + in posts on feed formats that do *not* adequately support xml:base | |
| 307 | + (notably, RSS 2.0 feeds). In response to a user request, I have added | |
| 308 | + this functionality back in, so that MagpieRSS will resolve any relative | |
| 309 | + URIs that it knows how to resolve using xml:base, and then FeedWordPress | |
| 310 | + will attempt to resolve any relative URIs that are left over afterwards. | |
| 311 | + | |
| 312 | +* BUGFIX: INTERFACE OPTION FOR SETTING SYNDICATED POST PUBLICATION STATUS | |
| 313 | + ON A FEED-BY-FEED BASIS HAS BEEN RESTORED: Due to a version-checking | |
| 314 | + bug, users of WordPress 2.7.x lost an option from the "Edit a syndicated | |
| 315 | + feed" interface which allowed them to determine whether newly syndicated | |
| 316 | + posts should be published immediately, held as "Pending Review," saved | |
| 317 | + as drafts, or saved as private posts. (The option to change this | |
| 318 | + setting globally remained in place, but users could no longer set it on | |
| 319 | + a feed-by-feed basis.) The version-checking bug has been fixed, and the | |
| 320 | + option has been restored. | |
| 321 | + | |
| 322 | +* BUGFIX: "ARE YOU SURE?" FATAL ERROR ELIMINATED AND SECURITY IMPROVED: | |
| 323 | + Under certain circumstances (for example, when users have configured | |
| 324 | + their browser or proxy not to send HTTP Referer headers, for privacy or | |
| 325 | + other reasons), many features in the FeedWordPress administrative | |
| 326 | + interface (such as adding new feeds or changing settings) would hit a | |
| 327 | + fatal error, displaying only a cryptic message reading "Are you sure?" | |
| 328 | + and a blank page following it. This problem has been eliminated by | |
| 329 | + taking advantage of WordPress's nonce functions, which allow the | |
| 330 | + security check which ran into this error to work properly even without | |
| 331 | + receiving an HTTP Referer header. (N.B.: WordPress's nonce functions | |
| 332 | + were first introduced in WordPress 2.0.3. If you're using FeedWordPress | |
| 333 | + with an older version of WordPress, there's no fix for this problem: | |
| 334 | + you'll just need to turn Referer headers back on. Sorry.) | |
| 335 | + | |
| 336 | +* BUGFIX: MANUALLY-ALTERED POST STATUS, COMMENT STATUS, AND PING STATUS NO | |
| 337 | + LONGER REVERTED BY POST UPDATES: If you manually altered the post status, | |
| 338 | + comment status, or ping status of a syndicated post from what it was set | |
| 339 | + to when first syndicated -- for example, if you had a feed that was set | |
| 340 | + to bring in new posts as "Pending Review," and you then marked some of | |
| 341 | + the pending posts as "Published" and others as "Unpublished" -- then | |
| 342 | + in previous versions of FeedWordPress, these manual changes to the | |
| 343 | + status would be lost -- so that, for example, your Published or Unpublished | |
| 344 | + articles would revert to Pending Review -- if the source feed made any | |
| 345 | + upates to the item. This could make the Pending Review feature both | |
| 346 | + unreliable and also extremely frustrating to work with. The good news is | |
| 347 | + that this bug has since been fixed: if you manually update the status | |
| 348 | + of a post, it will no longer be reverted if or when the post is updated. | |
| 349 | + | |
| 350 | +* BUGFIX: OCCASIONAL FATAL ERROR ON UPDATE ELIMINATED: Under certain | |
| 351 | + limited conditions (specifically, when both the title and the content of | |
| 352 | + a post to be updated are empty), an attempt to update the post would | |
| 353 | + result in a fatal error. This has been fixed. | |
| 354 | + | |
| 355 | +* INTERFACE: "CONFIGURE SETTINGS" CONVENIENCE LINK ADDED TO CONFIRMATION | |
| 356 | + MESSAGE WHEN A NEW FEED IS ADDED: When you add a new subscription to | |
| 357 | + FeedWordPress, the message box that appears to confirm it now includes a | |
| 358 | + handy link to the feed's settings subpage, so that you can quickly set | |
| 359 | + up any special settings you may want to set up for the new feed, without | |
| 360 | + having to hunt through the list of all your other subscriptions to pick | |
| 361 | + out the new one. | |
| 362 | + | |
| 363 | +* INTERFACE: SIMPLIFYING AND CLARIFYING AUTOMATIC UPDATES SETTINGS. I have | |
| 364 | + removed an interval setting for the cronless automatic updates which has | |
| 365 | + confused many FeedWordPress users. In past versions of FWP, when you | |
| 366 | + turned on automatic updates, you would be presented with a time interval | |
| 367 | + setting which controlled how often FeedWordPress would check for feeds | |
| 368 | + ready to be polled for updates. (That is, it DID NOT control how often | |
| 369 | + feeds *would be polled*; it controlled how often FeedWordPress would | |
| 370 | + *check* for feeds that *had become ready to poll*. The schedule on which | |
| 371 | + feeds became ready for polling was still controlled either by requests | |
| 372 | + encoded in elements within the feed itself, or else according to an | |
| 373 | + internal calculation within FeedWordPress, averaging out to about 1 hour, | |
| 374 | + if the feed did not include any scheduling request elements.) Since many | |
| 375 | + users very often (and understandably) confused the purpose of this | |
| 376 | + setting, and since the setting is for a feature that's actually very | |
| 377 | + unlikely to require any manual control by the user, I have removed the | |
| 378 | + setting; FeedWordPress now simply uses the default value of checking for | |
| 379 | + feeds to poll every 10 minutes. | |
| 380 | + | |
| 381 | +* FEEDFINDER PERFORMANCE IMPROVEMENT: FeedWordPress's FeedFinder class | |
| 382 | + now uses `array_unique()` to make sure that it doesn't waste time | |
| 383 | + repeatedly iterating over and polling the same URI. Props to Camilo | |
| 384 | + (<http://projects.radgeek.com/2008/12/14/feedwordpress-20081214/#comment-20090122160414>). | |
| 385 | + | |
| 4 | 386 | Changes from 2008.1105 to 2008.1214 |
| 5 | 387 | ----------------------------------- |
| 6 | 388 | |
| 7 | 389 | * WORDPRESS 2.7 COMPATIBILITY: FeedWordPress has been tested for |
| @@ -465,9 +847,9 @@ | ||
| 465 | 847 | * DATE BUG AFFECTING SOME PHP INSTALLATIONS RESOLVED: due to a subtle bug |
| 466 | 848 | in parse_w3cdtf(), some installations of PHP encountered problems with |
| 467 | 849 | FeedWordPress's attempt to date posts, which would cause some new posts |
| 468 | 850 | on Atom feeds to be dated as if they had apppeared in 1969 or 1970 |
| 469 | - (thus, effectively, never appearing on front apge at all). This bug in | |
| 851 | + (thus, effectively, never appearing on front page at all). This bug in | |
| 470 | 852 | the date handling should now be fixed. |
| 471 | 853 | |
| 472 | 854 | * PHP <?=...?> SHORT FORM ELIMINATED: some installations of PHP do not |
| 473 | 855 | allow the <?=...?> short form for printing PHP values, which was used |
| @@ -549,9 +931,9 @@ | ||
| 549 | 931 | regular expressions and careful matching of lowercasing functions |
| 550 | 932 | (comparing results from PHP only to other results from PHP, and results |
| 551 | 933 | from MySQL only to other results from MySQL). |
| 552 | 934 | |
| 553 | -* BUG FIX: Items dated Decembr 31, 1969 should appear less often. The | |
| 935 | +* BUG FIX: Items dated December 31, 1969 should appear less often. The | |
| 554 | 936 | function for parsing W3C date-time format dates that ships with |
| 555 | 937 | MagpieRSS can only correctly parse fully-specified dates with a |
| 556 | 938 | fully-specified time, but valid W3C date-time format dates may omit the |
| 557 | 939 | time, the day of the month, or even the month. Some feeds in the wild |
| @@ -576,9 +958,9 @@ | ||
| 576 | 958 | that all the examples of improper side-effects that I can find now |
| 577 | 959 | require an HTTP POST to take effect. I think I got pretty much |
| 578 | 960 | everything; if there's anything that I missed, let me know. |
| 579 | 961 | |
| 580 | - Further reading: [Sam Ruby 2005-05-06: This Stuff Matters] (http://www.intertwingly.net/blog/2005/05/06/This-Stuff-Matters) | |
| 962 | + Further reading: [Sam Ruby 2005-05-06: This Stuff Matters](http://www.intertwingly.net/blog/2005/05/06/This-Stuff-Matters) | |
| 581 | 963 | |
| 582 | 964 | * BUG FIX: Categories applied by `cats` setting should no longer prevent |
| 583 | 965 | category-based filtering from working. In FeedWordPress, you can (1) |
| 584 | 966 | apply certain categories to all syndicated posts, or all posts from |
