tail -f development.log

5 Comments

• Otto
  February 19th, 2008 at 12:22 pm

  Question: WordPress has built in feed-reading functionality (somewhat limited, but functional), and a built in caching system for reading those feeds. How is this better than that, or why would this be needed?

  Reference: http://codex.wordpress.org/Function_Reference/fetch_rss

• Craig
  February 19th, 2008 at 12:39 pm

  This is another alternative and provides a little better interface for the end-user to be able to grab and cache feeds.

  A lot of users don’t want to manually edit their theme files and put in the fetch_rss code and actually redisplay of the parsed feed. If you have 1 or 2 feeds, sure this is easy.

  Some of my users have over 50-100 feeds that they are fetching and displaying and having to duplicate that code that many times in your theme files can be a bit of a pain.

  The plugin gives a nice dashboard interface for the user to input as many feeds as they want in as many different groups as they want and allows them to also set various display options. Then, all they need to do is insert one line of code into their theme file where they want the output displayed.

  You can, of course, use fetch_rss, but I found it was easier to work with this plugin and I wrote the plugin at the request of several clients of mine. We also have found that the caching mechanism in using RSSCache (which Magpie uses) doesn’t actually work as advertised and can severely degrade page load performance in certain situations.

  Hope this answer helped and if not, please let me know what I can do to clarify

• Otto
  February 19th, 2008 at 1:08 pm

  What specifically doesn’t work about the RSSCache? I find that it works quite well, with a minor problem in cases where the feed URL changes.

  I do understand adding ease of use (one line calls, etc), but adding a whole extra caching mechanism using an external cron job and requiring Ruby support seems like major overkill to me.

• Otto
  February 19th, 2008 at 1:10 pm

  Extra: My main upshot was that it would seem to me that it would make more sense to improve the code in the WordPress core and submit that as a patch than to create a whole separate system to do something that the core code should have available in the first place. Why not fix the existing code (minor effort) instead of re-inventing the wheel (major effort)?

• Craig
  February 19th, 2008 at 1:20 pm

  Points well taken.

  This plugin was initially developed back for WordPress 2.0 for a client and was no released publically. At that time, I wasn’t satisfied with any built in WP RSS mechanism’s and we already had some custom Ruby scripts on my clients webserver so I decided to do write the Ruby script as I did.

  When two of my other clients requested basically the same functionality for their WP installs, I decided to roll the code I already had into a plugin to make it easier on myself to distribute and maintain. That is why the plugin has Ruby code and requires a CRON job instead of being all native PHP and using WP-Cron. I simply took the code I had available at the time and didn’t do much to rewrite that.

  But, now that you have brought it up I will investigate using fetch_rss and it should be pretty simple to convert the FeedCache plugin to use fetch_rss. This would achieve both goals of using WP core features and providing the nice interface for “non-techie” users to be able to setup their feeds.

  I’m actually in the process of making another FeedCache plugin called FeedCache Pipes that will provide much the same feature set as FeedCache and Yahoo Pipes. I’ll definitely look into using fetch_rss from the start.

  Also, your suggestion for submitting patches to improve the caching of RSSCache is appreciated. I’ll do the leg work and investigate and submit patches if I still see there being the caching problems I noticed back with WP 2.0.

Leave a Reply