I'm trying to set up a planet of my users' blogs. I've enabled the aggregate, meta, and tag plugins (but not htmltidy, that thing has a gajillion dependencies). aggregateinternal is 1. The cron job is running and I've also enabled the webtrigger. My usage is like so:
\[[!inline pages="internal(planet/*) show=0"]]
\[[!aggregate
name="Amitai's blog"
url="http://www.schmonz.com/"
dir="planet/schmonz-blog"
feedurl="http://www.schmonz.com/atom/"
expirecount="2"
tag="schmonz"
]]
\[[!aggregate
name="Amitai's photos"
url="http://photos.schmonz.com/"
dir="planet/schmonz-photos"
feedurl="http://photos.schmonz.com/main.php?g2_view=rss.SimpleRender&g2_itemId=7"
expirecount="2"
tag="schmonz"
]]
(and a few more aggregate directives like these)
Two things aren't working as I'd expect:
expirecount doesn't take effect on the first run, but on the second. (This is minor, just a bit confusing at first.)- Where are the article bodies for e.g. David's and Nathan's blogs? The bodies aren't showing up in the
._aggregated files for those feeds, but the bodies for my own blog do, which explains the planet problem, but I don't understand the underlying aggregation problem. (Those feeds include article bodies, and show up normally in my usual feed reader rss2email.) How can I debug this further? --[[schmonz]]
I only looked at David's, but its rss feed is not escaping the html
inside the rss description tags, which is illegal for rss 2.0. These
unknown tags then get ignored, including their content, and all that's
left is whitespace. Escaping the html to < and > fixes the
problem. You can see the feed validator complain about it here:
http://feedvalidator.org/check.cgi?url=http%3A%2F%2Fwww.davidj.org%2Frss.xml
It's sorta unfortunate that [[!cpan XML::Feed]] doesn't just assume the
un-esxaped html is part of the description field. Probably other feed
parsers are more lenient. --[[Joey]]
Thanks for the quick response (and the expirecount fix); I've forwarded it to David so he can fix his feed. Nathan's Atom feed validates -- it's generated by the same CMS as mine -- so I'm still at a loss on that one. --[[schmonz]]
Nathan's feed contains only summary elements, with no content elements.
This is legal according to the Atom spec, so I've fixed ikiwiki to use
the summary if no content is available. --[[Joey]]
After applying your diffs, blowing away my cached aggregated stuff, and running the aggregate cron job by hand, the resulting planet still doesn't have Nathan's summaries... and the two posts from each feed that aren't being expired aren't the two newest ones (not sure what the pattern is there). Have I done something wrong? --[[schmonz]]
I think that both issues are now fixed. Thanks for testing.
--[[Joey]]
I can confirm, they're fixed on my end. --[[schmonz]]
New bug: new posts aren't getting displayed (or cached for aggregation). After fixing his feed, David posted a new item today, and the aggregator is convinced there's nothing to do, whether by cronjob or webtrigger. I verified that it wasn't another problem with his feed by adding another of my ikiwiki's feed to the planet, running the aggregator, posting a new item, and running the aggregator again: no new item. --[[schmonz]]
Even if you start it more frequently, aggregation will only occur every
updateinterval minutes (default 15), maximum. Does this explain what
you're seeing? --[[Joey]]
Crap, right, and my test update has since made it into the planet. His post still hasn't. So it must be something with David's feed again? A quick test with XML::Feed looks like it's parsing just fine: --[[schmonz]]
$ perl
use XML::Feed;
my $feed = XML::Feed->parse(URI->new('http://www.davidj.org/rss.xml')) or die XML::Feed->errstr;
print $feed->title, "\n";
for my $entry ($feed->entries) {
print $entry->title, ": ", $entry->issued, "\n";
}
^D
davidj.org
Amway Stories - Refrigerator Pictures: 2008-09-19T00:12:27
Amway Stories - Coffee: 2008-09-13T10:08:17
Google Alphabet Update: 2008-09-11T22:55:37
Writing for writing's sake: 2008-09-09T23:39:05
Google Chrome: 2008-09-02T23:12:26
Mister Casual: 2008-07-25T09:01:17
Parental Conversations: 2008-07-24T10:44:44
Place Of George Orwell: 2008-06-03T22:11:07
The Raw Beauty Of A National Duolian: 2008-05-31T12:41:06
I had no problem getting the "Refrigerator Pictures" post to aggregate
here, though without a copy of the old feed I can't be 100% sure I've
reproduced your ikiwiki's state. --[[Joey]]
Okay, I blew away the cached entries and aggregator state files and reran the aggregator and all appears well again. If the problem recurs I'll be sure to post here. :-) --[[schmonz]]
On the off chance that you retained a copy of the old state, I'd not
mind having a copy to investigate. --[[Joey]]
Didn't think of that, will keep a copy if there's a next time. -- [[schmonz]]
In a corporate environment where feeds are generally behind
authentication, I need to prime the aggregator's LWP::UserAgent
with some cookies. What I've done is write a custom plugin to populate
$config{cookies} with an HTTP::Cookies object, plus this diff:
--- /var/tmp/pkg/lib/perl5/vendor_perl/5.10.0/IkiWiki/Plugin/aggregate.pm 2010-06-24 13:03:33.000000000 -0400
+++ aggregate.pm 2010-06-24 13:04:09.000000000 -0400
@@ -488,7 +488,11 @@
}
$feed->{feedurl}=pop @urls;
}
- my $res=URI::Fetch->fetch($feed->{feedurl});
+ my $res=URI::Fetch->fetch($feed->{feedurl},
+ UserAgent => LWP::UserAgent->new(
+ cookie_jar => $config{cookies},
+ ),
+ );
if (! $res) {
$feed->{message}=URI::Fetch->errstr;
$feed->{error}=1;
It works, but I have to remember to apply the diff whenever I update
ikiwiki. Can you provide a more elegant means of allowing cookies and/or
the user agent to be programmatically manipulated? --[[schmonz]]
Ping -- is the above patch perhaps acceptable (or near-acceptable)? -- [[schmonz]]
Pong.. I'd be happier with a more 100% solution that let cookies be used
w/o needing to write a custom plugin to do it. --[[Joey]]
According to LWP::UserAgent, for the common case, a complete
and valid configuration for $config{cookies} would be { file => "$ENV{HOME}/.cookies.txt" }. In the more common case of not needing
to prime one's cookies, cookie_jar can be undef (that's the
default). In my less common case, the cookies are generated by
visiting a couple magic URLs, which would be trivial to turn into
config options, except that these particular URLs rely on SPNEGO
and so LWP::Authen::Negotiate has to be loaded. So I think adding
$config{cookies} (and using it in the aggregate plugin) should
be safe, might help people in typical cases, and won't prevent
further enhancements for less typical cases. --[[schmonz]]
|
