With a relative xrds-location, the openid perl client module will fail.
I haven't checked the specs to see if it needs to be absolute, but all
examples I've seen are absolute, so it seems a very good idea.
I also tried setting RPC::XML::ENCODING but that did not prevent the crash,
and it seems that blogspam.net doesn't like getting xml encoded in unicode,
since it mis-flagged comments as spammy that way that are normally allowed
through.
The rss spec says that unless the attribute is set, guid elements *are*
permalinks. The problem with that is that if [[meta permalink=]] is used,
as is done with aggregated posts, that goes into the link element, and
apparently some rss readers prefer the not-really-permalink in the guid
element when linking to the post.
Without meta permalink, the link and guid elements have the same content,
so it should be ok, in that case too for the guid to not be a permalink.
(Checked and this does not flood aggregators.)
The idea here is that <meta name="foo" description="bar">
can be written like [[!meta name="foo" description="bar">.
Of course, [[!meta foo=bar]] is still supported; this new feature
provides some DWIM when trying to directly convert a meta tag into
a meta directive.
template_depends was adding a dependency on the source filename,
instead of on the page name when a template is a page. Such a
dependency doesn't work.
Since misctemplate is called with a page context, the comments plugin
thinks it should add that, as well as the comment link in the actionbar.
I kept the comment link because a quick link back to the comments to a page
is sorta useful.
Cleanly fixed case where destdir file failed to be written because there
was a directory with the same name. This can be detected with no extra
system calls, and dealt with by finding all pages that wrote files
inside the directory, and removing them and the directory.
The other, inverse case would be expensive to detect in will_render,
since it would need to check each parent directory of the file to see
if the directory is really a conflicting file. But prep_writefile
already does a similar scan for symlinks in the path, so I added code
there to remove the conflicting file. This fix assumes that the file
is written using writefile, and not some other means (but using other means
would be a security hole too, so hopefully nothing does).
Joey Hess