| @@ -1,216 +1,7 @@ | ||
| 1 | 1 | FeedWordPress Change Log |
| 2 | 2 | ======================== |
| 3 | -Changes from 2009.0613 to 2009.0618 | |
| 4 | -* BUGFIX: MYSTERY ERRORS WITH WITH WP_Http_Fsockopen HTTP TRANSPORT | |
| 5 | - ELIMINATED: Thanks to a combination of a subtle bug in FeedWordPress, | |
| 6 | - and changes to the HTTP transport code in WordPress, a number of users | |
| 7 | - encountered an error in which any time they attempted to add a new feed | |
| 8 | - through the FeedFinder interface, FeedWordPress would fail and display | |
| 9 | - an HTTP request failure diagnostic message. The subtle bug has been | |
| 10 | - fixed, and with it, most of these errors should now be eliminated. | |
| 11 | - | |
| 12 | - Be sure to upgrade your MagpieRSS to the most recent MagpieRSS version | |
| 13 | - after you have insalled FeedWordPress 2009.0618, or this bug fix will | |
| 14 | - not take effect. | |
| 15 | 3 | |
| 16 | - | |
| 17 | -Changes from 2009.0612 to 2009.0613 | |
| 18 | -* INTERFACE/BUGFIX: WORDPRESS 2.8 CATEGORY BOX FIX. Thanks to a subtle | |
| 19 | - change in class names between the WordPress 2.7 and 2.8 stylesheets, | |
| 20 | - category boxes in the FeedWordPress settings interface tended to overflow | |
| 21 | - and have a lot of messy-looking overlapping text under WordPress 2.8. | |
| 22 | - This has now been fixed. | |
| 23 | - | |
| 24 | -* FeedFinder FAILURE DIAGNOSTICS: When FWP's FeedFinder fails to find any | |
| 25 | - feeds at a given URL (for example, when you are trying to add a | |
| 26 | - subscription through the administrative interface and you run into an | |
| 27 | - error message), FeedWordPress now provides more diagnostic information | |
| 28 | - for the reasons behind the failure. If that helps you, great; if not, | |
| 29 | - it should help me respond more intelligently to your support request.. | |
| 30 | - | |
| 31 | -Changes from 2008.1214 to 2009.0612 | |
| 32 | -* WORDPRESS 2.8 COMPATIBILITY: FeedWordPress 2009.0612 has been tested for | |
| 33 | - compatibility with the recent version 2.8 release of WordPress. | |
| 34 | - | |
| 35 | -* INTERFACE RESTRUCTURING: In order to avoid settings posts from becoming | |
| 36 | - too crowded, and to modularize and better organize the user interface, | |
| 37 | - new "Posts" and "Categories & Tags" subpages have been created under the | |
| 38 | - "Syndication" menu. "Posts" controls settings for individal syndicated | |
| 39 | - posts (such as publication status, comment and ping status, whether or | |
| 40 | - not to use the original location of the post as the permalink, whether | |
| 41 | - or not to expose posts to formatting filters, and so on). "Categories & | |
| 42 | - Tags" controls settings for assigning new syndicated posts to categories | |
| 43 | - and tags, such as categories or tags to apply to all syndicated posts, | |
| 44 | - and how to handle categories that do not yet exist in the WordPress | |
| 45 | - database. These subpages, like the Authors subpage, handle settings for | |
| 46 | - the global default level and for individual syndicated feeds. | |
| 47 | - | |
| 48 | - Corresponding to these new subpages, the old Syndication Settings and | |
| 49 | - Feed Settings subpages have been cleaned up and simplified, and now only | |
| 50 | - link to the appropriate subpages for options that can be set in the | |
| 51 | - Posts, Authors, or Categories & Tags subpages. | |
| 52 | - | |
| 53 | -* FEATURE: ADD CUSTOM SETTINGS TO EACH SYNDICATED POST: FeedWordPress has | |
| 54 | - long had an interface for creating custom settings for each syndicated | |
| 55 | - *feed* which could be retrieved in templates using the `get_feed_meta()` | |
| 56 | - template function. But it had no feature for adding custom fields to | |
| 57 | - each individual syndicated *post*. In response to requests from users, I | |
| 58 | - have added the ability to apply custom fields to each individual | |
| 59 | - syndicated post, using the new Syndication --> Posts subpage. You can | |
| 60 | - set up custom fields to be applied to every syndicated post, or custom | |
| 61 | - fields to be applied to syndicated posts from a particular feed. | |
| 62 | - | |
| 63 | -* FEATURE: MAGPIERSS VERSION CHECK AND UPGRADE: FeedWordPress will attempt | |
| 64 | - to determine whether or not you are using the upgraded version of | |
| 65 | - MagpieRSS that comes packaged with FeedWordPress. If not, it will throw | |
| 66 | - an error on admin pages, and, if you are a site administrator, it will | |
| 67 | - give you the option to ignore the error message, or to attempt an | |
| 68 | - automatic upgrade (using a native file copy). If the file copy fails, | |
| 69 | - FeedWordPress will offer some guidance on how to perform the upgrade | |
| 70 | - manually. | |
| 71 | - | |
| 72 | -* BLANK POSTS PROBLEM NO LONGER OCCURS WITH OLD & BUSTED MAGPIERSS: Due | |
| 73 | - to the fact that I relied on a content normalization that occurs in my | |
| 74 | - upgraded version of MagpieRSS, but not in the old & busted version of | |
| 75 | - MagpieRSS that ships with WordPress, until this version, if you tried to | |
| 76 | - syndicate an Atom feed without having performed the (*strongly | |
| 77 | - recommended*) MagpieRSS upgrade, all of the posts would come up with | |
| 78 | - completely blank contents. That's not because MagpieRSS couldn't read | |
| 79 | - the data, but rather because the new Magpie version puts that data in a | |
| 80 | - location where the old version doesn't, and I was only looking in that | |
| 81 | - newer location. Now it checks for both, meaning that posts will continue | |
| 82 | - to display their contents even if you don't upgrade MagpieRSS. (But you | |
| 83 | - **really should** upgrade it, anyway.) | |
| 84 | - | |
| 85 | -* BUGFIX: RELATIVE URI RESOLUTION FOR POST CONTENT RESTORED. Some time | |
| 86 | - back, I added support for resolving relative URIs against xml:base on | |
| 87 | - feeds that support it to the MagpieRSS upgrade in FeedWordPress. Then I | |
| 88 | - took out code that did the same thing from the main FeedWordPress code. | |
| 89 | - Of course, the problem is that some people, even though it is clearly | |
| 90 | - stupid or evil to do so, still include relative URIs for images or links | |
| 91 | - in posts on feed formats that do *not* adequately support xml:base | |
| 92 | - (notably, RSS 2.0 feeds). In response to a user request, I have added | |
| 93 | - this functionality back in, so that MagpieRSS will resolve any relative | |
| 94 | - URIs that it knows how to resolve using xml:base, and then FeedWordPress | |
| 95 | - will attempt to resolve any relative URIs that are left over afterwards. | |
| 96 | - | |
| 97 | -* BUGFIX: INTERFACE OPTION FOR SETTING SYNDICATED POST PUBLICATION STATUS | |
| 98 | - ON A FEED-BY-FEED BASIS HAS BEEN RESTORED: Due to a version-checking | |
| 99 | - bug, users of WordPress 2.7.x lost an option from the "Edit a syndicated | |
| 100 | - feed" interface which allowed them to determine whether newly syndicated | |
| 101 | - posts should be published immediately, held as "Pending Review," saved | |
| 102 | - as drafts, or saved as private posts. (The option to change this | |
| 103 | - setting globally remained in place, but users could no longer set it on | |
| 104 | - a feed-by-feed basis.) The version-checking bug has been fixed, and the | |
| 105 | - option has been restored. | |
| 106 | - | |
| 107 | -* BUGFIX: "ARE YOU SURE?" FATAL ERROR ELIMINATED AND SECURITY IMPROVED: | |
| 108 | - Under certain circumstances (for example, when users have configured | |
| 109 | - their browser or proxy not to send HTTP Referer headers, for privacy or | |
| 110 | - other reasons), many features in the FeedWordPress administrative | |
| 111 | - interface (such as adding new feeds or changing settings) would hit a | |
| 112 | - fatal error, displaying only a cryptic message reading "Are you sure?" | |
| 113 | - and a blank page following it. This problem has been eliminated by | |
| 114 | - taking advantage of WordPress's nonce functions, which allow the | |
| 115 | - security check which ran into this error to work properly even without | |
| 116 | - receiving an HTTP Referer header. (N.B.: WordPress's nonce functions | |
| 117 | - were first introduced in WordPress 2.0.3. If you're using FeedWordPress | |
| 118 | - with an older version of WordPress, there's no fix for this problem: | |
| 119 | - you'll just need to turn Referer headers back on. Sorry.) | |
| 120 | - | |
| 121 | -* BUGFIX: MANUALLY-ALTERED POST STATUS, COMMENT STATUS, AND PING STATUS NO | |
| 122 | - LONGER REVERTED BY POST UPDATES: If you manually altered the post status, | |
| 123 | - comment status, or ping status of a syndicated post from what it was set | |
| 124 | - to when first syndicated -- for example, if you had a feed that was set | |
| 125 | - to bring in new posts as "Pending Review," and you then marked some of | |
| 126 | - the pending posts as "Published" and others as "Unpublished" -- then | |
| 127 | - in previous versions of FeedWordPress, these manual changes to the | |
| 128 | - status would be lost -- so that, for example, your Published or Unpublished | |
| 129 | - articles would revert to Pending Review -- if the source feed made any | |
| 130 | - upates to the item. This could make the Pending Review feature both | |
| 131 | - unreliable and also extremely frustrating to work with. The good news is | |
| 132 | - that this bug has since been fixed: if you manually update the status | |
| 133 | - of a post, it will no longer be reverted if or when the post is updated. | |
| 134 | - | |
| 135 | -* BUGFIX: OCCASIONAL FATAL ERROR ON UPDATE ELIMINATED: Under certain | |
| 136 | - limited conditions (specifically, when both the title and the content of | |
| 137 | - a post to be updated are empty), an attempt to update the post would | |
| 138 | - result in a fatal error. This has been fixed. | |
| 139 | - | |
| 140 | -* INTERFACE: "CONFIGURE SETTINGS" CONVENIENCE LINK ADDED TO CONFIRMATION | |
| 141 | - MESSAGE WHEN A NEW FEED IS ADDED: When you add a new subscription to | |
| 142 | - FeedWordPress, the message box that appears to confirm it now includes a | |
| 143 | - handy link to the feed's settings subpage, so that you can quickly set | |
| 144 | - up any special settings you may want to set up for the new feed, without | |
| 145 | - having to hunt through the list of all your other subscriptions to pick | |
| 146 | - out the new one. | |
| 147 | - | |
| 148 | -* INTERFACE: SIMPLIFYING AND CLARIFYING AUTOMATIC UPDATES SETTINGS. I have | |
| 149 | - removed an interval setting for the cronless automatic updates which has | |
| 150 | - confused many FeedWordPress users. In past versions of FWP, when you | |
| 151 | - turned on automatic updates, you would be presented with a time interval | |
| 152 | - setting which controlled how often FeedWordPress would check for feeds | |
| 153 | - ready to be polled for updates. (That is, it DID NOT control how often | |
| 154 | - feeds *would be polled*; it controlled how often FeedWordPress would | |
| 155 | - *check* for feeds that *had become ready to poll*. The schedule on which | |
| 156 | - feeds became ready for polling was still controlled either by requests | |
| 157 | - encoded in elements within the feed itself, or else according to an | |
| 158 | - internal calculation within FeedWordPress, averaging out to about 1 hour, | |
| 159 | - if the feed did not include any scheduling request elements.) Since many | |
| 160 | - users very often (and understandably) confused the purpose of this | |
| 161 | - setting, and since the setting is for a feature that's actually very | |
| 162 | - unlikely to require any manual control by the user, I have removed the | |
| 163 | - setting; FeedWordPress now simply uses the default value of checking for | |
| 164 | - feeds to poll every 10 minutes. | |
| 165 | - | |
| 166 | -* FEEDFINDER PERFORMANCE IMPROVEMENT: FeedWordPress's FeedFinder class | |
| 167 | - now uses `array_unique()` to make sure that it doesn't waste time | |
| 168 | - repeatedly iterating over and polling the same URI. Props to Camilo | |
| 169 | - (<http://projects.radgeek.com/2008/12/14/feedwordpress-20081214/#comment-20090122160414>). | |
| 170 | - | |
| 171 | -Changes from 2008.1105 to 2008.1214 | |
| 172 | - | |
| 173 | -* WORDPRESS 2.7 COMPATIBILITY: FeedWordPress has been tested for | |
| 174 | - compatibility with the newly released WordPress 2.7. WordPress 2.7 has | |
| 175 | - deprecated the Snoopy library for HTTP requests, which caused a fatal | |
| 176 | - error for users who had not installed the MagpieRSS upgrade (or whose | |
| 177 | - installation of the MagpieRSS upgrade was overwritten by a recent update | |
| 178 | - of WordPress). FeedWordPress now handles things gracefully when Snoopy | |
| 179 | - is not immediately available. | |
| 180 | - | |
| 181 | -* INTERFACE SPIFFED UP: Interface elements have been updated so that | |
| 182 | - FeedWordPress's management interface fits in more naturally with the | |
| 183 | - WordPress 2.7 interface (including a new logo and a number of small | |
| 184 | - interface tweaks). | |
| 185 | - | |
| 186 | -* BUG WITH TAGS FOR SYNDICATED ARTICLES FIXED: Several users encountered a | |
| 187 | - bug with the option to add tags to all syndicated posts under | |
| 188 | - Syndication --> Settings -- if you told FeedWordPress to add more than | |
| 189 | - one tag to all syndicated posts, instead of doing so correctly, it would | |
| 190 | - add a *single* tag instead, whose name was composed of the names of all | |
| 191 | - the tags you asked it to add. This bug was the result of nothing more | |
| 192 | - dignified than a typographical error on my part. It has now been fixed. | |
| 193 | - | |
| 194 | -* MORE INFORMATION AVAILABLE WHEN FEEDWORDPRESS CAN'T FIND A FEED: When | |
| 195 | - you enter a URL for a new syndication source, FeedWordPress uses a | |
| 196 | - simple feed-finding algorithm (originally based on Mark Pilgrim's | |
| 197 | - Universal Feed Finder) to try to determine whether the URL is the URL | |
| 198 | - for a feed, or, if the URL points to an ordinary website rather than to | |
| 199 | - a feed, whether there is a feed for that website. All well and good, but | |
| 200 | - if FeedWordPress failed to find a feed, for whatever reason, it would | |
| 201 | - typically return nothing more than a nasty little note to the effect of | |
| 202 | - "no feed found," without any explanation of what went wrong. | |
| 203 | - FeedWordPress now keeps track of error conditions from the HTTP | |
| 204 | - requests that it uses in the course of looking for the feed, and so may | |
| 205 | - be able to give you a bit more information about the nature of the | |
| 206 | - problem if something goes wrong. | |
| 207 | - | |
| 208 | - | |
| 209 | 4 | Changes from 2008.1101 to 2008.1105 |
| 210 | 5 | ----------------------------------- |
| 211 | 6 | |
| 212 | 7 | * INTERFACE RESTRUCTURING AND SYNDICATION --> AUTHORS PAGE: As a first |
| @@ -635,9 +426,9 @@ | ||
| 635 | 426 | * DATE BUG AFFECTING SOME PHP INSTALLATIONS RESOLVED: due to a subtle bug |
| 636 | 427 | in parse_w3cdtf(), some installations of PHP encountered problems with |
| 637 | 428 | FeedWordPress's attempt to date posts, which would cause some new posts |
| 638 | 429 | on Atom feeds to be dated as if they had apppeared in 1969 or 1970 |
| 639 | - (thus, effectively, never appearing on front page at all). This bug in | |
| 430 | + (thus, effectively, never appearing on front apge at all). This bug in | |
| 640 | 431 | the date handling should now be fixed. |
| 641 | 432 | |
| 642 | 433 | * PHP <?=...?> SHORT FORM ELIMINATED: some installations of PHP do not |
| 643 | 434 | allow the <?=...?> short form for printing PHP values, which was used |
| @@ -719,9 +510,9 @@ | ||
| 719 | 510 | regular expressions and careful matching of lowercasing functions |
| 720 | 511 | (comparing results from PHP only to other results from PHP, and results |
| 721 | 512 | from MySQL only to other results from MySQL). |
| 722 | 513 | |
| 723 | -* BUG FIX: Items dated December 31, 1969 should appear less often. The | |
| 514 | +* BUG FIX: Items dated Decembr 31, 1969 should appear less often. The | |
| 724 | 515 | function for parsing W3C date-time format dates that ships with |
| 725 | 516 | MagpieRSS can only correctly parse fully-specified dates with a |
| 726 | 517 | fully-specified time, but valid W3C date-time format dates may omit the |
| 727 | 518 | time, the day of the month, or even the month. Some feeds in the wild |
| @@ -746,9 +537,9 @@ | ||
| 746 | 537 | that all the examples of improper side-effects that I can find now |
| 747 | 538 | require an HTTP POST to take effect. I think I got pretty much |
| 748 | 539 | everything; if there's anything that I missed, let me know. |
| 749 | 540 | |
| 750 | - Further reading: [Sam Ruby 2005-05-06: This Stuff Matters](http://www.intertwingly.net/blog/2005/05/06/This-Stuff-Matters) | |
| 541 | + Further reading: [Sam Ruby 2005-05-06: This Stuff Matters] (http://www.intertwingly.net/blog/2005/05/06/This-Stuff-Matters) | |
| 751 | 542 | |
| 752 | 543 | * BUG FIX: Categories applied by `cats` setting should no longer prevent |
| 753 | 544 | category-based filtering from working. In FeedWordPress, you can (1) |
| 754 | 545 | apply certain categories to all syndicated posts, or all posts from |
