PluginProbe
FeedWordPress / 2009.1111
FeedWordPress v2009.1111
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 +437 -9 0.993 → 2009.1111 View file →
@@ -1,7 +1,434 @@
1 1 FeedWordPress Change Log
2 2 ========================
3 +Changes from 2009.0707 to Trunk
4 +-------------------------------
5 +* NEW INTERFACE HOOKS
3 6
7 +* FILTER API: SyndicatedPost::isTaggedAs
8 +
9 +* BUGIFX: SILENT FAILURE OF "SYNDICATE" BUTTON FIXED
10 +
11 +* BUGFIX: MagpieRSS "ILLEGAL OFFSET TYPE" ERROR MESSAGE FIXED
12 +
13 +Changes from 2009.0618 to 2009.0707
14 +-----------------------------------
15 +* BUGFIX: WORDPRESS 2.8 AJAX COMPATIBILITY ISSUES RESOLVED (blank or
16 + truncated "Syndicated Sites" administration page): Due to changes in the
17 + AJAX interface elements between WordPress 2.7 and WordPress 2.8, several
18 + FeedWordPress users encountered an issue where the front "Syndication"
19 + page in the FeedWordPress administrative interface would come up blank,
20 + without the normal "Syndicated Sites" list and "Update" control, or
21 + sometimes wth the boxes visible but one or both of them truncated, with
22 + only the title bar. This issue should now be resolved: with the new
23 + version of FeedWordPress, the compatibility issue that caused the
24 + disappearance should be eliminated, and if boxes are shown with only
25 + their handle visible, you should once again be able to drop down the
26 + rest of the box by clicking once on its title bar.
27 +
28 +* BUGFIX: TAG SETTING WIDGET FIXED. Due to changes in interface elements
29 + between WordPress 2.7 and WordPress 2.8, people using FeedWordPress with
30 + WordPress 2.8 found that the widget for setting tags to be applied to
31 + all syndicated posts, or all syndicated posts from a particular feed,
32 + no longer displayed "Add" and "Remove" buttons for individual tags. This
33 + issue has now been fixed, and the tagging widget should once again work
34 + more or less exactly like the tagging widget for individual posts in the
35 + normal WordPress admin interface.
36 +
37 +Changes from 2009.0613 to 2009.0618
38 +-----------------------------------
39 +* BUGFIX: MYSTERY ERRORS WITH WITH WP_Http_Fsockopen HTTP TRANSPORT
40 + ELIMINATED: Thanks to a combination of a subtle bug in FeedWordPress,
41 + and changes to the HTTP transport code in WordPress, a number of users
42 + encountered an error in which any time they attempted to add a new feed
43 + through the FeedFinder interface, FeedWordPress would fail and display
44 + an HTTP request failure diagnostic message. The subtle bug has been
45 + fixed, and with it, most of these errors should now be eliminated.
46 +
47 + Be sure to upgrade your MagpieRSS to the most recent MagpieRSS version
48 + after you have insalled FeedWordPress 2009.0618, or this bug fix will
49 + not take effect.
50 +
51 +
52 +Changes from 2009.0612 to 2009.0613
53 +-----------------------------------
54 +* INTERFACE/BUGFIX: WORDPRESS 2.8 CATEGORY BOX FIX. Thanks to a subtle
55 + change in class names between the WordPress 2.7 and 2.8 stylesheets,
56 + category boxes in the FeedWordPress settings interface tended to overflow
57 + and have a lot of messy-looking overlapping text under WordPress 2.8.
58 + This has now been fixed.
59 +
60 +* FeedFinder FAILURE DIAGNOSTICS: When FWP's FeedFinder fails to find any
61 + feeds at a given URL (for example, when you are trying to add a
62 + subscription through the administrative interface and you run into an
63 + error message), FeedWordPress now provides more diagnostic information
64 + for the reasons behind the failure. If that helps you, great; if not,
65 + it should help me respond more intelligently to your support request..
66 +
67 +Changes from 2008.1214 to 2009.0612
68 +-----------------------------------
69 +* WORDPRESS 2.8 COMPATIBILITY: FeedWordPress 2009.0612 has been tested for
70 + compatibility with the recent version 2.8 release of WordPress.
71 +
72 +* INTERFACE RESTRUCTURING: In order to avoid settings posts from becoming
73 + too crowded, and to modularize and better organize the user interface,
74 + new "Posts" and "Categories & Tags" subpages have been created under the
75 + "Syndication" menu. "Posts" controls settings for individal syndicated
76 + posts (such as publication status, comment and ping status, whether or
77 + not to use the original location of the post as the permalink, whether
78 + or not to expose posts to formatting filters, and so on). "Categories &
79 + Tags" controls settings for assigning new syndicated posts to categories
80 + and tags, such as categories or tags to apply to all syndicated posts,
81 + and how to handle categories that do not yet exist in the WordPress
82 + database. These subpages, like the Authors subpage, handle settings for
83 + the global default level and for individual syndicated feeds.
84 +
85 + Corresponding to these new subpages, the old Syndication Settings and
86 + Feed Settings subpages have been cleaned up and simplified, and now only
87 + link to the appropriate subpages for options that can be set in the
88 + Posts, Authors, or Categories & Tags subpages.
89 +
90 +* FEATURE: ADD CUSTOM SETTINGS TO EACH SYNDICATED POST: FeedWordPress has
91 + long had an interface for creating custom settings for each syndicated
92 + *feed* which could be retrieved in templates using the `get_feed_meta()`
93 + template function. But it had no feature for adding custom fields to
94 + each individual syndicated *post*. In response to requests from users, I
95 + have added the ability to apply custom fields to each individual
96 + syndicated post, using the new Syndication --> Posts subpage. You can
97 + set up custom fields to be applied to every syndicated post, or custom
98 + fields to be applied to syndicated posts from a particular feed.
99 +
100 +* FEATURE: MAGPIERSS VERSION CHECK AND UPGRADE: FeedWordPress will attempt
101 + to determine whether or not you are using the upgraded version of
102 + MagpieRSS that comes packaged with FeedWordPress. If not, it will throw
103 + an error on admin pages, and, if you are a site administrator, it will
104 + give you the option to ignore the error message, or to attempt an
105 + automatic upgrade (using a native file copy). If the file copy fails,
106 + FeedWordPress will offer some guidance on how to perform the upgrade
107 + manually.
108 +
109 +* BLANK POSTS PROBLEM NO LONGER OCCURS WITH OLD & BUSTED MAGPIERSS: Due
110 + to the fact that I relied on a content normalization that occurs in my
111 + upgraded version of MagpieRSS, but not in the old & busted version of
112 + MagpieRSS that ships with WordPress, until this version, if you tried to
113 + syndicate an Atom feed without having performed the (*strongly
114 + recommended*) MagpieRSS upgrade, all of the posts would come up with
115 + completely blank contents. That's not because MagpieRSS couldn't read
116 + the data, but rather because the new Magpie version puts that data in a
117 + location where the old version doesn't, and I was only looking in that
118 + newer location. Now it checks for both, meaning that posts will continue
119 + to display their contents even if you don't upgrade MagpieRSS. (But you
120 + **really should** upgrade it, anyway.)
121 +
122 +* BUGFIX: RELATIVE URI RESOLUTION FOR POST CONTENT RESTORED. Some time
123 + back, I added support for resolving relative URIs against xml:base on
124 + feeds that support it to the MagpieRSS upgrade in FeedWordPress. Then I
125 + took out code that did the same thing from the main FeedWordPress code.
126 + Of course, the problem is that some people, even though it is clearly
127 + stupid or evil to do so, still include relative URIs for images or links
128 + in posts on feed formats that do *not* adequately support xml:base
129 + (notably, RSS 2.0 feeds). In response to a user request, I have added
130 + this functionality back in, so that MagpieRSS will resolve any relative
131 + URIs that it knows how to resolve using xml:base, and then FeedWordPress
132 + will attempt to resolve any relative URIs that are left over afterwards.
133 +
134 +* BUGFIX: INTERFACE OPTION FOR SETTING SYNDICATED POST PUBLICATION STATUS
135 + ON A FEED-BY-FEED BASIS HAS BEEN RESTORED: Due to a version-checking
136 + bug, users of WordPress 2.7.x lost an option from the "Edit a syndicated
137 + feed" interface which allowed them to determine whether newly syndicated
138 + posts should be published immediately, held as "Pending Review," saved
139 + as drafts, or saved as private posts. (The option to change this
140 + setting globally remained in place, but users could no longer set it on
141 + a feed-by-feed basis.) The version-checking bug has been fixed, and the
142 + option has been restored.
143 +
144 +* BUGFIX: "ARE YOU SURE?" FATAL ERROR ELIMINATED AND SECURITY IMPROVED:
145 + Under certain circumstances (for example, when users have configured
146 + their browser or proxy not to send HTTP Referer headers, for privacy or
147 + other reasons), many features in the FeedWordPress administrative
148 + interface (such as adding new feeds or changing settings) would hit a
149 + fatal error, displaying only a cryptic message reading "Are you sure?"
150 + and a blank page following it. This problem has been eliminated by
151 + taking advantage of WordPress's nonce functions, which allow the
152 + security check which ran into this error to work properly even without
153 + receiving an HTTP Referer header. (N.B.: WordPress's nonce functions
154 + were first introduced in WordPress 2.0.3. If you're using FeedWordPress
155 + with an older version of WordPress, there's no fix for this problem:
156 + you'll just need to turn Referer headers back on. Sorry.)
157 +
158 +* BUGFIX: MANUALLY-ALTERED POST STATUS, COMMENT STATUS, AND PING STATUS NO
159 + LONGER REVERTED BY POST UPDATES: If you manually altered the post status,
160 + comment status, or ping status of a syndicated post from what it was set
161 + to when first syndicated -- for example, if you had a feed that was set
162 + to bring in new posts as "Pending Review," and you then marked some of
163 + the pending posts as "Published" and others as "Unpublished" -- then
164 + in previous versions of FeedWordPress, these manual changes to the
165 + status would be lost -- so that, for example, your Published or Unpublished
166 + articles would revert to Pending Review -- if the source feed made any
167 + upates to the item. This could make the Pending Review feature both
168 + unreliable and also extremely frustrating to work with. The good news is
169 + that this bug has since been fixed: if you manually update the status
170 + of a post, it will no longer be reverted if or when the post is updated.
171 +
172 +* BUGFIX: OCCASIONAL FATAL ERROR ON UPDATE ELIMINATED: Under certain
173 + limited conditions (specifically, when both the title and the content of
174 + a post to be updated are empty), an attempt to update the post would
175 + result in a fatal error. This has been fixed.
176 +
177 +* INTERFACE: "CONFIGURE SETTINGS" CONVENIENCE LINK ADDED TO CONFIRMATION
178 + MESSAGE WHEN A NEW FEED IS ADDED: When you add a new subscription to
179 + FeedWordPress, the message box that appears to confirm it now includes a
180 + handy link to the feed's settings subpage, so that you can quickly set
181 + up any special settings you may want to set up for the new feed, without
182 + having to hunt through the list of all your other subscriptions to pick
183 + out the new one.
184 +
185 +* INTERFACE: SIMPLIFYING AND CLARIFYING AUTOMATIC UPDATES SETTINGS. I have
186 + removed an interval setting for the cronless automatic updates which has
187 + confused many FeedWordPress users. In past versions of FWP, when you
188 + turned on automatic updates, you would be presented with a time interval
189 + setting which controlled how often FeedWordPress would check for feeds
190 + ready to be polled for updates. (That is, it DID NOT control how often
191 + feeds *would be polled*; it controlled how often FeedWordPress would
192 + *check* for feeds that *had become ready to poll*. The schedule on which
193 + feeds became ready for polling was still controlled either by requests
194 + encoded in elements within the feed itself, or else according to an
195 + internal calculation within FeedWordPress, averaging out to about 1 hour,
196 + if the feed did not include any scheduling request elements.) Since many
197 + users very often (and understandably) confused the purpose of this
198 + setting, and since the setting is for a feature that's actually very
199 + unlikely to require any manual control by the user, I have removed the
200 + setting; FeedWordPress now simply uses the default value of checking for
201 + feeds to poll every 10 minutes.
202 +
203 +* FEEDFINDER PERFORMANCE IMPROVEMENT: FeedWordPress's FeedFinder class
204 + now uses `array_unique()` to make sure that it doesn't waste time
205 + repeatedly iterating over and polling the same URI. Props to Camilo
206 + (<http://projects.radgeek.com/2008/12/14/feedwordpress-20081214/#comment-20090122160414>).
207 +
208 +Changes from 2008.1105 to 2008.1214
209 +-----------------------------------
210 +
211 +* WORDPRESS 2.7 COMPATIBILITY: FeedWordPress has been tested for
212 + compatibility with the newly released WordPress 2.7. WordPress 2.7 has
213 + deprecated the Snoopy library for HTTP requests, which caused a fatal
214 + error for users who had not installed the MagpieRSS upgrade (or whose
215 + installation of the MagpieRSS upgrade was overwritten by a recent update
216 + of WordPress). FeedWordPress now handles things gracefully when Snoopy
217 + is not immediately available.
218 +
219 +* INTERFACE SPIFFED UP: Interface elements have been updated so that
220 + FeedWordPress's management interface fits in more naturally with the
221 + WordPress 2.7 interface (including a new logo and a number of small
222 + interface tweaks).
223 +
224 +* BUG WITH TAGS FOR SYNDICATED ARTICLES FIXED: Several users encountered a
225 + bug with the option to add tags to all syndicated posts under
226 + Syndication --> Settings -- if you told FeedWordPress to add more than
227 + one tag to all syndicated posts, instead of doing so correctly, it would
228 + add a *single* tag instead, whose name was composed of the names of all
229 + the tags you asked it to add. This bug was the result of nothing more
230 + dignified than a typographical error on my part. It has now been fixed.
231 +
232 +* MORE INFORMATION AVAILABLE WHEN FEEDWORDPRESS CAN'T FIND A FEED: When
233 + you enter a URL for a new syndication source, FeedWordPress uses a
234 + simple feed-finding algorithm (originally based on Mark Pilgrim's
235 + Universal Feed Finder) to try to determine whether the URL is the URL
236 + for a feed, or, if the URL points to an ordinary website rather than to
237 + a feed, whether there is a feed for that website. All well and good, but
238 + if FeedWordPress failed to find a feed, for whatever reason, it would
239 + typically return nothing more than a nasty little note to the effect of
240 + "no feed found," without any explanation of what went wrong.
241 + FeedWordPress now keeps track of error conditions from the HTTP
242 + requests that it uses in the course of looking for the feed, and so may
243 + be able to give you a bit more information about the nature of the
244 + problem if something goes wrong.
245 +
246 +
247 +Changes from 2008.1101 to 2008.1105
248 +-----------------------------------
249 +
250 +* INTERFACE RESTRUCTURING AND SYNDICATION --> AUTHORS PAGE: As a first
251 + step towards modularizing and better organizing the user interface, a
252 + new "Authors" subpage has been created under the Syndication menu, which
253 + controls settings for syndicated authors, both at the global default
254 + level and at level of individual syndicated feeds.
255 +
256 +* BUG RELATED TO THE ATTRIBUTION OF POSTS TO THE WRONG AUTHOR FIXED: Some
257 + users encountered an issue in which posts by different authors on
258 + different blogs -- especially blogs generated by Blogger -- were
259 + mistakenly attributed to a single author. The problem was caused by the
260 + way in which FeedWordPress matches syndicated authors to user accounts
261 + in the WordPress database: normally, if two feeds each list an author
262 + with the same e-mail address, they are counted as being the same person.
263 + Normally this works well, but it creates an issue in cases where
264 + blogging software assigns a single anonymous e-mail address to users who
265 + do not want their real e-mail address published. This is, for example,
266 + what Blogger does (by giving all users a default e-mail address of
267 + <noreply@blogger.com> if they don't want their own e-mail address
268 + listed). FeedWordPress now allows the user to correct for this problem
269 + with a couple of new settings under **Syndication --> Authors**, which
270 + allow users to turn off e-mail based author matching for particular
271 + addresses, or, if desired, to turn it off entirely. By default, e-mail
272 + based author matching is still turned on, but disabled for a list of
273 + known generic e-mail addresses. Right now, the "list" consists entirely
274 + of <noreply@blogger.com>; if you know other addresses that should be
275 + added, please [contact me](http://radgeek.com/contact) to let me know.
276 +
277 + Please note that if you have already encountered this issue on your
278 + blog, upgrading FeedWordPress will prevent it from re-occurring in the
279 + future, but you still need to do two other things to fix the existing
280 + problem on your blog.
281 +
282 + First, for each feed where posts have been mis-attributed, you need to
283 + change the existing author mapping rules to re-map a a syndicated
284 + author's name to the proper target account. Go to **Syndication -->
285 + Authors**, select the feed you want to change from the drop-down list,
286 + and then change the settings under the "Syndicated Authors" section.
287 + (You will probably need to select "will be assigned to a new user..." to
288 + create a new user account with the appropriate name.)
289 +
290 + Second, for each feed where posts have been mis-attributed, you need to
291 + re-assign already-syndicated posts that were mis-attributed to the
292 + correct author. You can do that from **Syndication --> Authors** by
293 + using the author re-assignment feature, described below.
294 +
295 +* AUTHOR RE-ASSIGNMENT FOR A PARTICULAR FEED: The author settings page
296 + for each syndicated feed, under **Syndication --> Authors**, now
297 + includes an section titled "Fixing mis-matched authors," which provides
298 + an interface for re-assigning or deleting all posts attributed to a
299 + particular author on a particular feed.
300 +
301 +* SUPPORT FOR `<atom:source>` ELEMENT IN SYNDICATED FEEDS: Some feeds
302 + (for example, those produced by FeedWordPress) aggregate content from
303 + several different sources, and include information about the original
304 + source of the post in an `<atom:source>` element. A new setting under
305 + **Syndication --> Options** allows you to control what FeedWordPress
306 + will report as the source of posts syndicated from aggregator feeds in
307 + your templates and feeds: you can have FeedWordPress report that the
308 + source of a post is the aggregator feed itself, or you can have it
309 + report that the source of a post is the original source that the
310 + aggregator originally syndicated the post from.
311 +
312 + By default, FeedWordPress will report the aggregator, not the original
313 + source, as the source of a syndicated item.
314 +
315 +* LOAD BALANCING AND TIME LIMITING FEATURES FOR UPDATES: Some users have
316 + encountered issues due to running up against PHP execution time limits
317 + during the process of updating large syndicated feeds, or a very large
318 + set of syndicated feeds. FeedWordPress now has a feature that allows you
319 + to limit the total amount of time spent updating a feed, through the
320 + "Time limit on updates" setting under **Syndication --> Options**. By
321 + turning on this setting and adjusting the time limit to a low enough
322 + figure to avoid your PHP installation's time-out setting. (PHP execution
323 + time limits are usually in the vicinity of 30 seconds, so an update
324 + time limit of 25 seconds or so should provide plenty of time for updates
325 + while allowing a cushion of time for other, non-update-related functions
326 + to do their work.)
327 +
328 + If feed updates are interrupted by the time limit, FeedWordPress uses
329 + some simple load balancing features to make sure that updates to other
330 + feeds will not be blocked by the time-hogging feed, and will also make
331 + sure that when the interrupted update is resumed, FeedWordPress will
332 + skip ahead to resume processing items at the point at which it was
333 + interrupted last time, so that posts further down in the feed will
334 + eventually get processed, and not get blocked by the amount of time it
335 + takes to process the items higher up in the feed.
336 +
337 +* `guid` INDEX CREATION BUTTON: FeedWordPress frequently issues queries on
338 + the `guid` column of the WordPress posts database (since it uses post
339 + guid URIs to keep track of which posts it has syndicated). In very large
340 + FeedWordPress installations, you can often significantly improve
341 + performance by creating a database index on the `guid` column, but
342 + normally you would need to poke around with MySQL or a tool like
343 + phpMyAdmin to do this. FeedWordPress can now save you the trouble: to
344 + create an index on the `guid` column, just go to
345 + **Syndication --> Options**, and mash the button at the bottom of the
346 + "Back End" section.
347 +
348 +Changes from 2008.1030 to 2008.1101
349 +-----------------------------------
350 +
351 +* INTERFACE BUG THAT PREVENTED ADDING NEW SITES FIXED: The UI reforms in
352 + FWP 2008.1030 unintentionally introduced a bug that prevents clean
353 + installations of FeedWordPress from providing an input box for adding
354 + new feeds to the list of syndicated feeds. This bug has been fixed.
355 +
356 +Changes from 0.993 to 2008.1030
357 +-------------------------------
358 +
359 +* WORDPRESS 2.6 COMPATIBILITY: FeedWordPress should now be compatible with
360 + WordPress 2.6, and should work more or less seamlessly with the new post
361 + revision system. A bug which caused multiple new revisions to be created
362 + for posts on certain feeds, regardless of whether or not the item had
363 + been updated, has been fixed.
364 +
365 +* INTERFACE IMPROVEMENTS: The user interface has been substantially
366 + restyled to fit in better with the visual style of WordPress 2.5 and
367 + 2.6.
368 +
369 +* YOUTUBE BUG FIXED: POSTS SYNDICATED THROUGH AN AUTOMATIC UPDATE ARE NO
370 + LONGER STRIPPED OF `<OBJECT>` TAGS AND CERTAIN OTHER HTML ELEMENTS: Due
371 + to the way that some versions of WordPress process posts that are
372 + inserted into the database when no user is logged in, many users
373 + experienced an issue where YouTube videos and other content using the
374 + HTML `<object>` tag would be stripped out of posts that were syndicated
375 + during an automatic update. (Posts that were syndicated through manual
376 + updates from within the WordPress Dashboard were not affected, because
377 + the issue does not arise when an update is executed under a logged-in
378 + administrator's credentials.) This bug has now been fixed; YouTube
379 + videos and other content using `<object>` tags should now appear
380 + properly in syndicated posts, regardless of the way in which the post
381 + was syndicated.
382 +
383 +* AJAX BUGS FIXED: Bugs which blocked the normal operation of WordPress
384 + 2.5's AJAX interface elements when FeedWordPress was activated have been
385 + fixed.
386 +
387 +* TAG SUPPORT: A couple of features have been introduced to take advantage
388 + of the tagging features in WordPress 2.3.x, 2.5.x, and 2.6.x. Now, when
389 + unfamiliar categories are encountered for posts on a feed, you can
390 + choose for FeedWordPress (1) to drop the category; (2) to drop the
391 + category and to filter out any post that does not match at least one
392 + familiar category; (3) to create a new category with that name, or,
393 + now, you can also have FeedWordPress (4) create a new *tag* with that
394 + name. This option can be set site-wide under Syndication --> Options,
395 + or it can be set on a feed-by-feed basis in a feed's Edit screen.
396 +
397 + In addition, you can now set particular tags to apply to all incoming
398 + syndicated posts, under Syndication --> Options, or you can set tags
399 + to apply to all incoming syndicated posts from a particular feed in that
400 + feed's Edit screen.
401 +
402 +* FORMATTING FILTERS: There is a new option available under Syndication ->
403 + Options which allows users to choose whether or not to expose syndicated
404 + posts to being altered by formatting filters. By default, FeedWordPress
405 + has always protected syndicated posts (which are already in display-ready
406 + HTML when they are syndicated) from being reformatted by formatting
407 + filters. However, this approach means that certain plugins which depend
408 + on formatting filters (for example, to add "Share This" bars or relevant
409 + links to the end of a post) are blocked from working on any syndicated
410 + posts. If you want to use one of these plugins together with
411 + FeedWordPress, you can now do so by changing the "Formatting Filters"
412 + setting from "Protect" to "Expose."
413 +
414 +* `<atom:source>` ELEMENTS NOW INCLUDED IN ATOM FEED: Atom 1.0 provides
415 + a standard method for aggregators to indicate information about the original source of
416 + a syndicated post, using the `<atom:source>` element. FeedWordPress now
417 + introduces standard `<atom:source>` elements including the title, homepage, and
418 + feed URI of the source from which a syndicated post was syndicated. Cf.
419 + <http://www.atomenabled.org/developers/syndication/atom-format-spec.php#element.source>
420 +
421 +* MODULARIZATION OF CODE: The code for different elements of FeedWordPress
422 + has been broken out into several modules for easier inspection,
423 + documentation, and maintenance of the code.
424 +
425 +* VERSIONING SCHEME CHANGED: FeedWordPress's feature set has proven stable
426 + enough that it can now be removed from beta status; a good thing, since
427 + I was very quickly running out of version numbers to use. New releases
428 + of FeedWordPress will have version numbers based on the date of their
429 + release.
430 +
4 431 Changes from 0.992 to 0.993
5 432 ---------------------------
6 433
7 434 * WORDPRESS 2.5.1 COMPATIBILITY: FeedWordPress should now be compatible
@@ -63,9 +490,9 @@
63 490 has, hopefully, been resolved, by correcting for the bug in WordPress.
64 491
65 492 Changes from 0.99 to 0.991
66 493 --------------------------
67 -* WORDPRESS MU COMPATABILITY: FeedWordPress should now be compatible with
494 +* WORDPRESS MU COMPATIBILITY: FeedWordPress should now be compatible with
68 495 recent releases of WordPress MU. Once FeedWordPress is made available
69 496 as a plugin, each individual blog can choose to activate FeedWordPress
70 497 and syndicate content from its own set of contributors.
71 498
@@ -82,12 +509,12 @@
82 509 authors whose names included international characters. This
83 510 incompatability has now been fixed; hopefully, authors with
84 511 international characters in their names should now be handled properly.
85 512
86 -* media:content BUG IN MAGPIERSS FIXED: A bug in MagpieRSS's handling of
87 - namespaced elements has been fixed. Among other things, this bug caused
88 - items containing a Yahoo MediaRSS `<media:content>` element (such as
89 - many of the feeds produced by wordpress.com) to be represented
513 +* `<media:content>` BUG IN MAGPIERSS FIXED: A bug in MagpieRSS's handling
514 + of namespaced elements has been fixed. Among other things, this bug
515 + caused items containing a Yahoo MediaRSS `<media:content>` element (such
516 + as many of the feeds produced by wordpress.com) to be represented
90 517 incorrectly, with only a capital "A" where the content of the post
91 518 should have been. Feeds containing `<media:content>` elements should now
92 519 be syndicated correctly.
93 520
@@ -242,9 +669,9 @@
242 669 * DATE BUG AFFECTING SOME PHP INSTALLATIONS RESOLVED: due to a subtle bug
243 670 in parse_w3cdtf(), some installations of PHP encountered problems with
244 671 FeedWordPress's attempt to date posts, which would cause some new posts
245 672 on Atom feeds to be dated as if they had apppeared in 1969 or 1970
246 - (thus, effectively, never appearing on front apge at all). This bug in
673 + (thus, effectively, never appearing on front page at all). This bug in
247 674 the date handling should now be fixed.
248 675
249 676 * PHP <?=...?> SHORT FORM ELIMINATED: some installations of PHP do not
250 677 allow the <?=...?> short form for printing PHP values, which was used
@@ -326,9 +753,9 @@
326 753 regular expressions and careful matching of lowercasing functions
327 754 (comparing results from PHP only to other results from PHP, and results
328 755 from MySQL only to other results from MySQL).
329 756
330 -* BUG FIX: Items dated Decembr 31, 1969 should appear less often. The
757 +* BUG FIX: Items dated December 31, 1969 should appear less often. The
331 758 function for parsing W3C date-time format dates that ships with
332 759 MagpieRSS can only correctly parse fully-specified dates with a
333 760 fully-specified time, but valid W3C date-time format dates may omit the
334 761 time, the day of the month, or even the month. Some feeds in the wild
@@ -353,9 +780,9 @@
353 780 that all the examples of improper side-effects that I can find now
354 781 require an HTTP POST to take effect. I think I got pretty much
355 782 everything; if there's anything that I missed, let me know.
356 783
357 - Further reading: [Sam Ruby 2005-05-06: This Stuff Matters] (http://www.intertwingly.net/blog/2005/05/06/This-Stuff-Matters)
784 + Further reading: [Sam Ruby 2005-05-06: This Stuff Matters](http://www.intertwingly.net/blog/2005/05/06/This-Stuff-Matters)
358 785
359 786 * BUG FIX: Categories applied by `cats` setting should no longer prevent
360 787 category-based filtering from working. In FeedWordPress, you can (1)
361 788 apply certain categories to all syndicated posts, or all posts from
@@ -463,9 +890,10 @@
463 890 into the WordPress database so that (among other things) that post
464 891 will have its enclosure listed in your blog's RSS 2 newsfeed.
465 892
466 893 Note that enclosure support requires using the optional MagpieRSS
467 - upgrade (i.e., replacing your `wp-includes/rss-functions.php` with `OPTIONAL/wp-includes/rss-functions.php` from the FWP archive)
894 + upgrade (i.e., replacing your `wp-includes/rss-functions.php` with
895 + `OPTIONAL/wp-includes/rss-functions.php` from the FWP archive)
468 896
469 897 * FEATURE: for completeness's sake, there is now a feed setting,
470 898 `hardcode url`, that allows you to set the URI for the front page
471 899 of a contributor's website manually (that is, prevent it from being