Since commit c4d4cad3be, the single dot in
a pagespec can be used to mean the current page. While this worked
correctly in link() it didn't work in backlink(). Fix this by explicitly
checking the testpage in backlink against . and replacing it with the
current location if necessary.
This has been a while coming. It turns out that non-excutable setup files
have a number of benefits. Also, I find YAML setup files easier to edit
myself, and I suspect many users will prefer not needing to deal with
perl syntax.
This brings back the old behavior before urlto changes for this case.
It will generate a path like "/foo", which is not right, but is
the same as is generated by urlto($page, "", 1) -- which is what
the code that now uses 1-parameter urlto used to use.
To get an absolute version you can use cgiurl(cgiurl => $config{cgiurl}).
The only place in IkiWiki that seems to actually need an absolute URL
is the openid plugin, and that already uses the named parameter.
"local" here is short for "locally valid" - the idea is that we can use
URLs that are relative in the sense of only having the path part, but
absolute in the sense that they start from '/', such as
'/~smcv/ikiwiki.cgi'. There's no particularly good name that I can find
for these between-relative-and-absolute URLs.
They're useful because in the common case where the pages and the CGI
script have the same scheme and authority component, each page is
identified by the same locally-valid URL when linking from any page or
from the CGI, without hard-coding a choice between HTTP and HTTPS, or
between multiple virtual hostnames with the same path layout. As such,
we can use them in many situations that previously used an absolute URL.
If there's no suitable semi-absolute value for local_url (for instance,
if your pages and your CGI reside on different servers), we can just fall
back to using the absolute URL. I append '/' because $config{url} doesn't
end with '/', but the common case for local_url (on all branchable.com
sites, for instance) is that it's just '/'.
plovs reported a crash when templates were not installed properly,
with a non-useful error about the template object not being defined.
I've audited all uses of template_depends(), and template(), and it makes
sense for them to throw an error if the template cannot be found. All code
with a user-supplied template catches errors already, to handle template
parse failures.
It did not make sense for template_file to throw errors, as some code uses
it to probe if a template file is available.
Avoid the generic "you are not allowed to change" message,
and instead allow check_canedit to propigate out useful error messages.
Went back to calling check_canedit in fatal mode, but added a parameter to
avoid calling the troublesome subs that might cause a login attempt.
Since it already looks for things starting with a dot, I was able to avoid
matching against the string twice.
This also fixes a minor bug; $from may not be defined. Avoid uninitialized
value warnings in this case.