Released: FeedWordPress 2012.1218. WordPress 3.5 compatibility, PHP 5.4 compatibility, bug fixes, diagnostics improvements, and a great deal more.

It’s been a long time, much too long, since my last official release announcement. But I’m happy to announce that today I have released v. 2012.1218(http://downloads.wordpress.org/plugin/feedwordpress.2012.1218.zip), now available for download from the Plugins Repository(http://wordpress.org/extend/plugins/feedwordpress/) or from [1](https://github.com/radgeek/feedwordpress/).

This announcement is actually doing double duty as an announcement for two releases. The first release, **FeedWordPress version 2012.1212**, which came out last Wednesday, was an important compatibility release to ensure compatibility with WordPress 3.5 and PHP 5.4; as well as a roll-up of the many changes and improvements in FeedWordPress, which have been documented here, but which never got into the WordPress plugins repository since previous official public release in 2011(http://feedwordpress.radgeek.com/2011/10/19/feedwordpress-2011-1019/). Today’s release, **FeedWordPress 2012.1218**, is an incremental update improving on 2012.1212 by rolling in some bug fixes in response to issues reported by users after the 2012.1212 upgrade.

There are many more changes in the big release than I’ll try to document here, but we can hit up some of the highlights:

### FeedWordPress 2012.1212 changes ###

  • **WORDPRESS 3.5 COMPATIBILITY:** This release has been tested for compatibility with new releases of WordPress, up to version 3.5, and any documented compatibility issues have been cleared — in particular, if you were seeing error pages stating that you don’t have permission to access the FeedWordPress Syndication page within the WordPress admin interface, then upgrading to this release should fix the problem.

As always, if you encounter any compatibility problems after upgrading your version of WordPress and your version of FeedWordPress to the most recent versions, please contact me with as detailed a description as possible of the issue you are encountering, the circumstances you’re encountering it under, what you expect to see happening, and what is happening instead.

* **PHP 5.4 COMPATIBILITY:** This release has been audited to fix potential problems with deprecation notices or fatal errors under recent versions of PHP. In particular, all uses of run-time pass-by-reference have been eliminated from the code; if you were seeing a fatal error reading “Call-time pass-by-reference has been removed …” then upgrading to this release should fix the problem.

* **CUSTOMIZATION FRAMEWORK:** A great deal of work has been done to make the underlying framework more flexible, so that PHP add-ons can be written to adapt FeedWordPress to handle custom XML vocabularies, expiration of posts under specified conditions, and other custom behavior.

* **BUGFIX: MANUALLY EDITED POST SLUGS NOT OVERWRITTEN.** Thanks to a report by Chris Fritz, I’ve identified some code that causes post slugs for the posts generated by FWP to be rewritten with every update, even if the user has manually updated the slug from within the WordPress editing interface. This has been fixed: FWP will continue to generate new slugs for syndicated posts, but when syndicated posts are updated, they will retain the slug that they had at the time of the update; any manual changes to the post slug should be preserved.

* **USER-AGENT STRING:** FeedWordPress now sends a distinctive User-Agent string identifying itself, and noting that it is a feed aggregator.

* **MISCELLANEOUS PERFORMANCE IMPROVEMENTS:** A number of changes have been made to try to reduce the intensity and expense in terms of both database performance and web server memory consumption.

* **DIAGNOSTICS IMPROVEMENTS:** A number of new and improved diagnostics have been added which should aid in understanding and troubleshooting issues that may arise.

Here are the specific incremental changes and bugfixes made in today’s release, 2012.1218.

### FeedWordPress 2012.1218 changes ###

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

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

* **BUG FIX: PERMALINKS REWRITTEN FOR CUSTOM POST TYPES AS WELL AS NORMAL WORDPRESS POSTS.** If you had WordPress set up to syndicate incoming posts to a custom post type (under Syndication > Posts & Links), and asked FeedWordPress to make “permalinks point to the original site”, then previous versions of FeedWordPress would fail to do the rewriting — permalinks would only be rewritten to point to the original source for normal WordPress posts, not for custom post types. In 2012.1218 this bug has been fixed: all post types will now have permalinks rewritten unless you request for permalinks to point to the local copy on your aggregator site.

* **BUG FIX: ELIMINATES “PHP Fatal error: Call to a member function setting() on a non-object….”** Some changes to the in-memory caching of information about feed subscriptions in 2012.1212 could result in a fatal PHP error in cases where you have de-activated one of your subscriptions, but posts from that subscription were still in the archive. This would normally show up through half-completed feeds or half-completed pages that suddenly broke off in the middle, and displayed or logged an error message like: “PHP Fatal error: Call to a member function setting() on a non-object in {…}/wp-content/plugins/feedwordpress/feedwordpress.php on line 615”. This bug has been eliminated, so affected feeds and pages should now render correctly, and the error message should no longer appear.

* **BUG FIX: CATEGORY BOXES IN SYNDICATION > CATEGORIES & TAGS.** Some minor bugs in the appearance and animation of category checkboxes (for example, the checkbox used to select categories for syndicated posts on the Syndication > Categories & Tags settings page) have been fixed.

### 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(http://feedwordpress.radgeek.com/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 out the new release(http://downloads.wordpress.org/plugin/feedwordpress.2012.1218.zip)! Download and enjoy!

1 thought on “Released: FeedWordPress 2012.1218. WordPress 3.5 compatibility, PHP 5.4 compatibility, bug fixes, diagnostics improvements, and a great deal more.

  1. The latest version seems to be running wild in creating “syndicateditemhash” entries in the WP database. I just one single post with 450,000 database entries with different hashes. It would be helpful if a future edition did not do this and had the ability to remove so many duplicate hash records.

Comments are closed.