# feedwordpress/0.97/ChangeLog.text FeedWordPress, version 0.97. 319 lines. - Page: https://pluginprobe.com/plugins/feedwordpress/0.97/code/ChangeLog.text - Raw: https://pluginprobe.com/plugins/feedwordpress/0.97/raw/ChangeLog.text - Modified: 2007-11-21T22:56:02+00:00 Line numbers below start at 1. Link to a line or a range by appending a fragment to the page URL, for example `https://pluginprobe.com/plugins/feedwordpress/0.97/code/ChangeLog.text#L10-L20`. ``` FeedWordPress Change Log ======================== Changes from 0.96 to 0.97 ------------------------- * INSTALLATION PROCEDURE: Some of the changes between 0.96 and 0.97 require upgrades to the meta-data stored by FeedWordPress to work properly. Thus, if you are upgrading from 0.96 or earlier to 0.97, most FeedWordPress operations (including updates and template functions) WILL BE DISABLED until you run the upgrade procedure. Fortunately, running the upgrade procedure is easy: just go to either Options --> Syndication or Links --> Syndicated in the WordPress Dashboard and press the button. * FEED FORMAT SUPPORT: Support has been added for the Atom 1.0 IETF standard. Several other elements are also newly supported (dcterms:created, dcterms:issued, dcterms:modified, dc:identifier, proper support for the RSS 2.0 guid element, the RSS 2.0 author element, the use of Atom author or Dublin Core dc:creator constructs at the feed level to identify the author of individual items, etc.) N.B.: full support of several Atom 1.0 features, such as categories and enclosures, requires you to install the optional rss-functions.php upgrade in your wp-includes directory. * BUG FIX: Running `update-feeds.php` from command line or crontab returned "I don't syndicate..." errors. It turns out that WordPress sometimes tramples on the internal PHP superglobals that I depended on to determine whether or not the script was being invoked from the command line. This has been fixed (the variables are now checked *before* WordPress can trample them). Note that `update-feeds.php` has been thoroughly overhauled anyway; see below for details. * BUG FIX: Duplicate categories or author names. Fixed two bugs that could create duplicate author and/or category names when the name contained either (a) certain international characters (causing a mismatch between MySQL and PHP's handling of lowercasing text), or (b) characters that have a special meaning in regular expressions (causing MySQL errors when looking for the author or category due to regexp syntax errors). These should now be fixed thanks to careful escaping of names that go into regular expressions and careful matching of lowercasing functions (comparing results from PHP only to other results from PHP, and results from MySQL only to other results from MySQL). * BUG FIX: Items dated Decembr 31, 1969 should appear less often. The function for parsing W3C date-time format dates that ships with MagpieRSS can only correctly parse fully-specified dates with a fully-specified time, but valid W3C date-time format dates may omit the time, the day of the month, or even the month. Some feeds in the wild date their items with coarse-grained dates, so the optional `rss-functions.php` upgrade now includes a more flexible parse_w3cdtf() function that will work with both coarse-grained and fully-specified dates. (If parts of the date or the time are omitted, they are filled in with values based on the current time, so '2005-09-10' will be dated to the current time on that day; '2004' will be dated to this day and time one year ago. N.B.: This fix is only available in the optional `rss-functions.php` upgrade. * BUG FIX: Evil use of HTTP GET has been undone. The WordPress interface is riddled with inappropriate (non-idempotent) uses of HTTP GET queries (ordinary links that make the server do something with significant side-effects, such as deleting a post or a link from the database). FeedWordPress did some of this too, especially in places where it aped the WordPress interface (e.g. the "Delete" links in Links --> Syndicated). That's bad business, though. I've changed the interface so that all the examples of improper side-effects that I can find now require an HTTP POST to take effect. I think I got pretty much everything; if there's anything that I missed, let me know. Further reading: [Sam Ruby 2005-05-06: This Stuff Matters] (http://www.intertwingly.net/blog/2005/05/06/This-Stuff-Matters) * BUG FIX: Categories applied by `cats` setting should no longer prevent category-based filtering from working. In FeedWordPress, you can (1) apply certain categories to all syndicated posts, or all posts from a particular feed; and (2) filter out all posts that don't match one of the categories that are already in the WordPress database (allowing for simple category-based filtering; just load up WordPress with the categories you want to accept, and then tell FeedWordPress not to create new ones). However, the way that (1) and (2) were implemented meant that you couldn't effectively use them together; once you applied a known category to all syndicated posts from a particular feed, it meant that they'd have at least one familiar category (the category or categories you were applying), and that would get all posts past the filter no matter what categories they were originally from. Well, no longer. You can still apply categories to all syndicated posts (using either Syndication --> Options, or the feed-level settings under Links --> Syndicated). But these categories are not applied to the post until *after* it has already passed by the "familiar categories" filter. So now, if you want, you can do category filtering and *then* apply as many categories as you please to all and only posts that pass the filter. * BUG FIX: Other minor typos and HTML gaffes were fixed along the way. * PERFORMANCE: get_feed_meta() no longer hits the database for information on every call; it now caches link data in memory, so FeedWordPress only goes to the database once for each syndicated link. This may substantially improve performance if your database server resources are tight and your templates make a lot of use of custom settings from get_feed_meta(). * API CHANGE: Link ID numbers, rather than RSS URIs, are now used to identify the feed from which a post is syndicated when you use template functions such as get_feed_meta(). The practical upshot of this is you can switch feeds, or change the feed address for a particular syndicated site, without breaking your templates for all the posts that were syndicated from the earlier URI. * API CHANGE: if you have plugins or templates that make use of the get_feed_meta() function or the $fwp_feedmeta global, note that the data formerly located under the `uri` and `name` fields is now located under the `link/uri` field and the `link/name` field, respectively. Note also that you can access the link ID number for any given feed under the global $fwp_feedmeta['link/id'] (in plugins) or get_feed_meta('link/id') (in a template in post contexts). * FEATURE: the settings for individual feeds can now be edited using a humane interface (where formerly you had to tweak key-value pairs in the Link Notes section). To edit settings for a feed, pick the feed that you want under Links --> Syndicated and click the Edit link. * FEATURE: The "Unsubscribe" button (formerly "Delete") in Links --> Syndicated now offers three options for unsubscribing from a feed: (1) turning off the subscription without deleting the feed data or affecting posts that were syndicated from the feed (this works by setting the Link for the feed as "invisible"); (2) deleting the feed data and all of the posts that were syndicated from the feed; or (3) deleting the feed data and *keeping* the posts that were syndicated from the feed setting the Link to "Invisible" (meaning that it will not be displayed in lists of the site links on the front page, and it won't be checked for updates; (2) deleting the Link and all of the posts that were syndicated from its feed; or (3) deleting the feed data but keeping the posts that were syndicated (which will henceforward be treated as if they were local rather than syndicated posts). (Note that (1) is usually the best option for aggregator sites, unless you want to clean up the results of an error or a test.) * FEATURE / BUG FIX: If you have been receiving mysterious "I don't syndicate...", or "(local) HTTP status code was not 200", or "(local) transport error - could not open socket", or "parse error - not well formed" errors, then this update may solve your problems, and if it does *not* solve them, it will at least make the reasons for the problems easier to understand. That's because I've overhauled the way that FeedWordPress goes about updating feeds. If you use the command-line PHP scripting method to run scheduled updates, then not much should change for you, except for fewer mysterious errors. If you have done updates by sending periodic HTTP requests to , then the details have changed somewhat; mostly in such a way as to make things easier on you. See the README file or online documentation on Staying Current for the details. * FEATURE: FeedWordPress now features a more sophisticated system for timed updates. Instead of polling *every* subscribed feed for updates *each* time `update-feeds.php` is run, FeedWordPress now keeps track of the last time it polled each feed, and only polls them again after a certain period of time has passed. The amount of time is normally set randomly for each feed, in a period between 30 minutes and 2 hours (so 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 directly by the feed, which brings us to ... * FEATURE: FeedWordPress now respects the settings in the `ttl` and Syndication Module RSS elements. Feeds with these elements set will not be polled any more frequently than they indicate with these feeds unless the user manually forces FeedWordPress to poll the feed (see Links --> Syndicated --> Edit settings). Changes from 0.95 to 0.96 ------------------------- * FEATURE: support has been added for enclosures in RSS 2.0 and Atom 0.6+ newsfeeds. WordPress already supports adding enclosures to an item; FeedWordPress merely gets the information on the enclosure from the feed it is syndicating and plugs that information directly into the WordPress database so that (among other things) that post will have its enclosure listed in your blog's RSS 2 newsfeed. Note that enclosure support requires using the optional MagpieRSS upgrade (i.e., replacing your `wp-includes/rss-functions.php` with `OPTIONAL/wp-includes/rss-functions.php` from the FWP archive) * FEATURE: for completeness's sake, there is now a feed setting, `hardcode url`, that allows you to set the URI for the front page of a contributor's website manually (that is, prevent it from being automatically updated from the feed channel link on each update). To set the URI manually, put a line like this in the Link Notes section of a feed: hardcode url: yes You can also instruct FeedWordPress to use hardcoded URIs by default on all feeds using Options --> Syndication * FEATURE: by default, when FeedWordPress finds new syndicated posts, it (1) publishes them immediately, (2) turns comments off, and (3) turns trackback / pingback pings off. You can now alter all three default behaviors (e.g., to allow pings on syndicated posts, or to send newly-syndicated posts to the draft pile for moderation) using Options --> Syndication Changes from 0.91 to 0.95 ------------------------- * BUG FIX: Fixed an obscure bug in the handling of categories: categories with trailing whitespace could cause categories with duplicate names to be created. This no longer happens. While I was at it I tightened up the operation of FeedWordPress::lookup_categories() a bit in general. * FEATURE DEPRECATED: the feed setting `hardcode categories` is now deprecated in favor of `unknown categories` (see below), which allows you to strip off any syndication categories not already in your database using `unknown categories: default` or `unknown categories: filter`. If you have `hardcode categories: yes` set on a feed, this will be treated as `unknown categories: default` (i.e., no new categories will be added, but if a post doesn't match any of the categories it will be added in the default category--usually "Uncategorized" or "General"). * FEATURE: You can now set global defaults as to whether or not FeedWordPress will update the Link Name and Link Description settings for feeds automatically from the feed title and feed tagline. (By default, it does, as it has in past versions.) Whether this behavior is turned on or off, you can still override the default behavior using feed settings of `hardcode name: yes`, `hardcode name: no`, `hardcode description: yes`, or `hardcode description: no`. * FEATURE: Users can now provide one or several "aliases" for an author, just as they can for a category. For example, to make FeedWordPress treat posts by "Joseph Cardinal Ratzinger" and "Pope Benedict XVI" as by the same author, edit the user profile for Pope Benedict XVI and add a line like this to the "User profile" field: a.k.a.: Joseph Cardinal Ratzinger You can add several aliases, each on a line by itself. You can also add any other text you like to the Profile without interfering with the aliases. * FEATURE: Users can now choose how to handle syndicated posts that are in unfamiliar categories or by unfamiliar authors (i.e., categories or authors whose names are not yet in the WordPress database). By default, FeedWordPress will (as before) create a new category (or new author) and use it for the current post and any future posts. This behavior can be changed, either for all feeds or for one or another particular feed. There are now three different options for an unfamiliar author: (1) FeedWordPress can create a new author account and attribute the syndicated post to the new account; (2) FeedWordPress can attribute the post to an author if the author's name is familiar, and to a default author (currently, this means the Site Administrator account) if it is not; (3) FeedWordPress can drop posts by unfamiliar authors and syndicate only posts by authors who are already in the database. There are, similarly, two different options for an unfamiliar category: (1) FeedWordPress can create new categories and place the syndicated post in them; (2) FeedWordPress can drop the unfamiliar categories and place syndicated posts only in categories that it is already familiar with. In addition, FeedWordPress 0.95 lets you choose whether posts that are in *no* familiar categories should be syndicated (and placed in the default category for the blog) or simply dropped. You can set the default behavior for both authors and categories using the settings in Options --> Syndication. You can also set different behavior for specific feeds by adding the `unfamiliar author` and / or `unfamiliar categories` settings to the Link Notes section of a feed: unfamiliar author: (create|default|filter) unfamiliar categories: (create|default|filter) A setting of `unfamiliar author: create` will make FeedWordPress create new authors to match unfamiliar author names *for this feed alone*. A setting of `unfamiliar author: default` will make it assign posts from unfamiliar authors to the default user account. A setting of `unfamiliar author: filter` will cause all posts (from this feed alone) to be dropped unless they are by an author already listed in the database. Similiarly, `unfamiliar categories: create` will make FeedWordPress create new categories to match unfamiliar category names *for this feed alone*; `unfamiliar categories: default` will cause it to drop any unfamiliar category names; and `unfamiliar categories: filter` will cause it to *both* drop any unfamiliar category names *and* to only syndicate posts that are placed in one or more familiar categories. These two new features allow users to do some coarse-grained filtering without having to write a PHP filter. Specifically, they offer an easy way for you to filter feeds by category or by author. Suppose, for example, that you only wanted to syndicate posts that your contributors place in the "Llamas" category. You could do so by setting up your installation of WordPress so that the only category in the database is "Llamas," and then use Options --> Syndication to set "Unfamiliar categories" to "don't create new categories and don't syndicate posts unless they match at least one familiar category". Now, when you update, only posts in the "Llamas" category will be syndicated by FeedWordPress. Similarly, if you wanted to filter one particular feed so that only posts by (for example) the author "Earl J. Llama" were syndicated to your site, you could do so by creating a user account for Earl J. Llama, then adding the following line to the settings for the feed in Link Notes: unfamiliar author: filter This will cause any posts from this feed that are not authored by Earl J. Llama to be discarded, and only the posts by Earl J. Llama will be syndicated. (If the setting is used on one specific feed, it will not affect how posts from other feeds are syndicated.) ```