FeedWordPress 2017.1020. New Boilerplate / Credits feature rolled into main settings interface, code modernization, PHP compatibility fixes, and more.

To-day I released a new version of version 2017.1020[1]. This version includes one major visible new feature in the plugin, and a lot of smaller changes, some of them bug fixes and others compatibility tweaks. test it out, and enjoy.(https://wordpress.org/plugins/feedwordpress/)

This release includes a major new feature, in a certain sense: you can now set up Boilerplate / Credit attribution text for syndicated posts directly from the FeedWordPress admin interface, without having to touch your template or theme files. This functionality has been available for a long time by installing a separate “experimental” add-on, FWP+: Add Attribution; but after several years of recommending the same add-on to multiple correspondents, with its feature set remaining largely unchanged, I figured it was long since time to incorporate the “experiment” into the off-the-shelf code.)

FeedWordPress is now an extremely … “mature” project, at over 12 years old. I have been working on it on and off as time, academic obligations, and the rest of life allowed, but I regret that I haven’t been doing a very good job here of documenting the changes as they’ve been made, or more actively enhancing and improving the product above and beyond responding to relatively simple bug reports. In the next few months, I expect to have significantly more time and mind space to recommit to keeping this project not just functional, but useful, enjoyable and up to date with ongoing development in the WordPress world. Part of that is going to be making an effort to keep up more with documenting the progress here on this website, rather than simply syndicating in batches of geek-talk from the changes I make behind the scenes at Github or in the WordPress plugins repository SVN. So, in the interest of catching up a bit on that, here’s some of the significant changes that have occurred over the past year in FeedWordPress:

### 2017.1020 ###

* 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 [2].” 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.

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:

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: 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!

* 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.

### 2017.0913 ###

* 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:

http://www.example.com/?guid=c1cd28da39e8d7babcf6499983aca545
https://www.example.com/?guid=c1cd28da39e8d7babcf6499983aca545

… 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.

* 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.

* AVOID “PHP Warning: shell_exec() has been disabled for security reasons in [3]/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.

### 2016.1213 ###

* WORDPRESS BACKWARD COMPATIBILITY FOR VERSIONS 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 ‘[4]/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.

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.

### 2016.1211 ###

* WORDPRESS COMPATIBILITY: Tested with new versions of WordPress up to 4.7.

* 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.

* 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.

* 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.

### As always ###
If you notice any problems, have any questions, need any help, or just want to say Hi, don’t hesitate to me a line(/contact) via e-mail or through the comment form. If you have a specific problem that you need help with, please try to describe the circumstances and the problem you are seeing in as much detail as possible — what you expected to happen, what you see happening instead, what you are doing (if anything) when the error comes up. If the problem has to do with one or more particular feeds, it helps a lot to include the URL(s) of the feed or feeds that you’re seeing the problem with. If the problem has to do with an error message appearing that you do not understand, a screenshot of the error message would help a lot.

Now get on out there and check out the new release! and enjoy![5]

[6]: https://downloads.wordpress.org/plugin/feedwordpress.2017.1020.zip

FeedWordPress 2011.1018. It’s like two upgrades in one!

