> Okay just to be sure... if you embed an external image like > {{http://someserver.com/foo.jpg}} it works. Correct? Yup, that works fine. (neat, I didn't know you could do that!) Does that definitely download the image, though? Looking in .../wiki/media/_cache, there's nothing in there which is the file I'm pointing at. > //$elvl = error_reporting(E_ERROR); > $rss = fetch_rss($url); > //error_reporting($elvl); > > Try again. You should get some error (if not in the page then > in your errorlogs) That gets me more errors in the page; the problem is definitely something to do with how magpie is interacting with snoopy, but I don't think it's character sets -- if I put in more logging to trace the various HTTP response codes inside snoopy, then I get 302 from the first request, then 401 from the second one, as it redirects from wordpress to the internal websense page, then fails to authenticate with the second page. The {{image}} stuff doesn't seem to be using the Snoopy code to fetch things, so I guess that's why it's not having problems. The actual error I get is Warning: MagpieRSS: Failed to fetch http://wordpress.org/development/feed/ and cache is off in /var/www/html/wiki/inc/magpie/rss_fetch.inc on line 241 Setting $user and $pass in Snoopy.class.inc doesn't help any -- and, again, they're not set in the Wordpress install, and that can somehow manage to retrieve things just fine. Ah... the mystery starts to become clearer. I lied, Wordpress _can't_ retrieve things just fine. Once, a long time ago, it could retrieve things -- but now that I put the same logging into snoopy-in-wordpress, I get the same 302->401 sequence and failure as I do in Dokuwiki. Wordpress just looks like it's working because it has a cached version of the feed from a long time ago.. -- dan -- DokuWiki mailing list - more info at http://wiki.splitbrain.org/wiki:mailinglist