| @@ -1,174 +1,6 @@ | ||
| 1 | -FeedWordPress Change Log | |
| 2 | -======================== | |
| 3 | - | |
| 4 | -Changes from 0.96 to 0.97 | |
| 5 | - | |
| 6 | -* INSTALLATION PROCEDURE: Some of the changes between 0.96 and 0.97 | |
| 7 | - require upgrades to the meta-data stored by FeedWordPress to work | |
| 8 | - properly. Thus, if you are upgrading from 0.96 or earlier to 0.97, most | |
| 9 | - FeedWordPress operations (including updates and template functions) | |
| 10 | - WILL BE DISABLED until you run the upgrade procedure. Fortunately, | |
| 11 | - running the upgrade procedure is easy: just go to either Options --> | |
| 12 | - Syndication or Links --> Syndicated in the WordPress Dashboard and press | |
| 13 | - the button. | |
| 14 | - | |
| 15 | -* FEED FORMAT SUPPORT: Support has been added for the Atom 1.0 IETF | |
| 16 | - standard. Several other elements are also newly supported | |
| 17 | - (dcterms:created, dcterms:issued, dcterms:modified, dc:identifier, | |
| 18 | - proper support for the RSS 2.0 guid element, the RSS 2.0 author element, | |
| 19 | - the use of Atom author or Dublin Core dc:creator constructs at the feed | |
| 20 | - level to identify the author of individual items, etc.) | |
| 21 | - | |
| 22 | - N.B.: full support of several Atom 1.0 features, such as categories | |
| 23 | - and enclosures, requires you to install the optional rss-functions.php | |
| 24 | - upgrade in your wp-includes directory. | |
| 25 | - | |
| 26 | -* BUG FIX: Running `update-feeds.php` from command line or crontab | |
| 27 | - returned "I don't syndicate..." errors. It turns out that WordPress | |
| 28 | - sometimes tramples on the internal PHP superglobals that I depended on | |
| 29 | - to determine whether or not the script was being invoked from the | |
| 30 | - command line. This has been fixed (the variables are now checked | |
| 31 | - *before* WordPress can trample them). Note that `update-feeds.php` has | |
| 32 | - been thoroughly overhauled anyway; see below for details. | |
| 33 | - | |
| 34 | -* BUG FIX: Duplicate categories or author names. Fixed two bugs that could | |
| 35 | - create duplicate author and/or category names when the name contained | |
| 36 | - either (a) certain international characters (causing a mismatch between | |
| 37 | - MySQL and PHP's handling of lowercasing text), or (b) characters that | |
| 38 | - have a special meaning in regular expressions (causing MySQL errors when | |
| 39 | - looking for the author or category due to regexp syntax errors). These | |
| 40 | - should now be fixed thanks to careful escaping of names that go into | |
| 41 | - regular expressions and careful matching of lowercasing functions | |
| 42 | - (comparing results from PHP only to other results from PHP, and results | |
| 43 | - from MySQL only to other results from MySQL). | |
| 44 | - | |
| 45 | -* BUG FIX: Items dated Decembr 31, 1969 should appear less often. The | |
| 46 | - function for parsing W3C date-time format dates that ships with | |
| 47 | - MagpieRSS can only correctly parse fully-specified dates with a | |
| 48 | - fully-specified time, but valid W3C date-time format dates may omit the | |
| 49 | - time, the day of the month, or even the month. Some feeds in the wild | |
| 50 | - date their items with coarse-grained dates, so the optional | |
| 51 | - `rss-functions.php` upgrade now includes a more flexible parse_w3cdtf() | |
| 52 | - function that will work with both coarse-grained and fully-specified | |
| 53 | - dates. (If parts of the date or the time are omitted, they are filled in | |
| 54 | - with values based on the current time, so '2005-09-10' will be dated to | |
| 55 | - the current time on that day; '2004' will be dated to this day and time | |
| 56 | - one year ago. | |
| 57 | - | |
| 58 | - N.B.: This fix is only available in the optional `rss-functions.php` | |
| 59 | - upgrade. | |
| 60 | - | |
| 61 | -* BUG FIX: Evil use of HTTP GET has been undone. The WordPress interface | |
| 62 | - is riddled with inappropriate (non-idempotent) uses of HTTP GET queries | |
| 63 | - (ordinary links that make the server do something with significant | |
| 64 | - side-effects, such as deleting a post or a link from the database). | |
| 65 | - FeedWordPress did some of this too, especially in places where it aped | |
| 66 | - the WordPress interface (e.g. the "Delete" links in Links --> | |
| 67 | - Syndicated). That's bad business, though. I've changed the interface so | |
| 68 | - that all the examples of improper side-effects that I can find now | |
| 69 | - require an HTTP POST to take effect. I think I got pretty much | |
| 70 | - everything; if there's anything that I missed, let me know. | |
| 71 | - | |
| 72 | - Further reading: [Sam Ruby 2005-05-06: This Stuff Matters] (http://www.intertwingly.net/blog/2005/05/06/This-Stuff-Matters) | |
| 73 | - | |
| 74 | -* BUG FIX: Categories applied by `cats` setting should no longer prevent | |
| 75 | - category-based filtering from working. In FeedWordPress, you can (1) | |
| 76 | - apply certain categories to all syndicated posts, or all posts from | |
| 77 | - a particular feed; and (2) filter out all posts that don't match one | |
| 78 | - of the categories that are already in the WordPress database (allowing | |
| 79 | - for simple category-based filtering; just load up WordPress with the | |
| 80 | - categories you want to accept, and then tell FeedWordPress not to create | |
| 81 | - new ones). However, the way that (1) and (2) were implemented meant that | |
| 82 | - you couldn't effectively use them together; once you applied a known | |
| 83 | - category to all syndicated posts from a particular feed, it meant that | |
| 84 | - they'd have at least one familiar category (the category or categories | |
| 85 | - you were applying), and that would get all posts past the filter no | |
| 86 | - matter what categories they were originally from. | |
| 87 | - | |
| 88 | - Well, no longer. You can still apply categories to all syndicated posts | |
| 89 | - (using either Syndication --> Options, or the feed-level settings under | |
| 90 | - Links --> Syndicated). But these categories are not applied to the post | |
| 91 | - until *after* it has already passed by the "familiar categories" filter. | |
| 92 | - So now, if you want, you can do category filtering and *then* apply as | |
| 93 | - many categories as you please to all and only posts that pass the filter. | |
| 94 | - | |
| 95 | -* BUG FIX: Other minor typos and HTML gaffes were fixed along the way. | |
| 96 | - | |
| 97 | -* PERFORMANCE: get_feed_meta() no longer hits the database for information | |
| 98 | - on every call; it now caches link data in memory, so FeedWordPress only | |
| 99 | - goes to the database once for each syndicated link. This may | |
| 100 | - substantially improve performance if your database server resources | |
| 101 | - are tight and your templates make a lot of use of custom settings from | |
| 102 | - get_feed_meta(). | |
| 103 | - | |
| 104 | -* API CHANGE: Link ID numbers, rather than RSS URIs, are now used to | |
| 105 | - identify the feed from which a post is syndicated when you use template | |
| 106 | - functions such as get_feed_meta(). The practical upshot of this is you | |
| 107 | - can switch feeds, or change the feed address for a particular syndicated | |
| 108 | - site, without breaking your templates for all the posts that were | |
| 109 | - syndicated from the earlier URI. | |
| 110 | - | |
| 111 | -* API CHANGE: if you have plugins or templates that make use of the | |
| 112 | - get_feed_meta() function or the $fwp_feedmeta global, note that the | |
| 113 | - data formerly located under the `uri` and `name` fields is now located | |
| 114 | - under the `link/uri` field and the `link/name` field, respectively. Note | |
| 115 | - also that you can access the link ID number for any given feed under the | |
| 116 | - global $fwp_feedmeta['link/id'] (in plugins) or | |
| 117 | - get_feed_meta('link/id') (in a template in post contexts). | |
| 118 | - | |
| 119 | -* FEATURE: the settings for individual feeds can now be edited using a | |
| 120 | - humane interface (where formerly you had to tweak key-value pairs in the | |
| 121 | - Link Notes section). To edit settings for a feed, pick the feed that you | |
| 122 | - want under Links --> Syndicated and click the Edit link. | |
| 123 | - | |
| 124 | -* FEATURE: The "Unsubscribe" button (formerly "Delete") in Links --> | |
| 125 | - Syndicated now offers three options for unsubscribing from a feed: (1) | |
| 126 | - turning off the subscription without deleting the feed data or affecting | |
| 127 | - posts that were syndicated from the feed (this works by setting the Link | |
| 128 | - for the feed as "invisible"); (2) deleting the feed data and all of the | |
| 129 | - posts that were syndicated from the feed; or (3) deleting the feed data | |
| 130 | - and *keeping* the posts that were syndicated from the feed | |
| 131 | - setting the Link to "Invisible" (meaning that it will not be displayed | |
| 132 | - in lists of the site links on the front page, and it won't be checked | |
| 133 | - for updates; (2) deleting the Link and all of the posts that were | |
| 134 | - syndicated from its feed; or (3) deleting the feed data but keeping the | |
| 135 | - posts that were syndicated (which will henceforward be treated as if | |
| 136 | - they were local rather than syndicated posts). (Note that (1) is usually | |
| 137 | - the best option for aggregator sites, unless you want to clean up the | |
| 138 | - results of an error or a test.) | |
| 139 | - | |
| 140 | -* FEATURE / BUG FIX: If you have been receiving mysterious "I don't | |
| 141 | - syndicate...", or "(local) HTTP status code was not 200", or "(local) | |
| 142 | - transport error - could not open socket", or "parse error - not well | |
| 143 | - formed" errors, then this update may solve your problems, and if it does | |
| 144 | - *not* solve them, it will at least make the reasons for the problems | |
| 145 | - easier to understand. That's because I've overhauled the way that | |
| 146 | - FeedWordPress goes about updating feeds. | |
| 147 | - | |
| 148 | - If you use the command-line PHP scripting method to run scheduled | |
| 149 | - updates, then not much should change for you, except for fewer | |
| 150 | - mysterious errors. If you have done updates by sending periodic HTTP | |
| 151 | - requests to <http://your-blog.com/path/wp-content/update-feeds.php>, | |
| 152 | - then the details have changed somewhat; mostly in such a way as to make | |
| 153 | - things easier on you. See the README file or online documentation on | |
| 154 | - Staying Current for the details. | |
| 155 | - | |
| 156 | -* FEATURE: FeedWordPress now features a more sophisticated system for | |
| 157 | - timed updates. Instead of polling *every* subscribed feed for updates | |
| 158 | - *each* time `update-feeds.php` is run, FeedWordPress now keeps track of | |
| 159 | - the last time it polled each feed, and only polls them again after a | |
| 160 | - certain period of time has passed. The amount of time is normally set | |
| 161 | - randomly for each feed, in a period between 30 minutes and 2 hours (so | |
| 162 | - as to stagger updates over time rather than polling all of the feeds at once. However, the length of time between updates can also be set | |
| 163 | - directly by the feed, which brings us to ... | |
| 164 | - | |
| 165 | -* FEATURE: FeedWordPress now respects the settings in the `ttl` and | |
| 166 | - Syndication Module RSS elements. Feeds with these elements set will not | |
| 167 | - be polled any more frequently than they indicate with these feeds unless | |
| 168 | - the user manually forces FeedWordPress to poll the feed (see Links --> | |
| 169 | - Syndicated --> Edit settings). | |
| 1 | +Change Log | |
| 2 | +========== | |
| 170 | 3 | |
| 171 | 4 | Changes from 0.95 to 0.96 |
| 172 | 5 | ------------------------- |
| 173 | 6 | |
