| 1 |
=== FeedWordPress === |
| 2 |
Contributors: Charles Johnson |
| 3 |
Donate link: http://feedwordpress.radgeek.com/ |
| 4 |
Tags: syndication, aggregation, feed, atom, rss |
| 5 |
Requires at least: 3.0 |
| 6 |
Tested up to: 3.2.1 |
| 7 |
Stable tag: 2011.1019 |
| 8 |
|
| 9 |
FeedWordPress syndicates content from feeds you choose into your WordPress weblog. |
| 10 |
|
| 11 |
== Description == |
| 12 |
|
| 13 |
* Author: [Charles Johnson](http://radgeek.com/contact) |
| 14 |
* Project URI: <http://projects.radgeek.com/feedwordpress> |
| 15 |
* License: GPL 2. See License below for copyright jots and tittles. |
| 16 |
|
| 17 |
FeedWordPress is an Atom/RSS aggregator for WordPress. It syndicates content |
| 18 |
from feeds that you choose into your WordPress weblog; the content it syndicates |
| 19 |
appears as a series of special posts in your WordPress posts database. If you |
| 20 |
syndicate several feeds then you can use WordPress's posts database and |
| 21 |
templating engine as the back-end of an aggregation ("planet") website. It was |
| 22 |
developed, originally, because I needed a more flexible replacement for |
| 23 |
[Planet][] to use at [Feminist Blogs][]. |
| 24 |
|
| 25 |
[Planet]: http://www.planetplanet.org/ |
| 26 |
[Feminist Blogs]: http://feministblogs.org/ |
| 27 |
|
| 28 |
FeedWordPress is designed with flexibility, ease of use, and ease of |
| 29 |
configuration in mind. You'll need a working installation of WordPress or |
| 30 |
WordPress MU (version [3.0] or later), and also FTP or SFTP access to your web |
| 31 |
host. The ability to create cron jobs on your web host is helpful but not |
| 32 |
required. You *don't* need to tweak any plain-text configuration files and you |
| 33 |
*don't* need shell access to your web host to make it work. (Although, I should |
| 34 |
point out, web hosts that *don't* offer shell access are *bad web hosts*.) |
| 35 |
|
| 36 |
[WordPress]: http://wordpress.org/ |
| 37 |
[WordPress MU]: http://mu.wordpress.org/ |
| 38 |
[3.0]: http://codex.wordpress.org/Version_3.0 |
| 39 |
|
| 40 |
== Installation == |
| 41 |
|
| 42 |
To use FeedWordPress, you will need: |
| 43 |
|
| 44 |
* an installed and configured copy of [WordPress][] or [WordPress MU][] |
| 45 |
(version 3.0 or later). |
| 46 |
|
| 47 |
* FTP, SFTP or shell access to your web host |
| 48 |
|
| 49 |
= New Installations = |
| 50 |
|
| 51 |
1. Download the FeedWordPress installation package and extract the files on |
| 52 |
your computer. |
| 53 |
|
| 54 |
2. Create a new directory named `feedwordpress` in the `wp-content/plugins` |
| 55 |
directory of your WordPress installation. Use an FTP or SFTP client to |
| 56 |
upload the contents of your FeedWordPress archive to the new directory |
| 57 |
that you just created on your web host. |
| 58 |
|
| 59 |
3. Log in to the WordPress Dashboard and activate the FeedWordPress plugin. |
| 60 |
|
| 61 |
4. Once the plugin is activated, a new **Syndication** section should |
| 62 |
appear in your WordPress admin menu. Click here to add new syndicated |
| 63 |
feeds, set up configuration options, and determine how FeedWordPress |
| 64 |
will check for updates. For help, see the [FeedWordPress Quick Start][] |
| 65 |
page. |
| 66 |
|
| 67 |
[FeedWordPress Quick Start]: http://feedwordpress.radgeek.com/wiki/quick-start |
| 68 |
|
| 69 |
= Upgrades = |
| 70 |
|
| 71 |
To *upgrade* an existing installation of FeedWordPress to the most recent |
| 72 |
release: |
| 73 |
|
| 74 |
1. Download the FeedWordPress installation package and extract the files on |
| 75 |
your computer. |
| 76 |
|
| 77 |
2. Upload the new PHP files to `wp-content/plugins/feedwordpress`, |
| 78 |
overwriting any existing FeedWordPress files that are there. |
| 79 |
|
| 80 |
3. Log in to your WordPress administrative interface immediately in order |
| 81 |
to see whether there are any further tasks that you need to perform |
| 82 |
to complete the upgrade. |
| 83 |
|
| 84 |
4. Enjoy your newer and hotter installation of FeedWordPress |
| 85 |
|
| 86 |
== Using and Customizing FeedWordPress == |
| 87 |
|
| 88 |
FeedWordPress has many options which can be accessed through the WordPress |
| 89 |
Dashboard, and a lot of functionality accessible programmatically through |
| 90 |
WordPress templates or plugins. For further documentation of the ins and |
| 91 |
outs, see the documentation at the [FeedWordPress project homepage][]. |
| 92 |
|
| 93 |
[FeedWordPress project homepage]: http://feedwordpress.radgeek.com/ |
| 94 |
|
| 95 |
== Changelog == |
| 96 |
|
| 97 |
= 2011.1019 = |
| 98 |
|
| 99 |
* BUGFIX: "THERE ARE NO HTTP TRANSPORTS AVAILABLE" ERROR FIXED: The initial |
| 100 |
support for HTTP Basic and Digest authentication in version 2011.1018 |
| 101 |
contained a bug that could cause HTTP requests for feeds or for other |
| 102 |
WordPress resources to break down if you do not have the PHP curl module |
| 103 |
installed. This bug has been fixed, and these errors should no longer |
| 104 |
appear. |
| 105 |
|
| 106 |
* IMPROVED HTTP AUTHENTICATION SUPPORT: In addition, the HTTP Authentication |
| 107 |
support in FeedWordPress has been extended, to ensure that Basic |
| 108 |
authentication is available in many web host configurations, and to allow |
| 109 |
you to add a username and password for a feed immediately when you |
| 110 |
subscribe to it. |
| 111 |
|
| 112 |
= 2011.1018 = |
| 113 |
|
| 114 |
* HTTP BASIC AND DIGEST AUTHENTICATION SUPPORT: FeedWordPress now offers |
| 115 |
improved support for syndicating feeds that make use of HTTP Basic or HTTP |
| 116 |
Digest authentication methods. In order to set up authentication on one of |
| 117 |
your feeds, just go to its Settings > Feed page, and click on the "Uses |
| 118 |
Username/Password" link underneath the Feed URL. Enter the username and |
| 119 |
password for accessing the feed, then select the authentication method. (If |
| 120 |
you're not sure which method your feed provider uses, try Basic first.) |
| 121 |
Save Changes, and syndicate away. |
| 122 |
|
| 123 |
NOTE: HTTP Digest support requires the curl module for PHP. If you are not |
| 124 |
sure whether this module has been installed, contact your web hosting |
| 125 |
provider to check. |
| 126 |
|
| 127 |
* WP 3.3 (BETA) COMPATIBILITY: This version fixes an init-sequence bug that |
| 128 |
could cause intrusive warning messages or fatal errors in WP 3.3 beta |
| 129 |
versions. |
| 130 |
|
| 131 |
* BUGFIX: FIXES LONG DELAYS IN UPDATES SCHEDULES IN LARGE INSTALLATIONS. A |
| 132 |
performance feature introduced in version 2011.0721 had some flaws in its |
| 133 |
implementation, which tended to create serious delays (on the order of |
| 134 |
several hours) in FeedWordPress's attempts to schedule updates for feeds, |
| 135 |
when users had a very large number of feeds (several dozen or more) in their |
| 136 |
FeedWordPress installation. This feature has been reconfigured to adjust |
| 137 |
dynamically to the number of feeds in Syndicated Sources and the frequency |
| 138 |
with which they are updated. If you've seen a lot of ready-to-update feeds |
| 139 |
piling up, several hours after they were supposed to get updated, then this |
| 140 |
upgrade should better ensure that your feeds get updated in a timely fashion. |
| 141 |
|
| 142 |
* BUGFIX: syndicated_item_guid FILTERS FIXED. Previous versions of |
| 143 |
FeedWordPress theoretically allowed for filters on the syndicated_item_guid |
| 144 |
hook, which was intended to filter the globally-unique identifier element |
| 145 |
(rss:guid or atom:id) -- useful if you need to convince FeedWordPress to use |
| 146 |
different guids, or to recognize two or more incoming posts as versions of |
| 147 |
the same post rather than as distinct items. However, while the hook |
| 148 |
affected the guid stored in the WordPress database, it did not affect the |
| 149 |
guid used to check whether an incoming feed item had already been syndicated |
| 150 |
or was a new item -- which greatly limited the practical usefulness of the |
| 151 |
filter. This bug has been fixed: syndicated_item_guid filters should now |
| 152 |
properly control not only the final database record, but also the initial |
| 153 |
uniqueness test applied to posts. |
| 154 |
|
| 155 |
= 2011.0721 = |
| 156 |
|
| 157 |
* BUGFIX: SERIOUS BUG CAUSING RARE UNEXPECTED DELETION OF PAGES AND OTHER |
| 158 |
CONTENT. A bug in the guid-checking code for some rare kinds of guids could |
| 159 |
cause content in the wp_posts table to seemingly disappear at random after |
| 160 |
FeedWordPress updates.This most frequently but not exclusively affected |
| 161 |
static pages. What actually happened is that in these rare cases the |
| 162 |
existing static page was mistaken for an older version of the new incoming |
| 163 |
syndicated post, which was then stored as a new revision of the original |
| 164 |
page. The bug that caused these mistaken identities has been fixed. |
| 165 |
|
| 166 |
* BUGFIX: UNWANTED AUTOMATIC PAGE-LOAD-BASED UPDATES NO LONGER A NUISANCE. |
| 167 |
Some users encountered a bug in which FeedWordPress would adopt an automatic |
| 168 |
page-load-based update method, even if they had requested that it not do |
| 169 |
so, and that it use a manual or cron job update method instead. The bug |
| 170 |
causing this has been fixed, and page-load-based updates should no longer |
| 171 |
trigger unless explicitly turned on. |
| 172 |
|
| 173 |
* WP 3.2 USER INTERFACE COMPATIBILITY: POST TAGS BOX NOW WORKS AGAIN. The |
| 174 |
release of WordPress 3.2 caused a breakage in the tags box which prevented |
| 175 |
you from adding or removing tags under Syndication --> Categories & Tags. |
| 176 |
(The breakage was the result of an incompatibility introduced by the new |
| 177 |
release of jQuery.) This breakage has now been fixed, and the tags box |
| 178 |
should work correctly again. |
| 179 |
|
| 180 |
* FEED UPDATE SCHEDULING IMPROVEMENTS: UI. The Syndicated Sources table now |
| 181 |
provides considerably more data to understand update scheduling, when |
| 182 |
specific scheduling decisions are made because of, e.g., requests from the |
| 183 |
feed producer. |
| 184 |
|
| 185 |
* FEED UPDATE SCHEDULING IMPROVEMENTS: ENFORCEABLE "MINIMUM INTERVAL" SETTING |
| 186 |
TO SPACE OUT UPDATES. Some feeds request specific update schedules, using |
| 187 |
standard elements such as sy:updateFrequency and rss:ttl. Normally, |
| 188 |
FeedWordPress respects any scheduling requests that a feed makes -- if it |
| 189 |
requests a longer gap between polls than what FWP would normally adopt, then |
| 190 |
FWP slows down to meet the request. If it indicates a shorter gap than what |
| 191 |
FWP would normally adopt, FWP speeds up and checks that feed for updates |
| 192 |
more often than it normally would. Now, there should not be any way for user |
| 193 |
settings to override an explicit slow-down request from the feed producer -- |
| 194 |
if producers indicate a particular update schedule, then polling the feed |
| 195 |
more frequently than they request is considered abusive behavior. But |
| 196 |
there's no reason why users should not be able -- if they so desire -- to |
| 197 |
override speed-up requests, and poll a feed *less* frequently than the |
| 198 |
indicated update schedule, if the FWP user wants to space update checkins |
| 199 |
over a longer interval of time. Before, they could not do this: FWP always |
| 200 |
sped up to meet the indicated update schedule. Now, they can do this, by |
| 201 |
using the new "Minimum Interval" setting in Syndication --> Feeds & |
| 202 |
Updates.. |
| 203 |
|
| 204 |
= 2011.0706 = |
| 205 |
|
| 206 |
* WP 3.2 COMPATIBILITY: ELIMINATES FATAL ERROR "Call to undefined method |
| 207 |
WP_SimplePie_File::WP_SimplePie_File() in |
| 208 |
[...]/wp-content/plugins/feedwordpress/feedwordpress.php on line 1841." The |
| 209 |
latest release of WordPress, version 3.2, has shifted the minimum |
| 210 |
requirements up to PHP 5.2, and in line with the shift to PHP5 they have |
| 211 |
rewritten a number of code segments that made use of now-obsolete PHP4 |
| 212 |
idioms. Unfortunately, this caused a fatal error whenever FeedWordPress |
| 213 |
attempted to make use of the cache, since FWP's caching plugin was written |
| 214 |
to match the older idiom. FeedWordPress has been updated to follow the new, |
| 215 |
PHP5 idiom when possible, thus eliminating the fatal error. |
| 216 |
|
| 217 |
* PERFORMANCE: The handling of queries to determine whether posts had been |
| 218 |
previously syndicated produced some very slow queries (usually, but not |
| 219 |
always, involving a scan over the MD5(post_guid) column of the table). The |
| 220 |
code that prepares MySQL queries for previously-syndicated checks has been |
| 221 |
revised to eliminate the MD5(post_guid) scan entirely, and to significantly |
| 222 |
improve performance by eliminating other unnecessary clauses. |
| 223 |
|
| 224 |
* BUGFIX: NO LONGER DESTROYS STICKY POSTS. Previous versions could destroy |
| 225 |
(or, more precisely, replace the content of) sticky posts due to some |
| 226 |
queries mashed together in unexpected ways by WordPress. Version 2011.0706 |
| 227 |
accounts for and eliminates the problem; your sticky posts should be safe |
| 228 |
once again. |
| 229 |
|
| 230 |
* BUGFIX: GUIDS CONTAINING MYSQL-ESCAPED CHARACTERS NO LONGER CAUSE DUPLICATE |
| 231 |
POSTS TO APPEAR. One remaining source of duplicate post issues in 2011.0602 |
| 232 |
was guids that contained characters that needed to be escaped for MySQL, |
| 233 |
such as single quotes and double quotes. The work-around for handling |
| 234 |
filtered URIs has now been corrected to ensure that these do not cause |
| 235 |
duplicate posts. |
| 236 |
|
| 237 |
= 2011.0602 = |
| 238 |
|
| 239 |
* WP 3.1.3 COMPAT / BUGFIX: WHITESPACE IN GUIDS NO LONGER PRODUCES DUPLICATE |
| 240 |
POSTS. The work-around for handling filtered URIs in guid elements has now |
| 241 |
been extended to handle URIs that were filtered because of leading or |
| 242 |
trailing whitespace, in addition to URIs that were filtered because of |
| 243 |
unapproved schemes. |
| 244 |
|
| 245 |
* WP 3.1.3 COMPAT / BUGFIX: RELATIVE URLS IN GUIDS NO LONGER PRODUCE DUPLICATE |
| 246 |
POSTS. The work-around for handling filtered URIs in guid elements has now |
| 247 |
been extended to handle URIs that were altered without being filtered out |
| 248 |
entirely (most commonly because a scheme was added to a relative URL). |
| 249 |
|
| 250 |
* BUGFIX: UPDATES TO POST NO LONGER CAUSE DUPLICATE DRAFT VERSION TO APPEAR. |
| 251 |
Under certain conditions in 2011.0531, an update to an existing post would |
| 252 |
not be properly applied to the post itself, but rather would appear as a |
| 253 |
duplicate post with Draft status. This bug has been eliminated, and updates |
| 254 |
will now be properly inserted as revisions to the existing post. |
| 255 |
|
| 256 |
= 2011.0531 = |
| 257 |
|
| 258 |
* WORDPRESS 3.1.3 COMPATIBILITY: DUPLICATE POSTS ISSUE FIXED. Due to |
| 259 |
internal changes in the way that WordPress handles post guids in the |
| 260 |
most recent release (3.1.3), many users experienced problems with many |
| 261 |
duplicate posts appearing in rapid succession. (Specifically, this would |
| 262 |
happen with any posts using tag: URL guids -- such as all the posts |
| 263 |
coming from Blogger feeds or feeds from other Google services.) This |
| 264 |
compatibility release of FeedWordPress eliminates the issue by working |
| 265 |
around the new restrictions on tag: URLs. |
| 266 |
|
| 267 |
* NEW AND IMPROVED DIAGNOSTICS: Syndication --> Diagnostics now contains some |
| 268 |
new diagnostics settings useful for debugging problems with duplicate posts |
| 269 |
(allowing you to easily view the guid of posts in the WordPress posts |
| 270 |
database and allowing you to track the SQL used to check for existing |
| 271 |
versions of a syndicated post). |
| 272 |
|
| 273 |
= 2011.0512 = |
| 274 |
|
| 275 |
* DIAGNOSTICS IMPROVEMENTS; "THERE MAY BE A BUG IN FEEDWORDPRESS" CRITICAL |
| 276 |
ERROR NOTICES ELIMINATED: This version includes some major improvements |
| 277 |
to the Syndication --> Diagnostics section, which should aid in |
| 278 |
troubleshooting difficulties with items failing to be imported, posts |
| 279 |
failing to be properly inserted into the database, or updates failing to |
| 280 |
be recorded. If you have been encountering critical error / bug notices |
| 281 |
with a white screen and the message "THERE MAY BE A BUG IN |
| 282 |
FEEDWORDPRESS," followed by an extraordinarily long dump of mostly |
| 283 |
incomprehensible diagnostic information, you'll be happy to know that |
| 284 |
the condition causing these notices has been eliminated. In the few |
| 285 |
cases where errors may still crop up with database insertions, |
| 286 |
FeedWordPress will now produce a significantly more manageable and more |
| 287 |
useful diagnostic message. |
| 288 |
|
| 289 |
* BUGFIX: NEW POSTS FAILING TO APPEAR IN A CLEANLY-INSTALLED FEEDWORDPRESS |
| 290 |
SYSTEM. If you encountered a recurring problem with FeedWordPress |
| 291 |
failing to import new posts, after a clean install of FeedWordPress |
| 292 |
(i.e., not an upgrade from a previous version), this problem may have |
| 293 |
been the result of a bug with author-handling which has now been fixed |
| 294 |
in the 2011.0512 release. (If the problem does *not* go away with the |
| 295 |
upgrade, this version also includes significant improvements to the |
| 296 |
Diagnostics system, which will help track down what *is* causing it |
| 297 |
in your particular case.) |
| 298 |
|
| 299 |
* PERFORMANCE: New handling of update hashes allows FeedWordPress to avoid |
| 300 |
a certain kind of infinite loop, caused when two more more different |
| 301 |
syndicated feeds each carried a version of the same item (for example, |
| 302 |
because it appeared on two different aggregator feeds that you're |
| 303 |
syndicating). In previous versions, when this kind of loop cropped up, |
| 304 |
syndicated posts could pile up an indefinitely large number of revisions |
| 305 |
-- each revision alternating between the version from each of the two |
| 306 |
feeds where it appeared -- which would, over time, dramatically inflate |
| 307 |
the size of the database, and kill the performance of queries on the |
| 308 |
post table. This issue has been resolved: revisions of the post that |
| 309 |
have been syndicated once will not be re-syndicated over and over again. |
| 310 |
|
| 311 |
* AUTHOR LISTS: Lists of authors presented on the Author settings pages |
| 312 |
should now be easier to scan through, with author names arranged in |
| 313 |
alphabetical order. |
| 314 |
|
| 315 |
* FEED ITEM DATE PARSING: More tweaks to make date-time handling more |
| 316 |
resilient when feeds provide broken or weird values for the timestamps |
| 317 |
on syndicated items. FWP will now attempt to work around unparseable |
| 318 |
timezone values. |
| 319 |
|
| 320 |
* AUTHOR MATCHING: Now attempts to match author names against the WP login |
| 321 |
name in addition to display_name; when creating user record, also fills |
| 322 |
in some best-guess values for nickname, firstname and lastname. Also |
| 323 |
properly picks up Atom 1.0 author/uri data from feed. |
| 324 |
|
| 325 |
* COMPATIBILITY: FeedWordPress has been successfully tested for |
| 326 |
compatibility with recent releases of WordPress, up to version 3.1.2. |
| 327 |
|
| 328 |
= 2011.0211 = |
| 329 |
|
| 330 |
* BUGFIX: DUPLICATE POSTS WHEN GUIDS ARE TOO LONG: When feeds included |
| 331 |
exceptionally long GUIDs, FeedWordPress could occasionally get into |
| 332 |
a situation where posts with the long GUIDs would be duplicated over |
| 333 |
and over again with each update (because FWP failed to store the full |
| 334 |
GUID, due to length constraints in the relevant database tables). |
| 335 |
Without the full GUID, FWP would not know that the post had already |
| 336 |
been syndicated once. This bug has been fixed, and should no longer |
| 337 |
produce duplicate posts. |
| 338 |
|
| 339 |
* HTTP TIMEOUT SETTING: If you are frequently running into timeout |
| 340 |
problems with one or more of the feeds you syndicate, FWP now allows you |
| 341 |
to adjust the timeout for HTTP requests using a global or feed-by-feed |
| 342 |
setting. |
| 343 |
|
| 344 |
* HTTP GET PARAMETERS: You can now temporarily or permanently add HTTP |
| 345 |
GET parameters to a subscription using an interface in Syndication --> |
| 346 |
Feeds & Updates. This is especially helpful for making quick, short-term |
| 347 |
changes to a subscription (for example, to pull in all the previous |
| 348 |
items from a web service, before settling down to pulling in only newly |
| 349 |
updated items). |
| 350 |
|
| 351 |
* DIAGNOSTICS SYSTEM: Added several new diagnostics which are useful in |
| 352 |
troubleshooting, and established a framework for add-on modules to hook |
| 353 |
in with their own diagnostic messages. |
| 354 |
|
| 355 |
* UI: Adjusted some internal coding, which should allow for settings |
| 356 |
pages and add-ons to properly display multiple category pickers on a |
| 357 |
single settings page. |
| 358 |
|
| 359 |
* PHP4 COMPATIBILITY TWEAKS: This version makes some tweaks to the handling |
| 360 |
of object references which should improve compatibility with older |
| 361 |
versions of PHP. (Although, I should note, web hosts that still force |
| 362 |
you to run under PHP 4 -- in 2011! -- are *bad web hosts*.) |
| 363 |
|
| 364 |
* IMPROVED PERFORMANCE: This version eliminates a *major* performance drag |
| 365 |
that shows up on sites with large numbers of users (due to some poor |
| 366 |
decisions about where to place a user query, which caused the user table |
| 367 |
to be scanned frequently when it did not need to be). If you experienced |
| 368 |
serious problems with CPU load or slow database performance under |
| 369 |
2010.0905, which kicked in immediately when FWP was loaded and tended |
| 370 |
to disappear immediately if FWP was de-activated, it is likely that |
| 371 |
upgrading away from 2010.0905 to the most recent version will resolve |
| 372 |
your problem. |
| 373 |
|
| 374 |
|
| 375 |
= 2010.0905 = |
| 376 |
|
| 377 |
* BUGFIX: CATEGORIES AND TAGS CORRECTLY ASSIGNED IN AUTOMATIC UPDATES. |
| 378 |
Version 2010.0903 switched over to a new way of assigning categories and |
| 379 |
tags as part of its support for handling custom taxonomies. |
| 380 |
Unfortunately, the method that it uses is subjected to some checks of |
| 381 |
the current user's capabilities, which creates problems for posts that |
| 382 |
are being inserted into the WordPress database when there *is* no |
| 383 |
current user logged in (as, for example, when an update is being carried |
| 384 |
out from a cron job or automatic update). The result was that posts |
| 385 |
from cron jobs and automatic updates ended up with no Categories and no |
| 386 |
Tags being assigned. This bug has now been fixed: in 2010.0905, Tags and |
| 387 |
Categories should be correctly assigned to all posts, regardless of |
| 388 |
whether they were added from manual updates, cron jobs, or automatic |
| 389 |
updates. |
| 390 |
|
| 391 |
= 2010.0903 = |
| 392 |
|
| 393 |
* WORDPRESS 3 REQUIRED: Please note that this release of FeedWordPress |
| 394 |
*requires* WordPress 3.0 or later. If you are currently using a 2.x |
| 395 |
branch of WordPress, you will need to upgrade to WordPress 3 before you |
| 396 |
can successfully upgrade FeedWordPress. |
| 397 |
|
| 398 |
* BUGFIX: NO MORE DISAPPEARING "SYNDICATED SOURCES" PANEL; INTERNET |
| 399 |
EXPLORER UI GLITCH APPARENTLY FIXED: Several users independently |
| 400 |
reported a problem with FWP 2010.0623 and various versions of IE. A |
| 401 |
problem with the HTML markup caused IE (but not Firefox or |
| 402 |
Chrome) to completely hide the Syndicated Sources administration panel |
| 403 |
(the main list of currently-syndicated sources, and the main location |
| 404 |
for adding new sources, under the Syndication menu item) when a user |
| 405 |
added their first syndicated feed. Maddeningly, the glitch seemed to |
| 406 |
affect some IE users and not others: I was never able to reproduce the |
| 407 |
problem for myself on my own machines. However, the markup of Syndicated |
| 408 |
Sources has undergone significant changes and corrections since |
| 409 |
2010.0623, and two independent sources who had been having this problem |
| 410 |
confirm that they no longer encounter it with the updated version. For |
| 411 |
the time being, I am going to declare this bug squashed. |
| 412 |
|
| 413 |
* BUGFIX: MORE PROTECTION AGAINST FATAL ERRORS FROM PLUGGABLE VERSIONS OF |
| 414 |
SimplePie: FeedWordPress now takes some precautions that should help to |
| 415 |
better avoid conflicts for users who have installed pluggable versions |
| 416 |
of SimplePie for another plugin or theme. (You may not know that you have |
| 417 |
done this; but if you've been encountering fatal errors indicating that |
| 418 |
you cannot redeclare class SimplePie, or something along those lines, |
| 419 |
there is now a better chance that those fatal errors will be eliminated. |
| 420 |
|
| 421 |
* PERFORMANCE: SIGNIFICANTLY REDUCED MEMORY CONSUMPTION FOR LARGE UPDATES: |
| 422 |
FeedWordPress is still a memory-hungry little module, especially when |
| 423 |
you are dealing with very large feeds. However, users should notice a |
| 424 |
significant reduction in memory overloads, especially if they update a |
| 425 |
large number of feeds at once. |
| 426 |
|
| 427 |
* USER INTERFACE IMPROVEMENTS: Nothing is radically different, but there's |
| 428 |
been a fair amount of extra spit and polish added, including a convenient |
| 429 |
new Dashboard widget that may save you a trip to the Syndication menu, |
| 430 |
a lot of effort to make the relationship between global and feed-by-feed |
| 431 |
settings more obvious to the user and more easily controllable, to make |
| 432 |
navigation between settings pages easier, to sand off a few rough edges, |
| 433 |
and to make other improvements on the margins. I hope you'll like how |
| 434 |
it looks. |
| 435 |
|
| 436 |
* ADDING MULTIPLE FEEDS: FeedWordPress now provides a convenient mode for |
| 437 |
adding multiple feeds at once, using either a copy-and-pasted list, or |
| 438 |
else an OPML file. Go to Syndication --> Syndicated Sources and check |
| 439 |
out the two new buttons underneath the New Source input box. When you |
| 440 |
have to add a number of feeds at once, this can save you considerable |
| 441 |
time and trouble. |
| 442 |
|
| 443 |
* IMPROVED HANDLING OF AUTHORS WITH DUPLICATE E-MAIL ADDRESS AND AUTHORS |
| 444 |
WITH NAMES WRITTEN IN FOREIGN SCRIPTS: WordPress 3 is increasingly picky |
| 445 |
about what it will accept for new author accounts, and some of the |
| 446 |
conditions it imposes can cause error conditions that prevent posts from |
| 447 |
being properly syndicated, or properly attributed, if authors happen to |
| 448 |
have identical e-mail addresses, or if users are given usernames that are |
| 449 |
written in non-Western scripts. FeedWordPress now handles these much |
| 450 |
better, and systematically works to avoid clashes between syndicated |
| 451 |
authors' account names or in their e-mail addresses, which should result |
| 452 |
in significantly better results in mapping author names to WordPress |
| 453 |
user accounts. |
| 454 |
|
| 455 |
* MAPPING CATEGORIES ON SYNDICATED POSTS TO TAGS NOW BETTER SUPPORTED: |
| 456 |
In previous versions, the only way for the Categories provided by a |
| 457 |
syndicated feed to be mapped into Post Tags was to instruct FWP to |
| 458 |
create new tags, rather than new categories, for unfamiliar categories |
| 459 |
from the feed. This works fine if you want tags to be the default; but |
| 460 |
if you want only a *specific* set of tags, there was no way to get them |
| 461 |
without getting most or all other categories imported as tags. You can |
| 462 |
now do this by creating a tag (under Posts ==> Post Tags) before |
| 463 |
importing the post; when the syndicated category matches a pre-existing |
| 464 |
tag, the incoming post will be tagged with that tag, without creating |
| 465 |
a local Post Category. |
| 466 |
|
| 467 |
* REL-TAG MICROFORMAT SUPPORT FOR INLINE TAGS: Syndicated posts that |
| 468 |
contain inline tags, marked up using the Rel-Tag microformat |
| 469 |
<http://microformats.org/wiki/rel-tag>, are now tagged with the tags |
| 470 |
provided by Rel-Tag format links. |
| 471 |
|
| 472 |
* MUCH GREATER CONTROL OVER CATEGORY AND TAG MAPPING: This is partly the |
| 473 |
result of building in support for a potentially endless set of custom |
| 474 |
taxonomies (see below), but in general there has been a great deal of |
| 475 |
effort towards giving you more control over how categories and tags |
| 476 |
provided by the feed are mapped into terms on the local blog. In |
| 477 |
particular, you can now force FeedWordPress to create only categories |
| 478 |
from categories and tags provided by the feed; or to create only tags; |
| 479 |
or to search both categories and tags for a match; or you can simply |
| 480 |
force it to drop all of the categories provided by the feed and use |
| 481 |
only categories or tags that you explicitly provide. In addition, you |
| 482 |
can now also choose whether to override global categories settings with |
| 483 |
a local, feed-specific setting; or whether to *add together* *both* the |
| 484 |
global categories and the local feed-specific categories -- depending |
| 485 |
on whatever your use-case may demand. |
| 486 |
|
| 487 |
* CUSTOM POST TYPES AND TAXONOMY SUPPORTS: This is mainly for the |
| 488 |
super-geeky, but if you use other plugins or themes that make |
| 489 |
significant use of WordPress's support for custom post types and custom |
| 490 |
taxonomies, you may be pleased to find that FeedWordPress now allows you |
| 491 |
to feed incoming posts into any custom feed type that you wish, and to |
| 492 |
map categories and tags from the feed to custom taxonomies as well as |
| 493 |
to the standard Category and Tag taxonomies. |
| 494 |
|
| 495 |
* STORING NAMESPACED CUSTOM FEED ELEMENTS IN POST CUSTOM FIELDS: If you |
| 496 |
would like to use FeedWordPress's support for storing custom meta-data |
| 497 |
from feed elements in the custom fields for a post (for example, to |
| 498 |
store geolocation data or iTunes media meta-data), you'll find that it's |
| 499 |
now much easier for you to access these namespaced elements. You always |
| 500 |
could access them, but in previous versions you might have to write |
| 501 |
something ugly like $(/{http://www.w3.org/2003/01/geo/wgs84_pos#}lat) |
| 502 |
just to get at the value of a `<geo:lat>` tag. Now, as long as you use |
| 503 |
the same mnemonic codes that the feed producer used, you should always |
| 504 |
be able to write a nice, simple expression like $(/geo:lat) to get the |
| 505 |
value of a <geo:lat> tag. |
| 506 |
|
| 507 |
* CUSTOM DIRECTORY STRUCTURE SUPPORT: if you poke at it enough, WordPress |
| 508 |
is relatively flexible about where it should store admin interface code, |
| 509 |
uploaded content, plugins, and a number of other things that occupy an |
| 510 |
important place in the WordPress directory structure. Previous versions |
| 511 |
of FeedWordPress encountered serious errors or broke entirely when used |
| 512 |
with directory structures other than the default. This should now be |
| 513 |
fixed: FWP now supports custom directory structures wherever WordPress |
| 514 |
allows them to be customized, rather than depending on the default |
| 515 |
locations. Enjoy your freedom! |
| 516 |
|
| 517 |
* MANY NEW FILTERS AND API UTILITY FUNCTIONS FOR ADD-ON PROGRAMMERS: There |
| 518 |
have been too many improvements to list them all in this ChangeLog, but |
| 519 |
it means that much more power and ease for folks who are customizing |
| 520 |
FeedWordPress through PHP filters or add-on modules. Fuller |
| 521 |
documentation will be put up at the Wiki at feedwordpress.radgeek.org |
| 522 |
soon. |
| 523 |
|
| 524 |
= 2010.0623 = |
| 525 |
|
| 526 |
* WORDPRESS 3.0 COMPATIBILITY / AUTHOR MAPPING INTERFACE ISSUES: I |
| 527 |
resolved a couple of outstanding issues with the author mapping |
| 528 |
interface (Syndication --> Authors), which were preventing new users |
| 529 |
from being created correctly and author mapping rules from being set up |
| 530 |
correctly. These partly had to do with new restrictions on user account |
| 531 |
creation introduced in WordPress 3.0; anyway, they should now be fixed. |
| 532 |
|
| 533 |
* MORE EFFICIENT SYNDICATED URL LOOKUPS: Several users noticed that the |
| 534 |
bug fix introduced in 2010.0528 for compatibility with post-listing |
| 535 |
plugins caused a lot more queries to the database in order to look up |
| 536 |
numerical post IDs from the URL provided to the filter. This shouldn't |
| 537 |
cause any major problems, but it is not as efficient as it could be; the |
| 538 |
code now takes advantage of a more efficient way of doing things, |
| 539 |
which usually will not require any additional database queries. |
| 540 |
|
| 541 |
* SIMPLEPIE FEED UPDATE ISSUES: If you have been having significant |
| 542 |
problems with getting feeds to update correctly, this may be the result |
| 543 |
of some bugs in the implementation of SimplePie caching that ships with |
| 544 |
WordPress (as of version 3.0). (You would most commonly experience this |
| 545 |
error if you continually saw errors such as "No feed found at <...>" in |
| 546 |
your updates.) Fortunately, SimplePie allows for a great deal of |
| 547 |
extensibility and this allows me to work around the problem; these |
| 548 |
error conditions should now be mostly eliminated when the underlying |
| 549 |
feed is valid. |
| 550 |
|
| 551 |
* UI: SHOW INACTIVE SOURCES: When you use the default unsubscribe option |
| 552 |
-- which turns off the subscription to a feed while preserving the posts |
| 553 |
from it and the syndication-related meta-data for the feed -- the |
| 554 |
unsubscribed feed can now easily be viewed in a special "Inactive" |
| 555 |
section of the Syndicated Sources page. (As a side benefit, if you've |
| 556 |
accidentally, or only temporarily, turned off the subscription to a |
| 557 |
feed, it is now much easier to restore the feed to being active, or to |
| 558 |
delete it permanently, if you prefer. |
| 559 |
|
| 560 |
* UI: FEED FINDER / SWITCH FEED INTERFACE IMPROVEMENTS: changes to styling |
| 561 |
and options for the feed finder / switch feed, which should now make it |
| 562 |
easier, in some cases, to find alternative feeds, and make interface |
| 563 |
options more clearly visible. |
| 564 |
|
| 565 |
* FILTERS: `syndicated_item_published` and `syndicated_item_updated` NOW |
| 566 |
PROPERLY AFFECT THE DATING OF POSTS. These filters used to affect some |
| 567 |
date-related settings, but not others -- and, most importantly, not the |
| 568 |
final date that is set for a post's publication or last-modified date |
| 569 |
in the WordPress database. Now, they do affect that, as they should. |
| 570 |
(Filters should receive, and return, a long integer, representing a Unix |
| 571 |
epoch relative timestamp.) |
| 572 |
|
| 573 |
* MAGIC URL TO CLEAR THE CACHE: Suppose that you need to clear the feed |
| 574 |
cache, for whatever reason; suppose, even, that you need to clear it on |
| 575 |
a regular basis. One way you might do this is by logging into the |
| 576 |
FeedWordPress administrative interface and going to Syndication --> |
| 577 |
Performance. Another way you might do it, now, is to simply send an |
| 578 |
HTTP request to a magic URL provided by FeedWordPress: if your blog is |
| 579 |
at example.com, the URL would be <http://example.com/?clear_cache=1> |
| 580 |
|
| 581 |
= 2010.0602 = |
| 582 |
|
| 583 |
* CATEGORY BOX INTERFACE ELEMENT FIXED FOR WP 3.0: Stylesheet changes |
| 584 |
between WordPress 2.9.x and the WordPress 3.0 RC caused the Categories |
| 585 |
box under **Syndication --> Categories & Tags** to malfunction. This |
| 586 |
has been fixed. |
| 587 |
|
| 588 |
* LINK CATEGORY SELECTION BOX IN SYNDICATION ==> FEEDS FIXED FOR WP 2.8 |
| 589 |
AND 2.9: A WP 3.0 compatibility change introduced in 2010.0531 |
| 590 |
inadvertently broke the Syndicated Link Category selector under |
| 591 |
Syndication --> Feeds & Updates in WP 2.8 and WP 2.9, causing the post |
| 592 |
categories to be displayed in the selector rather than the link |
| 593 |
categories. This should now be fixed so that the selector will work |
| 594 |
correctly under both the current versions of WordPress and the 3.0 RC. |
| 595 |
|
| 596 |
* MORE PERMISSIVE HANDLING OF FEEDS WITH BAD CONTENT-TYPE HEADERS: One of |
| 597 |
the small advantages that MagpieRSS had over SimplePie is that it was |
| 598 |
more tolerant about parsing well-formed feeds that the remote web server |
| 599 |
happened to deliver with weird or incorrect HTTP Content-type headers. |
| 600 |
In feeds affected by this problem, the new SimplePie parser would simply |
| 601 |
fail to find a feed, due to its being led astray by the contents of the |
| 602 |
Content-type header. This version includes an extension to SimplePie's |
| 603 |
content-type sniffer that offers more permissive handling of the HTTP |
| 604 |
headers. |
| 605 |
|
| 606 |
* MORE FULL-TEXT "EXCERPTS" NOW PROPERLY SHORTENED. Version 2010.0528 |
| 607 |
introduced code to control for cases in which elements intended for |
| 608 |
item summaries are (ill-advisedly) used to carry the full text of posts; |
| 609 |
past versions of FeedWordPress would simply include the full text of the |
| 610 |
post in the excerpt field, but newer versions now attempt to detect |
| 611 |
this condition when it arises and to head it off, by blanking out the |
| 612 |
excerpt field and filling it with an automatically generated short, |
| 613 |
plain text excerpt from the full content. This release broadens the |
| 614 |
test conditions that indicate when an excerpt field is treated as |
| 615 |
identical to the full text of the post, and should therefore improve |
| 616 |
the handling of some feeds (such as Google Reader feeds) where the full |
| 617 |
text of each post was still appearing in the excerpt field. |
| 618 |
|
| 619 |
* FILTERS: `syndicated_item_published` AND `syndicated_item_updated` |
| 620 |
FILTERS NOW ALLOW FILTER AUTHORS TO CHANGE POST TIMESTAMPS. You can now |
| 621 |
use the `syndicated_item_published` and `syndicated_item_updated` filter |
| 622 |
hooks to write filters or add-ons which directly change the post date |
| 623 |
and most-recently-updated timestamps on incoming syndicated posts. Props |
| 624 |
to niska for pointing out where the filters needed to be applied in |
| 625 |
order to change WordPress's internal timestamps for incoming posts. |
| 626 |
|
| 627 |
= 2010.0531 = |
| 628 |
|
| 629 |
* PERMALINK / CUSTOM FIELDS PROBLEM RESOLVED: An issue in 2010.0528 caused |
| 630 |
some posts to be imported without the proper syndication-related |
| 631 |
meta-data being attached (thus causing permalinks to point back to the |
| 632 |
aggregator website rather than to the source website, among other |
| 633 |
problems). This problem has been resolved (and a fix has been applied |
| 634 |
which will resolve the problem for any posts affected by this problem, |
| 635 |
if the original post is recent enough to still be available on the feed). |
| 636 |
|
| 637 |
* UI: The "Back End" section has been split into two separate sections -- |
| 638 |
"Performance" (dealing with caching, database index, and other |
| 639 |
performance tweaks), and "Diagnostics" (dealing with debug mode, |
| 640 |
update logging, and a number of new diagnostic tests which I will be |
| 641 |
rolling out over the next few releases). |
| 642 |
|
| 643 |
* Several minor interface bug fixes and PHP warning notices eliminated. |
| 644 |
|
| 645 |
= 2010.0528 = |
| 646 |
|
| 647 |
#### Compatibility #### |
| 648 |
|
| 649 |
* SIMPLEPIE IS NOW USED TO PARSE FEEDS; NO MORE MAGPIERSS UPGRADES NEEDED: |
| 650 |
One of the biggest changes in this release is that FeedWordPress no |
| 651 |
longer depends on MagpieRSS to parse feeds, and has switched to the much |
| 652 |
more up-to-date and flexible SimplePie feed parser, which is included as |
| 653 |
a standard part of WordPress versions 2.8 and later. Using SimplePie will |
| 654 |
hopefully allow for better handling of feeds going further, and will |
| 655 |
allow me greater flexibility in determining how exactly the feed parser |
| 656 |
will operate. It also means that FeedWordPress no longer requires |
| 657 |
special upgrades to the WordPress core MagpieRSS files, and should |
| 658 |
eliminate quite a bit of complexity. |
| 659 |
|
| 660 |
* MAGPIERSS COMPATIBILITY LAYER FOR EXISTING FILTERS AND ADD-ONS: However, |
| 661 |
I have also implemented a compatibility layer to ensure that existing |
| 662 |
filters and add-ons for FeedWordPress which depended on the MagpieRSS |
| 663 |
data format *should not be broken* by the switch to SimplePie. Going |
| 664 |
forward, I recommend that new filters and add-ons be written to take |
| 665 |
advantage of the SimplePie object representations of items, feeds, etc., |
| 666 |
rather than the MagpieRSS arrays, but the MagpieRSS arrays will still |
| 667 |
be available and older filters should continue to work as they have in |
| 668 |
the past. |
| 669 |
|
| 670 |
* COMPATIBILITY WITH WORDPRESS 2.9.x and 3.0: This release has been tested |
| 671 |
for the existing WordPress 2.9.x branch and with the upcoming release of |
| 672 |
WordPress 3.0. Changes in the user interface JavaScript between WordPress |
| 673 |
2.8.x and WordPress 2.9 caused the tag box interface element to break in |
| 674 |
the Syndication --> Categories & Tags settings page; changes in the API |
| 675 |
functions for adding new authors caused fatal errors under certain |
| 676 |
conditions in WordPress 3.0. These breakages have been fixed. |
| 677 |
|
| 678 |
* DROPPED LEGACY SUPPORT FOR WORDPRESS PRIOR TO 2.8: Because SimplePie is |
| 679 |
not included with versions of WordPress prior to 2.8, I have chosen to |
| 680 |
drop legacy support for WordPress versions 1.5 through 2.7. If you are |
| 681 |
using FeedWordPress with a version of WordPress before 2.8, you will |
| 682 |
have to upgrade your installation of WordPress in order to take |
| 683 |
advantage of this release. |
| 684 |
|
| 685 |
* PHP 5.3 COMPATIBILITY: A couple of compatibility issues, which were |
| 686 |
causing fatal errors amd ugly warnings for users of PHP 5.3, |
| 687 |
have been eliminated. |
| 688 |
|
| 689 |
#### Features and Processing #### |
| 690 |
|
| 691 |
* INTERFACE REORGANIZATION: The interface restructuring, began with |
| 692 |
Version 2009.0612, has been completed. Catch-all settings pages have |
| 693 |
been eliminated entirely for pages that cover each aspect of handling |
| 694 |
a feed: Feeds & Updates, Posts & Links, Authors, Categories & Tags, |
| 695 |
and Back End handling of the database and diagnostic information. |
| 696 |
Extensive new interface hooks allow add-on modules to significantly |
| 697 |
change or extend the FeedWordPress admin interface and workflow. |
| 698 |
|
| 699 |
* STORING INFORMATION FROM THE FEED IN CUSTOM FIELDS: Many users |
| 700 |
have written to request the ability to store information from elements |
| 701 |
in the feed in a custom field on each post. (So that, for example, if |
| 702 |
post includes a `itunes:duration` element, you could store the contents |
| 703 |
in a Custom Field called `duration` on the post (for a Theme to access |
| 704 |
later). The Custom Post Settings under Syndication --> Posts & Links now |
| 705 |
allow you to access any item or feed tag, using a syntax similar to |
| 706 |
a much-simplified version of XPath. See Posts & Links settings for |
| 707 |
details. |
| 708 |
|
| 709 |
* UPDATE-FREEZING ON MANUALLY EDITED POSTS: FeedWordPress now allows you |
| 710 |
to mark posts that have been manually edited, so that the changes you |
| 711 |
make will not be overwritten by later updates from the feed. If you make |
| 712 |
manual edits to a particular post, just check the "Manual editing" |
| 713 |
checkbox in order to protect your changes from being overwritten. If you |
| 714 |
want to block *all* posts from being updated after they are imported |
| 715 |
for the first time, a new "Updated Posts" setting in Posts & Links |
| 716 |
allows you to freeze all posts from a particular feed, or all syndicated |
| 717 |
posts. |
| 718 |
|
| 719 |
* SETTING: FEED-BY-FEED SETTINGS FOR WHERE PERMALINKS POINT TO: You've |
| 720 |
always been able to tell FeedWordPress whether permalinks for posts |
| 721 |
should point to the original source of the story or the local copy. Now |
| 722 |
you can choose different policies for different feeds, instead of one |
| 723 |
global policy for all feeds. (Of course, you can still use a global |
| 724 |
default if you prefer.) |
| 725 |
|
| 726 |
* SETTING: USER CONTROL OVER TIMING BASIS. You can now determine the |
| 727 |
schedule on which feeds are considered ready to poll for updates -- |
| 728 |
by default feeds become ready for polling after about 1 hour. You can |
| 729 |
now increase or decrease the time window under Syndication --> Feeds & |
| 730 |
Updates. (However, please pay *CAREFUL ATTENTION* to the recommendations |
| 731 |
and DO NOT set the scheduling lower than 60 minutes unless you are |
| 732 |
ABSOLUTELY SURE that you have specific permission from webmaster who |
| 733 |
provides that specific feed to poll more frequently than that. If you |
| 734 |
set this too low (and about 60 minutes is the polite minimum if you |
| 735 |
haven't been given a different figure), most webmasters will consider |
| 736 |
the frequent hits on their server as rude, or even downright abusive. |
| 737 |
|
| 738 |
* OTHER SETTINGS: New settings also include the ability to stop FWP from |
| 739 |
resolving relative URLs within syndicated content, and the ability to |
| 740 |
choose whether FeedWordPress should indicate the comment feed from the |
| 741 |
original source, or the local comment feed, when providing the comment |
| 742 |
feed URL for a syndicated post. |
| 743 |
|
| 744 |
#### Parsing #### |
| 745 |
|
| 746 |
* BETTER DATE HANDLING -- FEWER FLASHBACKS TO 1969 and 1970: FeedWordPress |
| 747 |
has made some bugfixes and some improvements in the logic for parsing |
| 748 |
dates. This should allow FeedWordPress to correctly parse more dates in |
| 749 |
more feeds; and, in the last resort, when FeedWordPress fails to |
| 750 |
correctly parse a date, to fall back to a more intelligent default. This |
| 751 |
should hopefully avoid most or all error conditions that have resulted |
| 752 |
in articles being erroneously dated to the dawn of the Unix epoch |
| 753 |
(31 December 1969 or 1 January 1970). |
| 754 |
|
| 755 |
* FULL-TEXT "EXCERPTS" NOW PROPERLY SHORTENED. Based on a straightforward |
| 756 |
reading of the existing RSS specs, it's reasonable for the |
| 757 |
rss:description element to be read as a plaintext summary or excerpt for |
| 758 |
the item containing the description -- with the full text of the item, |
| 759 |
if available, in another, better-suited element, such as the de facto |
| 760 |
standard content:encoded extension element. The problem is that uses of |
| 761 |
RSS rarely have much to do with anything like a straightforward reading |
| 762 |
of the specs. As a result, many actual RSS producers in the wild put the |
| 763 |
full text of the article in a description element. But since |
| 764 |
FeedWordPress has treated this text as a summary, this produces |
| 765 |
aggregated posts with lengthy "excerpts" containing the full text of the |
| 766 |
article. This release of FeedWordPress fixes the problem by doing a |
| 767 |
little digging before treating rss:description as a summary: if the |
| 768 |
description element is used properly as a plain text summary, then |
| 769 |
FeedWordPress will take the summary provided by the feed, rather than |
| 770 |
recreating its own excerpt from the full text; but if an RSS item has no |
| 771 |
full-text element other than description, FeedWordPress will treat the |
| 772 |
description element as the full text of the article, and generate a |
| 773 |
shortened excerpt automatically from that text. |
| 774 |
|
| 775 |
#### API #### |
| 776 |
|
| 777 |
* TEMPLATE API: new template tags `get_local_permalink()` and |
| 778 |
`the_local_permalink()` allow you to access the permalink for a post on |
| 779 |
your aggregator site, even when FeedWordPress is rewriting permalinks to |
| 780 |
point to the original source site. |
| 781 |
|
| 782 |
* NEW HOOKS FOR ADD-ONS AND FILTERS: I have added a number of new hooks |
| 783 |
which allow add-on modules to filter more precisely, gather information |
| 784 |
at more points, and to enhance the FeedWordPress admin interface. For |
| 785 |
a list of new hooks and documentation, see the FeedWordPress |
| 786 |
documentation wiki at |
| 787 |
<http://feedwordpress.radgeek.com/wiki/add-ons-and-filters> |
| 788 |
|
| 789 |
* FILTER API: A number of new utility methods have been added to the |
| 790 |
SyndicatedPost class to make it easier for filters and add-ons to |
| 791 |
|
| 792 |
* FILTER API: Globals $fwp_channel and $fwp_feedmeta DEPRECATED. These |
| 793 |
global variables, originally introduced to allow filters access to |
| 794 |
information about the source feed in `syndicated_item` filters (which |
| 795 |
were passed in through global variables rather than as parameters |
| 796 |
because of a bug in WP 1.5 which was then fixed in 1.5.1) have been |
| 797 |
DEPRECATED. If you have any filters or add-ons which still depend on |
| 798 |
these global variables, you should see about fixing them to access data |
| 799 |
about the source feed using the SyndicatedPost::link element instead. |
| 800 |
For documentation, see the FeedWordPress documentation wiki at |
| 801 |
<http://feedwordpress.radgeek.com/wiki/syndicatedpost> and |
| 802 |
<http://feedwordpress.radgeek.com/wiki/syndicatedlink>. |
| 803 |
|
| 804 |
* DIAGNOSTICS: I've included a number of new diagnostic options and |
| 805 |
messages, which should allow an experienced user to better investigate |
| 806 |
any problems that may crop up. |
| 807 |
|
| 808 |
#### Bug Fixes #### |
| 809 |
|
| 810 |
* BUGFIX: & IN PERMALINKS NO LONGER CAUSING ATOM OR HTML VALIDATION |
| 811 |
EFFORTS: Many users reported an issue in which syndicating a feed with |
| 812 |
special XML characters in the URLs (& was the most common, since it is |
| 813 |
used to separate HTTP GET parameters) would cause the aggregator's |
| 814 |
feeds to produce invalid (malformed) XML. This update addresses the |
| 815 |
issue in Atom feeds. Unfortunately, it has not been technically possible |
| 816 |
to address the problem in RSS 2.0 feeds, due to limitations on |
| 817 |
WordPress's internal templates for RSS feeds. |
| 818 |
|
| 819 |
* BUGFIX: BROKEN URLS IN "POPULAR POSTS" AND SIMILAR PLUGINS SHOULD NO |
| 820 |
LONGER BE BROKEN. A number of users noticed an issue where plugins and |
| 821 |
templates that listed posts in locations outside of the post loop |
| 822 |
(for example, "Popular Posts"-style plugins that listed posts in the |
| 823 |
sidebar), often produced the wrong URL for post links. (Typically, all |
| 824 |
the posts listed would get the same wrong URL.) This should now be |
| 825 |
fixed. Thanks to Björn for sending in a quick fix! |
| 826 |
|
| 827 |
* MINOR BUGFIXES: This release includes a number of fixes to minor bugs |
| 828 |
and compatibility issues, including: silent failures of the "Syndicate" |
| 829 |
button, "Illegal Offset Type" error messages from MagpieRSS, and others. |
| 830 |
|
| 831 |
= 2009.0707 = |
| 832 |
|
| 833 |
* BUGFIX: WORDPRESS 2.8 AJAX COMPATIBILITY ISSUES RESOLVED (blank or |
| 834 |
truncated "Syndicated Sites" administration page): Due to changes in the |
| 835 |
AJAX interface elements between WordPress 2.7 and WordPress 2.8, several |
| 836 |
FeedWordPress users encountered an issue where the front "Syndication" |
| 837 |
page in the FeedWordPress administrative interface would come up blank, |
| 838 |
without the normal "Syndicated Sites" list and "Update" control, or |
| 839 |
sometimes wth the boxes visible but one or both of them truncated, with |
| 840 |
only the title bar. This issue should now be resolved: with the new |
| 841 |
version of FeedWordPress, the compatibility issue that caused the |
| 842 |
disappearance should be eliminated, and if boxes are shown with only |
| 843 |
their handle visible, you should once again be able to drop down the |
| 844 |
rest of the box by clicking once on its title bar. |
| 845 |
|
| 846 |
* BUGFIX: TAG SETTING WIDGET FIXED. Due to changes in interface elements |
| 847 |
between WordPress 2.7 and WordPress 2.8, people using FeedWordPress with |
| 848 |
WordPress 2.8 found that the widget for setting tags to be applied to |
| 849 |
all syndicated posts, or all syndicated posts from a particular feed, |
| 850 |
no longer displayed "Add" and "Remove" buttons for individual tags. This |
| 851 |
issue has now been fixed, and the tagging widget should once again work |
| 852 |
more or less exactly like the tagging widget for individual posts in the |
| 853 |
normal WordPress admin interface. |
| 854 |
|
| 855 |
= 2009.0618 = |
| 856 |
|
| 857 |
* BUGFIX: MYSTERY ERRORS WITH WITH WP_Http_Fsockopen HTTP TRANSPORT |
| 858 |
ELIMINATED: Thanks to a combination of a subtle bug in FeedWordPress, |
| 859 |
and changes to the HTTP transport code in WordPress, a number of users |
| 860 |
encountered an error in which any time they attempted to add a new feed |
| 861 |
through the FeedFinder interface, FeedWordPress would fail and display |
| 862 |
an HTTP request failure diagnostic message. The subtle bug has been |
| 863 |
fixed, and with it, most of these errors should now be eliminated. |
| 864 |
|
| 865 |
Be sure to upgrade your MagpieRSS to the most recent MagpieRSS version |
| 866 |
after you have insalled FeedWordPress 2009.0618, or this bug fix will |
| 867 |
not take effect. |
| 868 |
|
| 869 |
= 2009.0613 = |
| 870 |
|
| 871 |
* INTERFACE/BUGFIX: WORDPRESS 2.8 CATEGORY BOX FIX. Thanks to a subtle |
| 872 |
change in class names between the WordPress 2.7 and 2.8 stylesheets, |
| 873 |
category boxes in the FeedWordPress settings interface tended to overflow |
| 874 |
and have a lot of messy-looking overlapping text under WordPress 2.8. |
| 875 |
This has now been fixed. |
| 876 |
|
| 877 |
* FeedFinder FAILURE DIAGNOSTICS: When FWP's FeedFinder fails to find any |
| 878 |
feeds at a given URL (for example, when you are trying to add a |
| 879 |
subscription through the administrative interface and you run into an |
| 880 |
error message), FeedWordPress now provides more diagnostic information |
| 881 |
for the reasons behind the failure. If that helps you, great; if not, |
| 882 |
it should help me respond more intelligently to your support request.. |
| 883 |
|
| 884 |
= 2009.0612 = |
| 885 |
|
| 886 |
* WORDPRESS 2.8 COMPATIBILITY: FeedWordPress 2009.0612 has been tested for |
| 887 |
compatibility with the recent version 2.8 release of WordPress. |
| 888 |
|
| 889 |
* INTERFACE RESTRUCTURING: In order to avoid settings posts from becoming |
| 890 |
too crowded, and to modularize and better organize the user interface, |
| 891 |
new "Posts" and "Categories & Tags" subpages have been created under the |
| 892 |
"Syndication" menu. "Posts" controls settings for individal syndicated |
| 893 |
posts (such as publication status, comment and ping status, whether or |
| 894 |
not to use the original location of the post as the permalink, whether |
| 895 |
or not to expose posts to formatting filters, and so on). "Categories & |
| 896 |
Tags" controls settings for assigning new syndicated posts to categories |
| 897 |
and tags, such as categories or tags to apply to all syndicated posts, |
| 898 |
and how to handle categories that do not yet exist in the WordPress |
| 899 |
database. These subpages, like the Authors subpage, handle settings for |
| 900 |
the global default level and for individual syndicated feeds. |
| 901 |
|
| 902 |
Corresponding to these new subpages, the old Syndication Settings and |
| 903 |
Feed Settings subpages have been cleaned up and simplified, and now only |
| 904 |
link to the appropriate subpages for options that can be set in the |
| 905 |
Posts, Authors, or Categories & Tags subpages. |
| 906 |
|
| 907 |
* FEATURE: ADD CUSTOM SETTINGS TO EACH SYNDICATED POST: FeedWordPress has |
| 908 |
long had an interface for creating custom settings for each syndicated |
| 909 |
*feed* which could be retrieved in templates using the `get_feed_meta()` |
| 910 |
template function. But it had no feature for adding custom fields to |
| 911 |
each individual syndicated *post*. In response to requests from users, I |
| 912 |
have added the ability to apply custom fields to each individual |
| 913 |
syndicated post, using the new Syndication --> Posts subpage. You can |
| 914 |
set up custom fields to be applied to every syndicated post, or custom |
| 915 |
fields to be applied to syndicated posts from a particular feed. |
| 916 |
|
| 917 |
* FEATURE: MAGPIERSS VERSION CHECK AND UPGRADE: FeedWordPress will attempt |
| 918 |
to determine whether or not you are using the upgraded version of |
| 919 |
MagpieRSS that comes packaged with FeedWordPress. If not, it will throw |
| 920 |
an error on admin pages, and, if you are a site administrator, it will |
| 921 |
give you the option to ignore the error message, or to attempt an |
| 922 |
automatic upgrade (using a native file copy). If the file copy fails, |
| 923 |
FeedWordPress will offer some guidance on how to perform the upgrade |
| 924 |
manually. |
| 925 |
|
| 926 |
* BLANK POSTS PROBLEM NO LONGER OCCURS WITH OLD & BUSTED MAGPIERSS: Due |
| 927 |
to the fact that I relied on a content normalization that occurs in my |
| 928 |
upgraded version of MagpieRSS, but not in the old & busted version of |
| 929 |
MagpieRSS that ships with WordPress, until this version, if you tried to |
| 930 |
syndicate an Atom feed without having performed the (*strongly |
| 931 |
recommended*) MagpieRSS upgrade, all of the posts would come up with |
| 932 |
completely blank contents. That's not because MagpieRSS couldn't read |
| 933 |
the data, but rather because the new Magpie version puts that data in a |
| 934 |
location where the old version doesn't, and I was only looking in that |
| 935 |
newer location. Now it checks for both, meaning that posts will continue |
| 936 |
to display their contents even if you don't upgrade MagpieRSS. (But you |
| 937 |
**really should** upgrade it, anyway.) |
| 938 |
|
| 939 |
* BUGFIX: RELATIVE URI RESOLUTION FOR POST CONTENT RESTORED. Some time |
| 940 |
back, I added support for resolving relative URIs against xml:base on |
| 941 |
feeds that support it to the MagpieRSS upgrade in FeedWordPress. Then I |
| 942 |
took out code that did the same thing from the main FeedWordPress code. |
| 943 |
Of course, the problem is that some people, even though it is clearly |
| 944 |
stupid or evil to do so, still include relative URIs for images or links |
| 945 |
in posts on feed formats that do *not* adequately support xml:base |
| 946 |
(notably, RSS 2.0 feeds). In response to a user request, I have added |
| 947 |
this functionality back in, so that MagpieRSS will resolve any relative |
| 948 |
URIs that it knows how to resolve using xml:base, and then FeedWordPress |
| 949 |
will attempt to resolve any relative URIs that are left over afterwards. |
| 950 |
|
| 951 |
* BUGFIX: INTERFACE OPTION FOR SETTING SYNDICATED POST PUBLICATION STATUS |
| 952 |
ON A FEED-BY-FEED BASIS HAS BEEN RESTORED: Due to a version-checking |
| 953 |
bug, users of WordPress 2.7.x lost an option from the "Edit a syndicated |
| 954 |
feed" interface which allowed them to determine whether newly syndicated |
| 955 |
posts should be published immediately, held as "Pending Review," saved |
| 956 |
as drafts, or saved as private posts. (The option to change this |
| 957 |
setting globally remained in place, but users could no longer set it on |
| 958 |
a feed-by-feed basis.) The version-checking bug has been fixed, and the |
| 959 |
option has been restored. |
| 960 |
|
| 961 |
* BUGFIX: "ARE YOU SURE?" FATAL ERROR ELIMINATED AND SECURITY IMPROVED: |
| 962 |
Under certain circumstances (for example, when users have configured |
| 963 |
their browser or proxy not to send HTTP Referer headers, for privacy or |
| 964 |
other reasons), many features in the FeedWordPress administrative |
| 965 |
interface (such as adding new feeds or changing settings) would hit a |
| 966 |
fatal error, displaying only a cryptic message reading "Are you sure?" |
| 967 |
and a blank page following it. This problem has been eliminated by |
| 968 |
taking advantage of WordPress's nonce functions, which allow the |
| 969 |
security check which ran into this error to work properly even without |
| 970 |
receiving an HTTP Referer header. (N.B.: WordPress's nonce functions |
| 971 |
were first introduced in WordPress 2.0.3. If you're using FeedWordPress |
| 972 |
with an older version of WordPress, there's no fix for this problem: |
| 973 |
you'll just need to turn Referer headers back on. Sorry.) |
| 974 |
|
| 975 |
* BUGFIX: MANUALLY-ALTERED POST STATUS, COMMENT STATUS, AND PING STATUS NO |
| 976 |
LONGER REVERTED BY POST UPDATES: If you manually altered the post status, |
| 977 |
comment status, or ping status of a syndicated post from what it was set |
| 978 |
to when first syndicated -- for example, if you had a feed that was set |
| 979 |
to bring in new posts as "Pending Review," and you then marked some of |
| 980 |
the pending posts as "Published" and others as "Unpublished" -- then |
| 981 |
in previous versions of FeedWordPress, these manual changes to the |
| 982 |
status would be lost -- so that, for example, your Published or Unpublished |
| 983 |
articles would revert to Pending Review -- if the source feed made any |
| 984 |
upates to the item. This could make the Pending Review feature both |
| 985 |
unreliable and also extremely frustrating to work with. The good news is |
| 986 |
that this bug has since been fixed: if you manually update the status |
| 987 |
of a post, it will no longer be reverted if or when the post is updated. |
| 988 |
|
| 989 |
* BUGFIX: OCCASIONAL FATAL ERROR ON UPDATE ELIMINATED: Under certain |
| 990 |
limited conditions (specifically, when both the title and the content of |
| 991 |
a post to be updated are empty), an attempt to update the post would |
| 992 |
result in a fatal error. This has been fixed. |
| 993 |
|
| 994 |
* INTERFACE: "CONFIGURE SETTINGS" CONVENIENCE LINK ADDED TO CONFIRMATION |
| 995 |
MESSAGE WHEN A NEW FEED IS ADDED: When you add a new subscription to |
| 996 |
FeedWordPress, the message box that appears to confirm it now includes a |
| 997 |
handy link to the feed's settings subpage, so that you can quickly set |
| 998 |
up any special settings you may want to set up for the new feed, without |
| 999 |
having to hunt through the list of all your other subscriptions to pick |
| 1000 |
out the new one. |
| 1001 |
|
| 1002 |
* INTERFACE: SIMPLIFYING AND CLARIFYING AUTOMATIC UPDATES SETTINGS. I have |
| 1003 |
removed an interval setting for the cronless automatic updates which has |
| 1004 |
confused many FeedWordPress users. In past versions of FWP, when you |
| 1005 |
turned on automatic updates, you would be presented with a time interval |
| 1006 |
setting which controlled how often FeedWordPress would check for feeds |
| 1007 |
ready to be polled for updates. (That is, it DID NOT control how often |
| 1008 |
feeds *would be polled*; it controlled how often FeedWordPress would |
| 1009 |
*check* for feeds that *had become ready to poll*. The schedule on which |
| 1010 |
feeds became ready for polling was still controlled either by requests |
| 1011 |
encoded in elements within the feed itself, or else according to an |
| 1012 |
internal calculation within FeedWordPress, averaging out to about 1 hour, |
| 1013 |
if the feed did not include any scheduling request elements.) Since many |
| 1014 |
users very often (and understandably) confused the purpose of this |
| 1015 |
setting, and since the setting is for a feature that's actually very |
| 1016 |
unlikely to require any manual control by the user, I have removed the |
| 1017 |
setting; FeedWordPress now simply uses the default value of checking for |
| 1018 |
feeds to poll every 10 minutes. |
| 1019 |
|
| 1020 |
* FEEDFINDER PERFORMANCE IMPROVEMENT: FeedWordPress's FeedFinder class |
| 1021 |
now uses `array_unique()` to make sure that it doesn't waste time |
| 1022 |
repeatedly iterating over and polling the same URI. Props to Camilo |
| 1023 |
(<http://projects.radgeek.com/2008/12/14/feedwordpress-20081214/#comment-20090122160414>). |
| 1024 |
|
| 1025 |
= 2008.1214 = |
| 1026 |
|
| 1027 |
* WORDPRESS 2.7 COMPATIBILITY: FeedWordPress has been tested for |
| 1028 |
compatibility with the newly released WordPress 2.7. WordPress 2.7 has |
| 1029 |
deprecated the Snoopy library for HTTP requests, which caused a fatal |
| 1030 |
error for users who had not installed the MagpieRSS upgrade (or whose |
| 1031 |
installation of the MagpieRSS upgrade was overwritten by a recent update |
| 1032 |
of WordPress). FeedWordPress now handles things gracefully when Snoopy |
| 1033 |
is not immediately available. |
| 1034 |
|
| 1035 |
* INTERFACE SPIFFED UP: Interface elements have been updated so that |
| 1036 |
FeedWordPress's management interface fits in more naturally with the |
| 1037 |
WordPress 2.7 interface (including a new logo and a number of small |
| 1038 |
interface tweaks). |
| 1039 |
|
| 1040 |
* BUG WITH TAGS FOR SYNDICATED ARTICLES FIXED: Several users encountered a |
| 1041 |
bug with the option to add tags to all syndicated posts under |
| 1042 |
Syndication --> Settings -- if you told FeedWordPress to add more than |
| 1043 |
one tag to all syndicated posts, instead of doing so correctly, it would |
| 1044 |
add a *single* tag instead, whose name was composed of the names of all |
| 1045 |
the tags you asked it to add. This bug was the result of nothing more |
| 1046 |
dignified than a typographical error on my part. It has now been fixed. |
| 1047 |
|
| 1048 |
* MORE INFORMATION AVAILABLE WHEN FEEDWORDPRESS CAN'T FIND A FEED: When |
| 1049 |
you enter a URL for a new syndication source, FeedWordPress uses a |
| 1050 |
simple feed-finding algorithm (originally based on Mark Pilgrim's |
| 1051 |
Universal Feed Finder) to try to determine whether the URL is the URL |
| 1052 |
for a feed, or, if the URL points to an ordinary website rather than to |
| 1053 |
a feed, whether there is a feed for that website. All well and good, but |
| 1054 |
if FeedWordPress failed to find a feed, for whatever reason, it would |
| 1055 |
typically return nothing more than a nasty little note to the effect of |
| 1056 |
"no feed found," without any explanation of what went wrong. |
| 1057 |
FeedWordPress now keeps track of error conditions from the HTTP |
| 1058 |
requests that it uses in the course of looking for the feed, and so may |
| 1059 |
be able to give you a bit more information about the nature of the |
| 1060 |
problem if something goes wrong. |
| 1061 |
|
| 1062 |
|
| 1063 |
= 2008.1105 = |
| 1064 |
|
| 1065 |
* INTERFACE RESTRUCTURING AND SYNDICATION --> AUTHORS PAGE: As a first |
| 1066 |
step towards modularizing and better organizing the user interface, a |
| 1067 |
new "Authors" subpage has been created under the Syndication menu, which |
| 1068 |
controls settings for syndicated authors, both at the global default |
| 1069 |
level and at level of individual syndicated feeds. |
| 1070 |
|
| 1071 |
* BUG RELATED TO THE ATTRIBUTION OF POSTS TO THE WRONG AUTHOR FIXED: Some |
| 1072 |
users encountered an issue in which posts by different authors on |
| 1073 |
different blogs -- especially blogs generated by Blogger -- were |
| 1074 |
mistakenly attributed to a single author. The problem was caused by the |
| 1075 |
way in which FeedWordPress matches syndicated authors to user accounts |
| 1076 |
in the WordPress database: normally, if two feeds each list an author |
| 1077 |
with the same e-mail address, they are counted as being the same person. |
| 1078 |
Normally this works well, but it creates an issue in cases where |
| 1079 |
blogging software assigns a single anonymous e-mail address to users who |
| 1080 |
do not want their real e-mail address published. This is, for example, |
| 1081 |
what Blogger does (by giving all users a default e-mail address of |
| 1082 |
<noreply@blogger.com> if they don't want their own e-mail address |
| 1083 |
listed). FeedWordPress now allows the user to correct for this problem |
| 1084 |
with a couple of new settings under **Syndication --> Authors**, which |
| 1085 |
allow users to turn off e-mail based author matching for particular |
| 1086 |
addresses, or, if desired, to turn it off entirely. By default, e-mail |
| 1087 |
based author matching is still turned on, but disabled for a list of |
| 1088 |
known generic e-mail addresses. Right now, the "list" consists entirely |
| 1089 |
of <noreply@blogger.com>; if you know other addresses that should be |
| 1090 |
added, please [contact me](http://radgeek.com/contact) to let me know. |
| 1091 |
|
| 1092 |
Please note that if you have already encountered this issue on your |
| 1093 |
blog, upgrading FeedWordPress will prevent it from re-occurring in the |
| 1094 |
future, but you still need to do two other things to fix the existing |
| 1095 |
problem on your blog. |
| 1096 |
|
| 1097 |
First, for each feed where posts have been mis-attributed, you need to |
| 1098 |
change the existing author mapping rules to re-map a a syndicated |
| 1099 |
author's name to the proper target account. Go to **Syndication --> |
| 1100 |
Authors**, select the feed you want to change from the drop-down list, |
| 1101 |
and then change the settings under the "Syndicated Authors" section. |
| 1102 |
(You will probably need to select "will be assigned to a new user..." to |
| 1103 |
create a new user account with the appropriate name.) |
| 1104 |
|
| 1105 |
Second, for each feed where posts have been mis-attributed, you need to |
| 1106 |
re-assign already-syndicated posts that were mis-attributed to the |
| 1107 |
correct author. You can do that from **Syndication --> Authors** by |
| 1108 |
using the author re-assignment feature, described below. |
| 1109 |
|
| 1110 |
* AUTHOR RE-ASSIGNMENT FOR A PARTICULAR FEED: The author settings page |
| 1111 |
for each syndicated feed, under **Syndication --> Authors**, now |
| 1112 |
includes an section titled "Fixing mis-matched authors," which provides |
| 1113 |
an interface for re-assigning or deleting all posts attributed to a |
| 1114 |
particular author on a particular feed. |
| 1115 |
|
| 1116 |
* SUPPORT FOR `<atom:source>` ELEMENT IN SYNDICATED FEEDS: Some feeds |
| 1117 |
(for example, those produced by FeedWordPress) aggregate content from |
| 1118 |
several different sources, and include information about the original |
| 1119 |
source of the post in an `<atom:source>` element. A new setting under |
| 1120 |
**Syndication --> Options** allows you to control what FeedWordPress |
| 1121 |
will report as the source of posts syndicated from aggregator feeds in |
| 1122 |
your templates and feeds: you can have FeedWordPress report that the |
| 1123 |
source of a post is the aggregator feed itself, or you can have it |
| 1124 |
report that the source of a post is the original source that the |
| 1125 |
aggregator originally syndicated the post from. |
| 1126 |
|
| 1127 |
By default, FeedWordPress will report the aggregator, not the original |
| 1128 |
source, as the source of a syndicated item. |
| 1129 |
|
| 1130 |
* LOAD BALANCING AND TIME LIMITING FEATURES FOR UPDATES: Some users have |
| 1131 |
encountered issues due to running up against PHP execution time limits |
| 1132 |
during the process of updating large syndicated feeds, or a very large |
| 1133 |
set of syndicated feeds. FeedWordPress now has a feature that allows you |
| 1134 |
to limit the total amount of time spent updating a feed, through the |
| 1135 |
"Time limit on updates" setting under **Syndication --> Options**. By |
| 1136 |
turning on this setting and adjusting the time limit to a low enough |
| 1137 |
figure to avoid your PHP installation's time-out setting. (PHP execution |
| 1138 |
time limits are usually in the vicinity of 30 seconds, so an update |
| 1139 |
time limit of 25 seconds or so should provide plenty of time for updates |
| 1140 |
while allowing a cushion of time for other, non-update-related functions |
| 1141 |
to do their work.) |
| 1142 |
|
| 1143 |
If feed updates are interrupted by the time limit, FeedWordPress uses |
| 1144 |
some simple load balancing features to make sure that updates to other |
| 1145 |
feeds will not be blocked by the time-hogging feed, and will also make |
| 1146 |
sure that when the interrupted update is resumed, FeedWordPress will |
| 1147 |
skip ahead to resume processing items at the point at which it was |
| 1148 |
interrupted last time, so that posts further down in the feed will |
| 1149 |
eventually get processed, and not get blocked by the amount of time it |
| 1150 |
takes to process the items higher up in the feed. |
| 1151 |
|
| 1152 |
* `guid` INDEX CREATION BUTTON: FeedWordPress frequently issues queries on |
| 1153 |
the `guid` column of the WordPress posts database (since it uses post |
| 1154 |
guid URIs to keep track of which posts it has syndicated). In very large |
| 1155 |
FeedWordPress installations, you can often significantly improve |
| 1156 |
performance by creating a database index on the `guid` column, but |
| 1157 |
normally you would need to poke around with MySQL or a tool like |
| 1158 |
phpMyAdmin to do this. FeedWordPress can now save you the trouble: to |
| 1159 |
create an index on the `guid` column, just go to |
| 1160 |
**Syndication --> Options**, and mash the button at the bottom of the |
| 1161 |
"Back End" section. |
| 1162 |
|
| 1163 |
= 2008.1101 = |
| 1164 |
|
| 1165 |
* INTERFACE BUG THAT PREVENTED ADDING NEW SITES FIXED: The UI reforms in |
| 1166 |
FWP 2008.1030 unintentionally introduced a bug that prevents clean |
| 1167 |
installations of FeedWordPress from providing an input box for adding |
| 1168 |
new feeds to the list of syndicated feeds. This bug has been fixed. |
| 1169 |
|
| 1170 |
= 2008.1030 = |
| 1171 |
|
| 1172 |
* WORDPRESS 2.6 COMPATIBILITY: FeedWordPress should now be compatible with |
| 1173 |
WordPress 2.6, and should work more or less seamlessly with the new post |
| 1174 |
revision system. A bug which caused multiple new revisions to be created |
| 1175 |
for posts on certain feeds, regardless of whether or not the item had |
| 1176 |
been updated, has been fixed. |
| 1177 |
|
| 1178 |
* INTERFACE IMPROVEMENTS: The user interface has been substantially |
| 1179 |
restyled to fit in better with the visual style of WordPress 2.5 and |
| 1180 |
2.6. |
| 1181 |
|
| 1182 |
* YOUTUBE BUG FIXED: POSTS SYNDICATED THROUGH AN AUTOMATIC UPDATE ARE NO |
| 1183 |
LONGER STRIPPED OF `<OBJECT>` TAGS AND CERTAIN OTHER HTML ELEMENTS: Due |
| 1184 |
to the way that some versions of WordPress process posts that are |
| 1185 |
inserted into the database when no user is logged in, many users |
| 1186 |
experienced an issue where YouTube videos and other content using the |
| 1187 |
HTML `<object>` tag would be stripped out of posts that were syndicated |
| 1188 |
during an automatic update. (Posts that were syndicated through manual |
| 1189 |
updates from within the WordPress Dashboard were not affected, because |
| 1190 |
the issue does not arise when an update is executed under a logged-in |
| 1191 |
administrator's credentials.) This bug has now been fixed; YouTube |
| 1192 |
videos and other content using `<object>` tags should now appear |
| 1193 |
properly in syndicated posts, regardless of the way in which the post |
| 1194 |
was syndicated. |
| 1195 |
|
| 1196 |
* AJAX BUGS FIXED: Bugs which blocked the normal operation of WordPress |
| 1197 |
2.5's AJAX interface elements when FeedWordPress was activated have been |
| 1198 |
fixed. |
| 1199 |
|
| 1200 |
* TAG SUPPORT: A couple of features have been introduced to take advantage |
| 1201 |
of the tagging features in WordPress 2.3.x, 2.5.x, and 2.6.x. Now, when |
| 1202 |
unfamiliar categories are encountered for posts on a feed, you can |
| 1203 |
choose for FeedWordPress (1) to drop the category; (2) to drop the |
| 1204 |
category and to filter out any post that does not match at least one |
| 1205 |
familiar category; (3) to create a new category with that name, or, |
| 1206 |
now, you can also have FeedWordPress (4) create a new *tag* with that |
| 1207 |
name. This option can be set site-wide under Syndication --> Options, |
| 1208 |
or it can be set on a feed-by-feed basis in a feed's Edit screen. |
| 1209 |
|
| 1210 |
In addition, you can now set particular tags to apply to all incoming |
| 1211 |
syndicated posts, under Syndication --> Options, or you can set tags |
| 1212 |
to apply to all incoming syndicated posts from a particular feed in that |
| 1213 |
feed's Edit screen. |
| 1214 |
|
| 1215 |
* FORMATTING FILTERS: There is a new option available under Syndication -> |
| 1216 |
Options which allows users to choose whether or not to expose syndicated |
| 1217 |
posts to being altered by formatting filters. By default, FeedWordPress |
| 1218 |
has always protected syndicated posts (which are already in display-ready |
| 1219 |
HTML when they are syndicated) from being reformatted by formatting |
| 1220 |
filters. However, this approach means that certain plugins which depend |
| 1221 |
on formatting filters (for example, to add "Share This" bars or relevant |
| 1222 |
links to the end of a post) are blocked from working on any syndicated |
| 1223 |
posts. If you want to use one of these plugins together with |
| 1224 |
FeedWordPress, you can now do so by changing the "Formatting Filters" |
| 1225 |
setting from "Protect" to "Expose." |
| 1226 |
|
| 1227 |
* `<atom:source>` ELEMENTS NOW INCLUDED IN ATOM FEED: Atom 1.0 provides |
| 1228 |
a standard method for aggregators to indicate information about the original source of |
| 1229 |
a syndicated post, using the `<atom:source>` element. FeedWordPress now |
| 1230 |
introduces standard `<atom:source>` elements including the title, homepage, and |
| 1231 |
feed URI of the source from which a syndicated post was syndicated. Cf. |
| 1232 |
<http://www.atomenabled.org/developers/syndication/atom-format-spec.php#element.source> |
| 1233 |
|
| 1234 |
* MODULARIZATION OF CODE: The code for different elements of FeedWordPress |
| 1235 |
has been broken out into several modules for easier inspection, |
| 1236 |
documentation, and maintenance of the code. |
| 1237 |
|
| 1238 |
* VERSIONING SCHEME CHANGED: FeedWordPress's feature set has proven stable |
| 1239 |
enough that it can now be removed from beta status; a good thing, since |
| 1240 |
I was very quickly running out of version numbers to use. New releases |
| 1241 |
of FeedWordPress will have version numbers based on the date of their |
| 1242 |
release. |
| 1243 |
|
| 1244 |
= 0.993 = |
| 1245 |
|
| 1246 |
* WORDPRESS 2.5.1 COMPATIBILITY: FeedWordPress should now be compatible |
| 1247 |
with WordPress 2.5.1. |
| 1248 |
|
| 1249 |
* WORDPRESS 2.5 INTERFACE IMPROVEMENTS: FeedWordPress's Dashboard |
| 1250 |
interface has undergone several cosmetic changes that should help it |
| 1251 |
integrate better with the WordPress Dashboard interface in WordPress |
| 1252 |
version 2.5.x. |
| 1253 |
|
| 1254 |
* SYNDICATED POSTS CAN BE MARKED AS "PENDING REVIEW": WordPress 2.3 users |
| 1255 |
can now take advantage of WordPress's new "Pending Review" features for |
| 1256 |
incoming syndicated posts. Posts marked as "Pending Review" are not |
| 1257 |
published immediately, but are marked as ready to be reviewed by an |
| 1258 |
Administrator or Editor, who can then choose to publish the post or |
| 1259 |
hold it back. If you want to review syndicated posts from a particular |
| 1260 |
feed, or from all feeds, before they are posted, then use |
| 1261 |
Syndication --> Syndicated Sites --> Edit or Syndication --> Options to |
| 1262 |
change the settings for handling new posts. |
| 1263 |
|
| 1264 |
* AWARE OF NEW URI FOR del.icio.us FEEDS: Previous releases of |
| 1265 |
FeedWordPress already automatically split del.icio.us tags up |
| 1266 |
appropriately appropriately when generating categories. (del.icio.us |
| 1267 |
feeds smoosh all the tags into a single `<dc:subject>` element, |
| 1268 |
separated by spaces; FeedWordPress un-smooshes them into multiple |
| 1269 |
categories by separating them at whitespace.) Unfortunately, del.icio.us |
| 1270 |
recently broke the existing behavior by changing host names for their |
| 1271 |
feeds from del.icio.us to feeds.delicious.com. Version 0.993 accounts |
| 1272 |
for the new host name and un-breaks the tag splitting. |
| 1273 |
|
| 1274 |
= 0.992 = |
| 1275 |
|
| 1276 |
* AUTHOR RE-MAPPING: FeedWordPress now offers considerable control over |
| 1277 |
how author names on a feed are translated into usernames within the |
| 1278 |
WordPress database. When a post by an unrecognized author comes in, |
| 1279 |
Administrators can now specify any username as the default username to |
| 1280 |
assign the post to by setting the option in Syndication --> Options |
| 1281 |
(formerly FeedWordPress only allowed you to assign such posts to user |
| 1282 |
#1, the site administrator). Administrators can also create re-mapping |
| 1283 |
rules for particular feeds (under Syndication --> Syndicated Sites --> |
| 1284 |
Edit), so that (for example) any posts attributed to "Administrator" |
| 1285 |
on the feed <http://praxeology.net/blog/feed/> will be assigned to |
| 1286 |
a user named "Roderick T. Long," rather than a user named |
| 1287 |
"Administrator." These settings also allow administrators to filter out |
| 1288 |
posts by particular users, and to control what will happen when |
| 1289 |
FeedWordPress encounters a post by an unrecognized user on that |
| 1290 |
particular feed. |
| 1291 |
|
| 1292 |
* BUG RELATED TO URIS CONTAINING AMPERSAND CHARACTERS FIXED: A bug in |
| 1293 |
WordPress 2.x's handling of URIs in Blogroll links created problems for |
| 1294 |
updating any feeds whose URIs included an ampersand character, such as |
| 1295 |
Google News RSS feeds and other feeds that have multiple parameters |
| 1296 |
passed through HTTP GET. If you experienced this bug, the most likely |
| 1297 |
effect was that FeedWordPress simply would not import new posts from a |
| 1298 |
feed when instructred to do so, returning a "0 new posts" response. In |
| 1299 |
other cases, it might lead to unpredictable results from feed updates, |
| 1300 |
such as importing posts which were not contained in the feed being |
| 1301 |
syndicated, but which did appear elsewhere on the same website. This bug |
| 1302 |
has, hopefully, been resolved, by correcting for the bug in WordPress. |
| 1303 |
|
| 1304 |
= 0.991 = |
| 1305 |
|
| 1306 |
* WORDPRESS MU COMPATIBILITY: FeedWordPress should now be compatible with |
| 1307 |
recent releases of WordPress MU. Once FeedWordPress is made available |
| 1308 |
as a plugin, each individual blog can choose to activate FeedWordPress |
| 1309 |
and syndicate content from its own set of contributors. |
| 1310 |
|
| 1311 |
* DISPLAY OF MAGPIE WARNINGS: A number of MagpieRSS warnings or error |
| 1312 |
messages that were displayed when performing an automatic update are |
| 1313 |
no longer displayed, unless debugging parameters have been explicitly |
| 1314 |
enabled. |
| 1315 |
|
| 1316 |
* BUG RELATED TO INTERNATIONAL CHARACTERS IN AUTHOR NAMES FIXED: Due to a |
| 1317 |
subtle incompatability between the way that FeedWordPress generated new |
| 1318 |
user information, and the way that WordPress 2.0 and later added new |
| 1319 |
authors to the database, FeedWordPress might end up creating duplicate |
| 1320 |
authors, or throwing a critical error message, when it encountered |
| 1321 |
authors whose names included international characters. This |
| 1322 |
incompatability has now been fixed; hopefully, authors with |
| 1323 |
international characters in their names should now be handled properly. |
| 1324 |
|
| 1325 |
* `<media:content>` BUG IN MAGPIERSS FIXED: A bug in MagpieRSS's handling |
| 1326 |
of namespaced elements has been fixed. Among other things, this bug |
| 1327 |
caused items containing a Yahoo MediaRSS `<media:content>` element (such |
| 1328 |
as many of the feeds produced by wordpress.com) to be represented |
| 1329 |
incorrectly, with only a capital "A" where the content of the post |
| 1330 |
should have been. Feeds containing `<media:content>` elements should now |
| 1331 |
be syndicated correctly. |
| 1332 |
|
| 1333 |
* update_feedwordpress PARAMETER: You can now use an HTTP GET parameter |
| 1334 |
(`update_feedwordpress=1`) to request that FeedWordPress poll its feeds |
| 1335 |
for updates. When used together with a crontab or other means of |
| 1336 |
scheduling tasks, this means that you can keep your blog automatically |
| 1337 |
updated on a regular schedule, even if you do not choose to use the |
| 1338 |
cron-less automatic updates option. |
| 1339 |
|
| 1340 |
* Some minor interface-related bugs were also fixed. |
| 1341 |
|
| 1342 |
|
| 1343 |
= 0.99 = |
| 1344 |
|
| 1345 |
Version 0.99 adds several significant new features, fixes some bugs, and |
| 1346 |
provides compatability with WordPress 2.2.x and 2.3.x. |
| 1347 |
|
| 1348 |
* WORDPRESS 2.2 AND 2.3 COMPATIBILITY: FeedWordPress should now be |
| 1349 |
compatible with WordPress version 2.2 and the upcoming WordPress |
| 1350 |
version 2.3. In particular, it has been tested extensively against |
| 1351 |
WordPress 2.2.3 and WordPress 2.3 Release Candidate 1. |
| 1352 |
|
| 1353 |
* AUTOMATIC UPDATES WITHOUT CRON: FeedWordPress now allows you to |
| 1354 |
automatically schedule checks for new posts without using external task |
| 1355 |
scheduling tools such as cron. In order to enable automatic updates, go |
| 1356 |
to **Syndication --> Options** and set "Check for new posts" to |
| 1357 |
"automatically." For details, see "Automatic Feed Updates" in |
| 1358 |
README.text. |
| 1359 |
|
| 1360 |
An important side-effect of the changes to the update system is that if |
| 1361 |
you were previously using the cron job and the `update-feeds.php` script |
| 1362 |
to schedule updates, you need to change your cron set-up. The old |
| 1363 |
`update-feeds.php` script no longer exists. Instead, if you wish to use |
| 1364 |
a cron job to guarantee updates on a particular schedule, you should |
| 1365 |
have the cron job fetch the front page of your blog (for example, by |
| 1366 |
using `curl http://www.zyx.com/blog/ > /dev/null`) instead of activating |
| 1367 |
the `update-feeds.php` script. If automatic updates have been enabled, |
| 1368 |
fetching the front page will automatically trigger the update process. |
| 1369 |
|
| 1370 |
* INTERFACE REORGANIZATION: All FeedWordPress functions are now located |
| 1371 |
under a top-level "Syndication" menu in the WordPress Dashboard. To |
| 1372 |
manage the list of syndicated sites, manually check for new posts on |
| 1373 |
one or more feeds, or syndicate a new site, you should use the main page |
| 1374 |
under **Syndication**. To change global settings for FeedWordPress, |
| 1375 |
you should use **Syndication --> Options**. |
| 1376 |
|
| 1377 |
* FILE STRUCTURE REORGANIZATION: Due to a combination of changing styles |
| 1378 |
for FeedWordPress plugins and lingering bugs in the FeedWordPress admin |
| 1379 |
menu code, the code for FeedWordPress is now contained in two different |
| 1380 |
PHP files, which should be installed together in a subdirectory of your |
| 1381 |
plugins directory named `feedwordpress`. (See README.text for |
| 1382 |
installation and upgrade instructions relating to the change.) |
| 1383 |
|
| 1384 |
* MULTIPLE CATEGORIES SETTING: Some feeds use non-standard methods to |
| 1385 |
indicate multiple categories within a single category element. (The most |
| 1386 |
popular site to do this is del.icio.us, which separates tags with a |
| 1387 |
space.) FeedWordPress now allows you to set an optional setting, for any |
| 1388 |
feed which does this, indicating the character or characters used to |
| 1389 |
divide multiple categories, using a Perl-compatible regular expression. |
| 1390 |
(In the case of del.icio.us feeds, FeedWordPress will automatically use |
| 1391 |
\s for the pattern without your having to do any further configuration.) |
| 1392 |
To turn this setting on, simply use the "Edit" link for the feed that |
| 1393 |
you want to turn it on for. |
| 1394 |
|
| 1395 |
* REGULAR EXPRESSION BUG FIXED: Eliminated a minor bug in the regular |
| 1396 |
expressions for e-mail addresses (used in parsing RSS `author` |
| 1397 |
elements), which could produce unsightly error messages for some users |
| 1398 |
parsing RSS 2.0 feeds. |
| 1399 |
|
| 1400 |
* DATE / UPDATE BUG FIXED: A bug in date handling was eliminated that may |
| 1401 |
have caused problems if any of (1) WordPress, or (2) PHP, or (3) your |
| 1402 |
web server, or (4) your MySQL server, has been set to use a different |
| 1403 |
time zone from the one that any of the others is set to use. If |
| 1404 |
FeedWordPress has not been properly updating updated posts, or has been |
| 1405 |
updating posts when there shouldn't be any changes for the update, this |
| 1406 |
release may solve that problem. |
| 1407 |
|
| 1408 |
* GOOGLE READER BUGS FIXED: A couple of bugs that made it difficult for |
| 1409 |
FeedWordPress to interact with Google Reader public feeds have been |
| 1410 |
fixed. Firstly, if you encountered an error message reading "There was a |
| 1411 |
problem adding the newsfeed. [SQL: ]" when you tried to add the feed, |
| 1412 |
the cause of this error has been fixed. Secondly, if you succeeded in |
| 1413 |
getting FeedWordPress to check a Google Reader feed, only to find that |
| 1414 |
the title of posts had junk squashed on to the end of them, that bug |
| 1415 |
has been fixed too. To fix this bug, you must install the newest version |
| 1416 |
of the optional MagpieRSS upgrade. |
| 1417 |
|
| 1418 |
* FILTER PARAMETERS: Due to an old, old bug in WordPress 1.5.0 (which was |
| 1419 |
what was available back when I first wrote the filter interface), |
| 1420 |
FeedWordPress has traditionally only passed one parameter to |
| 1421 |
syndicated_item and syndicated_post filters functions -- an array |
| 1422 |
containing either the Magpie representation of a syndicated item from |
| 1423 |
the feed, or the database representation of a post about to be inserted |
| 1424 |
into the WordPress database. If you needed information about the feed |
| 1425 |
that the item came from, this was accessible only through a pair of |
| 1426 |
global variables, $fwp_channel and $fwp_feedmeta. |
| 1427 |
|
| 1428 |
Since it's been a pretty long time since WordPress 1.5.0 was in |
| 1429 |
widespread usage, I have gone ahead and added an optional second |
| 1430 |
parameter to the invocation of the syndicated_item and syndicated_post |
| 1431 |
filters. If you have written a filter for FeedWordPress that uses either |
| 1432 |
of these hooks, you can now register that filter to accept 2 parameters. |
| 1433 |
If you do so, the second parameter will be a SyndicatedPost object, |
| 1434 |
which, among other things, allows you to access information about the |
| 1435 |
feed from which an item is syndicated using the $post->feed and the |
| 1436 |
$post->feedmeta elements (where $post is the name of the second |
| 1437 |
parameter). |
| 1438 |
|
| 1439 |
NOTE THAT THE OLD GLOBAL VARIABLES ARE STILL AVAILABLE, for the time |
| 1440 |
being at least, so existing filters will not break with the upgrade. |
| 1441 |
They should be considered deprecated, however, and may be eliminated in |
| 1442 |
the future. |
| 1443 |
|
| 1444 |
* FILTER CHANGE / BUGFIX: the array that is passed as the first argument |
| 1445 |
syndicated_post filters no longer is no longer backslash-escaped for |
| 1446 |
MySQL when filters are called. This was originally a bug, or an |
| 1447 |
oversight; the contents of the array should only be escaped for the |
| 1448 |
database *after* they have gone through all filters. IF YOU HAVE WRITTEN |
| 1449 |
ANY syndicated_post FILTERS THAT PRESUME THE OLD BEHAVIOR OF PASSING IN |
| 1450 |
STRINGS THAT ARE ALREADY BACKSLASH-ESCAPED, UPDATE YOUR FILTERS |
| 1451 |
ACCORDINGLY. |
| 1452 |
|
| 1453 |
* OTHER MINOR BUGFIXES AND INTERNAL CHANGES: The internal architecture of |
| 1454 |
FeedWordPress has been significantly changed to make the code more |
| 1455 |
modular and clean; hopefully this should help reduce the number of |
| 1456 |
compatibility updates that are needed, and make them easier and quicker |
| 1457 |
when they are needed. |
| 1458 |
|
| 1459 |
= 0.981 = |
| 1460 |
|
| 1461 |
Version 0.981 is a narrowly targeted bugfix and compatibility release, whose |
| 1462 |
main purpose is to resolve a major outstanding problem: the incompatibility |
| 1463 |
between version 0.98 of WordPress and the recently released WordPress 2.1. |
| 1464 |
|
| 1465 |
* WORDPRESS 2.1 COMPATIBILITY: FeedWordPress is now compatible with |
| 1466 |
WordPress 2.1, as well as retaining its existing support for WordPress |
| 1467 |
2.0 and 1.5. Incompatibilities that resulted in database warnings, fatal |
| 1468 |
errors, and which prevented FeedWordPress from syndicating new posts, |
| 1469 |
have been eliminated. |
| 1470 |
|
| 1471 |
* RSS-FUNCTIONS.PHP RENAMED TO RSS.PHP: if you use the upgraded MagpieRSS |
| 1472 |
replacement that's included with FeedWordPress, be sure to note that |
| 1473 |
there are now *two* files to upload from the `OPTIONAL/wp-includes` |
| 1474 |
subdirectory in order to carry out the upgrade: rss-functions.php and |
| 1475 |
rss.php. **It is necessary to upload both files**, due to a change in |
| 1476 |
the file naming scheme in WordPress 2.1, and it is necessary to do so |
| 1477 |
whether you are using WordPress 2.1 or not. If you only upload the |
| 1478 |
`rss-functions.php` file as in previous installations you will not have |
| 1479 |
a working copy of MagpieRSS; the rss.php file contains the actual code. |
| 1480 |
|
| 1481 |
* DATE BUG AFFECTING SOME PHP INSTALLATIONS RESOLVED: due to a subtle bug |
| 1482 |
in parse_w3cdtf(), some installations of PHP encountered problems with |
| 1483 |
FeedWordPress's attempt to date posts, which would cause some new posts |
| 1484 |
on Atom feeds to be dated as if they had apppeared in 1969 or 1970 |
| 1485 |
(thus, effectively, never appearing on front page at all). This bug in |
| 1486 |
the date handling should now be fixed. |
| 1487 |
|
| 1488 |
* PHP <?=...?> SHORT FORM ELIMINATED: some installations of PHP do not |
| 1489 |
allow the <?=...?> short form for printing PHP values, which was used |
| 1490 |
extensively in the FeedWordPress interface code. Since this could cause |
| 1491 |
fatal errors for users with the wrong installation of PHP, the short |
| 1492 |
form has been replaced with full PHP echo statements, and is no longer |
| 1493 |
used in FeedWordPress. |
| 1494 |
|
| 1495 |
* BETTER USER INTERFACE INTEGRATION WITH WORDPRESS 2.x: Some minor changes |
| 1496 |
have been made to help the FeedWordPress interface pages blend in better |
| 1497 |
with the user interface when running under WordPress 2.x. |
| 1498 |
|
| 1499 |
* GLOBAL CATEGORIES BUG RESOLVED: a bug that prevented some users from |
| 1500 |
setting one or more categories to apply to syndicated posts from all |
| 1501 |
feeds (using the checkbox interface under Options --> Syndication) has |
| 1502 |
been resolved. |
| 1503 |
|
| 1504 |
= 0.98 = |
| 1505 |
|
| 1506 |
* WORDPRESS 2.0 COMPATIBILITY: This is a narrowly-targeted release to |
| 1507 |
solve a major outstanding problem. FeedWordPress is now compatible with |
| 1508 |
both WordPress 1.5 and WordPress 2.0. Incompatibilities that caused |
| 1509 |
fatal SQL errors, and a more subtle bug with off-kilter counts of posts |
| 1510 |
under a given category, have been resolved. FeedWordPress tests for |
| 1511 |
database schema using the global $wp_db_version variable (if null, then |
| 1512 |
we presume that we're dealing with WordPress 1.5). |
| 1513 |
|
| 1514 |
NOTE: I have **not** fully tested FeedWordPress with WordPress 2.0. |
| 1515 |
Further testing may reveal more bugs. However, you should now be able |
| 1516 |
to get at least basic FeedWordPress functionality up and running. |
| 1517 |
|
| 1518 |
* AUTHOR MATCHING: FeedWordPress tests several fields to see if it can |
| 1519 |
identify the author of the post as a user already in the WordPress user |
| 1520 |
database. In previous versions, it tested the user login, the nickname, |
| 1521 |
and tested for "aliases" listed in the Profile (see documentation). FWP |
| 1522 |
now also matches authors on the basis of e-mail address (*if* an e-mail |
| 1523 |
address is present). This is particularly helpful for formats such as |
| 1524 |
RSS 2.0, in which authors are primarily identified by e-mail addresses. |
| 1525 |
|
| 1526 |
= 0.97 = |
| 1527 |
|
| 1528 |
* INSTALLATION PROCEDURE: Some of the changes between 0.96 and 0.97 |
| 1529 |
require upgrades to the meta-data stored by FeedWordPress to work |
| 1530 |
properly. Thus, if you are upgrading from 0.96 or earlier to 0.97, most |
| 1531 |
FeedWordPress operations (including updates and template functions) |
| 1532 |
WILL BE DISABLED until you run the upgrade procedure. Fortunately, |
| 1533 |
running the upgrade procedure is easy: just go to either Options --> |
| 1534 |
Syndication or Links --> Syndicated in the WordPress Dashboard and press |
| 1535 |
the button. |
| 1536 |
|
| 1537 |
* FEED FORMAT SUPPORT: Support has been added for the Atom 1.0 IETF |
| 1538 |
standard. Several other elements are also newly supported |
| 1539 |
(dcterms:created, dcterms:issued, dcterms:modified, dc:identifier, |
| 1540 |
proper support for the RSS 2.0 guid element, the RSS 2.0 author element, |
| 1541 |
the use of Atom author or Dublin Core dc:creator constructs at the feed |
| 1542 |
level to identify the author of individual items, etc.) |
| 1543 |
|
| 1544 |
N.B.: full support of several Atom 1.0 features, such as categories |
| 1545 |
and enclosures, requires you to install the optional rss-functions.php |
| 1546 |
upgrade in your wp-includes directory. |
| 1547 |
|
| 1548 |
* BUG FIX: Running `update-feeds.php` from command line or crontab |
| 1549 |
returned "I don't syndicate..." errors. It turns out that WordPress |
| 1550 |
sometimes tramples on the internal PHP superglobals that I depended on |
| 1551 |
to determine whether or not the script was being invoked from the |
| 1552 |
command line. This has been fixed (the variables are now checked |
| 1553 |
*before* WordPress can trample them). Note that `update-feeds.php` has |
| 1554 |
been thoroughly overhauled anyway; see below for details. |
| 1555 |
|
| 1556 |
* BUG FIX: Duplicate categories or author names. Fixed two bugs that could |
| 1557 |
create duplicate author and/or category names when the name contained |
| 1558 |
either (a) certain international characters (causing a mismatch between |
| 1559 |
MySQL and PHP's handling of lowercasing text), or (b) characters that |
| 1560 |
have a special meaning in regular expressions (causing MySQL errors when |
| 1561 |
looking for the author or category due to regexp syntax errors). These |
| 1562 |
should now be fixed thanks to careful escaping of names that go into |
| 1563 |
regular expressions and careful matching of lowercasing functions |
| 1564 |
(comparing results from PHP only to other results from PHP, and results |
| 1565 |
from MySQL only to other results from MySQL). |
| 1566 |
|
| 1567 |
* BUG FIX: Items dated December 31, 1969 should appear less often. The |
| 1568 |
function for parsing W3C date-time format dates that ships with |
| 1569 |
MagpieRSS can only correctly parse fully-specified dates with a |
| 1570 |
fully-specified time, but valid W3C date-time format dates may omit the |
| 1571 |
time, the day of the month, or even the month. Some feeds in the wild |
| 1572 |
date their items with coarse-grained dates, so the optional |
| 1573 |
`rss-functions.php` upgrade now includes a more flexible parse_w3cdtf() |
| 1574 |
function that will work with both coarse-grained and fully-specified |
| 1575 |
dates. (If parts of the date or the time are omitted, they are filled in |
| 1576 |
with values based on the current time, so '2005-09-10' will be dated to |
| 1577 |
the current time on that day; '2004' will be dated to this day and time |
| 1578 |
one year ago. |
| 1579 |
|
| 1580 |
N.B.: This fix is only available in the optional `rss-functions.php` |
| 1581 |
upgrade. |
| 1582 |
|
| 1583 |
* BUG FIX: Evil use of HTTP GET has been undone. The WordPress interface |
| 1584 |
is riddled with inappropriate (non-idempotent) uses of HTTP GET queries |
| 1585 |
(ordinary links that make the server do something with significant |
| 1586 |
side-effects, such as deleting a post or a link from the database). |
| 1587 |
FeedWordPress did some of this too, especially in places where it aped |
| 1588 |
the WordPress interface (e.g. the "Delete" links in Links --> |
| 1589 |
Syndicated). That's bad business, though. I've changed the interface so |
| 1590 |
that all the examples of improper side-effects that I can find now |
| 1591 |
require an HTTP POST to take effect. I think I got pretty much |
| 1592 |
everything; if there's anything that I missed, let me know. |
| 1593 |
|
| 1594 |
Further reading: [Sam Ruby 2005-05-06: This Stuff Matters](http://www.intertwingly.net/blog/2005/05/06/This-Stuff-Matters) |
| 1595 |
|
| 1596 |
* BUG FIX: Categories applied by `cats` setting should no longer prevent |
| 1597 |
category-based filtering from working. In FeedWordPress, you can (1) |
| 1598 |
apply certain categories to all syndicated posts, or all posts from |
| 1599 |
a particular feed; and (2) filter out all posts that don't match one |
| 1600 |
of the categories that are already in the WordPress database (allowing |
| 1601 |
for simple category-based filtering; just load up WordPress with the |
| 1602 |
categories you want to accept, and then tell FeedWordPress not to create |
| 1603 |
new ones). However, the way that (1) and (2) were implemented meant that |
| 1604 |
you couldn't effectively use them together; once you applied a known |
| 1605 |
category to all syndicated posts from a particular feed, it meant that |
| 1606 |
they'd have at least one familiar category (the category or categories |
| 1607 |
you were applying), and that would get all posts past the filter no |
| 1608 |
matter what categories they were originally from. |
| 1609 |
|
| 1610 |
Well, no longer. You can still apply categories to all syndicated posts |
| 1611 |
(using either Syndication --> Options, or the feed-level settings under |
| 1612 |
Links --> Syndicated). But these categories are not applied to the post |
| 1613 |
until *after* it has already passed by the "familiar categories" filter. |
| 1614 |
So now, if you want, you can do category filtering and *then* apply as |
| 1615 |
many categories as you please to all and only posts that pass the filter. |
| 1616 |
|
| 1617 |
* BUG FIX: Other minor typos and HTML gaffes were fixed along the way. |
| 1618 |
|
| 1619 |
* PERFORMANCE: get_feed_meta() no longer hits the database for information |
| 1620 |
on every call; it now caches link data in memory, so FeedWordPress only |
| 1621 |
goes to the database once for each syndicated link. This may |
| 1622 |
substantially improve performance if your database server resources |
| 1623 |
are tight and your templates make a lot of use of custom settings from |
| 1624 |
get_feed_meta(). |
| 1625 |
|
| 1626 |
* API CHANGE: Link ID numbers, rather than RSS URIs, are now used to |
| 1627 |
identify the feed from which a post is syndicated when you use template |
| 1628 |
functions such as get_feed_meta(). The practical upshot of this is you |
| 1629 |
can switch feeds, or change the feed address for a particular syndicated |
| 1630 |
site, without breaking your templates for all the posts that were |
| 1631 |
syndicated from the earlier URI. |
| 1632 |
|
| 1633 |
* API CHANGE: if you have plugins or templates that make use of the |
| 1634 |
get_feed_meta() function or the $fwp_feedmeta global, note that the |
| 1635 |
data formerly located under the `uri` and `name` fields is now located |
| 1636 |
under the `link/uri` field and the `link/name` field, respectively. Note |
| 1637 |
also that you can access the link ID number for any given feed under the |
| 1638 |
global $fwp_feedmeta['link/id'] (in plugins) or |
| 1639 |
get_feed_meta('link/id') (in a template in post contexts). |
| 1640 |
|
| 1641 |
* FEATURE: the settings for individual feeds can now be edited using a |
| 1642 |
humane interface (where formerly you had to tweak key-value pairs in the |
| 1643 |
Link Notes section). To edit settings for a feed, pick the feed that you |
| 1644 |
want under Links --> Syndicated and click the Edit link. |
| 1645 |
|
| 1646 |
* FEATURE: The "Unsubscribe" button (formerly "Delete") in Links --> |
| 1647 |
Syndicated now offers three options for unsubscribing from a feed: (1) |
| 1648 |
turning off the subscription without deleting the feed data or affecting |
| 1649 |
posts that were syndicated from the feed (this works by setting the Link |
| 1650 |
for the feed as "invisible"); (2) deleting the feed data and all of the |
| 1651 |
posts that were syndicated from the feed; or (3) deleting the feed data |
| 1652 |
and *keeping* the posts that were syndicated from the feed |
| 1653 |
setting the Link to "Invisible" (meaning that it will not be displayed |
| 1654 |
in lists of the site links on the front page, and it won't be checked |
| 1655 |
for updates; (2) deleting the Link and all of the posts that were |
| 1656 |
syndicated from its feed; or (3) deleting the feed data but keeping the |
| 1657 |
posts that were syndicated (which will henceforward be treated as if |
| 1658 |
they were local rather than syndicated posts). (Note that (1) is usually |
| 1659 |
the best option for aggregator sites, unless you want to clean up the |
| 1660 |
results of an error or a test.) |
| 1661 |
|
| 1662 |
* FEATURE / BUG FIX: If you have been receiving mysterious "I don't |
| 1663 |
syndicate...", or "(local) HTTP status code was not 200", or "(local) |
| 1664 |
transport error - could not open socket", or "parse error - not well |
| 1665 |
formed" errors, then this update may solve your problems, and if it does |
| 1666 |
*not* solve them, it will at least make the reasons for the problems |
| 1667 |
easier to understand. That's because I've overhauled the way that |
| 1668 |
FeedWordPress goes about updating feeds. |
| 1669 |
|
| 1670 |
If you use the command-line PHP scripting method to run scheduled |
| 1671 |
updates, then not much should change for you, except for fewer |
| 1672 |
mysterious errors. If you have done updates by sending periodic HTTP |
| 1673 |
requests to <http://your-blog.com/path/wp-content/update-feeds.php>, |
| 1674 |
then the details have changed somewhat; mostly in such a way as to make |
| 1675 |
things easier on you. See the README file or online documentation on |
| 1676 |
Staying Current for the details. |
| 1677 |
|
| 1678 |
* FEATURE: FeedWordPress now features a more sophisticated system for |
| 1679 |
timed updates. Instead of polling *every* subscribed feed for updates |
| 1680 |
*each* time `update-feeds.php` is run, FeedWordPress now keeps track of |
| 1681 |
the last time it polled each feed, and only polls them again after a |
| 1682 |
certain period of time has passed. The amount of time is normally set |
| 1683 |
randomly for each feed, in a period between 30 minutes and 2 hours (so |
| 1684 |
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 |
| 1685 |
directly by the feed, which brings us to ... |
| 1686 |
|
| 1687 |
* FEATURE: FeedWordPress now respects the settings in the `ttl` and |
| 1688 |
Syndication Module RSS elements. Feeds with these elements set will not |
| 1689 |
be polled any more frequently than they indicate with these feeds unless |
| 1690 |
the user manually forces FeedWordPress to poll the feed (see Links --> |
| 1691 |
Syndicated --> Edit settings). |
| 1692 |
|
| 1693 |
= 0.96 = |
| 1694 |
|
| 1695 |
* FEATURE: support has been added for enclosures in RSS 2.0 and Atom |
| 1696 |
0.6+ newsfeeds. WordPress already supports adding enclosures to an |
| 1697 |
item; FeedWordPress merely gets the information on the enclosure |
| 1698 |
from the feed it is syndicating and plugs that information directly |
| 1699 |
into the WordPress database so that (among other things) that post |
| 1700 |
will have its enclosure listed in your blog's RSS 2 newsfeed. |
| 1701 |
|
| 1702 |
Note that enclosure support requires using the optional MagpieRSS |
| 1703 |
upgrade (i.e., replacing your `wp-includes/rss-functions.php` with |
| 1704 |
`OPTIONAL/wp-includes/rss-functions.php` from the FWP archive) |
| 1705 |
|
| 1706 |
* FEATURE: for completeness's sake, there is now a feed setting, |
| 1707 |
`hardcode url`, that allows you to set the URI for the front page |
| 1708 |
of a contributor's website manually (that is, prevent it from being |
| 1709 |
automatically updated from the feed channel link on each update). To |
| 1710 |
set the URI manually, put a line like this in the Link Notes section |
| 1711 |
of a feed: |
| 1712 |
|
| 1713 |
hardcode url: yes |
| 1714 |
|
| 1715 |
You can also instruct FeedWordPress to use hardcoded URIs by default |
| 1716 |
on all feeds using Options --> Syndication |
| 1717 |
|
| 1718 |
* FEATURE: by default, when FeedWordPress finds new syndicated posts, |
| 1719 |
it (1) publishes them immediately, (2) turns comments off, and (3) |
| 1720 |
turns trackback / pingback pings off. You can now alter all three |
| 1721 |
default behaviors (e.g., to allow pings on syndicated posts, or to |
| 1722 |
send newly-syndicated posts to the draft pile for moderation) using |
| 1723 |
Options --> Syndication |
| 1724 |
|
| 1725 |
|
| 1726 |
= From 0.91 to 0.95 = |
| 1727 |
|
| 1728 |
* BUG FIX: Fixed an obscure bug in the handling of categories: |
| 1729 |
categories with trailing whitespace could cause categories with |
| 1730 |
duplicate names to be created. This no longer happens. While I was |
| 1731 |
at it I tightened up the operation of |
| 1732 |
FeedWordPress::lookup_categories() a bit in general. |
| 1733 |
|
| 1734 |
* FEATURE DEPRECATED: the feed setting `hardcode categories` is now |
| 1735 |
deprecated in favor of `unknown categories` (see below), which |
| 1736 |
allows you to strip off any syndication categories not already in |
| 1737 |
your database using `unknown categories: default` or `unknown |
| 1738 |
categories: filter`. If you have `hardcode categories: yes` set on a |
| 1739 |
feed, this will be treated as `unknown categories: default` (i.e., |
| 1740 |
no new categories will be added, but if a post doesn't match any of |
| 1741 |
the categories it will be added in the default category--usually |
| 1742 |
"Uncategorized" or "General"). |
| 1743 |
|
| 1744 |
* FEATURE: You can now set global defaults as to whether or not |
| 1745 |
FeedWordPress will update the Link Name and Link Description |
| 1746 |
settings for feeds automatically from the feed title and feed |
| 1747 |
tagline. (By default, it does, as it has in past versions.) Whether |
| 1748 |
this behavior is turned on or off, you can still override the |
| 1749 |
default behavior using feed settings of `hardcode name: yes`, |
| 1750 |
`hardcode name: no`, `hardcode description: yes`, or `hardcode |
| 1751 |
description: no`. |
| 1752 |
|
| 1753 |
* FEATURE: Users can now provide one or several "aliases" for an |
| 1754 |
author, just as they can for a category. For example, to make |
| 1755 |
FeedWordPress treat posts by "Joseph Cardinal Ratzinger" and "Pope |
| 1756 |
Benedict XVI" as by the same author, edit the user profile for Pope |
| 1757 |
Benedict XVI and add a line like this to the "User profile" field: |
| 1758 |
|
| 1759 |
a.k.a.: Joseph Cardinal Ratzinger |
| 1760 |
|
| 1761 |
You can add several aliases, each on a line by itself. You can also |
| 1762 |
add any other text you like to the Profile without interfering with |
| 1763 |
the aliases. |
| 1764 |
|
| 1765 |
* FEATURE: Users can now choose how to handle syndicated posts that |
| 1766 |
are in unfamiliar categories or by unfamiliar authors (i.e., |
| 1767 |
categories or authors whose names are not yet in the WordPress |
| 1768 |
database). By default, FeedWordPress will (as before) create a new |
| 1769 |
category (or new author) and use it for the current post and any |
| 1770 |
future posts. This behavior can be changed, either for all feeds or |
| 1771 |
for one or another particular feed. |
| 1772 |
|
| 1773 |
There are now three different options for an unfamiliar author: (1) |
| 1774 |
FeedWordPress can create a new author account and attribute the |
| 1775 |
syndicated post to the new account; (2) FeedWordPress can attribute |
| 1776 |
the post to an author if the author's name is familiar, and to a |
| 1777 |
default author (currently, this means the Site Administrator |
| 1778 |
account) if it is not; (3) FeedWordPress can drop posts by |
| 1779 |
unfamiliar authors and syndicate only posts by authors who are |
| 1780 |
already in the database. |
| 1781 |
|
| 1782 |
There are, similarly, two different options for an unfamiliar |
| 1783 |
category: (1) FeedWordPress can create new categories and place the |
| 1784 |
syndicated post in them; (2) FeedWordPress can drop the unfamiliar |
| 1785 |
categories and place syndicated posts only in categories that it is |
| 1786 |
already familiar with. In addition, FeedWordPress 0.95 lets you |
| 1787 |
choose whether posts that are in *no* familiar categories should be |
| 1788 |
syndicated (and placed in the default category for the blog) or |
| 1789 |
simply dropped. |
| 1790 |
|
| 1791 |
You can set the default behavior for both authors and categories |
| 1792 |
using the settings in Options --> Syndication. You can also set |
| 1793 |
different behavior for specific feeds by adding the `unfamiliar |
| 1794 |
author` and / or `unfamiliar categories` settings to the Link Notes |
| 1795 |
section of a feed: |
| 1796 |
|
| 1797 |
unfamiliar author: (create|default|filter) |
| 1798 |
unfamiliar categories: (create|default|filter) |
| 1799 |
|
| 1800 |
A setting of `unfamiliar author: create` will make FeedWordPress |
| 1801 |
create new authors to match unfamiliar author names *for this feed |
| 1802 |
alone*. A setting of `unfamiliar author: default` will make it |
| 1803 |
assign posts from unfamiliar authors to the default user account. A |
| 1804 |
setting of `unfamiliar author: filter` will cause all posts (from |
| 1805 |
this feed alone) to be dropped unless they are by an author already |
| 1806 |
listed in the database. Similiarly, `unfamiliar categories: create` |
| 1807 |
will make FeedWordPress create new categories to match unfamiliar |
| 1808 |
category names *for this feed alone*; `unfamiliar categories: |
| 1809 |
default` will cause it to drop any unfamiliar category names; and |
| 1810 |
`unfamiliar categories: filter` will cause it to *both* drop any |
| 1811 |
unfamiliar category names *and* to only syndicate posts that are |
| 1812 |
placed in one or more familiar categories. |
| 1813 |
|
| 1814 |
These two new features allow users to do some coarse-grained |
| 1815 |
filtering without having to write a PHP filter. Specifically, they |
| 1816 |
offer an easy way for you to filter feeds by category or by author. |
| 1817 |
Suppose, for example, that you only wanted to syndicate posts that |
| 1818 |
your contributors place in the "Llamas" category. You could do so by |
| 1819 |
setting up your installation of WordPress so that the only category |
| 1820 |
in the database is "Llamas," and then use Options --> Syndication to |
| 1821 |
set "Unfamiliar categories" to "don't create new categories and |
| 1822 |
don't syndicate posts unless they match at least one familiar |
| 1823 |
category". Now, when you update, only posts in the "Llamas" category |
| 1824 |
will be syndicated by FeedWordPress. |
| 1825 |
|
| 1826 |
Similarly, if you wanted to filter one particular feed so that only |
| 1827 |
posts by (for example) the author "Earl J. Llama" were syndicated to |
| 1828 |
your site, you could do so by creating a user account for Earl J. |
| 1829 |
Llama, then adding the following line to the settings for the feed |
| 1830 |
in Link Notes: |
| 1831 |
|
| 1832 |
unfamiliar author: filter |
| 1833 |
|
| 1834 |
This will cause any posts from this feed that are not authored by |
| 1835 |
Earl J. Llama to be discarded, and only the posts by Earl J. Llama |
| 1836 |
will be syndicated. (If the setting is used on one specific feed, it |
| 1837 |
will not affect how posts from other feeds are syndicated.) |
| 1838 |
|
| 1839 |
== License == |
| 1840 |
|
| 1841 |
The FeedWordPress plugin is copyright © 2005-2010 by Charles Johnson. It uses |
| 1842 |
code derived or translated from: |
| 1843 |
|
| 1844 |
- [wp-rss-aggregate.php][] by [Kellan Elliot-McCrea](kellan@protest.net) |
| 1845 |
- [MagpieRSS][] by [Kellan Elliot-McCrea](kellan@protest.net) |
| 1846 |
- [Ultra-Liberal Feed Finder][] by [Mark Pilgrim](mark@diveintomark.org) |
| 1847 |
- [WordPress Blog Tool and Publishing Platform](http://wordpress.org/) |
| 1848 |
|
| 1849 |
according to the terms of the [GNU General Public License][]. |
| 1850 |
|
| 1851 |
This program is free software; you can redistribute it and/or modify it under |
| 1852 |
the terms of the [GNU General Public License][] as published by the Free |
| 1853 |
Software Foundation; either version 2 of the License, or (at your option) any |
| 1854 |
later version. |
| 1855 |
|
| 1856 |
This program is distributed in the hope that it will be useful, but WITHOUT ANY |
| 1857 |
WARRANTY; without even the implied warranty of MERCHANTABILITY or FITNESS FOR A |
| 1858 |
PARTICULAR PURPOSE. See the GNU General Public License for more details. |
| 1859 |
|
| 1860 |
[wp-rss-aggregate.php]: http://laughingmeme.org/archives/002203.html |
| 1861 |
[MagpieRSS]: http://magpierss.sourceforge.net/ |
| 1862 |
[HTTP Navigator 2]: http://www.keyvan.net/2004/11/16/http-navigator/ |
| 1863 |
[Ultra-Liberal Feed Finder]: http://diveintomark.org/projects/feed_finder/ |
| 1864 |
[GNU General Public License]: http://www.gnu.org/copyleft/gpl.html |
| 1865 |
|
| 1866 |
|