I’m happy to announce that ** version 2011.1018 is now available for download(http://downloads.wordpress.org/plugin/feedwordpress.2011.1018.zip).**

This announcement is actually going to sum up the changes for a couple of different releases of FeedWordPress. The previous public release, **2011.0721**, was released some time ago, and has been available at through the WordPress plugin repository, but I was unable to post the announcement on the project due to an unfortunate combination of two factors: a technical breakdown at the old project website, and a cross-country move that effectively prevented me from taking the time to fix the breakdown. Happily, the move is over and, rather than fixing the breakdown, I have simply decided to migrate the project website over to a brand new home. (Same URL as before, but running the latest release of WordPress.) So, without further ado, here are the changes made in today’s release, along with the changes that 2011.0721 had already introduced:

### Version 2011.1018 ###

* **HTTP BASIC AND DIGEST AUTHENTICATION SUPPORT:** FeedWordPress now offers
improved support for syndicating feeds that make use of HTTP Basic or HTTP
Digest authentication methods. In order to set up authentication on one of
your feeds, just go to its Settings > Feed page, and click on the “Uses
Username/Password” link underneath the Feed URL. Enter the username and
password for accessing the feed, then select the authentication method. (If
you’re not sure which method your feed provider uses, try Basic first.)
Save Changes, and syndicate away.

**NOTE:** HTTP Digest support requires the curl module for PHP. If you are not
sure whether this module has been installed, contact your web hosting
provider to check.

* **WP 3.3 (BETA) COMPATIBILITY:** This version fixes an init-sequence bug that
could cause intrusive warning messages or fatal errors in WP 3.3 beta
versions.

* **BUGFIX: FIXES LONG DELAYS IN UPDATES SCHEDULES IN LARGE INSTALLATIONS.** A
performance feature introduced in version 2011.0721 had some flaws in its
implementation, which tended to create serious delays (on the order of
several hours) in FeedWordPress’s attempts to schedule updates for feeds,
when users had a very large number of feeds (several dozen or more) in their
FeedWordPress installation. This feature has been reconfigured to adjust
dynamically to the number of feeds in Syndicated Sources and the frequency
with which they are updated. If you’ve seen a lot of ready-to-update feeds
piling up, several hours after they were supposed to get updated, then this
upgrade should better ensure that your feeds get updated in a timely fashion.

* **BUGFIX: syndicated_item_guid FILTERS FIXED.** Previous versions of
FeedWordPress theoretically allowed for filters on the syndicated_item_guid
hook, which was intended to filter the globally-unique identifier element
(rss:guid or atom:id) — useful if you need to convince FeedWordPress to use
different guids, or to recognize two or more incoming posts as versions of
the same post rather than as distinct items. However, while the hook
affected the guid stored in the WordPress database, it did not affect the
guid used to check whether an incoming feed item had already been syndicated
or was a new item — which greatly limited the practical usefulness of the
filter. This bug has been fixed: syndicated_item_guid filters should now
properly control not only the final database record, but also the initial
uniqueness test applied to posts.

### Version 2011.0721 ###

* **BUGFIX: SERIOUS BUG CAUSING RARE UNEXPECTED DELETION OF PAGES AND OTHER
CONTENT.** A bug in the guid-checking code for some rare kinds of guids could
cause content in the wp_posts table to seemingly disappear at random after
FeedWordPress updates.This most frequently but not exclusively affected
static pages. What actually happened is that in these rare cases the
existing static page was mistaken for an older version of the new incoming
syndicated post, which was then stored as a new revision of the original
page. The bug that caused these mistaken identities has been fixed.

* **BUGFIX: UNWANTED AUTOMATIC PAGE-LOAD-BASED UPDATES NO LONGER A NUISANCE.**
Some users encountered a bug in which FeedWordPress would adopt an automatic
page-load-based update method, even if they had requested that it not do
so, and that it use a manual or cron job update method instead. The bug
causing this has been fixed, and page-load-based updates should no longer
trigger unless explicitly turned on.

* **WP 3.2 USER INTERFACE COMPATIBILITY: POST TAGS BOX NOW WORKS AGAIN.** The
release of WordPress 3.2 caused a breakage in the tags box which prevented
you from adding or removing tags under Syndication –> Categories & Tags.
(The breakage was the result of an incompatibility introduced by the new
release of jQuery.) This breakage has now been fixed, and the tags box
should work correctly again.

* **FEED UPDATE SCHEDULING IMPROVEMENTS: UI.** The Syndicated Sources table now
provides considerably more data to understand update scheduling, when
specific scheduling decisions are made because of, e.g., requests from the
feed producer.

* **FEED UPDATE SCHEDULING IMPROVEMENTS: ENFORCEABLE “MINIMUM INTERVAL” SETTING
TO SPACE OUT UPDATES.** Some feeds request specific update schedules, using
standard elements such as sy:updateFrequency and rss:ttl. Normally,
FeedWordPress respects any scheduling requests that a feed makes — if it
requests a longer gap between polls than what FWP would normally adopt, then
FWP slows down to meet the request. If it indicates a shorter gap than what
FWP would normally adopt, FWP speeds up and checks that feed for updates
more often than it normally would. Now, there should not be any way for user
settings to override an explicit slow-down request from the feed producer —
if producers indicate a particular update schedule, then polling the feed
more frequently than they request is considered abusive behavior. But
there’s no reason why users should not be able — if they so desire — to
override speed-up requests, and poll a feed *less* frequently than the
indicated update schedule, if the FWP user wants to space update checkins
over a longer interval of time. Before, they could not do this: FWP always
sped up to meet the indicated update schedule. Now, they can do this, by
using the new “Minimum Interval” setting in Syndication –> Feeds &
Updates..

As always, if you notice any problems, have any questions, need any help, or just want to say “Hi,” don’t hesitate to me a line(/contact) via e-mail or through the comment form. Keep in mind that while I do my best to answer any e-mails I receive about FeedWordPress, I’m currently working through a significant backlog of e-mails (somewhere in the high dozens or low hundreds) that accumulated while I was making my move. So for the time being, you can assume I’ll be getting back to you, but it may be a few days before that happens.

Now and enjoy(http://downloads.wordpress.org/plugin/feedwordpress.2011.1018.zip)!