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