PluginProbe
FeedWordPress / 2009.0612
FeedWordPress v2009.0612
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 +820 -3 0.96 → 2009.0612 View file →
@@ -1,7 +1,823 @@
1 -Change Log
2 -==========
1 +FeedWordPress Change Log
2 +========================
3 3
4 +Changes from 2008.1214 to 2009.0612
5 +-----------------------------------
6 +* WORDPRESS 2.8 COMPATIBILITY: FeedWordPress 2009.0612 has been tested for
7 + compatibility with the recent version 2.8 release of WordPress.
8 +
9 +* INTERFACE RESTRUCTURING: In order to avoid settings posts from becoming
10 + too crowded, and to modularize and better organize the user interface,
11 + new "Posts" and "Categories & Tags" subpages have been created under the
12 + "Syndication" menu. "Posts" controls settings for individal syndicated
13 + posts (such as publication status, comment and ping status, whether or
14 + not to use the original location of the post as the permalink, whether
15 + or not to expose posts to formatting filters, and so on). "Categories &
16 + Tags" controls settings for assigning new syndicated posts to categories
17 + and tags, such as categories or tags to apply to all syndicated posts,
18 + and how to handle categories that do not yet exist in the WordPress
19 + database. These subpages, like the Authors subpage, handle settings for
20 + the global default level and for individual syndicated feeds.
21 +
22 + Corresponding to these new subpages, the old Syndication Settings and
23 + Feed Settings subpages have been cleaned up and simplified, and now only
24 + link to the appropriate subpages for options that can be set in the
25 + Posts, Authors, or Categories & Tags subpages.
26 +
27 +* FEATURE: ADD CUSTOM SETTINGS TO EACH SYNDICATED POST: FeedWordPress has
28 + long had an interface for creating custom settings for each syndicated
29 + *feed* which could be retrieved in templates using the `get_feed_meta()`
30 + template function. But it had no feature for adding custom fields to
31 + each individual syndicated *post*. In response to requests from users, I
32 + have added the ability to apply custom fields to each individual
33 + syndicated post, using the new Syndication --> Posts subpage. You can
34 + set up custom fields to be applied to every syndicated post, or custom
35 + fields to be applied to syndicated posts from a particular feed.
36 +
37 +* FEATURE: MAGPIERSS VERSION CHECK AND UPGRADE: FeedWordPress will attempt
38 + to determine whether or not you are using the upgraded version of
39 + MagpieRSS that comes packaged with FeedWordPress. If not, it will throw
40 + an error on admin pages, and, if you are a site administrator, it will
41 + give you the option to ignore the error message, or to attempt an
42 + automatic upgrade (using a native file copy). If the file copy fails,
43 + FeedWordPress will offer some guidance on how to perform the upgrade
44 + manually.
45 +
46 +* BLANK POSTS PROBLEM NO LONGER OCCURS WITH OLD & BUSTED MAGPIERSS: Due
47 + to the fact that I relied on a content normalization that occurs in my
48 + upgraded version of MagpieRSS, but not in the old & busted version of
49 + MagpieRSS that ships with WordPress, until this version, if you tried to
50 + syndicate an Atom feed without having performed the (*strongly
51 + recommended*) MagpieRSS upgrade, all of the posts would come up with
52 + completely blank contents. That's not because MagpieRSS couldn't read
53 + the data, but rather because the new Magpie version puts that data in a
54 + location where the old version doesn't, and I was only looking in that
55 + newer location. Now it checks for both, meaning that posts will continue
56 + to display their contents even if you don't upgrade MagpieRSS. (But you
57 + **really should** upgrade it, anyway.)
58 +
59 +* BUGFIX: RELATIVE URI RESOLUTION FOR POST CONTENT RESTORED. Some time
60 + back, I added support for resolving relative URIs against xml:base on
61 + feeds that support it to the MagpieRSS upgrade in FeedWordPress. Then I
62 + took out code that did the same thing from the main FeedWordPress code.
63 + Of course, the problem is that some people, even though it is clearly
64 + stupid or evil to do so, still include relative URIs for images or links
65 + in posts on feed formats that do *not* adequately support xml:base
66 + (notably, RSS 2.0 feeds). In response to a user request, I have added
67 + this functionality back in, so that MagpieRSS will resolve any relative
68 + URIs that it knows how to resolve using xml:base, and then FeedWordPress
69 + will attempt to resolve any relative URIs that are left over afterwards.
70 +
71 +* BUGFIX: INTERFACE OPTION FOR SETTING SYNDICATED POST PUBLICATION STATUS
72 + ON A FEED-BY-FEED BASIS HAS BEEN RESTORED: Due to a version-checking
73 + bug, users of WordPress 2.7.x lost an option from the "Edit a syndicated
74 + feed" interface which allowed them to determine whether newly syndicated
75 + posts should be published immediately, held as "Pending Review," saved
76 + as drafts, or saved as private posts. (The option to change this
77 + setting globally remained in place, but users could no longer set it on
78 + a feed-by-feed basis.) The version-checking bug has been fixed, and the
79 + option has been restored.
80 +
81 +* BUGFIX: "ARE YOU SURE?" FATAL ERROR ELIMINATED AND SECURITY IMPROVED:
82 + Under certain circumstances (for example, when users have configured
83 + their browser or proxy not to send HTTP Referer headers, for privacy or
84 + other reasons), many features in the FeedWordPress administrative
85 + interface (such as adding new feeds or changing settings) would hit a
86 + fatal error, displaying only a cryptic message reading "Are you sure?"
87 + and a blank page following it. This problem has been eliminated by
88 + taking advantage of WordPress's nonce functions, which allow the
89 + security check which ran into this error to work properly even without
90 + receiving an HTTP Referer header. (N.B.: WordPress's nonce functions
91 + were first introduced in WordPress 2.0.3. If you're using FeedWordPress
92 + with an older version of WordPress, there's no fix for this problem:
93 + you'll just need to turn Referer headers back on. Sorry.)
94 +
95 +* BUGFIX: MANUALLY-ALTERED POST STATUS, COMMENT STATUS, AND PING STATUS NO
96 + LONGER REVERTED BY POST UPDATES: If you manually altered the post status,
97 + comment status, or ping status of a syndicated post from what it was set
98 + to when first syndicated -- for example, if you had a feed that was set
99 + to bring in new posts as "Pending Review," and you then marked some of
100 + the pending posts as "Published" and others as "Unpublished" -- then
101 + in previous versions of FeedWordPress, these manual changes to the
102 + status would be lost -- so that, for example, your Published or Unpublished
103 + articles would revert to Pending Review -- if the source feed made any
104 + upates to the item. This could make the Pending Review feature both
105 + unreliable and also extremely frustrating to work with. The good news is
106 + that this bug has since been fixed: if you manually update the status
107 + of a post, it will no longer be reverted if or when the post is updated.
108 +
109 +* BUGFIX: OCCASIONAL FATAL ERROR ON UPDATE ELIMINATED: Under certain
110 + limited conditions (specifically, when both the title and the content of
111 + a post to be updated are empty), an attempt to update the post would
112 + result in a fatal error. This has been fixed.
113 +
114 +* INTERFACE: "CONFIGURE SETTINGS" CONVENIENCE LINK ADDED TO CONFIRMATION
115 + MESSAGE WHEN A NEW FEED IS ADDED: When you add a new subscription to
116 + FeedWordPress, the message box that appears to confirm it now includes a
117 + handy link to the feed's settings subpage, so that you can quickly set
118 + up any special settings you may want to set up for the new feed, without
119 + having to hunt through the list of all your other subscriptions to pick
120 + out the new one.
121 +
122 +* INTERFACE: SIMPLIFYING AND CLARIFYING AUTOMATIC UPDATES SETTINGS. I have
123 + removed an interval setting for the cronless automatic updates which has
124 + confused many FeedWordPress users. In past versions of FWP, when you
125 + turned on automatic updates, you would be presented with a time interval
126 + setting which controlled how often FeedWordPress would check for feeds
127 + ready to be polled for updates. (That is, it DID NOT control how often
128 + feeds *would be polled*; it controlled how often FeedWordPress would
129 + *check* for feeds that *had become ready to poll*. The schedule on which
130 + feeds became ready for polling was still controlled either by requests
131 + encoded in elements within the feed itself, or else according to an
132 + internal calculation within FeedWordPress, averaging out to about 1 hour,
133 + if the feed did not include any scheduling request elements.) Since many
134 + users very often (and understandably) confused the purpose of this
135 + setting, and since the setting is for a feature that's actually very
136 + unlikely to require any manual control by the user, I have removed the
137 + setting; FeedWordPress now simply uses the default value of checking for
138 + feeds to poll every 10 minutes.
139 +
140 +* FEEDFINDER PERFORMANCE IMPROVEMENT: FeedWordPress's FeedFinder class
141 + now uses `array_unique()` to make sure that it doesn't waste time
142 + repeatedly iterating over and polling the same URI. Props to Camilo
143 + (<http://projects.radgeek.com/2008/12/14/feedwordpress-20081214/#comment-20090122160414>).
144 +
145 +Changes from 2008.1105 to 2008.1214
146 +-----------------------------------
147 +
148 +* WORDPRESS 2.7 COMPATIBILITY: FeedWordPress has been tested for
149 + compatibility with the newly released WordPress 2.7. WordPress 2.7 has
150 + deprecated the Snoopy library for HTTP requests, which caused a fatal
151 + error for users who had not installed the MagpieRSS upgrade (or whose
152 + installation of the MagpieRSS upgrade was overwritten by a recent update
153 + of WordPress). FeedWordPress now handles things gracefully when Snoopy
154 + is not immediately available.
155 +
156 +* INTERFACE SPIFFED UP: Interface elements have been updated so that
157 + FeedWordPress's management interface fits in more naturally with the
158 + WordPress 2.7 interface (including a new logo and a number of small
159 + interface tweaks).
160 +
161 +* BUG WITH TAGS FOR SYNDICATED ARTICLES FIXED: Several users encountered a
162 + bug with the option to add tags to all syndicated posts under
163 + Syndication --> Settings -- if you told FeedWordPress to add more than
164 + one tag to all syndicated posts, instead of doing so correctly, it would
165 + add a *single* tag instead, whose name was composed of the names of all
166 + the tags you asked it to add. This bug was the result of nothing more
167 + dignified than a typographical error on my part. It has now been fixed.
168 +
169 +* MORE INFORMATION AVAILABLE WHEN FEEDWORDPRESS CAN'T FIND A FEED: When
170 + you enter a URL for a new syndication source, FeedWordPress uses a
171 + simple feed-finding algorithm (originally based on Mark Pilgrim's
172 + Universal Feed Finder) to try to determine whether the URL is the URL
173 + for a feed, or, if the URL points to an ordinary website rather than to
174 + a feed, whether there is a feed for that website. All well and good, but
175 + if FeedWordPress failed to find a feed, for whatever reason, it would
176 + typically return nothing more than a nasty little note to the effect of
177 + "no feed found," without any explanation of what went wrong.
178 + FeedWordPress now keeps track of error conditions from the HTTP
179 + requests that it uses in the course of looking for the feed, and so may
180 + be able to give you a bit more information about the nature of the
181 + problem if something goes wrong.
182 +
183 +
184 +Changes from 2008.1101 to 2008.1105
185 +-----------------------------------
186 +
187 +* INTERFACE RESTRUCTURING AND SYNDICATION --> AUTHORS PAGE: As a first
188 + step towards modularizing and better organizing the user interface, a
189 + new "Authors" subpage has been created under the Syndication menu, which
190 + controls settings for syndicated authors, both at the global default
191 + level and at level of individual syndicated feeds.
192 +
193 +* BUG RELATED TO THE ATTRIBUTION OF POSTS TO THE WRONG AUTHOR FIXED: Some
194 + users encountered an issue in which posts by different authors on
195 + different blogs -- especially blogs generated by Blogger -- were
196 + mistakenly attributed to a single author. The problem was caused by the
197 + way in which FeedWordPress matches syndicated authors to user accounts
198 + in the WordPress database: normally, if two feeds each list an author
199 + with the same e-mail address, they are counted as being the same person.
200 + Normally this works well, but it creates an issue in cases where
201 + blogging software assigns a single anonymous e-mail address to users who
202 + do not want their real e-mail address published. This is, for example,
203 + what Blogger does (by giving all users a default e-mail address of
204 + <noreply@blogger.com> if they don't want their own e-mail address
205 + listed). FeedWordPress now allows the user to correct for this problem
206 + with a couple of new settings under **Syndication --> Authors**, which
207 + allow users to turn off e-mail based author matching for particular
208 + addresses, or, if desired, to turn it off entirely. By default, e-mail
209 + based author matching is still turned on, but disabled for a list of
210 + known generic e-mail addresses. Right now, the "list" consists entirely
211 + of <noreply@blogger.com>; if you know other addresses that should be
212 + added, please [contact me](http://radgeek.com/contact) to let me know.
213 +
214 + Please note that if you have already encountered this issue on your
215 + blog, upgrading FeedWordPress will prevent it from re-occurring in the
216 + future, but you still need to do two other things to fix the existing
217 + problem on your blog.
218 +
219 + First, for each feed where posts have been mis-attributed, you need to
220 + change the existing author mapping rules to re-map a a syndicated
221 + author's name to the proper target account. Go to **Syndication -->
222 + Authors**, select the feed you want to change from the drop-down list,
223 + and then change the settings under the "Syndicated Authors" section.
224 + (You will probably need to select "will be assigned to a new user..." to
225 + create a new user account with the appropriate name.)
226 +
227 + Second, for each feed where posts have been mis-attributed, you need to
228 + re-assign already-syndicated posts that were mis-attributed to the
229 + correct author. You can do that from **Syndication --> Authors** by
230 + using the author re-assignment feature, described below.
231 +
232 +* AUTHOR RE-ASSIGNMENT FOR A PARTICULAR FEED: The author settings page
233 + for each syndicated feed, under **Syndication --> Authors**, now
234 + includes an section titled "Fixing mis-matched authors," which provides
235 + an interface for re-assigning or deleting all posts attributed to a
236 + particular author on a particular feed.
237 +
238 +* SUPPORT FOR `<atom:source>` ELEMENT IN SYNDICATED FEEDS: Some feeds
239 + (for example, those produced by FeedWordPress) aggregate content from
240 + several different sources, and include information about the original
241 + source of the post in an `<atom:source>` element. A new setting under
242 + **Syndication --> Options** allows you to control what FeedWordPress
243 + will report as the source of posts syndicated from aggregator feeds in
244 + your templates and feeds: you can have FeedWordPress report that the
245 + source of a post is the aggregator feed itself, or you can have it
246 + report that the source of a post is the original source that the
247 + aggregator originally syndicated the post from.
248 +
249 + By default, FeedWordPress will report the aggregator, not the original
250 + source, as the source of a syndicated item.
251 +
252 +* LOAD BALANCING AND TIME LIMITING FEATURES FOR UPDATES: Some users have
253 + encountered issues due to running up against PHP execution time limits
254 + during the process of updating large syndicated feeds, or a very large
255 + set of syndicated feeds. FeedWordPress now has a feature that allows you
256 + to limit the total amount of time spent updating a feed, through the
257 + "Time limit on updates" setting under **Syndication --> Options**. By
258 + turning on this setting and adjusting the time limit to a low enough
259 + figure to avoid your PHP installation's time-out setting. (PHP execution
260 + time limits are usually in the vicinity of 30 seconds, so an update
261 + time limit of 25 seconds or so should provide plenty of time for updates
262 + while allowing a cushion of time for other, non-update-related functions
263 + to do their work.)
264 +
265 + If feed updates are interrupted by the time limit, FeedWordPress uses
266 + some simple load balancing features to make sure that updates to other
267 + feeds will not be blocked by the time-hogging feed, and will also make
268 + sure that when the interrupted update is resumed, FeedWordPress will
269 + skip ahead to resume processing items at the point at which it was
270 + interrupted last time, so that posts further down in the feed will
271 + eventually get processed, and not get blocked by the amount of time it
272 + takes to process the items higher up in the feed.
273 +
274 +* `guid` INDEX CREATION BUTTON: FeedWordPress frequently issues queries on
275 + the `guid` column of the WordPress posts database (since it uses post
276 + guid URIs to keep track of which posts it has syndicated). In very large
277 + FeedWordPress installations, you can often significantly improve
278 + performance by creating a database index on the `guid` column, but
279 + normally you would need to poke around with MySQL or a tool like
280 + phpMyAdmin to do this. FeedWordPress can now save you the trouble: to
281 + create an index on the `guid` column, just go to
282 + **Syndication --> Options**, and mash the button at the bottom of the
283 + "Back End" section.
284 +
285 +Changes from 2008.1030 to 2008.1101
286 +-----------------------------------
287 +
288 +* INTERFACE BUG THAT PREVENTED ADDING NEW SITES FIXED: The UI reforms in
289 + FWP 2008.1030 unintentionally introduced a bug that prevents clean
290 + installations of FeedWordPress from providing an input box for adding
291 + new feeds to the list of syndicated feeds. This bug has been fixed.
292 +
293 +Changes from 0.993 to 2008.1030
294 +-------------------------------
295 +
296 +* WORDPRESS 2.6 COMPATIBILITY: FeedWordPress should now be compatible with
297 + WordPress 2.6, and should work more or less seamlessly with the new post
298 + revision system. A bug which caused multiple new revisions to be created
299 + for posts on certain feeds, regardless of whether or not the item had
300 + been updated, has been fixed.
301 +
302 +* INTERFACE IMPROVEMENTS: The user interface has been substantially
303 + restyled to fit in better with the visual style of WordPress 2.5 and
304 + 2.6.
305 +
306 +* YOUTUBE BUG FIXED: POSTS SYNDICATED THROUGH AN AUTOMATIC UPDATE ARE NO
307 + LONGER STRIPPED OF `<OBJECT>` TAGS AND CERTAIN OTHER HTML ELEMENTS: Due
308 + to the way that some versions of WordPress process posts that are
309 + inserted into the database when no user is logged in, many users
310 + experienced an issue where YouTube videos and other content using the
311 + HTML `<object>` tag would be stripped out of posts that were syndicated
312 + during an automatic update. (Posts that were syndicated through manual
313 + updates from within the WordPress Dashboard were not affected, because
314 + the issue does not arise when an update is executed under a logged-in
315 + administrator's credentials.) This bug has now been fixed; YouTube
316 + videos and other content using `<object>` tags should now appear
317 + properly in syndicated posts, regardless of the way in which the post
318 + was syndicated.
319 +
320 +* AJAX BUGS FIXED: Bugs which blocked the normal operation of WordPress
321 + 2.5's AJAX interface elements when FeedWordPress was activated have been
322 + fixed.
323 +
324 +* TAG SUPPORT: A couple of features have been introduced to take advantage
325 + of the tagging features in WordPress 2.3.x, 2.5.x, and 2.6.x. Now, when
326 + unfamiliar categories are encountered for posts on a feed, you can
327 + choose for FeedWordPress (1) to drop the category; (2) to drop the
328 + category and to filter out any post that does not match at least one
329 + familiar category; (3) to create a new category with that name, or,
330 + now, you can also have FeedWordPress (4) create a new *tag* with that
331 + name. This option can be set site-wide under Syndication --> Options,
332 + or it can be set on a feed-by-feed basis in a feed's Edit screen.
333 +
334 + In addition, you can now set particular tags to apply to all incoming
335 + syndicated posts, under Syndication --> Options, or you can set tags
336 + to apply to all incoming syndicated posts from a particular feed in that
337 + feed's Edit screen.
338 +
339 +* FORMATTING FILTERS: There is a new option available under Syndication ->
340 + Options which allows users to choose whether or not to expose syndicated
341 + posts to being altered by formatting filters. By default, FeedWordPress
342 + has always protected syndicated posts (which are already in display-ready
343 + HTML when they are syndicated) from being reformatted by formatting
344 + filters. However, this approach means that certain plugins which depend
345 + on formatting filters (for example, to add "Share This" bars or relevant
346 + links to the end of a post) are blocked from working on any syndicated
347 + posts. If you want to use one of these plugins together with
348 + FeedWordPress, you can now do so by changing the "Formatting Filters"
349 + setting from "Protect" to "Expose."
350 +
351 +* `<atom:source>` ELEMENTS NOW INCLUDED IN ATOM FEED: Atom 1.0 provides
352 + a standard method for aggregators to indicate information about the original source of
353 + a syndicated post, using the `<atom:source>` element. FeedWordPress now
354 + introduces standard `<atom:source>` elements including the title, homepage, and
355 + feed URI of the source from which a syndicated post was syndicated. Cf.
356 + <http://www.atomenabled.org/developers/syndication/atom-format-spec.php#element.source>
357 +
358 +* MODULARIZATION OF CODE: The code for different elements of FeedWordPress
359 + has been broken out into several modules for easier inspection,
360 + documentation, and maintenance of the code.
361 +
362 +* VERSIONING SCHEME CHANGED: FeedWordPress's feature set has proven stable
363 + enough that it can now be removed from beta status; a good thing, since
364 + I was very quickly running out of version numbers to use. New releases
365 + of FeedWordPress will have version numbers based on the date of their
366 + release.
367 +
368 +Changes from 0.992 to 0.993
369 +---------------------------
370 +
371 +* WORDPRESS 2.5.1 COMPATIBILITY: FeedWordPress should now be compatible
372 + with WordPress 2.5.1.
373 +
374 +* WORDPRESS 2.5 INTERFACE IMPROVEMENTS: FeedWordPress's Dashboard
375 + interface has undergone several cosmetic changes that should help it
376 + integrate better with the WordPress Dashboard interface in WordPress
377 + version 2.5.x.
378 +
379 +* SYNDICATED POSTS CAN BE MARKED AS "PENDING REVIEW": WordPress 2.3 users
380 + can now take advantage of WordPress's new "Pending Review" features for
381 + incoming syndicated posts. Posts marked as "Pending Review" are not
382 + published immediately, but are marked as ready to be reviewed by an
383 + Administrator or Editor, who can then choose to publish the post or
384 + hold it back. If you want to review syndicated posts from a particular
385 + feed, or from all feeds, before they are posted, then use
386 + Syndication --> Syndicated Sites --> Edit or Syndication --> Options to
387 + change the settings for handling new posts.
388 +
389 +* AWARE OF NEW URI FOR del.icio.us FEEDS: Previous releases of
390 + FeedWordPress already automatically split del.icio.us tags up
391 + appropriately appropriately when generating categories. (del.icio.us
392 + feeds smoosh all the tags into a single `<dc:subject>` element,
393 + separated by spaces; FeedWordPress un-smooshes them into multiple
394 + categories by separating them at whitespace.) Unfortunately, del.icio.us
395 + recently broke the existing behavior by changing host names for their
396 + feeds from del.icio.us to feeds.delicious.com. Version 0.993 accounts
397 + for the new host name and un-breaks the tag splitting.
398 +
399 +Changes from 0.991 to 0.992
400 +---------------------------
401 +* AUTHOR RE-MAPPING: FeedWordPress now offers considerable control over
402 + how author names on a feed are translated into usernames within the
403 + WordPress database. When a post by an unrecognized author comes in,
404 + Administrators can now specify any username as the default username to
405 + assign the post to by setting the option in Syndication --> Options
406 + (formerly FeedWordPress only allowed you to assign such posts to user
407 + #1, the site administrator). Administrators can also create re-mapping
408 + rules for particular feeds (under Syndication --> Syndicated Sites -->
409 + Edit), so that (for example) any posts attributed to "Administrator"
410 + on the feed <http://praxeology.net/blog/feed/> will be assigned to
411 + a user named "Roderick T. Long," rather than a user named
412 + "Administrator." These settings also allow administrators to filter out
413 + posts by particular users, and to control what will happen when
414 + FeedWordPress encounters a post by an unrecognized user on that
415 + particular feed.
416 +
417 +* BUG RELATED TO URIS CONTAINING AMPERSAND CHARACTERS FIXED: A bug in
418 + WordPress 2.x's handling of URIs in Blogroll links created problems for
419 + updating any feeds whose URIs included an ampersand character, such as
420 + Google News RSS feeds and other feeds that have multiple parameters
421 + passed through HTTP GET. If you experienced this bug, the most likely
422 + effect was that FeedWordPress simply would not import new posts from a
423 + feed when instructred to do so, returning a "0 new posts" response. In
424 + other cases, it might lead to unpredictable results from feed updates,
425 + such as importing posts which were not contained in the feed being
426 + syndicated, but which did appear elsewhere on the same website. This bug
427 + has, hopefully, been resolved, by correcting for the bug in WordPress.
428 +
429 +Changes from 0.99 to 0.991
430 +--------------------------
431 +* WORDPRESS MU COMPATIBILITY: FeedWordPress should now be compatible with
432 + recent releases of WordPress MU. Once FeedWordPress is made available
433 + as a plugin, each individual blog can choose to activate FeedWordPress
434 + and syndicate content from its own set of contributors.
435 +
436 +* DISPLAY OF MAGPIE WARNINGS: A number of MagpieRSS warnings or error
437 + messages that were displayed when performing an automatic update are
438 + no longer displayed, unless debugging parameters have been explicitly
439 + enabled.
440 +
441 +* BUG RELATED TO INTERNATIONAL CHARACTERS IN AUTHOR NAMES FIXED: Due to a
442 + subtle incompatability between the way that FeedWordPress generated new
443 + user information, and the way that WordPress 2.0 and later added new
444 + authors to the database, FeedWordPress might end up creating duplicate
445 + authors, or throwing a critical error message, when it encountered
446 + authors whose names included international characters. This
447 + incompatability has now been fixed; hopefully, authors with
448 + international characters in their names should now be handled properly.
449 +
450 +* `<media:content>` BUG IN MAGPIERSS FIXED: A bug in MagpieRSS's handling
451 + of namespaced elements has been fixed. Among other things, this bug
452 + caused items containing a Yahoo MediaRSS `<media:content>` element (such
453 + as many of the feeds produced by wordpress.com) to be represented
454 + incorrectly, with only a capital "A" where the content of the post
455 + should have been. Feeds containing `<media:content>` elements should now
456 + be syndicated correctly.
457 +
458 +* update_feedwordpress PARAMETER: You can now use an HTTP GET parameter
459 + (`update_feedwordpress=1`) to request that FeedWordPress poll its feeds
460 + for updates. When used together with a crontab or other means of
461 + scheduling tasks, this means that you can keep your blog automatically
462 + updated on a regular schedule, even if you do not choose to use the
463 + cron-less automatic updates option.
464 +
465 +* Some minor interface-related bugs were also fixed.
466 +
467 +
468 +Changes from 0.981 to 0.99
469 +--------------------------
470 +Version 0.99 adds several significant new features, fixes some bugs, and
471 +provides compatability with WordPress 2.2.x and 2.3.x.
472 +
473 +* WORDPRESS 2.2 AND 2.3 COMPATIBILITY: FeedWordPress should now be
474 + compatible with WordPress version 2.2 and the upcoming WordPress
475 + version 2.3. In particular, it has been tested extensively against
476 + WordPress 2.2.3 and WordPress 2.3 Release Candidate 1.
477 +
478 +* AUTOMATIC UPDATES WITHOUT CRON: FeedWordPress now allows you to
479 + automatically schedule checks for new posts without using external task
480 + scheduling tools such as cron. In order to enable automatic updates, go
481 + to **Syndication --> Options** and set "Check for new posts" to
482 + "automatically." For details, see "Automatic Feed Updates" in
483 + README.text.
484 +
485 + An important side-effect of the changes to the update system is that if
486 + you were previously using the cron job and the `update-feeds.php` script
487 + to schedule updates, you need to change your cron set-up. The old
488 + `update-feeds.php` script no longer exists. Instead, if you wish to use
489 + a cron job to guarantee updates on a particular schedule, you should
490 + have the cron job fetch the front page of your blog (for example, by
491 + using `curl http://www.zyx.com/blog/ > /dev/null`) instead of activating
492 + the `update-feeds.php` script. If automatic updates have been enabled,
493 + fetching the front page will automatically trigger the update process.
494 +
495 +* INTERFACE REORGANIZATION: All FeedWordPress functions are now located
496 + under a top-level "Syndication" menu in the WordPress Dashboard. To
497 + manage the list of syndicated sites, manually check for new posts on
498 + one or more feeds, or syndicate a new site, you should use the main page
499 + under **Syndication**. To change global settings for FeedWordPress,
500 + you should use **Syndication --> Options**.
501 +
502 +* FILE STRUCTURE REORGANIZATION: Due to a combination of changing styles
503 + for FeedWordPress plugins and lingering bugs in the FeedWordPress admin
504 + menu code, the code for FeedWordPress is now contained in two different
505 + PHP files, which should be installed together in a subdirectory of your
506 + plugins directory named `feedwordpress`. (See README.text for
507 + installation and upgrade instructions relating to the change.)
508 +
509 +* MULTIPLE CATEGORIES SETTING: Some feeds use non-standard methods to
510 + indicate multiple categories within a single category element. (The most
511 + popular site to do this is del.icio.us, which separates tags with a
512 + space.) FeedWordPress now allows you to set an optional setting, for any
513 + feed which does this, indicating the character or characters used to
514 + divide multiple categories, using a Perl-compatible regular expression.
515 + (In the case of del.icio.us feeds, FeedWordPress will automatically use
516 + \s for the pattern without your having to do any further configuration.)
517 + To turn this setting on, simply use the "Edit" link for the feed that
518 + you want to turn it on for.
519 +
520 +* REGULAR EXPRESSION BUG FIXED: Eliminated a minor bug in the regular
521 + expressions for e-mail addresses (used in parsing RSS `author`
522 + elements), which could produce unsightly error messages for some users
523 + parsing RSS 2.0 feeds.
524 +
525 +* DATE / UPDATE BUG FIXED: A bug in date handling was eliminated that may
526 + have caused problems if any of (1) WordPress, or (2) PHP, or (3) your
527 + web server, or (4) your MySQL server, has been set to use a different
528 + time zone from the one that any of the others is set to use. If
529 + FeedWordPress has not been properly updating updated posts, or has been
530 + updating posts when there shouldn't be any changes for the update, this
531 + release may solve that problem.
532 +
533 +* GOOGLE READER BUGS FIXED: A couple of bugs that made it difficult for
534 + FeedWordPress to interact with Google Reader public feeds have been
535 + fixed. Firstly, if you encountered an error message reading "There was a
536 + problem adding the newsfeed. [SQL: ]" when you tried to add the feed,
537 + the cause of this error has been fixed. Secondly, if you succeeded in
538 + getting FeedWordPress to check a Google Reader feed, only to find that
539 + the title of posts had junk squashed on to the end of them, that bug
540 + has been fixed too. To fix this bug, you must install the newest version
541 + of the optional MagpieRSS upgrade.
542 +
543 +* FILTER PARAMETERS: Due to an old, old bug in WordPress 1.5.0 (which was
544 + what was available back when I first wrote the filter interface),
545 + FeedWordPress has traditionally only passed one parameter to
546 + syndicated_item and syndicated_post filters functions -- an array
547 + containing either the Magpie representation of a syndicated item from
548 + the feed, or the database representation of a post about to be inserted
549 + into the WordPress database. If you needed information about the feed
550 + that the item came from, this was accessible only through a pair of
551 + global variables, $fwp_channel and $fwp_feedmeta.
552 +
553 + Since it's been a pretty long time since WordPress 1.5.0 was in
554 + widespread usage, I have gone ahead and added an optional second
555 + parameter to the invocation of the syndicated_item and syndicated_post
556 + filters. If you have written a filter for FeedWordPress that uses either
557 + of these hooks, you can now register that filter to accept 2 parameters.
558 + If you do so, the second parameter will be a SyndicatedPost object,
559 + which, among other things, allows you to access information about the
560 + feed from which an item is syndicated using the $post->feed and the
561 + $post->feedmeta elements (where $post is the name of the second
562 + parameter).
563 +
564 + NOTE THAT THE OLD GLOBAL VARIABLES ARE STILL AVAILABLE, for the time
565 + being at least, so existing filters will not break with the upgrade.
566 + They should be considered deprecated, however, and may be eliminated in
567 + the future.
568 +
569 +* FILTER CHANGE / BUGFIX: the array that is passed as the first argument
570 + syndicated_post filters no longer is no longer backslash-escaped for
571 + MySQL when filters are called. This was originally a bug, or an
572 + oversight; the contents of the array should only be escaped for the
573 + database *after* they have gone through all filters. IF YOU HAVE WRITTEN
574 + ANY syndicated_post FILTERS THAT PRESUME THE OLD BEHAVIOR OF PASSING IN
575 + STRINGS THAT ARE ALREADY BACKSLASH-ESCAPED, UPDATE YOUR FILTERS
576 + ACCORDINGLY.
577 +
578 +* OTHER MINOR BUGFIXES AND INTERNAL CHANGES: The internal architecture of
579 + FeedWordPress has been significantly changed to make the code more
580 + modular and clean; hopefully this should help reduce the number of
581 + compatibility updates that are needed, and make them easier and quicker
582 + when they are needed.
583 +
584 +Changes from 0.98 to 0.981
585 +--------------------------
586 +Version 0.981 is a narrowly targeted bugfix and compatibility release, whose
587 +main purpose is to resolve a major outstanding problem: the incompatibility
588 +between version 0.98 of WordPress and the recently released WordPress 2.1.
589 +
590 +* WORDPRESS 2.1 COMPATIBILITY: FeedWordPress is now compatible with
591 + WordPress 2.1, as well as retaining its existing support for WordPress
592 + 2.0 and 1.5. Incompatibilities that resulted in database warnings, fatal
593 + errors, and which prevented FeedWordPress from syndicating new posts,
594 + have been eliminated.
595 +
596 +* RSS-FUNCTIONS.PHP RENAMED TO RSS.PHP: if you use the upgraded MagpieRSS
597 + replacement that's included with FeedWordPress, be sure to note that
598 + there are now *two* files to upload from the `OPTIONAL/wp-includes`
599 + subdirectory in order to carry out the upgrade: rss-functions.php and
600 + rss.php. **It is necessary to upload both files**, due to a change in
601 + the file naming scheme in WordPress 2.1, and it is necessary to do so
602 + whether you are using WordPress 2.1 or not. If you only upload the
603 + `rss-functions.php` file as in previous installations you will not have
604 + a working copy of MagpieRSS; the rss.php file contains the actual code.
605 +
606 +* DATE BUG AFFECTING SOME PHP INSTALLATIONS RESOLVED: due to a subtle bug
607 + in parse_w3cdtf(), some installations of PHP encountered problems with
608 + FeedWordPress's attempt to date posts, which would cause some new posts
609 + on Atom feeds to be dated as if they had apppeared in 1969 or 1970
610 + (thus, effectively, never appearing on front page at all). This bug in
611 + the date handling should now be fixed.
612 +
613 +* PHP <?=...?> SHORT FORM ELIMINATED: some installations of PHP do not
614 + allow the <?=...?> short form for printing PHP values, which was used
615 + extensively in the FeedWordPress interface code. Since this could cause
616 + fatal errors for users with the wrong installation of PHP, the short
617 + form has been replaced with full PHP echo statements, and is no longer
618 + used in FeedWordPress.
619 +
620 +* BETTER USER INTERFACE INTEGRATION WITH WORDPRESS 2.x: Some minor changes
621 + have been made to help the FeedWordPress interface pages blend in better
622 + with the user interface when running under WordPress 2.x.
623 +
624 +* GLOBAL CATEGORIES BUG RESOLVED: a bug that prevented some users from
625 + setting one or more categories to apply to syndicated posts from all
626 + feeds (using the checkbox interface under Options --> Syndication) has
627 + been resolved.
628 +
629 +Changes from 0.97 to 0.98
630 +--------------------------
631 +
632 +* WORDPRESS 2.0 COMPATIBILITY: This is a narrowly-targeted release to
633 + solve a major outstanding problem. FeedWordPress is now compatible with
634 + both WordPress 1.5 and WordPress 2.0. Incompatibilities that caused
635 + fatal SQL errors, and a more subtle bug with off-kilter counts of posts
636 + under a given category, have been resolved. FeedWordPress tests for
637 + database schema using the global $wp_db_version variable (if null, then
638 + we presume that we're dealing with WordPress 1.5).
639 +
640 + NOTE: I have **not** fully tested FeedWordPress with WordPress 2.0.
641 + Further testing may reveal more bugs. However, you should now be able
642 + to get at least basic FeedWordPress functionality up and running.
643 +
644 +* AUTHOR MATCHING: FeedWordPress tests several fields to see if it can
645 + identify the author of the post as a user already in the WordPress user
646 + database. In previous versions, it tested the user login, the nickname,
647 + and tested for "aliases" listed in the Profile (see documentation). FWP
648 + now also matches authors on the basis of e-mail address (*if* an e-mail
649 + address is present). This is particularly helpful for formats such as
650 + RSS 2.0, in which authors are primarily identified by e-mail addresses.
651 +
652 +Changes from 0.96 to 0.97
653 +-------------------------
654 +
655 +* INSTALLATION PROCEDURE: Some of the changes between 0.96 and 0.97
656 + require upgrades to the meta-data stored by FeedWordPress to work
657 + properly. Thus, if you are upgrading from 0.96 or earlier to 0.97, most
658 + FeedWordPress operations (including updates and template functions)
659 + WILL BE DISABLED until you run the upgrade procedure. Fortunately,
660 + running the upgrade procedure is easy: just go to either Options -->
661 + Syndication or Links --> Syndicated in the WordPress Dashboard and press
662 + the button.
663 +
664 +* FEED FORMAT SUPPORT: Support has been added for the Atom 1.0 IETF
665 + standard. Several other elements are also newly supported
666 + (dcterms:created, dcterms:issued, dcterms:modified, dc:identifier,
667 + proper support for the RSS 2.0 guid element, the RSS 2.0 author element,
668 + the use of Atom author or Dublin Core dc:creator constructs at the feed
669 + level to identify the author of individual items, etc.)
670 +
671 + N.B.: full support of several Atom 1.0 features, such as categories
672 + and enclosures, requires you to install the optional rss-functions.php
673 + upgrade in your wp-includes directory.
674 +
675 +* BUG FIX: Running `update-feeds.php` from command line or crontab
676 + returned "I don't syndicate..." errors. It turns out that WordPress
677 + sometimes tramples on the internal PHP superglobals that I depended on
678 + to determine whether or not the script was being invoked from the
679 + command line. This has been fixed (the variables are now checked
680 + *before* WordPress can trample them). Note that `update-feeds.php` has
681 + been thoroughly overhauled anyway; see below for details.
682 +
683 +* BUG FIX: Duplicate categories or author names. Fixed two bugs that could
684 + create duplicate author and/or category names when the name contained
685 + either (a) certain international characters (causing a mismatch between
686 + MySQL and PHP's handling of lowercasing text), or (b) characters that
687 + have a special meaning in regular expressions (causing MySQL errors when
688 + looking for the author or category due to regexp syntax errors). These
689 + should now be fixed thanks to careful escaping of names that go into
690 + regular expressions and careful matching of lowercasing functions
691 + (comparing results from PHP only to other results from PHP, and results
692 + from MySQL only to other results from MySQL).
693 +
694 +* BUG FIX: Items dated December 31, 1969 should appear less often. The
695 + function for parsing W3C date-time format dates that ships with
696 + MagpieRSS can only correctly parse fully-specified dates with a
697 + fully-specified time, but valid W3C date-time format dates may omit the
698 + time, the day of the month, or even the month. Some feeds in the wild
699 + date their items with coarse-grained dates, so the optional
700 + `rss-functions.php` upgrade now includes a more flexible parse_w3cdtf()
701 + function that will work with both coarse-grained and fully-specified
702 + dates. (If parts of the date or the time are omitted, they are filled in
703 + with values based on the current time, so '2005-09-10' will be dated to
704 + the current time on that day; '2004' will be dated to this day and time
705 + one year ago.
706 +
707 + N.B.: This fix is only available in the optional `rss-functions.php`
708 + upgrade.
709 +
710 +* BUG FIX: Evil use of HTTP GET has been undone. The WordPress interface
711 + is riddled with inappropriate (non-idempotent) uses of HTTP GET queries
712 + (ordinary links that make the server do something with significant
713 + side-effects, such as deleting a post or a link from the database).
714 + FeedWordPress did some of this too, especially in places where it aped
715 + the WordPress interface (e.g. the "Delete" links in Links -->
716 + Syndicated). That's bad business, though. I've changed the interface so
717 + that all the examples of improper side-effects that I can find now
718 + require an HTTP POST to take effect. I think I got pretty much
719 + everything; if there's anything that I missed, let me know.
720 +
721 + Further reading: [Sam Ruby 2005-05-06: This Stuff Matters](http://www.intertwingly.net/blog/2005/05/06/This-Stuff-Matters)
722 +
723 +* BUG FIX: Categories applied by `cats` setting should no longer prevent
724 + category-based filtering from working. In FeedWordPress, you can (1)
725 + apply certain categories to all syndicated posts, or all posts from
726 + a particular feed; and (2) filter out all posts that don't match one
727 + of the categories that are already in the WordPress database (allowing
728 + for simple category-based filtering; just load up WordPress with the
729 + categories you want to accept, and then tell FeedWordPress not to create
730 + new ones). However, the way that (1) and (2) were implemented meant that
731 + you couldn't effectively use them together; once you applied a known
732 + category to all syndicated posts from a particular feed, it meant that
733 + they'd have at least one familiar category (the category or categories
734 + you were applying), and that would get all posts past the filter no
735 + matter what categories they were originally from.
736 +
737 + Well, no longer. You can still apply categories to all syndicated posts
738 + (using either Syndication --> Options, or the feed-level settings under
739 + Links --> Syndicated). But these categories are not applied to the post
740 + until *after* it has already passed by the "familiar categories" filter.
741 + So now, if you want, you can do category filtering and *then* apply as
742 + many categories as you please to all and only posts that pass the filter.
743 +
744 +* BUG FIX: Other minor typos and HTML gaffes were fixed along the way.
745 +
746 +* PERFORMANCE: get_feed_meta() no longer hits the database for information
747 + on every call; it now caches link data in memory, so FeedWordPress only
748 + goes to the database once for each syndicated link. This may
749 + substantially improve performance if your database server resources
750 + are tight and your templates make a lot of use of custom settings from
751 + get_feed_meta().
752 +
753 +* API CHANGE: Link ID numbers, rather than RSS URIs, are now used to
754 + identify the feed from which a post is syndicated when you use template
755 + functions such as get_feed_meta(). The practical upshot of this is you
756 + can switch feeds, or change the feed address for a particular syndicated
757 + site, without breaking your templates for all the posts that were
758 + syndicated from the earlier URI.
759 +
760 +* API CHANGE: if you have plugins or templates that make use of the
761 + get_feed_meta() function or the $fwp_feedmeta global, note that the
762 + data formerly located under the `uri` and `name` fields is now located
763 + under the `link/uri` field and the `link/name` field, respectively. Note
764 + also that you can access the link ID number for any given feed under the
765 + global $fwp_feedmeta['link/id'] (in plugins) or
766 + get_feed_meta('link/id') (in a template in post contexts).
767 +
768 +* FEATURE: the settings for individual feeds can now be edited using a
769 + humane interface (where formerly you had to tweak key-value pairs in the
770 + Link Notes section). To edit settings for a feed, pick the feed that you
771 + want under Links --> Syndicated and click the Edit link.
772 +
773 +* FEATURE: The "Unsubscribe" button (formerly "Delete") in Links -->
774 + Syndicated now offers three options for unsubscribing from a feed: (1)
775 + turning off the subscription without deleting the feed data or affecting
776 + posts that were syndicated from the feed (this works by setting the Link
777 + for the feed as "invisible"); (2) deleting the feed data and all of the
778 + posts that were syndicated from the feed; or (3) deleting the feed data
779 + and *keeping* the posts that were syndicated from the feed
780 + setting the Link to "Invisible" (meaning that it will not be displayed
781 + in lists of the site links on the front page, and it won't be checked
782 + for updates; (2) deleting the Link and all of the posts that were
783 + syndicated from its feed; or (3) deleting the feed data but keeping the
784 + posts that were syndicated (which will henceforward be treated as if
785 + they were local rather than syndicated posts). (Note that (1) is usually
786 + the best option for aggregator sites, unless you want to clean up the
787 + results of an error or a test.)
788 +
789 +* FEATURE / BUG FIX: If you have been receiving mysterious "I don't
790 + syndicate...", or "(local) HTTP status code was not 200", or "(local)
791 + transport error - could not open socket", or "parse error - not well
792 + formed" errors, then this update may solve your problems, and if it does
793 + *not* solve them, it will at least make the reasons for the problems
794 + easier to understand. That's because I've overhauled the way that
795 + FeedWordPress goes about updating feeds.
796 +
797 + If you use the command-line PHP scripting method to run scheduled
798 + updates, then not much should change for you, except for fewer
799 + mysterious errors. If you have done updates by sending periodic HTTP
800 + requests to <http://your-blog.com/path/wp-content/update-feeds.php>,
801 + then the details have changed somewhat; mostly in such a way as to make
802 + things easier on you. See the README file or online documentation on
803 + Staying Current for the details.
804 +
805 +* FEATURE: FeedWordPress now features a more sophisticated system for
806 + timed updates. Instead of polling *every* subscribed feed for updates
807 + *each* time `update-feeds.php` is run, FeedWordPress now keeps track of
808 + the last time it polled each feed, and only polls them again after a
809 + certain period of time has passed. The amount of time is normally set
810 + randomly for each feed, in a period between 30 minutes and 2 hours (so
811 + 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
812 + directly by the feed, which brings us to ...
813 +
814 +* FEATURE: FeedWordPress now respects the settings in the `ttl` and
815 + Syndication Module RSS elements. Feeds with these elements set will not
816 + be polled any more frequently than they indicate with these feeds unless
817 + the user manually forces FeedWordPress to poll the feed (see Links -->
818 + Syndicated --> Edit settings).
819 +
4 820 Changes from 0.95 to 0.96
5 821 -------------------------
6 822
7 823 * FEATURE: support has been added for enclosures in RSS 2.0 and Atom
@@ -11,9 +827,10 @@
11 827 into the WordPress database so that (among other things) that post
12 828 will have its enclosure listed in your blog's RSS 2 newsfeed.
13 829
14 830 Note that enclosure support requires using the optional MagpieRSS
15 - upgrade (i.e., replacing your `wp-includes/rss-functions.php` with `OPTIONAL/wp-includes/rss-functions.php` from the FWP archive)
831 + upgrade (i.e., replacing your `wp-includes/rss-functions.php` with
832 + `OPTIONAL/wp-includes/rss-functions.php` from the FWP archive)
16 833
17 834 * FEATURE: for completeness's sake, there is now a feed setting,
18 835 `hardcode url`, that allows you to set the URI for the front page
19 836 of a contributor's website manually (that is, prevent it from being