PluginProbe
FeedWordPress / 2010.0528
FeedWordPress v2010.0528
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 +710 -4 0.99 → 2010.0528 View file →
@@ -1,7 +1,712 @@
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 +
386 +Changes from 2008.1105 to 2008.1214
387 +-----------------------------------
388 +
389 +* WORDPRESS 2.7 COMPATIBILITY: FeedWordPress has been tested for
390 + compatibility with the newly released WordPress 2.7. WordPress 2.7 has
391 + deprecated the Snoopy library for HTTP requests, which caused a fatal
392 + error for users who had not installed the MagpieRSS upgrade (or whose
393 + installation of the MagpieRSS upgrade was overwritten by a recent update
394 + of WordPress). FeedWordPress now handles things gracefully when Snoopy
395 + is not immediately available.
396 +
397 +* INTERFACE SPIFFED UP: Interface elements have been updated so that
398 + FeedWordPress's management interface fits in more naturally with the
399 + WordPress 2.7 interface (including a new logo and a number of small
400 + interface tweaks).
401 +
402 +* BUG WITH TAGS FOR SYNDICATED ARTICLES FIXED: Several users encountered a
403 + bug with the option to add tags to all syndicated posts under
404 + Syndication --> Settings -- if you told FeedWordPress to add more than
405 + one tag to all syndicated posts, instead of doing so correctly, it would
406 + add a *single* tag instead, whose name was composed of the names of all
407 + the tags you asked it to add. This bug was the result of nothing more
408 + dignified than a typographical error on my part. It has now been fixed.
409 +
410 +* MORE INFORMATION AVAILABLE WHEN FEEDWORDPRESS CAN'T FIND A FEED: When
411 + you enter a URL for a new syndication source, FeedWordPress uses a
412 + simple feed-finding algorithm (originally based on Mark Pilgrim's
413 + Universal Feed Finder) to try to determine whether the URL is the URL
414 + for a feed, or, if the URL points to an ordinary website rather than to
415 + a feed, whether there is a feed for that website. All well and good, but
416 + if FeedWordPress failed to find a feed, for whatever reason, it would
417 + typically return nothing more than a nasty little note to the effect of
418 + "no feed found," without any explanation of what went wrong.
419 + FeedWordPress now keeps track of error conditions from the HTTP
420 + requests that it uses in the course of looking for the feed, and so may
421 + be able to give you a bit more information about the nature of the
422 + problem if something goes wrong.
423 +
424 +
425 +Changes from 2008.1101 to 2008.1105
426 +-----------------------------------
427 +
428 +* INTERFACE RESTRUCTURING AND SYNDICATION --> AUTHORS PAGE: As a first
429 + step towards modularizing and better organizing the user interface, a
430 + new "Authors" subpage has been created under the Syndication menu, which
431 + controls settings for syndicated authors, both at the global default
432 + level and at level of individual syndicated feeds.
433 +
434 +* BUG RELATED TO THE ATTRIBUTION OF POSTS TO THE WRONG AUTHOR FIXED: Some
435 + users encountered an issue in which posts by different authors on
436 + different blogs -- especially blogs generated by Blogger -- were
437 + mistakenly attributed to a single author. The problem was caused by the
438 + way in which FeedWordPress matches syndicated authors to user accounts
439 + in the WordPress database: normally, if two feeds each list an author
440 + with the same e-mail address, they are counted as being the same person.
441 + Normally this works well, but it creates an issue in cases where
442 + blogging software assigns a single anonymous e-mail address to users who
443 + do not want their real e-mail address published. This is, for example,
444 + what Blogger does (by giving all users a default e-mail address of
445 + <noreply@blogger.com> if they don't want their own e-mail address
446 + listed). FeedWordPress now allows the user to correct for this problem
447 + with a couple of new settings under **Syndication --> Authors**, which
448 + allow users to turn off e-mail based author matching for particular
449 + addresses, or, if desired, to turn it off entirely. By default, e-mail
450 + based author matching is still turned on, but disabled for a list of
451 + known generic e-mail addresses. Right now, the "list" consists entirely
452 + of <noreply@blogger.com>; if you know other addresses that should be
453 + added, please [contact me](http://radgeek.com/contact) to let me know.
454 +
455 + Please note that if you have already encountered this issue on your
456 + blog, upgrading FeedWordPress will prevent it from re-occurring in the
457 + future, but you still need to do two other things to fix the existing
458 + problem on your blog.
459 +
460 + First, for each feed where posts have been mis-attributed, you need to
461 + change the existing author mapping rules to re-map a a syndicated
462 + author's name to the proper target account. Go to **Syndication -->
463 + Authors**, select the feed you want to change from the drop-down list,
464 + and then change the settings under the "Syndicated Authors" section.
465 + (You will probably need to select "will be assigned to a new user..." to
466 + create a new user account with the appropriate name.)
467 +
468 + Second, for each feed where posts have been mis-attributed, you need to
469 + re-assign already-syndicated posts that were mis-attributed to the
470 + correct author. You can do that from **Syndication --> Authors** by
471 + using the author re-assignment feature, described below.
472 +
473 +* AUTHOR RE-ASSIGNMENT FOR A PARTICULAR FEED: The author settings page
474 + for each syndicated feed, under **Syndication --> Authors**, now
475 + includes an section titled "Fixing mis-matched authors," which provides
476 + an interface for re-assigning or deleting all posts attributed to a
477 + particular author on a particular feed.
478 +
479 +* SUPPORT FOR `<atom:source>` ELEMENT IN SYNDICATED FEEDS: Some feeds
480 + (for example, those produced by FeedWordPress) aggregate content from
481 + several different sources, and include information about the original
482 + source of the post in an `<atom:source>` element. A new setting under
483 + **Syndication --> Options** allows you to control what FeedWordPress
484 + will report as the source of posts syndicated from aggregator feeds in
485 + your templates and feeds: you can have FeedWordPress report that the
486 + source of a post is the aggregator feed itself, or you can have it
487 + report that the source of a post is the original source that the
488 + aggregator originally syndicated the post from.
489 +
490 + By default, FeedWordPress will report the aggregator, not the original
491 + source, as the source of a syndicated item.
492 +
493 +* LOAD BALANCING AND TIME LIMITING FEATURES FOR UPDATES: Some users have
494 + encountered issues due to running up against PHP execution time limits
495 + during the process of updating large syndicated feeds, or a very large
496 + set of syndicated feeds. FeedWordPress now has a feature that allows you
497 + to limit the total amount of time spent updating a feed, through the
498 + "Time limit on updates" setting under **Syndication --> Options**. By
499 + turning on this setting and adjusting the time limit to a low enough
500 + figure to avoid your PHP installation's time-out setting. (PHP execution
501 + time limits are usually in the vicinity of 30 seconds, so an update
502 + time limit of 25 seconds or so should provide plenty of time for updates
503 + while allowing a cushion of time for other, non-update-related functions
504 + to do their work.)
505 +
506 + If feed updates are interrupted by the time limit, FeedWordPress uses
507 + some simple load balancing features to make sure that updates to other
508 + feeds will not be blocked by the time-hogging feed, and will also make
509 + sure that when the interrupted update is resumed, FeedWordPress will
510 + skip ahead to resume processing items at the point at which it was
511 + interrupted last time, so that posts further down in the feed will
512 + eventually get processed, and not get blocked by the amount of time it
513 + takes to process the items higher up in the feed.
514 +
515 +* `guid` INDEX CREATION BUTTON: FeedWordPress frequently issues queries on
516 + the `guid` column of the WordPress posts database (since it uses post
517 + guid URIs to keep track of which posts it has syndicated). In very large
518 + FeedWordPress installations, you can often significantly improve
519 + performance by creating a database index on the `guid` column, but
520 + normally you would need to poke around with MySQL or a tool like
521 + phpMyAdmin to do this. FeedWordPress can now save you the trouble: to
522 + create an index on the `guid` column, just go to
523 + **Syndication --> Options**, and mash the button at the bottom of the
524 + "Back End" section.
525 +
526 +Changes from 2008.1030 to 2008.1101
527 +-----------------------------------
528 +
529 +* INTERFACE BUG THAT PREVENTED ADDING NEW SITES FIXED: The UI reforms in
530 + FWP 2008.1030 unintentionally introduced a bug that prevents clean
531 + installations of FeedWordPress from providing an input box for adding
532 + new feeds to the list of syndicated feeds. This bug has been fixed.
533 +
534 +Changes from 0.993 to 2008.1030
535 +-------------------------------
536 +
537 +* WORDPRESS 2.6 COMPATIBILITY: FeedWordPress should now be compatible with
538 + WordPress 2.6, and should work more or less seamlessly with the new post
539 + revision system. A bug which caused multiple new revisions to be created
540 + for posts on certain feeds, regardless of whether or not the item had
541 + been updated, has been fixed.
542 +
543 +* INTERFACE IMPROVEMENTS: The user interface has been substantially
544 + restyled to fit in better with the visual style of WordPress 2.5 and
545 + 2.6.
546 +
547 +* YOUTUBE BUG FIXED: POSTS SYNDICATED THROUGH AN AUTOMATIC UPDATE ARE NO
548 + LONGER STRIPPED OF `<OBJECT>` TAGS AND CERTAIN OTHER HTML ELEMENTS: Due
549 + to the way that some versions of WordPress process posts that are
550 + inserted into the database when no user is logged in, many users
551 + experienced an issue where YouTube videos and other content using the
552 + HTML `<object>` tag would be stripped out of posts that were syndicated
553 + during an automatic update. (Posts that were syndicated through manual
554 + updates from within the WordPress Dashboard were not affected, because
555 + the issue does not arise when an update is executed under a logged-in
556 + administrator's credentials.) This bug has now been fixed; YouTube
557 + videos and other content using `<object>` tags should now appear
558 + properly in syndicated posts, regardless of the way in which the post
559 + was syndicated.
560 +
561 +* AJAX BUGS FIXED: Bugs which blocked the normal operation of WordPress
562 + 2.5's AJAX interface elements when FeedWordPress was activated have been
563 + fixed.
564 +
565 +* TAG SUPPORT: A couple of features have been introduced to take advantage
566 + of the tagging features in WordPress 2.3.x, 2.5.x, and 2.6.x. Now, when
567 + unfamiliar categories are encountered for posts on a feed, you can
568 + choose for FeedWordPress (1) to drop the category; (2) to drop the
569 + category and to filter out any post that does not match at least one
570 + familiar category; (3) to create a new category with that name, or,
571 + now, you can also have FeedWordPress (4) create a new *tag* with that
572 + name. This option can be set site-wide under Syndication --> Options,
573 + or it can be set on a feed-by-feed basis in a feed's Edit screen.
574 +
575 + In addition, you can now set particular tags to apply to all incoming
576 + syndicated posts, under Syndication --> Options, or you can set tags
577 + to apply to all incoming syndicated posts from a particular feed in that
578 + feed's Edit screen.
579 +
580 +* FORMATTING FILTERS: There is a new option available under Syndication ->
581 + Options which allows users to choose whether or not to expose syndicated
582 + posts to being altered by formatting filters. By default, FeedWordPress
583 + has always protected syndicated posts (which are already in display-ready
584 + HTML when they are syndicated) from being reformatted by formatting
585 + filters. However, this approach means that certain plugins which depend
586 + on formatting filters (for example, to add "Share This" bars or relevant
587 + links to the end of a post) are blocked from working on any syndicated
588 + posts. If you want to use one of these plugins together with
589 + FeedWordPress, you can now do so by changing the "Formatting Filters"
590 + setting from "Protect" to "Expose."
591 +
592 +* `<atom:source>` ELEMENTS NOW INCLUDED IN ATOM FEED: Atom 1.0 provides
593 + a standard method for aggregators to indicate information about the original source of
594 + a syndicated post, using the `<atom:source>` element. FeedWordPress now
595 + introduces standard `<atom:source>` elements including the title, homepage, and
596 + feed URI of the source from which a syndicated post was syndicated. Cf.
597 + <http://www.atomenabled.org/developers/syndication/atom-format-spec.php#element.source>
598 +
599 +* MODULARIZATION OF CODE: The code for different elements of FeedWordPress
600 + has been broken out into several modules for easier inspection,
601 + documentation, and maintenance of the code.
602 +
603 +* VERSIONING SCHEME CHANGED: FeedWordPress's feature set has proven stable
604 + enough that it can now be removed from beta status; a good thing, since
605 + I was very quickly running out of version numbers to use. New releases
606 + of FeedWordPress will have version numbers based on the date of their
607 + release.
608 +
609 +Changes from 0.992 to 0.993
610 +---------------------------
611 +
612 +* WORDPRESS 2.5.1 COMPATIBILITY: FeedWordPress should now be compatible
613 + with WordPress 2.5.1.
614 +
615 +* WORDPRESS 2.5 INTERFACE IMPROVEMENTS: FeedWordPress's Dashboard
616 + interface has undergone several cosmetic changes that should help it
617 + integrate better with the WordPress Dashboard interface in WordPress
618 + version 2.5.x.
619 +
620 +* SYNDICATED POSTS CAN BE MARKED AS "PENDING REVIEW": WordPress 2.3 users
621 + can now take advantage of WordPress's new "Pending Review" features for
622 + incoming syndicated posts. Posts marked as "Pending Review" are not
623 + published immediately, but are marked as ready to be reviewed by an
624 + Administrator or Editor, who can then choose to publish the post or
625 + hold it back. If you want to review syndicated posts from a particular
626 + feed, or from all feeds, before they are posted, then use
627 + Syndication --> Syndicated Sites --> Edit or Syndication --> Options to
628 + change the settings for handling new posts.
629 +
630 +* AWARE OF NEW URI FOR del.icio.us FEEDS: Previous releases of
631 + FeedWordPress already automatically split del.icio.us tags up
632 + appropriately appropriately when generating categories. (del.icio.us
633 + feeds smoosh all the tags into a single `<dc:subject>` element,
634 + separated by spaces; FeedWordPress un-smooshes them into multiple
635 + categories by separating them at whitespace.) Unfortunately, del.icio.us
636 + recently broke the existing behavior by changing host names for their
637 + feeds from del.icio.us to feeds.delicious.com. Version 0.993 accounts
638 + for the new host name and un-breaks the tag splitting.
639 +
640 +Changes from 0.991 to 0.992
641 +---------------------------
642 +* AUTHOR RE-MAPPING: FeedWordPress now offers considerable control over
643 + how author names on a feed are translated into usernames within the
644 + WordPress database. When a post by an unrecognized author comes in,
645 + Administrators can now specify any username as the default username to
646 + assign the post to by setting the option in Syndication --> Options
647 + (formerly FeedWordPress only allowed you to assign such posts to user
648 + #1, the site administrator). Administrators can also create re-mapping
649 + rules for particular feeds (under Syndication --> Syndicated Sites -->
650 + Edit), so that (for example) any posts attributed to "Administrator"
651 + on the feed <http://praxeology.net/blog/feed/> will be assigned to
652 + a user named "Roderick T. Long," rather than a user named
653 + "Administrator." These settings also allow administrators to filter out
654 + posts by particular users, and to control what will happen when
655 + FeedWordPress encounters a post by an unrecognized user on that
656 + particular feed.
657 +
658 +* BUG RELATED TO URIS CONTAINING AMPERSAND CHARACTERS FIXED: A bug in
659 + WordPress 2.x's handling of URIs in Blogroll links created problems for
660 + updating any feeds whose URIs included an ampersand character, such as
661 + Google News RSS feeds and other feeds that have multiple parameters
662 + passed through HTTP GET. If you experienced this bug, the most likely
663 + effect was that FeedWordPress simply would not import new posts from a
664 + feed when instructred to do so, returning a "0 new posts" response. In
665 + other cases, it might lead to unpredictable results from feed updates,
666 + such as importing posts which were not contained in the feed being
667 + syndicated, but which did appear elsewhere on the same website. This bug
668 + has, hopefully, been resolved, by correcting for the bug in WordPress.
669 +
670 +Changes from 0.99 to 0.991
671 +--------------------------
672 +* WORDPRESS MU COMPATIBILITY: FeedWordPress should now be compatible with
673 + recent releases of WordPress MU. Once FeedWordPress is made available
674 + as a plugin, each individual blog can choose to activate FeedWordPress
675 + and syndicate content from its own set of contributors.
676 +
677 +* DISPLAY OF MAGPIE WARNINGS: A number of MagpieRSS warnings or error
678 + messages that were displayed when performing an automatic update are
679 + no longer displayed, unless debugging parameters have been explicitly
680 + enabled.
681 +
682 +* BUG RELATED TO INTERNATIONAL CHARACTERS IN AUTHOR NAMES FIXED: Due to a
683 + subtle incompatability between the way that FeedWordPress generated new
684 + user information, and the way that WordPress 2.0 and later added new
685 + authors to the database, FeedWordPress might end up creating duplicate
686 + authors, or throwing a critical error message, when it encountered
687 + authors whose names included international characters. This
688 + incompatability has now been fixed; hopefully, authors with
689 + international characters in their names should now be handled properly.
690 +
691 +* `<media:content>` BUG IN MAGPIERSS FIXED: A bug in MagpieRSS's handling
692 + of namespaced elements has been fixed. Among other things, this bug
693 + caused items containing a Yahoo MediaRSS `<media:content>` element (such
694 + as many of the feeds produced by wordpress.com) to be represented
695 + incorrectly, with only a capital "A" where the content of the post
696 + should have been. Feeds containing `<media:content>` elements should now
697 + be syndicated correctly.
698 +
699 +* update_feedwordpress PARAMETER: You can now use an HTTP GET parameter
700 + (`update_feedwordpress=1`) to request that FeedWordPress poll its feeds
701 + for updates. When used together with a crontab or other means of
702 + scheduling tasks, this means that you can keep your blog automatically
703 + updated on a regular schedule, even if you do not choose to use the
704 + cron-less automatic updates option.
705 +
706 +* Some minor interface-related bugs were also fixed.
707 +
708 +
4 709 Changes from 0.981 to 0.99
5 710 --------------------------
6 711 Version 0.99 adds several significant new features, fixes some bugs, and
7 712 provides compatability with WordPress 2.2.x and 2.3.x.
@@ -142,9 +847,9 @@
142 847 * DATE BUG AFFECTING SOME PHP INSTALLATIONS RESOLVED: due to a subtle bug
143 848 in parse_w3cdtf(), some installations of PHP encountered problems with
144 849 FeedWordPress's attempt to date posts, which would cause some new posts
145 850 on Atom feeds to be dated as if they had apppeared in 1969 or 1970
146 - (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
147 852 the date handling should now be fixed.
148 853
149 854 * PHP <?=...?> SHORT FORM ELIMINATED: some installations of PHP do not
150 855 allow the <?=...?> short form for printing PHP values, which was used
@@ -226,9 +931,9 @@
226 931 regular expressions and careful matching of lowercasing functions
227 932 (comparing results from PHP only to other results from PHP, and results
228 933 from MySQL only to other results from MySQL).
229 934
230 -* 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
231 936 function for parsing W3C date-time format dates that ships with
232 937 MagpieRSS can only correctly parse fully-specified dates with a
233 938 fully-specified time, but valid W3C date-time format dates may omit the
234 939 time, the day of the month, or even the month. Some feeds in the wild
@@ -253,9 +958,9 @@
253 958 that all the examples of improper side-effects that I can find now
254 959 require an HTTP POST to take effect. I think I got pretty much
255 960 everything; if there's anything that I missed, let me know.
256 961
257 - 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)
258 963
259 964 * BUG FIX: Categories applied by `cats` setting should no longer prevent
260 965 category-based filtering from working. In FeedWordPress, you can (1)
261 966 apply certain categories to all syndicated posts, or all posts from
@@ -363,9 +1068,10 @@
363 1068 into the WordPress database so that (among other things) that post
364 1069 will have its enclosure listed in your blog's RSS 2 newsfeed.
365 1070
366 1071 Note that enclosure support requires using the optional MagpieRSS
367 - upgrade (i.e., replacing your `wp-includes/rss-functions.php` with `OPTIONAL/wp-includes/rss-functions.php` from the FWP archive)
1072 + upgrade (i.e., replacing your `wp-includes/rss-functions.php` with
1073 + `OPTIONAL/wp-includes/rss-functions.php` from the FWP archive)
368 1074
369 1075 * FEATURE: for completeness's sake, there is now a feed setting,
370 1076 `hardcode url`, that allows you to set the URI for the front page
371 1077 of a contributor's website manually (that is, prevent it from being