| Age | Commit message (Collapse) | Author |
|---|
|
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.
|
|
via the web.
|
|
configured
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.
|
|
This means we don't need to import Cwd and use abs_path.
|
|
|
|
This allows urlabs($foo, $config{url}) to be used safely, even if
no url is configured.
|
|
|
|
|
|
Non-edit pages are now back to having `<base>` set to the site's main url.
|
|
reading in enormous commits.
|
|
|
|
The warning was "Use of uninitialized value $IkiWiki::config{"url"} in
length" when running a modified t/tag.t.
|
|
Else setting parameters that do not appear in the template (such as
title_overridden) fails horribly.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
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.
|
|
This means we can use cgiurl() instead of $config{cgiurl} if an absolute
URL isn't desired.
|
|
"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 '/'.
|
|
|
|
|
|
In practice every use of glob2re uses it like that.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
I removed the IkiWiki::rcs_ stubs for the revert hooks. Instead
recentchanges tests to see if the hooks are available and calls
them directly.
|
|
|
|
|
|
|
|
|
|
|
|
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.
|
|
Abstraction violation. I now think the problem should be treated as a bug
in httpauth.
|
|
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.
|
|
|
|
PageSpec.
|
|
been disabled.
|
|
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.
|
|
|
|
|
|
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).
|
|
Handles the case where foo.mdwn is moved too foo/index.html
|
