PluginProbe
FeedWordPress / 0.981
FeedWordPress v0.981
trunk 0.8 0.9 0.91 0.95 0.96 0.97 0.98 0.981 0.99 0.991 0.992 0.993 2008.1030 2008.1101 2008.1105 2008.1214 2009.0612 2009.0613 2009.0618 2009.0707 2009.1111 2009.1112 2010.0127 2010.0528 All 65 releases
← All changes | ChangeLog.text +239 -2 0.960.981 View file →
@@ -1,6 +1,243 @@
1 -Change Log
2 -==========
1 +FeedWordPress Change Log
2 +========================
3 +
4 +Changes from 0.98 to 0.981
5 +--------------------------
6 +
7 +Version 0.981 is a narrowly targeted bugfix and compatibility release, whose
8 +main purpose is to resolve a major outstanding problem: the incompatibility
9 +between version 0.98 of WordPress and the recently released WordPress 2.1.
10 +
11 +* WORDPRESS 2.1 COMPATIBILITY: FeedWordPress is now compatible with
12 + WordPress 2.1, as well as retaining its existing support for WordPress
13 + 2.0 and 1.5. Incompatibilities that resulted in database warnings, fatal
14 + errors, and which prevented FeedWordPress from syndicating new posts,
15 + have been eliminated.
16 +
17 +* RSS-FUNCTIONS.PHP RENAMED TO RSS.PHP: if you use the upgraded MagpieRSS
18 + replacement that's included with FeedWordPress, be sure to note that
19 + there are now *two* files to upload from the `OPTIONAL/wp-includes`
20 + subdirectory in order to carry out the upgrade: rss-functions.php and
21 + rss.php. **It is necessary to upload both files**, due to a change in
22 + the file naming scheme in WordPress 2.1, and it is necessary to do so
23 + whether you are using WordPress 2.1 or not. If you only upload the
24 + `rss-functions.php` file as in previous installations you will not have
25 + a working copy of MagpieRSS; the rss.php file contains the actual code.
26 +
27 +* DATE BUG AFFECTING SOME PHP INSTALLATIONS RESOLVED: due to a subtle bug
28 + in parse_w3cdtf(), some installations of PHP encountered problems with
29 + FeedWordPress's attempt to date posts, which would cause some new posts
30 + on Atom feeds to be dated as if they had apppeared in 1969 or 1970
31 + (thus, effectively, never appearing on front apge at all). This bug in
32 + the date handling should now be fixed.
33 +
34 +* PHP <?=...?> SHORT FORM ELIMINATED: some installations of PHP do not
35 + allow the <?=...?> short form for printing PHP values, which was used
36 + extensively in the FeedWordPress interface code. Since this could cause
37 + fatal errors for users with the wrong installation of PHP, the short
38 + form has been replaced with full PHP echo statements, and is no longer
39 + used in FeedWordPress.
40 +
41 +* BETTER USER INTERFACE INTEGRATION WITH WORDPRESS 2.x: Some minor changes
42 + have been made to help the FeedWordPress interface pages blend in better
43 + with the user interface when running under WordPress 2.x.
44 +
45 +* GLOBAL CATEGORIES BUG RESOLVED: a bug that prevented some users from
46 + setting one or more categories to apply to syndicated posts from all
47 + feeds (using the checkbox interface under Options --> Syndication) has
48 + been resolved.
49 +
50 +Changes from 0.97 to 0.98
51 +--------------------------
52 +
53 +* WORDPRESS 2.0 COMPATIBILITY: This is a narrowly-targeted release to
54 + solve a major outstanding problem. FeedWordPress is now compatible with
55 + both WordPress 1.5 and WordPress 2.0. Incompatibilities that caused
56 + fatal SQL errors, and a more subtle bug with off-kilter counts of posts
57 + under a given category, have been resolved. FeedWordPress tests for
58 + database schema using the global $wp_db_version variable (if null, then
59 + we presume that we're dealing with WordPress 1.5).
60 +
61 + NOTE: I have **not** fully tested FeedWordPress with WordPress 2.0.
62 + Further testing may reveal more bugs. However, you should now be able
63 + to get at least basic FeedWordPress functionality up and running.
64 +
65 +* AUTHOR MATCHING: FeedWordPress tests several fields to see if it can
66 + identify the author of the post as a user already in the WordPress user
67 + database. In previous versions, it tested the user login, the nickname,
68 + and tested for "aliases" listed in the Profile (see documentation). FWP
69 + now also matches authors on the basis of e-mail address (*if* an e-mail
70 + address is present). This is particularly helpful for formats such as
71 + RSS 2.0, in which authors are primarily identified by e-mail addresses.
72 +
73 +Changes from 0.96 to 0.97
74 +-------------------------
75 +
76 +* INSTALLATION PROCEDURE: Some of the changes between 0.96 and 0.97
77 + require upgrades to the meta-data stored by FeedWordPress to work
78 + properly. Thus, if you are upgrading from 0.96 or earlier to 0.97, most
79 + FeedWordPress operations (including updates and template functions)
80 + WILL BE DISABLED until you run the upgrade procedure. Fortunately,
81 + running the upgrade procedure is easy: just go to either Options -->
82 + Syndication or Links --> Syndicated in the WordPress Dashboard and press
83 + the button.
84 +
85 +* FEED FORMAT SUPPORT: Support has been added for the Atom 1.0 IETF
86 + standard. Several other elements are also newly supported
87 + (dcterms:created, dcterms:issued, dcterms:modified, dc:identifier,
88 + proper support for the RSS 2.0 guid element, the RSS 2.0 author element,
89 + the use of Atom author or Dublin Core dc:creator constructs at the feed
90 + level to identify the author of individual items, etc.)
91 +
92 + N.B.: full support of several Atom 1.0 features, such as categories
93 + and enclosures, requires you to install the optional rss-functions.php
94 + upgrade in your wp-includes directory.
95 +
96 +* BUG FIX: Running `update-feeds.php` from command line or crontab
97 + returned "I don't syndicate..." errors. It turns out that WordPress
98 + sometimes tramples on the internal PHP superglobals that I depended on
99 + to determine whether or not the script was being invoked from the
100 + command line. This has been fixed (the variables are now checked
101 + *before* WordPress can trample them). Note that `update-feeds.php` has
102 + been thoroughly overhauled anyway; see below for details.
103 +
104 +* BUG FIX: Duplicate categories or author names. Fixed two bugs that could
105 + create duplicate author and/or category names when the name contained
106 + either (a) certain international characters (causing a mismatch between
107 + MySQL and PHP's handling of lowercasing text), or (b) characters that
108 + have a special meaning in regular expressions (causing MySQL errors when
109 + looking for the author or category due to regexp syntax errors). These
110 + should now be fixed thanks to careful escaping of names that go into
111 + regular expressions and careful matching of lowercasing functions
112 + (comparing results from PHP only to other results from PHP, and results
113 + from MySQL only to other results from MySQL).
114 +
115 +* BUG FIX: Items dated Decembr 31, 1969 should appear less often. The
116 + function for parsing W3C date-time format dates that ships with
117 + MagpieRSS can only correctly parse fully-specified dates with a
118 + fully-specified time, but valid W3C date-time format dates may omit the
119 + time, the day of the month, or even the month. Some feeds in the wild
120 + date their items with coarse-grained dates, so the optional
121 + `rss-functions.php` upgrade now includes a more flexible parse_w3cdtf()
122 + function that will work with both coarse-grained and fully-specified
123 + dates. (If parts of the date or the time are omitted, they are filled in
124 + with values based on the current time, so '2005-09-10' will be dated to
125 + the current time on that day; '2004' will be dated to this day and time
126 + one year ago.
127 +
128 + N.B.: This fix is only available in the optional `rss-functions.php`
129 + upgrade.
130 +
131 +* BUG FIX: Evil use of HTTP GET has been undone. The WordPress interface
132 + is riddled with inappropriate (non-idempotent) uses of HTTP GET queries
133 + (ordinary links that make the server do something with significant
134 + side-effects, such as deleting a post or a link from the database).
135 + FeedWordPress did some of this too, especially in places where it aped
136 + the WordPress interface (e.g. the "Delete" links in Links -->
137 + Syndicated). That's bad business, though. I've changed the interface so
138 + that all the examples of improper side-effects that I can find now
139 + require an HTTP POST to take effect. I think I got pretty much
140 + everything; if there's anything that I missed, let me know.
141 +
142 + Further reading: [Sam Ruby 2005-05-06: This Stuff Matters] (http://www.intertwingly.net/blog/2005/05/06/This-Stuff-Matters)
143 +
144 +* BUG FIX: Categories applied by `cats` setting should no longer prevent
145 + category-based filtering from working. In FeedWordPress, you can (1)
146 + apply certain categories to all syndicated posts, or all posts from
147 + a particular feed; and (2) filter out all posts that don't match one
148 + of the categories that are already in the WordPress database (allowing
149 + for simple category-based filtering; just load up WordPress with the
150 + categories you want to accept, and then tell FeedWordPress not to create
151 + new ones). However, the way that (1) and (2) were implemented meant that
152 + you couldn't effectively use them together; once you applied a known
153 + category to all syndicated posts from a particular feed, it meant that
154 + they'd have at least one familiar category (the category or categories
155 + you were applying), and that would get all posts past the filter no
156 + matter what categories they were originally from.
157 +
158 + Well, no longer. You can still apply categories to all syndicated posts
159 + (using either Syndication --> Options, or the feed-level settings under
160 + Links --> Syndicated). But these categories are not applied to the post
161 + until *after* it has already passed by the "familiar categories" filter.
162 + So now, if you want, you can do category filtering and *then* apply as
163 + many categories as you please to all and only posts that pass the filter.
164 +
165 +* BUG FIX: Other minor typos and HTML gaffes were fixed along the way.
166 +
167 +* PERFORMANCE: get_feed_meta() no longer hits the database for information
168 + on every call; it now caches link data in memory, so FeedWordPress only
169 + goes to the database once for each syndicated link. This may
170 + substantially improve performance if your database server resources
171 + are tight and your templates make a lot of use of custom settings from
172 + get_feed_meta().
173 +
174 +* API CHANGE: Link ID numbers, rather than RSS URIs, are now used to
175 + identify the feed from which a post is syndicated when you use template
176 + functions such as get_feed_meta(). The practical upshot of this is you
177 + can switch feeds, or change the feed address for a particular syndicated
178 + site, without breaking your templates for all the posts that were
179 + syndicated from the earlier URI.
180 +
181 +* API CHANGE: if you have plugins or templates that make use of the
182 + get_feed_meta() function or the $fwp_feedmeta global, note that the
183 + data formerly located under the `uri` and `name` fields is now located
184 + under the `link/uri` field and the `link/name` field, respectively. Note
185 + also that you can access the link ID number for any given feed under the
186 + global $fwp_feedmeta['link/id'] (in plugins) or
187 + get_feed_meta('link/id') (in a template in post contexts).
188 +
189 +* FEATURE: the settings for individual feeds can now be edited using a
190 + humane interface (where formerly you had to tweak key-value pairs in the
191 + Link Notes section). To edit settings for a feed, pick the feed that you
192 + want under Links --> Syndicated and click the Edit link.
193 +
194 +* FEATURE: The "Unsubscribe" button (formerly "Delete") in Links -->
195 + Syndicated now offers three options for unsubscribing from a feed: (1)
196 + turning off the subscription without deleting the feed data or affecting
197 + posts that were syndicated from the feed (this works by setting the Link
198 + for the feed as "invisible"); (2) deleting the feed data and all of the
199 + posts that were syndicated from the feed; or (3) deleting the feed data
200 + and *keeping* the posts that were syndicated from the feed
201 + setting the Link to "Invisible" (meaning that it will not be displayed
202 + in lists of the site links on the front page, and it won't be checked
203 + for updates; (2) deleting the Link and all of the posts that were
204 + syndicated from its feed; or (3) deleting the feed data but keeping the
205 + posts that were syndicated (which will henceforward be treated as if
206 + they were local rather than syndicated posts). (Note that (1) is usually
207 + the best option for aggregator sites, unless you want to clean up the
208 + results of an error or a test.)
209 +
210 +* FEATURE / BUG FIX: If you have been receiving mysterious "I don't
211 + syndicate...", or "(local) HTTP status code was not 200", or "(local)
212 + transport error - could not open socket", or "parse error - not well
213 + formed" errors, then this update may solve your problems, and if it does
214 + *not* solve them, it will at least make the reasons for the problems
215 + easier to understand. That's because I've overhauled the way that
216 + FeedWordPress goes about updating feeds.
217 +
218 + If you use the command-line PHP scripting method to run scheduled
219 + updates, then not much should change for you, except for fewer
220 + mysterious errors. If you have done updates by sending periodic HTTP
221 + requests to <http://your-blog.com/path/wp-content/update-feeds.php>,
222 + then the details have changed somewhat; mostly in such a way as to make
223 + things easier on you. See the README file or online documentation on
224 + Staying Current for the details.
225 +
226 +* FEATURE: FeedWordPress now features a more sophisticated system for
227 + timed updates. Instead of polling *every* subscribed feed for updates
228 + *each* time `update-feeds.php` is run, FeedWordPress now keeps track of
229 + the last time it polled each feed, and only polls them again after a
230 + certain period of time has passed. The amount of time is normally set
231 + randomly for each feed, in a period between 30 minutes and 2 hours (so
232 + 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
233 + directly by the feed, which brings us to ...
234 +
235 +* FEATURE: FeedWordPress now respects the settings in the `ttl` and
236 + Syndication Module RSS elements. Feeds with these elements set will not
237 + be polled any more frequently than they indicate with these feeds unless
238 + the user manually forces FeedWordPress to poll the feed (see Links -->
239 + Syndicated --> Edit settings).
3 240
4 241 Changes from 0.95 to 0.96
5 242 -------------------------
6 243