Version 0.6 of the OPML Renderer Plugin for WordPress has been released.
This release primarily fixes some bugs and enhances some functions. In the works for the next release is inclusion of RSS feeds, which would enable feed grazing.
Dan MacTough
Version 0.6 of the OPML Renderer Plugin for WordPress has been released.
This release primarily fixes some bugs and enhances some functions. In the works for the next release is inclusion of RSS feeds, which would enable feed grazing.
Comments are closed.
Hey, great plugin. I just installed the latest version on my WP 2.0 install and it works great, with one small tweak. On line 149, I had to replace
$xsltfree($xsltinst);
with
xsltfree($xsltinst);
That is, I changed it to be a function call. Other than that, good stuff! If I had to have a wishlist for this plugin, it might look something like this:
* Have it use the nifty feed icon, instead of the XML icons
* A link or button for expanding/collapsing all groups, and a switch to specify it as a default.
* Some sort of switch to easily shut off the caching. For those running in safe mode, caching files locally can be cumbersome.
Cheers,
-Justin
Wow, nice catch on line 149, Justin. Thanks! I’m a little comforted by the fact that that was borrowed code. 😉
Regarding the feed icon: I’ll probably change at some point, but I don’t think the new icon is universally recognized yet.
I’ve considered adding more options to the expand/collapse state. The initial state is dictated by the XSL stylesheet, so I have to think about how to implement this. I guess all initially expanded is actually pretty easy. Then I’d need some sort of button to expand/collapse all, and the javascript to go with it. I’m not really a javascript guru, to put it mildly, so I’ll have to figure out how to walk the whole tree and set that state. It’s doable, I think. I guess that’ll be on my future features list.
I don’t want to make it easy to switch off caching because of the potential to really hammer a site that’s hosting a remote OPML file. I mean, without caching, you’d pull a remote file on every page load. That’s really nasty. I made a point of not releasing this plugin until I was sure that the caching was working properly for just that reason. If you turn it off and include files from someone else’s server, you’re going to make enemies very quickly if you get even moderate traffic on your site. However, I was planning on moving the cache to the database, which I believe would address your issue. It would probably be faster, too. Unfortunately, I don’t know how the inclusion feature will work with the database…. I’ve got to mull that over.
Thanks very much for your feedback.
Good point. One solution to consider might be disabling the caching (manually via a switch or automatically) when you are using a local file, as opposed to a remote one. -j
Point taken. I’ll disable caching of local files.