| 1 |
FeedWordPress Change Log |
| 2 |
======================== |
| 3 |
|
| 4 |
Changes from 0.98 to 0.981 |
| 5 |
-------------------------- |
| 6 |
|
| 7 |
Version 0.981 is a narrowly targeted bugfix and compatibility release, whose |
| 8 |
main purpose is to resolve a major outstanding problem: the incompatibility |
| 9 |
between version 0.98 of WordPress and the recently released WordPress 2.1. |
| 10 |
|
| 11 |
* WORDPRESS 2.1 COMPATIBILITY: FeedWordPress is now compatible with |
| 12 |
WordPress 2.1, as well as retaining its existing support for WordPress |
| 13 |
2.0 and 1.5. Incompatibilities that resulted in database warnings, fatal |
| 14 |
errors, and which prevented FeedWordPress from syndicating new posts, |
| 15 |
have been eliminated. |
| 16 |
|
| 17 |
* RSS-FUNCTIONS.PHP RENAMED TO RSS.PHP: if you use the upgraded MagpieRSS |
| 18 |
replacement that's included with FeedWordPress, be sure to note that |
| 19 |
there are now *two* files to upload from the `OPTIONAL/wp-includes` |
| 20 |
subdirectory in order to carry out the upgrade: rss-functions.php and |
| 21 |
rss.php. **It is necessary to upload both files**, due to a change in |
| 22 |
the file naming scheme in WordPress 2.1, and it is necessary to do so |
| 23 |
whether you are using WordPress 2.1 or not. If you only upload the |
| 24 |
`rss-functions.php` file as in previous installations you will not have |
| 25 |
a working copy of MagpieRSS; the rss.php file contains the actual code. |
| 26 |
|
| 27 |
* DATE BUG AFFECTING SOME PHP INSTALLATIONS RESOLVED: due to a subtle bug |
| 28 |
in parse_w3cdtf(), some installations of PHP encountered problems with |
| 29 |
FeedWordPress's attempt to date posts, which would cause some new posts |
| 30 |
on Atom feeds to be dated as if they had apppeared in 1969 or 1970 |
| 31 |
(thus, effectively, never appearing on front apge at all). This bug in |
| 32 |
the date handling should now be fixed. |
| 33 |
|
| 34 |
* PHP <?=...?> SHORT FORM ELIMINATED: some installations of PHP do not |
| 35 |
allow the <?=...?> short form for printing PHP values, which was used |
| 36 |
extensively in the FeedWordPress interface code. Since this could cause |
| 37 |
fatal errors for users with the wrong installation of PHP, the short |
| 38 |
form has been replaced with full PHP echo statements, and is no longer |
| 39 |
used in FeedWordPress. |
| 40 |
|
| 41 |
* BETTER USER INTERFACE INTEGRATION WITH WORDPRESS 2.x: Some minor changes |
| 42 |
have been made to help the FeedWordPress interface pages blend in better |
| 43 |
with the user interface when running under WordPress 2.x. |
| 44 |
|
| 45 |
* GLOBAL CATEGORIES BUG RESOLVED: a bug that prevented some users from |
| 46 |
setting one or more categories to apply to syndicated posts from all |
| 47 |
feeds (using the checkbox interface under Options --> Syndication) has |
| 48 |
been resolved. |
| 49 |
|
| 50 |
Changes from 0.97 to 0.98 |
| 51 |
-------------------------- |
| 52 |
|
| 53 |
* WORDPRESS 2.0 COMPATIBILITY: This is a narrowly-targeted release to |
| 54 |
solve a major outstanding problem. FeedWordPress is now compatible with |
| 55 |
both WordPress 1.5 and WordPress 2.0. Incompatibilities that caused |
| 56 |
fatal SQL errors, and a more subtle bug with off-kilter counts of posts |
| 57 |
under a given category, have been resolved. FeedWordPress tests for |
| 58 |
database schema using the global $wp_db_version variable (if null, then |
| 59 |
we presume that we're dealing with WordPress 1.5). |
| 60 |
|
| 61 |
NOTE: I have **not** fully tested FeedWordPress with WordPress 2.0. |
| 62 |
Further testing may reveal more bugs. However, you should now be able |
| 63 |
to get at least basic FeedWordPress functionality up and running. |
| 64 |
|
| 65 |
* AUTHOR MATCHING: FeedWordPress tests several fields to see if it can |
| 66 |
identify the author of the post as a user already in the WordPress user |
| 67 |
database. In previous versions, it tested the user login, the nickname, |
| 68 |
and tested for "aliases" listed in the Profile (see documentation). FWP |
| 69 |
now also matches authors on the basis of e-mail address (*if* an e-mail |
| 70 |
address is present). This is particularly helpful for formats such as |
| 71 |
RSS 2.0, in which authors are primarily identified by e-mail addresses. |
| 72 |
|
| 73 |
Changes from 0.96 to 0.97 |
| 74 |
------------------------- |
| 75 |
|
| 76 |
* INSTALLATION PROCEDURE: Some of the changes between 0.96 and 0.97 |
| 77 |
require upgrades to the meta-data stored by FeedWordPress to work |
| 78 |
properly. Thus, if you are upgrading from 0.96 or earlier to 0.97, most |
| 79 |
FeedWordPress operations (including updates and template functions) |
| 80 |
WILL BE DISABLED until you run the upgrade procedure. Fortunately, |
| 81 |
running the upgrade procedure is easy: just go to either Options --> |
| 82 |
Syndication or Links --> Syndicated in the WordPress Dashboard and press |
| 83 |
the button. |
| 84 |
|
| 85 |
* FEED FORMAT SUPPORT: Support has been added for the Atom 1.0 IETF |
| 86 |
standard. Several other elements are also newly supported |
| 87 |
(dcterms:created, dcterms:issued, dcterms:modified, dc:identifier, |
| 88 |
proper support for the RSS 2.0 guid element, the RSS 2.0 author element, |
| 89 |
the use of Atom author or Dublin Core dc:creator constructs at the feed |
| 90 |
level to identify the author of individual items, etc.) |
| 91 |
|
| 92 |
N.B.: full support of several Atom 1.0 features, such as categories |
| 93 |
and enclosures, requires you to install the optional rss-functions.php |
| 94 |
upgrade in your wp-includes directory. |
| 95 |
|
| 96 |
* BUG FIX: Running `update-feeds.php` from command line or crontab |
| 97 |
returned "I don't syndicate..." errors. It turns out that WordPress |
| 98 |
sometimes tramples on the internal PHP superglobals that I depended on |
| 99 |
to determine whether or not the script was being invoked from the |
| 100 |
command line. This has been fixed (the variables are now checked |
| 101 |
*before* WordPress can trample them). Note that `update-feeds.php` has |
| 102 |
been thoroughly overhauled anyway; see below for details. |
| 103 |
|
| 104 |
* BUG FIX: Duplicate categories or author names. Fixed two bugs that could |
| 105 |
create duplicate author and/or category names when the name contained |
| 106 |
either (a) certain international characters (causing a mismatch between |
| 107 |
MySQL and PHP's handling of lowercasing text), or (b) characters that |
| 108 |
have a special meaning in regular expressions (causing MySQL errors when |
| 109 |
looking for the author or category due to regexp syntax errors). These |
| 110 |
should now be fixed thanks to careful escaping of names that go into |
| 111 |
regular expressions and careful matching of lowercasing functions |
| 112 |
(comparing results from PHP only to other results from PHP, and results |
| 113 |
from MySQL only to other results from MySQL). |
| 114 |
|
| 115 |
* BUG FIX: Items dated Decembr 31, 1969 should appear less often. The |
| 116 |
function for parsing W3C date-time format dates that ships with |
| 117 |
MagpieRSS can only correctly parse fully-specified dates with a |
| 118 |
fully-specified time, but valid W3C date-time format dates may omit the |
| 119 |
time, the day of the month, or even the month. Some feeds in the wild |
| 120 |
date their items with coarse-grained dates, so the optional |
| 121 |
`rss-functions.php` upgrade now includes a more flexible parse_w3cdtf() |
| 122 |
function that will work with both coarse-grained and fully-specified |
| 123 |
dates. (If parts of the date or the time are omitted, they are filled in |
| 124 |
with values based on the current time, so '2005-09-10' will be dated to |
| 125 |
the current time on that day; '2004' will be dated to this day and time |
| 126 |
one year ago. |
| 127 |
|
| 128 |
N.B.: This fix is only available in the optional `rss-functions.php` |
| 129 |
upgrade. |
| 130 |
|
| 131 |
* BUG FIX: Evil use of HTTP GET has been undone. The WordPress interface |
| 132 |
is riddled with inappropriate (non-idempotent) uses of HTTP GET queries |
| 133 |
(ordinary links that make the server do something with significant |
| 134 |
side-effects, such as deleting a post or a link from the database). |
| 135 |
FeedWordPress did some of this too, especially in places where it aped |
| 136 |
the WordPress interface (e.g. the "Delete" links in Links --> |
| 137 |
Syndicated). That's bad business, though. I've changed the interface so |
| 138 |
that all the examples of improper side-effects that I can find now |
| 139 |
require an HTTP POST to take effect. I think I got pretty much |
| 140 |
everything; if there's anything that I missed, let me know. |
| 141 |
|
| 142 |
Further reading: [Sam Ruby 2005-05-06: This Stuff Matters] (http://www.intertwingly.net/blog/2005/05/06/This-Stuff-Matters) |
| 143 |
|
| 144 |
* BUG FIX: Categories applied by `cats` setting should no longer prevent |
| 145 |
category-based filtering from working. In FeedWordPress, you can (1) |
| 146 |
apply certain categories to all syndicated posts, or all posts from |
| 147 |
a particular feed; and (2) filter out all posts that don't match one |
| 148 |
of the categories that are already in the WordPress database (allowing |
| 149 |
for simple category-based filtering; just load up WordPress with the |
| 150 |
categories you want to accept, and then tell FeedWordPress not to create |
| 151 |
new ones). However, the way that (1) and (2) were implemented meant that |
| 152 |
you couldn't effectively use them together; once you applied a known |
| 153 |
category to all syndicated posts from a particular feed, it meant that |
| 154 |
they'd have at least one familiar category (the category or categories |
| 155 |
you were applying), and that would get all posts past the filter no |
| 156 |
matter what categories they were originally from. |
| 157 |
|
| 158 |
Well, no longer. You can still apply categories to all syndicated posts |
| 159 |
(using either Syndication --> Options, or the feed-level settings under |
| 160 |
Links --> Syndicated). But these categories are not applied to the post |
| 161 |
until *after* it has already passed by the "familiar categories" filter. |
| 162 |
So now, if you want, you can do category filtering and *then* apply as |
| 163 |
many categories as you please to all and only posts that pass the filter. |
| 164 |
|
| 165 |
* BUG FIX: Other minor typos and HTML gaffes were fixed along the way. |
| 166 |
|
| 167 |
* PERFORMANCE: get_feed_meta() no longer hits the database for information |
| 168 |
on every call; it now caches link data in memory, so FeedWordPress only |
| 169 |
goes to the database once for each syndicated link. This may |
| 170 |
substantially improve performance if your database server resources |
| 171 |
are tight and your templates make a lot of use of custom settings from |
| 172 |
get_feed_meta(). |
| 173 |
|
| 174 |
* API CHANGE: Link ID numbers, rather than RSS URIs, are now used to |
| 175 |
identify the feed from which a post is syndicated when you use template |
| 176 |
functions such as get_feed_meta(). The practical upshot of this is you |
| 177 |
can switch feeds, or change the feed address for a particular syndicated |
| 178 |
site, without breaking your templates for all the posts that were |
| 179 |
syndicated from the earlier URI. |
| 180 |
|
| 181 |
* API CHANGE: if you have plugins or templates that make use of the |
| 182 |
get_feed_meta() function or the $fwp_feedmeta global, note that the |
| 183 |
data formerly located under the `uri` and `name` fields is now located |
| 184 |
under the `link/uri` field and the `link/name` field, respectively. Note |
| 185 |
also that you can access the link ID number for any given feed under the |
| 186 |
global $fwp_feedmeta['link/id'] (in plugins) or |
| 187 |
get_feed_meta('link/id') (in a template in post contexts). |
| 188 |
|
| 189 |
* FEATURE: the settings for individual feeds can now be edited using a |
| 190 |
humane interface (where formerly you had to tweak key-value pairs in the |
| 191 |
Link Notes section). To edit settings for a feed, pick the feed that you |
| 192 |
want under Links --> Syndicated and click the Edit link. |
| 193 |
|
| 194 |
* FEATURE: The "Unsubscribe" button (formerly "Delete") in Links --> |
| 195 |
Syndicated now offers three options for unsubscribing from a feed: (1) |
| 196 |
turning off the subscription without deleting the feed data or affecting |
| 197 |
posts that were syndicated from the feed (this works by setting the Link |
| 198 |
for the feed as "invisible"); (2) deleting the feed data and all of the |
| 199 |
posts that were syndicated from the feed; or (3) deleting the feed data |
| 200 |
and *keeping* the posts that were syndicated from the feed |
| 201 |
setting the Link to "Invisible" (meaning that it will not be displayed |
| 202 |
in lists of the site links on the front page, and it won't be checked |
| 203 |
for updates; (2) deleting the Link and all of the posts that were |
| 204 |
syndicated from its feed; or (3) deleting the feed data but keeping the |
| 205 |
posts that were syndicated (which will henceforward be treated as if |
| 206 |
they were local rather than syndicated posts). (Note that (1) is usually |
| 207 |
the best option for aggregator sites, unless you want to clean up the |
| 208 |
results of an error or a test.) |
| 209 |
|
| 210 |
* FEATURE / BUG FIX: If you have been receiving mysterious "I don't |
| 211 |
syndicate...", or "(local) HTTP status code was not 200", or "(local) |
| 212 |
transport error - could not open socket", or "parse error - not well |
| 213 |
formed" errors, then this update may solve your problems, and if it does |
| 214 |
*not* solve them, it will at least make the reasons for the problems |
| 215 |
easier to understand. That's because I've overhauled the way that |
| 216 |
FeedWordPress goes about updating feeds. |
| 217 |
|
| 218 |
If you use the command-line PHP scripting method to run scheduled |
| 219 |
updates, then not much should change for you, except for fewer |
| 220 |
mysterious errors. If you have done updates by sending periodic HTTP |
| 221 |
requests to <http://your-blog.com/path/wp-content/update-feeds.php>, |
| 222 |
then the details have changed somewhat; mostly in such a way as to make |
| 223 |
things easier on you. See the README file or online documentation on |
| 224 |
Staying Current for the details. |
| 225 |
|
| 226 |
* FEATURE: FeedWordPress now features a more sophisticated system for |
| 227 |
timed updates. Instead of polling *every* subscribed feed for updates |
| 228 |
*each* time `update-feeds.php` is run, FeedWordPress now keeps track of |
| 229 |
the last time it polled each feed, and only polls them again after a |
| 230 |
certain period of time has passed. The amount of time is normally set |
| 231 |
randomly for each feed, in a period between 30 minutes and 2 hours (so |
| 232 |
as to stagger updates over time rather than polling all of the feeds at once. However, the length of time between updates can also be set |
| 233 |
directly by the feed, which brings us to ... |
| 234 |
|
| 235 |
* FEATURE: FeedWordPress now respects the settings in the `ttl` and |
| 236 |
Syndication Module RSS elements. Feeds with these elements set will not |
| 237 |
be polled any more frequently than they indicate with these feeds unless |
| 238 |
the user manually forces FeedWordPress to poll the feed (see Links --> |
| 239 |
Syndicated --> Edit settings). |
| 240 |
|
| 241 |
Changes from 0.95 to 0.96 |
| 242 |
------------------------- |
| 243 |
|
| 244 |
* FEATURE: support has been added for enclosures in RSS 2.0 and Atom |
| 245 |
0.6+ newsfeeds. WordPress already supports adding enclosures to an |
| 246 |
item; FeedWordPress merely gets the information on the enclosure |
| 247 |
from the feed it is syndicating and plugs that information directly |
| 248 |
into the WordPress database so that (among other things) that post |
| 249 |
will have its enclosure listed in your blog's RSS 2 newsfeed. |
| 250 |
|
| 251 |
Note that enclosure support requires using the optional MagpieRSS |
| 252 |
upgrade (i.e., replacing your `wp-includes/rss-functions.php` with `OPTIONAL/wp-includes/rss-functions.php` from the FWP archive) |
| 253 |
|
| 254 |
* FEATURE: for completeness's sake, there is now a feed setting, |
| 255 |
`hardcode url`, that allows you to set the URI for the front page |
| 256 |
of a contributor's website manually (that is, prevent it from being |
| 257 |
automatically updated from the feed channel link on each update). To |
| 258 |
set the URI manually, put a line like this in the Link Notes section |
| 259 |
of a feed: |
| 260 |
|
| 261 |
hardcode url: yes |
| 262 |
|
| 263 |
You can also instruct FeedWordPress to use hardcoded URIs by default |
| 264 |
on all feeds using Options --> Syndication |
| 265 |
|
| 266 |
* FEATURE: by default, when FeedWordPress finds new syndicated posts, |
| 267 |
it (1) publishes them immediately, (2) turns comments off, and (3) |
| 268 |
turns trackback / pingback pings off. You can now alter all three |
| 269 |
default behaviors (e.g., to allow pings on syndicated posts, or to |
| 270 |
send newly-syndicated posts to the draft pile for moderation) using |
| 271 |
Options --> Syndication |
| 272 |
|
| 273 |
|
| 274 |
Changes from 0.91 to 0.95 |
| 275 |
------------------------- |
| 276 |
|
| 277 |
* BUG FIX: Fixed an obscure bug in the handling of categories: |
| 278 |
categories with trailing whitespace could cause categories with |
| 279 |
duplicate names to be created. This no longer happens. While I was |
| 280 |
at it I tightened up the operation of |
| 281 |
FeedWordPress::lookup_categories() a bit in general. |
| 282 |
|
| 283 |
* FEATURE DEPRECATED: the feed setting `hardcode categories` is now |
| 284 |
deprecated in favor of `unknown categories` (see below), which |
| 285 |
allows you to strip off any syndication categories not already in |
| 286 |
your database using `unknown categories: default` or `unknown |
| 287 |
categories: filter`. If you have `hardcode categories: yes` set on a |
| 288 |
feed, this will be treated as `unknown categories: default` (i.e., |
| 289 |
no new categories will be added, but if a post doesn't match any of |
| 290 |
the categories it will be added in the default category--usually |
| 291 |
"Uncategorized" or "General"). |
| 292 |
|
| 293 |
* FEATURE: You can now set global defaults as to whether or not |
| 294 |
FeedWordPress will update the Link Name and Link Description |
| 295 |
settings for feeds automatically from the feed title and feed |
| 296 |
tagline. (By default, it does, as it has in past versions.) Whether |
| 297 |
this behavior is turned on or off, you can still override the |
| 298 |
default behavior using feed settings of `hardcode name: yes`, |
| 299 |
`hardcode name: no`, `hardcode description: yes`, or `hardcode |
| 300 |
description: no`. |
| 301 |
|
| 302 |
* FEATURE: Users can now provide one or several "aliases" for an |
| 303 |
author, just as they can for a category. For example, to make |
| 304 |
FeedWordPress treat posts by "Joseph Cardinal Ratzinger" and "Pope |
| 305 |
Benedict XVI" as by the same author, edit the user profile for Pope |
| 306 |
Benedict XVI and add a line like this to the "User profile" field: |
| 307 |
|
| 308 |
a.k.a.: Joseph Cardinal Ratzinger |
| 309 |
|
| 310 |
You can add several aliases, each on a line by itself. You can also |
| 311 |
add any other text you like to the Profile without interfering with |
| 312 |
the aliases. |
| 313 |
|
| 314 |
* FEATURE: Users can now choose how to handle syndicated posts that |
| 315 |
are in unfamiliar categories or by unfamiliar authors (i.e., |
| 316 |
categories or authors whose names are not yet in the WordPress |
| 317 |
database). By default, FeedWordPress will (as before) create a new |
| 318 |
category (or new author) and use it for the current post and any |
| 319 |
future posts. This behavior can be changed, either for all feeds or |
| 320 |
for one or another particular feed. |
| 321 |
|
| 322 |
There are now three different options for an unfamiliar author: (1) |
| 323 |
FeedWordPress can create a new author account and attribute the |
| 324 |
syndicated post to the new account; (2) FeedWordPress can attribute |
| 325 |
the post to an author if the author's name is familiar, and to a |
| 326 |
default author (currently, this means the Site Administrator |
| 327 |
account) if it is not; (3) FeedWordPress can drop posts by |
| 328 |
unfamiliar authors and syndicate only posts by authors who are |
| 329 |
already in the database. |
| 330 |
|
| 331 |
There are, similarly, two different options for an unfamiliar |
| 332 |
category: (1) FeedWordPress can create new categories and place the |
| 333 |
syndicated post in them; (2) FeedWordPress can drop the unfamiliar |
| 334 |
categories and place syndicated posts only in categories that it is |
| 335 |
already familiar with. In addition, FeedWordPress 0.95 lets you |
| 336 |
choose whether posts that are in *no* familiar categories should be |
| 337 |
syndicated (and placed in the default category for the blog) or |
| 338 |
simply dropped. |
| 339 |
|
| 340 |
You can set the default behavior for both authors and categories |
| 341 |
using the settings in Options --> Syndication. You can also set |
| 342 |
different behavior for specific feeds by adding the `unfamiliar |
| 343 |
author` and / or `unfamiliar categories` settings to the Link Notes |
| 344 |
section of a feed: |
| 345 |
|
| 346 |
unfamiliar author: (create|default|filter) |
| 347 |
unfamiliar categories: (create|default|filter) |
| 348 |
|
| 349 |
A setting of `unfamiliar author: create` will make FeedWordPress |
| 350 |
create new authors to match unfamiliar author names *for this feed |
| 351 |
alone*. A setting of `unfamiliar author: default` will make it |
| 352 |
assign posts from unfamiliar authors to the default user account. A |
| 353 |
setting of `unfamiliar author: filter` will cause all posts (from |
| 354 |
this feed alone) to be dropped unless they are by an author already |
| 355 |
listed in the database. Similiarly, `unfamiliar categories: create` |
| 356 |
will make FeedWordPress create new categories to match unfamiliar |
| 357 |
category names *for this feed alone*; `unfamiliar categories: |
| 358 |
default` will cause it to drop any unfamiliar category names; and |
| 359 |
`unfamiliar categories: filter` will cause it to *both* drop any |
| 360 |
unfamiliar category names *and* to only syndicate posts that are |
| 361 |
placed in one or more familiar categories. |
| 362 |
|
| 363 |
These two new features allow users to do some coarse-grained |
| 364 |
filtering without having to write a PHP filter. Specifically, they |
| 365 |
offer an easy way for you to filter feeds by category or by author. |
| 366 |
Suppose, for example, that you only wanted to syndicate posts that |
| 367 |
your contributors place in the "Llamas" category. You could do so by |
| 368 |
setting up your installation of WordPress so that the only category |
| 369 |
in the database is "Llamas," and then use Options --> Syndication to |
| 370 |
set "Unfamiliar categories" to "don't create new categories and |
| 371 |
don't syndicate posts unless they match at least one familiar |
| 372 |
category". Now, when you update, only posts in the "Llamas" category |
| 373 |
will be syndicated by FeedWordPress. |
| 374 |
|
| 375 |
Similarly, if you wanted to filter one particular feed so that only |
| 376 |
posts by (for example) the author "Earl J. Llama" were syndicated to |
| 377 |
your site, you could do so by creating a user account for Earl J. |
| 378 |
Llama, then adding the following line to the settings for the feed |
| 379 |
in Link Notes: |
| 380 |
|
| 381 |
unfamiliar author: filter |
| 382 |
|
| 383 |
This will cause any posts from this feed that are not authored by |
| 384 |
Earl J. Llama to be discarded, and only the posts by Earl J. Llama |
| 385 |
will be syndicated. (If the setting is used on one specific feed, it |
| 386 |
will not affect how posts from other feeds are syndicated.) |
| 387 |
|
| 388 |
|
